Google旧日志与监控代理结束支持：仍会传数据，迁移协助保留一年
2026年9月28日，Google Cloud旧版Monitoring与Logging代理正式结束支持。官方说明，不再发布新版本，标准支持与维护已结束，常规错误修复也停止。现有安装不会被直接关闭，仍会把日志送入Cloud Logging、把指标送入Cloud Monitoring，安装包也继续提供下载。因此，看到数据还在更新，并不能证明采集组件仍处于受支持状态。
配图为AI生成的概念插图，表现旧采集器向新采集器过渡，不是真实产品界面。
一年协助期，支持的是迁移工作
官方从2026年9月28日起提供12个月迁移宽限期，Cloud Customer Care可通过支持工单协助迁移，到2027年9月28日结束。这个日期不应被改写成旧代理又获得了一年常规维护，更不能推断到期当天所有遥测接收端都会关闭。
两种时间含义不同，决定了正确的运维优先级。团队可以按风险分批安排迁移，但应停止把旧代理继续加入新镜像或新实例模板，否则迁移清单会在清理过程中持续增长。只更新现有虚拟机，遗漏自动扩容模板，也可能在下次扩容时重新引入旧组件。
建议先统计实际安装与运行版本，并把实例、镜像、启动脚本和配置管理仓库连起来。清单中还应标记自定义日志解析、额外插件和关键告警依赖，以便知道哪些主机能采用标准方案，哪些需要单独试验。
替代方案按采集需要选择
Google首选Ops Agent作为Compute Engine实例的遥测代理，它把日志和指标采集合并，采用YAML配置。Google-Built OpenTelemetry Collector则面向应用侧的OTLP追踪、指标和日志，可发送到Google Cloud Observability及其他后端。它们面向的接入方式不同，不宜只因名称更新就直接互换。
对于大量自定义Fluentd配置、无法转换到Ops Agent的旧环境，官方也列出上游Fluentd配合Google平台插件的日志迁移路线。该路径只覆盖日志，不能顺手假设它也接管原来的主机指标采集。
实际选型应从现有数据契约倒推：需要收集哪些日志和指标，哪些字段必须保持，谁依赖这些字段，采集失败如何发现。完成这张依赖图之后再选择组件，比安装一个新代理后等待告警“自己恢复”更容易控制风险。
数据仍到达，不代表看板与告警保持原义
迁移文档列出若干指标差异。例如Ops Agent中的磁盘设备标签使用完整路径，而旧代理可能使用不含/dev的名称；对虚拟设备的采集行为也有差别。Windows的CPU状态取值同样不同。这些变化可能让旧筛选条件不再匹配，或者让图表中的序列数量发生改变。
因此，验收不应只有“日志出现”和“CPU有曲线”。还要核对设备标签、严重性、时间戳、资源标识和应用自定义字段，并检查依赖这些字段的告警是否仍能触发。尤其是磁盘容量告警，如果设备标签改变后没有匹配到任何序列，安静的告警并不代表磁盘健康。
本文建议选一组可控测试数据：写入已知日志、制造一次允许的测试错误、观察指定主机指标，然后确认目标看板与通知路径。对关键系统，应让值班人员知道切换窗口与可能出现的短暂空档，避免把迁移波动误判成业务事故。
切换步骤与长期配置一起收尾
官方Ops Agent迁移指南要求卸载旧Logging及Monitoring代理，安装新代理并配置；控制台对卸载状态的显示可能最多延迟一小时。因此应按运行进程、接收端数据和配置记录综合检查，不要只依赖控制台图标的即时变化。
在测试环境验证新旧字段后，再分批切换生产主机。每批都应保留配置备份、操作时间和结果，确认没有意外重复采集造成额外摄入，也没有遗漏应用日志。对仍采用Fluentd的主机，应明确后续谁维护插件和版本，而不是把迁移后的系统继续当作托管旧代理。
这次支持终止提醒的是一个容易被忽视的基础设施层：遥测还在流动，组件维护能力却已经变化。把采集端版本、数据格式与告警依赖一起迁移，才能保证下一次故障发生时，团队仍能看到可信而完整的现场。
