运维支撑保障之监控管理体系建设

监控是为了实时或及时把握设备和系统的整体运行动态，提前、主动发现故障和隐患，缩短故障发现时间和解决时间，提高运维效率，是运维工作的主要内容之一。监控范围覆盖运维基础数据CMDB的全部对象的全生命周期，从底层数据中心机房到顶层应用系统和数据、从系统建设数据产生到系统注销数据归档，从基础信息、可用性、性能、容量以及安全等多个维度进行细粒度的实时监控，通过监控策略、数据分析等手段实现对故障问题的及时处理，通过数据挖掘、数据分析预判故障和建立故障自愈能力，进一步提高应用系统和数据的持续可用性。

监控平台、监控系统目前呈多样化、多平台的分布，如监控机房运行状态的机房环监系统、物理服务器自带监控页面、存储自带监控页面、网路设备自带监控页面、数据库监控平台、操作系统及应用监控平台、日志监控平台、应用性能APM监控、微服务链路监控等。同时基于开源监控平台也是百花齐放，如Zabbix、Prometheus、Open-falcon以及老牌的Nagios等。监控发现问题的告警形式也趋于多样，有传统的邮件告警到现在微信告警、语音电话告警以及监控中心的大屏展示等。同时基于监控历史数据分析和挖掘的智能监控实现故障问题的预判和自愈是监控未来发展的主流。

● 机房环监

机房环境监控系统主要对机房运行的整体环境进行监控，确保机房可以运行在一个健康的环境中正常运行，包括机房的温湿度、UPS电力、精密空调、消防、安防等内容。

图：某数据中心环监系统

● 物理机、存储及网络设备

采购的品牌物理机、存储设备以及存储等多自带管理界面，有简单的监控页面，如服务器的运行情况、网络设备的监控情况、网络负载、存储设备的容量、性能等内容。

图：某品牌服务器管理界面

图：某企业网络监控平台（某厂商自带）

图：某存储设备自带监控管理页面

● 日志监控

设备、应用系统、数据库等在运行过程中沉淀了大量日志，同时设备及系统运行如何也在日志中有直接的反馈，所以日志监控是监控的重要内容只用，常用的有开源的ELK平台和商业Splunk平台等。另外日志监控也有专业的SaaS服务厂商，如日志易等。

图：Splunk日志监控平台

● 应用性能管理及监控、微服务链路监控

随着应用系统服务化，应用系统除了正常性监控外，性能监控、链路监控已经成为监控的重点，通过APM、链路监控等工具可以很直观的观察应用系统运行的情况，并且了解整个服务调用的链路，当某一节点出现问题时，可以快速响应。常用的APM监控厂商有云智慧、听云、博睿、Dynatrace等，微服务的联络监控厂商也多有支持，开源的产品有skywalking等。

图：某厂商应用性能管理APM

图：链路监控skywalking

● 数据库监控

数据库监控主要聚焦数据库的运行状态，包括数据库服务器、数据库网络以及数据库自身的内容等。一般数据库产品厂商有自带的监控产品，但是大多只能监控自身的产品，如Oracle的EMCC，但是现在数据库呈现多样式，如Oracle、MySQL、Redis、MongoDB等，监控手段也有平台产品、脚本等内容。常使用的开源数据库监控产品有基于zabbix的插件产品、Lepus天兔等。

图：开源数据库监控产品Lepus

● 监控平台

完整统一的监控平台应该兼顾上述的机房、服务器、存储、网络等多方面的监控服务，并且能够沉淀历史数据、开展数据分析等功能。比较常见的开源监控平台有Zabbix、Prometheus、Nagios等，但是在实际上并不完善，不能够全面覆盖多维度，商业产品功能比较完善，但是多根据监控的点位收费，成本较高，所以对于中大型企业来说，统一的监控平台可根据自身需求进行开发或二次开发。

图：Zabbix监控平台

图：Prometheus监控平台

x.1 监控管理体系

基于监控平台、监控对象、监控策略、告警阈值等结合告警处理流程和应急预案建立企业自身监控管理体系，完善监控工作的闭环管理，从而实现监控的两个根本目的：一是故障问题的及时发现、及时处理，大幅多算故障时间；二是基于故障历史数据进行动态分析，实现问题隐患的预判和故障自愈。

图：监控管理体系及平台

监控管理体系围绕CMDB运维基础数据的全生命周期进行问题/故障的PDCA闭环管理，其作为运维保障体系的关键一环，与其他体系方案一道保障应用系统及数据的安全、稳定的运行。

● 监控对象

