¿Qué son las métricas de OpenTelemetry?

Al igual que los logs y rastreos de OpenTelemetry, las métricas de OTel proporcionan señales de telemetría estandarizadas que usan un modelo de datos y un protocolo de transmisión comunes e independientes del idioma —OpenTelemtetry Protocol (OTLP), para ser exactos— para ingerir datos de diferentes fuentes, sistemas y formatos y enviarlos a los backends de observabilidad. 

Las métricas de OTel dependen de la instrumentación OpenTelemetry para recopilar datos de series temporales —como el uso de CPU y memoria, el rendimiento, las tasas de error, el número de solicitudes y los tiempos de respuesta— de aplicaciones y componentes de infraestructura mientras se ejecutan. Después de que los desarrolladores instrumenten el código para registrar las métricas necesarias, OTel permite que esas métricas se agreguen y exporten a cualquier herramienta (o a todas) de observabilidad de backend para almacenamiento, consulta y visualización, sin cambiar la instrumentación.

Las métricas suelen ser las primeras señales de telemetría que revelan un problema del sistema. En el marco OTel, están integrados con logs (registros inmutables de eventos discretos del sistema) y rastreos (el recorrido de extremo a extremo de una solicitud de datos) que se basan en los mismos conceptos y metadatos.

Estas dinámicas permiten a los desarrolladores y a los ingenieros de confiabilidad del sitio (SRE) utilizar métricas como un sistema de alerta temprana de alto nivel. Pueden seguir la ruta completa de una falla (incluidas las métricas para cada servicio con el que interactuó el componente fallido) en una vista coherente y pueden cambiar rápidamente a rastreos y logs para el análisis de causa principal.

En la práctica, eso significa que los equipos de TI pueden pasar de “este endpoint es lento” a “estas solicitudes y dependencias específicas son el problema” con solo unos pocos clics.

Además, los protocolos de estandarización de OTel facilitan la correlación automatizada de señales entre proveedores de observabilidad, lo que brinda a las empresas la flexibilidad de cambiar las herramientas de observabilidad cada vez que elijan o utilicen varias herramientas simultáneamente.

Las métricas de OpenTelemetry son un componente fundamental de OpenTelemetry. OpenTelemetry es un marco de observabilidad de código abierto que incluye una colección de kits de desarrollo de software (SDK), interfaces de programación de aplicaciones (API) neutrales respecto al proveedor y otras herramientas para la instrumentación de aplicaciones, sistemas y dispositivos.

El código de instrumentación solía variar ampliamente, y ningún proveedor comercial ofrecía una herramienta capaz de recopilar datos de cada aplicación y servicio en una red. Esta brecha de funcionalidad dificultaba (y, a menudo, imposibilitaba) que los equipos recopilaran datos de diferentes lenguajes de programación, formatos y entornos de tiempo de ejecución.

Los enfoques tradicionales de observabilidad también hicieron que cambiar la infraestructura y los componentes de backend fuera un proceso que requería mucho tiempo y trabajo.

Digamos que un equipo de desarrollo quería cambiar las herramientas de backend. Tendrían que volver a instrumentar completamente su código y configurar nuevos agentes (componentes de software que ejecutan tareas automatizadas de compilación y lanzamiento) para enviar datos de telemetría a los nuevos servidores. Los enfoques fragmentados creaban silos de datos y confusión, lo que dificultaba la resolución eficaz de los problemas de rendimiento.

OpenTelemetry representó un avance significativo en las herramientas de observabilidad porque estandarizó la forma en que se recopilan, analizan y transmiten los datos de telemetría a las plataformas de backend. Proporcionó una solución de código abierto (basada en estándares impulsados por la comunidad) para recopilar datos sobre el comportamiento y la seguridad del sistema, ayudando a los equipos a optimizar el monitoreo y la observabilidad en ecosistemas distribuidos.

Las métricas de OpenTelemetry se basan en un grupo de componentes relacionados que, en conjunto, definen cómo se producen, describen y envían las métricas a los backends de observabilidad. Por ejemplo:

