在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表的邮件服务器,请记住,snowshoe attacks可以在合法的DNS流量中创建短暂的峰值,这可能会耗尽接收队列中的空间.这是增加套接字接收队列大小可能值得的一种情况(因为它是一个已知的临时条件),但通常最好在问题上投入更多硬件以减少延迟.

如果您无法将这些指标的增加与系统上的其他性能问题相关联,那么祝贺：您合法地接近/超过容量并且是时候添加服务器了.考虑我印象深刻. 原文链接：https://www.f2er.com/html/229227.html