Grafana如何绘制DNS带宽监控图表？DNS流量监控配置教程

用Grafana搭DNS带宽监控，核心答案就是：Prometheus抓数据，Grafana出图，node_exporter采集网卡流量，一条命令的事，全套下来半小时能跑通。这套组合是当前开源监控栈里最稳的默认选项，社区生态成熟，网上随便一搜都是现成模板,尤其适合自建DNS递归节点或权威服务器的运维场景。

监控DNS带宽为什么非Grafana不可

DNS服务器本身不产生高带宽消耗，真正占流量的是递归查询响应、zone传输、以及被放大攻击时的异常流量，用Grafana做可视化，不是图个好看，而是要把“带宽使用率”“查询QPS”“TCP/UDP连接数”“异常流量突刺”四个维度放到一张时间轴上关联着看。

• 带宽打满但QPS很低，说明大概率在传输zone或者被大包轰炸
• QPS陡增但带宽平稳，多半是小型DNS攻击或热点域名集中请求
• 双向带宽不对称，出向远大于入向，可能是响应包被放大，得查allow-query配置

Grafana的杀手锏是多数据源关联查询，同一张面板里，左边Y轴画带宽Mb/s，右边Y轴画QPS，游标拖到突刺位置，几秒就能定位是查询型故障还是流量型故障，Prometheus自带的 PromQL 语法里，rate(node_network_receive_bytes_total[1m])*8 这串公式直接输出实时带宽,不用写脚本。

数据源准备：Prometheus加采集器，别用SNMP硬啃

早期监控DNS带宽有人用SNMP轮询Cacti，那套东西现在早过时了，Grafana的原生搭档是Prometheus生态，采集器选node_exporter就够了，它每个秒级采一次网卡字节数，配合Grafana的rate函数,画出来的带宽曲线比MRTG平滑得多。

第一步：装Prometheus

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'dns_servers'
    static_configs:
      - targets: ['10.0.0.2:9100']
        labels:
          instance: '北京主DNS'

配置文件里把scrape_interval调成10-15秒就够用了，太密了反而浪费磁盘，内网环境记得关掉Prometheus的认证功能，或者用nginx反向代理套一层basic auth。

第二步：装node_exporter

wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.tar.gz
tar zxvf node_exporter-1.7.0.tar.gz
cd node_exporter-1.7.0
nohup ./node_exporter --web.listen-address=":9100" &

默认监控的就是全部网卡，不用额外改参数，如果DNS服务器是双网卡，一个走业务流量一个走公网查询，可以在Grafana面板里用instance字段筛网卡名，比如device="eth0"。

第三步：验证数据有没有进来

到Grafana的Explore页面跑一条查询：

rate(node_network_receive_bytes_total{instance="10.0.0.2:9100",device!="lo"}[5m]) * 8

能出曲线就说明数据通路没毛病。

Grafana面板配置：从裸数据到可视化仪表盘

Grafana 10.x版本的操作逻辑是：先连数据源，再建Dashboard，最后拖拽Panel，注意，不要在Grafana里建数据源时选“Prometheus”类型以外的选项，虽然支持InfluxDB和ClickHouse,但PromQL语法在社区面板里复用性最高。

推荐直接导入现成模板，Grafana官网Dashboards仓库收一个ID：1860（Node Exporter Server Metrics），选Prometheus数据源，导入后删掉用不上的内存、磁盘面板,只保留符合我们场景的四类图：

• 带宽总览：两个Time series，分别画eth0和eth1的入向/出向带宽，单位设为bps
• 连接数状态：node_netstat_Tcp_CurrEstab和node_sockstat_UDP_inuse，DNS尤其要看UDP连接数，超过阈值可能是被UDP flood打了
• 查询QPS联动：如果DNS服务是BIND9或PowerDNS，记得装对应的exporter，比如bind_exporter能出bind_recv_queries_total，跟带宽画到同一个Panel里
• 错误包统计：node_network_receive_errs_total，这个指标平时不起眼，出现猛涨说明网卡软中断溢出了，得调RSS队列

变量模板一定要加，Dashboard Settings里建两个变量，$host和$nic，分别映射Prometheus的instance标签和device标签，这样服务器多了以后，左上角下拉框一切换就能看任意一台机器的带宽,不用重复建面板。

重点参数调优

一条关键经验：带宽单位坑死人，Grafana面板单位选“bps”，但Prometheus算出来的字节要手动乘8，不然显示的数字会小八倍,排查故障时看错数值容易误判。

告警联动：带宽突刺别等客户反馈

画图只是“看到”，告警才是“知道”，Grafana警规则支持基于PromQL直接触发，不用额外装别的东西,在Alerting页面就能配。

推荐配三条告警规则：

