域名解析缓慢或失败时，业务侧表现出的症状往往是连接超时、请求堆积，排查起来容易误判为网络或后端服务问题。与其在故障发生后追查，不如把DNS解析的关键指标纳入Grafana统一监控。Grafana本身并不采集数据，它依赖数据源提供指标，因此构建DNS仪表盘的第一步是确定数据从哪里来，以及如何把原始指标转化为可读的图表和告警规则。
DNS监控指标的采集方案与选型
DNS服务的指标采集方式与运行的具体软件强相关。如果使用CoreDNS作为集群DNS服务，官方提供了Prometheus插件，只需在Corefile中启用prometheus配置，即可通过HTTP端点暴露解析请求总数、响应码分布、延迟直方图等指标。如果是自建的BIND或Unbound，则需要借助第三方exporter或者启用内建的统计模块。例如Unbound可通过remote control接口获取缓存命中率和递归耗时，再通过unbound_exporter转换为Prometheus格式。
对于不直接运行DNS软件、只关心解析链路的场景，blackbox_exporter能承担拨测任务，从外部视角探测指定域名的解析耗时、DNSSEC验证结果以及特定记录类型的存在性。拨测数据与内部统计数据的区别在于，前者反映用户实际体验，后者反映服务自身健康状态，两者结合才能形成完整的监控视图。生产环境中建议同时部署内部指标采集和外部拨测，将两套数据源同时接入Grafana，便于对比故障时内外部表现。
选择采集方案时还需要考虑指标基数问题。CoreDNS暴露的每域名每类型指标可能产生高基数，若在Grafana中频繁按域名分组聚合，查询压力会明显增大。常见做法是保留原始指标的分钟级聚合任务（如recording rule），或者只把Top N域名绘制成表格面板，减少模板变量的复杂度和面板加载时间。
数据源接入与仪表盘初始化
Grafana中的数据源类型选择Prometheus，填写CoreDNS导出端点或blackbox exporter的地址，并设置合适的时间间隔与超时参数。建议在数据源配置中开启“Min time interval”，例如设置为15s，防止面板刷新频率过高导致Prometheus负载上升。接入数据源后，新建Dashboard时先定义好常用的模板变量，如instance、job、domain，让后续所有面板能够按需切换视角。
模板变量的query可以使用Prometheus的label_values函数，例如从coredns_dns_requests_total中提取instance列表。这样在查看仪表盘时，可以直接在下拉菜单里切换不同的CoreDNS实例，而无须修改每张面板的查询语句。更进一步的用法是联动变量，比如根据所选instance自动过滤出该实例上解析量最高的域名列表，用于局部下钻分析。
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}
上面的Corefile片段启用了prometheus插件，监听9153端口。配置改动后无需重启CoreDNS，reload插件会平滑加载新配置。此时访问/metrics路径即可看到类似coredns_dns_requests_total和coredns_dns_response_time_seconds_bucket的指标输出，Grafana数据源中直接填写该地址就能开始出图。若使用Kubernetes部署，也可以借助Service的DNS名称指向Prometheus采集端，避免硬编码Pod IP。
核心面板设计：从QPS到延迟分布
DNS仪表盘的核心面板至少要覆盖请求量、延迟、失败率和缓存命中率四个维度。请求量面板使用sum(rate(coredns_dns_requests_total[5m])) by (type)，按A、AAAA、PTR等记录类型分组展示；这里用堆叠柱状图比较合适，能够直观反映各类型解析请求的占比变化。延迟面板则采用直方图分位数计算，结合histogram_quantile(0.99, sum(rate(coredns_dns_response_time_seconds_bucket[5m])) by (le))绘制分位线，便于观察长尾请求。
失败率面板需要关注两种视角：一是CoreDNS返回的SERVFAIL、NXDOMAIN等响应码占比，二是客户端视角的连接失败。前者通过sum(rate(coredns_dns_responses_total{rcode!="NOERROR"}[5m]))计算，后者需要依赖blackbox_exporter采集的probe_dns_lookup_time_seconds等指标。两个面板放在同一行，可以快速判断问题究竟出在权威解析环节还是网络链路环节。
# 查询延迟 P99 示例
histogram_quantile(
0.99,
sum(
rate(
coredns_dns_response_time_seconds_bucket[5m]
)
) by (le, server)
)
# 查询失败率示例
sum(
rate(
coredns_dns_responses_total{
rcode!="NOERROR"
}[5m]
)
) by (rcode)
缓存命中率面板适用于启用了cache插件的CoreDNS环境。命中率下降通常意味着域名TTL配置过短或cache容量不足。使用coredns_cache_hits_total与coredns_cache_misses_total计算命中百分比，绘制成饼图或饼图形式的Grafana面板均可，但饼图不适合展示趋势，建议同时放置一个时间序列面板呈现命中率波动，以便关联其他指标变化。每个图表都需要精确设置单位、小数位和图例格式，避免信息噪声。
告警规则配置与故障定位联动
仪表盘只是呈现数据，真正发挥作用的是告警规则。Grafana内置的Alerting模块可以直接基于面板查询创建告警，无需额外部署Alertmanager。对于DNS服务，建议配置两条基础告警：解析失败率突增和P99延迟超过阈值。失败率告警的条件可以设置为最近5分钟内SERVFAIL占比超过1%，延迟告警则根据业务容忍度设置，通用起步值为500ms。
- alert: CoreDNSHighErrorRate
expr: |
sum(rate(coredns_dns_responses_total{rcode="SERVFAIL"}[5m]))
/
sum(rate(coredns_dns_responses_total[5m])) > 0.01
for: 10m
labels:
severity: critical
annotations:
summary: "CoreDNS 解析失败率过高"
description: "当前 SERVFAIL 占比超过 1%，持续 10 分钟"
- alert: CoreDNSHighLatency
expr: |
histogram_quantile(0.99,
sum(rate(coredns_dns_response_time_seconds_bucket[5m])) by (le)
) > 0.5
for: 5m
labels:
severity: warning
annotations:
summary: "CoreDNS P99 延迟超过 500ms"
告警触发后，定位问题需要结合仪表盘上的多面板联合分析。比如延迟升高时，切换模板变量到不同instance，检查是否为单节点故障；结合缓存命中率面板判断是否因缓存失效引发上游压力；再配合网络拨测面板确认是否为机房出口问题。为了提升定位效率，可以在Grafana中使用Dashboard links跳转到关联的日志面板或基础设施监控页面，减少来回切换时间。
通知渠道方面，Grafana支持钉钉、企业微信、Slack等Webhook方式。建议将告警消息设置为包含当前面板的截图快照链接，这样收到通知的同事无需登录Grafana就能看到具体图表，大幅缩短响应链路。同时注意为告警规则添加不同的分级标签，例如critical与warning分别路由到不同的通知组，避免所有告警都打扰同一批人。
仪表盘调优与运维最佳实践
初次搭建的DNS仪表盘往往包含过多面板，导致加载缓慢或重点不突出。优化方向包括：减少每秒查询次数，降低时间范围跨度；将低频查看的明细面板折叠到Row中；利用Grafana的Library Panel机制复用通用查询；对重要面板设置阈值线，例如在延迟图上标记500ms横线，让超出范围的值一目了然。这些细节决定仪表盘是否真正适合日常值班使用。
保持仪表盘简洁的另一个有效技巧是使用“经济型”指标。例如用
coredns_dns_requests_total代替原始日志统计，用probe_dns_lookup_time_seconds代替业务埋点数据，既能满足监控需求，又降低了数据链路维护成本。
日常巡检模板可以围绕每日、每周两个维度设计：每日巡检关注请求量异常波动和错误码变化，每周巡检关注缓存命中率趋势和延迟分位数抬升幅度。把巡检结论记录在Grafana的注释（Annotations）中，可方便将来对比发布、变更等因素对DNS指标的影响。若存在多个环境（生产、预发、测试），建议将仪表盘JSON导出后统一管理，并通过脚本批量导入，确保各环境面板配置一致。
最后建议定期演练DNS故障场景，例如模拟上游递归不可达、CoreDNS Pod被驱逐等情形，观察仪表盘指标和告警是否符合预期。监控的价值不只在看板本身，更在于对异常模式形成条件反射式的判断路径，才能让Grafana真正成为DNS稳定性的守护工具。