Cuando JavaScript Conoce OpenTelemetry: Es Hora de Observabilidad

Hola a todos. Mi nombre es Yash Verma. Soy un ingeniero de software que trabaja en el ámbito de la observabilidad. Soy uno de los contribuyentes al Proyecto OpenTelemetry, y me encanta cocinar, y andar en bicicleta es uno de mis pasatiempos. Este es mi perro bonito. Su nombre es Ty. Y, sí, hemos estado juntos durante aproximadamente 12 años hasta ahora, y todavía seguimos. Listo para continuar.

Así que, avanzando. La charla de hoy se titula, cuando JavaScript se encuentra con OpenTelemetry, es la hora de la observabilidad. Así que la primera pregunta que surge en nuestra mente es, ¿por qué estamos hablando de la observabilidad en primer lugar? Bueno, porque nunca ha sido tan importante y nunca ha sido tan complejo al mismo tiempo. Así que, déjame rápidamente guiarte a través de la agenda de hoy, lo que vamos a ver en esta sesión. Primero, hablaremos sobre qué es la observabilidad, luego pasaremos a cuáles son las diferentes señales de telemetría, y luego haremos un análisis profundo del Proyecto OpenTelemetry y un poco de su historia.

Luego hablaremos sobre la demostración de código específica de OpenTelemetry JavaScript. Y finalmente, hablaremos sobre el estado del servidor y el lado del cliente de la observabilidad en relación con OpenTelemetry. Así que, quería comenzar esta charla con OpenTelemetry. Pero antes, necesitamos entender y tener una comprensión clara de qué es exactamente la observabilidad en primer lugar. Porque, para ser honesto, si la observabilidad es el porqué, entonces OpenTelemetry es el cómo. Así que, primero necesitamos entender el porqué de lo que está sucediendo allí. Así que la teoría del control lo define como, es la capacidad de entender el estado interno de nuestro sistema a partir de sus salidas o señales externas, diría yo. Es el proceso donde hacemos múltiples preguntas y obtenemos respuestas hasta que estamos satisfechos de que, sí, estamos completamente convencidos de que nuestros sistemas se comportan de la manera en que lo hacen. Así que avanzando, un poco de su historia de dónde comenzamos y lo que ahora llamamos observabilidad moderna. Todo esto comenzó a principios de 2000. En esos días, si le preguntabas a alguien, oye, ¿cómo mantienes un monitoreo de tu sistema? La respuesta sería, oh, sí, llevamos un seguimiento de un montón de métricas. Así que con eso, lo que quieren decir es que estas líneas y gráficos coloridos y eso es lo que ves en la pantalla en este momento. Así que estos gráficos nos decían cuándo algo estaba mal. Las métricas eran todo en ese entonces, principalmente porque era más barato almacenar y el almacenamiento no era tan barato en ese momento porque era realmente caro en ese entonces. Así que hay una cosa más de la que quiero hablar en esta charla. Veo a muchas personas hablando sobre, oye, la observabilidad versus la monitorización. Pero honestamente, como lo veo, la monitorización es solo un subconjunto de la observabilidad. Así que la monitorización te dice que, oye, algo está mal.

Te dice por qué está mal, dónde está mal. Y probablemente puedas obtener algo de cómo puedes depurar esa cosa. Así que se trata de esto. Así que avanzando con la historia, para 2010, comenzábamos a ver las raíces de la observabilidad moderna. Así que alrededor de este tiempo, Facebook se estaba convirtiendo en una empresa masiva. Y tenían millones de usuarios uniéndose y la escalabilidad se convirtió en un problema para ellos. El equipo de Facebook ideó una solución que llamaron Proyecto Scuba. Funcionaba con grandes conjuntos de datos distribuidos y arbitrarios, que llamaron eventos amplios.