监控对象包括机房环境（UPS电力单元、空调单元、消防单元、安防单元等）、硬件设施设备（物理服务器、网络交换机、安全设备以及备品备件等）、操作系统OS级别、应用系统及服务、数据库、业务运行监控和日志等软硬件内容。

● 监控类别

监控的类别包括基础信息监控（物理位置、设备名称、设备属性、设备参数等）、可用性监控（正常与否、可用性指标等）、性能监控（计算性能、网络性能、IO等）、容量监控（可用空间、增长率等）以及安全等其他监控类别。

● 监控工具

监控工具包括开源或商业监控平台、自定义脚本、数据库数据监控等多工具的组合，部署的位置包括本地监控部署、云监控和第三方监控部署。其中不同的工具平台和脚本可以满足不同监控对象、不同监控类别的监控需求，以本地部署为主、云和第三方为辅的监控部署方式，可以有效规避单点故障，实现监控自身的持续可用性。

根据监控对象的规模，本地监控部署也以多集群部署的方式呈现，监控数据的存储有关系型数据库存储和时序数据库存储两种方式，对历史数据存储归档。

● 监控指标

监控体系最关键的部分在于不同监控对象的监控指标设计以及阈值的动态调整。同时这也是监控的难点之一，监控指标设计的完善度以及阈值设置的合理性是监控质量的根本影响因素。基于此出现的监控不准确和告警风暴是监控质量最常见的两个问题。

常见监控对象的监控指标有如下：

表：监控指标

● 阈值及告警

监控阈值的设置基于行业经验、历史数据以及监控对象自身的容量、性能等能力进行综合评估。告警阈值的设置有固定，也有动态调整的，常见的固定的阈值有：是否正常运行1正常0故障、内存使用率超过90%中的90%、存储使用率超过75%中的75%、CPU使用率超过50%中的50%、数据库连接数的75%中的75%、防火墙连接数的60%中的60%、CPU/主板温度60℃中的60等等，常见的需要根据实际情况动态调整的指标阈值有：CPU负载超过1.5、硬盘读写IO超过3000、网络丢包率达到千分之1、存储增长率达到100%、网络流程达到1G、业务增长率达到300%等等。

动态调整的阈值多根据实际运行情况进行合理的调整，目的在于使得监控更加准确的同时降低误报率，这在监控的日常工作中需要基于经验和实际情况结合历史数据进行分析和动态调整。实际上在建立监控体系或平台时，比较传统的做法会维护一张二维表格记录监控对象和阈值，但现在多在平台直接维护。监控的阈值为告警提供了触发条件，一旦超过阈值则触发告警，为了提高监控的准确有效性，设置科学合理的告警规则、告警分类分级、告警策略等至关重要。

告警规则泛指在告警平台配置的一条条告警策略，例如当存储使用达到75%时进行邮件告警，告警几次、间隔多久再次告警等则属于告警策略，规则与策略相配合，一般并无明显的界限。但是告警设置存在如下技巧：

（1）告警必须分类分级，包括待告警内容的分类分级、告警接收对象的分类分级，同时分类分级要与系统及数据的分类分级一致，并且可借鉴。

表：应用系统5级分类样例

表：不同类别的告警机制及处理措施

告警的分类分级可以集中力量解决核心关键问题，在现有资源配布情况下，最大化发挥运维团队的效力，保障应用系统及数据的持续可用性的最大化收益。

x.2 故障处理流程

故障处理流程包括从故障发现进行故障处理，包括如下几个阶段，每个阶段的处理要点可一并参考：

图：故障处理流程

（1）故障发现阶段。故障发现的渠道有监控平台的告警、业务部门的报故、巡检的异常以及其他渠道等，值班人员或相关工程师收到故障信息。

（2）故障确认阶段。收到故障信息后，首先需要对故障的现象、故障范围以及影响进行确认，可通过故障复现测试、业务现场询问和电话复问等多这种方式全面了解故障的最准确的情况，这还包括原因的初步判定、恢复方案的初步选择等。

（3）故障汇报阶段。故障汇报是整个故障处理流程中第一个最关键的环境，但很容易被工程师忽略。故障汇报采用逐级汇报模式，以便一线工程师可以更专注的处理问题，故障汇报至关重要，特别对于值班人员和一线工程师，切忌直接解决故障而忽略汇报事宜。通过汇报，可以让领导从全盘考虑统筹问题解决最优解。

（4）业务恢复阶段。故障发生后，首先要恢复业务使用，这包括现场技术支持辅助业务手动处理、按照工作手册和应急预案开展处理、采用IT备份手段或业务备份手段支持业务正常运行。同时业务恢复阶段联系系统负责人、业务负责人等多方人员共同保障业务的快速恢复。

