我已经阅读和理解你能帮我做我的能力计划吗? ,但我不确定我是否明白在DNS服务器scheme中我的下一步是什么。 我认为我的CPU负载很高,或者我可能会开始删除查询,但我想更好地了解我的服务器的负载,然后我采取行动。 这对我来说尤其重要,因为众所周知,将基础架构扩展到DDoS负载正在失去战斗力。
我应该怎样分析才能了解我的环境?
在Serverfault上,我们通常告诉你,我们不能帮助你的容量规划。 这是有原因的:我们不知道你的环境的具体情况,关于如何衡量它的答案几乎是一样的。 不幸的是,DNS容量测量是一个很难理解的话题,大多数pipe理员会认为高CPU使用率意味着是时候考虑增加容量。 这是一个非常糟糕的主意,扩展到DNS DDoS将不可避免地导致networking设备窒息。 (或者更糟的是,有人向你的法律部门伸出援手)
服务器日志和数据包捕获是大多数pipe理员首先尝试利用的,但简单的事实是,SNMP可以告诉你有关环境的更多信息。 不要忽视日志和数据包捕获,但SNMP通常可以帮助您更快地发现问题的存在。
除了跟踪由您的SNMP监视工具(包括CPU负载,每个接口吞吐量和数据包计数器,磁盘I / O等)提供的默认系统统计数据之外,我还build议添加以下OID:
udpInErrors
(强烈build议生气的红色) udpInDatagrams
, udpOutDatagrams
udpNoPorts
tcpInSegs
, tcpOutSegs
这些图可以分为两类:指示问题的度量标准和帮助您诊断问题的度量标准。
指标
udpInErrors
是容量问题的主要标志。 每次内核丢弃UDP数据报时,该计数器都会递增,因为应用程序处理stream量不够快。 这意味着您的DNS服务过载,无法跟上传入的stream量。
如果您无法将这些指标的增长与系统上的其他性能问题相关联,则恭喜您:您正在接近/超过容量,是时候添加服务器了。 考虑我印象深刻。 🙂
诊断
这仅涵盖DNS特定项目。 在这里用你的头,不要指望这是包罗万象的。 (例如:磁盘I / O饱和不是特定于DNS的问题)
附注: udpNoPorts
不是一个真正的容量指标,但对识别caching中毒尝试很有用。 每当在一个意外的端口上看到一个UDP数据包时,这个计数器就会增加,并且在正常操作期间持续的这些数据包可能表明有人试图伪造一个回复。 (或者,或者你的一个听众没有运行:把它重新打开!)
对于DNS服务器(实际上是任何types的服务器),有时您需要查看和分析正在进行的请求,以防错误configuration(可能在其他地方)放大请求量(例如,请参阅Windows DNS服务器重复请求区域中的logging当他们得到SERVFAIL响应 )。 查看查询和响应的比例,然后尝试find比较器来检查正常性。