Por qué los ingenieros aún no saben qué métricas emiten sus sistemas
El caos oculto tras las métricas modernas
La observabilidad promete claridad. Los paneles, las alertas y las trazas deberían dar a los ingenieros una imagen nítida de lo que ocurre dentro de sus sistemas. Pero basta con plantear una pregunta sorprendentemente sencilla, ¿qué métricas emite realmente nuestro stack?, para que todo empiece a desmoronarse.
Un ingeniero describió muy bien este problema mientras construía una herramienta para resolverlo. Los stacks de observabilidad modernos generan miles de métricas en distintas capas: instrumentación de aplicaciones, exportadores, componentes de Kubernetes y plataformas en la nube. Sin embargo, esas métricas están dispersas por cientos de repositorios, páginas de documentación y librerías de instrumentación.
Eso deja una extraña paradoja: los sistemas producen enormes cantidades de telemetría, pero los equipos suelen tener dificultades para entender qué señales existen. Va mucho más allá de una pequeña molestia, ya que influye en cómo se diseñan las estrategias de monitoreo, cómo se crean las alertas y cómo se depuran los incidentes. También deja a la vista un fallo en la evolución de los ecosistemas de observabilidad.
La dispersión de métricas que nadie planeó
Los stacks de infraestructura modernos se ensamblan como juegos de Lego digitales. Un entorno típico puede incluir clústeres de Kubernetes, servicios de aplicaciones escritos en varios lenguajes, bases de datos gestionadas, colas de mensajes y docenas de componentes de soporte, y cada uno de esos sistemas expone sus propias métricas mediante mecanismos diferentes.
Algunas métricas provienen de la instrumentación de OpenTelemetry integrada en el código de la aplicación. Otras llegan desde exportadores de Prometheus, pequeños servicios diseñados para exponer métricas de sistemas como PostgreSQL, Redis, Kafka o MySQL. Kubernetes aporta sus propias señales con herramientas como kube-state-metrics y cAdvisor, y los proveedores de nube añaden otra capa más con métricas de servicios como EC2, Lambda, S3 y pasarelas de API.
Cada origen utiliza un formato ligeramente distinto. Algunas métricas se definen en archivos de metadatos YAML, mientras que otras están integradas directamente en el código fuente. Las librerías de Python pueden recurrir a decoradores o APIs de instrumentación. En muchos casos, la única documentación se reduce a un puñado de comentarios repartidos por los repositorios.
Al juntar todo eso, el ecosistema de observabilidad empieza a parecerse a una excavación arqueológica. Los datos existen; lo difícil es encontrarlos.
Un proyecto para ordenar el caos
Ante tanta fragmentación, un ingeniero construyó una herramienta que parece casi obvia en retrospectiva: un registro público de métricas.
En lugar de obligarte a buscar manualmente en decenas de repositorios, el registro rastrea código fuente, documentación y archivos de metadatos en varios ecosistemas de observabilidad. El resultado es un catálogo con buscador que contiene miles de métricas de OpenTelemetry, exportadores de Prometheus, componentes de Kubernetes y servicios en la nube. El conjunto actual incluye más de 3,000 métricas recopiladas de una amplia variedad de fuentes.
Solo los componentes del OpenTelemetry Collector aportan más de mil métricas. Los exportadores de nodos de Prometheus añaden cientos más, y los de Redis, MySQL y PostgreSQL introducen sus propios conjuntos de señales de telemetría. A eso se suman las métricas de AWS CloudWatch que cubren servicios como Lambda, DynamoDB, S3 y balanceadores de carga de aplicaciones.
De forma individual, cada una de estas métricas está documentada en alguna parte. Sin embargo, hasta que aparecieron iniciativas como esta, rara vez se encontraban en un solo lugar, y ese es precisamente el problema que el registro intenta solucionar.
Planificar antes de instrumentar
Cuando los ingenieros oyen hablar por primera vez de un registro de métricas, suelen asumir que sirve como documentación. Un comentario de la comunidad apuntó a un uso más valioso: entender qué métricas aparecerían si despliegas cierto exportador o librería de instrumentación, además de comprobar lo que ya existe.
Esto tiene más peso del que parece. La planificación de la observabilidad suele hacerse antes de desplegar los sistemas, y los ingenieros quieren saber con qué señales contarán una vez instaladas las herramientas de monitoreo. Si despliegas el exportador de PostgreSQL para Prometheus, ¿qué métricas de la base de datos aparecerán? Si instrumentas tu servicio con OpenTelemetry, ¿qué métricas de peticiones estarán disponibles de forma automática? Si activas componentes de monitoreo de Kubernetes, ¿qué señales sobre la salud del clúster vas a poder recopilar?
Sin una referencia centralizada, responder a esas preguntas exige bucear en la documentación y en el código fuente. Un registro simplifica mucho esa tarea.
Un dolor cotidiano que cualquier ingeniero reconoce
La reacción de otros ingenieros fue inmediata. Muchos señalaron que la dispersión de las métricas de observabilidad es una de las partes más frustrantes al monitorear sistemas, con definiciones repartidas por infinidad de repositorios de GitHub, paquetes de exportadores y páginas de documentación. Incluso profesionales con experiencia tienen que pelear a veces para averiguar el significado exacto de una métrica concreta.
Un desarrollador lo resumió con sencillez: reunir la información de métricas de Prometheus y OpenTelemetry en un único lugar hace que resulte mucho más fácil planificar las estrategias de monitoreo antes de desplegar nueva infraestructura.
Ese comentario apunta a algo más amplio. La observabilidad ha madurado enormemente durante la última década. Las herramientas para recopilar telemetría son potentes y los sistemas de almacenamiento pueden gestionar volúmenes gigantescos de datos. Entender las señales en sí, en cambio, sigue siendo sorprendentemente complicado.
Por qué la documentación de observabilidad sigue tan fragmentada
Parte del problema radica en cómo evolucionaron estos ecosistemas. La mayoría de los exportadores y librerías de instrumentación fueron creados de forma independiente por comunidades distintas, y cada proyecto documentó sus métricas en el formato que mejor encajaba en ese momento. Algunos usan archivos de metadatos estructurados, otros integran descripciones en el código fuente y otros dependen de documentación autogenerada. Muy pocos siguen un estándar universal.
Incluso OpenTelemetry, cuyo objetivo es estandarizar la telemetría en distintos lenguajes y frameworks, todavía contiene muchos paquetes de instrumentación independientes mantenidos por equipos diferentes.
Nadie tiene la culpa real de esa fragmentación, pero genera un problema evidente de descubrimiento para quien intenta entender sus sistemas de monitoreo.
La escala de las métricas modernas
Un detalle del proyecto del registro muestra la rapidez con la que se multiplican las métricas. Solo el exportador de nodos de Prometheus expone más de quinientas métricas del sistema que cubren uso de CPU, presión sobre la memoria, E/S de disco y actividad de red. Los componentes de monitoreo de Kubernetes suman cientos de señales adicionales sobre pods, nodos y el estado del clúster, y la instrumentación de las aplicaciones agrega métricas de peticiones, distribución de latencias, tasas de errores y señales de negocio personalizadas.
Para un sistema con una complejidad moderada es fácil llegar a miles de métricas. La mayoría de los equipos de ingeniería solo monitorea de forma activa una pequeña parte, y el resto permanece en la sombra hasta que algo falla.
El siguiente reto de la observabilidad: la capacidad de descubrimiento
Durante años, el sector de la observabilidad se centró en tres desafíos técnicos: cómo recopilar la telemetría, cómo almacenarla y cómo visualizarla. Esos problemas están en gran medida resueltos.
El siguiente reto puede ser la capacidad de descubrimiento. Los ingenieros necesitan mejores métodos para entender la telemetría que sus sistemas son capaces de generar, con herramientas que expliquen qué señales existen, de dónde proceden y qué significan. Los registros de métricas suponen un paso inicial hacia ese objetivo, transformando la observabilidad de un juego de adivinanzas en algo más parecido a una base de conocimiento consultable.
El paso hacia sistemas de conocimiento de observabilidad
A medida que los ecosistemas de observabilidad se vuelven más complejos, las herramientas que estructuran el conocimiento sobre telemetría pueden llegar a ser tan importantes como las que la recopilan. Quizá los ingenieros empiecen a tratar las métricas como información estructurada en lugar de señales aisladas: de dónde surgió una métrica, qué sistema la emitió, qué mide y qué alertas suelen depender de ella.
Responder a esas preguntas con rapidez podría acelerar la depuración y hacer más eficaces las estrategias de monitoreo, además de ahorrar horas buscando en repositorios.
Lo que muestra el registro
A primera vista, un catálogo de métricas con buscador puede sonar a proyecto de nicho. Sin embargo, dice mucho sobre la infraestructura moderna: hemos aprendido a generar telemetría de forma increíble y todavía estamos aprendiendo a entenderla.
Hasta que los ingenieros puedan responder fácilmente a la pregunta "qué métricas produce mi sistema", la observabilidad seguirá teniendo una parte de ciencia y otra de trabajo detectivesco.