监控系统运行过程中必然会产生各类告警,不过,有告警并不代表有生产事件,并不是每一条告警都需要人为介入处理。
那么什么是事件?ITIL中对事件的定义是会引起或可能引起服务中断、服务质量下降的任何活动,包括硬件故障、软件故障、投诉、服务请求等。不过在事件管理系统中事件的定义稍有不同:需要我们响应、处理、跟踪的事情都称为事件。
事件管理系统是监控体系中的重要组成部分,对外提供统一接口,以实现对外部系统事件的对接,事件的触发可能来自监控服务层的各个系统。为了能让来自不同监控系统、不同格式的告警事件,以尽可能直观的方式展示给监控运维团队,实现监控事件集中管理、聚合收敛、关联分析,事件管理系统要收集和汇总来自不同系统的各类事件。
一方面要对包括基础监控、业务监控、全链路监控等在内的各套监控系统的告警信息进行事件多维度分析,为实现事件的关联分析、应急处置策略、事件影响范围评估、故障预测等智能化分析提供数据支持,为故障自愈的实施提供支持;另一方面也要通过系统,对事件的发现、处置、定级、跟踪等进行流程化管控,通过对事件提供统一受理入口,解决IT运维团队多系统对接处理困境,提升事件响应效率。
为了简化事件的响应,对于不同的事件,要根据该事件的影响、关联分析,给予不同的处理方式。事件的关联分析是形成故障树,为后续实现故障自愈的基础条件。执行关联分析可以从纵向和横向两个维度展开。
所有资源都是有限的,监控运维资源更是如此。如果出现事件后一股脑儿地同步给监控运维团队,运维团队的同事要么四处救火,疲于奔命,但问题始终不断,处置了一堆系统告警,可发现只解决了鸡毛蒜皮的小问题,真正的严重问题始终没有彻底消除;要么事件处理完全依赖最有经验的有限人员,其他人员或者经验不足,或者能力不够,手忙脚乱。
事件管理系统关注事件的应急处置、关联分析等,明确事件的危险程度、影响范围和优先级。这部分工作做得越细致、越精确,最终流转到运维团队的维护工作量就越小。对于已知的事件,通过标准化的事件应急策略,不管谁来处理,处置的策略都是相同的,结果也一样,通过这种方式也变相实现了对事件响应的标准化,甚至会实现有限程度的故障自愈。
各类信息系统多了之后,告警也可能越来越多,别说介入,有可能看都看不过来。为了让关键监控事件得到及时处理,信息系统要做分级,告警同样也要进行分级,并且告警信息中要有紧急程度的明确标识,方便接收者快速分辨哪些告警需要更高优先级响应,哪些告警可以等待。对于低级别告警要设置升级条件,比如处理时间过长或者短时间内多次发生等,则要考虑升级,必须尽可能把需要人为关注或介入的信息及时展示给IT运维团队。
企业内的监控系统并不止一个,从展现角度看,不同的工具有不同的展示界面,有不同的关注点。多套运维系统不仅需要投入更多的人力关注,而且相互独立展现也造成缺乏对各类数据的汇总分析,不能全面反映系统整体运行状况。一个问题发生时,有可能多个监控维度都会有监控告警信息。比如一台物理机宕机,那么该物理机上的所有虚拟机监控都会出现告警,虚拟机上运行的应用系统、交易级业务监控、应用性能监控、客户体验监控等也都会出现异常告警事件。这时,如果监控自身的信息归集、告警去重、事件收敛等策略不完善,监控指标越丰富,触发的告警就会越多,反倒会给监控团队造成干扰,不利于快速定位问题根源。对于同一个故障触发多类指标告警,以及同一个指标在故障未解除前重复产生告警的事件,把这些事件都展示出来既无必要,更是一种信息骚扰,因此一定要对告警进行收敛分析。
告警事件的处理属于日常性事务,工作琐碎但又不能轻视,需要耐心、细致,当然,监控系统自身功能是否完备也很重要。举例来说,发生生产事件并触发了告警之后,哪些人接收、谁负责跟进、处理的情况如何同步、持续一段时间后事件仍未能消除时的事件升级机制等,都需要能够清晰展示。尽管所有优秀的理念或设计最终都是落在软件功能上,但功能实现只是增加代码量而已,真正优秀的系统关注的是监控整体过程和用户体验,帮助企业建立和优化监控告警事件的处置机制。