经验驱动的运维在大规模高频率场景下已失效，因传统命令仅提供瞬时局部指标，缺乏趋势分析、历史对比与根因关联能力。
经验驱动的运维正在失效——当服务规模超过百台节点、变更频率达到每天数十次时，靠“感觉”和“上次这么搞没出事”已经扛不住了。
为什么 top 和 df -h 不再够用
它们给出的是瞬时快照，不是趋势；是局部指标，不是关联证据。比如 load average 高，可能是 CPU 密集型任务，也可能是 I/O 等待，还可能是内存回收卡顿——单靠 top 无法区分。
-
vmstat 1能补上上下文（si/so看 swap、bi/bo看磁盘吞吐），但仍是命令行拼凑 - 没有历史对比：今天
%wa是 30%，但上周三同一时段也是 28%，这算异常吗？ - 告警滞后：等
df -h显示/var/log95% 才触发，日志轮转可能已失败三次
从 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"，否则再好的时序库也只是一堆无意义的曲线。
