如何了解我在 DNS 服务器上的 CPU 使用率？

在 Serverfault 上，我们通常会告诉您，我们无法帮助您进行容量规划。这是有充分理由的：我们不知道您的环境的具体情况，而关于如何衡量它的答案几乎相同。不幸的是，DNS 容量测量是一个鲜为人知的话题，大多数管理员会认为高 CPU 使用率意味着是时候考虑增加容量了。这是一个非常非常糟糕的主意，并且扩展到 DNS DDoS 将不可避免地导致您的网络设备阻塞。（或者更糟糕的是，人们联系您的法律部门）

大多数管理员首先会尝试利用服务器日志和数据包捕获，但简单的事实是 SNMP 可以告诉您的环境信息远多于日志的功能。不要忽略日志和数据包捕获，但 SNMP 通常可以帮助您更快地发现问题的存在。

除了跟踪 SNMP 监控工具提供的默认系统统计信息（应包括 CPU 负载、每个接口的吞吐量和数据包计数器、磁盘 I/O 等），我建议添加以下 OID：

• UDP-MIB
  • 接收队列错误：（ udpInErrors强烈推荐愤怒的红色）
  • UDP 数据报计数器： udpInDatagrams ,udpOutDatagrams
  • （可选）意外数据报： udpNoPorts
• TCP-MIB
  • TCP 段计数器： tcpInSegs ,tcpOutSegs

解释图表

这些图表可以分为两类：指示问题的指标和帮助您诊断问题的指标。

指标

• CPU 利用率高是不好的。这是给定的，但是当它发生时，您需要寻找其他指标来关联它。如果高 CPU 利用率映射到出站网络利用率（吞吐量或数据包数量）的峰值，那么您很有可能被用于 DDoS 攻击。关于如何解释攻击性质的细节在下一节中。
• udpInErrors是容量问题的主要迹象。每次内核丢弃 UDP 数据报时，此计数器都会增加，因为应用程序处理流量的速度不够快。这意味着您的 DNS 服务已超载，无法跟上传入的流量。
  • 大多数网络性能指南会告诉您增加接收队列的大小不是正确的解决方案：它们通常是正确的。尝试通过查看其他图表或分析日志来找到解释服务器过载的原因。
  • 如果您的公司运营使用 DNSBL 表的邮件服务器，请记住雪鞋攻击会在合法DNS 流量中造成短暂的峰值，从而耗尽您的接收队列中的空间。这是可能值得增加套接字接收队列大小的情况之一（因为这是一个已知的临时条件），但通常最好在问题上投入更多硬件以降低延迟。

如果您无法将这些指标的增加与系统上的其他性能问题相关联，那么恭喜：您合法地接近/超出容量，是时候添加服务器了。认为我印象深刻。:)

诊断

这仅涵盖 DNS 特定项目。在这里用你的头脑，不要指望这是包罗万象的。（例如：磁盘 I/O 饱和不是 DNS 特有的问题）

• 在繁忙的递归服务器上，出站吞吐量应保持在输入的 2 倍左右。这是因为回复通常比关联的查询大得多。显着高于此水平的持续峰值表明您的服务器正在参与放大攻击。您很可能正在运行一个开放式解析器。
• 输入的数据包应该大致等于输出的数据包，即使在递归 DNS 服务器上也是如此。虽然偶尔会因超时而需要重新传输查询，但这种情况不会经常发生，以至于会导致显着的图倾斜。传出数据包的显着增加表明存在网络问题，或者您的集群正被用于对权威名称服务器的攻击。这并不一定表明您正在运行一个开放的解析器：其他 DNS 服务器可能正在向您转发无法缓存的查询。
• 除了每个接口图之外，我建议绘制 UDP+TCP I/O 似乎是多余的，但是这些图不与接口绑定，并且当您有足够的经验时，还可以让您深入了解正在进行的攻击的性质您的名称服务器软件。

旁注：udpNoPorts并不是真正的容量指标，但它对于识别缓存中毒尝试很有用。每次在意外端口上看到 UDP 数据包时，此计数器都会增加，并且在正常操作期间持续存在这些数据包可能表明有人试图伪造回复。（要么那个，要么你的一个听众没有运行：把它重新打开 foo'！）

对于 DNS 服务器（实际上是任何类型的服务器），有时您需要查看和分析由它发出的请求，以防配置错误（可能在其他地方）放大请求量（例如，参见Windows DNS 服务器重复请求区域中的记录当他们得到 SERVFAIL 响应时）。查看查询和响应的比例，然后尝试找到一个比较器来检查是否正常。