Seguimiento de errores y ralentizaciones en Node + JavaScript utilizando Sentry

Muy bien, empecemos. En primer lugar, gracias a todos por tomar el tiempo para asistir a esta masterclass. Solo quiero confirmar si todos pueden escucharme. Si alguien puede simplemente decirme sí en el chat, sería fantástico. Genial, gracias. Lo aprecio, a todos.

Muy bien, hoy vamos a hablar sobre cómo podemos rastrear nuestra experiencia de usuario en nuestras aplicaciones de Node y JavaScript, específicamente cuando se trata de bloqueos, errores, excepciones, cargas de página lentas, renderizaciones, y todas esas cosas en las que estarías interesado si fueras el desarrollador que escribió este código, y lo puso en producción.

Además, obtendremos la visibilidad y el contexto que necesitamos desde el lado de la aplicación para poder saber por qué ocurren estos problemas, dónde en el código ocurren, a quién le ocurren y solucionarlos y avanzar.

A modo de introducción, mi nombre es Neil Manbar. Vengo de un fondo de desarrollo front-end y ahora dirijo el equipo de ingeniería de soluciones en Sentry, donde ayudo a otros desarrolladores front-end y desarrolladores de backend a usar Sentry y conocer sus problemas para que puedan solucionarlos, que es el ejercicio que vamos a hacer hoy y estoy muy emocionado al respecto.

Entonces, rápidamente, repasemos la agenda. Primero, quiero demostrar el problema. Quiero mostrar dónde están las brechas cuando estás desarrollando una aplicación de navegador que se comunica, digamos, con un backend Express, y cuando ocurren problemas, dónde están las brechas específicas en visibilidad y contexto y por qué necesitas una verdadera herramienta de monitoreo de aplicaciones dentro de tus aplicaciones.

Luego procederemos a integrar Sentry, específicamente introducir el SDK en nuestra aplicación para el front-end. También configuraremos los mapas de origen para obtener una traza legible. Y luego pasaremos por todos los diferentes casos de uso. Usaremos Sentry para solucionar errores. Le diremos qué está sucediendo, obtendremos todo el contexto que necesitamos, el quién, qué, cuándo, dónde y por qué para poder hacer algo al respecto. Y haremos lo mismo para las ralentizaciones. Y luego, como desarrollador, estás lanzando versiones, estás lanzando nuevas compilaciones. Estamos tratando de hacer esto a un ritmo cada vez mayor. Sentry también te dirá cómo todo esto se une en términos de versiones, si tu versión es adoptada, si tiene nuevos errores, si tiene ralentizaciones, etc. Y luego cualquier dato que enviemos a la plataforma, podremos analizarlo, consultar y crear paneles de control, y lo explicaré al final.

Si tienen alguna pregunta, no duden en escribirla en el chat. También responderé preguntas al final.

Entonces, ¿por qué el monitoreo de aplicaciones, y por qué realmente lo necesito en mis aplicaciones? En lugar de simplemente proporcionarles un montón de texto, voy a mostrarles el problema. Aquí tengo mi aplicación, y básicamente es un front-end de React que se comunica con un paquete de Express. Voy a dejar la consola abierta. Voy a actualizar y, de vez en cuando, se bloqueará, y ahí lo tienen. Y cuando se bloquea, básicamente tenemos esta traza de pila ilegible. Realmente no sabemos qué está pasando. Ni siquiera sabemos si ocurrió, a menos que el usuario nos lo informe, o eventualmente descubramos que esto está sucediendo y luego lo reproduzcamos, y luego obtenemos esta información aquí.

Además, digamos que cuando esto funciona, también hay ralentizaciones. Aquí es lento. ¿Es por el back-end? ¿Es por el front-end? ¿Es por mi código de renderizado? ¿Es por alguna ralentización en la capa de la database? No lo sé. Así que agreguemos algunos elementos al carrito, y luego procederemos a pagar. Y cuando lo hacemos, también hubo cierta lentitud, y parece que también hubo un error. Así que ahora voy a resumir lo que sucedió aquí. Si observamos, lo primero es que nos quedamos con una traza de pila ilegible. Estaba minimizada. No sabíamos qué estaba pasando, e incluso ni siquiera sabíamos del error en primer lugar. Lo mismo con la ralentización. Ni siquiera sabíamos de la ralentización a menos que un usuario nos lo informara, y luego lo reprodujéramos, y luego tuviéramos que buscar en todas las herramientas de perfilado y todo ese tipo de cosas. Y además, también hubo un error con la ralentización. Entonces, en el front-end no tenemos la visibilidad que necesitamos. Y estamos limitados a la reproducción. Y en el back-end, si no estamos utilizando una herramienta de monitoreo de aplicaciones, terminamos teniendo que buscar en los registros, armar consultas, y luego armar esto desde el exterior en lugar de desde el interior de la aplicación.

