如何了解我在 DNS 伺服器上的 CPU 使用率？
我已閱讀並理解您能否幫助我進行容量規劃？，但我不確定我是否了解在 DNS 伺服器方案中我的下一步是什麼。我認為我的 CPU 負載很高，或者我可能開始放棄查詢，但我想在對伺服器採取行動之前更好地了解伺服器的負載。這對我來說尤其令人擔憂，因為眾所周知，將您的基礎架構擴展到 DDoS 負載正在輸掉戰鬥。
為了了解我的環境，我應該分析什麼？
在 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’！）