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

在Serverfault上，我们通常告诉你，我们不能帮助你的容量规划。 这是有原因的：我们不知道你的环境的具体情况，关于如何衡量它的答案几乎是一样的。 不幸的是，DNS容量测量是一个很难理解的话题，大多数pipe理员会认为高CPU使用率意味着是时候考虑增加容量。 这是一个非常糟糕的主意，扩展到DNS DDoS将不可避免地导致networking设备窒息。 （或者更糟的是，有人向你的法律部门伸出援手）

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

除了跟踪由您的SNMP监视工具（包括CPU负载，每个接口吞吐量和数据包计数器，磁盘I / O等）提供的默认系统统计数据之外，我还build议添加以下OID：

• UDP-MIB
  • 接收队列错误： udpInErrors （强烈build议生气的红色）
  • UDP数据报计数器： udpInDatagrams ， udpOutDatagrams
  • （可选） 意外的数据报： udpNoPorts
• TCP-MIB
  • TCP段计数器： tcpInSegs ， tcpOutSegs

解释图表

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

指标

• 高CPU利用率是不好的。 这是一个给定的，但是当它发生时，你需要寻找其他的指标来关联它。 如果高CPU利用率映射到出站networking利用率（吞吐量或数据包数量）的峰值，那么在DDoS攻击中使用这些机会相当不错。 关于如何解释攻击性质的具体内容在下面的部分。
• udpInErrors是容量问题的主要标志。 每次内核丢弃UDP数据报时，该计数器都会递增，因为应用程序处理stream量不够快。 这意味着您的DNS服务过载，无法跟上传入的stream量。
  • 大多数networking性能指南会告诉你，增加接收队列的大小并不是正确的解决scheme：它们通常是正确的。 尝试通过查看其他图表或分析日志来find解释服务器过载的原因。
  • 如果您的公司运行使用DNSBL表的邮件服务器，请记住， snowshoe攻击可能会在合法的 DNSstream量中产生短暂的尖峰，从而导致接收队列中的空间耗尽。 在这种情况下，增加套接字接收队列的大小是值得的（因为这是一个已知的临时条件），但通常最好是抛出更多的硬件来减less延迟。

如果您无法将这些指标的增长与系统上的其他性能问题相关联，则恭喜您：您正在接近/超过容量，是时候添加服务器了。 考虑我印象深刻。 🙂

诊断

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

• 在繁忙的recursion服务器上，出站吞吐量应该保持在您的input的2倍左右。 这是因为回复通常比关联的查询大得多。 持续高于此级别的尖峰表明您的服务器正在参与放大攻击 。 你最有可能运行一个开放的parsing器 。
• 即使在recursionDNS服务器上，数据包也应该大致等于数据包输出。 虽然由于超时会偶尔需要重传查询，但这种情况不会经常发生，因此会导致严重的graphics歪斜。 输出数据包的显着增加表明networking问题，或者您的群集正在用于针对权威域名服务器的攻击。 这并不一定build议您使用开放的parsing程序：其他DNS服务器可能会向您转发无法caching的查询。
• 除了每个接口图，我build议绘制UDP + TCP I / O似乎是多余的，但是这些图不是与接口绑定的，也让您深入了解正在进行的攻击的本质。你的名字服务器软件。

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

对于DNS服务器（实际上是任何types的服务器），有时您需要查看和分析正在进行的请求，以防错误configuration（可能在其他地方）放大请求量（例如，请参阅Windows DNS服务器重复请求区域中的logging当他们得到SERVFAIL响应 ）。 查看查询和响应的比例，然后尝试find比较器来检查正常性。