該有的矜持---域控CPU長期飆60-80%問題源頭確認過程

背景：

很早就發現域控的CPU長期飆在60-80%之間，日誌服務是CPU佔用大頭，改小日誌的最大大小也沒有用，域控使用了paloalto和 SXF的單點登陸功能，因此我雖然肯定確定是兩個的其中一個，可是一直沒有實錘。

使用Stack Trace我只能確認是日誌查詢致使的

因爲日誌的查詢是經過WMI進行的，因此在找到一些WMI TRACE相關的信息後，我抓了一小段時間WMI TRACE爲ETL文件，而後使用windows message analyzer 把須要的字段提取出來，生成一個CSV，而後在EXCEL裏面進行查看。

1. 白色背景的查詢1，彷佛沒有太規則的規律，查詢間隔時間最小彷佛是1s,可是大的間隔也有5s ,2s左右居多。

select __RELPATH, InsertionStrings from Win32_NTLogEvent where ((Logfile = "security" AND (((EventCode = 672 OR EventCode = 4624) OR EventCode = 540) OR EventCode = 4768)) AND RecordNumber > 939574642)

2. (Yellow)色背景的查詢2 （唉，這博客的關鍵詞太優（cu）雅（fang)），查詢間隔大概是14-15s.

select __RELPATH, EventIdentifier, InsertionStrings, TimeGenerated from Win32_NTLogEvent where (((((((((EventIdentifier = 4624 OR EventIdentifier = 4768) OR EventIdentifier = 4769) OR EventIdentifier = 4770) OR EventIdentifier = 540) OR EventIdentifier = 672) OR EventIdentifier = 673) OR EventIdentifier = 674) AND LogFile = "Security") AND TimeGenerated >= "20190906013740.751000+000")

找到真兇

是的上面的查詢1，頻率很高，多是真兇，可是這個查詢是誰發出的呢？可否跟到IP地址？

使用netsh trace 進行抓包，使用Windows Message Analyzer進行分析，先篩選WMI，而後點中其中一條，點最前面的加號，一直跟到ip 模塊，而後把SourceAddress 顯示成列，把strquery 單獨顯示成一列，大體以下圖。真兇找到。

後記

覺得在網頁上把下面的設置禁用，刪除配置的域控列表，就能夠禁用日誌查詢了，結果抓包後不是這樣的，SXF 是堅持要幹活，AD的日誌查詢仍是一直在繼續，估計釜底抽薪的辦法，只能把SXF用的帳號給改個密碼或者把帳號禁用了。

我驗證了個人想法，而後發現確實有效，我只想說，作人真的要矜持。。。。。。。。。。。

禁用了SXF用的AD帳號一段後，又開啓後，DC的CPU表現圖以下：

附加下Palo Alto的查詢配置（可更改的）

第二週後，我獲取了補丁文件，按照原來的建議，把頻率改爲25s，不過是寫死在程序中的，這響應還算是快捷了（Tou）(Lan), 搞個配置文件，能夠修改頻率不行嗎？對比下palo,只能呵呵了.......

雖然不少嘆息，不過該高興的是，這個問題持續一年多終於解決了...

參考連接

network tracing using ETW

WMI Tracing