为什么需要监控
问一个简单的问题：你的网站现在在线吗？大多数人答得上来。再问一个：过去 24 小时里有多少次请求耗时超过 3 秒？大多数人答不上来。监控的意义不是证明"一切正常"，而是发现那些你原本不知道的问题——深夜的一次磁盘写满、凌晨三点的回源超时，往往都是先于用户感知暴露在监控曲线里的。
AI 提示词模板
请帮我制定网站监控方案。
- 网站 URL：[网址] | 服务器：[VPS/独立/云服务]
- 技术栈：[PHP/Node.js/Python]
- 报警方式：[邮件/微信/Telegram/Slack]
输出：监控工具推荐、监控指标、报警阈值、通知配置、故障处理流程。
三个不可妥协的指标
可用性
最基础的指标：网站是否返回 200。建议每 1-5 分钟从外部发起一次 HTTP 探测并检查响应码，连续 3 次失败即触发告警。注意一定要用"外部"探测——服务器本机自测会绕过机房网络、DNS 和公网链路，无法发现真实用户的可达性问题。
响应时间
用户感知到的性能就是响应时间。相比平均值，更该关注 P95（95 分位）：平均值会被少量极快请求拉低，而 P95 反映的是大多数用户实际体验。
| 页面类型 | P95 阈值 |
|---|---|
| 静态页面 | < 800ms |
| 动态页面 | < 2s |
| API | < 500ms |
错误率
HTTP 5xx 不可能降到零，但持续高于 0.5% 就该查了。错误率从 0.1% 跳到 5%，要么是服务端配置问题，要么是上游故障，无论哪种都要立刻排查。
告警设计原则
告警的目标不是"处理每一条告警"，而是"让重要的告警不被淹没"。
分级
P0（立即处理，5 分钟内响应）：
站点完全不可用超过 5 分钟
P1（紧急，30 分钟内响应）：
P95 响应时间连续 15 分钟超过 3s
错误率连续 10 分钟超过 2%
P2（工作时间内处理）：
SSL 证书 剩余有效期不足 30 天
磁盘使用率超过 85%
告警频率
同一条告警不要反复推送。问题持续存在时，做到"发一次、确认一次、升级一次"。想象凌晨 3 点被一条误报叫醒，连续两次之后你就会对告警麻木——告警疲劳比没有告警更危险。
工具选型对比
| 工具 | 类型 | 免费限制 | 适用场景 |
|---|---|---|---|
| Uptime Kuma | 自建开源 | 无限制 | 中小站点可用性与 SSL 检测 |
| Better Uptime | SaaS | 10 个监控 | 需要 on-call 轮班的团队 |
| Grafana + Prometheus | 自建开源 | 无限制 | 基础设施性能指标 |
| Checkly | SaaS | 免费版有限 | API 与浏览器端到端监控 |
中小站点建议先用 Uptime Kuma + Grafana 起步，不要第一天就上完整 ELK。更细的实践可参考 站点监控报警设置指南 与 Prometheus + Grafana 基础监控。
Uptime Kuma 部署
单容器最简方式：
docker run -d --name uptime-kuma --restart=always -p 3001:3001 louislam/uptime-kuma:latest
生产环境建议用 docker-compose 并挂载数据目录，避免容器重建丢失监控配置：
version: '3'
services:
uptime-kuma:
image: louislam/uptime-kuma:latest
ports: ["3001:3001"]
volumes: ["./data:/app/data"]
restart: always
完整部署与配置细节见 Uptime Kuma 部署教程。
告警通知渠道与升级
| 渠道 | 优先级 | 适用场景 |
|---|---|---|
| 邮件 | 基础 | 全员周报、低优先级汇总 |
| Telegram/Slack/企业微信 | 实时 | 值班人员的即时告警 |
| 短信 | 高 | 严重故障兜底 |
| 电话 | P0 | 站点完全宕机 |
建议配置升级策略：首次告警发到即时渠道，15 分钟无人响应升级短信，30 分钟仍未响应直接电话。同时给维护窗口和夜间静默配置留出开关，避免例行维护被当成故障。
一个真实场景
某电商站用 Uptime Kuma 做了 5 分钟粒度的可用性探测，某天深夜收到"连续 3 次探测失败"的告警。值班人员打开 Grafana 看到 CPU 并没有异常，反而是磁盘使用率在 22:00 后从 60% 一路冲到 96%——日志文件把数据盘写满了。因为告警链路清晰（可用性 → 磁盘指标 → 定位根因），站点在 40 分钟内恢复了。如果没有监控，这个问题大概率要等第二天早上用户反映"网站打不开"才会被发现。
告警降噪清单
告警越精准，值班的人越愿意看。落地时对照这份清单自查：
- 每条告警都要有明确的动作（看什么、修什么、找谁）；
- 相同问题 24 小时内不重复推送，只更新状态；
- 夜间只放 P0/P1，P2 留到工作时间；
- 每个季度清理一次不再需要的旧规则。
配合 告警疲劳与值班实践 一起用，能把告警从"负担"变成"情报"。
常见问题
自建 Uptime Kuma 和 SaaS 监控怎么选？ 只监控几个关键站点、有人能维护服务器，自建足够；团队需要 on-call、短信电话这类增值能力，或不想自己运维监控服务本身，选 SaaS 更省心。
监控指标是不是越多越好？ 不是。指标太多等于没有指标，关键是把可用性、响应时间和错误率这三条主线盯住，再按业务补一两个核心指标。
为什么强调"外部探测"？ 本机自测绕过了机房网络、DNS 和公网链路，探测结果会"过分乐观"，无法代表真实用户的可达性。
参考：Uptime Kuma 官方文档 — https://github.com/louislam/uptime-kuma ；Prometheus 官方文档 — https://prometheus.io/docs/introduction/overview/