企业微信集成怎么做监控告警

先按「谁在坏」分，指标才有意义

集成链路上会坏的东西只有三类：账号还能不能用、事件进不进得来、动作出不出得去。绝大多数团队的监控只覆盖第三类，因为它有明确的错误码 —— 而前两类的失效方式恰恰是安静的。

三类的坏法不一样，检测手段也就不一样：账号侧是「突然全断」，靠状态比对；事件侧是「悄悄变少」，靠基线比较；出向侧是「有明确失败」，靠错误率。用一套阈值告警去覆盖三类，一定会漏掉中间那类，而中间那类恰好是发现最慢、影响最广的。

指标一：账号在线率，以及掉线时长

网关式接入的第一前提是账号实例在线。这个数最容易被漏掉，因为它不属于任何一次请求 —— 没有请求失败，只是所有请求都发不出去。

要盯的不是「有多少个在线」，是「应该在线的有几个不在线」。把预期在线的账号清单维护在自己的配置里，定期和 wecomapi 的实例状态做比对，差集才是告警对象。只看平台返回的在线列表，某个账号被误删或者从来没接上，你永远发现不了。

• 在线率按业务线拆开看。三十个账号掉一个，整体在线率 97%，但如果掉的是唯一那个承接售后的，这条业务是 100% 中断。
• 单账号的掉线时长分布比在线率更有用：偶尔抖十几秒和持续掉线半小时，是两种完全不同的问题，前者不用叫人，后者必须叫。
• 掉线要记原因分类，自愈重连成功的也要记。一天自愈二十次的账号，下一次多半就自愈不回来了。

指标二：事件到达率与静默检测

这是五个里最想强调的一个。事件链路坏掉时你的系统不会报错 —— 回调地址被改、证书过期、订阅关系被人动过、上游网关拦截，表现全都是「什么都没发生」。错误率监控对「没有请求」这件事天然失明，因为分母也是零。

所以要监控的是「一段时间内事件数为零或显著偏低」，而不是「事件处理失败率」。按事件类型分别统计，因为不同类型的正常节奏差很多：消息类几分钟没有就可疑，群变更类一天没有很正常。

阈值不能用固定值，要用同比基线：拿上周同一星期几、同一时段的量做参照，低于基线某个比例才报，并且要求连续两个窗口都低。周末和节假日的消息量天然是工作日的零头，用固定阈值的结果是每个周六都误报，两周之后没人再看这条告警 —— 而它恰恰是唯一能抓住哑故障的那条。

// 示意逻辑，事件类型口径以 wecomapi 文档为准
function checkSilence(type, now) {
  const cur  = counter.sum(type, now - WINDOW, now);
  const base = counter.sum(type, now - WEEK - WINDOW, now - WEEK);  // 上周同一时段
  if (base < MIN_SAMPLE) return;                  // 基线样本太少，这一轮不判

  const ratio = cur / base;
  streak[type] = ratio < FLOOR[type] ? streak[type] + 1 : 0;
  if (streak[type] >= 2) {                        // 连续两个窗口都低才报
    alert("event.silent", { type, cur, base, ratio });
  }
}

基线法有个盲区：业务量本来就可能为零。半夜没人说话，事件数是零，同比基线也是零，这一轮什么都判断不出来。补这个洞要靠合成探针 —— 自己发一条、再从事件侧收回来，业务量为零时它照样该通。探针怎么做站内的运维清单那篇有具体写法，这里只强调它和基线法是互补的：基线管「变少」，探针管「彻底为零」。

指标三：端到端时延，按段归因

时延要测的是「事件在平台侧产生」到「业务动作完成」的整段，而不是自己代码那一截。只测自己那截，投递排队、队列积压这些真正的延迟源全在视野之外，面板上会长期显示一切健康。

把「平台侧产生时刻」纳进来需要从事件本身取，具体取值方式以线上接口文档为准。没有这个时刻，投递段的延迟就只能算进你自己的耗时里，而这两段的处置方式完全不同 —— 一个要找对面，一个要改自己。

