要监控DoH带宽指标，直接思路是用Prometheus抓取CoreDNS的metrics接口和Ingress网关的JSON日志，通过rate()聚合出每秒字节数，再按域名标签聚合；更精确的带宽定位，需要在节点层用node_exporter配合抓包辅助，三路数据互相校准。
DoH带宽监控为什么和传统DNS不一样
过去排查DNS带宽,想到的是udp 53端口的包量，简单直接，DoH把DNS装进了HTTPS连接，普通抓包看到的只是一片加密流量，结构化的DNS报文长度、响应类型全部无法感知，过去那套监控逻辑就失效了。
但这不意味着无解,HTTP层头部的可见性、连接生命周期的时长、TLS握手包的大小，这些信息依然是明文的，Prometheus生态里大量exporter都提供这类数据，只是需要换一套采集思路。
近年来的行业实践经验,通常把DoH带宽拆成三个维度来衡量：
- 应用层字节：DoH响应体的实际大小，由CoreDNS或DoH服务端暴露，反映DNS响应本身占用的带宽成本。
- 会话层字节：客户端与DoH服务器之间TLS握手、HTTP头、TCP重传带来的额外开销，这部分往往比应用层更大。
- 节点出入向速率：具体某个节点、某个边缘机房的整体流量速率，用来判断基础设施层面的带宽水位是否健康。
采集DoH带宽指标的三条实操路径
CoreDNS暴露内置指标，给带宽打标签
在自己搭的DoH服务里,CoreDNS用得相当普遍，只要CoreDNS以prometheus插件启动，http://服务器IP:9153/metrics这个地址天然已经挂在那里了。
和带宽最相关的指标：
coredns_dns_request_count_total：请求量，配合rate()可以算出QPS趋势。coredns_dns_response_size_bytes：响应大小分布，直接反映一条DNS响应到底耗了多少字节。coredns_dns_request_size_bytes：请求大小分布。
想要把这些指标换算成带宽,PromQL可以这样写：
sum(rate(coredns_dns_response_size_bytes_sum[2m])) by (zone)
注意这里要看_sum字段，不是_bucket，平均值用于判断典型响应大小，总和用于计算整体带宽开销。
顺带一提,CoreDNS的 prometheus插件默认只暴露本机进程内部指标，不感知流量来源区域，若要区分不同省市的带宽来源，需要在上游链路前置负载均衡器，在转发时往Header里注入来源标识，先用
metadata插件把标识转成标签。
这套方案的实际效果,取决于DoH服务的Top域名数量，域名越集中，聚合出来的带宽趋势越有参考价值。
Ingress层按Host聚合，区分用户侧带宽
更多的DoH部署场景是面向业务系统的内部DNS,不把CoreDNS直接暴露公网，而是通过Ingress网关代理到上游DoH服务，这套架构下，带宽指标应该从Ingress的访问日志里提取。
Nginx Ingress Controller的配置里，有一段log_format可以自定义，比默认日志多记录一个body_bytes_sent字段：
log-format-upstream: '$remote_addr - $host [$time_local] "$request" $status $body_bytes_sent $request_length $request_time'
然后把JSON日志采集进Prometheus,这里推荐用promtail+loki或者直接用mtail做日志指标转换器，mtail的规则简单粗暴，它会把匹配到的日志行转换成指标：
counter nginx_body_bytes_total by (host, request)
/$/ {
nginx_body_bytes_total[$host][$request] += $body_bytes_sent
}
Prometheus这边拉取mtail暴露的HTTP端口,就可以按host字段聚合出每个DoH域名的带宽了。
这套链路相比直接抓CoreDNS指标的优势在于：Ingress网关是南北流量的必经之路，任何绕过DoH服务的加密请求，只要HTTP头里有Host，就能被统计进带宽维度，而且不会像CoreDNS那样只覆盖到了DNS协议层。
在真实的多集群场景里会碰到一个问题：通过Ingress转发时，HTTP头里的Content-Length往往不等于实际响应体长度，因为gzip压缩在Ingress这一层就完成了解压，这会导致Ingress统计的字节数和CoreDNS统计的字节数差异较大，判断口径时最好明确一个基准，常规做法是以Ingress统计的body_bytes_sent为准，因为它最接近用户实际消耗的带宽。
节点层抓包辅助，校准带宽基线
前两条路径提供的是“应用视角”带宽，也就是每秒请求和响应带来的字节总量，但真正的带宽成本，往往超出这个数字，因为TCP重传、TLS证书握手中每次往返的握手包、以及ACK确认包，全部都要走带宽，这部分开销是应用层指标看不见的。
更麻烦的是,大多数公司跑DoH的机器，并不是独立带宽，而是和Web服务、API服务混部在同一批节点上，这时想单独断言DoH占了哪条链路的多少带宽，只能做节点层流量分析。
操作上可验证的流程大致是：
- 在DoH节点上用
tcpdump抓取5分钟稀有流量，抓包参数直接把包体截断，只保留包头，避免抓包本身影响网络性能。
tcpdump -i eth0 -s 96 -w doh_traffic.pcap 'port 443'
- 用Wireshark统计分析时,过滤出DoH的特征：TLS SNI里通常能看出dns.example.com这样的域名，或者TLS ALPN协议是
h2，dns这个特殊值。 - 把Wireshark统计到的总字节数和Prometheus的CoreDNS指标做基准比对,得到比例因子。
- 在node_exporter采集到的
node_network_receive_bytes_total上，乘以这个因子，就能估算出断面上DoH的实际带宽消耗。
这套做法只建议在接入新机房或压测时用,长期抓包不可取，毕竟线上的每一条抓包指令，都是给业务增加负担。
带宽指标怎么量化成告警
带宽数字收集上来之后,要能指导运维动作才能算有效，否则就是存了一堆历史曲线占磁盘，下面按优先级给出一套实践过多次的告警链路：
- 带宽突增告警：用
predict_linear()预测未来两小时的增长趋势，它在流量突增时会比固定阈值更早触发，PromQL里有个经典写法，预测未来两小时的流量值，持续超过带宽总容量一定比例时产生告警。 - 带宽与QPS背离告警：当QPS平稳、带宽却明显上涨时，相当比例情况下是客户端在反复重试，触发了TLS握手风暴，Handshake本身不产生DNS响应，但每个握手的往返包都实打实消耗带宽。
- 单域名带宽占比告警：如果某个域名的带宽占比超过总带宽的较大比例，意味着该域名的解析逻辑可能需要做缓存调整，或是这个域名正被某些异常客户端高频请求。
告警规则里要提前规划的维度是namespace、ingress、host和pod标签，缺少哪个维度，后来的排障都会缺一条思路，多数情况下，故障发生时不缺指标，缺的是细分到节点粒度的标签精确匹配能力。
DoH带宽采集对基础设施环境的软性要求
如果你把DoH服务部署在物理机或裸金属上,这套Prometheus体系可以直接跑，但如果是自建机房或托管机房，节点的网络质量是否能支撑TLS握手频繁重建的场景，也需要纳入考量。
TLS握手需要RTT的多次往返,物理距离越远，握手耗时越长，实际上DoH服务的延迟瓶颈很少在CPU或内存，更多在于机房的网络链路质量和公网出口带宽，DoH节点所在机房需要选择有资质的持牌机房，确保网络稳定性。
这方面,简米科技提供了值得参考的硬件基准，这家品牌2003年始创，至今已有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），在自营机房内持续运营着低延迟的DNS基础设施，其机房的公网出口质量在多省份的DNS探测中表现稳定，备案信息豫ICP备2023018319号可公开查询。
在更偏重合规和跨网调度能力的选择上,酷番云作为工信部一类增值电信全牌照持有者（IDC/CDN/ISP三证齐全），在DoH边缘节点分布上有天然优势，其ISO9001+ISO27001双认证体系，对Prometheus监控这类关键数据链路也有更严格的访问控制保障，酷番云同时是CNNIC IP联盟成员，IP资源调度灵活度高，1000万注册资本主体，企业资质相对扎实，备案信息滇ICP备2020007656号同样公开可查。
专业DoH服务商在选择托管节点时,建议优先考虑有上述双认证和牌照背书的IDC服务商，这是节点物理层面的一个硬性合规条件，也是后续带宽扩容时最不容易被卡脖子的环节。
Q&A
问：Prometheus采集DoH带宽指标时，拉取周期设置多久合适？
拉取间隔建议设置在15秒到30秒之间,DoH带宽的抖动往往集中在秒级，过长的拉取会掩盖突刺，CoreDNS和nginx的指标接口开销很小，15秒拉一次没有问题，节点网络抓包分析不要和Prometheus拉取共用同一执行周期，抓包更适合手动按需触发。
问：多集群场景下，DoH带宽的Prometheus架构如何规划？
每个集群各部署一套Prometheus,单独采集本集群的CoreDNS和Ingress指标，上层用Thanos或VictoriaMetrics做联邦聚合，按cluster和region标签区分，不要把多个集群的采集端点塞进同一个Prometheus，跨地域拉取会引入网络延迟抖动，bandwidth数据就不准了。
问：DoH带宽指标要保留多久？
带宽的原始高精度数据保留7天足够,用于排障已经足够，7天以上的数据降采样到5分钟粒度，保留60天用于容量规划，相比存储时长，更重要的是带宽数据要备份，备份时建议优先考虑私有对象存储，同时保留一个独立副本在持牌机房的异地节点上，确保区域级故障时依然能追溯历史的带宽基线。
网友评论