Google Cloud在2026年9月28日确认，旧版Cloud Logging代理与Cloud Monitoring代理已正式结束支持。标准维护与常规缺陷修复随之停止，继续依赖旧代理的云服务器不会在公告当天自动失去采集能力，但后续操作系统、依赖组件或服务端接口变化都可能放大运行风险。
这项变化直接影响仍在虚拟机中运行google-fluentd或stackdriver-agent的环境。运维团队需要先确认资产和自定义配置，再设计迁移窗口；“还能运行”不能等同于“仍受支持”，生产系统不宜把迁移动作拖到下一次系统升级之后。
两类旧代理结束支持的范围不同
旧版Logging代理以Fluentd为基础，主要把系统及应用日志发送到Cloud Logging；旧版Monitoring代理以collectd为基础，负责采集主机与部分应用指标。公告针对的是这些旧式虚拟机代理，而不是把Cloud Logging、Cloud Monitoring或云端可观测性服务本身下线。
资产盘点时应同时检查安装包、systemd服务、启动脚本与镜像模板。只在控制台里查看近期数据并不足以确认代理类型，尤其是经过多年滚动升级的实例，可能同时保留旧代理配置和新的采集组件。
结束支持不会立即切断现有数据流
结束支持意味着标准维护和常规缺陷修复停止，并不代表所有旧代理会在同一时刻停止上传。短期内保持运行可以为迁移争取时间，但新的操作系统版本、库依赖变化或安全问题将不再得到常规修复。
不要先卸载旧代理再验证新链路。如果日志和指标承担告警、审计或容量规划职责，直接切换可能造成不可见的监控空窗；更稳妥的做法是限定范围并行运行，再比较关键数据是否连续。
Ops Agent是主要迁移方向
Google建议新工作负载使用Ops Agent，并推动现有虚拟机迁移。Ops Agent在一个代理中处理日志和指标，但它的配置模型与Fluentd、collectd并非逐行对应。原有输入、解析规则、过滤条件、标签和指标插件需要按新管线重新表达。
迁移前应把自定义配置分类：哪些负责读取文件，哪些解析多行日志，哪些过滤敏感字段，哪些产生自定义指标。配置可启动并不等于语义完全一致，字段名称、资源标签和采样方式都要通过实际数据核对。
采用小批量并行验证可以降低风险
建议先选择业务影响较小但流量具有代表性的实例作为试点，记录切换前的日志吞吐、指标基线、采集延迟和代理资源占用。部署Ops Agent后，比较相同时间窗口内的事件数量、严重级别、资源标签以及告警触发结果。
并行期间可能产生重复日志或额外采集费用，因此需要设置明确的验证时长和退出条件。确认仪表盘、告警规则、日志路由与保留策略均正常后，再按实例组或可用区分批扩大范围，并保留旧配置的可恢复副本。
迁移验收要覆盖采集链路和下游规则
完成安装只是第一步。最终验收应检查代理健康状态、数据摄取延迟、日志排除规则、指标名称、标签维度、告警条件和导出接收端。特别是依赖旧字段路径的查询与告警，可能在数据仍持续上传时悄然失效。
当新代理连续稳定运行并通过业务高峰验证后，再移除旧代理及其服务账户权限。对无法立即迁移的主机，应记录责任人、例外原因与最后迁移日期，避免失去支持的组件长期留在生产基线中。