看分位数，不看平均。平均 200 毫秒、P99 八秒的服务在面板上很好看，但那 1% 正在源源不断地制造超时和重投。P99 涨而 P50 不涨，通常是某一类事件或某个分区在拖后腿，不是整体变慢，这时候扩容是无效的。

时延告警要挂在业务能感知的那一段上。「客户发出消息到自动回复发出去用了多久」是业务指标，值得告警；「消费者单条处理耗时」是排查指标，放面板不放告警。两者混在一起，真正的业务劣化会被排查指标的正常波动淹掉。链路分段定位的具体方法站内另有一篇，这里不展开。

指标四：出向动作的确认率

出向侧最常见的错误是把「接口返回成功」当成「动作生效」。提交成功只说明请求被接受，中间还隔着投递、对象状态和平台侧的处理。这两个数之间的差额，就是确认率，它比错误率更接近业务的真实体感。

做法是给每次出向动作记两个时刻：提交成功的时刻，以及确认生效的时刻。第二个时刻靠 wecomapi 的事件回调回填，超过约定时间还没回填的进「已提交未确认」池子。这个池子的大小和最老一条的年龄，是这一节真正要盯的两个数。

• 确认率按动作类型分开算。发消息和改标签的确认路径完全不同，混在一起算出来的数没有含义。
• 突然下跌通常不是接口坏了，是某类对象的前置条件变了 —— 关系已解除、群已解散、账号权限被调整。
• 长期稳定在某个不到 100% 的值也要查一次。它往往对应一批一直失败、但因为占比稳定而没人看的对象。

指标五：积压的年龄，不是深度

队列深度是最常被摆上面板、也最容易误导的一个数。深度 5000 可能完全健康（吞吐高，几秒就消化完），深度 3 也可能是重大故障（三条毒消息卡住了分区，后面全在等）。深度只有配上消费速率才有意义，而告警不该依赖两个数的组合判断。

该盯的是最老一条待处理记录的年龄。它直接对应业务感知到的最坏时延，而且不受吞吐量影响 —— 无论量大量小，年龄超过阈值就一定有东西卡住了。深度和消费速率留给排查用，年龄用来告警。

• 各分区、各分片分别算年龄再取最大值。全局平均会把单个卡死的分区完全抹平。
• 重试中的条目也要算进年龄，别只统计「还没开始处理」的那些，否则一条反复重试的消息永远不会让年龄涨上去。
• 死信队列单独算年龄。数量不大但最老一条是三天前，说明这个队列根本没人看。

阈值与分级：别让告警变成背景噪音

五个指标定完，剩下的活是让告警可信。企业微信告警最常见的失败不是漏报，是报得太多 —— 可信只有一个标准：收到的人相信「这条一定需要处理」。达不到这个标准的告警，多加一条不如不加，它不只是没用，还会顺带降低旁边那些有用告警的可信度。

1. 1只分两级：需要立刻有人处理的（账号全掉、事件静默、确认率断崖）走强提醒；需要今天有人看的（单账号抖动、积压年龄超标、死信增长）走工单或群消息。第三级应该叫面板，不叫告警。
2. 2阈值从基线来，不从想象来。上线后先只采集不告警跑一到两周，拿真实分布定阈值，比任何经验值都准，也比抄别人的配置准。
3. 3每条告警都带处置线索：哪个账号、哪条业务线、最近一次变更是什么。没有线索的告警等于把排查工作原样推给值班的人。
4. 4加静默窗口：发布期间、已知维护期、业务的非活跃时段都该能临时压掉对应告警。但压制必须带过期时间，不能永久关掉 —— 永久关掉的告警会以「大家都忘了有这回事」的方式回来。

最后一条经验：告警数量应该是收敛的。同一条告警一周响了五次都没人动手，它要么该被修复，要么该被删掉。留着它只会训练团队忽略所有告警，而这个习惯一旦养成，下一次真事故也会被划过去。