监控不是"装个工具就完事"
不少站点上线后第一件事就是装监控工具，但装了不一定等于"有监控"。真正有效的监控要回答三个问题：盯哪些指标、异常时怎么通知、通知了以后谁来处理。这一篇把这套配置串起来讲清楚，配合 Prometheus + Grafana 基础监控 和 监控报警总览 一起看，能覆盖从单机到多机的监控需求。
核心指标与阈值
| 指标 | 检查内容 | 告警阈值 | 检查频率 |
|---|---|---|---|
| 可用性 | 站点是否可访问 | 1 次检查失败 | 每 1-5 分钟 |
| 响应时间 | 服务器响应速度 | > 3 秒 | 每 5 分钟 |
| SSL 证书 | 距到期天数 | < 30 天 | 每天 |
| 磁盘使用率 | 剩余存储 | > 85% | 每 30 分钟 |
| 内存使用率 | RAM 占用 | > 90% | 每 30 分钟 |
| CPU 负载 | 处理器占用 | > 80% 持续 | 每 5 分钟 |
| 数据库 | 连接状态 | 连接失败 | 每 5 分钟 |
阈值不要照抄模板，要基于自己站点的基线调整。比如一个图片站磁盘涨得快，85% 的磁盘告警可能太晚，建议在 75% 就提醒。SSL 证书的自动签发与续期可参考 Let's Encrypt 证书配置，证书类型对比见 SSL 证书类型指南。
监控工具对比
| 工具 | 类型 | 价格 | 适合场景 |
|---|---|---|---|
| Uptime Kuma | 自建 | 免费 | 中小站点 |
| Better Uptime | SaaS | 免费 / $20 每月 | 有 on-call 的团队 |
| Checkly | SaaS | 免费 / $30 每月 | API 与浏览器监控 |
| Datadog | SaaS | $15/主机/月 | 企业级全栈 |
| Grafana + Prometheus | 自建 | 免费 | 进阶基础设施 |
| Netdata | 自建 | 免费 | 实时服务器指标 |
分层监控方案
小站点（免费）
可用性监控：Uptime Kuma（自建）
服务器指标：Netdata（一条命令安装）
SSL 检查：Uptime Kuma 内置
通知：Telegram / 邮件
中型站点（每月 $0-30）
可用性监控：Better Uptime 或 Checkly
服务器指标：Netdata 或基础 Prometheus
APM：Sentry（免费额度够用）
日志：简单轮转 + 手动检查
通知：Slack / Telegram / 邮件
企业级
可用性：Datadog / Pingdom
指标：Grafana + Prometheus
APM：Datadog APM / New Relic
日志：ELK Stack / Loki
通知：PagerDuty / Opsgenie
告警通知渠道
| 渠道 | 成本 | 紧急度 | 适合场景 |
|---|---|---|---|
| 邮件 | 免费 | 低 | 日报、汇总 |
| Telegram | 免费 | 中 | 实时告警、团队群 |
| Slack | 免费 | 中 | 团队协作 |
| Discord | 免费 | 中 | 开发者社区频道 |
| 短信 | 付费 | 高 | 关键问题 |
| 电话 | 付费 | 最高 | P0 级事故 |
低优先级的日报可以用 邮件自动化 定时推送，把告警噪音从即时通道里分流出去。
告警配置技巧
设置升级策略
首次告警 → Telegram/Slack（立即）
15 分钟无响应 → 短信
30 分钟无响应 → 电话
配置维护窗口
- 把例行维护时间从告警中排除；
- 非关键告警设置静默时段（如 22:00-8:00）。
避免告警疲劳
- 不要对每个小事件都告警；
- 用迟滞判断（如连续 3 次失败才告警）；
- 把相关告警分组合并。
告警信息模板
一条好告警要让值班的人不用打开页面就能判断优先级，建议包含：标题（是什么）、影响（影响谁、多严重）、证据（当前值 vs 阈值）、动作（先看哪条命令）。例如：磁盘使用率 92%（阈值 85%）- 主机 web-01 - 先执行 df -h 确认哪个挂载点。把模板写进规则，比事后补说明有效得多。
Uptime Kuma 通知设置
Uptime Kuma 原生支持 Telegram、Slack、Discord、邮件等多种通知渠道，也支持告警升级策略和静默时间配置。在监控项里勾选"启用通知"，绑定对应渠道的 Webhook 即可。详细部署见 Uptime Kuma 部署教程。
一个实战案例
某论坛站上线半年，一直没配数据库监控。某次凌晨数据库连接池被打满，首页 502 持续了 20 分钟，直到有用户去客服群反馈才被发现。事后补上了三件事：数据库连接状态 5 分钟一次探测、错误率持续 10 分钟超 2% 触发 P1 告警、Telegram 值班群 + 30 分钟未响应升级电话。之后同样的连接池问题再发生时，值班人员在 12 分钟内完成了重启与扩容。监控的价值不是"避免故障"，而是把故障的发现时间从"用户反馈"压缩到"分钟级"。
监控清单
- 可用性监控已配置（5 分钟间隔）
- SSL 证书 到期告警（< 30 天）
- 磁盘使用率告警（> 85%）
- 内存使用率告警（> 90%）
- 数据库 连接监控
- 通知渠道已配置（Telegram/Slack/邮件）
- 维护窗口已定义
- 告警升级策略已文档化
- 关键指标仪表盘已创建
- 故障响应预案已文档化
常见问题
告警阈值应该怎么定？ 先让监控跑一两周，观察正常基线，再把阈值设为基线的 1.2-1.5 倍；不要一上来就照搬网上的推荐值。
监控工具和监控项是不是越多越好？ 不是。工具堆得多、告警发得勤，值班的人很快就会麻木。先把关键链路盯住，再逐步补。
小站点需要全套 ELK 吗？ 不需要。日志能查到、磁盘能预警就够了，等日志量上来再考虑 ELK 平台 或 Loki。
参考：Uptime Kuma 通知文档 — https://github.com/louislam/uptime-kuma ；Checkly 文档 — https://checklyhq.com/docs/ ；Datadog 文档 — https://docs.datadoghq.com/