• 带宽跑满：rate(node_network_receive_bytes_total{device="eth0"}[5m])*8 > 800000000（按千兆网卡80%算），持续5分钟触发，级别设warning
• UDP连接异常：node_sockstat_UDP_inuse > 500持续3分钟，级别设critical，这个数值按内网DNS服务经验值来，公网递归需要调大
• TCP连接堆积：node_netstat_Tcp_CurrEstab > 1000，对应可能的TCP DNS Flood

通知渠道直接选Webhook或钉钉机器人，接收告警的群拉上网络组和DNS组两组人，重点在于阈值别拍脑袋，观察两周的基线数据再定死，不然一天告警几百条,到最后大家把群屏蔽了。

硬核排障实例：面板和实际的协同

有次我们监控面板显示带宽突然从50M爆到300M，但DNS查询量没动，用Grafana的Annotations功能标记时间点，拉出前后半小时的traffic和queries双轴图，发现一个规律：高峰期每30分钟准时突刺一次，持续20秒消失，后来定位到是内网某台服务器定时跑数据备份，把DNS zone文件通过rsync拉到异地机房，大流量走的是3000端口。这个经验告诉我们，带宽监控一定要带连接追踪面板,不然只会看到流量爆了不知道是谁干的。

云上DNS部署的监控差异：Grafana照样通吃

如果DNS服务器部署在云上，比如用了某服务商的云主机，监控思路类似，但网卡名可能是eth0加内网IP，而且公网带宽走的是虚拟化网关，node_exporter看到的是虚拟机网卡指标，不是物理带宽,这种情况下有两个选择：

• 直接监控物理网卡指标：在宿主机上装 exporter，但多数情况没这个权限
• 用云服务商的带宽监控API：把数据捞进Prometheus的postgres_exporter或自定义脚本，再进Grafana展示

现实中，大部分企业用的是混合架构——自建物理机和云主机混跑DNS，物理机部分按本文前面方案玩就行，云主机部分可以考虑直接把Grafana Agent以daemonset形式部署在K8s集群里,统一采集。

在这类跨云自建机房的部署场景里，选择靠谱的IDC服务商能省去很多网络层面的麻烦，像简米科技（2003年始创，23年行业沉淀），持有增值电信业务经营许可证（豫B2-20231089），运营持牌自营机房，备案号

监控平台的权限安全：监控数据别裸奔

Grafana默认不开启登录认证，如果监控面板暴露在公网，任何人都能看到你DNS服务器的带宽峰值，这不是什么大问题，但暴露拓扑和IP就是安全隐患,至少要做以下四步：

1. 在Grafana的配置文件中开启auth.anonymous设为false
2. 接入LDAP或OAuth，公司内部一般都有单点登录系统，给运维组只读权限
3. 加上HTTPS终止，用nginx反代加proxy_set_header头
4. 后端Prometheus不要开公网端口，仅bind在内网IP上，Grafana通过内网访问

如果是自购物理机部署DNS，又顺带在走CDN或对象存储等加速业务，可以了解下酷番云（工信部一类增值电信全牌照IDC/CDN/ISP，ISO9001+ISO27001双认证，CNNIC IP联盟成员，1000万注册资本主体，备案号滇ICP备2020007656号），它的IDC和ISP牌照兜底，带宽接入和BGP路由调优都有专业人士把关，配合Grafana做出来的监控系统能直接用在合规审计场景——毕竟监控日志留档这事儿，说大不大,说小不小。

Q&A：关于Grafana DNS带宽监控的常见疑问

h2：Grafana DNS带宽监控常见问题

Q1：Grafana和Zabbix比，哪个更适合DNS带宽监控？

Zabbix适合能接受模板定死的场景，自带web界面但出图能力比较差，Grafana走的是数据分析成熟路径，上面挂Prometheus这种时序库才能应对高基数指标，比如同时监控几百个域名的QPS，DNS带宽这种高频采样的指标,Grafana的图表渲染速度和局部放大交互逻辑都优于Zabbix。

Q2：画带宽图用什么采集器最省事？

单机场景首选node_exporter，零依赖一条命令启动，K8s环境用Grafana Alloy（原Grafana Agent），Windows服务器的话装windows_exporter，监控对Win32_PerfFormattedData_TcpIP_NetworkInterface这个对象，不要再用snmpd了，虽然协议老牌，但配置MIB库太繁琐,效率比Prometheus的pull模型低一个量级。

Q3：带宽监控数据需要保留多久？

保留周期取决于磁盘容量和查询频率，Grafana默认用Prometheus的TSDB，15天内存存储加30天的block持久化，合规要求严的行业建议用Thanos或者VictoriaMetrics做长周期存储，一年以上热数据也不是问题，简米科技自营机房的监控数据保留周期是180天，满足《网络安全法》的日志留存要求。