Introducción a la Observabilidad de Código Abierto

software. Mi nombre es Connor Lindsey y soy un ingeniero de software en Grafana Labs.

Strong Bad Inc. es una plataforma de consejos por correo electrónico donde las personas pueden ir en línea y hacer preguntas que Strong Bad responderá. Por ejemplo, ¿puedes dibujar un dragón o te gusta la música techno? Strong Bad es un buen desarrollador, pero quería un poco de ayuda adicional en la oficina, así que trajo a su amigo Homestar Runner para ayudar con algunas tareas de desarrollo.

En su primer día, después de configurar su entorno de desarrollo, Homestar Runner estaba súper emocionado de tomar su primer ticket y agregar etiquetas e inputs al formulario de envío de correo electrónico. Todo estaba genial, abrió su primer PR, fue aprobado y todos estaban extasiados cuando se fusionó en producción. Estaba tan emocionado de contribuir con código en su primer día. Solo para descubrir después de regresar del almuerzo que el sitio web había sido desactivado. No tenían idea de qué estaba pasando, así que fueron a atención al cliente para ver qué estaba sucediendo y, de hecho, confirmaron que el sistema estaba caído. Después de un par de horas de depuración estresante, encontraron una solución y pudieron enviarla a producción y ¡hooray, el sitio web volvió a funcionar! Pero se quedaron preguntándose qué causó el error. Incluso después de depurar, no estaban seguros al 100% cuál era la causa raíz. Incluso con la solución, no tenían mucha confianza en lo que estaba sucediendo y cómo podrían evitarlo en el futuro.

Entonces Homestar se preguntaba a sí mismo, debe haber una mejor manera. Como ingenieros, tenemos los mismos objetivos. Queremos lanzar sitios web confiables. Cuando tenemos problemas, queremos depurarlos rápidamente y con confianza, comprendiendo la causa raíz de lo que está sucediendo. Queremos sitios web de alto rendimiento y queremos comprender los problemas de rendimiento que están ocurriendo para poder mejorarlos. En última instancia, queremos sitios confiables y de alto rendimiento para tener una experiencia de usuario positiva. Para que las personas puedan ir a nuestros sitios web y lograr con éxito lo que vinieron a hacer. También queremos tener una buena experiencia de desarrollo. Debería ser lo menos doloroso posible. Escribir, lanzar y mantener código. Creo que una de las cosas más frustrantes como desarrollador es tratar de reproducir un error realmente, realmente difícil de reproducir donde no tienes pistas, no tienes idea de por dónde empezar. Y te quedas, ya sabes, vagando sin rumbo a través de tus registros, a través de cualquier tipo de migajas de pan que tengas para comenzar. Entonces, la observabilidad es una herramienta en nuestra caja de herramientas a la que podemos recurrir para ayudar a lograr algunos de esos objetivos. Este concepto proviene de la teoría del control. Y una definición formal sería tener la capacidad de inferir el estado de un sistema interno en función de sus salidas. Entonces, cuando pensamos en nuestras aplicaciones front-end que se ejecutan en dispositivos de usuarios finales, son como una

caja negra. No tenemos control total ni visión de lo que está sucediendo cuando se ejecutan. Sabes, funciona en mi máquina, pero no tengo idea de por qué está roto en la máquina de un cliente. Y así, la observabilidad como concepto puede ayudarnos a obtener información sobre cómo se están ejecutando nuestras aplicaciones en producción de la misma manera que lo hacemos cuando las ejecutamos localmente. Sabes, donde tenemos una visión completa de lo que está sucediendo. Tenemos todos nuestros registros, tenemos nuestras herramientas de desarrollo, podemos ver la pestaña de red, etc. Queremos lograr algunas de esas mismas herramientas y conocimientos en producción que tenemos cuando las ejecutamos localmente. Entonces, al hablar de observabilidad, hablemos de algunas de las herramientas, algunas de las cosas a las que podemos recurrir para lograr ese objetivo. Y una cosa son los diferentes tipos de datos que podemos recopilar. Las métricas, los registros y las trazas son los tipos fundamentales de datos con los que tenemos que trabajar. Por sí mismos, no significan que nuestros sistemas sean observables. Pero son puntos de partida. Son herramientas con las que podemos trabajar para lograr la observabilidad. Entonces, las métricas son tipos de datos numéricos o agregados. Y debido a las agregaciones que ocurren para obtener estas métricas, se pierde cierto nivel de detalle. Por eso las trazas y los registros son herramientas complementarias realmente importantes a las que podemos recurrir. Entonces, algunas métricas que podemos ver en este panel son cosas como la memoria versus el uso de la CPU. El número de solicitudes que reciben nuestros servidores. O para el frontend, la distribución de los tiempos de carga de las páginas. El siguiente tipo de datos son las trazas. Las trazas, similares a una traza de pila, te brindarán una descripción general de una solicitud a medida que pasa por tu sistema. A diferencia de una traza de pila cuando estás ejecutando una sola aplicación, una traza distribuida, al hablar de observabilidad, puede atravesar límites de servicio. Por ejemplo, podrías ver una traza de lo que sucede cuando un usuario inicia sesión en tu sitio web. Bueno, algunas operaciones ocurren en el frontend, que luego realiza una solicitud HTTP a tu backend, que luego realiza una solicitud a una capa de almacenamiento en caché a una base de datos, por ejemplo. Las trazas te brindan muchos detalles sobre cómo fluye la solicitud a través de todos esos sistemas y pueden ser realmente útiles. A continuación, veremos los registros. Estos son un flujo lineal de eventos, que son realmente útiles pero a menudo pueden parecer una manguera de incendios. Por lo tanto, tener un buen formato y una buena herramienta de agregación de registros hace que los registros sean mucho más útiles y mucho más fáciles de trabajar. Individualmente, cada uno de estos tipos de datos es realmente poderoso, pero tienen diferentes ventajas y desventajas en cuanto al tipo de información que muestran, su costo, sus implicaciones de rendimiento, ya sabes, lo que se necesita para operarlos. Y así, tener todos ellos y poder correlacionarlos es súper, súper útil. Por ejemplo, cuando pensamos en una métrica, es una descripción general agregada de un solo punto de datos, mientras que una traza es una sola solicitud que pasa por un sistema.

Y así, un flujo muy útil es pasar de una métrica que es una vista agregada de alto nivel a una traza que contribuyó a esa métrica. Eso es una característica llamada ejemplares, que puede ser realmente útil, ya sabes. Estás viendo tu panel de carga de página y ves que hay un pico a las 2 p.m., y puedes hacer clic en un ejemplar en ese punto y ver que es un ejemplo de una carga de página que contribuyó a esa métrica. Y luego, tal vez obtengas más información cuando estás viendo el ejemplo específico en lugar de una visión general agregada. Así que veamos cómo Homestar Runner podría aplicar estos conceptos en su aplicación. Al mirar la aplicación de demostración, tienen un frontend de React, un backend de Node y trabajan con una base de datos de Postgres. Una vez que tienes tu aplicación, necesitas alguna forma de recopilar los datos de telemetría, y ahí es donde entra en juego algo como OpenTelemetry. Juega el papel de instrumentación donde recopilas los diferentes datos en los que estás interesado. A partir de ahí, necesitas enviarlo a algún lugar para almacenarlo a largo plazo. Aquí es donde entran en juego herramientas de código abierto como Tempo, Loki y Mamir. Almacenan trazas, registros y métricas, respectivamente, y tienen otras herramientas con ellas, como Queryers, que te permiten buscar los datos en los que estás interesado. A partir de ahí, una capa de visualización es útil para poder reunir y correlacionar todos esos datos en un solo lugar. Así que profundicemos en OpenTelemetry.

OpenTelemetry es un estándar de código abierto para datos de observabilidad. Tiene una especificación que define cosas como qué es una traza, qué es un registro, qué es una métrica, en qué formatos vienen, cómo se usan, así como convenciones semánticas. ¿Qué datos se recopilarán siempre? ¿Bajo qué nombres aparecerán? A partir de ahí, hay implementaciones específicas del lenguaje de la especificación como APIs y SDKs. Por ejemplo, para JavaScript, eso significa que hay paquetes de NPM que nosotros, como usuarios finales, como desarrolladores, podemos descargar y usar en nuestras aplicaciones para recopilar métricas, registros y trazas. A partir de ahí, hay otros componentes como exportadores, que se encargan de enviar los datos de nuestras aplicaciones que hemos recopilado a cualquier backend que estemos usando para almacenarlos, y el recolector. Veamos un ejemplo de instrumentación.