Así que el objetivo era bastante simple. Permite a los ingenieros ejecutar consultas en tiempo real y visualizar el resultado para entender el comportamiento de un sistema. Digamos, por ejemplo, si alguien de la región APAC intenta iniciar sesión en Facebook, pero más tarde ese día, cuando viajan a Europa, algunas funciones no funcionan o tienen un tiempo de carga más largo. Así que usando Scuba, los ingenieros podían averiguar qué cambió, qué se rompió, por qué se rompió en una ubicación o tiempo específico. Así que estas son las cosas que los ingenieros usaban para profundizar en los temas. Y los eventos amplios les dieron una imagen completa de todo lo que estaba funcionando en los sistemas.

Así que avanzando hacia alrededor de 2012. Y aquí está el enlace al proyecto Scuba si realmente quieres leer sobre él. Te sugiero, sabes, por favor ve y léelo. Es un proyecto realmente interesante y tendrás una idea de cómo funcionaban las cosas alrededor de ese entonces. Correcto. Así que avanzando, para, sabes, como 2012, vimos un auge en las herramientas de registro y series temporales. Herramientas como Prometheus, Elixstack y muchas otras. Sabes, como que los desarrolladores comenzaron a ir más allá del registro de consola porque los sistemas estaban volviéndose más complejos, la base de usuarios se estaba, sabes, volviendo increíblemente enorme.

Sabes, como los desarrolladores comenzaron a moverse más allá del registro de consola porque los sistemas estaban volviéndose más complejos, la base de usuarios se estaba, sabes, volviendo increíblemente enorme. Y esto hizo y probablemente nos empujó de alguna manera a almacenar registros y así podríamos usarlo en el futuro y ejecutar algunas analíticas sobre eso. Correcto.

Así que para 2017 y 2016, como alrededor de este tiempo, las cosas se vuelven aún más locas porque ahora no estamos construyendo una aplicación simple más. Correcto. En aquellos días, teníamos un front end básico, un back end y algunos datos. Pero ahora muchas aplicaciones viven dentro del navegador mismo. Y todo ahora es parte de un sistema distribuido. Bienvenido a la nueva era de la ingeniería de software.

Correcto. Todo estaba distribuido. Las bases de datos están en algún otro lugar. OK. Esa base de datos está en alguna otra ubicación. El front end está en algún otro lugar. La gente del back end, sabes, todo estaba distribuido. Sí. Así que, sabes, y eso significa más complejidad. Eso significa más miedo y como más miedo de eso. ¿Cuáles son las posibilidades de que mis pequeños cambios de código en un front end simple no tengan un efecto dominó en algún otro lugar en la línea? Tal vez algo pueda romperse. No sabemos exactamente sobre eso. Así que aquí es donde entra el trazado distribuido. Te muestra todo el viaje de una solicitud fluyendo a través de un sistema y servicios como un flujo de transacciones, algo así como si esto sucedió, probablemente esta fue la razón detrás de eso. Y este es el potencial de fallo con respecto a este paso particular. Y también te dice que tomó este tiempo al ejecutar esta operación. Cada detalle ahí fuera. Diría. Correcto.

Así que esto es lo que da. Así que eso es lo que el trazado te da. Se trata de la causalidad. Correcto. Te ayuda. También te ayuda a averiguar que cuando un sistema se está desacelerando, por qué se está desacelerando y por qué a veces falla. Es toda la imagen. Correcto.

Así que ahora la pregunta es, ¿qué es una traza? ¿Es una entidad independiente o cómo se ve exactamente? Así que una traza está compuesta por un solo span o varios spans. Los spans se consideran como un bloque de construcción de una traza. Cada span tiene cosas como un nombre de span, ID de span, ID de span padre. Si es parte de una transacción más larga, tiene cosas como tiempo de inicio, tiempo de finalización y un montón de otros metadatos. Así que, sabes, así es como se ve una traza simple. Es interesante. Correcto.

