凌晨两点，手机把我震醒。监控面板上那条红色的“站点不可达”挂着，我第一反应是服务器挂了，翻身爬起来开电脑登录、ping 一下、curl 一下全都正常。网站好好的，一个访客都没少掉，但告警确实响了。这一夜我被吵醒四次，最后一次是凌晨五点。这次之后我花了整整两天，把探活这条链路从脚本到通知渠道整个拆开看了一遍，才发现问题根本不在服务器上，而在我自己搭的这套监控里。下面这三个点，是我踩过的坑，也是我改完之后再没被误报吵醒的原因。
如果你也在给海外站点做探活告警，下面这些服务器本身就是被监控的对象，也可以先看看这几家的报价和技术说明：isvoro（全球云服务器），香港、美国、德国、英国等多地区节点，适合把探活探针分散到不同地区。
第一个坑：探针自己所在的网络在抖，服务器却是好的
我最早是把探活脚本放在自己的一台海外 VPS 上跑的，脚本逻辑很朴素：curl 一个固定的 URL，返回码不是 200 就判定失败。问题出在这个“固定”上。我这台探针机在洛杉矶，走的是一条当时还不错的线路，但那条链路在美西晚高峰会抖 200 到 400 毫秒，偶尔丢包。我把超时设成了 3 秒，于是每天晚上八点到十点，探针就开始隔三差五超时。
而被监控的业务服务器本身在法兰克福，一点毛病没有。这就是典型的探活误报：告警反映的是探针的处境，不是被监控对象的处境。我后来的做法是把超时从 3 秒放宽到 8 秒，同时在探针侧加了一个“连续失败 3 次才判定失败”的计数，而不是一次超时就报。改完之后，那条线路晚高峰照样抖，但告警再没响过。
更稳一点的做法是多地探针：同一个站点从至少两个不同地区的节点去探，只要有一个节点成功就不算失败，这样单条链路的抖动就被过滤掉了。这里牵涉到一个现实问题如果你想让探针覆盖欧洲、美洲、亚洲，就得多准备几台分布在不同地区的机器，用一台机器硬扛全球链路，误报率一定压不下来。
第二个坑：探活路径和真实用户路径不是同一条
这个坑更隐蔽。我有一次告警说首页打不开，我手动访问发现首页好好的，只是慢。我顺着往下查，发现探活脚本请求的是 /healthz 这个内部健康检查接口，而这个接口挂在一套独立的服务上，平时正常，但它所在的那台机器当晚会做定时任务，占满了 CPU，响应时间从 5 毫秒涨到了 2 秒多虽然还在超时以内，但响应体里某个字段超时了，脚本判失败。
所以我现在的规则是：探活只探一个真正代表用户体验的路径，比如首页的 HTML，或者一个需要登录才能拿到的动态接口，而不是随便找个内部接口糊弄。而且探针要真的把响应体读下来，光看状态码不够有些反代在故障时会返回 200 但塞一个错误页，脚本不检查就当正常了。
另外还有一个细节：探活请求必须带一个真实的 User-Agent，别用 curl 默认的。有一回我看到监控面板上全是 403，才想起来探针没带 UA，被站点的 WAF 拦了，误报了一整天。
第三个坑：告警通知渠道本身不可靠，还互相重复
前两个坑修完，误报少了很多，但只要漏一次我还是会被吵醒，所以接着折腾通知渠道。我对比过好几种方案，说点实在的：
邮件通知最便宜也最不打扰，适合放“每天一次汇总”或者低优先级的告警，唯一的问题是手机邮件客户端不一定实时推送，夜间基本等于没有。
IM 群通知（比如各种机器人群机器人）实时性最好，成本也低，适合第一时间知道“出事了”。但群消息有个致命缺点它不做去重，一次故障连续探活失败三次，就是三条一模一样的消息刷屏。我现在的做法是告警侧加一个“抑制窗口”，同一台主机 10 分钟内的重复告警只推第一条。
电话/短信通知贵，但它是唯一能真把人从床上叫起来的渠道，适合只挂在“影响收入”的核心业务上。我的建议是分级：P1 用电话或者短信，P2 用 IM 群，P3 直接进邮件日报。一股脑全走 IM 群的结果就是群消息变多，人反而麻木了。
还有一个容易被忽略的点：监控本身也会挂。我有过一次探针脚本因为依赖的 Python 环境被升级搞崩了，脚本进程直接没了，监控面板一片安静这叫“静默失败”，比误报危险得多。后来我在监控服务器上加了一条“看门狗”定时任务，每 5 分钟检查一次探针进程还在不在，如果进程不在，就直接用另一条独立通道（比如最土的邮件）告诉运维。这个冗余在真正出事那一次救了我。
我现在的探活配置，改完就没再半夜被吵醒
把上面三条合起来，我现在的配置大概是这样，抄给同样在做海外站点监控和告警阈值调优的人参考：
第一，探针至少两个不同地区，单节点失败不算失败，全部节点失败才算真故障。
第二，超时 8 秒，连续失败 3 次才触发，一次网络抖动直接过滤掉。
第三，探活路径只保留一条，且必须校验响应体内容，不能只看状态码，UA 也要带。
第四，告警分级：P1 电话加短信，P2 群机器人加抑制窗口，P3 进邮件日报。
第五，看门狗冗余，探针进程没了也要有人知道。
这套东西前前后后调了三天，改完之后到现在两个月没有一条误报告警，也没有漏过一次真故障。回头看，探活误报这件事根本不是服务器的问题，是监控这条链路上的每一段都可能出问题：探针的网络、探活的路径、通知的渠道、监控的自监控。你把每一段都当成可能失败的环节去设计，误报自然就少了。
顺便说一句，如果你打算给探针配几台分布在不同地区的机器，上面提到的kdatacenter（全球云服务器）这类多机房服务商可以先了解一下节点分布，探针的地域覆盖越均匀，误报过滤效果越好。
喜欢 
顶
难过
囧
围观
无聊
