凌晨两点，控样我盯着Zabbix面板上那条突然飙升的容易CPU曲线，心里骂了一句。控样机房那台跑了三年的容易老服务器，负载从0.8蹦到14，控样报警邮件已经堆了十几封。容易这不是控样我第一次半夜爬起来看监控，但每次都想摔键盘——明明装了Prometheus，容易配了Grafana，控样告警规则也写了一大堆，容易真出事的控样时候还是手忙脚乱。

问题不在工具。容易Linux监控这摊子事，控样难的容易是你知道该盯什么。

先搞清楚你到底怕什么

刚入行那会儿，控样我恨不得把能装的监控全装上。Nagios、Cacti、Zabbix、Prometheus，一套接一套。结果呢？机器上跑了十几个agent，光采集进程就吃掉5%的CPU。后来一个老运维跟我说了句话：监控不是越多越好，是你得知道哪几个指标要命。

他给我看了他的清单，就四个东西：磁盘满没满、内存够不够、负载高不高、关键进程死没死。其他全是锦上添花。我当时不太服气，觉得这也太糙了。直到有次线上事故，根因是/var/log分区被写满，导致Nginx没法写日志直接挂了。而我的Zabbix上配了三十多条告警规则，偏偏没设磁盘使用率的阈值。

所以第一步，别急着搭平台。先问自己：这台机器挂了，最直接的原因可能是什么？

命令行那几把刷子够用了

很多人瞧不上top、free、df这些命令，觉得太土。但你真在故障现场的时候，SSH上去敲几个命令，比打开浏览器登Grafana快得多。

我习惯用vmstat 1看整体，iostat -x 1看磁盘IO，ss -s看连接数。这几个命令组合起来，大部分问题五分钟内能定位方向。有一次数据库响应变慢，应用层监控一切正常，我上去跑了个iostat -x 1，发现%util干到98%，磁盘队列排了几百个请求。问题不在数据库本身，是同一块物理盘上还有个日志服务在疯狂写。

这些工具不需要装任何东西，不需要配agent，不需要开端口。它们的输出直接、原始，没有中间商赚差价。

Prometheus好用，但别神化它

我现在的主力方案是Prometheus + node_exporter + Grafana。这套组合确实香，尤其是做趋势分析和容量规划的时候。但它有个坑：很多人装完之后就只盯着那几个默认面板看，CPU、内存、磁盘、网络，翻来覆去就这些。

node_exporter暴露了几百个指标，真正有用的可能就二三十个。比如node_filesystem_avail_bytes比node_filesystem_free_bytes更值得关注，因为前者扣掉了root保留空间。再比如node_load1要结合CPU核数看，8核机器负载到6和2核机器负载到6完全是两码事。

还有告警。我见过太多人把告警阈值设得死死的，CPU超过80%就发邮件。结果业务高峰期天天报警，后来大家直接把邮件规则扔进垃圾箱。告警疲劳比没有告警更可怕。我现在用的策略是：磁盘使用率超过85%才报，内存可用低于10%才报，负载超过核数乘以1.5持续五分钟才报。每条告警都问自己一句：收到之后我会做什么？如果答案是“再看看”，那这条告警就不该存在。

日志也是监控

指标告诉你“发生了什么”，日志告诉你“为什么”。很多人把这两件事割裂开，指标归Prometheus，日志归ELK，互不相干。实际上它们应该联动。

我的做法是在Grafana面板上放一个日志查询的链接，看到异常指标直接点过去查对应时间段的日志。有一次磁盘IO飙升，指标上只能看到%util爆了，点进日志发现是某个定时任务在批量压缩旧文件。这种信息，光看指标永远猜不到。

说到底，Linux监控容易不容易，取决于你对自己的系统了解多少。工具只是工具，top也好，Prometheus也好，它们不会替你思考。你得知道你的机器平时长什么样，什么算正常，什么算异常。这个基线，才是监控真正的起点。