Así que. Pasando a otro tema. Todos estos spans que están distribuidos a través de diferentes sistemas, a través de microservicios o incluso dentro del mismo sistema. Correcto. Todos estos están conectados a través de un mecanismo llamado propagación de contexto. Así que ahora nosotros. Así es como obtenemos una visibilidad completa de nuestro sistema en una vista de servicio a servicio o sobre una imagen más grande, diría. Así que la siguiente pregunta es, ¿son suficientes los registros? Bueno, cuando comencé a aprender sobre el trazado, me hice una pregunta. Espera, que hey, tenemos los registros, tenemos las métricas. Por un período de tiempo muy breve. Correcto. Pero, ¿por qué nos dan el nivel de visibilidad que el trazado proporciona? Así que la respuesta radica en el contexto. Ahora, el trazado se trata de contexto.

Está lleno de datos de contexto ricos. Sabes, como las métricas están bien. Los registros son geniales. Pero generalmente carecen de un contexto más profundo que te diga por qué está sucediendo algo. Los registros son geniales para el entorno de desarrollo. Los registros estructurados son aún mejores si los estás utilizando en un entorno de producción. Pero aquí está el problema: los registros en producción pueden ser algo desordenado debido a su enorme volumen y a veces puede ser un dolor. Son difíciles de buscar. A veces son difíciles de escalar. Y incluso cuestan mucho porque están en grandes volúmenes. Así que un pequeño error puede derribar todo tu sistema de producción y nunca sabes de dónde ocurrió. Correcto.

Así que particularmente, es algo muy común, como nosotros los desarrolladores también tendemos a enviar el mensaje básico de registro de consola al entorno de producción, lo que también se convierte en una gran preocupación cuando se trata del costo. Sabes, como que esa es una historia diferente para eso. Pero sí, es cierto. Así que particularmente, lo que me encanta del trazado es que puedes extraer métricas y registros de eso o de una traza, pero no puedes hacer lo contrario. Así que el trazado te da una imagen de extremo a extremo de toda tu transacción.

Así que ahora hablaremos sobre el auge de OpenTelemetry. Así que para 2017, el espacio de la observabilidad ha explotado con muchos proveedores ofreciendo sus SDKs propietarios y diciendo que, hey, somos las herramientas de observabilidad que usan. Somos geniales en todo tipo de cosas. Al mismo tiempo, en el mundo del trazado, pudimos ver un aumento de estos dos estándares competidores ganando tracción. Se llaman Open Census y Open Tracing. Correcto. Pero tener dos estándares puede hacer que las cosas sean un poco desordenadas porque algunas personas estaban confundidas sobre cuál usar o si deberíamos usar ambos. No sabemos exactamente qué hacer. Así que en 2019, la comunidad de estos dos proyectos se unió y decidieron que, hey, combinemos los dos en uno. Y así es como nació OpenTelemetry.

Correcto. Y sí, algunas personas también bromeaban al respecto porque se siente como el clásico cómic de ex-KCD que dice que al intentar arreglar dos estándares, ahora creamos un tercero. Y ahora tenemos un total de tres estándares allí. Pero esta vez, algo no fue, ya sabes, algo funcionó en realidad porque en 2022, open census y open tracing fueron, ya sabes, como descontinuados por la propia comunidad. Y el objetivo era claro, que open telemetry debería ser un estándar de facto en el mundo del trazado distribuido. Correcto. Así que open telemetry comenzó con la visión del trazado distribuido inicialmente, pero se movió hacia métricas. Y ahora en registros también lo está haciendo bien. Correcto.

Así que ahora entendamos qué es exactamente open telemetry en sí. Algunas personas creen que es solo otra herramienta de observabilidad. Es solo un lenguaje de observabilidad, diría yo y todo eso. Pero no lo es. Correcto. En su núcleo, open telemetry es un marco. Correcto. Es un protocolo de cómo manejamos los datos de telemetría. Te da el conjunto de APIs, SDKs y herramientas para crear datos de telemetría y enviarlos a tu backend de tu elección.