Este pequeño fragmento de código es cómo configurarías las métricas en una aplicación de notas. En la línea dos, estás importando el proveedor de medidores del paquete base de métricas del SDK de OpenTelemetry. En la línea cinco, lo instancias para obtener un medidor, este tipo de objeto de alto nivel que puedes usar para crear métricas. En las líneas 10 y 15, vemos un ejemplo de eso. En la línea 10, creamos un instrumento, que se utilizará para recopilar un solo punto de datos. En este caso, es el número de transacciones. En la línea 15, tienes métodos muy simples con los instrumentos que estás creando, como add, donde puedes incrementar una métrica que tienes en un número específico, o puedes registrar un ejemplo específico. Este es un ejemplo de instrumentación manual. Donde vas a lo largo de tu código base, recopilas estos puntos de datos cuando ocurre un evento, incrementas un valor, o agregas una traza o escribes un registro usando tu registrador, etc. Haces esto manualmente en toda tu aplicación, lo cual es un poco de trabajo, pero te da un alto nivel de control sobre los datos que estás recopilando. En contraste con la instrumentación manual,

existen instrumentaciones automáticas. Estos también son paquetes creados por la community de OpenTelemetry, que utilizan los mismos fundamentos para recopilar automáticamente data para ti. Así que veremos en el recuadro rojo del fragmento de código, registrar una instrumentación para recopilar automáticamente datos es realmente sencillo. Solo tienes que enumerar los que deseas. Los importas, y luego estás listo para empezar. Algunos ejemplos que son particularmente interesantes para el frontend son la carga del documento y la interacción del usuario. Estos se conectarán con las APIs del navegador, para recopilar automáticamente data sobre cómo los usuarios interactúan con tu aplicación, cómo funcionan tus aplicaciones y recopilar cosas como métricas web, por ejemplo. Definitivamente, es un equilibrio entre la instrumentación manual y automática, dependiendo del nivel de granularidad de data que necesitas recopilar, y en última instancia, como desarrollador, conoces mejor tus aplicaciones y casos de uso, y eso puede informar el tipo de data de telemetría que deseas recopilar, así como los atributos que deseas adjuntar a los eventos que estás recopilando, pero hay algunas pautas sobre qué recopilar. Para los eventos, un par de eventos clave que debes tener en cuenta son la carga de la página, eventos de navegación, eso es especialmente importante si tienes una aplicación de una sola página (SPA) en comparación con una aplicación de varias páginas, ya que los eventos del navegador se comportarán de manera un poco diferente cuando se trata de la navegación. Acciones significativas del usuario, ya sabes, clics importantes en botones o envíos de formularios, los errores son especialmente importantes de rastrear, y la descarga de la página, puedes usar eso y conectarlo con la carga de la página para ver una vista general de la interacción de un usuario con una página específica. Con cada uno de esos eventos, puedes recopilar metadatos adicionales que se pueden utilizar más adelante para consultar tus data de telemetría. Entonces, algunos atributos que es posible que desees recopilar son cosas relacionadas con los datos de la aplicación. Ya sabes, qué usuario ha iniciado sesión actualmente, en qué equipo están, si son usuarios de pago, incluso cosas como qué banderas de características tienen habilitadas, porque más adelante, cuando veas un punto de data interesante, puedes analizarlo de diferentes formas, y, ya sabes, tal vez ocurra un error, pero solo para los usuarios que tienen una determinada bandera de características habilitada. Y así, al recopilar eso en este punto de tu instrumentación, más adelante, cuando lo consultes, podrás ver tus data de diferentes formas, lo que puede llevar a ideas interesantes. La siguiente categoría de atributos que puedes querer recopilar son las capacidades. Estas serían cosas como qué navegador está utilizando el usuario, el tamaño de su pantalla y resolución, qué tipo de conexión tienen, si están en una red 3G lenta, si están sin conexión, si están en Wi-Fi, y como desarrolladores, es muy común querer saber, eh, ¿puedo usar esta nueva API del navegador, puedo usar esta característica de CSS? Y tenemos datos genéricos como `puedo usar`. Pero dependiendo de tu base de usuarios, de tu aplicación específica, eso puede variar mucho de las estadísticas genéricas. Entonces, si estás recopilando estos data y dices, quiero usar esta característica X de verdad, eso sería muy importante para nosotros, puedes consultar tus datos de telemetría y ver, oh, en realidad nuestra base de usuarios se inclina de una manera u otra en cuanto a los navegadores que están utilizando. Por ejemplo, tal vez puedas decir, oh, espera, en realidad podemos adoptar esta tecnología mucho antes de lo que pensábamos. Luego, cosas como metadatos de la aplicación, qué versión o número de compilación de la aplicación está utilizando el usuario. Entonces, con todos estos atributos que se recopilan y los datos que se recopilan, luego necesitamos enviarlos a algún lugar para almacenarlos y consultarlos más adelante. Y este es el papel de los procesadores y exportadores en OpenTelemetry. Un procesador, como vemos aquí, al agregar un procesador de lotes, recopilará todos los datos a medida que los agregues en tu aplicación. Y luego los enviará en lotes. Hay algunas otras personalizaciones que puedes hacer con OpenTelemetry. Pero enviarlos en lotes es un buen estándar. Y luego, a partir de ahí, tienes un exportador. Este se encargará de realizar cualquier conversión de datos si el backend al que lo envías no formatea las métricas, registros y trazas de la misma manera que OpenTelemetry, y luego se encarga del transporte, ¿verdad? Y así, en este caso, podríamos enviarlo directamente a Tempo o a Loki o a Mimir. Un componente opcional es que podríamos ejecutar el recolector. Hasta este punto, hemos estado hablando de que nuestro frontend envía datos a nuestro backend para almacenarlos. Pero definitivamente hay muchos casos de uso para tener un componente intermedio que pueda actuar como intermediario entre tu frontend y tu backend.

