ADR-0015 — Recogida de telemetría: agente unificado¶
Estado: propuesto
Esta decisión documenta el destino y su justificación para una fase futura de observabilidad. Todavía no está implementada: hoy la recogida de logs la hace el recolector actual.
Contexto¶
La recogida de logs la realiza un recolector que descubre los contenedores en ejecución, les asigna etiquetas coherentes (contenedor, servicio, proyecto), procesa cada línea para extraer campos estructurados (nivel, identificador de traza, identificador de petición, evento) y promueve algunos a etiquetas indexadas, de modo que se puede filtrar por ellas en las consultas. Después envía todo al agregador de logs.
El problema es que ese recolector está deprecado. El agente sucesor y con soporte a futuro unifica en un único agente la recogida de logs, métricas y trazas. Hoy la telemetría está repartida entre varios agentes: uno para logs, otro para métricas y una pasarela para las métricas del simulador. No hay un único agente de recogida.
Decisión¶
Sustituir el recolector deprecado por el agente unificado, empezando por la paridad funcional en logs y dejando la puerta abierta a unificar también métricas y trazas.
El plan previsto:
- Una configuración nueva que replique el pipeline actual: descubrimiento de contenedores, reetiquetado equivalente (mismas etiquetas de contenedor, servicio y proyecto), procesado de cada línea (extracción de los campos estructurados y promoción del nivel y el identificador de traza a etiquetas) y envío al mismo destino.
- Las mismas etiquetas y el mismo destino, de modo que los dashboards y las consultas existentes siguen funcionando sin cambios: es una sustitución del agente, no del contrato.
- Reemplazar el servicio del recolector por el nuevo agente y retirar el anterior.
- Como paso siguiente opcional dentro de la misma fase, mover también la recogida de métricas al agente único, para tener un solo agente de telemetría.
Consecuencias¶
Positivas:
- Se abandona un componente deprecado hacia el agente con soporte a futuro.
- Un único agente capaz de logs, métricas y trazas: menos piezas y una base para estándares abiertos de telemetría.
- Continuidad total para el usuario: mismas etiquetas, mismo destino, mismas consultas.
Negativas o deuda asumida:
- No implementado todavía: hay que portar el pipeline a la nueva sintaxis y validar la paridad (etiquetas, extracción del identificador de traza, marcas de tiempo) antes de retirar el recolector actual.
- Curva de aprendizaje de la nueva sintaxis de componentes frente a la configuración anterior.
- Riesgo de regresión en la correlación por identificador de traza (un objetivo clave de la fase de observabilidad) si el port no es exacto; requiere una prueba de extremo a extremo antes del cambio.
Alternativas descartadas¶
- Seguir con el recolector actual: está deprecado, sin evolución ni parches a futuro; insostenible a medio plazo.
- El recolector genérico de telemetría abierta, en lugar de la distribución integrada: válido, pero la distribución elegida es la vía soportada por el mismo proveedor del agregador y las herramientas de observabilidad, e integra mejor con ellas.
- Otros agentes de recogida: buenos, pero cambian más el ecosistema (no son la ruta natural desde las herramientas actuales) y no aportan ventaja para esta pila.