【解析向】腾讯云的Windows Server日志配置收集工具是个什么鬼?(1)

楼主在使用腾讯云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运维工程师提供一些更加底层的排错思路。


原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏华章科技

从 Python 转到 Go 语言的五大理由

“ Python 是非常强大的,特别是 Python3 有了异步功能,但是 GO 将完全取代它在大企业中的存在…”如果你真正理解了引号中的话,你可能会去尝试 G...

643
来自专栏TechBox

模块化与解耦简述4. 解耦与通信5. 源码推荐

1583
来自专栏EAWorld

微服务 to 变 or not to 变?

原著作者介绍: Viktor Farcic CloudBees资深顾问,熟悉多种编程语言,从最早的Pascal,Basic,ASP,C,C++,Perl,Py...

2797
来自专栏高性能服务器开发

9 百万用户级游戏服务器架构设计

所谓服务器结构,也就是如何将服务器各部分合理地安排,以实现最初的功能需求。所以,结构本无所谓正确与错误;当然,优秀的结构更有助于系统的搭建,对系统的可扩展性及可...

2185
来自专栏互联网高可用架构

如何设计一款多场景分布式发号器(Vesta)

2763
来自专栏Golang语言社区

再谈游戏服务器架构

一、服务器划分原则 在现有的网络游戏服务器端架构中,多是以功能和场景来划分服务器结构的。负载均衡和集群暂且不在本文中讨论(bigworld、atlas...

48613
来自专栏java一日一条

以生活例子说明单线程与多线程

在我看来单从程序的角度来看,一个好的程序的目标应该是性能与用户体验的平衡。当然一个程序是否能够满足用户的需求暂且不谈,这是业务层面的问题,我们仅仅讨论程序本身。...

813
来自专栏Java架构

高并发风控技术解密(下)

1433
来自专栏极客猴

高并发的那些事

"高并发"对后台开发同学来说,既熟悉又陌生。熟悉是因为面试和工作经常会提及它。陌生的原由是服务器因高并发导致出现各位问题的情况少之又少。同时,想收获这方面的经验...

1503
来自专栏鸿的学习笔记

聊聊分布式系统的时钟问题

诸如此类的问题,还能提出很多,因此需要一个靠谱的时钟来保证分布式系统里事件的处理不会出错。

741

扫码关注云+社区