Una de las razones principales sería security. Tener data proveniente de tus frontends significa que es público y que existen algunas preocupaciones de security. Por lo tanto, tener el recolector en funcionamiento puede agregar algunos beneficios de security, por ejemplo, al verificar los orígenes permitidos para que solo recibas eventos de telemetría de ciertos orígenes, o realizar limitación de velocidad, por ejemplo, en el recolector. El recolector también puede almacenar secretos, ya que se ejecuta en tu propia infraestructura en lugar de tus aplicaciones de frontend. Por lo tanto, si tienes secretos para tus diferentes backends de telemetría, no querrías exponerlos públicamente en tus frontends. Por lo tanto, tenerlos en el recolector puede ser realmente útil. Entonces, el recolector es un componente opcional, pero es especialmente relevante para

aplicaciones de frontend. Y a partir de ahí, tenemos nuestra fuente de datos, que almacenará y nos permitirá consultar nuestros datos. A partir de ahí, tenemos una capa de visualización. Esto es lo que usaremos utilizando Grafana. En Grafana, puedes configurar tus fuentes de datos y luego consultarlas utilizando Explore, donde puedes escribir consultas ad hoc o en paneles predefinidos, donde, nuevamente, estás escribiendo consultas, estás personalizando estos paneles para reunir todos tus datos rápidamente para visualizarlos. Veamos un par de ejemplos de datos específicos de frontend. En este primer panel, estamos viendo el rendimiento web utilizando las instrumentaciones de OpenTelemetry. Podemos recopilar web vitals, por ejemplo, y obtener una vista agregada de cómo están funcionando nuestras aplicaciones y cómo están evolucionando con el tiempo. Algo interesante que puedes hacer es marcar en estos diferentes gráficos cuándo ocurren diferentes despliegues. Puedes ver, por ejemplo, fusionamos esta nueva función, agregamos una nueva página, lo que sea. ¿Qué efecto tuvo eso en nuestras web vitals? Y puedes ver eso a lo largo del tiempo.

