Evaluando el Rendimiento de Aplicaciones React con un Sorbo de RUM

Hola a todos. ¿Cómo estamos todos? ¡Whoo! Bien. Ahora, voy a decepcionarlos. No hay bebidas en esta charla. Voy a hablar sobre Rome. Voy a explicar qué es eso. Voy a hablar sobre OpenTelemetry y cómo cada uno de estos puede usarse para identificar cuellos de botella de rendimiento y varios problemas dentro de nuestras aplicaciones de React y cómo lo harías.

Oh, querido. Ahí vamos. Bien. Entonces, lo primero de lo que voy a hablar es de los pilares de la observabilidad. O si conoces Otel, entonces conoces estos como señales. Entonces, si pensamos en términos agnósticos fuera del ecosistema de React, cómo averiguamos si nuestra aplicación particular está fallando. Normalmente hay tres tipos diferentes de señales.

Así que, con cada uno de estos, levanta la mano en cualquier momento si realmente los recopilas en tu aplicación. Entonces, ¿cuántas personas están mirando logs o recopilándolos en algún lugar? Estoy un poco preocupado de que hay algunas manos que no están levantadas. Si hay una razón para esto, házmelo saber. Pero todos sabemos qué son los logs, incluso si no los estamos recopilando. Son esos mensajes estructurados locos, a veces útiles, a veces no tan útiles, que hemos omitido de nuestra aplicación, ya sea como una advertencia de algo que está sucediendo, como un indicador de que algo ha sucedido o un error que nos va a decir que necesitamos correr y entrar en pánico e ir a arreglar algo.

La segunda cosa que podemos recopilar son métricas. ¿Alguien recopila métricas? Bien. Entonces, el mismo número de manos. Eso es algo positivo. Entonces, métricas, podríamos pensar en cosas como rendimiento, podríamos pensar en latencia, tal vez quieras algunas personalizadas como el número de solicitudes o algo útil hacia un componente o página particular dentro de tu aplicación de React. Pero el común que pensaremos son los vitales web principales. ¿Todos hemos oído hablar de los vitales web principales? Tengo algunos asentimientos y algunas olas y algunas personas que se ven muy confundidas y asustadas. Está bien. Entonces, para aquellos que se ven confundidos y asustados, los vitales web principales son un conjunto de métricas de rendimiento centradas en el usuario. Si alguna vez miraste en tus Chrome DevTools y viste la pequeña pestaña de lighthouse, entonces probablemente entrarás y echarás un vistazo y verás estas medidas aleatorias que no necesariamente entiendes qué son. Pero son una indicación del rendimiento desde una perspectiva del usuario.

No vamos a hablar sobre core web vitals y detalles para esto, pero es una medida estándar común que puedes usar. Es una indicación aproximada de si la experiencia del usuario va a ser razonable o si tu página está tardando una eternidad en cargar y deberías probablemente hacer algo al respecto.

La tercera cosa de la que hablamos son los traces. Entonces, ¿quién está recopilando esos? Y hay mucho menos en la sala, lo cual tiene sentido. Bien. Probablemente estás usando traces y no lo pensaste. Creo que mi laptop quiere que actualice. No lo haremos ahora mismo. No es el momento, laptop. Estamos bien.

Entonces, ¿qué son los traces? Probablemente has estado usando estos y no realmente pensando en ello. Lo que estos traces son, en términos simples, volviendo, ahí vamos. Es un proceso de ver a través del camino de tu aplicación lo que se está llamando. Entonces, esto podría estar relacionado con llamadas a funciones. Esto podría estar relacionado con llamadas de red. Tal vez tu aplicación de React está disparando a diferentes servicios. Pero lo que un trace a menudo nos da, también, es el conocimiento de cuánto tiempo realmente está tomando ejecutar algo.

Lo cual es por lo que normalmente son bastante útiles. Si quieres identificar un cuello de botella y estás pasando por, ya sabes, tres, cuatro microservicios de profundidad, probablemente quieras ver cuál de esos está tomando un poco de tiempo. Entonces, cuando se trata de herramientas que podemos usar para recopilar cada uno de estos tipos de cosas, uno de los estándares abiertos comunes es lo que llamamos open telemetry.

Entonces, levanten la mano, ¿quién ha oído hablar de open telemetry? Bien. Genial. Feliz. Entonces, para aquellos que no han oído hablar de ello, es un conjunto de APIs y herramientas de estándar abierto. Básicamente pionero como parte de la fundación CNCF. Y lo que te permite hacer es de una manera agnóstica al lenguaje, siempre que haya un SDK compatible apropiado, te permite recopilar esos pilares o tipos de señales de los que acabo de hablar.

Y con respecto al estado de adopción en el ecosistema de JavaScript, es un poco de un panorama mixto, porque los traces y las métricas están actualmente estables. Así que, por todos los medios, usa el SDK, y puedes ejecutarlo dentro de node y hacer algunas cosas en la web también, y eso es genial, porque podemos obtener alguna información de telemetría de nuestra aplicación de React para lo que está sucediendo. Los logs están en desarrollo. Veremos qué pasa con eso.

Pero si pensamos en React y la perspectiva del front end y la instrumentación del cliente, verás que hay una gran advertencia detrás de mí. Básicamente, es experimental y en su mayoría no especificada. Ahora, hay un grupo SIG que está haciendo algunas cosas realmente fabulosas. Pero el problema es que aún no está allí.

Así que, este es un gran fragmento de código. Realmente alto. Puedes ir y revisar la demo de open telemetry. Dentro de la demo de open telemetry, tienen un ejemplo usando React que muestra el fragmento de trazado de front end que tengo aquí. Entonces, lo que tienes que hacer es especificar un proveedor de trazas web y darle a tu nombre, a tu aplicación apropiada un nombre de servicio único, y desde allí, lo que harás es agregar el contexto y las auto instrumentaciones, y eso te dará algunas cosas bastante geniales de inmediato. Te va a dar algunas métricas básicas, aunque hay algunas otras cosas que están llegando, pero también te da una buena idea del trazado.

Así que, aquí está el ejemplo del front end dentro de la demo de open telemetry. Y lo que puedes ver es, puedo ver bastante bien que se está iniciando una solicitud HTTP POST, y también puedo ver la ruta a través del proxy, lo cual siempre es muy interesante de saber. Y puedo ver cuánto tiempo está tomando cada uno de esos pasos.

El problema es esa parte de la instrumentación del cliente de la que hablé, la gran advertencia llamativa que acabamos de ver antes. Porque hay bastantes cosas en las que están trabajando en este momento en el seg del cliente que en realidad es un trabajo en progreso. Y uno de ellos son esas métricas de core web vital de las que estaba hablando antes, junto con algunas otras, como las cosas del evento de vista de página.

Con la aparición de eventos a lo largo del tiempo, espero que no necesitemos usar otros tipos particulares de herramientas, y con suerte puedas usar un estándar abierto junto con lo mismo para cualquier servicio de back-end con el que estés hablando. Pero por el momento, eso significa que necesitamos sacar el rum. Como dije, no estoy hablando de la bebida favorita de los piratas, o tal vez algunos de ustedes en la audiencia hoy, estoy hablando de monitoreo real del usuario.

Y la forma en que esto funciona es que tienes un agente que ejecutas dentro de tu aplicación de JavaScript que recoge esas piezas que actualmente faltan en el ecosistema de open telemetry. Así que, algunos de los aspectos alrededor del modo de documento, modo de página, las métricas de core web vital, otra información útil del usuario, como el agente del navegador, que es realmente útil para saber si alguien lamentablemente todavía está usando Internet Explorer. Todavía sucede, lamentablemente.