Los instrumentos son las herramientas que utiliza el código para registrar valores métricos. Registran valores de dos maneras: sincrónicamente (de forma directa en la ruta de ejecución, a medida que se ejecuta el código) y asincrónicamente (siempre que el SDK solicite valores del código).

Debido a que se ejecutan en línea con la operación, los instrumentos sincrónicos pueden capturar el contexto de seguimiento actual y los atributos sobre el evento, lo que facilita la correlación de las métricas que recopilan con logs y rastreos.

Los instrumentos asíncronos se actualizan mediante funciones de devolución de llamada basadas en extracción que el SDK llama en un intervalo de recopilación predeterminado. Estos instrumentos son útiles para registrar valores que se muestrean periódicamente, en lugar de cada solicitud del usuario (uso de CPU o memoria, por ejemplo). 

La instrumentación de OTel se encuentra entre la lógica de la aplicación y el pipeline de métricas, convirtiendo eventos, como “solicitud HTTP completada”, en mediciones estructuradas que el SDK puede agregar y exportar. Cada tipo de instrumento métrico está optimizado para un patrón de medición específico y tiene una estrategia de agregación asociada que describe cómo el SDK debe combinar mediciones individuales en métricas exportadas.

Algunos tipos de instrumentos comunes son:

• Los contadores son instrumentos síncronos que registran incrementos que aumentan con el tiempo (como el número total de solicitudes o el total de bytes enviados desde el inicio del proceso). Los contadores también son monótonos, así que cada vez que registran una nueva medida, la suman al valor existente en lugar de reemplazarlo.

• Los contadores UpDown son instrumentos sincrónicos que registran valores que pueden aumentar o disminuir con el tiempo (número de usuarios activos o tamaño de cola, por ejemplo). A diferencia de los contadores estándar, los contadores UpDown no son monótonos, por lo que ajustan los totales hacia arriba o hacia abajo reemplazando los valores existentes.

• Los contadores asíncronos y los contadores asíncronos UpDown son similares a sus contrapartes síncronas, pero registran valores una vez por exportación en lugar de recopilarlos durante la ejecución del código.

• Los medidores son instrumentos síncronos que registran valores que pueden aumentar o disminuir arbitrariamente en cada envío de datos, representando los valores en el momento en que se recopilan del código. Además de los medidores síncronos, la recopilación de métricas requiere medidores observables, que son instrumentos asíncronos que extraen valores actuales cada vez que el backend de métricas recopila datos.
  
  Los medidores capturan instantáneas de valores de la misma manera que las cámaras capturan instantáneas de su objeto previsto. Y debido a que los medidores no son acumulativos, generalmente se aplican a valores no aditivos donde la suma no tendría sentido (uso de memoria o temperatura, por ejemplo).  

• Los histogramas son instrumentos síncronos que capturan cuántas mediciones se encuentran en diferentes rangos de valores, en lugar de seguir un solo número (como un valor total o actual). Ponen valores en “buckets”, lo que permite a los equipos de TI calcular percentiles y comprender la distribución de valor para métricas como la duración de la solicitud, la latencia y el tamaño de la carga útil.

OTel define un modelo de datos de métricas estandarizado y series temporales que convierten los eventos de métricas individuales en series de números limpias, consultables y basadas en el tiempo que los equipos de TI pueden almacenar y analizar en plataformas de observabilidad.

OpenTelemetry describe las métricas mediante el uso de tres modelos relacionados: el modelo de eventos (mediciones sin procesar de instrumentos), el modelo de flujo OTLP (cómo se agrupan y envían esas mediciones) y el modelo de series temporales (cómo las almacenan los backends).

En la práctica, el código de aplicación registra eventos usando el modelo Event, el SDK/Collector los convierte en flujos OTLP y la plataforma backend los almacena como series temporales, como “solicitudes por segundo para el servicio X con estado 200” a lo largo del tiempo.

