楼主在使用腾讯云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)

然后特意对比了三者的收集差距，结果如下：

（所以在这个版本没出来前，每次都需要经过全部场景至少需要70s时间，这还是楼主清理了日志后的结果）

5、三个场景选择对比如下，可以看到0、1场景都是会进行日志收集，2场景则产出了纯文本记录（奇怪的是这里1、2场景的秒数竟然消耗相差无几）：

6、仔细看了下三个场景的实现方式，脚本的场景实际上是通过标志位实现场景选择：

##定义执行模式，0为全部执行（默认），1为日志收集，2为精简收集
$selectvalue = 0

接着再通过简单的排序将模块进行排序，有序堆积，并将这个$selectvalue$ 值进行判断，如果数字越大则越轻量：

7、所以在场景的选择，完全没必要被一线工程师牵着鼻子走，完全可以根据自己的故障现象进行有限的收集，比如性能下降怀疑是进程级别问题，可以看到进程是通过以下语句进行收集的，会重定向到文本文件中，则不再需要直接收集日志文件（通常很大），直接选择场景2即可：

get-process -ErrorAction SilentlyContinue | select-object * | Fl | Out-File -Append ".\$Dirfilename\$Logfilename"

（所以文本级别的输出较为轻量，同时看到这个文本的输出位于场景2中）

今天主要解析了起始段、主体结构与场景选择方面的脚本，但我稍微整理下，发现有意思的是在主模块，竟然多达20多项，这20多项我将分为两篇（尽可能）来进行详细解析，希望通过对QCloud这个日志收集工具的解析，能够给予Windows Server运维工程师提供一些更加底层的排错思路。