（5）联合排故阶段。对于复杂故障未能快速定位故障原因的，可以组织各岗位专家工程师进行联合排故，包括部门内各领域技术专家、原厂专家以及合作伙伴等。从多方面、多维度排查处理复杂故障问题，以规避技术思维陷阱，旨在快速有效解决故障。

（6）故障恢复阶段。故障问题处理完成后应及时汇报业务部门并且进行再次确认，同时对故障影响以及故障处理过程进行复盘、分析和总结、固化成果。

每一次生产故障处理都是极其宝贵的经验财富，同时也是检验监控能力和运维能力的最直接、最有效的措施，例如：故障的通知是否通过预定方式爆出、故障从通知发出到响应的时间多久、应用系统或数据集群架构是否生效、临时恢复措施是否有效、应急手册是否切合实际等。同时对于故障解决后故障库的沉淀以及转化成知识库（处理手册等）是否完成，另外故障复盘还可以对监控指标、监控阈值等进行持续优化，形成的故障数据和处理规范可以充实到运维数据分析平台，进而实现对监控数据、监控状态的实时分析，实现对故障问题的提前预判和故障自动处理能力。这也是数字化转型构筑能力中心过程中支撑保障能力的重要部分之一。

x.3 实践问题分析

在监控实施过程中，面临着不少问题，虽上略有提及，但是从实践角度拿出来进行深入解读，进而可以提升监控能力和故障处理能力。

（1）监控平台/工具的选择

如上所述，监控平台、监控工具纷繁复杂，而且稍有一套大而全的监控管理平台，所以在实际过程中，多是几个平台的综合使用以及agent代理、自定义脚本等多工具结合。但是我们一定要选择最合适自己的一款监控平台作为主平台，如Zabbix，然后基于该平台去做响应的扩展，在不具备二次开发能力前，可以通过脚本的方式集成自定义监控到Zabbix上。同时还有有整体化以及目标导向的思维，众多的工具平台只是为了更早的发现问题和更好的处理故障，我们要取各平台之所长，在具备能力之后进行统一监控平台的开发，当然也不宜投入过多经历。

（2）分类分级必须做

正如运维基础数据CMDB一样，告警必须做分类分级。根据优先级细化监控粒度、监控维度（如核心系统从操作系统到JVM内核全程监控、从本地监控到第三方监控），同时在大面积告警和故障时，也是处理问题顺序的根本依据。实际过程中在出现大面积、多系统多环节故障时，很容易焦头乱额，缺乏优先级的思维，很容易被引导一会处理这个问题一会处理那个问题，找不到问题本质，影响问题处理时间。

（3）告警通知、告警风暴与告警疲劳

告警通知的方式有多种，包括邮件、短信、语音电话以及微信等，实际操作过程应依据通知方式的特点结合告警的优先级进行配置，避免标准、统一式告警。如：基础设施故障、核心系统故障类有通过语音电话和邮件/或其他两种方式结合告警，告警范围涵盖一线值班员、二线专家工程师和三线领导等，对于空间不足等非紧急故障可以配置邮件告警一线值班员和负责人即可。同时告警间隔及频次也需要根据告警优先级设置，如核心生产系统故障5分钟告警一次，实际操作中也可以设置阶梯式告警，例如前3次告警通知至一线值班员，第4次开始升级通知人职级等。通过告警的分类分级以及阶梯式告警方式，可以一定程度上降低告警疲劳。另外告警的触发条件一定要具有逻辑性，特别是对于某一个故障点引起大面积故障的情况，原始故障告警很容易淹没在突增的告警风暴中，所以故障告警的根因分析以及故障告警逻辑也是重要内容之一，最起码不应出现公共基础类故障导致的其他故障告警也一并告出。

（4）故障库、知识库以及监控告警的闭环管理至关重要

对于监控告警爆出的故障一定要做闭环管理，同时完善故障库的积累，这是监控工作的基础也是故障处理的重要参考依据。基于故障库形成的故障处理方法、系统优化方案等都是知识库的组成部分，同时要注重监控数据的积累、挖掘与分析，实际上从告警阈值到实时监控到问题提前发现以及自动处理整个链条并不复杂，自动处理也是通过脚本或定制化的办法进行处理，不存在较大的技术壁垒。

综上，监控管理体系的建设整体以运维基础数据CMDB为基础，贯彻分类、分级的思维综合运用各种平台、工具，通过多样化的告警方式、清晰明确的问题处理机制，提早发现问题及故障隐患，快速有效地解决已出现的问题，同时凭借故障库、知识库以及监控数据积累和常见问题处理方案形成监控问题的自动化处理，完成故障自愈功能，进而从监控侧提升运维支撑保障能力，促成数字化转型的平稳推进。