备份失败时通过企业微信机器人告警需满足：仅在命令退出码非0时触发，用jq构造合法json（含backup_time、exit_code、error_snippet），通过curl -m 5 -f -s post至webhook地址，避免阻塞主流程。
备份失败时怎么触发企业微信机器人告警？
MySQL 备份脚本执行失败，靠人工查日志太滞后，用企业微信机器人是最轻量、最可控的告警方式。关键不是“能不能发”，而是“失败了才发，且带明确上下文”。
企业微信机器人需要一个 webhook 地址（形如 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx），且只支持 POST JSON。别直接用 curl 拼接字符串——容易因特殊字符（比如备份路径含空格、错误信息含换行）导致 JSON 格式崩坏或消息截断。
- 用
jq构造合法 JSON：它能自动转义换行、引号和控制字符 - 只在备份命令退出码非 0 时调用告警：比如
mysqldump ... &>/tmp/backup.log || send_wechat_alert - 消息体里必须包含：
backup_time（时间戳）、exit_code（错误码）、error_snippet（取日志末 3 行，用tail -n 3 /tmp/backup.log） - 别把整个日志发过去——超长内容会被截断，且敏感信息可能泄露
钉钉机器人告警为什么老是收不到？常见配置陷阱
钉钉机器人同样依赖 webhook，但比企业微信多两道隐形关卡：签名验证和关键词过滤。90% 的“收不到”其实不是网络问题，而是配置没过校验。
如果你用的是自定义机器人，必须开启「加签」并计算 timestamp 和 sign——不能省略。否则钉钉服务端直接拒收，连 HTTP 状态码都不会返回（curl 默认静默失败）。
Wechat MP Article Stats Comments Suite - 微信公众号管理套件
下载
公众号运营：文章发布至草稿、样式封面、评论与用户管理、数据统计等。用户要求将 Markdown 发送到公众号草稿、查看阅读量统计或类似后台操作时，使用本技能。
- 检查是否勾选了「加签」：没勾选就用基础版 webhook；勾了就必须生成
sign -
sign计算方式是HMAC-SHA256，密钥是机器人后台显示的secret，输入是"${timestamp}\n${secret}" - 发送前务必用
curl -v抓包确认响应头含HTTP/1.1 200 OK，而不是400 Bad Request或超时 - 消息正文中的
text.content必须包含机器人设置的「关键词」（比如设了“backup”就至少出现一次）
如何让告警只在真正异常时触发，而不是每次备份都刷屏？
误报比漏报更伤信任。备份脚本里不能只要 mysqldump 返回非 0 就告警——比如磁盘满、权限不足、主从延迟导致锁表失败，这些要区分对待；而“无数据变更跳过备份”这种应静默处理。
- 用
mysql -e "SHOW SLAVE STATUS\G" | grep -q "Seconds_Behind_Master: 0"判断从库是否同步正常，不满足则告警 - 用
df -B1 /backup | awk 'NR==2 {print $5}' | sed 's/%//'获取根分区使用率，>90% 时中止备份并告警 - 对
mysqldump加--single-transaction和--skip-lock-tables，避免因锁表失败误判为异常 - 把“本次无新 binlog”或“全库无表变动”这类预期行为写进日志前缀（如
[INFO] No new data, skip dump），告警函数遇到该前缀直接 return
脚本里混用 curl 和告警逻辑，怎么避免阻塞主流程？
告警本身不该拖慢备份。如果企业微信接口抖动或 DNS 解析失败，curl 默认会等 30 秒才超时，整个备份脚本就卡住——这在定时任务里极其危险。
- 强制加超时：
curl -m 5 -f -s -X POST ...，其中-m 5是总耗时上限，-f表示服务端返回非 2xx 时报错 - 告警失败不中断主流程：用
|| true收尾，例如send_alert || true - 把告警逻辑抽成独立函数，并重定向 stderr 到
/dev/null，避免 curl 错误输出污染主日志 - 真要调试时，临时改成
send_alert 2>&1 | logger -t mysql-backup-alert，把告警过程单独落盘
最易被忽略的一点：所有告警请求必须走异步或超时保护，否则一个接口故障就能让整套备份机制雪崩。别假设“只是发个消息而已”。
