网站打不开，用户投诉电话打进来，运维才发现服务器已经宕机十几分钟。中小团队这种情况很常见，问题不在于故障本身，而是没人第一时间收到告警。宕机监控解决的就是这个信息差，系统在故障发生立刻推送提醒，而不是等用户反馈问题。
监控的逻辑并不复杂。判断服务器或者网站是否正常，最简单方式就是外部发起访问。每隔几十秒发送HTTP请求，校验返回状态码是否为200，响应时长是否超出阈值，页面内容有没有错误关键词。连续多次检测失败，判定服务宕机，触发告警。这套逻辑几十行代码就能实现，但做好监控重点在细节。
探测间隔和失败判定次数搭配很关键。探测频率太高会增加服务器负担，间隔太久无法捕捉短时故障。生产环境普遍一分钟探测一次，连续两次失败触发告警，属于比较均衡的方案。偶发网络抖动、瞬时502不会误报宕机，持续故障两三分钟内可以识别。核心业务可以缩短到三十秒一次，但要保证监控节点网络稳定，不然监控自身网络波动会产生大量无效告警。
告警通知方式是容易踩坑的地方。很多人一开始只配置邮件告警，服务器半夜宕机，邮件留在收件箱无人查看，等到上班才发现故障。推荐分级通知：普通可用性波动推送邮件或者工作群消息，严重宕机触发电话或者短信通知。电话告警触达能力强，不管运维人员休息或者开会都能收到提醒。缺点是电话告警服务一般需要付费，告警规则配置不当，频繁电话提醒会让人麻木，真正故障发生时忽略告警。故障分级要提前规划，不同级别故障匹配对应的通知渠道。
工具选型，不同规模团队适配方案不一样。个人站长或者只有一两台服务器的小团队，Uptime Kuma是省事选择。开源程序，部署在1核1G的VPS就能运行，资源占用很低，一台小型服务器监控几十个目标完全没问题。部署简单，Docker一条命令启动，Web界面直观，添加监控项目只需要填写URL、设置检测间隔。内置九十多种通知渠道，钉钉、飞书、企业微信、Telegram、邮件都支持，配置简单。自带状态页功能，可以生成公开页面展示全部监控目标实时状态，交付客户或是内部查看都合适。
使用云服务器，不想自己维护监控程序，可以选择UptimeRobot这类SaaS服务。免费版本支持50个监控目标，五分钟检测一次，个人项目够用。付费版本月费十几美元，检测间隔缩短至一分钟，支持短信、电话告警。SaaS优势是不用维护监控程序高可用，缺点是数据托管在第三方，监控节点大多在海外，探测国内服务器响应时间会受跨境网络影响。
规模稍大团队，十几台服务器，同时运行Web、数据库、缓存等多个服务，Prometheus搭配Grafana、Alertmanager这套组合更合适。Prometheus采集各项指标，Grafana做可视化图表，Alertmanager负责告警分组、抑制、路由。灵活性远高于前面两种方案，可以自定义告警规则，例如磁盘使用率持续五分钟超过90%触发警告，服务器up指标为0超过一分钟触发严重告警。缺点配置难度更高，理解Prometheus标签体系、PromQL查询语法、Alertmanager路由规则需要投入学习时间。
容易忽略一点：监控系统自身也要保障高可用。监控程序和被监控站点部署在同一台机器，服务器宕机时监控同步失效，告警无法发出。Prometheus主控和Alertmanager部署在独立服务器，和业务节点隔离。自托管Uptime Kuma同理，不要和被监控网站放在同一台VPS，否则VPS故障，网站和监控同时离线，无法收到告警。
自动恢复功能值得投入时间搭建。监控识别故障之后，告警同时执行自动恢复操作，很多小故障不用人工介入。最简单方案是编写脚本，服务器每分钟检测核心服务进程，进程消失自动重启。方法简单，但处理Nginx、PHP-FPM、MySQL进程意外退出效果很好。进阶方案借助Alertmanager的webhook，触发告警调用自动化脚本，SSH远程重启服务或者服务器。自动恢复需要设置边界，重启服务可以自动执行，重启数据库、清理磁盘这类高风险操作建议人工确认，脚本误操作损坏数据，后果比宕机更严重。
成本层面，自托管监控主要花费是一台小型VPS。1核1G机器每月二三十元，跑Uptime Kuma监控几十个目标足够。SaaS服务免费版有功能、探测频率限制，付费版月费十几到几十美元。Prometheus整套软件免费，但需要独立服务器，还要人力配置维护，隐性成本在人力。刚开始搭建监控的团队，从Uptime Kuma起步性价比最高，后续需求变复杂，再迁移到Prometheus。