Las convenciones semánticas, también llamadas convenciones de nomenclatura, definen nombres estandarizados, unidades y claves de atributos para métricas comunes, de modo que diferentes servicios y bibliotecas produzcan telemetría coherente. Por ejemplo, las convenciones prescriben nombres como “http.server.duration” para la latencia de la solicitud del servidor HTTP y recomendar unidades como segundos o milisegundos para la duración.

El uso de las convenciones semánticas de OTel permite a los equipos introducir métricas en paneles prediseñados y sistemas de alerta que esperan un esquema específico, lo que reduce el tiempo que dedican a realizar trabajos de configuración personalizados. También facilita la colaboración entre equipos porque todos hablan el mismo “lenguaje de métricas” en todos los microservicios.

Además, las características de propagación de contexto pueden vincular métricas con rastreos relacionados (mediante el uso de ejemplares) y logs al llevar contexto compartido, como identificadores de rastreo o tramo, a través de los límites de servicio.

Por ejemplo, un propagador OTel puede extraer el contexto entrante de un controlador de solicitudes, iniciar un tramo de rastreo con este y usar el mismo contexto para registrar métricas de latencia y escribir entradas de log. De esta forma, tanto el punto de la métrica como la línea del registro quedan etiquetados con el rastreo actual.

Cuando el código de la aplicación realiza una llamada descendente, el propagador inyecta el mismo contexto en la solicitud saliente. El código lo extrae, inicia su propio tramo secundario y utiliza ese contexto para sus propias métricas y logs, lo que mantiene todo, desde ambos servicios vinculado al mismo rastreo de extremo a extremo.

Los atributos, también conocidos como etiquetas o dimensiones, son pares clave-valor adjuntos a mediciones individuales o puntos de datos agregados. Definen total o parcialmente una serie temporal junto con el nombre de la métrica, el tipo de agregación y la unidad. Sin atributos, todas las mediciones de una métrica colapsarían en una serie indiferenciada.

Agregar atributos (como el nombre del servicio, el endpoint, el código de estado HTTP, la región o el ID de inquilino) convierte las métricas simples en flujos de métricas dimensionales y especializados que los equipos pueden dividir y analizar en herramientas de observabilidad. Los equipos pueden obtener vistas de alta resolución filtradas o agrupadas por cualquier dimensión que elijan.

Un buen diseño de atributos también equilibra los detalles con la cardinalidad métrica (la cantidad de valores únicos que puede tomar un atributo), para que los equipos puedan evitar la explosión de etiquetas sin dejar de ejecutar consultas útiles.

Una medición es una lectura única a nivel de evento tomada por un instrumento en un momento específico y, a menudo, acompañada de atributos. Por ejemplo, cuando termina una solicitud HTTP, puede registrar una latencia de 120 milisegundos con atributos como ruta=”/inicio de sesión” y código_de_estado=200 que representan la ruta y el código de estado.

Cada registro individual es una medición separada que describe lo que ocurrió durante esas operaciones.

Las mediciones se almacenan brevemente dentro del SDK, que luego convierte las mediciones sin procesar en puntos de datos dentro de flujos de métricas más grandes. En lugar de mostrar cada solicitud, un punto de datos agregado podría mostrar “para ruta /inicio de sesión con estado 200, de 10:00:00-10:00:10, hubo 500 solicitudes con una duración total de 25 segundos”. Son estos puntos de datos los que finalmente se exportan y almacenan en backends de observabilidad.

La API de métricas de OpenTelemetry es el conjunto de interfaces que el código de la aplicación llama para producir métricas. Está diseñado para ser independiente del proveedor, desacoplando la instrumentación de la implementación concreta del SDK. Los equipos de TI pueden escribir instrumentación una vez (mediante la API estándar) y luego intercambiar SDK, exportadores y backends sin tomar medidas adicionales.

Tres interfaces principales forman la estructura de la API de métricas de OTel: proveedores de medidores, medidores e instrumentos métricos.

Los proveedores de medidores son el punto de entrada de la API y son responsables de crear instancias de medidores. Determinan qué lectores y exportadores de métricas usar, qué vistas y agregaciones aplicar y con qué frecuencia recopilar y exportar datos. El proveedor de medidores suele cargarse una vez durante el inicio de la aplicación (a menudo como un proveedor global), por lo que todos los medidores e instrumentos comparten definiciones de recursos coherentes y pipelines de exportación.

