企业微信两条接入路径
企业微信有两种接入方式：一是 wechat_configs 走自建应用，用 corp_id、agent_id 与部门 ID 直接发送应用消息；二是群机器人 Webhook，Alertmanager 不支持该协议的消息体，需要自建中继做格式转换。自建应用适合按人/按部门精准投递，群机器人适合群内协同。
两条路径对比
| 维度 | 自建应用 | 群机器人 |
|---|---|---|
| 配置方式 | Alertmanager 内置 wechat_configs | 需自建中继转换消息体 |
| 投递对象 | 按成员、部门或标签定向 | 群内所有人可见 |
| 权限依赖 | 应用可见范围必须包含目标成员 | 机器人需在群内且未被移除 |
| 频控限制 | 受应用消息接口限制 | 群机器人每分钟条数有上限 |
自建应用接收器
自建应用接收器
receivers:
- name: wecom-app
wechat_configs:
- corp_id: ww1234567890abcd
api_secret_file: /etc/alertmanager/wecom.secret
agent_id: "1000002"
to_party: "2"
message_type: markdown
send_resolved: true
message: '{{ template "wecom.message" . }}'群机器人消息体（中继转换后 POST）
群机器人消息体（中继转换后 POST）
{
"msgtype": "markdown",
"markdown": { "content": "**[FIRING]** HighErrorRate\n> 服务: order-svc\n> 当前值: 12%" }
}典型使用场景
- 值班告警按部门或值班组定向送达，避免全员打扰
- 业务群接收本服务相关告警，群内直接协同处理
- 作为电话通道之外的确认来源，留痕便于事后复盘
- 迁移到自建中继后统一做限流、合并与消息格式转换
群机器人每分钟发送条数有上限，风暴场景不合并会短时间内触发限流丢消息，中继侧要做合并与指数退避重试。
接入后用真实告警验证一次：应用可见范围、部门 ID、机器人所属群三者任一不对，表现都是静默失败而非报错。
上线检查项
- 自建应用侧确认 agent_id、部门 ID 与应用可见范围三者一致
- 群机器人侧确认 webhook 地址有效且机器人仍在目标群内
- 中继侧记录投递失败原因与重试次数，失败率升高时触发告警
- 发送一条测试告警并确收，确认内容、@ 对象与恢复通知都符合预期
- 应用消息与群机器人使用两套凭据，迁移时先并行验证再停用旧通道
- 群机器人的 markdown 语法与企业微信应用消息略有差异，换行与加粗要按平台支持的形式书写