Google ends maintenance for legacy Monitoring and Logging agents

Teams still running Google’s legacy Monitoring or Logging agents now have a migration deadline to plan around. Standard maintenance and regular bug fixes ended on September 28, 2026. Google will help with migration through Cloud Customer Care support tickets until September 28, 2027. The notice describes a support transition; it does not announce that telemetry stopped arriving on September 28. Google’s end-of-support notice

Choose the replacement around the data you collect

Google recommends the Ops Agent for Compute Engine machines. It collects logs and metrics in one agent, configured through YAML. For application telemetry using OpenTelemetry Protocol, Google also offers its own OpenTelemetry Collector build. That route handles traces, metrics and logs sent by instrumented applications.

Upstream Fluentd remains a logging-only option for installations with custom configurations that cannot translate to the Ops Agent. A custom Fluentd parser that has no Ops Agent equivalent needs a separate migration decision. Copying the old configuration into a different collector does not establish that the same fields will reach Cloud Logging.

One changed label can hide a working disk

A migration can keep sending measurements while breaking the query used to investigate a failure. Google documents a concrete difference: the legacy Monitoring agent reports disk device labels such as sda15, whereas the generally available Ops Agent includes the path, such as /dev/sda15. It also excludes virtual devices such as tmpfs from these disk measurements. Google’s migration and metric-differences guide

In a hypothetical pilot, a disk alert filters on device="sda15". After migration, the new collector can be healthy and sending disk data while that filter matches nothing. Check the actual series labels, update the filter where necessary, and exercise the alert in an authorized test environment. A missing result must not be interpreted as spare disk capacity.

Use a known event and the existing investigation query to check the replacement. On one representative machine, save the old configuration and the query a responder uses, migrate with the documented procedure, then compare the resource identity, fields and timestamps returned. Test custom parsing separately from agent installation. This applies equally when an AIOps system consumes the results: a model cannot recover an event that its retrieval query excludes.

The same acceptance principle appears in our OpenTelemetry attributes migration coverage. For this change, start with an inventory of legacy-agent machines and custom parsers. Select a pilot that includes a real configuration difference, then use its query and alert checks to decide whether the rest of the fleet is ready.