Observabilidad para Desarrolladores de React

Hola, React Advanced London. Bienvenidos al Día Remoto. Es genial verlos a todos. Mi nombre es Carly Richmond, y estoy aquí hoy para hablar sobre la observabilidad, pero no como tradicionalmente se podría pensar. Cuando pensamos en observabilidad, a menudo nos enfocamos demasiado en los servicios de back-end y lo que están haciendo, cuando necesitamos entender el comportamiento de nuestras aplicaciones web en el front-end también. Así que vamos a hablar sobre cómo hacemos eso con aplicaciones web de React además de ver lo que está sucediendo en los servicios de back-end también.

Las herramientas que vamos a cubrir son Rome agents, open telemetry y synthetic monitoring. Les mostraré algunos ejemplos. Tendremos fragmentos en los que pueden profundizar después si quieren echar otro vistazo. Pero si también quieren hacerme alguna pregunta después, no duden en contactarme en línea y en varios lugares en la web. Soy defensora principal de desarrolladores y gerente en Elastic, así que podrán encontrarme fácilmente en LinkedIn también. Antes de eso, en realidad fui ingeniera de front-end durante diez años trabajando en un gran banco de inversión, así que estos son problemas con los que he lidiado de primera mano, lo que significa que tengo muchas opiniones sobre cómo debería hacerse esto.

Pero primero, necesitamos hablar sobre los pilares. Muy a menudo, cuando comienzas a profundizar en la observabilidad, la gente comienza a decir, oh, bueno, necesitamos hablar sobre los pilares. Hablemos de ellos como señales, porque eso es efectivamente lo que son. Estos son tres tipos de información de telemetría que podemos usar en nuestras aplicaciones para averiguar qué está pasando e identificar comportamientos y remediar problemas que no necesariamente anticipamos que van a suceder. Así que la primera señal de la que tendemos a hablar son los logs. Y los logs, todos sabemos lo que son. Son esos mensajes extraños que vemos que estamos poniendo en la consola del navegador que podemos ver cuando estamos diagnosticando problemas en nuestra aplicación. La segunda son las métricas, que son simplemente valores que nos dan una indicación aproximada del rendimiento que podemos usar para seguir a lo largo del tiempo. Así que podrías pensar en el rendimiento y la latencia, pero también tenemos Google Core Web Vitals, que son una buena indicación del rendimiento del usuario, al menos como una guía aproximada. Y luego tenemos trazas. Ahora, podrías pensar, bueno, ¿qué son estas? Pero en realidad, has estado usando estas por un tiempo y no necesariamente pensando en ello. Estas son el tipo simple de barras con spans subyacentes que puedes ver aquí arriba que hemos visto para mostrar la cantidad de tiempo que lleva pasar por diferentes etapas en nuestra aplicación, o incluso para ver cuánto tiempo están tardando en regresar ciertas llamadas de red, a lo que todos estamos acostumbrados cuando estamos diagnosticando problemas con aplicaciones de React tratando de conectarse a servicios de back-end y funciones serverless.

Pero necesitamos sacar el rum. Y tristemente, no estoy hablando de la bebida favorita de Jack aquí. Estoy hablando de un agente de monitoreo de usuario real. Este es un simple agente que inicializas dentro de tu aplicación JavaScript que va a recopilar métricas e información de diagnóstico junto con el trazado en la aplicación de front-end. Y eso significa que podemos usarlo para identificar cuellos de botella, ver si tenemos scripts particulares que están tardando mucho en cargar, y otras piezas de información útil cuando estamos tratando de averiguar cuál es el cuello de botella dentro de nuestra aplicación de React. Estoy hablando de un agente rum porque en este momento, a menos que alguien quiera corregirme, no tenemos nada que sea lo suficientemente genérico en cross vendor.

Necesitas usar el rum agent que está asociado con la plataforma de observabilidad en la que vas a ingerir datos. Sin embargo, mantén los ojos abiertos en el grupo de instrumentación del cliente para open telemetry. Si quieres unirte al SIG, los detalles están allí en su sitio también. Y ese es realmente el grupo que está buscando tratar de tener un estándar más abierto que no esté tan bloqueado por el proveedor. Pero para el vamos a usar el de Elastic.

Así que hay dos maneras de instrumentarlos. Y esto tiende a ser patrones similares en diferentes agentes. Así que puedes usar una etiqueta de script. Generalmente, no recomiendo esto en una aplicación HTML o en una aplicación React que quizás sea antigua que ya no estás tocando y solo quieres incluir alguna telemetría básica. Así que simplemente incluyes la etiqueta de script. Pero generalmente, el patrón que recomendaría es que instales la extensión APM rum, lo siento, la extensión elastic APM rum usando MPM y luego uses los inits y agregues las opciones apropiadas.

Así que las cosas que necesitas decirle al agente que va a enviar que básicamente van a categorizar las señales que tu aplicación va a enviar es el nombre del servicio. Si estás trabajando en muchas aplicaciones diferentes, que ciertamente fue mi experiencia, necesitas saber a qué aplicación corresponden las señales. Y también, si es el front end de React, o esos servicios de back end, cuando llegamos al trazado de frente a atrás. Luego tienes orígenes de trazado distribuido, esto es necesario porque por defecto, el rum agent opera en la política de mismo origen. Así que necesitas asegurarte de que pueda agregar el encabezado de trace parent a esas solicitudes HTTP que van de regreso a los servicios de back end, para que puedas ver realmente la traza completa, que veremos más adelante. Luego tienes la URL del servidor, este es el despliegue L al que vas a enviar. Y luego tienes atributos opcionales de versión del servicio y entorno, que aunque no son necesarios, puedes usarlos para asegurarte de que tal vez quieras comparar errores, ver cuántas versiones del servicio retrocede para tratar de identificar la fuente del problema. O incluso si estás haciendo comparaciones ambientales, estos atributos pueden ser útiles para agregar.

Pero también necesitamos pensar en el elemento React porque diferentes frameworks SPA se comportan de manera diferente. Y a veces puede que necesitemos agregar integraciones de framework personalizadas particulares junto con, para asegurarnos de que obtenemos la telemetría apropiada para nuestra aplicación. Y en este ejemplo particular, usas la extensión APM run react, que es otra instalación de MPM. Y usas eso para acceder al componente de rutas APM que luego se envuelve junto con tu ruta react y tus rutas DOM. Esto es a partir de la versión seis. Así que si estás usando versiones anteriores, asegúrate de que estás usando el patrón correcto. Todo está cubierto en la documentación.

Ahora, solo una advertencia, necesitamos pensar en los tipos de agentes que estamos agregando a nuestras aplicaciones. Porque si no tenemos cuidado, y no estamos usando las optimizaciones apropiadas, van a inflar la construcción, no hay manera de evitarlo, no importa si estamos usando un rum agent, Google Analytics, Hotjar, o algo más, estas cosas realmente pueden aumentar el tamaño del bundle. Así que asegúrate de que también estás siguiendo las instrucciones apropiadas para el empaquetador que estás usando para asegurarte de optimizar la versión de producción también. Pero volviendo a lo que estas cosas nos dan, nos dan todo tipo de métricas diferentes que se capturan.

Así que aquí en Elastic, puedes ver que tengo Core Web Vitals. Y lo bueno de esto es que a diferencia de cuando usamos herramientas como Google Lighthouse o algo más donde solo estamos ejecutando un informe genérico, esto se basa en lo que un usuario realmente está haciendo en tu aplicación y se captura en el tráfico de usuarios en vivo. No se captura como un evento sintético como tendrías con un informe de Lighthouse. También tienes estadísticas estáticas sobre las cargas de página, tienes información del agente para que puedas ver tal vez si un usuario está encontrando un error en un navegador específico y usar toda esa información para realmente averiguar qué está pasando mientras un usuario está usando tu aplicación React.

Pero además, también tenemos la noción de traces. Así que recuerda que hablé de estos spans que sabíamos pero tal vez no estábamos muy seguros de lo que realmente eran? Esto es de lo que estoy hablando. Estoy hablando de poder ver la carga de bundles particulares, la invocación de HTML u otras llamadas, y también la carga de otros activos como CSS para que puedas identificar dónde están los posibles cuellos de botella. Pero necesitamos más que eso porque queremos que la telemetría subyacente se conecte al servicio de backend. Y esto es importante para mí personalmente porque varias veces tuve que lidiar con un problema solo para descubrir que el problema estaba realmente en el servicio de backend. Era sorprendentemente alto cuando era ingeniero. Así que es importante tener ambos lados de la moneda.

Para eso, voy a recomendar usar open telemetry para que puedas usar ese estándar abierto y usar el protocolo de open telemetry con cualquier plataforma de observabilidad compatible con el proveedor. Así que si tomamos Node.js como ejemplo, manteniéndonos con el ecosistema de JavaScript, lo que puedes ver es que puedo realmente auto instrumentar. Tengo el enfoque manual próximamente. Pero lo que necesitas hacer es especificar ya sea los atributos opcionales bajo la variable de entorno OTL resource attributes. Tienes tu nombre de servicio. Luego tienes el endpoint, a qué tipo de despliegue lo estás enviando. O a qué plataforma de observabilidad particular generalmente lo estás enviando que es compatible con open telemetry. Luego necesito especificar mi bearer token en los encabezados para la autorización, que es un paso que no necesitaba con el agente de Rome. Y luego tengo que especificar los protocolos de exportador, que es OTLP. Y tengo que especificar eso para traces, métricas y logs, solo tomando una advertencia de que los logs están actualmente en desarrollo. Así que podrías querer considerar eso cuidadosamente, pero está por venir en el futuro. También deberíamos hablar sobre los detectores de recursos de nodo, que es ese en la línea número siete. Esto es si quieres ser muy específico sobre qué métricas vas a enviar, porque podría ser que estés pensando en los costos de almacenamiento y no quieras enviar todo, lo cual por defecto lo hace si no especificas nada. Y luego para auto instrumentar, usa opciones de nodo para especificar que vas a registrar el open telemetry y usar la opción require, que obviamente puedes agregar al final del comando de ejecución si así lo eliges, o puedes usar opciones de nodo como tengo aquí. Y eso significará que también va a adjuntar el open telemetry al proceso en ejecución y recopilará todos los datos básicos de telemetría para ti sin que tengas que cambiar el código. Sin embargo, podrías tener situaciones donde necesites tal vez agregar spans personalizados o transacciones o metadatos adicionales que quieras ver. Y en ese caso particular puedes usar el enfoque manual, lo que significa que necesitas inicializar el convertidor, inicializar esos formatos de exportador manualmente, y luego puedes agregar transacciones adicionales usando la API de open telemetry. Y eso significa que podremos ver no solo dónde está nuestra llamada de servicio de backend individual, sino que también podrás ver de qué servicio proviene. Así que si eres como yo, que tiene todo tipo de microservicios por todas partes, podrás ver exactamente a qué servicio va, si está entrando o no, y todos estos otros metadatos útiles también.

Así que así es como usamos RUM y OTEL juntos, pero también hablé sobre el monitoreo sintético, y podrías preguntarte qué es eso. Entonces, el monitoreo sintético es cuando tenemos un script que se ejecuta con una frecuencia fija, tal vez cada 10 minutos, una hora, algo así, que va a hacer ping a un endpoint dedicado en nuestro ecosistema de aplicaciones o va a automatizar interacciones de usuario como clics, entrada de texto y otros comportamientos contra nuestro sitio web de React para asegurarse de que está vivo y bien. Y la esperanza es que puedas detectar problemas antes de que un usuario lo haga y ser alertado al respecto.

Así que voy a usar Playwright para JavaScript, que es un marco de pruebas de extremo a extremo mantenido por Microsoft que se utiliza dentro del Ecosistema de Elastic. Si estás usando un proveedor diferente, Selenium es a menudo otra alternativa, así que asegúrate de mirar a qué proveedor está asociado con el marco de automatización que te permita hacer esto. Y luego también necesitarás ejecutarlo como parte de tu CI también. Queremos asegurarnos de que estamos ejecutando el monitor como código en etapas anteriores para potencialmente detectar defectos y también usarlo como una prueba, por lo que también vamos a usar GitHub Actions. Pero primero, déjame explicar cómo encajan estas piezas en un poco más de detalle antes de sumergirnos en el código.

Así que lo primero que necesitamos pensar es en tener definiciones de JavaScript o TypeScript que tengan nuestra prueba de Playwright envuelta en el operador de sintéticos. A partir de ahí, se ejecutará como una prueba de extremo a extremo en GitHub Actions bajo revisión por pares o bajo desarrollo local cuando básicamente tienes un pequeño inicio en ejecución que te permite básicamente probar a medida que avanzas y emprender desarrollo impulsado por pruebas mientras construyes la característica. Y luego, cuando llega el momento de desplegar, empujas tus monitores al mismo tiempo para asegurarte de que tu aplicación y tus monitores estén sincronizados. Lo último que quieres son monitores fallidos porque básicamente no están teniendo en cuenta los cambios que has hecho. Y usarías autenticación de clave API para empujar eso a donde se está ejecutando. Y luego los monitores se ejecutarán en un horario fijo programado a través de la infraestructura subyacente de Kubernetes para empujar a la aplicación web de producción y luego almacenar los resultados de telemetría de cada ejecución en Elasticsearch.

Así que aquí hay una prueba. Esta es una prueba de Playwright. Y para cualquiera que no esté familiarizado con Playwrights, las acciones clave que tengo aquí, como puedes ver en la línea 4, estoy diciendo que voy a ir a la página de inicio de sesión. Y luego, a partir de ahí, en las líneas 6 y 7, estoy sacando mi formulario de inicio de sesión y verificando que esté presente. No estoy usando localizadores CSS aquí a propósito. Estoy usando el atajo get by test ID porque esto significa que se vinculará al atributo data test ID en el elemento HTML en la página. De esa manera, desacoplas tu estilo de tu ubicación de prueba y lógica. Si usas, en mi experiencia, los selectores CSS y luego alguien comienza a cambiar estilos, tal vez quieras cambiar el aspecto o la apariencia, dependiendo de los selectores que elijas, terminas con pruebas inestables que cambian solo porque moviste un elemento bajo otro hijo. Así que intenta usar test ID, por favor. Así que a partir de ahí, necesitamos usar el botón de envío. Estamos verificando nuevamente, viendo si está deshabilitado porque no quiero que un usuario ingrese credenciales vacías en un flujo manual. Y a partir de ahí, puedo agregar las credenciales usando fill. Ahora, estos son valores ficticios a propósito. Por favor, no uses credenciales de producción legítimas en este caso. Y luego voy a llenar las cajas de entrada apropiadas con el nombre de usuario, contraseña, valor, luego voy a la línea 25. Estoy verificando que mi botón de envío ahora esté habilitado.

