错误日志推到钉钉机器人

这个策略解决什么问题

集成平台里跑着几十条同步策略,一旦某一条因为目标系统限流、字段缺失、网络抖动而报错,业务侧往往是「数据怎么不对了」才发现。在一次零售客户的现场,我们用轻易云数据集成平台(Qeasy)承接了「策略执行错误/跳过记录 → 钉钉群机器人推送」这条策略,把告警从「事后追数」变成「准实时播报」。

数据流向与字段映射

源端是轻易云集成平台内部的 StrategyErrorDetail 查询接口,目标端是钉钉机器人 Webhook DingTalkRobotDetail。整体流向是「平台 → 平台」。

关键字段对照:

目标字段(钉钉)	源字段(策略错误详情)	映射类型
name	strategy_name	DIRECT
lessee_name	lessee.name	DIRECT(嵌套属性)
number	number	DIRECT
response_at	response_at	DIRECT
problem	problem	DIRECT
solution	solution	DIRECT
id	strategy_id	DIRECT
access_token	固定配置值	CONSTANT

这里容易翻车的是 lessee_name:源端 lessee 是一个对象,不是字符串,直接写 {{lessee}} 只会拿到 [object Object],必须用 {{lessee.name}} 取嵌套属性。

在轻易云上如何配置

源端(Source)配置要点:

• api 选 StrategyErrorDetail,effect 选 QUERY,method POST。
• 请求参数里 recentSeconds 给默认值 900(15 分钟窗口),status 给 3,6(仅错误与跳过调度),ids 填入需要监控的方案 ID 列表,逗号分隔。
• 业务键 id 用模板拼接:{{response_at}}{{number}}{{strategy_id}},保证同一条错误记录只被消费一次。
• 打开 autoFillResponse,让响应字段自动回流,省去手工建模型的步骤。

目标端(Target)配置要点:

• api 选 DingTalkRobotDetail,effect 选 EXECUTE。
• access_token 用 CONSTANT 注入,不要硬编码在请求体里,生产环境走密钥管理或环境变量。
• 映射字段按上表逐条配 DIRECT 即可,无需 _findCollection 之类的联查。
• 调度建议 1-59/15 * * * *,全天每 15 分钟执行一次,保证告警不积压。

实施步骤

1. 增量起点:第一次全量触发,确认 status=3,6 的历史错误能被拉出来,并成功推送到测试群机器人。
2. 常态化调度:源端 1-59/15 7-21 * * *(7–21 点每 15 分钟),目标端 1-59/15 * * * *(全天每 15 分钟)。源端只在工作时间拉取,符合「业务白天高频、夜间低频」的运维节奏;目标端全天执行是为了消化白天的积压。
3. 依赖与时序:目标端依赖源端先就绪,实际项目中我们用「源端 QUERY 完成 → 触发目标端 EXECUTE」的隐式依赖,避免空推。
4. 静默期验证:上线后连续观察 3 个工作日,确认非业务时段(21:00–次日 7:00)告警量是否合理,避免夜间噪音。

踩坑复盘

1. access_token 硬编码是典型错误。一旦机器人轮换密钥,策略全部失效。稳妥的做法是走密钥管理服务,策略里只引用变量名。
2. {{lessee}} 取不到值。源端字段是对象,目标端是字符串,必须用 {{lessee.name}} 这种点路径语法。轻易云的字段引用支持嵌套,但第一次配的人很容易忽略。
3. 业务键冲突。我们最初用 strategy_id 单独做 id,结果同一策略连续报错时会被去重丢掉。后来改成 {{response_at}}{{number}}{{strategy_id}} 拼接,每条错误记录都是唯一的。
4. 调度时间窗不对齐。源端 7-21 只在白天拉,如果目标端也是白天,夜间的错误会漏掉。目标端必须全天跑,源端的窗口决定了「拉多新」,目标端的窗口决定了「推多勤」,两者要分开设计。
5. 告警风暴。某次目标系统短暂不可用,一小时内积压上百条错误,钉钉群被刷屏。后面我们加上「同一策略 5 分钟内同类错误合并」的预处理,告警噪音立刻降下来。