Pero ya sabes, como, ¿cómo haces que tu aplicación emita estos datos? Es a través del proceso llamado instrumentación. Correcto. Así que hay dos tipos de instrumentación. Una es la instrumentación automática y donde agregas una o dos líneas en sus paquetes de importación allí y boom, estás listo para comenzar. Obtienes tu traza. Obtienes tus métricas. Obtienes tus registros. La otra es la instrumentación manual, que es un poco más, que requiere un poco más de esfuerzo de tu parte. Pero en realidad, diría que puedes tener un control total sobre qué datos quieres obtener, qué quieres trazar, qué tan profundo quieres ir en una traza para poder depurar un problema de rendimiento dentro de tu aplicación.

Es especialmente útil cuando necesitas observar datos sensibles o usar un tercero Se trata del contexto, diría yo, del que hablé. Cuanto más intentes diseñar alrededor de esto, más datos obtendrás sobre esto. Así que esto nos lleva a nuestra siguiente pregunta. ¿Por qué importa OpenTelemetry? La razón más grande por la que la gente se está moviendo hacia OpenTelemetry es simplemente porque es un marco independiente del proveedor. Tu aplicación no necesita preocuparse por tu backend de observabilidad o el proveedor que estás usando.

Incluso ahora o incluso en el futuro. Solo tiene que emitir datos de telemetría y OpenTelemetry se encarga de todo lo demás. Desde enrutarlos al protocolo correcto usando el OTLP, que es el protocolo de OpenTelemetry, que es nativo de OpenTelemetry, lo que te ayuda a mover datos de tu aplicación a los proveedores. Se trata de eso. Incluso a través del protocolo HTTP o gRPC.

En este momento, soporta 12 lenguajes diferentes y JavaScript es uno de ellos. Así que continuando, hablemos sobre el OpenTelemetry Collector. Se le llama el corazón del proyecto OpenTelemetry. Aunque puedes usarlo, aunque no es obligatorio usarlo, puedes usarlo. No es obligatorio usar el OpenTelemetry Collector, pero se aconseja usarlo porque es el corazón del proyecto.

Así que el OpenTelemetry Collector es como una pieza central del proxy que se sitúa entre tu aplicación y tu marco de observabilidad de backend. Puedes hacer cosas como filtrar los datos, puedes agruparlos, a veces puedes incluso comprimir los datos, puedes descartar los datos e incluso puedes escribir en diferentes archivos o incluso en Kafka, lo que sea necesario para ti. Así que puedes ahorrar un montón de costos de datos incluso utilizando algunas técnicas como muestreo para reducir los datos, como muestreo de cola, muestreo basado en cabeza o una combinación de ambos, que es el más útil contexto para los datos resultando en, diría yo, te ayuda a reducir el costo de salida a veces. Así que hay dos versiones del OpenTelemetry Collector. Una es la core, que tiene la característica básica y la otra es la contrib. El OpenTelemetry Collector contrib, incluye un exportador de procesador más, que es activamente utilizado por la comunidad, que es activamente utilizado por los miembros, pero no es oficial.

Así que ahora comencemos con cómo puedes empezar a usar OpenTelemetry en tu aplicación de Node.js. ¿Verdad? Comencemos con eso. Así que es un paso bastante simple. Solo tienes que instalar algunos scripts allí, instalar OpenTelemetry SDKs, OpenTree APIs, ya sabes, y comienza, si estás comenzando por primera vez, si eres un usuario por primera vez de OpenTelemetry, por favor ve con la instrumentación automática. Es muy útil. Aunque la cantidad de datos es muy grande, obtienes muchos datos, pero podrás ver cómo funcionan las cosas allí. Y más tarde, si tienes, ya sabes, si realmente estás interesado en profundizar, ve con lo manual. Esa es la forma recomendada, diría yo.

