区块链baas平台告警方案

本文探讨了区块链告警系统现存的问题,如监控面狭窄、非原生告警、业务告警对接困难和告警质量低。提出了一种全新的区块链告警系统,支持用户动态配置告警规则,结合区块链内置审计合约、链上KVSQL等能力,通过告警规则管理、告警活动管理和告警通知管理实现高效、准确的告警,减少业务损失。
摘要由CSDN通过智能技术生成

前言

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

区块链告警现存问题

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

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

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

【业务告警无法灵活对接异构链】:针对区块链业务告警,往往需要先根据不同的区块链底层,在应用端根据业务诉求提前写好告警逻辑,这些逻辑往往是写死的&#x

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值