Otro panel que sería especialmente relevante es el de excepciones. Sabes, ver los mensajes en bruto que estás recibiendo, sabemos que tenemos 12 excepciones en el último período de tiempo relacionadas con helmet, esperando una cadena como hijo de title, sabes, tenemos algún error en alguna página. Y luego podemos segmentar y analizar esos datos de diferentes formas según los atributos que recopilamos anteriormente. Por ejemplo, si recopilamos la URL en la que se producen las excepciones, entonces podemos tener este panel adicional que muestra las principales URL por cantidad de excepciones. Entonces, vemos ahí, okay, la página de la función, algo está sucediendo, deberíamos echarle un vistazo a eso. O ver las excepciones por navegador, por ejemplo. Estos son solo ejemplos de diferentes formas en las que puedes dividir y consultar tus datos según los atributos que estás recopilando. Tal vez quieras ver las excepciones por feature flag para ver si un cierto feature flag está causando muchos errores. Y este panel brinda una visión general de alto nivel, pero algo realmente interesante que puedes hacer en Kufana es vincular estas diferentes fuentes de datos. Entonces ves estos errores, y tal vez quieras hacer clic y ver un ejemplo de eso. Y eso se vincularía a una traza donde ocurrió ese error. Y luego puedes ver la solicitud exacta desde el frontend hasta el backend hasta la base de datos que causó ese error. Y ahí es donde esa correlación se vuelve realmente, realmente importante. Entonces, este es un ejemplo de cómo utilizar paneles con métricas y registros para brindar una visión general del rendimiento web y las excepciones. Veamos un par de ejemplos de trazas. Este primer ejemplo es una traza bastante tradicional que muestra una solicitud que va desde un frontend a una API hasta la base de datos, y podemos ver los tipos de datos que estamos recopilando sobre ella como atributos. Tenemos, por ejemplo, la declaración, la consulta exacta que se estaba ejecutando y qué parámetros se pasaron. Si ocurre un error, esa sería información muy útil para saber qué consulta exacta se ejecutó que causó ese error y qué efectos tuvo aguas arriba. También obtenemos una vista interesante de cómo interactúan las diferentes secciones de las solicitudes, que se llaman spans, entre sí. Por ejemplo, la duración total de esta solicitud POST, según lo que ve el frontend, es de 27 milisegundos, de los cuales 16 milisegundos ocurrieron en la API.

Y luego podemos ver la duración de estas consultas individuales. Tal vez veamos que una consulta tarda mucho más de lo esperado, y eso nos proporciona algunos datos con los que podemos trabajar.

A continuación, se muestra un ejemplo de una interacción del usuario capturada como una traza. Se trata de un evento de navegación a una nueva página, que tardó un milisegundo. Y podemos ver algunos datos que recopilamos con eso, como el agente de usuario y la ruta X que utilizaron para navegar. Un dato realmente interesante y específico del frontend es el ID de sesión. A diferencia de un backend, donde normalmente se tiene un ciclo de vida de solicitud y respuesta muy claro, en el frontend, la sesión de un usuario, su interacción con un sitio web, no está tan claramente definida. Puede tener una duración muy larga. Puede ser de minutos, horas o incluso abarcar varios días, dependiendo de la aplicación y de cómo se defina. Crear ID de sesión y adjuntarlos a tus datos de telemetría puede brindarte mucha información sobre cómo se comportan los usuarios, a qué páginas van, con qué características interactúan, si hay errores que se producen a lo largo de una sesión. Por lo tanto, especialmente para aplicaciones frontend, tener ese ID de sesión es realmente, realmente importante.

Y finalmente, este es un ejemplo muy interesante de trazas para analizar las representaciones de los componentes. Aquí, nos conectamos a los eventos del ciclo de vida de un componente de clase de React y observamos cosas como el montaje y el renderizado del componente. Así vemos cuánto tiempo tarda un componente en montarse, cuánto tiempo tarda en renderizarse, si tiene renderizados innecesarios. En este caso, vemos que el segundo renderizado tarda 500 milisegundos, lo cual es mucho más largo que los demás. Y eso es información interesante que podemos analizar para comprender cómo se desempeñan nuestras aplicaciones. Por cierto, un uso realmente interesante de las trazas sería rastrear un pipeline de CI/CD. Las aplicaciones de esto pueden ser muy amplias y depende de nosotros, como desarrolladores, ser creativos y utilizar estas herramientas fundamentales para obtener información sobre diferentes partes de nuestro sistema, ya sean nuestras aplicaciones frontend, nuestros pipelines de CI/CD o nuestros servicios backend, etc. Y al utilizar todo esto, espero que Runner y StrongBoud comprendan mucho mejor su aplicación y tengan mucha más confianza a la hora de solucionar errores y problemas de rendimiento. Muchas gracias por escuchar. Espero que hayas aprendido algo y que puedas aplicar algunas de estas cosas a tus aplicaciones para obtener una mejor comprensión de cómo funcionan en producción. Gracias.