Identificar Problemas y Prevenir Ralentizaciones en tus Aplicaciones Vue.JS

Hola. Mi nombre es Simon. Soy un ingeniero de soluciones en Sentry. Nos enfocamos en la observabilidad del código. Con Sentry, puedes entender la salud de tu aplicación desde el front end hasta el back end. Sentry está diseñado para todos los desarrolladores, lo que significa que brindamos soporte a todos los lenguajes principales y frameworks, incluyendo Vue. Con el SDK de Sentry en tu aplicación, puedes alertar a los miembros del equipo necesarios y permitir que tus desarrolladores optimicen la experiencia del desarrollador y del cliente. La plataforma de Sentry proporciona múltiples perspectivas sobre la salud de tu aplicación. Pero hoy nos enfocaremos en el monitoreo de errores y el monitoreo de rendimiento. Para comenzar con Sentry, vamos al sitio de documentación de Sentry, buscamos Vue, o hacemos clic para ver las 99 plataformas compatibles. Y en esta sección de JavaScript, tenemos un enlace a Vue. El proceso de instalación es muy sencillo. Es una instalación de NPM y unos pocos

líneas de código para configurar Vue en tu aplicación. Lo que esto hará es conectar Sentry a tu manejador global de errores. Y a medida que los usuarios interactúan con tu aplicación, se envían eventos y transacciones a Sentry. Aquí tengo una aplicación de demostración Vue muy básica. Echemos un vistazo juntos. Acabo de actualizarla porque la he configurado para que se envíe una solicitud HTTP al cargar la página. Revisaremos lo que eso significa en el lado del performance, pero por ahora hagamos clic en estos botones de error. Y a medida que estos errores ocurren, también se envían a Sentry. He configurado algunas alertas para nosotros. Así que en realidad estamos recibiendo notificaciones de estos errores mientras ocurren. Así que en Slack, acabo de hacer clic en una notificación que nos llevará directamente a este error. Y todos estos detalles del error se muestran frente a mí. Tenemos el error, el mensaje de error, la magnitud de este error, cuántas veces ocurrió y cuántos usuarios se vieron afectados. También integramos con sistemas de control de código fuente, por lo que tenemos detalles sobre el commit que pudo haber causado esto, enlaces a esos commits, información contextual a través de estas etiquetas como los detalles del usuario, el entorno en el que se encuentran. Podemos agregar nuestras propias etiquetas, pero lo que probablemente nos importa más en este momento es la traza de la pila. Así que está justo debajo. Y en un mundo sin Sentry, estaríamos lidiando más con una traza de pila minimizada, óptima para el performance, pero no muy legible para los humanos. Pero afortunadamente, Sentry nos ayuda con eso. Así que durante nuestro proceso de compilación, hemos subido nuestros mapas de origen, Sentry tomó eso, tradujo el mapa de origen, la traza de la pila para nosotros, y tenemos esta hermosa traza de pila legible para los humanos, incluyendo el resaltado de la línea donde ocurrió el error. Y vemos que la respuesta fue falsa. También sabemos qué archivo revisar. Así que tengamos todo eso en mente, cosas muy interesantes. Pero justo debajo de eso, tenemos más contexto, una línea de tiempo de las actividades en nuestras migas de pan. También podemos agregar nuestras propias migas de pan si queremos. Y todo esto está instrumentado automáticamente. Podemos ajustar el tiempo a un formato más de cuenta regresiva donde cuando lleguemos a tiempo igual a cero, obtendremos ese error interno del servidor. Así que todo esto es genial para obtener más contexto. Y si eso no fuera suficiente, este error ha ocurrido unas 50 veces. Así que hemos recopilado todas las etiquetas de todos estos errores en esta sección de mapa de calor a la derecha. Con toda esta información, el contexto y el contenido desde la perspectiva del front-end, podemos considerar crear un nuevo ticket o vincularlo a un ticket existente a través de estas integraciones con herramientas de seguimiento de problemas. También quiero llamar la atención sobre la función de traza distribuida que tenemos en Sentry. Dado que tenemos Sentry instalado en nuestro back-end

También vemos una relación en el back-end. Vemos que hay un evento secundario y un error relacionado que debemos revisar. Esto se refiere a la respuesta que indica que OK fue falso proveniente de nuestro back-end. Si hacemos clic aquí, podemos ver las etiquetas del back-end, la traza de la pila del back-end, las migas de pan del back-end, todo lo que vemos aquí, pero desde la perspectiva del back-end. Cambiemos de tema por un momento. Hay mucho en el lado de los problemas y tenemos tiempo suficiente para ver la salud del rendimiento que proporciona Sentry. De inmediato, vemos nuestras métricas web. Eso es cuánto tiempo tarda en cargar la primera cosa, la cosa más grande en cargar, la demora de entrada, la estabilidad de nuestra página, la latencia a lo largo del tiempo y la distribución en las últimas 24 horas. Eso fue rápido, ¿verdad? Charla relámpago. Pero lo que destaca aquí es el índice de sufrimiento del usuario. Al resaltarlo, nos da una definición de esta métrica. Lo mismo ocurre con todas estas otras métricas también. Pero sigamos nuestro instinto, hagamos clic en la transacción de la página de inicio aquí y podrás ver el desglose de la duración, cuánto tiempo tardaron estas transacciones en completarse en el pasado, en este caso, 24 horas. Podemos interactuar con este gráfico resaltando una sección diferente. Eso actualizará el marco de tiempo, por supuesto, y también los eventos que aparecen. La mayor parte de la operación está cubierta en este rojo HTTP. Al hacer clic en un ID de evento, podemos ver el desglose de la operación en este tipo de gráfico en cascada. Tomó 15 segundos para esta transacción, y la mayor parte del tiempo de operación provenía de esta solicitud del cliente HTTP. Y esto va a nuestro back-end, y podemos ver eso porque tenemos este ícono de suma aquí. Tenemos configurada la traza distribuida. Si no lo tuviéramos, simplemente no veríamos este ícono de suma y no podríamos expandirlo. Afortunadamente, podemos hacerlo, y podemos ver que gran parte de este tiempo se debe a estas consultas secuenciales a la base de datos. Ahora tenemos una forma de avanzar, trabajar con nuestro equipo de back-end, optimizar estas consultas a la base de datos, hacerlo como una situación de procesamiento asíncrono, y eso mejorará la experiencia del usuario y reducirá el sufrimiento del usuario también. Así que solo para recapitular por un momento aquí. En nuestra aplicación Vue, hicimos clic en algunos de estos botones de error. Recibimos notificaciones a través de nuestra integración con Slack para llegar a nuestra página de errores. Al observar el contexto y el contenido completo desde la perspectiva del front-end y con la traza distribuida, también podríamos hacerlo desde la perspectiva del back-end. En cuanto a la salud del rendimiento, tenemos un resumen de esa salud a través de estas métricas web, seguimos nuestro instinto a través del índice de sufrimiento del usuario en esa transacción de la página de inicio, vimos el desglose de la operación y podemos hacer algunas mejoras en estas consultas subóptimas a la base de datos. En cualquier caso, muchas gracias por revisar esta aplicación Vue conmigo. Que tengas un maravilloso resto de tu conferencia. Muchas gracias. Transcrito por https://otter.ai