Así que vamos a mostrar lo que un desarrollador realmente querría y necesitaría cuando se trata de este tipo de cosas. Necesitarías el contexto. Necesitas un SDK que esté presente en el código que envía información. Y luego recibirás una alerta cuando haya un problema. Tu equipo lo sabrá. Y luego podemos obtener el contexto de la capa de la aplicación, quién, qué, cuándo, dónde y por qué, que mostraré que Sentry muestra. Y sería genial si incluso pudiéramos identificar qué confirmación o cambio de código causó esto. Así podríamos asignarlo al desarrollador correcto, y luego avanzar con esto y volver a un estado exitoso. Entonces, este es el flujo de trabajo que Sentry podrá proporcionarte. Enviaremos errores, transacciones y sesiones. Recibirás una alerta cuando algo salga mal, lo sabrás, obtendrás el contexto que necesitas y podrás avanzar. Pasaremos por todo esto, pero resolveremos errores. Resolveremos ralentizaciones. Veremos si nuestra última versión se adoptó correctamente. Crearemos paneles de control, analizaremos los datos. Y como desarrollador, uso Slack. Uso GitHub. Uso JIRA. Uso mis propias herramientas, y también uso alrededor de cien de estas herramientas juntas. Para aquellos de ustedes que deseen seguir el contenido, les sugiero que creen su propia aplicación Express utilizando Express Generator, y lo mismo con React, pueden crear una aplicación React. Y luego regístrense en Sentry. He insertado un enlace aquí, sentry.io/signup, y crearemos dos proyectos. Voy a usar mi propia aplicación. Es un poco más complicada. Por eso sugiero que ustedes simplemente usen Express Generator o creen una aplicación React y comiencen desde una aplicación completamente nueva. Registrarse en Sentry es gratuito. Simplemente vayan a Sentry.io/signup, creen una organización y luego creen proyectos, uno para su React, uno para su Express. Antes de meternos en todo esto, voy a resaltar toda la documentación, y luego pasaré por este ejercicio con todos ustedes. Mostraré cómo se integra en esa aplicación PlantStore que estaba mostrando.

Primero, vamos a dirigirnos a la documentación. Para React, será bastante sencillo, y verás que es muy similar a Express también. Todo lo que tienes que hacer es npm install o package o yarn add dependiendo del gestor de paquetes que estés utilizando. Todo lo que tendrás que hacer, y esto se suele hacer en index.js o lo antes posible dentro de tu aplicación para que podamos comenzar a rastrear esos errores y rastrear las transacciones. Todo lo que tienes que hacer es sentry.init, y cuando crees un proyecto, se te proporcionará un DSN, que es una clave, y luego queremos que los errores se envíen a Sentry y este es el ID de proyecto. Para rendimiento, vamos a habilitar nuestra integración de trazas y queremos que se generen el 100% de las trazas. Además, en mi ejemplo, voy a utilizar el enrutador de React y Redux, destacaré rápidamente la configuración para eso. También querremos cargar los mapas de origen para el frontend. Primero, debes poder generar esos mapas de origen. Por lo general, se puede hacer con un indicador, creo que es Source Map o DevTool, asegurándote de que tu proceso de compilación los genere y luego cárgalos en Sentry. Hay varias formas de cargarlos. Puedes usar nuestro complemento de webpack, que es muy fácil. Simplemente instálalo y luego especifica. En mi ejemplo, voy a utilizar nuestra herramienta de línea de comandos (CLI), que nuestro complemento de webpack utiliza detrás de escena directamente, pero todo lo que tenemos que hacer es básicamente sentry CLI upload source maps. También destacaré todo esto en un momento.

Repasemos rápidamente estas instrucciones para Node.js. Si vamos a Node.js y luego a Express. Una vez más, muy similar, npm install. Luego lo que haremos es sentry init. Adjuntaremos nuestro controlador de solicitudes para performance aquí, y también nuestro controlador de errores, y estaremos listos aquí. Permíteme mostrar esto en mi aplicación.

Aquí mencioné que tengo una aplicación de React que se comunica con un backend de Express aquí, y aquí está. Lo revisaremos junto con Sentry. Ya tengo una organización aquí. Debes ir a proyectos, y luego podemos crear un proyecto. Continúa y selecciona React. Se nos mostrarán las instrucciones de instalación. Aquí en este caso, solo para ahorrar tiempo, ya he hecho parte de esto, pero destacaré lo que se ha hecho y dónde están los puntos de integración. Aquí he instalado estos dos paquetes. Luego, si vamos a index.js, aquí podemos ver sentry.init, el DSN, y eso se creó como parte de la creación de este proyecto. Aquí tengo esto para performance, y quiero que se envíen el 100% de las transacciones. También quiero que Sentry sepa de qué versiones provienen todos estos datos. Como desarrollador, no ayuda tener errores o ralentizaciones en los últimos dos días. Quieres saber qué sucedió en las últimas versiones. Todavía está sucediendo, y lo mismo con el entorno. Quiero saber si está sucediendo en producción o si está sucediendo en alguno de mis entornos anteriores, para poder hacer algo al respecto. Mencioné que tenemos que cargar esos mapas de origen, así que eso es lo que he hecho aquí, crear aplicaciones de React. Si ejecutas una compilación de producción, se generarán esos mapas de origen. Aquí los estamos cargando en Sentry, y luego vas a crear un token de autenticación, y lo establecerás como una variable de entorno o lo pasarás para que podamos enviar esto a nuestra organización de Sentry, específicamente a esa versión, y eso unirá todos estos datos, por lo que cuando llegue un error, tendrá esa versión. Tendrá mapas de origen asociados. Aplicaremos esa transformación y obtendremos una pila limpia, que luego utilizaremos para agrupar, y hablaré de todo eso en un momento. En el lado de Express, aquí está mi paquete en JSON. Hemos incluido los paquetes aquí, y luego en mi server.js, lo que estoy haciendo es sentry.init, dfn, environment, y release, tal como vimos antes, y esto es para performance. Queremos que se envíe el 100% de las transacciones, y eso es todo aquí. Una cosa que olvidé destacar es que aquí para el frontend, si estás usando React, o, perdón, Redux, adjuntamos ese contexto a nuestros eventos si estás utilizando nuestra integración, y aquí está, justo aquí. También estoy utilizando la instrumentación del enrutador para que podamos adjuntarnos a eso y auto-instrumentar en consecuencia.

