监控与备份 Agent 重建
迁移后原有监控、日志采集与备份 Agent 往往失效或变成重复：Agent 通常与宿主标识、注册地址、证书或纳管关系绑定，换了环境后要么连不上，要么以旧身份上报，形成同名但来源混乱的数据。迁移期恰恰是最需要观测的时段，所以 Agent 重建应当写进迁移步骤里，并配一次真实的告警验证与恢复演练。
基本信息
| 监控 | 主机 Agent、进程与端口拨测重新纳管，核对采集项与告警规则 |
|---|---|
| 日志 | 采集器配置指向新路径与新的日志服务端点 |
| 备份 | 重建备份策略并做一次真实的恢复演练 |
| 核对 | 告警接收人与静默规则更新，避免告警发到已停用的通道 |
| 常见问题 | 新旧 Agent 同时运行：数据重复上报与资源占用上升 |
| 成功标准 | 能收到真实告警，且备份可恢复，而不是只看到 Agent 是运行中 |
典型使用场景
- 整机迁移后的纳管恢复，让监控覆盖迁移窗口
- 日志平台切换：把采集器从旧端点改到新端点
- 备份策略重建：新环境的实例纳入原备份策略或新建策略
- 避免重复计费与重复数据：清理源环境遗留的 Agent 注册记录
- 云监控与自建监控并存时的分工确认，明确告警由哪套系统发出
- 迁移演练：把 Agent 重建纳入演练清单，验证可重复执行
重建后的验证动作
重建后的验证动作
systemctl status node_exporter --no-pager | head -5 # 主机指标类 Agent 是否正常
systemctl status rsyslog --no-pager | head -5 # 日志采集服务状态，服务名以实际部署为准
logger -p user.err 'migration smoke test' # 制造一条日志，确认采集与告警链路打通
ss -lntp | grep -E '9100|采集端口' # 确认监听端口与访问控制
# 备份：执行一次手动备份，并在另一台机器完成恢复验证
# 核对：在监控平台确认新主机已纳管，且告警接收人已更新三类 Agent 的重建要点
| 类别 | 重建动作 | 验证方式 |
|---|---|---|
| 主机监控 | 安装 Agent 并重新纳管到目标监控平台 | 指标数据在平台上可见，且与迁移时间点衔接 |
| 日志采集 | 更新采集路径与输出端点，核对解析规则 | 产生测试日志后能在日志库里检索到 |
| 备份 | 重建策略并确认关联对象已更新为新实例 | 手动备份加异机恢复，验证备份真正可用 |
| 告警 | 更新接收人、分级与静默规则 | 触发一次测试告警，确认能实际送达 |
| 清理 | 注销旧环境里遗留的 Agent 注册记录 | 平台上不再出现重复主机与陈旧心跳 |
Agent 重建顺序建议放在业务验证之后、正式切流之前：这样迁移窗口内已有观测能力，出问题能看到现象而不是靠猜。
备份策略名称相同但关联对象未更新：备份任务显示成功，备的却是旧环境或其他实例的数据。