如何了解 DNS 服务器上的 CPU 使用情况？

Question

我已阅读并理解您能否帮助我进行容量规划？，但我不确定我是否了解 DNS 服务器方案中的下一步。我认为我的 CPU 负载很高，或者我可能开始放弃查询，但我想在对它采取行动之前更好地了解我的服务器的负载。这对我来说尤其重要，因为众所周知，将基础设施扩展到 DDoS 负载正在失败。

为了了解我的环境，我应该分析什么？

Answer 1

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

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

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

• UDP-MIB
  • 接收队列错误：（ udpInErrors强烈推荐愤怒红色）
  • UDP 数据报计数器： udpInDatagrams ,udpOutDatagrams
  • （可选）意外数据报： udpNoPorts
• 管理信息库
  • 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'！）