监控内网软件源镜像需关注同步准确性、完整性与时效性，而非仅退出码是否为0；应采集执行状态异常提示、元数据时间与校验和一致性、关键包存在性三类信号，并用systemd+轻量脚本+Prometheus实现闭环告警。
监控并告警内网软件源镜像同步失败，核心不是“有没有同步”，而是“同步得对不对、全不全、及时不及时”。很多团队只看rsync或reposync命令是否退出码为0，结果日志显示“success”，实际缺了关键包、元数据损坏、或同步中断后没重试——这正是典型的静默失败。
盯住三类关键失败信号
镜像同步失败往往不表现为报错，而表现为“看似成功但数据异常”。需重点采集以下维度：
-
同步任务执行状态与退出码：不只是“0=成功”，还要捕获stderr中是否含
WARNING: failed to sync、skipping package、repomd.xml not found等非致命但高风险提示； -
同步前后元数据一致性：比对源站与本地
repomd.xml的timestamp和checksum，时间差超2小时或校验和不匹配即触发告警； -
关键包存在性验证：例如定期检查
kernel-core、glibc、openssl等基础包在本地repo中是否存在且可解析（用repoquery --info或dnf repoquery --available）。
用轻量脚本+标准工具实现闭环监控
无需引入复杂平台，用Linux原生工具就能搭出可靠链路：
- 将同步命令（如
reposync -p /var/www/mirror/centos-stream-9-baseos --download-metadata）封装为systemd service，并启用Restart=on-failure和StartLimitIntervalSec=3600防频繁重启； - 同步完成后自动运行校验脚本：
check-mirror.sh，内容包括：读取repomd.xml生成时间、统计Packages/下rpm数量波动（环比下降＞5%即预警）、调用createrepo_c --update验证元数据可重建； - 脚本输出结构化结果（JSON格式），由
node_exporter的textfile collector读取，暴露为Prometheus指标，如mirror_sync_status{repo="centos9-baseos"} 0（0=异常，1=正常）。
告警必须带上下文，不能只说“同步失败”
运维人员收到告警时，应能立刻判断影响范围和恢复路径。建议告警消息包含：
- 失败镜像名称与上游地址（如
mirrors.aliyun.com/centos/9-stream/BaseOS/x86_64/os/）； - 最近一次成功同步时间 + 当前同步耗时（超2小时未更新即标红）；
- 具体异常线索：例如“
repomd.xml timestamp=2026-09-14T03:22:17Z, local is 2026-09-15T08:11:02Z → 滞后32h”或“missing rpm: kernel-core-5.14.0-427.13.1.el9_4.x86_64.rpm”； - 一键恢复命令提示：
sudo systemctl restart mirror-centos9-baseos.service。
避免常见盲区
这些细节常被忽略，却最容易导致告警失效：
- 同步进程被OOM killer干掉，但exit code是137——需在
systemctl show中查StatusText或journalctl -u xxx | grep "killed process"； - 磁盘inode耗尽（
df -i），导致createrepo写入失败，但df -h显示空间充足； - 内网DNS不稳定，同步时解析上游域名超时，但重试机制未覆盖DNS层——建议在同步前加
timeout 10 getent hosts mirrors.aliyun.com || exit 1； - 所有节点未强制chrony时间同步，导致
repomd.xml时间戳校验误判——务必确认timedatectl status显示System clock synchronized: yes。