Los medidores son los objetos que el código de aplicación utiliza para crear contadores, histogramas e indicadores. Cada medidor suele llevar el nombre de una biblioteca o servicio (por ejemplo, “banco.pago”), para que las métricas procedentes de ese código puedan agruparse e identificarse de forma coherente.

Los medidores no almacenan datos por sí mismos; en cambio, sirven como fábricas de instrumentos y pasan las mediciones registradas al SDK subyacente para su agregación y exportación. Dado que los medidores se obtienen de un proveedor de medidores, siempre funcionan con la configuración, las vistas y los exportadores definidos por el proveedor.

Luego, los instrumentos proporcionan instrucciones para que el código pueda reportar mediciones con atributos.

El SDK de OpenTelemetry es una implementación concreta de la API de OpenTelemetry que convierte las llamadas a la API en puntos de datos de telemetría reales. Proporciona una biblioteca específica del lenguaje (como Java™ o Python) que recopila, agrega y prepara datos métricos para su exportación.

Los SDK gestionan los ciclos de vida de la instrumentación, manejan el almacenamiento en memoria para mediciones, ejecutan devoluciones de llamada para instrumentos asíncronos, aplican agregaciones y vistas configuradas, y controlan los intervalos de recopilación de métricas (normalmente de 10 a 60 segundos).

Dentro del SDK, los procesadores aplican agregación y lógica adicional, incluido el filtrado, la limitación de velocidad o la transformación de las transmisiones métricas antes de enviarlas.

Los exportadores convierten los puntos de datos métricos procesados en formatos específicos de backend y los envían a backends externos o plataformas de observabilidad mediante protocolos compatibles (como OTLP).

Los equipos pueden optar por encadenar varios exportadores en el SDK para admitir múltiples backends en entornos que requieren alta disponibilidad y redundancia. En estos casos, los recopiladores de OpenTelemetry actúan como proxies inteligentes que pueden enviar métricas a varios backends simultáneamente, reintentar intentos de exportación o autenticar datos a escala. 

Las agregaciones definen cómo las mediciones individuales sin procesar se combinan matemáticamente en estadísticas resumidas que los backends almacenan y consultan como puntos de datos de series temporales. El agregador del SDK acumula los datos sin procesar en un único punto de datos por intervalo de recopilación para cada serie temporal única.

Los patrones de agregación comunes incluyen:

• Sum, que suma todos los valores para cantidades acumuladas (como bytes transferidos).

• LastValue, que solo conserva la medición más reciente, descartando las anteriores.

• Histogram aggregation, que agrupa los valores en buckets para que los equipos puedan calcular percentiles y detectar valores atípicos.

• Drop, que descarta todos los valores para protección contra datos de alta cardinalidad (datos con un alto número de valores únicos).

Las agregaciones también llevan metadatos de temporalidad, que indican a los backends cómo interpretar un valor métrico a lo largo del tiempo. Los dos tipos principales son:

• Los valores acumulados reflejan el total desde el inicio del proceso. Estos valores se restablecen solo cuando el proceso se reinicia y los backends calculan las tasas diferenciando los puntos de datos.

• Los valores delta reflejan los cambios desde la última recopilación de datos. Los backends pueden sumar deltas directamente para determinar las tasas.

Los SDK aplican automáticamente la agregación correcta en función del tipo de instrumento. También permiten a los equipos de TI cambiar de totales simples a histogramas enriquecidos u otros algoritmos sin cambiar la instrumentación.

Las métricas muestran tendencias y envían alertas, los rastreos revelan la ruta de las solicitudes y los logs proporcionan un contexto enriquecido a nivel de evento. La correlación de métricas con trazas y logs conecta las tres señales principales de observabilidad (conocidas como los “pilares de la observabilidad”) para que los equipos puedan obtener una vista en capas del comportamiento del sistema.

