Google ends maintenance for legacy Monitoring and Logging agents

Google’s legacy Monitoring and Logging agents reached the end of standard maintenance and regular bug fixes on September 28, 2026. Migration help through Cloud Customer Care tickets continues until September 28, 2027. Google’s end-of-support notice gives teams a support window in which to replace them; it does not say telemetry stopped arriving on the maintenance-end date. The less visible migration risk is that data keeps arriving while an old alert can no longer find it.

Choosing a replacement for logs, metrics and traces

For Compute Engine, Google recommends the Ops Agent, combining logs and metrics in one YAML-configured agent. Instrumented applications sending traces, metrics and logs through OpenTelemetry Protocol can also use Google’s OpenTelemetry Collector build. These choices follow the source and type of telemetry rather than simply replacing one agent name with another.

A custom logging parser can make the choice less straightforward. Upstream Fluentd remains a logging-only option when an existing configuration cannot translate to Ops Agent. If a custom parser has no equivalent, it needs a separate migration decision based on the fields responders require. Copying configuration or starting the new process cannot establish that those fields survived.

A disk-label change can leave an alert without data

Google documents the small change with large query consequences in its migration and metric-differences guide: the legacy agent reports a disk device such as sda15, while the generally available Ops Agent includes the path, such as /dev/sda15, and excludes virtual devices including tmpfs from these measurements. A migration can therefore preserve incoming measurements and still break the query an investigator depends on.

In a hypothetical pilot, an alert filters on device="sda15". After migration, the agent is healthy and sending disk measurements, but the old filter returns nothing because the device value now includes its path. The empty result is not evidence of spare disk capacity. Inspecting the actual series reveals the mismatch; updating the filter and exercising it in an authorized test environment can show whether the intended condition is detected again.

Use that failure path to design the wider pilot. Save one representative machine’s configuration and a responder’s real query, migrate through the documented procedure, and generate a known event. Compare resource identity, fields and timestamps in the retrieved result. Test custom parsing separately from installation, because successful collection can still change the data’s meaning. An AIOps reader inherits the same limit: it cannot recover an event excluded by its query.

For the disk alert, migration is verified when the retrieved series and revised filter let the responder detect the intended condition again. The OpenTelemetry attributes migration coverage examines the same query-level problem in another telemetry change. Use the remaining support window to establish that result for the queries and custom parsers the team depends on, rather than treating an installed replacement as the end of the work.