Google’s legacy agents are retiring. Will the disk alert still find its disk?

The disk is still there. The new agent is sending measurements. But the alert that used to watch it has gone blank. Picture a migration where the old agent called that disk sda15 and its replacement calls it /dev/sda15. A person can recognize the family resemblance. The saved query, still asking for the first name, does not.

Google’s end-of-support notice makes this a timely detail to catch. Standard maintenance and regular bug fixes for the legacy Monitoring and Logging agents ended September 28, 2026; Cloud Customer Care migration assistance continues through September 28, 2027. The notice covers installed legacy agents, not managed environments with built-in or pre-installed logging agents. Maintenance ending is not a statement that measurements suddenly stopped arriving.

Start with what the machine needs to send

An agent is the collector on the machine: it gathers logs or measurements and sends them to the monitoring service. For Compute Engine, Google recommends Ops Agent, which collects both logs and metrics using YAML configuration. If an application already sends traces, metrics and logs through OpenTelemetry Protocol, usually shortened to OTLP, Google’s OpenTelemetry Collector build is another route.

That leaves an important corner of the migration: custom log parsing, the rules that pull useful fields out of log entries. Some heavily customized Fluentd configurations cannot translate to Ops Agent. Upstream Fluentd remains a logging-only option for those setups. Pick the replacement around the records the workload produces, then check that the fields a responder relies on still arrive with the same meaning.

The query is asking for the old name

The disk example comes from Google’s migration and metric-differences guide. For the relevant disk measurements, the legacy agent uses a device value such as sda15. The generally available Ops Agent uses the full path, such as /dev/sda15, and leaves out virtual devices such as tmpfs. These are differences in the records, not just in the process collecting them.

A filter for device="sda15" will not select /dev/sda15. That label helps identify the time series, the sequence of measurements returned by the query. New readings can be accumulating under the full path while the old filter returns nothing. The empty panel has not answered the question the alert was meant to ask: how much space is left?

Try the migration on one representative machine before spreading the change. Keep its configuration and a query responders actually use. Follow Google’s migration procedure, produce a known event in an authorized test environment, and look for it through that query. Compare the identity, fields and timestamps returned. If the filter needs the full disk path, update it and exercise the intended alert condition again. Give custom parsing the same attention; a running collector cannot tell you whether an important field kept its meaning.

The satisfying finish is not simply a new process running. It is a responder finding the right disk and an alert recognizing the condition it was built to catch. The OpenTelemetry attributes migration article follows a similar query mismatch through another kind of change. Here, a few extra characters in a disk name are enough to make the point: carry the investigation across the migration, not just the measurements.