钉钉报错推送策略实战：从轻易云拉取错误明细到钉钉机器人告警

这个策略解决什么问题

在一次实际项目里，某零售企业把金蝶云星空和钉钉上的十几条业务单据同步交给了轻易云数据集成平台。日常跑得稳，但运维同事很快就发现一个尴尬现实：集成任务一旦报错，默认只写在平台日志里，不主动通知。结果往往是第二天上班才发现昨晚财务报销、费用申请断了好几个小时，等到手动补单已经过去大半天。

「钉钉报错推送」这条策略就是为这个痛点设计的：定时从轻易云拉取近一段时间内处于「错误」状态的策略明细，再用钉钉自定义机器人把异常推到指定群。它本身不搬运业务数据，而是给所有业务策略加上一道“监控哨兵”，属于典型的运维型集成。

数据流向与字段映射

这条策略的数据流向是单向拉取 + 推送，可以理解为「轻易云错误日志 → 中间组装 → 钉钉机器人消息体」。

我们特别建议把 recentSeconds 和 ids 这两个字段做成「集中配置」：所有运维策略都用同一套回溯窗口和策略清单，避免每个告警通道各写一份。

在轻易云上如何配置

这条策略在轻易云数据集成平台里其实只有两个集成动作：源是 StrategyErrorDetail（内部 WebAPI），目标是 DingTalkRobotDetail（同样是 WebAPI，但 effect 设为 EXECUTE）。

几个关键配置要点：

1. 源接口选 WebAPI / QUERY：它返回的是错误明细数组；务必勾选自动填充响应字段，避免每次新增策略都要手动加字段。
2. 目标接口选 WebAPI / EXECUTE：写动作，直接调钉钉自定义机器人的 webhook。access_token 在钉钉群里生成后填入即可，注意保存在平台的密钥管理而不是直接明文散落在请求体里。
3. 字段映射阶段：源侧的 strategy_name、strategy_id、number、response_at 等直接引用到目标请求体里；lessee.name 使用平台内置变量，方便多租户场景区分。
4. 不要启用构建模型：错误明细结构相对固定，没必要为它单独建模，反而会拖慢调度。

实施步骤

我们建议把这条策略拆成三个阶段落地：

第一步：建一个最小可运行的告警策略。 先只监控一两条最关键的策略，调度频率设为「每 2 小时一次」，源接口只传一个 ids 值，目标指向一个测试群机器人。确认能从钉钉收到卡片后，再放大。

第二步：扩到全量策略并切到正式频率。 把所有需要监控的策略 ID 集中维护在一个常量里（轻易云支持变量集中管理，正好对应「编码映射集中管理」的常见模式），频率从测试的 30 分钟切回 0 */2 * * * 这类稳态调度。目标机器人换成生产群，建议错峰 10 分钟（10 */2 * * *）避免和源在同一秒触发。

第三步：增量起点与全量触发分离。 我们习惯把第一次上线视为「全量触发」——也就是回溯窗口临时拉大（比如 7 天），把历史积压的错误一次性刷出来，让运维同事有个完整账本；之后再用默认 3 小时窗口做「增量」。这样既不会丢历史告警，也不会天天被同一批旧错误打扰。

踩坑复盘

1. 回溯窗口和告警频率不匹配。 一开始我们把 recentSeconds 设成 1 小时、调度设成每 2 小时一次，结果整点窗口外那 1 小时的错误直接漏掉。稳妥的做法是「窗口 ≥ 调度周期 × 1.5」，留出重叠。
2. ids 漏配新策略。 上线新业务策略时，运维忘记把它加进 ids 列表，告警机器人当然不会响。我们后来把这条做成上线检查清单里的固定一项。
3. 钉钉机器人被限流。 一次集中报错触发了上百条推送，钉钉群机器人被频控，运维反而收不到消息。经验是：要么在轻易云里对同一策略的错误做去重，要么在源接口侧用更小的回溯窗口控制单次推送量。
4. access_token 误提交到代码仓库。 这条最敏感也最容易翻车，强烈建议放进平台的密钥字段而不是请求体明文。
5. 告警里缺少定位信息。 最早版本只推 strategy_name，多租户场景下根本分不清是哪家子公司的报错；后来加上 lessee_name、response_at、number，运维一眼就能定位。

适用场景与不适用场景

适用：多业务策略同时运行、需要“统一告警入口”的运维场景；多租户 SaaS 集成环境；金蝶云星空、钉钉、SAP、用友等组合。不适用：单条低频策略（直接看日志即可）；对告警实时性要求秒级（应改用事件驱动而非定时轮询）；以及不希望在钉钉群出现业务错误摘要的合规敏感场景。