mysql备份状态需通过改造备份脚本上报至pushgateway实现监控，而非依赖mysqld_exporter；脚本应在成功/失败时分别推送1/0状态码及时间戳，并配合prometheus抓取与grafana展示。
MySQL备份状态不能直接被 mysqld_exporter 采集
mysqld_exporter 本身不暴露备份相关指标（比如 mysqldump 是否成功、xtrabackup 进度、binlog 保留天数等），它只采集 MySQL 实例运行时的内部状态（连接数、QPS、InnoDB 缓冲池命中率等）。所以想监控“备份”，必须把备份动作本身变成可观测事件。
把备份脚本改造成可上报的指标源
核心思路：让备份脚本在成功/失败时，向一个轻量 HTTP 端点写入时间戳或状态码，再由 Prometheus 抓取该端点。推荐用 pushgateway（适合短生命周期任务）或自建简单 metrics 接口（更可控）。
- 备份脚本末尾加一行：
curl -X POST -d "backup_status{type=\"full\",instance=\"db01\"} 1 $(date +%s)" http://pushgateway:9091/metrics/job/mysql_backup - 失败时发
0：curl -X POST -d "backup_status{type=\"full\",instance=\"db01\"} 0 $(date +%s)" http://pushgateway:9091/metrics/job/mysql_backup - 确保
pushgateway已部署且 Prometheus 的scrape_configs中配置了对它的抓取（job_name:pushgateway，targets:["pushgateway:9091"]） - 避免指标堆积：在 pushgateway 启动时加参数
--persistence.file=/data/pushgateway.data --persistence.interval=5m，并定期清理过期 job
Grafana 里查最后一次备份时间或是否成功
直接用 PromQL 查询最可靠：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 查最近一次成功备份时间：
time() - max(mysql_backup_backup_status{type="full", instance="db01"} == 1)→ 单位秒，转成“X 分钟前”需在 Grafana panel 设置 Unit 为duration (mm:ss) - 查当前状态（1=成功，0=失败或未运行）：
mysql_backup_backup_status{type="full", instance="db01"}，用 Stat 或 Gauge panel 展示 - 告警建议：
mysql_backup_backup_status{type="full"} == 0 or absent(mysql_backup_backup_status{type="full"})，表示失败或超 24 小时没上报
别忽略备份脚本自身的可观测性细节
很多故障不是备份失败，而是脚本根本没执行（crontab 权限错、环境变量丢失、磁盘满导致 mysqldump 静默退出）。
- 在脚本开头加
set -euxo pipefail，确保任何子命令失败立即退出并打印命令 - 重定向 stdout/stderr 到日志文件，并用
logger或echo "$(date) backup start" >> /var/log/mysql-backup.log记录关键节点 - 检查备份文件大小：
[ -s /backup/full_$(date +\%Y\%m\%d).sql ] || exit 1，防止空文件误报成功 - Pushgateway 上报必须放在脚本最后、且独立于主逻辑——用子 shell 或
trap 'curl ...' EXIT更稳妥
真正难的不是画看板，而是让备份这件事本身留下可验证的痕迹；指标只是结果，脚本健壮性才是前提。