Así que aquí está la cosa. Ahora puedes ver cómo puedes configurar un exportador de trazas. Es como, ya sabes, como primero tienes que, es un paso básico de uso. Solo tienes que copiar y pegar parte del código allí y estarás listo para comenzar. No hay nada de un código base muy grande, ya sabes, es muy pequeño. Solo tienes que copiar y pegar alrededor de esto y luego comenzar con esto. Así que, y también una cosa, por favor ten en cuenta que no debes enviar, ya sabes, como datos de consola al sistema de producción porque realmente te costará mucho en torno a eso. Te costará realmente no, diría yo. Así que para fines de desarrollo, puedes consolear todos los datos y ver si está funcionando o no. Pero para el caso de producción, por favor intenta evitar enviar datos a la producción, como los registros de consola de cosas y todo lo diferente que ves en la consola, ¿verdad? Así que veamos cómo puedes crear spans alrededor de eso. Así que este es un paso simple, cómo puedes crear un span. Puedes etiquetarlos con el span padre si son parte de una transacción más larga. Ya sabes, si es la primera cosa, entonces se convertirá también en un root span. Esa es la cosa básica alrededor de eso.

Así que hay otra cosa sobre cómo puedes registrar excepciones de span. Como cuando algún span no, ya sabes, como cuando alguna, cuando alguna función no funciona, el span fue registrado y el error. También podemos hacer una cosa, como podemos asumir que si esto sucedió en este particular span, podemos de antemano, podemos dar algunas lógicas alrededor de eso sobre cómo resolver eso y cómo podemos, ya sabes, extraer esa información o registros de esa información en un trazo más largo para que luego, cuando volvamos, puedas entender cómo funcionan las cosas allí, ¿verdad? Así que podemos registrar las excepciones y realizar operaciones basadas en eso también.

Así que ahora la cosa es, ¿qué es una convención semántica? Una convención semántica, es algo muy importante en el mundo de OpenTelemetry porque confía en mí, en la ingeniería de software, nombrar es un gran desafío. Nombrar una variable, ya sabes, o nombrar una función o nombrar cualquier cosa es un gran desafío. Así que OpenTelemetry surge con esta idea de convención semántica, donde se define que ciertas cosas se llaman así, ya sabes, como cosas de trazas, cosas de métricas, registros y, ya sabes, recursos, todo tiene un nombre particular. ¿Verdad? Si es porque de alguna manera se llama HTTP, por ejemplo, si estás, digamos, por ejemplo, si dices, si tengo que dar un puerto, ya sabes, como si tengo que verificar si una solicitud proviene de HTTP o no, podemos hacer cosas como solicitud en HTTP o para definir la cosa de dónde exactamente proviene, que está definido en todo el sistema. No puedes cambiarlo generalmente para eso también. Así que todo tiene su propia convención, la traza tiene la suya, las métricas tienen la suya, los registros tienen la suya, todo allá afuera.

Así que ahora tenemos que verificar cuánto se ha hecho en el mundo de OpenTelemetry con respecto a JavaScript, ¿verdad? Así que con respecto a las señales, el trazado es bastante estable. Sabes, las métricas son estables. Sin embargo, los registros no son completamente estables. Diría que algunas partes aún están pendientes. Hay una gran cantidad de trabajo que ha sido realizado por la comunidad misma dentro de la, ya sabes, siempre puedes, siempre eres bienvenido a revisar nuestro repositorio de GitHub alrededor de allí y trabajar con estas cosas, ¿verdad?

Así que hay una cosa más que quiero compartir contigo. Se llama cumplimiento de especificaciones. Así que si quieres verificar eso, hey, pero tú eres, ya sabes, como que eres particular si quieres usar algo como, ya sabes, obtener un ID de traza con una URL de esquema, si está proporcionado en el, si está disponible dentro del GIS hasta ahora, definitivamente puedes ir y revisar. Hay un montón de cosas. El enlace está aquí. Puedes ir y revisar qué características están en, ya sabes, como que han sido producidas activamente por la comunidad y cuáles aún están en progreso, ¿verdad?