Entonces, después de todo esto, ¿qué se va a hacer? Voy a seguir adelante, una vez más, volviendo a la documentación y simplemente destacando lo que se va a configurar. Entonces, si entramos aquí, y luego entramos en React, puedes ver que informaremos automáticamente errores y excepciones dentro de tu aplicación. Y luego, si configuramos el rendimiento, también crearemos una nueva transacción para cada carga de página y evento de navegación y subtrazas para solicitudes de backend. Y verás muchas cosas, también y te lo mostraré en un momento. Pero básicamente, todo lo que sucede en el navegador se adjuntará como una subtraza, y podremos entender qué sucedió. Y de manera similar para Node, esto mostrará errores y transacciones. Además de cada solicitud que ingrese al backend, habrá una transacción, y todas las actividades dentro de ella serán subtrazas. Y te lo mostraré. Y tenemos integraciones con bases de datos y demás, también para mostrarte qué está sucediendo allí. Pero ahora que estamos integrados, y si todos siguen el proceso, básicamente ejecutas todas esas instalaciones de NPM en Sentry.init, copiando y pegando el código desde aquí debería funcionar, y luego también se te presenta el código para crear un error para que podamos ver si todo está configurado correctamente. Pero ahora que estamos integrados, los errores se enviarán a Sentry, las transacciones se enviarán a Sentry. También se enviarán sesiones, para que sepamos si alguien ingresó a la aplicación y tuvo una salida saludable o si se bloqueó y, ya sabes, las sesiones sin bloqueos disminuyeron al 95% y queremos depurar eso y Sentry sabe sobre nuestros entornos y versiones y en el frontend, también cargaremos los mapas de origen. Entonces, ¿cómo se ve todo esto después de estar configurado? Aquí tengo una aplicación que ya está enviando tráfico, pero puedes ver que aquí se envían las sesiones sin bloqueos, aquí se envían las transacciones y podemos mostrar esas y entrar en las vistas específicas en un momento y también se configuran los errores. Pero esto ayuda a comprender exactamente qué está sucediendo. Sentry conoce todas estas versiones y veremos las alertas más adelante. Pero en resumen, a través del poder de esta vista única, aquí vemos que disminuimos al 95%, podemos resaltar ese conjunto de datos y ver exactamente los errores que impactaron eso. Entonces, ahora lo que vamos a hacer es pasar por los diversos flujos de trabajo aquí. Resolvamos los errores. Sé que te mostré un poco a nivel general aquí, pero ahora realmente vamos a profundizar cuando se trata de errores, ralentizaciones y luego, como desarrollador, te mostraré cómo sé si publiqué una versión y si se adopta correctamente y qué está sucediendo con ella. Y luego ensamblaremos algunas consultas y paneles, y te mostraré cómo las integraciones se relacionan con todo esto. Entonces, primero, vamos aquí. Y déjame seguir adelante. ¿Recuerdan este error que tuve antes en la página de inicio? Entonces, si no estuviera usando Sentry, tendría que reproducirlo y finalmente llegar a esto. En este caso, estoy usando Sentry. Entonces, lo que puedo hacer ahora es que automáticamente recibiré una notificación de que hay un error. Ahí vamos. Acaba de llegar. Parece que hubo un error de rango. Y ahora esto me lleva directamente al problema de Sentry. Y este fue un error no controlado en el frontend. Y puedo ver exactamente el quién, qué, cuándo, dónde y por qué. Parece que fue un error de rango. Ocurrió X cantidad de veces para Y cantidad de usuarios. Comenzó hace unos 14 días, como podemos ver en este gráfico aquí. Ha estado aumentando en las últimas 24 horas en consecuencia. Se introdujo por primera vez en esta versión. Está sucediendo en esta versión. Parece que está sucediendo principalmente en Chrome. Oh, sí. Y aquí hay una etiqueta personalizada, que te mostraré más tarde. Puedes configurar. Pero está sucediendo a mis clientes más importantes en producción. En estas versiones. Y si quiero ver todos los datos específicos del evento, puedo recorrerlos aquí mismo. Pero aquí están todas las etiquetas asociadas. Y vemos exactamente de quién proviene. Y aquí está probablemente la parte más importante para un error cuando se trata de un desarrollador, específicamente esta fábrica. Entonces, si no estuviéramos usando algo como Sentry, esto es lo que eventualmente veríamos, este código ofuscado y minificado. Pero como cargamos esos mapas de origen en Sentry, llegamos al código legible. Y luego incluso te mostramos el contexto o las líneas, exactamente donde ocurrió el error, la traza de la pila, y el contexto del código para cada uno de estos marcos.

Y podemos ir bajando según sea necesario. Y algunos de estos son bibliotecas. Por lo tanto, no queremos verlos, así que podemos hacer solo la aplicación. Y estos son los marcos relevantes que el desarrollador querrá ver.

Entonces aquí. Parece que se produjo un error en la línea 14 de errors.js. Y debajo de eso tenemos migas de pan. Esto es lo que sucedió antes de llegar a los errores. Entonces aquí redux estaba haciendo su trabajo. Hubo algunos registros en la consola y esto sucedió en un lanzamiento. No hay mucho, pero te mostraré otro ejemplo mañana. Pero también veríamos aquí XHRs, clics y otras interacciones.

Este es el contexto que Sentry pudo capturar, incluido el estado de redux, cualquier información del agente de usuario. Y vamos a asociar esto con transacciones, que te mostraré más adelante. Pero en resumen, como desarrollador, ahora sé quién, qué, cuándo, dónde y por qué. Y puedo solucionarlo. Puedo resolverlo. Puedo ignorarlo. O si nunca quiero verlo de nuevo, aquí hay algunos pasos que puedo tomar. Pero si esto fuera algo que se pudiera solucionar, querría arreglarlo y seguir adelante.

Muy bien. Esto fue solo un error básico no controlado en el frontend. Aumentemos un poco la complejidad. Entonces aquí, lo que voy a hacer es averiguar y debug por qué el proceso de pago estaba roto. ¿Fue el frontend? ¿Fue el backend? Y exactamente qué está sucediendo aquí. Cuando hago clic en Pagar y Enviar aquí, hay un error. ¿Qué está sucediendo específicamente? Vamos aquí. Y una vez más, recibiremos una alerta en un momento. Solo voy a ahorrar algo de tiempo. Voy a entrar aquí y realmente descubrir qué está sucediendo.

Entonces aquí, sucedió X cantidad de veces, afectando a Y cantidad de usuarios. Parece que no obtuvimos una buena respuesta desde el backend. Veamos qué estaba haciendo el usuario aquí. Parece que se hicieron clics en la lista de productos y luego, eventualmente... parece que se emitió una solicitud a nuestro backend que devolvió un 500, que se propagó a nuestro frontend. Como tal, y eso es lo que estamos viendo aquí. Entonces, este es un problema que se manifestó en el backend pero también se mostró en el frontend porque no pudimos obtener una buena respuesta. Y como estoy usando Sentry tanto en mi frontend como en mi backend, puedo simplemente entrar aquí y luego hacer clic en el error relacionado. Y ahora, con un solo clic, estoy en el frontend y el backend y veo exactamente qué sucedió. Parece que estábamos intentando comprar una serie de artículos y no teníamos suficiente inventario para ese producto. Entonces se produjo un error. Y solucionar este problema realmente solucionará ambos. Como puedes ver, como desarrollador de frontend, pude pasar del frontend al backend y ver exactamente qué estaba sucediendo.

Y veo que Ignas preguntó, sería genial tener valores de variables en la traza de la pila. Así que lo hacemos para Python y PHP, cuando es posible, pero en Node y JavaScript Lint es realmente complicado. Pero la filosofía de Sentry es que queremos poder adjuntar todo lo que podamos. Y si hubiera valores de variables, veríamos un botón de mostrar más y podríamos hacer clic en eso y también lo mostraría. En realidad, mostraré un ejemplo en Python al final. Pero aquí, una vez más, estoy en el servidor de Express, en la línea 177 de JS. Y esto es exactamente por qué sucedió esto.

Tal vez deba manejar esto mejor o agregar inventario para poder volver a vender. Pero probablemente queremos manejar esto mejor y manejarlo de manera elegante en el frontend y solucionar eso solucionaría ambos. Y como desarrollador de frontend, sabía exactamente qué sucedió. Comenzaron en el proceso de pago, hubo un error en el proceso de pago y hubo un error en el backend y eso es lo que produjo todo esto.

Muy bien. Hasta ahora, lo que hemos hecho es revisar problemas hasta ahora. Ahora revisemos los errores o revisemos el rendimiento ahora. Específicamente, estamos depurando un problema no controlado en el front-end y luego tal vez depurar un ejemplo más complejo que se debió al backend pero se manifestó en el front-end. Ahora depuremos esa ralentización. Entonces, si todos recuerdan de qué estoy hablando es cuando cargamos una aplicación y hacemos clic en productos es muy lento. ¿Es esto el front-end? ¿Es esto el backend? ¿Es una combinación de ambos? No lo sé, pero en este caso estoy usando Sentry. Entonces, lo que puedo hacer aquí es, si no tengo un bucle configurado para esto puedo simplemente ir a la pestaña de rendimiento aquí. Voy a seleccionar mi proyecto de front-end aquí. Empecemos por ahí. Y las transacciones se envían a Sentry y también aprovechamos las métricas vitales web si están disponibles aquí. Entonces, lo que me preocupa aquí es el punto de vista del producto y veo que el índice de remisión del usuario es bastante alto aquí. Parece que tarda alrededor de siete segundos en cargar. Eso es... Filtraré eso. Puedo ver que es una de las búsquedas relacionadas solo para mantener la consistencia con este usuario aquí. Lo que voy a hacer es abrir este resumen de transacción. Y... Puedo ver aquí que el desglose de la duración tarda alrededor de, ya sabes, 950 segundos en cargar, especialmente cuando se trata de un P95. Puedo alternar las métricas vitales web y si no estás familiarizado con las métricas vitales web, esto es básicamente... el mayor contenido visible, el primer contenido visible, y el primer retraso de entrada. Y algunas de estas métricas que los navegadores proporcionan además de la información básica de duración de transacción para que realmente sepas que el front-end se cargó y era utilizable. Y terminó de cargarse y realmente... para que el usuario pueda continuar con los siguientes pasos y la aplicación. Entonces aquí lo que vemos es que hay muchas LCP, que es la que estoy usando aquí que son muy altas en los siete segundos. Voy a filtrar eso aquí. Oh, ¿qué pasó aquí? Tampoco está, sí, parece que tampoco está. Measurements.lcp. Deberías usar el predictor automático. Y solo por diversión, lo que voy a hacer es navegar desde nuestro nombre. Y vamos a ver algunas de estas transacciones. Pero en el resumen de transacciones, podemos ver qué está sucediendo aquí en el agregado tal como vimos en la página de problemas. Tenemos todas las etiquetas aquí. Y aquí, yendo al grano, puedo ver que la mayor parte del tiempo se está gastando en una solicitud HTTP. E incluso SpendTree lo está identificando aquí. Parece que este sospechoso bin, esta solicitud HTTP está tardando mucho tiempo, ocurriendo con bastante frecuencia y se ha gastado mucho tiempo allí. Vamos a profundizar en esto. Voy a hacer clic aquí, y ahora veo exactamente todo lo que sucedió en el navegador. Esto es cuando cargué la página de productos. Carga de página, el navegador hizo su trabajo, importó algunos recursos, reaccionó a esto. Aquí, comenzó el montaje de navegación para ese componente. Y luego productos, que es lo que nos interesa aquí. Y ahora podemos ver que tardó mucho tiempo, específicamente el 86% del tiempo. Y después de que se cargó o se recuperó, parece que se renderizó y la verificación de largestContentfulPaint falló aquí. Y aquí, lo vemos claramente como J, aquí está el marcador rojo, aquí está la solicitud HTTP, y aquí está todo lo demás que sucedió en el navegador también desde todas las acciones del navegador, las importaciones de recursos, react haciendo su trabajo.

También podemos ver el contenido del DOM cargándose y aquí estoy usando Sentry en el backend. Así que puedo simplemente hacer clic aquí y hacer clic en Ver Transacción y ir directamente allí. Pero mejor aún, simplemente voy a retroceder un paso. Puedo simplemente desplegar esto aquí y ver exactamente lo que estaba sucediendo. Esta es la transacción del backend, en línea aquí debajo del span de la transacción del frontend, y puedo ver que llegó a Express, y parece que hicimos una serie de consultas secuenciales, y esto aquí es la razón por la cual toda esta solicitud fue lenta y fallamos en el LCP aquí. Así que tengo todo el contexto sobre la ralentización en una página aquí.

Parece que tenemos un par de preguntas que creo que me perdí. ¿Qué sucede si el código de producción está minificado? Por eso quieres cargar tus mapas de origen en relación a los problemas. Para el rendimiento, eso no importará aquí. Esto es algo que hemos instrumentado automáticamente. Parece que también hubo otra pregunta. ¿Hay alguna forma de enviar esos datos de Sentry a Google Analytics? Sí, la hay. Tenemos ganchos de servicio y reenvío de datos y cosas así que podemos mostrarte. Así que solo queríamos aclarar eso. Pero volviendo aquí, una vez más, para resumir, aquí está la página de productos, cargada, se emitió una solicitud donde se gastó el 86% del tiempo. Por eso fallamos en el LCP. Y aquí podemos ver exactamente lo que estaba sucediendo. Lo desplegamos y obtuvimos toda la información y tendremos las migas de pan y toda la información adicional aquí. Entonces, lo que estamos viendo específicamente es una transacción aquí. Muy bien.