Las métricas pueden, por ejemplo, mostrar tendencias agregadas como “la tasa de error se disparó a las 2:15 p. m.”, pero no pueden revelar qué solicitudes fallaron o por qué. Los rastreos arrojan luz sobre las rutas problemáticas de solicitudes individuales en todos los servicios, pero sin métricas, no pueden ayudar a los equipos a determinar si una solicitud incorrecta es un valor atípico o un problema sistémico. Los registros proporcionan mensajes de error y eventos detallados, pero sin contexto son solo ruido.

La correlación de las tres señales permite a los equipos de TI pasar perfectamente de las tendencias métricas de alto nivel al rastreo afectado y los logs relacionados en segundos.

Las métricas de OTel difieren fundamentalmente de las métricas tradicionales. Las métricas tradicionales suelen referirse a enfoques de monitoreo heredados que se centran en contadores simples y predefinidos para el uso de recursos. Estas métricas enfatizan las mediciones a nivel de host o específicas de la aplicación. 

Las métricas de OpenTelemetry, por el contrario, forman parte de un marco de observabilidad unificado e independiente del proveedor que estandariza la recopilación en rastreos, logs y métricas para entornos de TI distribuidos. Se basan en métricas tradicionales al proporcionar un modelo de datos e instrumentación más flexibles, incluidos UpDownCounters para cambios bidireccionales e histogramas que admiten buckets exponenciales. También proporcionan atributos, unidades y marcas de tiempo explícitos para enriquecer las métricas.

Las métricas de OTel también son diferentes de las métricas tradicionales en términos de su diseño, métodos de recopilación y aplicabilidad a los sistemas modernos.

Las métricas tradicionales tienen una característica de modelo rígido de paquete completo que acopla estrechamente la recopilación, el almacenamiento y las consultas, a menudo utilizando valores solo acumulativos de contadores básicos, indicadores, resúmenes e histogramas con buckets explícitos (que requieren bucketing manual).

Las métricas de OpenTelemetry emplean un diseño modular de tres capas, con una API, un SDK y un protocolo, que separa la generación de señales del procesamiento y la exportación. Esta configuración permite que las métricas de OTel admitan características avanzadas, como temporalidad delta, valores enteros, metadatos mínimos y máximos en histogramas e histogramas exponenciales para escalado dinámico.

Los enfoques tradicionales se basan en la extracción de datos de los endpoints de la API expuestos, principalmente para obtener métricas de forma aislada. Utilizan instrumentación manual y ofrecen soporte limitado para rastreos o logs, lo que lleva a pipelines de telemetría y observabilidad fragmentados.

OpenTelemetry utiliza OTLP (un protocolo binario) para la recopilación de datos basada en push, lo que permite la recopilación unificada de rastreos, métricas y logs a través de instrumentación automática y manual. OTel también proporciona un recopilador para facilitar la transformación de datos, el procesamiento por lotes y el enrutamiento a herramientas de backend, lo que ayuda a los equipos de TI a tratar las preocupaciones de almacenamiento de aplicaciones.

Los datos de telemetría tradicionales funcionan bien para configuraciones simples y monolíticas. Sin embargo, fallan en entornos de microservicios debido a capacidades de rastreo deficientes, problemas de vendor lock-in (dependencia de proveedores) y señales aisladas que ocultan las dependencias y no logran descubrir fallas en cascada.

OpenTelemetry destaca en entornos distribuidos nativos de la nube, porque proporciona telemetría correlacionada e independiente del proveedor para una visibilidad de extremo a extremo de los flujos de solicitudes entre servicios, cuellos de botella de latencia y diagnósticos de recursos. OTel también admite el muestreo y la integración de herramientas híbridas, lo que ayuda a la telemetría y la instrumentación a escalar junto con el entorno de TI. 

Las métricas de OpenTelemetry proporcionan mediciones estandarizadas y cuantitativas que ayudan a mejorar la observabilidad en las arquitecturas modernas. Ofrecen insights detallados sobre el rendimiento del sistema, lo que permite a los desarrolladores e ingenieros implementar estrategias proactivas de resolución de problemas y optimización.

Otros beneficios incluyen: