现代综合管廊安全监控报警管理实践与优化

王金锋

（上海电科智能系统股份有限公司）

1 前言

在综合管廊集成监控平台运营中，系统实时或定期采集管廊廊体安全、气体环境安全以及入廊管线运营、风机水泵设备等安全指标。一旦相应的指标出现异常或达到报警阈值，系统会发起实时报警事件。但是在上海滴水湖北岛7km的管廊工程实际运营管理中，运维工程师们白天平均12min就会接收一次短信报警，在夜间则是平均18min一次，而实际数据统计发现，有效短信报警占比不到15%。因此短信报警的冗余度是相当高的，已经造成了报警风暴。

报警是为了预防事故发生、发现问题根源，发展和蔓延。一旦形成报警风暴，运维值班人员必将迷失在报警信息的海洋了，从而可能延误对异常根源的排查和判定，错失事故处理的最佳时机，影响管廊运行安全，甚至酿成更大的生产管理事故。

2 报警风暴形成的原因

2.1 报警重复度高

首先报警策略执行按周期计算，因此会持续产生重复报警，部分策略甚至会导致持续报警达1h以上。更严重的情形是，一次故障可能引发多个相关策略报警。比如一个防火分区出现有毒气体，本防火区首先报警，然后实例层面报警，随着空气流通，接着紧邻的防火区也会报警。

2.2 报警关注度不足

报警关注度是指接到报警信息后相应人员的及时处理动作——把报警发送后有实际处理的比例作为报警关注度的度量指标，发现实际关注度并不高，而在夜间短信报警关注率则低至25%。但事实上夜间短信报警的级别一般都是比较高的。这就意味着很多报警策略的发送方式和实际的报警等级已经相违背了。这是因为报警的关注度随着业务发展发生变化，但是这些关注度的变化没有及时的在报警系统中修改，导致已经变得不那么重要紧急的报警，却还在以短信的形式给值班工程师发送报警。

2.3 报警接收人冗余

每个报警策略平均有3个接收人，部分报警甚至超过了7个。报警策略的接收人往往会填写了运维团队中的所有人，但实际值班人只有一个人，大家按周期轮转。因此，对于一个特定的报警，大部分在列人员是不需要即时关注的。

2.4 报警有效性不足

超过88%以上的报警都是单实例报警，40%以上只需要简单的处理即可恢复，比如平台本身磁盘打满或者内存泄露等。因此我们在运维系统中增加了自愈机制，自愈成功后，只需记录报警日志即可。

3 报警信息管理优化

3.1 报警合并策略

报警合并对很多做监控系统常用的优化措施，相关文献都提到了这个过程，但大多数提及的报警合并都是将某个时间窗口内的报警简单的合并成为一条，此举对削减报警数量固然有效，但不利于值班工程师进行故障诊断。我们希望把若干描述同一故障的报警合并在一起，让值班工程师可以快速捕捉到故障本质，甚至故障根因，而并非一味的削减报警量。

最简单的报警合并方法可以基于报警策略的自然属性，包含策略名或者部署维度等。当合并的内容过多时，将最主要的报警或者报警的总结汇总到短信内容里面，具体的每一条细节报警、报警起始结束时间、报警持续时间、报警配置内容等细节信息都会在短链的页面中展示。

3.2 报警合并的机制

一个报警产生以后，我们先把这个报警插入一个发送等待队列而非立即发送。报警产生后先插入等待队列里面去，在队列里等进行延迟计时，当达到了能够容忍的延迟时间以后，我们在等待队列中找到可以和该报警一起合并发送的报警，根据实际的合并维度渲染成不同的报警短信内容，然后合并成一条报警短信发送。

3.3 关联策略的报警合并

某个模块的出现问题，往往会引发上游或者下游模块也一并报警。假设模块A调用了模块B，当模块B出现问题的时候，很显然模块A和模块B都会产生报警。

历史上每次B模块出现同样的问题的时候都会导致A模块有类似的报警，换言之，若历史上A模块的策略rule1和B模块的rule2经常同时报警，那么A模块的策略rule1和B模块的策略rule2就可能存在关联。因此我们可以挖掘历史报警数据中的关联关系，即关联的报警策略列表。

使用常见关联分析算法挖掘频繁项集（历史上经常在一起出现的报警策略）和关联规则（报警策略之间存在很强的关系）。下面定义报警策略的频繁出现或是否存在关联：一个项集的支持度计数被定义为该项集出现的次数，区别于传统的支持度是因为历史报警数据产生的数据往往较多，而实际项集数据出现的比较稀疏，意味着支持度的分母巨大，分子却很小。

置信度是针对一条关联规则X：rulem→Y：rulen而言定义的，代表了X：rulem导致Y：rulen发生的可能的概率。

支持度计数S_count(X：rulem)=以X：rulem开头的transaction的数量

支 持 度 计 数S_count(X：rulem →Y：rulen)=以X：rulem开头，并且包含Y：rulen的transaction的数量置信度c（X→Y）计算公式如下：

支持度和置信度超过一定数值即为所需的关联规则。按照这样的规则，在等待发送队列中，当某个报警发送时在报警策略关联表中查找等待队列中如果包含合并策略，就合并成一条报警信息发送。

3.4 报警关注度

报警关注度是指报警发送后有实际处理的比例，但系统运维一段时间后都会发现部分报警的关注度远低于100%，大多数情况下并非是值班工程师不尽责，而是部分报警策略随着系统的演化已经失效而又没有及时删除，因此需要我们能够识别无效报警。

一般地，值班工程师收到一条有效的短信报警后，会登录运维系统（包括监控系统、预案系统等）对报警进行定位、处理，这些行为会体现在各种运维系统的访问日志中。通过收集这些日志，就可以对每条报警的处理情况进行分析：如果在收到报警后的一段时间内访问过运维系统，可以认为该报警得到了关注，反之就认为该报警没有得到关注。汇总一段时间后，就能够筛选出关注度较低的报警策略，即为无效报警策略。

3.5 报警自愈机制

很多报警都有明确的处理预案，报警发生后，值班工程师登录机器或者中控机执行预案（脚本）就可以完成这类故障的处理。比如，清理磁盘这类操作，可以完全自动处理，无需人工干预，就能够大量节省人工成本，同时减少报警量。因此，监控报警系统提供了报警回调机制，在报警发生时可以回调预案处理脚本。

对于更复杂的场景，值班工程师往往需要根据服务的整体情况来调整预案。例如当某个实例异常需要重启的时候，需要综合判断其他实例的状态才能确定是否以及何时可以重启该实例，以免给其他服务造成损失。这种场景的自愈操作可能是有损的，需要对服务整体情况有一个判断才可以执行预案，监控报警系统为此提供了一种回调机制。在发生报警时，报警系统会把相关的报警策略、实例的状态都统一发送给一个中枢决策服务，由中枢决策服务统一做出判断。

4 结论

通过对现代综合管廊安全运营监测报警子系统的监测报警数据进行问题梳理，并有针对性的进行的信息优化处理。以科学合理的数据管理方式，准确判定数据异常，通过报警合并策略及报警分级，高效便捷的管理跟踪报警事件处理过程，避免管理过程中设备设施报警信息的报警风暴，为后续综合管廊监控运营优化提供参照，提升管廊管理水平。