樓主在使用騰訊雲IaaS時，經常遇到一些疑似平台問題的Windows疑難雜症，通常會向騰訊雲工單送出OS工單，讓其專業工程師來排查，畢竟我買IaaS的CVM要來上線業務的，無暇來解決系統層面的問題。
但是不知道從什麼時候開始，提相關工單後，一線工程師了解初步問題後，如果是性能上或者配置上存在問題，會丢來一個日志配置收集工具的下載下傳位址：
http://mirrors.tencentyun.com/install/platform_ops/qcloud/QCloud_Windows_Status_Check_Script.zip
下載下傳後解壓出來的内容
在送出了N次收集内容後，偶爾有一次看了内容，發現收集的東西還是挺多的：
收集入門界面
是以，準備寫一系列的文章，用有限的知識來解析下這個所謂的windows狀态檢查腳本（雖然一線工程師稱其為日志配置收集工具，不過從這個“工具”的英文名直譯過來其實是個腳本）
1、右鍵對主腳本進行編輯，發現并沒有進行加密：
打開後的界面
2、分析了一波，發現這個工具其實分為四大部分：
渣畫圖表結構
3、在UI部分，可能是為了照顧入門使用者，采用了“小Q”作為旁白發聲者，同時采用日期時間+主機名的方式來命名收集目錄，這樣确實避免了多次收集時可能出現沖突的的問題：
Write-Host -ForegroundColor 10 "小Q：此腳本功能為收集系統運作日志用于故障定位，不會收集任何敏感資料和做任何操作，請您放心使用:-)"
write-host "———————————————————————————"
write-host "———————————————————————————"
write-host "———————————————————————————"
write-host "———————————————————————————"
write-host "———————————————————————————"
$filehostname = hostname
$filedatetmp = Get-Date
$filedate = $filedatetmp.ToString('MM-dd-hh-mm-ss')
$Logfilebx = "$filehostname-$filedate-Log"
$Logfilename = "TotalLog.txt"
$Dirfilename = $filedate + "QCloud-TS-$filehostname" 複制
建立後效果
4、從上圖看到有個“可選場景”，這個應該是最近才更新的特性，之前都是一把梭全收集，現在有了場景收集，時間上我給腳本加了收集秒數計算：
$startscptime = Get-Date
<QCloud_Windows_Status_Check_Script>
$endscptime = Get-Date
Write-Host -ForegroundColor Red ('Total Runtime: ' + ($endscptime - $startscptime).TotalSeconds) 複制
然後特意對比了三者的收集差距，結果如下：
| 場景名 | 消耗秒數 |
|---|---|
| 0（全部場景） | 70.129646 |
| 1（日志收集場景） | 40.190996 |
| 2（關鍵配置收集場景） | 40.180253 |
（是以在這個版本沒出來前，每次都需要經過全部場景至少需要70s時間，這還是樓主清理了日志後的結果）
5、三個場景選擇對比如下，可以看到0、1場景都是會進行日志收集，2場景則産出了純文字記錄（奇怪的是這裡1、2場景的秒數竟然消耗相差無幾）：
6、仔細看了下三個場景的實作方式，腳本的場景實際上是通過标志位實作場景選擇：
##定義執行模式，0為全部執行（預設），1為日志收集，2為精簡收集
$selectvalue = 0 複制
接着再通過簡單的排序将子產品進行排序，有序堆積，并将這個selectvalue 值進行判斷，如果數字越大則越輕量：
通過selectvalue值進行判斷
7、是以在場景的選擇，完全沒必要被一線工程師牽着鼻子走，完全可以根據自己的故障現象進行有限的收集，比如性能下降懷疑是程序級别問題，可以看到程序是通過以下語句進行收集的，會重定向到文本檔案中，則不再需要直接收集日志檔案（通常很大），直接選擇場景2即可：
get-process -ErrorAction SilentlyContinue | select-object * | Fl | Out-File -Append ".\$Dirfilename\$Logfilename" 複制
（是以文本級别的輸出較為輕量，同時看到這個文本的輸出位于場景2中）
今天主要解析了起始段、主體結構與場景選擇方面的腳本，但我稍微整理下，發現有意思的是在主子產品，竟然多達20多項，這20多項我将分為兩篇（盡可能）來進行詳細解析，希望通過對QCloud這個日志收集工具的解析，能夠給予Windows Server運維工程師提供一些更加底層的排錯思路。