磁盘空间与 inode 管理:从 df 到 lsof 的生产排障全攻略

概述 凌晨三点,你被告警吵醒——线上数据库写入失败,Nginx 起不来,SSH 登录卡顿。登上服务器一查,df -h 显示根分区 100%。这种事每个运维都遇到过,磁盘满大概是生产环境最高频的故障类型之一,根据实际运维统计,磁盘相关告警占比约 15%-20%。 但磁盘满不是一个简单问题。df -h 看到的 100% 可能并不是全部真相: inode 耗尽:磁盘空间还有剩余,但文件系统inode用完了,照样报 No space left on device。这种问题更隐蔽,排查难度也更大。 已删除文件未释放:rm 删了大文件,df 显示空间没变。因为还有进程持有文件描述符,数据块并没有真正释放。 预留空间:ext4 默认预留 5% 空间给 root,400GB 的数据盘就有 20GB 被"藏"起来了。 这篇文章把磁盘空间和 inode 管理的排查思路、清理策略、预防机制一次说透。所有命令都在 Ubuntu 22.04 和 CentOS 7.9 上实测过,能直接拿去用。 磁盘空间的两个维度:blocks 与 inode 很多人对磁盘空间的理解只停留在"还剩多少 GB"这个层面。但 Linux 文件系统管理的是两个独立资源:数据块(blocks) 和 索引节点(inode)。 打个比方:文件系统像一个停车场。blocks 是停车位,inode 是停车记录。停车场可能还有空车位(blocks 没满),但记录本写满了(inode 耗尽),新来的车也停不进去。 inode 是什么 inode(Index Node,索引节点)是文件系统里描述文件元数据的数据结构。每个文件或目录对应一个 inode,存储了以下信息: 元数据字段 说明 文件类型 普通文件、目录、符号链接等 权限信息 rwx 权限位 所有者 uid 和 gid 文件大小 字节数 时间戳 atime / mtime / ctime 数据块指针 指向实际数据存储位置的索引 硬链接数 指向该 inode 的目录项数量 注意一个关键点:inode 不存储文件名。文件名存在目录项(dentry)中,目录项将文件名映射到 inode 编号。这也是为什么硬链接能存在——多个文件名可以指向同一个 inode。...

July 23, 2026 · 9 分钟 · 1726 字 · 徐保金

大模型辅助故障排查:从日志分析到根因定位

概述 大模型辅助故障排查:从日志分析到根因定位是SRE运维工作中的重要技能。在实际生产环境中,掌握这些技术能够有效提升系统的稳定性和运维效率。 为什么需要大模型辅助故障排查 随着系统规模的扩大和复杂度的增加,传统的运维手段已经难以满足现代分布式系统的需求。大模型辅助故障排查能够帮助运维团队: 快速定位问题:通过系统化的工具和方法,缩短故障排查时间 提升系统可见性:建立全面的监控和可观测性体系 预防故障发生:通过主动发现和修复潜在风险,降低故障率 优化资源利用:合理分配和调度资源,提升系统性能 核心概念与原理 基础概念 大模型辅助故障排查的核心在于建立标准化的流程和自动化的工具链。主要包括以下几个方面: 数据收集与处理:从各种数据源收集指标、日志和追踪信息 分析与可视化:通过仪表盘和告警系统展示系统状态 自动化响应:基于预设规则自动执行修复操作 持续优化:根据历史数据和反馈不断改进流程 关键技术点 1. 配置管理 合理的配置管理是大模型辅助故障排查的基础。建议使用版本控制工具管理配置文件,确保变更可追溯: # 示例:配置版本控制 # 所有配置文件存放在 Git 仓库中 git init /etc/monitoring cd /etc/monitoring git add . git commit -m "Initial monitoring configuration" 2. 自动化工具选择 根据团队技术栈选择合适的工具: 场景 推荐工具 说明 配置管理 Ansible 无代理,适合中小规模 容器编排 Kubernetes 云原生标准 监控告警 Prometheus + Grafana 开源,社区活跃 日志收集 Loki / ELK 轻量或功能丰富 CI/CD GitLab CI / GitHub Actions 与代码托管集成 实践案例 场景:生产环境故障排查 假设线上服务出现响应延迟,排查步骤如下:...

June 13, 2026 · 1 分钟 · 185 字 · 徐保金

Kubernetes Pod故障排查速查

排查路径 kubectl get pods → 看状态 kubectl describe pod → 看 Events kubectl logs → 看日志 常见 Pod 状态 状态 含义 常见原因 Pending 未调度 资源不足、调度约束 CrashLoopBackOff 崩溃重启 应用异常、配置错误 ImagePullBackOff 镜像拉取失败 镜像不存在、认证失败 OOMKilled 内存溢出 内存限制过低 CrashLoopBackOff 排查 最常见故障,排查步骤: # 查看上次崩溃日志 kubectl logs <pod> --previous # 查看退出码 kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}' 退出码含义: 137:OOMKilled → 增加 resources.limits.memory 1:应用错误 → 查应用日志 126/127:命令不存在或权限问题 ImagePullBackOff 排查 kubectl describe pod <pod> | grep -A5 Events 常见原因:镜像名拼写错误、仓库需认证、网络不通。...

May 8, 2024 · 1 分钟 · 185 字 · 徐保金