¿Qué son las métricas de OpenTelemetry?

Al igual que los registros y trazas de OpenTelemetry , las métricas de Otel proporcionan señales de telemetría estandarizadas que utilizan un modelo de datos y un protocolo de transmisión comunes e independientes del idioma (el protocolo de OpenTelemetry (OTLP) para ser exactos) para consumir datos de diferentes fuentes, sistemas y formatos y enviarlos a los backends de observabilidad. 

Las métricas OTel dependen de la instrumentación OpenTelemetry para recopilar datos de series temporales, como el uso de CPU y memoria, el rendimiento, 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 agregar y exportar esas métricas a cualquier (o a todas) herramientas de observabilidad de backend para su almacenamiento, consulta y visualización, todo ello 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 "traces" (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 e ingenieros de confiabilidad de sitios (SRE) utilizar las métricas como un sistema de alerta temprana de alto nivel. Pueden seguir la trayectoria completa de un fallo (incluyendo las métricas de cada servicio con el que interactuó el componente fallido) en una vista coherente y pivotar rápidamente a trazas y registros para el análisis de causa raíz.

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" en solo unos 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) independientes del proveedor y otras herramientas para la instrumentación de aplicaciones, sistemas y dispositivos.

El código de instrumentación solía variar mucho y ningún proveedor comercial ofrecía una herramienta capaz de recopilar datos de todas las aplicaciones y servicios de 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 del backend fuera un proceso que consumiera mucho tiempo y trabajo.

Supongamos que un equipo de desarrollo quisiera cambiar las herramientas de backend. Tendrían que reinstrumentar por completo su código y configurar nuevos agentes (componentes de software que ejecutan tareas automatizadas de creación y publicación) 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 la la monitorización y la observabilidad en ecosistemas distribuidos.

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

Los instrumentos son las herramientas que el código utiliza para registrar los valores de las métricas. Registran valores de dos maneras: de forma síncrona (directamente en la ruta de ejecución, a medida que se ejecuta el código) y de forma asíncrona (siempre que el SDK solicite valores del código).

Como se ejecutan en línea con la operación, los instrumentos síncronos pueden capturar el contexto de rastreo actual y los atributos del evento, lo que facilita la correlación de las métricas que recopilan con los registros y las trazas.

Los instrumentos asíncronos se actualizan mediante funciones de devolución de llamada basadas en pull a las 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 sitúa entre la lógica de la aplicación y el pipeline de métricas, convirtiendo eventos como "solicitud HTTP completada" en medidas estructuradas que el SDK puede agregar y exportar. Cada tipo de instrumento de métricas está optimizado para un patrón de medición específico y cuenta con una estrategia asociada que describe cómo el SDK debe combinar mediciones individuales en métricas exportadas.

Los tipos de instrumentos más comunes son:

• Los contadores son instrumentos síncronos que registran los 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, por lo que cada vez que registran una nueva medición, la añaden al valor existente en lugar de reemplazar el valor existente.

• Los contadores UpDown son instrumentos síncronos que registran valores que pueden aumentar o disminuir con el tiempo (el número de usuarios activos o el tamaño de las colas, 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 de upDown son similares a sus contrapartes síncronas, pero registran los valores una vez por exportación en lugar de recogerlos durante la ejecución del código.

• Los indicadores son instrumentos síncronos que registran valores que pueden aumentar o disminuir arbitrariamente cada vez que se introducen datos, y representan los valores en el momento en que se recopilan del código. Además de los indicadores síncronos, la recopilación de métricas requiere indicadores 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 manera muy similar a como las cámaras capturan instantáneas de su sujeto previsto. Y como los indicadores no son acumulativos, normalmente se aplican a valores no aditivos en los que la suma no tendría sentido (uso de memoria o temperatura, por ejemplo).  

• Los histogramas son instrumentos síncronos que capturan el número de medidas incluidas en diferentes rangos de valores, en lugar de rastrear un solo número (como un valor total o actual). Ponen los valores en "grupos", lo que permite a los equipos de TI calcular los percentiles y entender la distribución de valores de métricas como la duración de las solicitudes, la latencia y el tamaño de la carga útil.

OTel define un modelo de datos de métricas estandarizado y una serie temporal que convierte 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 utilizando tres modelos relacionados: el modelo de eventos (medidas sin procesar de los 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 la aplicación registra eventos utilizando 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, unidades y claves de atributos estandarizados 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 las solicitudes del servidor HTTP y recomienda unidades como segundos o milisegundos para la duración.

Utilizar las convenciones semánticas de OTel permite a los equipos introducir métricas en paneles de control y sistemas de alertas 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" entre microservicios.

Además, las características de propagación de contexto pueden vincular métricas con trazas relacionadas (mediante el uso de ejemplares) y registros transportando contexto compartido, como identificadores de rastreo o intervalo, a través de Boundary.

Por ejemplo, un propagador OTel puede extraer el contexto entrante de un controlador de solicitudes, iniciar un tramo de rastreo con él y utilizar el mismo contexto para registrar métricas de latencia y escribir entradas de registro. De esa forma, tanto la métrica como la línea de registro se etiquetan con la traza actual.

Cuando el código de la aplicación realiza una llamada downstream, el propagador inyecta el mismo contexto en la solicitud saliente. El código lo extrae, inicia su propio span hijo y usa ese contexto para sus propias métricas y registros, lo que mantiene todo lo de ambos servicios vinculado a la misma traza de extremo a extremo.

Los atributos (también conocidos como etiquetas o dimensiones) son pares clave-valor que se adjuntan a medidas 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 medidas de una métrica colapsarían en una serie indiferenciada.

Añadir atributos (como nombre del servicio, endpoint, código de estado HTTP, región o ID de inquilino) convierte métricas simples en flujos métricos dimensionales y especializados que los equipos pueden 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 (el número de valores únicos que puede tomar un atributo), de modo 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, puedes registrar una latencia de 120 milisegundos con atributos como route="/login" y status_code=200 que representan el código de ruta y estado.

Cada grabación individual es una medida independiente que describe lo que ocurrió durante esa operación.

Las mediciones se almacenan brevemente dentro del SDK, que luego convierte las mediciones en bruto en puntos de datos dentro de flujos de métricas mayores. En lugar de mostrar cada solicitud, un punto de datos agregado podría mostrar "para la ruta /inicio de sesión con estado 200, de 10:00:00 a 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 a las que llama el código de la aplicación para producir métricas. Está diseñado para ser independiente del proveedor, desvinculando la instrumentación de la implementación concreta del SDK. Los equipos de TI pueden escribir la instrumentación una vez (utilizando la API estándar) y luego intercambiar SDK, exportadores y backends sin necesidad de realizar pasos adicionales.

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

Los proveedores de contadores son el punto de entrada de la API y se encargan de crear las instancias de contadores. Determinan qué lectores y exportadores de métricas utilizar, 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 y medidores. Cada medidor suele llevar el nombre de una biblioteca o servicio (por ejemplo, “bank.payment”), 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 su lugar, 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.

A continuación, los instrumentos proporcionan instrucciones para que el código pueda informar de las 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, gestionan el almacenamiento en memoria para las 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, incluyendo el filtrado, la limitación de velocidad o la transformación de los flujos de métricas antes de enviarlos hacia adelante.

Los exportadores convierten los puntos de datos de métricas 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 múltiples exportadores en el SDK para soporte multi-backend 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 se combinan matemáticamente las mediciones individuales en bruto 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:

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

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

• La agregación de histogramas, que agrupa los valores en grupos para que los equipos puedan calcular los percentiles y detectar los valores atípicos.

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

Las agregaciones también transportan 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 solo se restablecen cuando el proceso se reinicia y los backends calculan las velocidades 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 pasar de totales simples a histogramas enriquecidos u otros algoritmos sin modificar la instrumentación.

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

Las métricas pueden, por ejemplo, mostrar tendencias agregadas como "la tasa de error se disparó a las 14:15", pero no pueden revelar qué solicitudes fallaron ni por qué. Las trazas arrojan luz sobre las rutas problemáticas de solicitudes individuales entre servicios, pero sin métricas, no pueden ayudar a los equipos a determinar si una petición incorrecta es un valor atípico o un problema sistémico. Los registros proporcionan mensajes de error y eventos detallados, pero sin contexto no son más que ruido.

La correlación de las tres señales permite a los equipos de TI pasar de manera fluida, en cuestión de segundos, de las tendencias de las métricas de alto nivel a la traza afectada y a los registros relacionados.

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

Las métricas de OpenTelemetry, en cambio, forman parte de un marco unificado de observabilidad independiente del proveedor que estandariza la recopilación entre trazas, registros 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 cubos exponenciales. También proporcionan atributos explícitos, unidades y marcas de tiempo 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 presentan una característica de modelo full stack rígido que combina estrechamente la recopilación, el almacenamiento y la consulta, a menudo usando valores acumulados solo de contadores básicos, calibres, 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 la temporalidad delta, los valores enteros, los metadatos mínimos y máximos en histogramas e histogramas exponenciales para el escalado dinámico.

Los enfoques tradicionales se basan en la extracción de datos basada en extracción de endpoint de API expuestos, principalmente para métricas en aislamiento. Utilizan instrumentación manual y ofrecen soporte limitado para trazas o registros, lo que conduce 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 trazas, métricas y registros a través de instrumentación automática y manual. OTel también proporciona un Collector 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 abordar la dirección de almacenamiento de aplicación.

Los datos de telemetría tradicionales funcionan bien en configuraciones simples y monolíticas. Sin embargo, fallan en entornos de microservicios debido a capacidades de rastreo deficientes, problemas de vendor lock-in 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 y 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 soporta la integración de muestreo y herramientas híbridas, lo que ayuda a que la telemetría y la instrumentación escalen junto con el entorno informático. 

Las métricas de OpenTelemetry proporcionan mediciones estandarizadas y cuantitativas que ayudan a mejorar la observabilidad en las arquitecturas modernas. Ofrecen una perspectiva detallada 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: