监控工作的教训 一

在上一份工作离职前的最后几个月里，我承担了团队内部的系统的监控工作，监控范围主要包含1个SAP CRM系统，1个基于SQL Server的查询系统，以及2个Dynamics CRM系统。

基本上，在SAP CRM和SQL Server系统的监控工作还算良好，一些监控可以及时发现系统中存在的不一致现象，并确定其范围，减轻了运维负担。但Dynamics系统的监控堪称失败，出现了包括没有及时检测出问题、误告警、开了多次低效会议等等。可以说不仅没有提高运维效率，反倒是让相关人付出了不必要的时间成本，让我颇感惭愧。本文记录了对失败监控的一些反思，随想随写，也许并不全面。

我们做了什么

失败的监控可以分为黑盒和白盒2个部分。

黑盒监控的内容是，通过分布在全球各地区的一些实体测试计算机，运行EasyRepro测试脚本，访问Dynamics系统，并模拟一些业务操作，将记录的信息发送给Splunk。Splunk根据设定的告警条件对异常情况发出告警邮件。

白盒监控的内容是，通过Azure收集系统信息，并通过Azure自带的工具分析和发出告警。

然而这两方面的监控都产生了一些问题，下面一一分析。

 

本文链接：https://www.cnblogs.com/hhelibeb/p/14153490.html

转载请注明

监控的目标问题

最初的监控目标非常简单，就是IT团队希望在系统不可用的时候能及时收到告警，在用户打热线之前先掌握情况，以避免过于被动。

我们试图通过黑盒测试来发现系统不可用的情况。但在开始阶段我们就犯了一个比较明显的错误：没有真正明确什么是“系统不可用”。

比如，测试脚本的开发人员根据自己的理解，认为每个步骤超过若干秒没有响应就说明该功能不可用。但现实当中的确会偶尔出现系统响应很慢的情况，这可能和客户端计算机的状态有关，也可能和服务器状态有关。重点在于，这种偶然出现的状况在大部分企业用户眼里不算很严重的问题。即便它是问题，也不应该触发需要IT立刻采取行动的告警，而是应该产生一个级别比较低的、可以让IT在接下来几天内响应和处理的事件。

所以，负责监控的人员必须明确监控的目标是什么、什么样的信息是需要相关人立刻做出反应的。如果在这种问题上产生模糊，就会导致误解和不必要的工作。

另外，在根据监控数据制作报表和Dashboard前，我们也没有充分和需求方交流，这导致做出了一些无用的东西，浪费了时间。

故障与自动检测/恢复的问题

黑盒测试的另一个尴尬问题是，测试计算机本身也可能出问题。而且由于测试计算机有多台，且分布在不同的地理区域、有着不同的软件和硬件环境，它们出现问题的概率远远大于被监控的系统出问题的概率。它们有时可能出现网络故障，有时可能遇到系统、浏览器自动更新，有时可能会产生配置错误。这些都可能导致测试失败。

而当监控手段比监控对象更加不可靠的时候，监控会变得无意义。

一开始，测试机器比较少，我们用人工的方式配置机器，并在监控出现问题时人工排查和解决。但随着测试机器的增多，我们逐渐疲于奔命，只好开始写脚本，来对这些机器做统一的配置。我想通过脚本对它们做自动化的配置是一个正确的思路，但还远远不够，而且做的太晚、太被动，导致我们付出了过多的劳动、遇到了多次假告警。正确的思路应该是在早期就通过脚本自动配置每台机器，而且测试机器必须有自我检查能力，可以自动的发现自身的异常并尝试修复。否则它们只会给人带来负担而不是收益。

监控的指标问题

理论上，监控系统有4个关键指标，分别是延迟、流量、错误和饱和度。

我们最早试图从延迟和错误来发现故障，忽略了其它指标，直到很晚的是时候才意识到这个缺失。比如单纯的延迟提高未必说明系统不可用，但延迟提高再加上流量急剧降低，很可能意味着系统已经不可用了。

饱和度有时也是一个容易被忽略的指标。

数据收集的问题

收集过多的监控数据可能会带来成本的提高和性能的下降，收集错误的数据可能会导致监控规则的复杂化和错误结果。我们注意到了前者，但没能及时意识到后者的重要性。

另外，多样的数据来源也许不是问题，但如果它们无法汇集到同一个平台，则可能出现问题。我们的一个比较失败的地方是把收集到的数据分散在Splunk和Azure两个平台上，这带来了一些问题，比如不能直接把2个平台的数据结合分析，比如不同的界面和查询语言导致了额外的学习成本和沟通成本。

 

参考资料：SRE