Linux 运维从经验驱动到数据驱动

经验驱动的运维在大规模高频率场景下已失效，因传统命令仅提供瞬时局部指标，缺乏趋势分析、历史对比与根因关联能力。

经验驱动的运维正在失效——当服务规模超过百台节点、变更频率达到每天数十次时，靠“感觉”和“上次这么搞没出事”已经扛不住了。

为什么 top 和 df -h 不再够用

它们给出的是瞬时快照，不是趋势；是局部指标，不是关联证据。比如 load average 高，可能是 CPU 密集型任务，也可能是 I/O 等待，还可能是内存回收卡顿——单靠 top 无法区分。

• vmstat 1 能补上上下文（si/so 看 swap、bi/bo 看磁盘吞吐），但仍是命令行拼凑
• 没有历史对比：今天 %wa 是 30%，但上周三同一时段也是 28%，这算异常吗？
• 告警滞后：等 df -h 显示 /var/log 95% 才触发，日志轮转可能已失败三次

从 crontab + awk 到 prometheus + grafana 的真实过渡点

真正切换的临界点不是“想上监控”，而是某次故障复盘发现：所有猜测都缺数据佐证，而手动扒 /var/log/messages 和 journalctl 花了 47 分钟才定位到 systemd-journald 的 RateLimitIntervalSec 配置被改小了。

• 用 node_exporter 替代手写 df 脚本：它默认暴露 node_filesystem_avail_bytes，配合 predict_linear() 可预测磁盘耗尽时间
• process_exporter 比 ps aux --sort=-%cpu 更稳：能持续跟踪进程生命周期，避免采样间隙漏掉短命进程
• Grafana 里一个 irate(node_cpu_seconds_total{mode="idle"}[5m]) 就能反推真实 CPU 使用率，不用再心算 100 - idle%

journalctl --since "2 hours ago" 为什么不该是故障排查第一动作

它查得慢、过滤弱、无聚合。当 systemd 每秒写入 200+ 条日志时，文本 grep 本质是暴力扫描。

• 优先查 loki + logql：例如 {job="systemd-journal"} |~ "OOM|killed process"，毫秒级返回
• 关键服务必须加结构化日志：python 用 structlog、Go 用 zerolog，让 level="Error" service="nginx" upstream_status="502" 可被直接切片分析
• journalctl 只保留在无远程日志系统时的兜底角色，且务必加 -o json 配合 jq 做字段提取，别用 grep -A5 猜上下文

数据驱动不是堆工具，是把“我怀疑是网络问题”变成“rate(node_network_receive_errs_total{device="eth0"}[1h]) 突增 300 倍”。最常被跳过的一步，是给每个指标配业务语义标签——比如给 http_request_duration_seconds_bucket 加上 endpoint="/api/v1/order" 和 payment_method="alipay"，否则再好的时序库也只是一堆无意义的曲线。