最低要求
- 服务挂了 → 5 分钟内你能收到通知
- 不要等用户/老板 pin 你才知道
健康检查端点
服务里加个 /health 路由：
# FastAPI
@app.get("/health")
def health():
return {"ok": True, "version": "0.1.0"}
// Express
app.get("/health", (req, res) => res.json({ ok: true }));
进阶：检查依赖（数据库、Redis）：
@app.get("/health")
async def health():
try:
await db.execute("SELECT 1")
return {"ok": True}
except Exception as e:
return JSONResponse({"ok": False, "error": str(e)}, status_code=503)
外部探测：UptimeRobot
最简单的免费方案：
- uptimerobot.com 注册（免费 50 个监控）
- Add New Monitor → HTTP(s) → 填
https://wadely.com/health - 间隔 5 分钟（免费档最快）
- 通知方式：Email / Slack / Webhook / 微信（部分支持）
宕机即收通知。
Better Stack（更现代）
UptimeRobot 的进化版，1 分钟探测、状态页、On-call 排班：
- 免费 10 个监控
- 自动生成公开状态页（
status.wadely.com） - 集成 PagerDuty / Slack / 短信
健康检查的常见坑
坑 1：检查太轻
@app.get("/health")
def health(): return "ok"
服务进程在但数据库挂了——这种检查会漏报。要检查关键依赖。
坑 2：检查太重
跑完整 SQL 查询、调外部 API——监控本身把服务打挂。检查要快、要轻。
坑 3：探测频率太高
1 秒一次 → 一天 86400 次，对小服务是负担。1–5 分钟一次够用。
服务器层面：CPU / 内存 / 磁盘
/health 只看应用层。服务器资源用 Node Exporter + Prometheus（公司运维系列详细讲），小项目用云商自带的：
- 阿里云、腾讯云控制台都有基础监控
- DigitalOcean: 装 Agent 后一键开
- 不想接复杂系统：Glances 终端面板
应用层日志告警
错误日志的 ERROR 级别条数突然上升 → 往往比挂掉先发生。 方案：
- 应用平台（Railway/Render）UI 里看错误日志
- VPS：把
journalctl -u myapp -p err出现就发通知 - 进阶：Sentry（免费档够用，专门收错误）
业务指标监控
技术上没挂 ≠ 业务正常。
举例：注册流程坏了，技术监控全绿，但 24 小时 0 注册——这种要靠业务监控：
- 简单做法：每天定时查 SQL，新增数据 < 阈值就发 Slack
- 中型做法：埋点到 PostHog / Mixpanel，看异常下降
下一篇：最后一片拼图——push 即部署。