Hagamos otro ejemplo, y este será un poco más complicado. Recuerda que cuando hacemos clic en pagar, hubo una ralentización además de un error. Así que vamos a depurar eso. Lo que voy a hacer es ir al frontend. Simplemente voy a alternar las transacciones. Esto, creo, es la transacción de pago. Y puedo ver una vez más toda la información aquí. Específicamente, lo que quiero mostrar es que esta es la transacción de pago del frontend. Está tardando X cantidad de tiempo. Hay una solicitud HTTP sucediendo. Y aquí están los errores relacionados asociados con eso también. Una vez más, estas transacciones son lentas y se ven afectadas por estos errores. Tenemos todo eso en una página. Pero vamos a profundizar en esto. Así que aquí, vamos a entrar aquí. Ahora, si hacemos clic aquí, recuerda que hacer clic aquí te lleva al error del backend. Pero podemos entrar en las transacciones haciendo clic aquí e ir directamente al backend o a la transacción aguas abajo también haciendo clic aquí dentro. En resumen, si vemos la traza completa, vemos exactamente lo que sucedió. Hubo dos transacciones y ambas tuvieron errores, y esta fue la imagen completa aquí. Y podemos ir sin problemas de una a otra para que los errores y las ralentizaciones estén en la misma plataforma, ya que frecuentemente los errores tienen algo que ver con las ralentizaciones porque puede haber habido un reintento, etc. Pero ahora conozco toda la imagen. Muy bien. Eso es genial. Hasta ahora mostré cómo podemos monitorear errores, cómo podemos monitorear transacciones y cómo podemos averiguar qué las está causando y luego obtener todo el contexto de quién, qué, cuándo, dónde y por qué, y averiguar qué está causando la ralentización. ¿Es el frontend, es el backend, es el navegador haciendo esto? ¿Es el código de mi aplicación frontend? Y a continuación, voy a hablar de las versiones. Parece que hubo otra pregunta, que puedo responder. Sí, viste que los correos electrónicos de los usuarios se muestran. ¿Hay alguna forma de anonimizarlos para cumplir con el GDPR? Sí, la hay. Puedes hacerlo en nuestro lado del servidor, diciendo que si alguna vez ves una etiqueta de usuario, adelante, anonimízala, enmascárala, elimínala. Tenemos toda esa limpieza y ese tipo de cosas en nuestro lado.

Y también puedes hacerlo dentro del SDK del lado del cliente, para asegurarte de que nunca se envíe por la red. Pero sin duda, eso es genial. Muy bien, a continuación, vamos a monitorear una versión, y luego averiguar qué está afectando esa versión. ¿Está teniendo algunos errores? ¿Está teniendo algunas ralentizaciones? Una vez más, voy a entrar en Sentry, y voy a ir a Versiones aquí. Y recientemente publiqué algunas versiones. Voy a consultar por eso. Creo que eran algo así. Así que aquí estoy consultando por versionado semántico, y puedes ver que el 20% de mis usuarios todavía están en esta versión y el 80% de los usuarios están en esta versión. Tengo una vista de 14 días aquí. Puedes ver que esto estaba recibiendo tráfico, y ahora este comenzó a recibir tráfico. Tiene una tasa de fallos. Parece que hubo una regresión un poco, y parece que también se introdujeron algunos problemas nuevos. Así que vamos a depurar esta versión aquí. También depura algunas cosas también. Pero aquí ahora veo toda la información de la sesión, y puedo arrastrar y soltar esto. En el lado derecho, tengo la adopción agregada en términos de sesiones y usuarios. Puedo ver cómo va esto en cuanto a la tasa de fallos de los usuarios a lo largo del tiempo. Veo cuándo se lanzó este código, y específicamente aquí tengo la información de la sesión en todas las versiones, esta versión, si cambió, y también puedo ver otras métricas. Nuevos problemas que se introdujeron en esta versión, pero esto probablemente también tuvo algo que ver con el porcentaje disminuido. Y puedo ver todos esos errores que se muestran y se agregan aquí. Y luego tengo las transacciones fallidas aquí también. También puedo ver transacciones lentas, cualquier cosa de eso, todo en un solo lugar. Entonces, aquí, lo que estamos haciendo es unir todos los data en términos de una versión. Y podemos entender si se está adoptando correctamente, o si no lo está, qué está impactando realmente, ir directamente al problema, ir directamente a las trazas de pila, o ir directamente a la transacción, y luego depurar desde allí. Entonces, eso es la ayuda de la versión. Así que, ahora lo que hemos hecho es mostrar cómo Sentry muestra errores, muestra transacciones, las correlaciona, también te muestra todo esto desde una perspectiva de versión para que sepas qué está sucediendo mientras estás lanzando tu código, y todos sabemos que estamos tratando de acelerar los ciclos de lanzamiento. Entonces, cuanto más pongamos ahí fuera, mejor será para el usuario, pero tenemos que poder monitorearlo, especialmente cuando se trata de la web. A continuación, voy a mostrar que podemos consultar y filtrar cualquiera de estos data para realmente averiguar lo que queremos, y podemos establecer alertas al respecto, hacer todas esas cosas buenas, y fijarlo como un panel de control. Así que, voy a presentar dos casos de uso aquí. Primero, vamos a ir a Descubrir. Entonces, lo que quiero es entender qué tipo de clientes están teniendo errores, y luego quiero obtener una descomposición del navegador, y averiguar cuáles son esos errores más populares. Y esto es solo para mostrar el poder de lo que podemos hacer con estos data y cómo podemos consultar esto. Así que aquí estoy en Descubrir, que básicamente es nuestro generador de consultas y visualizador aquí. Voy a seguir adelante, y comencemos. Y ahora mismo estoy consultando todos mis proyectos, todos mis entornos. Y lo que voy a hacer es que solo me importan los errores en este momento. Así que hagamos algo así. Y también quiero asegurarme de que sean aquellos que tengan esta etiqueta, y es una etiqueta personalizada que he establecido. También, si estás interesado en establecer una etiqueta personalizada, Más o menos, es sentry.setTag, así que si vamos aquí, y luego Etiquetas Personalizadas, lo estoy haciendo en mi código. Es solo sentry.setTag, tipo de cliente. Y luego, volvamos aquí, Como Tipo de Cliente, ahí vamos. Y ahora, sigamos adelante y definamos las columnas. Por ejemplo, tipo de cliente. Y obtengamos simplemente un recuento total de ellos. Y por diversión, ¿por qué no hacemos también un recuento de usuarios únicos? Ahí vamos. Parece que, ya sabes, están bastante repartidos. Eso es genial. Y también podemos confirmarlo haciendo algo como esto. Lo que realmente me interesa es tomar solo los usuarios de enterprise.

