告警一响 运维上岗

前言

在《24*7动态化监管为“链”站岗》中，我们介绍了区块链动态化监控中心，如果说监控的作用是防患于未然，那么告警则是当异常发生时第一时间触发运维人员的关键，可充分降低监控对象异常的时间，最大化降低因异常给区块链业务带来的潜在业务损失。

区块链告警现存问题

当前，比较主流的BaaS平台告警系统实现方案往往基于 Prometheus+Grafana+AlertManager 来实现，由于是外接第三方平台，会存在以下问题：

• 缺乏业务事件告警：目前区块链告警主要是将节点作为一种资源进程监控，通过监控其资源使用情况，通常为节点运行的CPU、内存、磁盘空间等，这就不可避免地导致监控告警面狭窄，更为妥善的方式是增加链维度的监控，如链上异常账户、链上数据异常、链上共识异常等业务类监控，实现从物理和业务等多维全面判断区块链是否发生异常，否则运维人员很难定位异常；

• 非区块链原生告警：目前针对区块链的监控告警，通常是在节点所在主机安装采集器，用于定时采集单个节点的资源类监控指标，再通过第三方监控系统，如prometheus。以上模式，不可避免地需要将节点自身进程数据和链上数据导出至第三方系统，再进行告警，一旦脱离区块链系统，数据就容易被篡改，且现在往往都是对单节点进行告警，会存在因单节点故障而存在错误告警或者不同节点的监控结果不一致等问题，导致整个告警系统的可信度降低；

• 业务告警无法灵活对接异构链：针对区块链业务告警，往往需要先根据不同的区块链底层，在应用端根据业务诉求提前写好告警逻辑，这些逻辑往往是写死的，一旦业务发生变更，整个业务告警逻辑都需要变更，造成监控系统维护难度大；

• 告警质量低：在实际运行中，会出现该告警时不告警，不该告警却告警，或者告警频繁轰炸等问题。例如，当区块链网络之间出现故障时，每个节点都有可能出现接收不到其他节点信息的状况，此时每个节点都会发生很多链上异常事件，这就会导致已配置好告警规则的相关服务给每个节点频繁发送告警。

如何解决区块链告警问题

全新的区块链告警系统

区块链告警系统支持用户根据业务诉求动态化配置告警规则，基于区块链的内置审计合约、链上KVSQL和采集器等能力的有机组合，通过周期性的触发活动来检查监控对象（链或节点）是否存在异常，一旦检测到异常后会将告警活动上报给告警管理模块，告警模块会根据相关配置及当前的告警状态决定如何处理相应的告警（如分组、过滤、抑制等），以及通知方式（如短信、邮件、钉钉等方式）。用户即可在第一时间获知区块链上存在的异常事件，如“节点被攻击”、“双花问题”、“异常账户”、“分叉”等，减少业务损失。

整体架构

◆告警规则管理

支持自定义创建告警规则，支持相关规则配置，如查询分析的对象（时序数据库、合约文件、链上KVSQL等）、查询分析的语句、以及一些自定义配置（检查时间、持续时间）等配置项。更进一步地，创建规则的方式主要有3种：

• 静态阈值：该方式提供了系统预设的告警指标，通过选择已有的告警指标，可通过语义化的方式快速创建对应指标项的告警规则。如针对指标“节点cpu占用率”，只需要选择具体的告警对象、cpu占用率的阈值和通知方式，即可快速创建告警；

• 自定义查询语句：如上一篇文字中介绍的动态化监控平台，该模式集成了prometheus采集端服务以及链上kvsql服务，因此支持通过自定义查询语句（promQL和SQL）设置告警规则表达式。例如：

# promQL# 遍历链上所有节点，存在节点CPU占用率超过80%就告警node_cpu_usage_percent{chain_id="$chain_id”}>0.8# KVSQL# 查询合约调用记录表（contract_invoke_record）中合约地址为“0x6f31381d45bc061045ca27327905cce0b562f405”的账户数，大于100就告警（账户在批量创建）select count(*)>100 as result from contract_invoke_record  where contract_addrress =”0x6f31381d45bc061045ca27327905cce0b562f405”

