3 分钟评估 你的运维监控系统是“救命稻草”还是“鸡肋”

摘要：如何提升企业运维监控能力，让我们先从监控成熟度评估开始吧。从运维监控到服务观测，3 分钟，5 个维度，快速获悉企业的 IT 资源监控现状。

IT 运维监控，是⼀个被持续关注了多年的话题。⻓期以来，IT 运维⼈员⼀直寄希望于运维监控系统可以“⽐⽤户和领导先发现业务应⽤系统问题”，希望运维监控系统具备“未⼘先知”能⼒，希望运维监控系统在出现问题时，可以“直达要害”地告诉运维⼈员是什么原因导致了业务应⽤系统出现了问题...

但⾮常遗憾的是，花⼤价钱采购的商业版运维监控系统，并没有做到“⽐⽤户和领导先发现问题”，⽽且⼤型商业版运维监控系统本身的运⾏和维护⼯作量却很⼤，资源消耗也⽐较“感⼈”；各式各样技术和理念领先的开源运维监控⼯具和⽅案，也没有真正“未⼘先知”的能⼒，排查问题时，还是要去各个运维监控系统中“翻江倒海”的寻找“蛛丝⻢迹”，⽽且开源系统也不是免费的午餐，在各种“踩坑”和“试错”过程中艰难的前⾏...

运维监控系统，是“救命稻草”还是“鸡肋”？除了运维监控，我们是否还有更好⼿段或⽅案来为业务应⽤系统的稳定可靠运⾏保驾护航？传统的运维监控系统是否能适应⾼速迭代的 IT 技术栈？

针对上述问题，我们从“现状”⼊⼿来进⾏逐⼀剖析：

我们⽬前的 IT 运维监控做的怎么样？存在哪些缺失和不⾜？是否可以满⾜企业数字化业务对于稳定可靠运⾏的需求（MTTR，SLA 等）？

通常，我们从⼀下五个⽅⾯对 IT 资源监控能⼒（成熟度）进⾏评估：

IT 资源监控数据采集

IT 资源监控数据处理和存储

IT 资源监控指标体系

IT 资源监控告警和事件处理

IT 资源监控事件分析和故障定位

一、数据采集

数据采集能⼒是 IT 资源监控的核⼼能⼒之⼀，主要从数据采集⽅式、数据采集协议、数据采集内容（范围）三个⽅⾯来进⾏评估。

数据采集⽅式：通常包含有 Agent 和⽆Agent 两种。传统的运维监控⼯具都有⾃⼰专属的数据采集 Agent，⽬前业界尚没有统⼀的运维监控 Agent 标准或协议规范，因此如果同时采⽤多个不同的监控系统，则会出现同⼀台主机上部署多个运维监控 Agent 的问题；⽆Agent 数据采集⽅式通常⽤于从⽹络设备、存储设备、安全设备等 IT 硬件资源中采集运维监控数据，常⻅的⽆Agent 数据采集协议有 SNMP、IPMI 和 SMI-S 等。除了常⻅的时序型指标数据，⽇志也是运维监控数据采集的⽬标。

二、数据处理和存储

随着 IT 资源规模的不断扩⼤，被监控对象和每个被监控对象上的监控指标数量也会急剧增加。传统的运维监控系统通常使⽤⾯向过程的数据处理⽅式，数据最终落盘到关系型数据库中。当监控数据⽇增量超过 50GB 时，由于数据处理过程和数据存储的限制（低成本横向扩展困难），只能压缩监控数据的存储周期，即便如此，在进⾏监控数据分析或者故障定位数据查询时，依然会⾯临查询效率低下，甚⾄会造成整个监控系统“卡顿”。

监控数据也是企业重要的数字化资产之⼀，其中同样蕴藏着的巨⼤的业务价值。通过对历史监控数据进⾏分析和挖掘，可以为更多的智能⾼阶应⽤场景提供⽀撑，例如：容量规划、异常检测、根因分析、⽤户体验分析、业务流程分析等。

三、指标体系

对于 IT 资源监控来说，并⾮监控的指标越多越好。不同的业务应⽤系统也有其不同的特质。在实施运维监控系统的过程中，也不可以⼀概⽽论，需要针对不同的业务应⽤系统，不同⽣产运⾏环境，不同的场景进⾏差异化监控。

每个业务应⽤系统，以及⽀撑业务应⽤系统运⾏所需的 IT 资源，都会有数⼗个甚⾄数百上千个监控指标，但是能表明业务应⽤系统是否在正常运⾏（处于健康态）的指标，不会超过 5 个，即：⻩⾦指标。⻩⾦指标中所包含的指标，⾄少有⼀个是与业务密切相关的（业务指标），例如：交易量、订单量、xx 事务错误率等。当某个业务指标出现异常时，即便其他与之相关的技术指标都处于正常状态，那么依然意味着此业务应⽤系统已经出现了问题。

监控指标不是平⾯的列表，每个监控指标，都需要有清晰的定义，例如：指标的含义是什么，数据是从哪⾥采集的，指标如何被聚合/计算等。

四、告警和事件处理

“告警⻛暴”，⼀个在传统运维监控系统中常⻅的名词，太多的告警消息对运维⼈员来说相当于“狼来了”，导致的后果就是对运维⼈员对告警消息“⽆动于衷”，或者⼲脆关闭⼤部分的告警消息以得“⽿根清净”。即便运维⼈员对所有的告警消息都保持“⾼度警惕”，认真的去阅读和查看每⼀条告警消息，这样真的就能从“简单明了”的告警消息内容中解读出关键信息吗？

当有告警消息产⽣时，监控的告警组件应该根据 CMDB 或者其他 IT 资源图谱系统中的数据对告警消息内容进⾏“丰富”，以此告知运维⼈员与这条告警消息相关的更多有价值的信息，例如：哪个业务应⽤系统的哪个集群的哪台服务器出现了故障。

如果部署了多个运维监控系统对同⼀组 IT 资源进⾏不同视⻆和维度的监控，那么当某个 IT 资源出现问题⽽触发多个运维监控系统告警时，这些来⾃多个运维监控系统的告警消息应该被根据 IT 资源拓扑或者预制的规则进⾏“收敛”。

五、事件分析和故障定位

监控告警和告警事件不仅仅是要告诉 IT 运维⼈员“发⽣了什么”，还要告诉 IT 运维⼈员“是什么原因导致发⽣了什么问题”，“当前发⽣的问题对哪个业务应⽤系统造成了什么样的影响”。以监控告警事件为“⼊⼝”，开展针对特定事件的分析和故障定位，以此有效提升 MTTI 和 MTTK（故障发现和故障定位）。

在排查问题的过程中，充分利⽤遵循 OpenTelemetry 规范的调⽤链/业务追踪数据（⽇志），从“全链路追踪”和“数字化业务客户旅程”层⾯，实现更加精准⾼效的故障定位。

为了确保事件分析和故障定位效率，现代化的运维监控系统需要具备统⼀的、跨多数据源的秒级（即席）监控数据查询分析和可视化功能。

更多 IT 资源监控成熟度评估相关的内容，请⾄优维官⽹了解更多信息并联系我们的咨询顾问进⾏深层技术交流。