Nightingale CDN 探测集成指南Categraf 采集配置、指标语义与告警规则【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale本篇技术指南围绕 Nightingale 仓库中 integrations/CDN 集成目录展开讲解如何借助 Categraf 采集器对 CDN 加速域名进行主动探测输出 DNS 解析、TCP 建连、TLS 握手、首包响应等分阶段耗时指标并基于这些指标在 Nightingale 中配置可用性、状态码与性能告警。读完本文你将掌握 CDN 插件从配置文件编写、指标解读到告警规则导入的完整实战链路。Nightingale 本身不承担监控数据采集职责官方推荐搭配 Categraf。本文介绍的 CDN 插件正是 Categraf 生态中的一款主动探测型插件其配置模板位于 integrations/CDN/collect/cdn/cdn.toml。一、插件定位与工作原理CDN 插件的核心目标是从探测点主动发起 HTTP 请求把一次资源访问拆解为多个可量化的阶段从而回答三个运维问题链路是否可用—— 请求能否成功建立并拿到响应链路是否健康—— DNS、TCP、TLS、首包各阶段耗时是否在合理范围业务是否符合预期—— 返回的状态码与响应内容是否与期望一致。从指标命名上看该插件以cdn_为统一前缀输出全部指标如cdn_dns_request、cdn_total_cost与同仓库的 HTTP 探测插件http_response_系列指标见 integrations/HTTP_Response/metrics/categraf.json在语义与状态码设计上高度一致可视为面向 CDN 场景定制的探测探针。仓库内还以 integrations/CDN/alerts/cdn_by_categraf.json 提供了配套的告警规则模板开箱即用。二、配置文件编写详解CDN 插件的配置以[[instances]]为单元每个 instance 对应一组探测目标。完整配置示例如下依据 integrations/CDN/markdown/README.md 与 collect/cdn/cdn.toml[[instances]] targets [ https://www.baidu.com ] # # 自定义 DNS # # 自定义 dns 地址 # dns # # 自定义 dns 使用的协议 # dns_Protocol udp # # 自定义 dns 超时时间 # dns_timeout_ms 1000 # # 连接相关配置 # 连接超时时间 connect_timeout_ms 3000 # tls 握手超时时间 tls_handshake_timeout_ms 1000 # # http 相关配置 # http 请求方法 HEAD GET POST method GET # # 响应内容编码支持GBK GB2312 HZGB2312 GBK18030 BIG5 ,default: UTF8 encode UTF8 # # http 请求头部配置 # headers { Authorization, X-Forwarded-For, Host} headers { User-AgentMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36} ## body 配置 paylaod ## basic auth配置 ,也可以直接在header中配置 # username # password # # 响应部分配置 # 匹配方式 完全匹配还是部分匹配, 支持complete or substring # 不配置 则使用substring match_pattern substring # 期望返回的响应内容 expect_response_string ok # 期望返回的响应码 expect_response_status_code 2002.1 目标与 DNS 配置配置项默认值说明targets无必填待探测的 URL 列表支持同时配置多个域名例如https://www.baidu.comdns空自定义 DNS 服务器地址留空则使用系统默认解析dns_Protocoludp自定义 DNS 使用的协议如udpdns_timeout_ms1000自定义 DNS 解析超时时间单位毫秒targets中每个 URL 都会独立执行一次完整探测产生一套独立的指标序列。当业务域名存在多地域、多线路解析时建议按需拆分为多个[[instances]]并配合 Categraf 的标签能力区分探测目标。2.2 连接与 HTTP 配置配置项默认值说明connect_timeout_ms3000TCP 连接超时时间单位毫秒tls_handshake_timeout_ms1000TLS 握手超时时间单位毫秒methodGETHTTP 请求方法支持HEAD、GET、POSTencodeUTF8响应内容编码支持GBK、GB2312、HZGB2312、GBK18030、BIG5默认UTF8headers无自定义请求头支持Authorization、X-Forwarded-For、Host、User-Agent等paylaod空请求体body内容配合POST方法使用username/password空Basic Auth 认证凭据也可直接写入headers示例中默认携带了完整的浏览器 User-Agent用于规避部分 CDN 节点对空 UA 或爬虫 UA 的拦截真实业务中应替换为目标站点认可的正常 UA或直接配置headers { Host你的站点域名 }等与业务强相关的请求头。若探测资源受 Basic Auth 保护既可以在headers中直接写Authorization也可以使用username/password两个独立配置项。2.3 响应校验配置配置项默认值说明match_patternsubstring响应体匹配方式complete为完全匹配substring为部分匹配子串包含expect_response_string无期望的响应内容如okexpect_response_status_code200期望的 HTTP 响应状态码这是决定探测业务是否正常的关键一环仅有状态码不足以证明页面内容有效例如源站 500 时若 CDN 缓存了旧页面仍会返回 200。因此建议同时配置expect_response_string与expect_response_status_code让探测结果同时反映可访问性与内容正确性。注意match_pattern不配置时默认采用substring部分匹配。三、指标说明每次探测完成后插件输出以下指标各耗时类指标单位为毫秒与配置项connect_timeout_ms/dns_timeout_ms的单位保持一致这一点同样在告警规则注释中明确说明见 cdn_by_categraf.json指标名含义cdn_dns_request请求资源链接时 DNS 解析花费的时间cdn_tcp_connect请求资源链接时建立 TCP 连接花费的时间cdn_tls_handshake请求资源链接时TLS 握手花费的时间cdn_first_byte请求资源链接时首包响应时间从请求发出到收到首包的时间cdn_total_cost请求资源链接总共花费的时间cdn_response_status_code请求资源链接的响应状态码cdn_probe_result探测结果0 为成功非 0 为各类失败见下节这组指标的时间线关系为cdn_dns_request→cdn_tcp_connect→cdn_tls_handshake→cdn_first_byte→cdn_total_cost。当需要定位访问慢问题时可以沿时间线逐段对比找出耗时占比最大的阶段这一点在第五节告警排查中会具体展开。四、cdn_probe_result 状态码说明cdn_probe_result是判定探测成败的核心指标取值含义如下Success 0 探测成功 ConnectionFailed 1 连接失败 Timeout 2 超时 DNSError 3 DNS解析失败 AddressError 4 地址错误 BodyMismatch 5 响应内容不匹配 CodeMismatch 6 响应码不匹配状态码的设计思路非常清晰只有0代表整体成功其余 1~6 分别对应链路不同环节的失败。其中3DNSError指向解析环节多半是域名解析链路、CNAME 指向或本地 DNS 配置问题1ConnectionFailed与2Timeout指向网络或目标节点不可达、响应过慢4AddressError指向目标地址本身非法5BodyMismatch与6CodeMismatch则说明服务可达但内容不符合预期是回源内容变化、源站故障或鉴权变更的典型信号。由于 Prometheus 生态的时间序列数据库只存储 float64 数值该状态码以数值形式存储、以语义表解读使用方式与仓库中http_response_result_code的设计一致可对照 HTTP_Response/metrics/categraf.json 的指标注释。五、内置告警规则与故障排查仓库在 integrations/CDN/alerts/cdn_by_categraf.json 中预置了 4 条 Prometheus 告警规则模板默认disabled: 1处于停用状态导入后按需启用规则名核心 PromQL级别说明CDN 探测失败cdn_probe_result ! 01严重任何非 0 的探测结果即告警持续 120s 生效CDN 响应状态码异常cdn_response_status_code 4001严重状态码进入 4xx/5xx 即告警CDN 首包响应时间过长cdn_first_byte 20002警告首包超过 2000ms2 秒告警持续 300sCDN 请求总耗时过长cdn_total_cost 50002警告总耗时超过 5000ms5 秒告警规则的annotations.action字段还内置了分场景的排障步骤中文与英文均可在 i18n/en_US.json 中查到翻译核心方法论如下cdn_probe_result ! 0场景先从告警标签取出被探测的target本地执行curl -sv target复现对照cdn_probe_result取值定位故障环节。值为3时执行dig 域名确认 CNAME 是否仍指向 CDN 厂商值为1/2时从探测点执行mtr CDN节点IP区分网络故障与节点故障并到厂商控制台确认节点异常公告值为5/6时说明回源内容或状态码变化优先排查源站是否发布过新版本或已故障。状态码异常场景curl -sI target确认实际状态码。4xx 中 403 最常见检查 CDN 防盗链、Referer 白名单、URL 鉴权是否刚变更404 确认源站资源是否被删。5xx 说明回源失败直接 curl 源站验证健康度并核对回源 Host 头与源站站点配置。确认是 CDN 侧问题则回滚最近一次配置变更并刷新缓存。首包慢场景curl -w %{time_namelookup} %{time_connect} %{time_starttransfer}拆解耗时。连接快而首包慢说明回源慢检查源站响应时间与 CDN 缓存命中率命中率低时排查是否被Cache-Control: no-cache或随机查询参数破坏了缓存并考虑开启回源长连接与预取。总耗时慢场景用curl -w将耗时拆解为 DNS/TCP/TLS/首包/传输五段找出占比最大的阶段逐一优化——DNS 慢查解析链路与 TTLTLS 慢确认证书链长度与会话复用传输慢评估压缩与分片各阶段均不突出但总量高的应从多个地域探测点对比确认是否为特定区域节点问题。六、在 Nightingale 中的落地流程采集侧将本文第二节的配置写入 Categraf 的 cdn 插件配置文件对应模板见 integrations/CDN/collect/cdn/cdn.toml填写真实待探测域名重启 Categraf 使其通过 Remote Write 将cdn_*指标推送至 Nightingale存储与查询指标落库后在 Nightingale 中使用 PromQL如cdn_probe_result、cdn_first_byte构建图表验证指标是否按预期上报告警侧导入 integrations/CDN/alerts/cdn_by_categraf.json 中的规则模板按业务容忍度调整阈值如首包 2000ms、总耗时 5000ms与持续时长prom_for_duration启用后即可获得 CDN 可用性与性能的自动监控排障闭环告警触发后按第五节 annotations 中的动作指引逐段定位形成探测 → 告警 → 分段定位 → 修复的完整闭环。需要注意的是所有耗时类指标均以毫秒为单位上报与connect_timeout_ms、dns_timeout_ms的配置单位保持一致因此调整超时类配置时告警阈值的语义也应参照同一单位理解避免量纲混淆。七、总结CDN 插件通过一次 HTTP 主动探测将访问链路拆解为 DNS、TCP、TLS、首包、总耗时五个可观测阶段配合cdn_probe_result的 0~6 状态码语义能够精确回答CDN 是否可用与慢在哪一段两个核心问题。结合仓库内置的 4 条告警规则与分场景排障指南运维团队可以用最小的探针成本获得对 CDN 接入域名端到端的可用性、正确性与性能监控能力与 Nightingale 的指标存储、告警引擎和可视化能力无缝衔接。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考