Ahora hablando del lado del cliente, que es hablar sobre el front end de la parte del cliente, ¿verdad? Así que hablemos de eso. Bien. Muchas cosas aún están en fase experimental. Diría que el repositorio central de OpenTelemetry.js no tiene completamente un estándar maduro con respecto al conjunto de instrumentos del cliente de OpenTelemetry. Pero diría que hay un montón de cosas sucediendo en el repositorio contrib de OpenTelemetry.js. Puedes ver muchas cosas sucediendo con eso. Personas de todo el mundo están decidiendo cómo puedes, ya sabes, diría entender, analizar y estandarizar el flujo de datos desde el front end y capturarlo, almacenarlo y luego correlacionarlo y luego correlacionarlo y luego correlacionarlo con el back end de las cosas. Así que hay un montón de cosas. Diría que definitivamente eres bienvenido a ver cómo se ven las cosas alrededor de eso. Además, esta es una instantánea de lo último que se ha estado haciendo en el mundo de OpenTelemetry. Así que es como, diría, hay cosas que se han hecho como almacenar datos de sesión en recursos, implementación de un instrumento de evento de vista de página, ya sabes, todo allá afuera. La API de eventos y registros se ha estabilizado allí. Luego, ya sabes, todo. Sin embargo, una cosa es muy importante, diría. El trabajo en progreso es el núcleo de los plugins de web vitals. Sabes, algunos trabajos han estado bastante, diría, en progreso. Es enorme. Es enorme. Así que la visión es clara que haremos de OpenTelemetry un lugar donde puedes, es capaz de, ya sabes, como analizar, obtener los datos, trabajar en eso. Obtendremos una visibilidad de extremo a extremo desde tu front end hasta el back end. También hay lo que se llama monitoreo de usuarios reales de OpenTelemetry, diría. Puedes ir y revisar, es bastante bueno.

Diría que una muy buena cantidad de trabajos han estado ocurriendo en ese particular campo. Así que te recomendaría que vayas allí. Bien. Así que ahora hablemos de otra cosa, que diría, como para el lado del front end, pocas empresas están utilizando su aplicación de front end y ejecutan un montón de observabilidad inspirada en OpenTelemetry en la aplicación. Pero no es un estándar comunitario completamente aceptado, pero no es un estándar comunitario completamente aceptado todavía. Así que si tienes alguna idea y quieres contribuir sobre eso o simplemente quieres aprender sobre lo que está sucediendo en la comunidad, siempre eres bienvenido a, ya sabes, tenemos unas horas de oficina diseñadas para eso. Así que, sí, ese es el mejor lugar.

Ahora, si no estás al tanto de qué es OpenTelemetry y no sabes por dónde empezar. Así que el proyecto de demostración de OpenTelemetry es un buen lugar para empezar. Luego puedes simplemente comenzar y, ya sabes, es un proyecto que tiene una aplicación inspirada en e-commerce con un montón de microservicios en múltiples lenguajes. Tienes un proceso de pago. Tenemos, ya sabes, un servicio de añadir al carrito, que se activa a través de diferentes servicios en diferentes lenguajes. Y es una gran manera de ver cómo funcionan las cosas en acción y cómo tú puedes comenzar a usar OpenTelemetry para el trabajo. Bien.

Así que, sí, creo que eso es todo por mi charla. Sin embargo, si hay una clave que se puede extraer de esta charla es que ahora mismo, es como si Open Telemetry ha cambiado definitivamente la forma en que miramos en el espacio de la observabilidad hasta ahora. OK, porque ahora no estamos compitiendo en la carrera por tener un SDK estable. Y pero ahora necesitamos más valor de lo que tenemos. Los proveedores que ya estaban compitiendo entre sí en términos de, hey, tenemos este SDK estable. Tenemos este SDK. Sabes, ahora los proveedores están luchando para proporcionar, ya sabes, como entre ellos para proporcionarnos una observabilidad eficiente y rentable, lo cual es muy útil para nosotros. Bien. Así que, sí, eso fue todo sobre mi charla. Espero que lo hayas disfrutado. Si quieres revisar cómo puedes involucrarte en este OpenTelemetry, estos son algunos enlaces. Y sí, gracias por sintonizar. Espero que realmente hayas tenido una buena conferencia. Adiós.