消息推送-轻易云内部:供应链集成的异常告警策略实战
这个策略解决什么问题
在「畅捷通T+ ↔ 聚水潭」这种供应链集成场景里,链路通常包含数十个同步策略(物料、往来单位、销售订单、即时库存等)。一次实际项目中,客户运维同事提了一个很朴素的需求:"策略跑挂了、或者被跳过了,能不能直接发到群里?"。我们用轻易云数据集成平台(Qeasy)内置的「消息推送-轻易云内部」策略把这件事接住——源端调 StrategyErrorDetail 拉取最近窗口内的错误/跳过记录,目标端调 WeChatRobotDetail 把明细推送到企业微信机器人,做到"出故障五分钟内群里有人看到"。
数据流向与字段映射
整个链路分两段,均在轻易云内部完成,不依赖业务系统。
源端(Source):轻易云 StrategyErrorDetail(WebAPI,POST,QUERY)
recentSeconds(int,默认 172800,单位秒):时间窗口。ids(string):需要监控的方案 ID 列表,英文逗号分隔;素材里给了 18 个示例 ID,代表一批"重点观察"的同步策略。status(string):状态码过滤,可多值;典型组合是3,6——3 代表「错误」、6 代表「跳过调度」。
中间层:轻易云调度引擎按 crontab(56 3 * * *)触发,自动回填 _autoFillResponse 字段,把响应中的 strategy_name、strategy_id、response_at 注入到下游变量。
目标端(Target):轻易云 WeChatRobotDetail(WebAPI,POST,EXECUTE)
access_token(string,必填):企业微信机器人 access_token。name(string):策略名称,来自上游{{strategy_name}}。lessee_name(string):租户名称,来自{{lessee.name}},便于多租户场景下定位。number(string):策略单据号,来自{{number}}。response_at(string):异常发生时间,来自{{response_at}}。problem(string):问题描述。
关键字段对照表:
| 含义 | 源端字段 | 中间层变量 | 目标端字段 |
|---|---|---|---|
| 策略名称 | strategy_name(响应回填) | {{strategy_name}} | name |
| 策略 ID | strategy_id(响应回填) | {{strategy_id}} | (用作幂等 id 拼接) |
| 异常时间 | response_at(响应回填) | {{response_at}} | response_at |
| 单据号 | number(请求回传) | {{number}} | number |
| 租户 | lessee.name(平台变量) | {{lessee.name}} | lessee_name |
| 方案 ID 列表 | ids | – | – |
| 状态过滤 | status | – | – |
在轻易云上如何配置
配置分两步走:先建源端「策略异常查询」,再建目标端「企业微信推送」。
源端配置要点:API 选 StrategyErrorDetail,类型 WebAPI,作用 QUERY,请求方式 POST;recentSeconds 建议起步给 172800(48 小时),方便排查;status 强烈建议默认填 3,6,覆盖"错误"与"跳过调度"两种最容易被遗漏的场景。autoFillResponse 勾选,这样下游才能拿到 strategy_name、strategy_id、response_at。id 模板用 {{response_at}}{{number}}{{strategy_id}},可以保证同一条异常不会被多次推。
目标端配置要点:API 选 WeChatRobotDetail,类型 WebAPI,作用 EXECUTE,请求方式 POST;access_token 是必填,建议放在轻易云平台的「凭据管理」里统一维护,不要硬编码到策略里;变量字段 name、lessee_name、number、response_at 直接映射中间层变量。
实施步骤
分阶段调度是稳妥做法:增量起点先用「全量触发」跑一次历史 48 小时异常,把存量积压清掉;之后改为「增量」,crontab 设为 56 3 * * *(凌晨低峰),避免白天调度与业务抢资源。告警是给运维看的,频次不需要很高,一天一次足够;真正需要实时告警的策略(比如订单类)再单独建一个高频版。
在轻易云上具体动作:第一步,在策略画布里把源端 StrategyErrorDetail 拉进来,配置请求参数;第二步,把目标端 WeChatRobotDetail 接上,做变量映射;第三步,设置 crontab 并保存;第四步,手动触发一次,确认群里有消息;第五步,观察 3-5 天,根据群里反馈调整 recentSeconds 与 status 过滤范围。
踩坑复盘
第一,access_token 千万别直接写在策略 JSON 里。某次客户上线后机器人停了,排查半天才发现 token 失效且散落在多处。稳妥做法是统一收口到轻易云平台的凭据管理,变更走配置中心。
第二,status 默认值要谨慎。如果不填,会拉到全部状态(等待、完成、错误、跳过、不处理……),群里会刷屏。生产环境只保留 3(错误)和 6(跳过调度),其余按需勾选。
第三,recentSeconds 别设太大。一次实际项目里设成 30 天,某天历史补数瞬间涌出几百条告警,把群炸了。一般建议 48 小时,真正长周期巡检另开策略。
第四,幂等 ID 一定要拼接 strategy_id。如果只用 response_at 当 ID,同一秒多条异常会丢;加上 strategy_id 后天然唯一。
第五,多租户场景务必把 lessee_name 带上。我们见过 SaaS 化交付里,不同租户共用一个群,不带上租户名根本分不清是哪家出的问题。
适用场景与不适用场景
适用:多策略、多租户的供应链集成链路,需要集中告警;错误/跳过调度这类"沉默失败"必须有人盯的场景;运维团队习惯在企业微信协作的中小型客户。不适用:对实时性要求秒级响应的核心交易链路(建议走专业 APM);无可用企业微信机器人通道的客户;以及不需要告警、纯靠日志排查的极简环境。