• 合约告警事件：用户可以上传审计合约，在审计合约中，可通过event事件便捷地使用合约引擎的日志基础功能，在合约的执行过程中，合约引擎会将事件推送给客户端，订阅了相关事件类型的客户端即可接收到该事件消息。

◆告警活动管理

告警活动管理模块主要负责告警质量和告警状态流转管理，其中告警质量管理主要是通过对任意告警源上报的告警活动去重、压缩、降噪和静默，实现告警的收敛，减少告警轰炸的产生。

• 告警活动去重：告警活动的数据结构主要包括告警元数据、告警活动开始时间和结束时间，其中告警元数据是由一组标签组成的，唯一标识一个活动，标签相同则认为是同一个活动，重复上报会进行合并；标签不同则产生新的告警活动。例如，

「

{"resource_type":"node","resource_id":"NODE-6sw23e", "alertname":"CPU使用率过高"}这组标签代表一个告警活动——节点ID为"NODE-6sw23e"的CPU使用率过高{"resource_type":"node","resource_id":"NODE-8qw23e", "alertname":"CPU使用率过高"}

」

当其中一个标签发生变化，如节点ID变化将产生新的告警活动。相同的告警活动，会累计计数，不触发告警通知，减少告警通知轰炸。

• 告警活动静默：告警活动管理模块根据静默规则，直接忽略静默时间内符合告警条件的告警活动，不发送告警。

• 告警活动抑制：告警活动管理模块在接收到告警后根据抑制策略，阻止与当前告警活动相关的其他告警活动触发告警通知。例如部署节点的宿主机发生宕机严重告警时，可以通过配置抑制策略暂时忽略其他非严重的告警。

• 告警活动压缩：根据告警活动的时间对告警活动进行压缩，每个告警活动都会包含开始时间和结束时间，多个标签相同的告警活动如果开始时间和结束时间有交集，会自动压缩合并为一个告警活动。

◆告警通知管理

主要负责告警活动的通知渠道和对象、通知策略和通知失败补偿逻辑。通知策略本质上是一种订阅规则，当触发告警时可根据配置的通知策略进行通知。通知失败补偿则是指已通过策略对没有成功触发用户的告警不断地进行补偿重试，减少遗漏。

系统流程

• 用户自定义策略：用户在前端页面选择告警规则创建方式（静态阈值、自定义语句和审计合约告警），配置告警规则、告警降噪策略以及通知策略，系统会将这些策略入库。

当告警数据源为审计合约：monitor服务内会常驻专门和链对接的驱动模块，各种异构链的驱动会负责与对应的异构链建立grpc长连接。发生审计事件后，会触发事件告警对接模块。事件告警对接模块会根据从数据库中获取的告警规则产生对应的告警活动，并将警告活动推送至notification。

当告警数据源为时序数据库或者KVSQL，通过在资源主机上安装hostagent定时采集监控数据并存入prometheus中，从而支持根据告警规则执行promQL语句查询，然后对接收到的数据做阈值判断，将满足阈值（告警条件表达式为真）的告警活动推送至notification。

• notification模块接收到告警活动后，会根据从数据库中获取的各种策略（具体策略可见上一节介绍）依次进行逻辑判断。当满足所有策略后，将触发sender（发送通知）模块。

• sender根据触发的告警进行相应的通知内容封装，并根据数据库存储的通知方式进行邮件、短信或者钉钉等通知。

自定义告警指标

上述的区块链告警系统支持自定义创建告警规则，即通过自定义查询语句对原始一级监控指标进行各类统计计算，从而构建满足业务诉求的告警规则。需要注意的是，原始一级监控指标通常是BaaS平台已经配备的较为常用的固定采集指标，在实际场景中，用户可能需要接入特定的业务指标来使用告警系统，此时可以通过系统提供的agent服务启动动态配置的so文件，采集用户自定义的metric，然后通过转换将metric传到prometheus，就可以实现自定义metric的接入。

回顾与总结

以上是趣链BaaS基于异构链打造的原生区块链告警平台，通过整合链上业务数据和资源监控数据等原始数据，支持基于实践经验灵活创建告警规则，保证区块链运行过程中85%以上的异常可以被准确定位。