监控别等出事才想起：我给 11 台云主机做每日巡检的实践

我手里现在有 11 台云主机，有跑博客和个人项目的，也有给朋友搭的小服务，还有两台专门做测试。以前我的做法很典型：不出事就不看，出了事才去翻日志。结果有一次，一台跑定时任务的机器磁盘被日志写满，任务静默失败了三天我才发现；还有一次，一台机器的容器半夜退出了，第二天用户来问我才知道。那之后我就给自己定了一条规矩：每天早上花十分钟，做一次只读巡检，不修、不改配置，只看状态，把变化记下来。

为什么是每日巡检，而不是全靠告警：云监控当然要开，但阈值设得太灵会吵人，设得太松又会漏事。我的体会是，监控适合兜底，巡检适合建立基线。每天看一眼，你才知道什么是这台机器的正常样子：哪台平时内存就用到七成，哪台磁盘每周涨两个点，哪台容器数本来就该是四个。没有这个基线，告警一来你还是要从头排查。巡检的另一个好处是便宜：不用上很重的 Agent，也不用改业务代码，一台跳板机加一个只读账号就能跑。

巡检清单：只查五项，全部只读。我的清单刻意很短，每台机器只查五项：第一，连通性，用 ping 和 SSH 连通测试确认机器还活着；第二，登录与系统负载，看 uptime 和最近有没有异常重启；第三，磁盘，看根分区和数据盘的使用率和增长趋势；第四，内存和 Swap，看有没有持续吃满或者开始用 Swap；第五，容器数和关键容器状态，看该在的容器是不是都在。只读是原则，我用的巡检账号只有查看权限，不能写文件、不能重启服务、不能改配置，这样即使脚本写错了，也不会把线上搞坏，巡检脚本本身也加了超时，单台超时就记为异常跳过，不让一台挂掉的机器拖住后面十台。

常用的命令就是这几条：ping -c 2 主机地址；ssh -o ConnectTimeout=5 只读账号@主机地址 uptime；df -h；free -m；docker ps。先跑通单台，再用一个主机清单循环跑 11 台，结果统一汇总到一张表里，表头就是日期、主机、连通、负载、磁盘、内存、容器数，异常行标红，正常行不用细看。

只在状态变化时告警：最开始我犯过一个错，每天把 11 台机器的完整结果都发出来，没过一周我就自己都不看了。后来改成只在状态变化时告警：连通从通变不通、容器数变了、磁盘跨过阈值、内存从正常变成持续高压，这些才发消息；没变化的只写一行汇总，比如 11 台正常，磁盘最高 68%。判断变化的办法很土但管用：每天把每台机器的关键结果写进一个状态文件，第二天巡检时先跟昨天对比，新增、消失、跨阈值才算变化。磁盘我不只看绝对值，还看增量，如果一台机器三天涨了 15%，哪怕现在只有 60%，我也会提前去看是哪个目录在涨，多数时候是日志没轮转，或者备份文件没清理。

磁盘阈值我是这样定的：70% 提醒，85% 预警，90% 当天处理。70% 只是让我记一笔，顺手看看增长速度；85% 就要进机器确认，到底是数据正常增长还是日志失控；90% 不管多忙当天都要处理，清理、扩容或者迁移，总之不能留到第二天。最容易被忽略的是日志目录和 Docker 数据目录，我吃过亏，后来巡检里单独看了 var/log 和 Docker 数据目录的占用。

几点心得：清单越短越能坚持，五项查完十分钟，二十项就坚持不了一个月；只读和超时是底线，巡检不能变成新的故障源；变化比绝对值重要，趋势比单点重要。巡检不是监控的替代品，严重故障还是要靠监控和告警兜底，巡检是让你对自己的机器有手感。如果你也管着几台到十几台机器，不用一开始就搭很复杂的平台，先列一张清单，写一个简单的循环脚本，每天早上跑一次，把结果存下来、只在变化时提醒自己。