mysql备份成功率必须由备份脚本自身上报状态，exporter仅暴露已存指标；因备份为离散任务，无法被prometheus持续拉取，需通过textfile_collector写.prom文件实现可靠上报。
直接结论：MySQL备份成功率不能靠Exporter“主动采集”，必须由备份脚本自身上报状态，Exporter只负责暴露已存的指标。
为什么不能用传统 Exporter 拉取备份结果？
MySQL 备份（如 mysqldump、mydumper 或 Percona XtraBackup）是离散、偶发、非持续运行的任务，不是常驻进程。Prometheus 的拉模式（scrape）要求目标端始终提供 HTTP 接口并返回指标文本——但备份任务执行完就退出，无法“被拉”。强行让 Exporter 去查日志或文件时间戳，会引入竞态、延迟和误判（比如备份刚失败，Exporter 还没来得及更新指标）。
正确做法：备份脚本写状态文件 + Node Exporter textfile collector
最轻量、可靠、符合 Prometheus 生态的方式，是让备份脚本执行完毕后，生成一个带时间戳和结果的指标文件，交由 node_exporter 的 textfile_collector 自动暴露：
- 备份成功时，写入：
mysql_backup_success{job="full"} 1+mysql_backup_timestamp{job="full"} 1717023456 - 备份失败时，写入：
mysql_backup_success{job="full"} 0+mysql_backup_timestamp{job="full"} 1717023456 - 确保文件名以
.prom结尾（如/var/lib/node_exporter/textfile_collector/backup_full.prom），且node_exporter启动时加了--collector.textfile.directory=/var/lib/node_exporter/textfile_collector - 权限要对：该文件需能被
node_exporter用户读取（常见坑：脚本用root写，但node_exporter以node_exporter用户运行）
如何在 Grafana 中计算“最近 24 小时成功率”？
别用 rate()——它适用于连续计数器，而备份是事件型指标。正确写法是用 count_over_time() 配合条件过滤：
count_over_time(mysql_backup_success{job="full"}[24h]) / count_over_time(mysql_backup_success{job="full"}[24h] offset 0s)
但注意：这个分母会包含所有上报点（成功+失败），所以更稳妥的是显式统计：
(count_over_time(mysql_backup_success{job="full"} == 1[24h])) / (count_over_time(mysql_backup_success{job="full"}[24h]))
如果某次备份未上报（脚本异常退出、磁盘满、权限失败），该次不会计入分母，导致成功率虚高——这是设计上必须接受的权衡：监控依赖上报完整性，不能“脑补”未发生的事件。
额外建议：加一个“超时未上报”告警
备份计划是每 6 小时一次，但指标文件可能因各种原因没更新。用 PromQL 检测“最后一次上报是否超过 7 小时”：
time() - mysql_backup_timestamp{job="full"} > 60 * 60 * 7
这个告警比“成功率下降”更前置——它告诉你“备份根本没跑”，而不是等你发现成功率变成 0% 才响应。
真正难的不是写 Exporter，而是让备份流程具备可观测性闭环：脚本要处理所有 exit 状态、重定向 stderr、统一写指标、清理旧文件。漏掉任意一环，监控就变成幻觉。
