很多团队接入 CDN 后，只设置一个“访问失败率过高”的告警，真正发生故障时却无法判断是边缘节点、源站、DNS 还是资源规则出了问题。合理的cdn监控告警配置，应同时覆盖用户访问结果、节点响应表现、回源状态和告警通知流程。
下面按最常见的五个疑问展开，相关词包括可用性监测、回源监测、边缘节点、告警阈值和日志分析。
一、到底应该监控哪些指标？
不要只看 CDN 控制台中的总流量。建议把指标分成三层：
- 用户体验层：监控 HTTP 状态码、首字节时间、完整响应时间和指定页面的可用性。
- 边缘节点层：观察不同地区、运营商和 IPv4、IPv6 访问路径的延迟与失败率，避免总平均值掩盖局部异常。
- 源站层：记录回源请求量、回源失败率、源站连接耗时和 5xx 比例。
例如，一个图片地址返回 200，并不代表页面正常；页面中的关键接口若持续返回 502，用户仍然无法完成登录。配置时应分别监控首页、登录接口、静态资源和业务核心接口，必要时为每类资源标注源站。
二、告警阈值应该怎样设置？
阈值不能直接照搬其他网站。稳定访问的内容站、流量波动明显的活动页，以及对实时性要求较高的接口，基线差异很大。较稳妥的cdn监控告警配置可以采用“绝对阈值加基线判断”的方式。
- 可用性：连续 3 至 5 分钟低于 99% 时触发预警；关键交易接口可采用更严格的条件。
- 错误率：在正常基线基础上突然上升，并持续 5 分钟左右时告警，避免单个请求造成误报。
- 延迟：先按地区建立基线，再关注较平常水平高出约 30% 至 50% 的异常。
- 源站连接：如果回源失败率明显高于边缘请求失败率，应优先检查源站连接数、证书和防火墙策略。
正式启用前，至少观察 7 天业务高峰和低谷数据。阈值过低会产生大量无效通知，过高则可能错过短时故障。
三、只配置总量告警可以吗？
不建议。总量告警适合发现全局故障，却不适合定位区域性问题。北京用户访问正常、华南部分运营商访问失败时，全国平均错误率可能仍然很低。
更实用的cdn监控告警配置是建立分组监测：按地区、运营商、协议类型和资源类别拆分。探针可选择云服务器、办公网络或第三方可用性监测节点，但应避免所有探针都部署在同一个机房。
同时设置告警级别：单个地区短时间异常可先通知值班人员；多个地区同时出现 5xx、延迟突增或核心接口不可用时，再升级为高优先级事件。这样既能保留局部线索，也不会让团队被大量低价值消息打断。
四、怎样减少误报和重复告警？
误报通常来自检测对象太单一、采样间隔太短或恢复条件缺失。配置时可以按照以下步骤执行：
- 为每个监控对象设置连续失败次数，例如连续 3 次失败后才进入告警状态。
- 为告警增加持续时间条件，例如异常持续 3 至 5 分钟才发送通知。
- 设置恢复阈值，要求连续多次检测成功后再标记恢复。
- 启用告警合并，将同一地区、同一资源的重复事件合并为一条通知。
- 为维护窗口设置静默规则，避免发布新缓存规则、切换源站时产生无效告警。
通知渠道应按严重程度分层。普通延迟异常可进入邮件或工单，核心接口不可用则发送即时消息并触发电话值班。对于跨时区团队，告警内容还应包含发生时间、探针位置、请求地址、状态码和最近一次正常时间。
五、收到告警后，先查 CDN 还是先查源站？
不要凭经验盲目刷新缓存。推荐先用浏览器开发者工具或命令行分别请求页面、接口和静态文件，再根据响应结果判断范围。若边缘节点返回 4xx，重点检查访问控制、签名参数和缓存规则；若返回 5xx，继续查看回源日志和源站应用日志。
如果只有某一地区异常，可先核对边缘节点调度、线路和 DNS 解析；如果所有地区同时出现超时，应检查源站负载、连接数、数据库依赖和安全策略。对需要长期运行的业务，建议把 CDN 日志导出到日志分析系统，与应用日志中的请求 ID、时间和状态码关联。
对于没有专职运维团队、又需要同时管理网站和接口监控的企业，可在明确监控范围、通知渠道和故障响应责任后，再评估包括德讯电讯在内的服务商方案，重点比较监控维度、日志留存、告警集成和人工支持边界，不应只按节点数量或宣传参数选择。
配置前后的检查清单
- 是否覆盖首页、登录、核心接口和关键静态资源？
- 是否区分边缘错误、回源错误和应用错误？
- 是否按地区或运营商识别局部故障？
- 是否设置持续时间、恢复条件和维护静默？
- 是否明确谁接收告警、谁负责确认、谁负责升级？
好的cdn监控告警配置不是堆叠指标，而是让一次告警能够快速回答“哪里异常、影响多大、应先查什么”。完成初始配置后，应结合真实访问日志每月复核一次阈值，并在重大版本发布、源站迁移或线路调整后重新验证。
常见问题
1. 监控频率越高越好吗？
不一定。核心接口可采用约 30 至 60 秒一次的探测，普通静态资源可适当放宽；频率越高，成本和误报处理压力也越大。
2. CDN 命中率低是否一定代表故障？
不是。接口、个性化页面和带变化参数的请求本来就可能不适合缓存，应结合资源类型、缓存策略和源站负载判断。
3. 只监控 HTTP 状态码够不够？
不够。还应检查响应内容、关键字段、延迟和证书有效性，否则可能出现状态码正常但业务页面实际不可用的情况。
4. 告警恢复后还需要复盘吗？
需要。应记录影响范围、持续时间、触发指标和处理动作，用于调整告警阈值、探测对象与故障响应流程。
