Introducción a la Observabilidad de Código Abierto

Rate this content
Bookmark
Slides

Aprende cómo instrumentar aplicaciones Node y de cliente utilizando OpenTelemetry y herramientas de observabilidad de código abierto populares como Prometheus y Grafana.

21 min
24 Oct, 2022

Video Summary and Transcription

La observabilidad es una herramienta crucial para los ingenieros para enviar sitios web confiables y tener una buena experiencia de desarrollo. Las métricas, los registros y las trazas son tipos de datos fundamentales para lograr la observabilidad. OpenTelemetry es un estándar de código abierto para datos de observabilidad, y la instrumentación se puede realizar de forma manual o automática. La recopilación y el transporte de datos pueden ser gestionados por paquetes construidos por la comunidad de OpenTelemetry, y el ejecutor en funcionamiento puede agregar beneficios de seguridad. Grafana se utiliza para la visualización de datos, y permite analizar el rendimiento web, excepciones y trazas. Las trazas capturan las interacciones de los usuarios y proporcionan información sobre el comportamiento de los usuarios y la aparición de errores. Aprovechar estas herramientas permite obtener información sobre varias partes del sistema y mejorar los objetivos de ingeniería.

Available in English

1. The Story of StrongBad Inc.

Short description:

Hablemos de la historia ficticia pero no del todo irreal de StrongBad Inc., una joven empresa de software. 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á. 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. Encontraron una solución y pudieron enviarla a producción y ¡hooray, el sitio web volvió a funcionar! Como ingenieros, queremos lanzar sitios web confiables, solucionar problemas rápidamente y con confianza, y tener una buena experiencia de desarrollo. La observabilidad es una herramienta en nuestra caja de herramientas para ayudar a lograr esos objetivos.

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

2. Tipos de Datos de Observabilidad

Short description:

Podemos obtener información sobre cómo se están ejecutando nuestras aplicaciones en producción utilizando la observabilidad. Las métricas, los registros y las trazas son tipos de datos fundamentales que ayudan a lograr la observabilidad. Las métricas proporcionan tipos de datos agregados, pero las trazas y los registros son importantes para obtener información más detallada. Las trazas ofrecen una descripción detallada del flujo de solicitudes entre límites de servicio, mientras que los registros proporcionan un flujo lineal de eventos. Tener todos estos tipos de datos y correlacionarlos es crucial para lograr la observabilidad.

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.

3. Exemplares, OpenTelemetry e Instrumentación

Short description:

Un flujo útil es pasar de una métrica de alto nivel a una traza con ejemplares. OpenTelemetry es un estándar de código abierto para datos de observabilidad. Tiene una especificación e implementaciones específicas del lenguaje. La instrumentación se realiza manualmente o automáticamente.

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,

4. Recopilación y transporte de datos

Short description:

Estos son paquetes creados por la comunidad de OpenTelemetry que recopilan datos automáticamente. Registrar una instrumentación es sencillo. Ejemplos para el frontend incluyen la carga del documento y la interacción del usuario. Los eventos clave a rastrear son la carga de la página, eventos de navegación, acciones significativas del usuario, errores y descarga de la página. Recopilar atributos como datos de la aplicación, capacidades y metadatos de la aplicación puede proporcionar información valiosa. Los procesadores y exportadores se encargan de la recopilación y el transporte de datos, con opciones para enviar datos a Tempo, Loki o Mimir. El recolector puede actuar como un componente intermedio con fines de seguridad.

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.

5. Recopilación de datos y seguridad

Short description:

Tener el recolector en funcionamiento puede agregar beneficios de seguridad al verificar los orígenes permitidos, realizar limitación de velocidad y almacenar secretos. Esto es especialmente relevante para aplicaciones de frontend.

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

6. Data Source, Visualization, and Examples

Short description:

Tenemos una fuente de datos y una capa de visualización utilizando Grafana. En Grafana, puedes configurar fuentes de datos, escribir consultas y personalizar paneles para visualizar tus datos. Los ejemplos incluyen rendimiento web, excepciones y trazas. Puedes marcar despliegues en los gráficos para analizar su impacto en el rendimiento web. Las excepciones se pueden segmentar y analizar según atributos como URL o navegadores. Kufana permite vincular fuentes de datos para ver el flujo exacto de solicitudes y correlaciones. Las trazas muestran el recorrido de la solicitud y los atributos recopilados, incluidos los detalles de la consulta y los efectos de error. Los spans muestran cómo interactúan diferentes partes de la solicitud.

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.

7. Observability Data Insights

Short description:

Podemos obtener información sobre la duración de las consultas individuales y recopilar datos para trabajar con ellos. Las trazas capturan las interacciones del usuario, incluidos los eventos de navegación y los datos asociados a ellos. Los datos específicos del frontend, como los ID de sesión, proporcionan información valiosa sobre el comportamiento del usuario y la aparición de errores. Examinar las representaciones de los componentes nos permite analizar los tiempos de montaje y renderizado, identificar renderizados innecesarios y comprender el rendimiento de la aplicación. El seguimiento de los pipelines de CI/CD es otro caso de uso interesante. Al aprovechar estas herramientas, podemos obtener información sobre diversas partes de nuestro sistema, mejorar los objetivos de ingeniería y aumentar la confianza en la corrección de errores y la optimización del rendimiento.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
DevOps.js Conf 2022DevOps.js Conf 2022
27 min
Why is CI so Damn Slow?
We've all asked ourselves this while waiting an eternity for our CI job to finish. Slow CI not only wrecks developer productivity breaking our focus, it costs money in cloud computing fees, and wastes enormous amounts of electricity. Let’s take a dive into why this is the case and how we can solve it with better, faster tools.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Atomic Deployment for JS Hipsters
Deploying an app is all but an easy process. You will encounter a lot of glitches and pain points to solve to have it working properly. The worst is: that now that you can deploy your app in production, how can't you also deploy all branches in the project to get access to live previews? And be able to do a fast-revert on-demand?Fortunately, the classic DevOps toolkit has all you need to achieve it without compromising your mental health. By expertly mixing Git, Unix tools, and API calls, and orchestrating all of them with JavaScript, you'll master the secret of safe atomic deployments.No more need to rely on commercial services: become the perfect tool master and netlifize your app right at home!

Workshops on related topic

DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.
DevOps.js Conf 2022DevOps.js Conf 2022
163 min
How to develop, build, and deploy Node.js microservices with Pulumi and Azure DevOps
Workshop
The workshop gives a practical perspective of key principles needed to develop, build, and maintain a set of microservices in the Node.js stack. It covers specifics of creating isolated TypeScript services using the monorepo approach with lerna and yarn workspaces. The workshop includes an overview and a live exercise to create cloud environment with Pulumi framework and Azure services. The sessions fits the best developers who want to learn and practice build and deploy techniques using Azure stack and Pulumi for Node.js.