navegue a la página de pedidos para que podamos comenzar a ordenar artículos de mi menú. Así que para convertir esto en un monitor, necesitamos configuración. Y la forma más fácil de hacerlo es realmente usar el asistente de inicio, que genera un proyecto de andamiaje para ti. Así que tengo ejemplos para comenzar. Tengo monitores ligeros, que son latidos, y no estoy hablando de esos hoy. Y luego también tengo el package.json, que genera los comandos para ejecutar las pruebas y también empujar los monitores. Y luego lo tengo como una configuración que puedo usar para especificar qué está pasando con mis monitores individuales que vienen en 10 pruebas. Así que esto es lo que parece la configuración del entorno. Así que verás que está empujando en el entorno de nodo, y eso me permite especificar parámetros que son específicos para ese entorno. Así que verás en la línea 6, estoy especificando la URL como localhost. Pero luego si nos saltamos hasta las líneas 33 a 35, verás que realmente puedo sobrescribir ese valor particular con la URL de producción. Y esto significa que podemos usar la misma definición de viaje en dos lugares. Tengo opciones de Playwright en la línea número 10. Usarías estas para agregar configuraciones y opciones específicas de Playwright. Así que un buen ejemplo sería si quieres hacer emulación de dispositivos. Tal vez quieras emular lo que va a suceder en un dispositivo Android versus un dispositivo iOS, y agregarías los dispositivos compatibles apropiados según la documentación de Playwright. Luego verás en la línea 17 a 21, esta es la configuración predeterminada del monitor diciendo que se va a ejecutar cada 10 minutos, y estoy usando la infraestructura de Elastic UK. No lo estoy ejecutando en mi propia ubicación de configuración, pero puedo hacerlo utilizando fleet e instalándolo donde necesite instalarlo. Y luego, la configuración del proyecto es básicamente dónde está la pila elk a la que quiero enviar esto. Así que esa configuración luego se pasa a un viaje junto con el objeto de página de Playwright. Así que esto es lo que necesitamos hacer para cambiar esa prueba que teníamos en un monitor. Solo necesitamos dividirla en un viaje de pasos más lógicos. En primer lugar, esto funciona bien porque te permite utilizar patrones como el desarrollo dirigido por comportamiento donde estás especificando el flujo de trabajo del usuario en un lenguaje similar al inglés que puedes aplicar a pasos individuales. Y también significa que cuando llegamos al lado del monitor, tienes una mejor idea de qué paso ha fallado precisamente en un proceso más largo, porque recuerda, estos viajes de usuario probablemente pueden volverse bastante largos y complicados. Así que estoy configurando yendo a la URL que estoy pasando en parámetros y el paso anterior. Y desde allí, solo estoy envolviendo mi inicio de sesión y mis pasos manuales que estaba haciendo antes en la única prueba y dividiéndolos. No he cambiado nada del código de Playwright que tengo en absoluto. Así que obviamente, voy a ejecutarlo localmente. También voy a ejecutarlo dentro de mi canalización de CI. Así que para ejecutarlo como una prueba, especificaré los entornos de nodo desarrollo, todavía necesito mis credenciales.

Y luego voy a ejecutar el comando real para ejecutar las mismas definiciones como lo hice en el desarrollo local desde el directorio de journeys. Y estoy publicando usando un reportero JUnit, pero también hay uno de build kite en caso de que alguien esté usando build kite.

Luego, cuando llega el momento de producción, necesito enviar estos. Necesito asegurarme de que estoy enviando las definiciones cuando estoy desplegando mi aplicación. Y cuando hago eso, termino con un conjunto de monitores que se ejecutarán en los horarios que he definido ya sea dentro de la configuración sintética o alternativamente en el monitor individual. Y puedo ver qué pasos particulares están pasando y fallando. Puedo ver cuánto tiempo están tomando, lo cual para mí cuando estaba escribiendo pruebas de extremo a extremo era súper importante porque si se estaban haciendo más y más largas, sugiere que tal vez el rendimiento de mi aplicación necesitaba ser investigado para ver por qué. Pero luego también puedo ver los pasos subyacentes. Podría ver cuánto tiempo toma cada paso individual como puedes ver desde mi derecha. Y también puedo ver exactamente qué error está ocurriendo, qué paso está fallando. E incluso tengo esos core web vitals también que tenemos que advertir. Estos son más sintéticos que los de monitoreo de usuario real, pero ciertamente pueden darte una idea, tal vez un paso individual no esté completamente alineado con tus core web vitals como te gustaría.

Y luego podemos comenzar a hacer cosas más inteligentes. Podemos generar alertas si estas cosas comienzan a fallar tantas veces, podemos comenzar a preguntar, ya sabes, al asistente para chatear con PT, qué significan los errores y luego intentar usar eso para obtener información. Así que, he hablado sobre logs, métricas y trazas y he hablado sobre cómo se relacionan con nosotros como desarrolladores de React y también he hablado sobre las herramientas que usamos para eso. Cómo usamos el monitoreo sintético y Raman open telemetry juntos no solo para evaluar el comportamiento del usuario y el tráfico y obtener información sobre cuellos de botella y rendimiento, sino también cómo podemos intentar simular algunas actividades de usuario y detectar los problemas antes de que ocurran. Si quieres ver los ejemplos de código, tienes el de RUM a la izquierda y tienes el monitoreo sintético a la derecha. Si tienes alguna pregunta, siéntete libre de comunicarte y React Advanced London. Ha sido un placer. Gracias.