Estos son los que nos pagan, digamos, la mayor cantidad de dinero. debug lo que está sucediendo aquí. Veamos cómo están teniendo una experiencia en todos los diferentes navegadores aquí.

Así que puedo ir a cambios. Bam. Parece que eso es así. La mayoría de ellos están utilizando Chrome, parece, y también experimentando errores en eso. Estoy interesado en ese conjunto de datos, así que vamos a agregar eso al filtro. Haciendo clic aquí también lo agregará al filtro. Así que aquí puedes ver que ahora estoy. Y ahora lo que quiero hacer es realmente ver el título de los errores y también los problemas. Y podemos ver exactamente qué está sucediendo y luego vincularnos al conjunto de datos también.

Y ahora, digamos que quiero establecer una alerta para todo esto. Viste algunas de las alertas de problemas que se activaron antes, pero tenemos el poder de incluso establecer alertas métricas aquí, así que puedo ir aquí y creo que tendría que establecer un proyecto. Ahí vamos. Y luego crear una alerta. Vamos a hacer eso. Y puedo establecer cualquier umbral. Y digamos que quiero que sea slack pager duty, etc. Todo se puede hacer aquí. Muy, muy fácil. Archivémoslo. Además, si quisiera agregar esto a cualquier panel de control, también podría hacerlo. Hablaré de los paneles de control un poco más tarde, pero hasta ahora he consultado el conjunto de datos de errores. Hagamos otro caso de uso aquí y consultemos nuestros datos de transacciones para que podamos averiguar las tasas de fallos de las transacciones. Y la tasa de fallos generalmente está dictada por si hay un error y la respuesta que da.

Así que vamos a filtrar esto primero. Digamos, tipo de evento.transacción. Sigamos adelante y miremos, y puedes ver lo fácil que es construir todas estas consultas. No tengo que saber sobre lenguaje de consulta ni nada parecido. Sigamos adelante y hagamos transacción y hagamos la tasa de fallos aquí, y empecemos desde ahí. Y aquí, en realidad, voy a empezar con mi aplicación backend. Ahí vamos. Y puedo ver que la transacción de pago está fallando con bastante frecuencia. Eso es interesante. Averigüemos, ¿está ocurriendo en todas las diferentes versiones? Así que vamos a agregar eso al filtro. Vamos a cambiar esto a versión. Y vamos a seguir adelante. Ahora podemos ver todos estos datos en cuanto a cómo se ha comportado en todas las diferentes versiones. Y podemos agregar eso a un panel de control o, una vez más, crear cualquier alerta diferente. Pero ahora sabemos exactamente qué está sucediendo. Parece que está ocurriendo en estas tres versiones en los últimos 14 días y ha estado alrededor del 75%, lo cual no es bueno. Probablemente deberíamos adelantarnos a esto y averiguar qué se introdujo en un punto. No voy a agregar esto a un panel de control, pero voy a mostrar rápidamente algunos paneles de control. Eso realmente debería mostrar el verdadero poder de todos estos datos.

De manera similar, si quisiéramos hacer uno de back-end, estarías interesado en parte de esa información, pero también en el rendimiento, appdex, todo ese tipo de cosas, y la tasa de fallos. Y eso es lo que vemos aquí. Una vez más, puedes anclar desde Descubrir a Paneles de control y crear todo esto, y consultar cualquier otro conjunto de datos para obtener las vistas adecuadas. Y lo último que quería mostrar aquí es el ecosystem.

