Entendiendo la “observabilidad” y “OpenTelemetry “ (Telemetría abierta)— Parte 1
Artículo original en: 👉 https://nsrc.io/NodeJS_OTel1
Cada vez se habla más de OpenTelemetry (Telemetría abierta); está ganando cada vez más tracción en los círculos de desarrollo en Node.js, pero ¿qué es? ¿Cómo podemos aprovechar los conceptos clave e implementarlos en nuestros proyectos?
Cabe destacar que NodeSource es partidario de aplicar OpenTelemetry, y recientemente implementamos soporte completo del estándar de código abierto en nuestro producto N|Solid. Lo que nos permite hacer que nuestros poderosos insights sobre una aplicación de Node.js sean accesibles a través del protocolo.
Empecemos ¿Qué es OpenTelemetry?
Opentelemetry es un estándar emergente, agnóstico, relativamente reciente que comenzó en 2019 cuando OpenCensus y OpenTracing se combinaron para formar el proeycto OpenTelemetry, que busca proporcionar una superficie de integración única y bien respaldada para la telemetría de seguimiento distribuida de punta a punta. En 2021, lanzaron V1. 0.0.
Y lo más importante, OpenTelemetry es un marco/proyecto de observabilidad de código abierto con una colección de kits de desarrollo de software (SDK), API y herramientas para instrumentación de Cloud Native Computing Foundation (CNCF).
W3C Trace Context es el formato estándar para OpenTelemetry. Se espera que los proveedores de la nube adopten este estándar, proporcionando una forma neutral de propagar las identificaciones de seguimiento a través de sus servicios. Las organizaciones usan OpenTelemetry para enviar datos de telemetría recopilados a un sistema de terceros para su análisis.
Pero para desglosar un poco su historia, creemos que es importante entender el concepto de Observabilidad.
En Nodesource, como probablemente sabrá, trabajamos a diario en Observabilidad, centrándonos exclusivamente en el tiempo de ejecución de Node.js y desde N|Solid versión 4.8.0 ya admite algunas características de OpenTelemetry.
Pero antes de profundizar en OTEL (La sigla de OpenTelemtry) es importante entender la Observabilidad. así que resolvamos la pregunta ¿Qué es la observabilidad?
Sentando las bases para hablar de OpenTelemetry
Es importante entender que cuando hablamos de Observabilidad, primero necesitamos saber qué preguntas buscamos responder o aclarar al detallar un sistema.
La primera pregunta que se hace a menudo es por qué mi aplicación tiene un comportamiento específico. Y para resolver esta y otras cuestiones, primero debemos instrumentar nuestro sistema para que nuestra aplicación pueda emitir señales, es decir, trazas, métricas y registros. Cuando hacemos esto correctamente, tenemos la información necesaria.
La observabilidad es la capacidad de medir los estados internos de un sistema examinando sus salidas. — Splunk
Detallar un sistema a través de la recopilación de datos: datos de telemetría
Sus sistemas y aplicaciones necesitan las herramientas adecuadas para recopilar los datos de telemetría apropiados para lograr la Observabilidad. Pero, ¿cuáles son los datos de telemetría que necesitamos?
Los tres conceptos clave son:
- Métrica / Metrics
- Registros / Logs
- Trazas / Traces
Bien, definamos cada uno de estos conceptos:
Métricas
Son agregaciones durante un período de tiempo de datos numéricos sobre su infraestructura o aplicación. Los ejemplos incluyen la tasa de errores del sistema, la utilización de la CPU y la tasa de solicitudes para un servicio determinado.
Según lo citado por isitobservable.io, OpenTelemetry tiene tres instrumentos métricos:
- Contador: un valor que se suma a lo largo del tiempo (similar al contador Prometheus)
- Medida: un valor que se agrega a lo largo del tiempo (un valor en un rango definido).
- Observador: captura un conjunto actual de valores en un momento dado (como un indicador en Prometheus).
El contexto sigue siendo muy importante, junto con la información métrica como el nombre, la descripción, la unidad, el tipo (contador, observador, medida), la etiqueta, la agregación y el tiempo.
Registros
Un registro es un mensaje con marca de tiempo emitido por servicios u otros componentes. No están necesariamente asociados con ninguna solicitud o transacción de un usuario en particular, pero se vuelven más valiosos cuando lo están.
La línea lógica nos diría que aquí debemos saltar a las trazas porque forma parte de los tres conceptos clave. Pero antes de definir qué es una traza, debemos acercarnos al concepto de Span.
Span
Un Span representa una unidad de trabajo u operación. Realiza un seguimiento de las operaciones específicas que realiza una solicitud, pintando una imagen de lo que sucedió durante el tiempo en que se ejecutó esa operación.
Un SPAN es el componente básico de una traza y es una operación cronometrada con nombre que representa una parte del flujo de trabajo en un sistema distribuido. Todas las trazas se componen de Spans.
Trazas
Una traza registra las rutas que toman las solicitudes (realizadas por una aplicación o un usuario final) a medida que se propagan a través de arquitecturas multiservicio, como microservicios y aplicaciones sin servidor. También se conoce como seguimiento distribuido.
Un seguimiento (Traza) es casi siempre una evaluación del rendimiento de un extremo a otro. Sin seguimiento, es un desafío identificar la causa de los problemas de rendimiento en un Sistema Distribuido.
Los tres pilares: Métricas, registros y trazas junto con el concepto de span se conoce como Datos de Telemetría, que son simples señales emitidas por aplicaciones y recursos sobre su estado interno.
El concepto clave de la propagación del contexto
*Context Propagation
Cuando queremos correlacionar eventos a través de los límites de nuestros servicios, buscamos un contexto que nos ayude a identificar el seguimiento y el intervalo actual. Pero el contexto no es lo único que necesitamos; también necesitamos propagación.
Si estás con nosotros siguiendo detenidamente el artículo, te darás cuenta de que en la definición de trazas hablamos de la palabra ‘propagación’.
La propagación es cómo se agrupa y transfiere el contexto en y entre servicios, a menudo a través de encabezados HTTP. Ahora, con estos conceptos claros, podemos empezar a entender el concepto de Propagación de Contexto.
Una funcionalidad crítica requerida para implementar el seguimiento distribuido es el concepto de propagación de contexto. Podemos definirlo como un mecanismo para almacenar los estado y acceder a datos a lo largo de la vida útil de una transacción distribuida, ya sea a través de contextos de ejecución dentro de un proceso o a través de los límites de los servicios que se ajustan a nuestro sistema.
La propagación de Contexto, puede dar directamente en el proceso o a lo largo del proceso.
- Para la propagación en proceso, normalmente usamos algo como la clase AsyncLocalStorage del módulo async_hooks.
- Mientras que Propagación a lo largo del proceso, dependerá del protocolo IPC utilizado. Por ejemplo, para HTTP, existe la especificación Trace Context del W3C, que define los encabezados traceparent y tracestate para propagar la información de seguimiento.
Revisemos una aplicación distribuida a profundidad
Digamos que tenemos una aplicación distribuida como la siguiente imagen.
Tiene 4 servicios Nodejs: API, auth, Servicio1 y Servicio2, y 1 base de datos.
Imagina que tenemos problemas de rendimiento intermitentes. Pueden provenir de varios puntos:
- — Acceso a la base de datos
- — Estado del enlace de la red
- — Latencia de solicitud de DNS, etc.
Encontrar dónde exactamente puede convertirse en una tarea muy difícil y que requiere mucho tiempo; será más difícil, cuanto más complejo es el sistema.
El rastreo distribuido ( Ditributed Tracing) nos ayudará MUCHO con eso, ya que generaremos información de rastreo en cada punto del sistema distribuido (A, B, C, D y E). No solo eso, sino que mientras la solicitud pasa por todos los servicios, gracias a la Propagación de contexto, se transmitirá un “estado de seguimiento” para que toda la información de seguimiento pueda vincularse a la misma solicitud.
Instrumenta tu sistema
Para obtener visibilidad del rendimiento y los comportamientos de los diferentes microservicios, necesitamos instrumentar el código con OpenTelemetry para generar seguimientos. Pero primero, definamos qué es Instrumentación…
Instrumentación Automática
Con la instrumentación automática, nuestras bibliotecas de instrumentación tomarán automáticamente la configuración proporcionada (mediante código o variables de entorno) y realizarán la mayor parte del trabajo.
En el siguiente ejemplo, usando OpenTelemetry SDK, mostramos cómo podemos generar intervalos automáticamente para cada transacción HTTP manejada por el módulo central HTTP de Nodejs.
Instrumentación Manual
La instrumentación manual, por otro lado, aunque requiere más trabajo por parte del usuario/desarrollador, permite muchas más opciones de personalización, desde nombrar varios componentes dentro de OpenTelemetry (por ejemplo, tramos y trazas) hasta agregar sus propios atributos, manejo de excepciones específico, y más. Consulte el siguiente ejemplo que muestra cómo generar manualmente un intervalo con el SDK de OpenTelemetry.
Cómo implementar Opentelemetry en mi proyecto?
La forma en que históricamente implementaríamos un pipeline de observabilidad típica se muestra en la siguiente imagen.
En este caso, tener todos esos datos a su disposición es excelente y puede brindarnos una valiosa descripción general de nuestro sistema, pero a menos que podamos correlacionar las señales de observabilidad de alguna manera: métricas, registros y seguimientos, no podremos tener lo mejor de ella.
OpenTelemetry viene a solucionar este problema.
La solución vendrá de correlacionar estas señales.
Esto se puede hacer aplicando el mismo concepto de Propagación de Contexto que se usó para seguimientos a Métricas y Registros, por lo que en este caso, los identificadores como trace_id y span_id se asocian con esas señales.
OpenTelemetry spanId y traceId pueden correlacionar registros y métricas con un intervalo específico en un seguimiento.
Los Componentes de telemetría abierta
OpenTelemetry es mucho más… Antes de terminar este artículo, es importante describir los diferentes componentes de OpenTelemetry.
Nota: Para obtener más detalles, lea la descripción general de las especificaciones del proyecto Opentelemetry.
- API de OpenTelemetry: Proporciona una API que define tipos de datos y operaciones para generar y correlacionar datos de rastreo, métricas y registro.
💚 Desde N|Solid 4.8.0 proporcionamos una implementación de OpenTelemetry TraceAPI, lo que permite a los usuarios instrumentar su propio código utilizando la API estándar de facto.
- OpenTelemetry SDK: proporciona implementaciones de la API específicas del idioma.
- OpenTelemetry OTLP: un protocolo para transportar los datos de telemetría.
💚 Con N|Solid 4.8.0 admitimos muchos módulos de instrumentación disponibles en el ecosistema OpenTelemetry. Así que tenemos compatibilidad con la exportación de datos de seguimientos mediante el protocolo OpenTelemetry (OTLP) a través de HTTP.
- OpenTelemetry Collector: para recibir, procesar y exportar datos de telemetría.
💚 En N|Solid 4.8.0 ahora es posible enviar información de monitoreo de N|Solid Runtime (métricas y seguimientos) a backends compatibles con el estándar OpenTelemetry como múltiples APMS (Dynatrace, Datadog, Newrelic).
- Convenciones semánticas de OpenTelemetry: Esto consiste en tener nombres bien definidos para los atributos asociados con las señales: (servicio.nombre, http.puerto, etc.)
Sabemos que puede haber otros conceptos clave a desarrollar en torno a Opentelemetry, y por ello te invitamos a visitar la web del proyecto o directamente el Github Repo.
Este artículo introductorio nos brinda la base para compartir una demostración que preparamos para NodeConf.EU, donde aplicamos herramientas de código abierto para implementar Opentelemetry en su proyecto. Te invitamos a estar atento a nuestra próxima publicación en el blog. 😉 ¡Espera la segunda parte!
Más información sobre este texto de origen en: https://nodesource.com/
Conclusiones
- Las trazas son realmente útiles para comprender los sistemas distribuidos modernos.
- Creamos un mejor software cuando obtenemos lo mejor de nuestros trazas.
- Con OTel (Opentelemetry), podemos tener información maximizada y responder preguntas futuras sin tener que hacer ningún cambio en el código.
- #OTel brinda interoperabilidad con herramientas de observabilidad.
Recopilar y correlacionar datos de telemetría es fácil si sigue el marco OpenTelemetry. - Por lo que sabemos, la comunidad de OpenTelemetry está trabajando arduamente para desarrollar soporte para métricas y registros. Esperando noticias pronto! 🤞
Nota: Si desea obtener más información sobre OpenTelemetry en Javascript, haga clic AQUÍ
Para comenzar a obtener más valor de sus seguimientos y métricas, puede usar Opentelemetry con N|Solid back-end.
¡Nos encantaría saber más de ti! 💚 — No dude en activar N|Solid y ponerse en contacto con nosotros en Twitter @nodesource.
