站点宕机告警

控制面板中的图表能显示机器状态，但无法回答“网站是否在线？”这个问题。应用可能在 CPU 空闲时卡死，如果没有外部检查，您只能从客户那里得知故障。

外部检查

主要原则：不要从您所监控的机器上进行检查。使用任何外部 uptime 监控服务——这类服务很多，其中不乏免费方案，支持多个地址、一分钟间隔。真正重要的设置：

• 检查地址。 不要用首页，而要用像 /healthz 这样的独立路由，同时检查数据库和队列。否则，即使后端已经死掉，缓存过的首页仍会被返回。
• 预期响应。 200 状态码加上响应体中的某个子串。很多应用在崩溃时仍会返回 200 并附带错误信息。
• 阈值。 连续两三次失败才告警，否则任何网络抖动都会把您吵醒。
• 通知渠道。 Telegram 或电子邮件。确保告警确实能送达：停掉服务一分钟，等待消息到来。

别忘了单独检查证书有效期——TLS 证书过期看起来就像服务中断，而且这种情况经常发生。

机器自身的看门狗

外部监控会告诉您网站挂了。要让它自行恢复，请配置 systemd。在服务单元中：

[Service]
Restart=always
RestartSec=5
StartLimitBurst=5
StartLimitIntervalSec=120

这样服务能扛住意外崩溃，但如果配置有误也不会无限重启。修改后执行：systemctl daemon-reload && systemctl restart myapp。

对于不崩溃但会卡死的应用，再加一个 HTTP 检查。一对单元——一个定时器和一个服务：

cat >/etc/systemd/system/healthcheck.service <<'EOF'
[Service]
Type=oneshot
ExecStart=/usr/local/bin/healthcheck.sh
EOF

cat >/etc/systemd/system/healthcheck.timer <<'EOF'
[Timer]
OnUnitActiveSec=60
[Install]
WantedBy=timers.target
EOF

systemctl enable --now healthcheck.timer

脚本本身：

#!/bin/sh
curl -fsS --max-time 10 http://127.0.0.1:8080/healthz >/dev/null || systemctl restart myapp

机器健康告警

在服务中断之前提前得知磁盘空间和内存耗尽也很有用。最简单的方案是一个 cron 任务，在超过阈值时发送 Telegram 消息：

0 * * * * root [ "$(df --output=pcent / | tr -dc 0-9)" -gt 85 ] && curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT -d text="VDS disk usage is over 85%"

更高级的方案带有现成的阈值，由 Netdata 提供。

常见错误

• 在同一台机器上监控。 如果机器宕机，看门狗和告警也会一起死掉。
• 阈值过于敏感。 一连串误报意味着您会直接划过真正的那条告警。
• 用 Restart=always 代替排查原因。 重启会掩盖内存泄漏：服务每半小时崩溃一次，而您却看不到。检查 systemctl show myapp -p NRestarts 和 journal。
• 只用 ping 检查。 即使 Web 服务器完全死掉，机器仍会响应 ICMP。

告警触发时，首先要查看控制面板 /hosting/vds/m/<id> 中的“Overview”。图表出现断点说明机器有问题；网站不可用而图表平坦，说明问题出在应用上。