监控机的DNS如何设置？

监控机DNS设置：运维老手教你筑牢业务监控生命线

监控机如同业务的"哨兵"，其网络通畅是生命线，DNS设置不当，轻则监控数据延迟、告警失灵，重则彻底"失联"，让你在故障面前变成"盲人"，正确配置DNS是保障监控系统稳定可靠的关键一步。

一、 为什么监控机DNS设置如此重要？

核心服务依赖 监控机需要解析NTP服务器地址同步时间，连接数据库存储数据，上报信息到中央监控平台（如Zabbix Server, Prometheus），访问外部API获取状态等，无一不依赖DNS解析。

告警及时性 DNS解析失败或缓慢，会直接导致监控项采集超时、失败，进而延误甚至丢失关键告警，错过故障黄金处理期。

数据完整性 解析问题可能造成监控数据点丢失或时间戳错乱，影响历史数据分析与问题回溯。

自身健康监测 监控系统自身组件（如Agent, Exporter）间的通信也常依赖主机名解析。

二、 如何正确设置监控机的DNS

1. 确定可靠的DNS服务器

主备搭配 强烈建议至少配置两个DNS服务器地址，一个作为主用，一个作为备用，避免单点故障。

来源选择

内部DNS服务器 如果企业有自建DNS（如Bind, Windows DNS），且能稳定解析内网监控相关域名（如数据库域名、内部应用域名、监控平台域名），这是首选，它通常具有更高的安全性和内网解析速度。

公共DNS 如阿里云DNS (223.5.5.5,223.6.6.6)、腾讯云DNS (119.29.29.29)、Google DNS (8.8.8.8,8.8.4.4)、Cloudflare DNS (1.1.1.1,1.0.0.1)，选择延迟低、稳定性高的公共DNS作为备用或补充，尤其当需要解析大量外部地址时。

关键原则 确保所选的DNS服务器高可用、低延迟、安全可信，避免使用不明确来源的DNS。

2. 配置监控机操作系统的DNS

Linux系统 (以常见发行版为例)

方法一修改/etc/resolv.conf (临时/部分系统)

使用root权限编辑文件sudo vi /etc/resolv.conf

添加或修改nameserver 行

        nameserver 192.168.1.10     # 主DNS (例如内部DNS)
        nameserver 223.5.5.5         # 备DNS (例如阿里云DNS)

注意 在某些使用systemd-resolved或NetworkManager的现代发行版上，直接修改/etc/resolv.conf可能被覆盖，更推荐使用方法二。

方法二使用NetworkManager (图形界面/命令行)

图形界面 在系统网络设置中，找到对应的网络连接（如eth0, ens33），在IPv4/IPv6设置里，将"自动(DNS)"关闭，手动填入DNS服务器地址。

命令行

        nmcli con mod "YourConnectionName" ipv4.dns "192.168.1.10 223.5.5.5"
        nmcli con mod "YourConnectionName" ipv4.ignore-auto-dns yes # 禁用自动DNS
        nmcli con down "YourConnectionName" && nmcli con up "YourConnectionName" # 重启连接生效

方法三修改网卡配置文件 (如CentOS/RHEL 7)

* 编辑对应网卡配置文件 (如/etc/sysconfig/network-scripts/ifcfg-eth0)

添加或修改

        DNS1=192.168.1.10
        DNS2=223.5.5.5
        PEERDNS=no # 防止DHCP覆盖DNS设置

重启网络服务sudo systemctl restart network

Windows系统

打开"控制面板" -> "网络和 Internet" -> "网络和共享中心"。

点击左侧"更改适配器设置"。

右键点击监控机使用的网络连接 -> 选择"属性"。

双击"Internet 协议版本 4 (TCP/IPv4)"。

在下方选择"使用下面的 DNS 服务器地址"。

填入主用和备用DNS服务器地址。

勾选"退出时验证设置"（可选）。

点击"确定"保存，通常无需重启。

三、 验证DNS设置与解析

配置完成后，务必进行验证：

1、检查配置：

* Linux:cat /etc/resolv.conf (注意是否被覆盖),nmcli dev show | grep DNS

* Windows:ipconfig /all 在输出中找到对应网卡，查看DNS服务器信息。

2、测试解析：

解析关键域名 使用nslookup 或dig (Linux) /nslookup (Windows) 命令测试监控机需要访问的核心域名：

        nslookup your-internal-database.company.com  # 测试内网重要地址
        nslookup ntp.aliyun.com                     # 测试外部NTP地址
        nslookup zabbix-server.yourcompany.local     # 测试监控平台地址
        dig +short time.google.com @223.5.5.5        # 使用特定DNS测试

测试反向解析 (可选但重要) 某些严格的监控项或服务依赖反向解析，使用nslookup <监控机IP> 检查是否能正确解析回主机名。

3、测试连通性： 使用ping 或telnet/nc 测试解析出来的IP地址的连通性（特别是端口，如NTP的123端口，数据库端口，监控服务端口）。

四、 最佳实践与避坑指南

明确记录 详细记录每台监控机使用的DNS服务器地址及其用途（主/备），纳入配置管理数据库(CMDB)。

隔离与专用 如果条件允许，考虑为监控网络或监控机配置专用的DNS解析策略，提高安全性和优先级。

监控DNS自身极其重要！ 务必监控你使用的主备DNS服务器的可用性和解析延迟（监控其IP的ICMP连通性，或使用dig监控特定域名的解析时间和结果），监控机DNS挂了，监控也就基本"瞎"了。

警惕DHCP覆盖 确保监控机的网络配置（尤其是Linux）不会被DHCP服务覆盖手动设置的DNS，留意/etc/resolv.conf中的提示或使用PEERDNS=no、ignore-auto-dns等配置。

注意域名TTL 了解监控相关域名的TTL值，过长的TTL在IP变更时会导致监控机长时间无法连接，必要时可在监控机本地hosts文件做临时覆盖（谨慎使用，需严格管理）。

防火墙规则 确保监控机防火墙(UDP/TCP 53端口)允许出站访问配置的DNS服务器IP，确保DNS服务器的防火墙允许监控机IP的入站查询请求。

定期复查 DNS环境并非一成不变，定期检查配置的有效性和DNS服务器的性能。

个人观点：

十几年运维踩坑经验告诉我，监控系统的可靠性是"木桶理论"的极致体现，任何一个环节的脆弱都会让整体形同虚设，DNS就是这个木桶上最容易被忽视却极其致命的一块短板，它无声无息，一旦出问题，监控数据中断、告警静默，你却在想"一切正常"，把监控机的DNS配置当作核心基础设施来对待，投入精力选择可靠的服务商、设计容灾方案、实施严格监控，这绝非小题大做，当真正的故障降临时，一个稳定解析的DNS，可能就是帮你快速定位问题、减少业务损失的关键所在，别让监控成了"灯下黑"，稳固DNS，就是加固了监控的根基。

文章摘自：https://idc.huochengrm.cn/dns/9076.html