Índice de contenidos
Claves de la noticia
- Google Cloud pone fin el 28 de septiembre de 2026 al mantenimiento estándar de sus agentes antiguos de Cloud Logging y Cloud Monitoring.
- Los agentes instalados seguirán enviando datos; la ayuda específica para migrar continuará durante doce meses, hasta el 28 de septiembre de 2027.
- Google recomienda pasar a Ops Agent u otra alternativa compatible y revisar las diferencias de configuración y métricas antes de extender el cambio.
Los servidores que todavía usan los agentes antiguos de observabilidad de Google Cloud entran hoy en una etapa distinta. El envío de registros y métricas no se interrumpe automáticamente, pero el software deja de recibir mantenimiento estándar y correcciones periódicas. Para las empresas que dependen de esos datos para detectar incidencias, la fecha marca el inicio de una migración que conviene comprobar por etapas, no una orden de apagar la recopilación de golpe.
Qué termina hoy y qué sigue funcionando
La página oficial de retirada fija el 28 de septiembre de 2026 como final del soporte para los antiguos agentes de Monitoring y Logging. Google indica que no publicará nuevas versiones, ni mantendrá las correcciones habituales de errores o la compatibilidad con nuevos sistemas operativos. Los paquetes continúan disponibles y las instalaciones existentes pueden seguir transmitiendo datos a Cloud Logging y Cloud Monitoring.
Esa distinción importa para interpretar el riesgo. Un panel que muestra valores esta mañana no demuestra que el agente conserve soporte; tampoco la fecha implica por sí sola un vacío inmediato en los registros. La conclusión práctica de comparar ambas condiciones es concreta: el primer problema es mantener una pieza sin correcciones, mientras que la pérdida de visibilidad puede aparecer más adelante por incompatibilidades o por una migración mal comprobada. Google no anuncia en esta documentación una fecha de apagado del servicio de ingestión para los agentes ya instalados.
Otra guía de Google Cloud sitúa el final de la asistencia para migrar el 28 de septiembre de 2027. Son dos relojes distintos: doce meses de acompañamiento para abandonar el software antiguo no equivalen a doce meses adicionales de mantenimiento normal. La fecha de 2027 sirve para planificar y solicitar ayuda, no para tratar la instalación actual como si todavía recibiera las mismas actualizaciones.
El cambio afecta a los datos que llegan a los paneles
La alternativa principal para las máquinas virtuales de Compute Engine es Ops Agent, que reúne la captura de logs y métricas en un solo componente. Google también propone su distribución de OpenTelemetry Collector para entornos que necesiten enviar trazas, métricas y registros mediante OTLP. Quien mantenga configuraciones muy personalizadas de Fluentd puede evaluar el proyecto original con los complementos de Google para los registros. Son opciones para necesidades distintas, no sustitutos idénticos que puedan instalarse sin revisar la operación existente.
| Alternativa | Uso que documenta Google | Comprobación prioritaria |
|---|---|---|
| Ops Agent | Logs y métricas de VM en un agente | Configuración, métricas y alertas |
| Google Built OpenTelemetry Collector | Telemetría basada en OTLP | Rutas de exportación y trazas |
| Fluentd con complementos | Logs con personalizaciones heredadas | Filtros y destinos de registros |
La tabla permite ver por qué no basta con sustituir el paquete: solo la primera ruta replica explícitamente la función conjunta de los dos agentes antiguos en una VM. Las otras responden a arquitecturas o configuraciones concretas. La documentación de Google recomienda Ops Agent como opción principal para Compute Engine, pero deja margen para flujos de telemetría diferentes.
La guía de transición advierte de cambios en las métricas recogidas. Por ejemplo, algunas etiquetas de disco y estados de CPU pueden diferir entre el agente de Monitoring heredado y Ops Agent. Si una alerta consulta una serie o una etiqueta precisa, puede dejar de coincidir aunque la máquina siga enviando métricas. Antes de cerrar la migración hay que comparar, en una VM de prueba, los gráficos y reglas que usa realmente el equipo, y ajustar las consultas dependientes de esos nombres.
Una migración por VM evita doble ingesta
Google prescribe desinstalar los agentes antiguos e instalar después Ops Agent en una sola máquina antes de extender el despliegue. Su documentación de instalación señala que mantener ambos tipos en una misma VM puede duplicar registros o provocar conflictos en las métricas. También avisa de que los archivos de configuración nuevos no son compatibles con los antiguos, por lo que las personalizaciones deben guardarse y traducirse antes de retirarlos.
Una secuencia prudente empieza por identificar qué VMs ejecutan cada agente y qué pipelines, filtros, paneles y alertas consumen sus datos. Después, se conserva la configuración personalizada, se elige una máquina representativa y se aplican los pasos de Google. La validación consiste en comparar series, volumen de logs y reglas de alerta durante un período que incluya actividad normal; la documentación no fija una duración universal. Solo con esa evidencia tiene sentido replicar el cambio en el resto de sistemas.
La operación resulta especialmente relevante para empresas españolas que administran VMs en Google Cloud con supervisión propia o a través de un proveedor. No hay en las fuentes consultadas una cifra pública sobre cuántas instalaciones españolas siguen con los agentes heredados. Lo verificable es el alcance técnico de la medida: depende del software instalado en cada entorno, no del país donde trabaja el equipo. Un inventario interno, por tanto, es más útil que inferir exposición a partir de la región de la cuenta.
La fecha de 2027 no sustituye al inventario
El plazo de asistencia hasta septiembre de 2027 ofrece tiempo para resolver casos difíciles, como filtros de Fluentd o alarmas ligadas a métricas antiguas. No convierte la retirada de hoy en un trámite aplazable sin coste técnico: cada nueva versión del sistema operativo que deje de ser compatible amplía la distancia entre un agente congelado y una plataforma que continúa cambiando. Esa posibilidad figura en la advertencia de Google sobre incompatibilidades futuras, aunque no se publica un calendario de fallos por sistema.
La decisión útil es separar tres estados en el inventario: máquinas ya migradas y verificadas, máquinas todavía funcionales con agente sin mantenimiento, y máquinas cuya telemetría necesita un rediseño. Esa clasificación evita dos errores opuestos: dar por perdido un flujo que sigue activo y asumir que un flujo activo permanece protegido. El objetivo de la migración es conservar la capacidad de detectar incidencias con datos equivalentes y un colector mantenido, no limitarse a instalar un paquete distinto antes de una fecha.
