网站上线那天，大概是它这辈子被盯得最紧的一天。你会一遍遍刷新首页，看它是不是秒开，顺手把状态码、加载时间、各个接口都点一遍。过了一周，这些动作基本就停了，再往后就是偶尔想起来才打开看一眼。而绝大多数故障，恰恰发生在没人看的那些日子里：半夜磁盘写满，凌晨证书过期，周末被爬虫刷到带宽跑满，人却在睡觉。等第二天发现，用户已经替你验收过好几个小时了。而你回头看日志时，往往连问题是从哪一刻开始的都分辨不清。
所以监控要解决的第一件事不是技术，而是替代那双不可能一直睁着的眼睛。常见做法是装一个能定时探测的服务，让它每分钟去访问一次你的站点，只要没在预期时间内返回预期结果，就通过邮件、短信、即时通讯把你叫起来。听起来简单，真正把它做扎实的站点并不多，问题普遍出在只做了最外面那一层，剩下的盲区一直留着。真正的问题从来不是没装监控，而是装了之后以为万事大吉。
监控要分三层，少一层就留一块盲区
最外面一层是从公网探测：站在外面访问你的域名，看通不通、响应多快、返回内容对不对。这一层最直观，也最接近用户的真实感受。第二层是主机指标：CPU、内存、磁盘、网络。它回答的是机器本身还好吗。第三层是应用日志和关键业务指标：订单有没有进来、队列有没有堆积、定时任务昨晚跑没跑完。三层各管一段，公网探测看不到磁盘涨满，主机指标也解释不了后端接口为什么变慢，只盯着其中一层，故障往往就从被你忽略的那两层冒出来。
工具层面，自建的话Uptime Kuma是个被大量使用的选择。按它的官方项目说明，能监控的种类相当全：HTTP(s)、TCP端口、HTTP关键字、JSON查询、Ping、DNS记录、推送心跳、Steam游戏服务器，甚至Docker容器。最短检查间隔可以压到20秒，通知渠道覆盖Telegram、Discord、Slack、邮件在内的90多种服务，还能做多个状态页并绑定到自己的域名。它是MIT许可的开源项目，可以完全自己托管。官方文档里有一条容易被忽略的提醒：它不支持把数据目录挂到NFS这类网络文件系统上，得映射到本地目录或卷。
这里有个几乎每个人都会踩的坑：你把监控装在要监控的那台服务器上。平时没问题，一旦那台机器整体失联，机房网络断了、系统盘挂了、被大流量攻击打死了，监控服务和被监控的服务一起消失，你手里一个告警都收不到。相对稳妥的做法是把两者分开，用一台便宜的独立小机器专门跑探测，它只负责从外面敲门，出事的时候它是唯一还站在门外的那个。
第二个常见问题是告警发出去没人看。邮件最容易出现这种情况：它安静地躺在收件箱里，和几百封推广邮件混在一起，等你想起来翻，故障已经过去半天。真出过一次事之后，多数人会把关键节点换成能立刻震动的渠道，比如即时通讯群里的机器人，或者直接打电话发短信的服务。通知渠道的选择标准其实很朴素：不是看它支不支持，而是故障发生的那一刻，这条消息能不能在你睡着的时候把你叫起来。
监控本身只负责发现，发现之后谁来看、看什么、按什么顺序处理，是另一件事。很多小团队的状态是：告警确实响了，但没有人说得清第一件事该做什么，于是宝贵的时间花在翻文档和互相问上。一个成本很低的办法是把最常见的几种故障写成一张纸，网站打不开先看哪、磁盘满先删哪、证书过期去哪续，贴在值班的人顺手能看到的地方。故障当下的判断力是最稀缺的资源，能提前想清楚的部分就该提前写下来。
第三个问题更隐蔽，是只监控通不通，不监控趋势。一个站点从健康到崩溃，中间通常有一段很长的斜坡：磁盘从三成涨到八成用了三个月，内存曲线每个月底都比上个月高一点，SSL证书到期日一天天逼近，响应时间从两百毫秒慢慢爬到八百毫秒。这些变化在单次的是否在线判断里完全看不出来，它们只出现在曲线上。盯着趋势，你拿到的是提前几周的预警；只盯着状态灯，你拿到的是事后通知，差别就在这里。预警和通报之间，隔着的正是你还能挽回多少。这一层差别，决定了你是在用户投诉前动手，还是在通报后道歉。
监控这件事，做到最后会发现工具是次要的，真正缺的是几双站在外面的眼睛和几条长期有人在看的曲线。分层是为了不留盲区，独立部署是为了自己别跟着一起倒下，叫得醒的渠道是为了消息真的送到，看趋势是为了别把预警做成事后的通报。把这四件事都补上，你不需要一个人守在电脑前，也不需要等到用户跑来告诉你网站挂了。
A5创业网 版权所有