响应时间监控

为什么响应时间值得单独设置告警

标准的在线监控告警依赖于二元信号：在线或离线。介于两者之间的灰色地带——在线但很慢——其实是现代大多数故障的所在。配置错误的数据库查询从50毫秒变成了4秒。内存泄漏导致垃圾回收跳变。后端请求的外部API开始不稳定。这些问题都不会让页面完全宕机，但却让其无法使用——而且通常是重大故障提前一两小时的预警信号。

响应时间监控可以在真正故障之前捕捉到变慢的趋势。你可以为每个监控配置一个阈值，只要响应时间在连续几次检查中超过阈值，就会收到告警。在告警发出前，你还有缓冲时间来调查问题、扩容、限制有问题的调用或回滚引发问题的部署。

DiagnoSEO Uptime Monitoring 中阈值是如何工作的

每个监控都可以配置两个参数：rt_threshold_ms 和 rt_threshold_breaches。第一个表示你认为可接受的响应时间（毫秒）。第二个是需要连续多少次超出阈值才会触发告警。默认阈值为关闭，连续次数为三次。

双参数设计可以防止误报。网络抖动时有发生。GC暂停偶尔就有。一次响应从200ms跳到1秒没必要半夜三点叫醒你。但三次连续1秒就不同了——那是持续慢下来的表现，而不是偶发。阈值可以根据实际情况和预留空间来定：例如正常p95为400ms，阈值可设1000ms；如果p95为50ms（内部API），阈值定200ms。

与哪些监控信号结合效果更佳

响应时间告警与其他监控信号结合时效果最佳。观察全局：响应时间阈值告警能提示系统正在退化；HTTP状态码告警表明系统确实崩了；SSL/域名告警反映由时间驱动的故障；DNS变更告警发现配置漂移。将四种信号结合在同一监控中，让原本二元的“是否可用”变为全视角可观测性。

仪表盘也会提供帮助。每个监控都显示最新响应时间的小型趋势图——快速直观地反映降级趋势。展开视图还展示最近24小时、7天和30天的平均响应时间。如果发现平均值一周比一周慢，这是触发阈值前值得警觉的早期信号。

不同页面类型的常用阈值建议

• 营销落地页：1500ms较为合理。因图片与追踪脚本较多，极致速度不如稳定性重要。
• 电商产品/分类页：800-1200ms。电商站点一慢就降低转化，较严格阈值有助更快发现问题。
• 应用仪表盘：500-800ms。用户期望操作灵敏，慢的仪表盘让产品看起来有问题。
• 公共API：简单接口建议200-400ms，更复杂计算可适当放宽。灵活分层。
• 内部微服务健康检测：50-100ms。应该接近实时，变慢几乎一定预示着真正的故障。

无论如何设定，别“一劳永逸”。要根据实际趋势每季度重新评估。如果你总是收到无意义的超阈值告警，阈值设低了。如果先发生故障再收到告警，说明阈值太宽。

告警推送通道

阈值超限告警会通过与宕机/恢复告警相同的渠道发送：邮件、Telegram、Slack、Discord、短信，并遵守相同的夜间静默设置，同时记录于同一告警日志表。唯一的区别是事件类型（“threshold”而非“down”），以及告警内容会直接说明当前响应时间和设置的阈值，让你一眼看出差距有多大。

配置方法

编辑任一监控。在表单中将“响应时间阈值（毫秒）”设为你想要的数值。如有需要，可调整“连续超出次数”以适配你的容忍度（默认是3）。保存后，从下一个监控周期起，每次检查都会将响应时间与阈值比对，连续超限后就会收到通知。

常见问题

• 记录的是哪类响应时间指标？

  首字节时间（TTFB）——即从发出请求到收到服务器首字节的毫秒数。还包括完整响应完成的总用时。TTFB 是衡量服务器健康状况最有用的单个指标。

• 什么样的响应时间算“好”？

  取决于地域和内容。静态页面+CDN：100ms以内极佳，300ms以内可以接受。动态应用：500ms以内尚可，1000ms以内可接受，2000ms以上就偏慢了。建议参考自己历史数据而非固定数值。

• 响应时间超出阈值时会收到告警吗？

  会。每个监控都能选配响应时间阈值。连续3次检查超过阈值，你会收到“慢响应”告警。3次判定机制可以防止偶发网络故障触发误报。

• 响应时间是从哪里测量的？

  我们分布于全球（欧洲、北美、亚洲、南美、大洋洲）的13个检测节点。如是单地域监控，则选取离目标最近的节点。多地域监控则每个地区独立统计——适合检测CDN的区域性异常。

• 仪表盘会显示响应时间趋势吗？

  会——含30天移动平均、每日最大/最小及分位值（p50、p95）。便于容量规划：比如p95在一个月内从800ms升至1500ms，即使上线率保持100%，服务器已明显过载。