Pero antes de hacer eso, parece que hay algunas preguntas. Si ocurre un error cuando la aplicación se está ejecutando, ¿habrá una alerta en tiempo real? Sí, exactamente. Entonces, lo que va a suceder, digamos que la aplicación se está ejecutando, ocurre un error. Sentry capturará eso, nos adjuntaremos al controlador de errores global, enviaremos ese error de forma asíncrona para no bloquear nada dentro de la aplicación. Lo agregaremos a un conjunto, lo mapearemos, lo procesaremos, lo agregaremos, y luego nuestras alertas se activarán en consecuencia. Por lo tanto, serás notificado en cuestión de segundos. Y creo que mostré algo de eso antes cuando causé un error. Viste que abrí Slack y en cuestión de segundos me habían notificado que esto estaba sucediendo, y luego también abrí el problema relevante de Sentry. Muy bien, hemos pasado por los errores. Hemos pasado por las transacciones o el performance. Mostramos cómo podemos monitorear una versión y ver cómo se adoptó. Construimos algunas consultas, mostramos un poco de panel de control, incluso mostramos un poco de alertas métricas como parte de eso, y todo eso se originó desde Descubrir. Por último, quiero mostrar cómo todo esto puede unirse en tu flujo de trabajo. Así que digamos que soy un desarrollador, ¿de acuerdo? Estoy usando GitHub para almacenar mi código como un sistema de repositorio. Estoy usando Slack para notificaciones y chat. Y digamos que también estoy usando PagerDuty para incidentes, y estoy usando JIRA para el seguimiento de problemas. Así que vamos a tomar esto. Digamos que, ya sabes, se disparó una alerta como vimos antes, y esa alerta nos señaló este problema aquí. Veamos cómo se unen todas estas cosas. Entonces, primero, Slack nos alertó. Eso nos lleva al problema, o podríamos haber hecho que PagerDuty hiciera lo mismo. Y hay muchas cosas que puedes hacer desde una alerta de Slack, podemos resolver, ignorar, asignar, todo ese tipo de cosas. Pero en resumen, quieres llegar al contexto de quién, qué, cuándo, dónde, por qué. Echemos un vistazo a esto. Parece que esto es por qué sucedió. Creo que alguien habló sobre los valores de las variables de la traza de pila. Así que aquí está en Python. Puedes ver los valores de las variables en ese momento o cada uno de los marcos y ver exactamente qué estaba sucediendo aquí. Y parece que, y esta es mi característica favorita de Sentry, nos integramos con el sistema de gestión de código fuente y podemos identificar qué confirmación causó este error. Así que aquí parece que Will cometió este código o lo fusionó en este código, lo cual causó este error. Por lo tanto, Will debería ser asignado a este problema porque es el mejor bombero para este trabajo y él escribió este código. Él sabe lo que va a suceder a partir de este contexto detallado aquí y puede solucionarlo en cinco minutos en lugar de que yo intente entender qué está sucediendo y me lleve un par de horas. Además, también tenemos la vinculación de trazas de pila. No lo tengo configurado en este ejemplo, pero podrías hacer clic aquí y te llevaría a la línea correspondiente en GitHub también o a esa revisión en GitHub también. Y digamos que ahora que sabemos que Will causó esto, creemos un problema en JIRA para esto. Asignémoslo a Will. Y en realidad se le habría asignado automáticamente a Will porque tenemos una vinculación bidireccional con JIRA. Aquí está el ticket de JIRA en el lado derecho. Si cambiamos el asignado o si cambiamos el estado, también se hará en el producto.

Ah, si tenemos una base de datos conectada, ¿informará sobre la lentitud allí? Sí. Tal vez podría haber dedicado un poco más de tiempo a resaltar esto, pero vamos a ir aquí y vamos a ir a Express. Bueno, estamos aquí y creo que tenía un par de llamadas aquí. Vamos a ir a checkout y post. Entonces, si entramos aquí en productos y vamos a ver algunas de estas transacciones, puedes ver que hay una integración de base de datos aquí que muestra las declaraciones select y exactamente qué está sucediendo aquí. Entonces, aquí en mi código, es posible que hayas visto que tenía seleccionada la integración de la base de datos. Oh, no aquí, pero vamos a ver la documentation. Entonces, si entramos aquí, entramos en node, entramos en Express, tenemos una integración de database para todos estos. Y creo que esta es la que estás buscando. Muy bien. Veamos, ¿alguna otra pregunta? Creo que esas. Muy bien. Solo quiero agradecer a todos por quedarse durante los últimos 55 minutos y hacer preguntas. Y realmente aprecio a cada uno de ustedes por tomarse el tiempo. Oh, lo último es que si te registras en Sentry, tenemos un pequeño código promocional aquí para ti. Y también, si te registras o instalas este SDK de Node durante la conferencia. Recibirás un par de calcetines gratis. Muy bien, gracias a todos.