开发者进阶中级274 次阅读
链上监控与告警：合约异常怎么第一时间知道
先定义什么算异常，再谈用什么渠道通知谁；本文给出资金权限、协议状态、运行与业务四类监控指标与降噪方法。
#监控#告警#运维#链上事件#值班
一句话结论
监控的本质不是「接一个通知机器人」，而是先定义清楚什么算异常、多久内必须通知到谁。没有基线的告警只会训练所有人忽略告警。
该监控哪四类信号
资金与权限类：大额转账、管理员地址变更、合约升级、暂停开关被触发、关键参数被修改、异常的代币授权。这一类直接对应「钱会不会丢」，优先级最高。
协议状态类：预言机价格与市场价偏离、资金池两侧失衡、借贷协议的利用率突变、抵押率接近清算线。这类变化往往先于事故出现。
运行类：RPC 可用性与高度滞后、交易失败率、Gas 费用异常、定时任务的执行者是否按时完成任务。运行类异常常常是业务异常的前兆。
业务类：总锁仓量的短时变化、清算量、异常的大额交互。它帮助你判断「有没有人在做不寻常的事」。
告警渠道与降噪
- 先分级再选渠道：最紧急的打值班电话或拉群，中等的进聊天机器人，低优先级的进日报。把所有事情都推到同一个渠道，等于没有分级。
- 去重与聚合：同一笔事故会触发一连串事件，要按事件源头聚合，而不是逐条轰炸。
- 用相对变化做阈值：链上活动的绝对量差异极大，比历史基线翻了多少倍通常比一个固定数字更有意义。
- 每条告警都要有对应的处理动作：写不出「收到之后该做什么」的告警，就是噪音，应该删掉。
怎么落地
起步阶段不必搭一整套平台：先订阅合约的关键事件，写几条规则比对，接到一个已有的通知渠道上，跑通「事件发生 → 有人收到 → 有人处理」这条链路，再逐步补齐指标与看板。等规模变大后，再把索引、规则和通知拆成独立服务。
给你的教训
- 没有基线的阈值撑不过两天，先攒一段时间的数据再定阈值。
- 监控要覆盖权限变更和升级，历史上相当多事故是从一次不被注意的配置修改开始的。
- 告警必须有主：没有明确责任人的告警，出事后不会有人接。
- 定期演练：在真实事故前，你永远不会知道通知链路是否畅通。