En el pasado, cuando hablábamos del backend, normalmente nos referíamos a una aplicación grande con una única base de datos grande, y el registro era suficiente para el monitoreo. Ahora, gracias a tecnologías como   ,   se han convertido en el estándar. Las aplicaciones son más numerosas y distribuidas, y el registro tradicional ya no es suficiente para   y diagnosticar problemas en nuestras aplicaciones. Kubernetes los microservicios depurar  Una excelente solución para organizar el monitoreo es OpenTelemetry, un conjunto de herramientas moderno que se puede utilizar para la depuración y el análisis del rendimiento de sistemas distribuidos.  Este artículo está dirigido a profesionales de TI que buscan ampliar sus conocimientos en optimización de backend. A continuación, detallaremos qué es OpenTelemetry, sus conceptos clave y los problemas que ayuda a resolver. Si está interesado en saber cómo OpenTelemetry puede cambiar su enfoque para monitorear y depurar sistemas backend, mejorando su confiabilidad y eficiencia, siga leyendo.  Una breve historia de OpenTelemetry  Las grandes empresas de tecnología enfrentaron por primera vez el desafío del registro y rastreo distribuidos a fines de la década de 2000. En 2010, Google publicó un artículo,  , que sentó las bases para la herramienta de rastreo de Twitter, Zipkin, lanzada en 2012.   Dapper, una infraestructura de seguimiento de sistemas distribuidos a gran escala  En 2014, surgió Kubernetes, que simplificó significativamente el desarrollo de microservicios y otros sistemas distribuidos en la nube. Esto llevó a que muchas empresas encontraran problemas con el registro y seguimiento distribuidos en microservicios. Para estandarizar el rastreo distribuido, se creó el estándar OpenTracing, adoptado por CNCF, y el proyecto OpenCensus de Google.  En 2019, los proyectos OpenTracing y OpenCensus anunciaron una fusión bajo el nombre OpenTelemetry. Esta plataforma combina las mejores prácticas acumuladas durante muchos años, lo que permite una integración perfecta de seguimiento, registro y métricas en cualquier sistema, independientemente de su complejidad.  Hoy en día, OpenTelemetry no es sólo un proyecto; es un estándar de la industria para recopilar y transmitir datos de telemetría. Está desarrollado y respaldado por una comunidad de especialistas y empresas líderes del mercado como Google y Microsoft. El proyecto continúa evolucionando, ganando nuevas capacidades para simplificar el proceso de integración y uso.    ¿Qué hay adentro?  OpenTelemetry es un conjunto integral de prácticas y herramientas que definen qué señales puede generar una aplicación para interactuar con el mundo exterior y cómo estas señales se pueden recopilar y visualizar para monitorear el estado de las aplicaciones y el sistema en su conjunto. Los tres tipos principales de señales son   y   . el seguimiento, el registro la recopilación de métricas  **Echemos un vistazo más de cerca a cada componente: \   Contextos  OpenTelemetry introduce el concepto de contextos de operación. Un contexto incluye principalmente atributos como   (identificador de la operación actual) y   (identificador de una subsolicitud, y cada reintento de una subrequest tiene un   único). `trace_id` `span_id` `span_id`  Además, un contexto puede contener información estática, como el nombre del nodo donde se implementa la aplicación o el nombre del entorno (prod/qa). Estos campos, conocidos como recursos en la terminología de OpenTelemetry, se adjuntan a cada registro, métrica o seguimiento para facilitar la búsqueda. Los contextos también pueden incluir datos dinámicos, como el identificador del punto final actual (   ), que se pueden adjuntar selectivamente a grupos de registros, métricas o seguimientos. `http_path: "GET /user/:id/info"`  Los contextos de OpenTelemetry se pueden pasar entre diferentes aplicaciones utilizando protocolos de propagación de contexto. Estos protocolos constan de conjuntos de encabezados que se agregan a cada solicitud HTTP o gRPC o a los encabezados de mensajes de las colas. Esto permite que las aplicaciones posteriores reconstruyan el contexto de operación a partir de estos encabezados.   A continuación se muestran algunos ejemplos de propagación de contexto:    Este es un conjunto de encabezados (   ) desarrollados originalmente para el sistema de rastreo Zipkin. Fue adaptado a OpenTracing y utilizado por muchas herramientas y bibliotecas. B3-Propagation lleva   /   y una bandera que indica si es necesario el muestreo. B3-Propagación x-b3-* trace_id span_id    Desarrollado por el grupo de trabajo del W3C, este estándar unifica varios enfoques de propagación de contexto en un único estándar y es el predeterminado en OpenTelemetry. Un buen ejemplo de aplicación de estos estándares es el seguimiento de la ejecución de una solicitud que pasa a través de microservicios implementados con diferentes tecnologías sin comprometer la precisión del monitoreo y la depuración. Contexto de seguimiento del W3C   Rastreo     El seguimiento es el proceso de registrar y posteriormente visualizar la línea de tiempo de la ruta de una solicitud a través de múltiples microservicios.  En la visualización, cada barra se denomina "span" y tiene un   único. El intervalo raíz se denomina   y tiene un   , que sirve como identificador para toda la solicitud. "span_id" "rastreo" "trace_id"   Este tipo de visualización le permite:  Analice el tiempo de ejecución de solicitudes en diferentes sistemas y bases de datos para identificar cuellos de botella que necesitan optimización.  Detectar dependencias cíclicas entre servicios.  Encuentra solicitudes duplicadas. Al utilizar datos de seguimiento, también puede crear análisis adicionales, como crear un mapa de microservicios o distribuir el tiempo entre diferentes sistemas durante el procesamiento de operaciones. Incluso si no utiliza datos de seguimiento para visualizar líneas de tiempo, OpenTelemetry aún genera   y   para usar en otras señales. trace_id span_id   Registros  A pesar de su aparente simplicidad, el registro sigue siendo una de las herramientas más poderosas para diagnosticar problemas. OpenTelemetry mejora el registro tradicional agregando información contextual. Específicamente, si hay un seguimiento activo, los atributos `trace_id` y `span_id` se agregan automáticamente a los registros, vinculándolos a la línea de tiempo del seguimiento. Además, los atributos de registro pueden incluir información estática del contexto de OpenTelemetry, como el identificador del nodo, así como información dinámica, como el identificador del punto final HTTP actual ("http_path: "GET /user/:id"`).  Usando `trace_id`, puede encontrar registros de todos los microservicios asociados con la solicitud actual, mientras que `span_id` le permite diferenciar entre subsolicitudes. Por ejemplo, en el caso de reintentos, los registros de diferentes intentos tendrán diferentes `span_id`. El uso de estos identificadores permite un análisis rápido de todo el comportamiento del sistema en tiempo real, acelerando el diagnóstico de problemas y mejorando la estabilidad y confiabilidad.   Métrica  La recopilación de métricas proporciona datos cuantitativos sobre el rendimiento del sistema, como latencia, tasas de error, uso de recursos y más. El monitoreo de métricas en tiempo real le permite responder rápidamente a los cambios de rendimiento, evitar fallas y agotamiento de recursos y garantizar una alta disponibilidad y confiabilidad de la aplicación para los usuarios.  La integración con sistemas de visualización y almacenamiento de métricas como Prometheus y Grafana facilita la visualización de estos datos, lo que simplifica significativamente el seguimiento.   Colectores de métricas  Los recopiladores de métricas de OpenTelemetry son compatibles con los estándares Prometheus y OpenMetrics, lo que permite una transición fácil a las soluciones OpenTelemetry sin cambios significativos. El SDK de OpenTelemetry permite exportar ejemplos de trace_id junto con métricas, lo que permite correlacionar métricas con ejemplos de registros y seguimientos.  Correlación de señal   Juntos, los registros, las métricas y el seguimiento crean una vista integral del estado del sistema:  Los registros proporcionan información sobre eventos del sistema, lo que permite una rápida identificación y resolución de errores.  Las métricas reflejan indicadores de rendimiento cualitativos y cuantitativos del sistema, como tiempos de respuesta o tasas de error.  El seguimiento complementa esta vista al mostrar la ruta de ejecución de la solicitud a través de varios componentes del sistema, lo que ayuda a comprender sus interrelaciones. La clara correlación entre registros, seguimientos y métricas es una característica distintiva de OpenTelemetry. Por ejemplo, Grafana permite a los usuarios ver el seguimiento correspondiente y solicitar métricas al ver un registro, lo que mejora enormemente la usabilidad y eficiencia de la plataforma.   Además de los tres componentes principales, OpenTelemetry incluye los conceptos de muestreo, equipaje y gestión del contexto de operaciones.   Muestreo  En sistemas de alta carga, el volumen de registros y rastreos se vuelve enorme, lo que requiere recursos sustanciales para infraestructura y almacenamiento de datos. Para abordar este problema, los estándares de OpenTelemetry incluyen muestreo de señales: la capacidad de exportar solo una parte de los seguimientos y registros. Por ejemplo, puede exportar señales detalladas de un porcentaje de solicitudes, solicitudes de larga duración o solicitudes de error. Este enfoque permite un muestreo suficiente para elaborar estadísticas y, al mismo tiempo, ahorra importantes recursos.  Sin embargo, si cada sistema decide de forma independiente qué solicitudes monitorear en detalle, terminamos con una vista fragmentada de cada solicitud. Algunos sistemas pueden exportar datos detallados, mientras que otros pueden exportarlos sólo parcialmente o no exportarlos en absoluto.  Para resolver este problema, los mecanismos de propagación de contexto de OpenTelemetry transmiten un indicador de muestreo junto con `trace_id`/`span_id`. Esto garantiza que si el servicio inicial que recibe la solicitud del usuario decide que la solicitud debe ser monitoreada en detalle, todos los demás sistemas harán lo mismo. De lo contrario, todos los sistemas deberían exportar señales parcialmente o no para conservar recursos. Este enfoque se denomina "muestreo principal": una decisión que se toma al comienzo del procesamiento de la solicitud, ya sea de forma aleatoria o en función de algunos atributos de entrada.  Además, OpenTelemetry admite "Tail Sampling", donde todas las aplicaciones siempre exportan todas las señales en detalle, pero existe un búfer intermedio. Después de recopilar todos los datos, este búfer decide si retiene todos los datos o conserva solo una muestra parcial. Este método permite una muestra más representativa de cada categoría de solicitud (exitosa/larga/error), pero requiere una configuración de infraestructura adicional.   equipaje  El mecanismo Baggage permite transmitir pares clave-valor arbitrarios junto con   /   , pasando automáticamente entre todos los microservicios durante el procesamiento de solicitudes. Esto es útil para transmitir información adicional necesaria a lo largo de la ruta de solicitud, como información del usuario o configuración del entorno de ejecución. trace_id span_id     Ejemplo de cabecera para transmisión de equipaje según el estándar W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5   A continuación se muestran algunos ejemplos de uso de equipaje:    , como   ,   o   se puede pasar a través de todos los microservicios. Las aplicaciones pueden registrar automáticamente esta información, lo que permite realizar búsquedas de registros por contexto de usuario para la solicitud original. Pasar información de contexto empresarial userId productId deviceId    para SDK o infraestructura. Parámetros de configuración específicos    Banderas que ayudan a los balanceadores de carga a tomar decisiones de enrutamiento. Durante las pruebas, es posible que sea necesario enrutar algunas solicitudes a servidores simulados. Dado que el equipaje se transmite automáticamente a través de todos los servicios, no es necesario crear protocolos adicionales; simplemente configure una regla en el equilibrador de carga. Banderas de enrutamiento  Tenga en cuenta que, si bien el impacto de Baggage en el rendimiento es mínimo, el uso excesivo puede aumentar significativamente la carga de la red y del servicio. Elija cuidadosamente qué datos realmente necesita pasar a través de Baggage para evitar problemas de rendimiento.   Implementación de infraestructura  La implementación de OpenTelemetry a nivel de infraestructura implica integrar los backends de OpenTelemetry en la arquitectura de la aplicación y configurar la infraestructura para la agregación de datos.   El proceso consta de cuatro etapas:    En la primera etapa, los SDK de OpenTelemetry se integran directamente en las aplicaciones para recopilar métricas, registros y seguimientos, lo que garantiza un flujo continuo de datos sobre el rendimiento de cada componente del sistema. Integración de aplicaciones    Los datos recopilados se enrutan desde las aplicaciones a través de exportadores a sistemas externos para su posterior procesamiento, como sistemas de registro, monitoreo, seguimiento o análisis, según sus necesidades. Configuración de exportadores    Esta etapa puede implicar normalizar datos, enriquecerlos con información adicional y fusionar datos de diferentes fuentes para crear una vista unificada del estado del sistema. Agregación y almacenamiento    Finalmente, los datos procesados se presentan como paneles en sistemas como Grafana (para métricas y seguimientos) o Kibana (para registros). Esto permite a los equipos evaluar rápidamente el estado del sistema, identificar problemas y tendencias y configurar alertas basadas en las señales generadas. Visualización de datos  Implementación de aplicaciones  Para integrarse con una aplicación, debe conectar el SDK de OpenTelemetry adecuado para el lenguaje de programación en uso o emplear bibliotecas y marcos que admitan directamente OpenTelemetry. OpenTelemetry a menudo implementa interfaces ampliamente utilizadas de bibliotecas conocidas, lo que permite reemplazos directos. Por ejemplo, la biblioteca Micrometer se usa comúnmente para la recopilación de métricas en el ecosistema Java. El SDK de OpenTelemetry proporciona sus implementaciones de interfaces Micrometer, lo que permite la exportación de métricas sin cambiar el código de la aplicación principal. Además, OpenTelemetry ofrece implementaciones de interfaces OpenTracing y OpenCensus más antiguas, lo que facilita una migración fluida a OpenTelemetry.  Conclusión  En los sistemas de TI, OpenTelemetry puede convertirse en la clave para el futuro de backends confiables y eficientes. Esta herramienta simplifica la depuración y el monitoreo y también abre oportunidades para una comprensión profunda del rendimiento y la optimización de las aplicaciones a un nuevo nivel. ¡Únase a la comunidad OpenTelemetry para ayudar a dar forma a un futuro donde el desarrollo backend sea más simple y efectivo!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Make resilience your competitive advantage

¿Qué es OpenTelemetry y cómo puede mejorar la calidad de su backend?

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

El modelo Bitcoin UTXO, impulsando un ecosistema único

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

El modelo Bitcoin UTXO, impulsando un ecosistema único

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps