Aprende sobre herramientas para rastrear datos desde el frontend hasta el backend y aumentar la visibilidad de errores y rendimiento. Repasaremos cómo saber qué equipos son responsables de cada error, cuál es su impacto y todo el contexto necesario para resolverlo.
Monitoreo de Errores y Ralentizaciones en Aplicaciones JS
Video Summary and Transcription
Sentry es una plataforma de monitoreo de errores que ayuda a los desarrolladores a optimizar la experiencia del cliente al alertarlos sobre errores y ralentizaciones. Admite todos los lenguajes y frameworks principales, con un enfoque en el monitoreo de errores, el monitoreo de rendimiento y la salud de las versiones. La charla explora cómo Sentry organiza y representa los datos de errores, analiza los detalles y etiquetas de errores, e investiga problemas en el backend, problemas de rendimiento y la salud de las versiones. Se enfatiza la colaboración con los equipos de backend para resolver problemas y optimizar el tiempo de transacción. La charla también destaca la importancia de analizar gráficos, problemas y regresiones para identificar áreas de mejora en la salud de las versiones.
1. Introduction to Sentry and Error Monitoring
Hola, soy Simon, un ingeniero de soluciones en Sentry. Monitoreamos errores y ralentizaciones en aplicaciones JS, conectando a los desarrolladores con la experiencia del usuario final. Con el SDK de Sentry, alertamos a los miembros del equipo y desarrolladores sobre errores y ralentizaciones, optimizando la experiencia del desarrollador y del cliente. La plataforma de Sentry se enfoca en el monitoreo de errores, el monitoreo de rendimiento y la salud de las versiones. Soportamos todos los lenguajes y frameworks principales, con Node.js como punto de partida. Generaremos datos de transacciones y errores para demostrar cómo Sentry los organiza y representa. Veamos cómo se representan los errores en Sentry, incluyendo la frecuencia, los datos contextuales y la información de etiquetas.
Hola, mi nombre es Simon. Soy un ingeniero de soluciones en Sentry, y hablaremos sobre el monitoreo de errores y ralentizaciones en aplicaciones JS. Sentry está diseñado específicamente para desarrolladores. Te diremos cuando tu código es lento, cuando está roto y te daremos pistas sobre por qué. Estamos conectando la experiencia del usuario final lo más cerca posible de los desarrolladores que hacen que esas experiencias sucedan. Con el SDK de Sentry en tus aplicaciones, alertaremos a los miembros del equipo y desarrolladores necesarios cuando ocurran esos errores y ralentizaciones. Permíteles hacer esos commits y los cambios para optimizar esa experiencia del desarrollador y del cliente. La plataforma de Sentry se divide en estos cinco pilares aquí. Nos enfocaremos en los primeros tres a la izquierda, es decir, el monitoreo de errores, el monitoreo de rendimiento y la salud de las versiones de Sentry.
Ahora, para comenzar, estaremos en la página de documentación de Sentry. Soportamos todos los lenguajes principales y frameworks. Pero probablemente el lugar donde tenemos Node.js en la página principal para comenzar con eso, la instalación de los paquetes necesarios con un comando Yarn o NPM y configurar con Sentry init, incluyendo ese DSN. Ese es un nombre de origen de datos. Le dirá a tu aplicación a dónde enviar eventos de errores y transacciones, y ese es tu proyecto en Sentry. Ahora, tengo una aplicación aquí para que la veamos juntos. Generaremos algunas transacciones y algunos datos de errores, y veremos cómo se representan en Sentry, cómo se organizan por versiones también. Ahora, para comenzar, haremos clic en explorar productos para ver las cosas disponibles para comprar. Y está tomando unos segundos aquí. Veremos esa ralentización en breve, pero voy a terminar con este flujo de usuario, agregando un par de elementos a nuestro carrito, y procediendo a comprarlos, ¿verdad? Nos encontramos con un error, sorpresa, sorpresa, pero veamos cómo se representa en Sentry. Ahora, tengo una alerta de Slack configurada. Así que en unos segundos, recibiremos una notificación sobre el error que acabamos de desencadenar en ese proceso de compra. Haz clic en esta notificación con, ya sabes, algo de contexto detrás de escena también de lo que acaba de suceder, pero veamos más a fondo. Desde ese enlace, se me lleva a quién, qué, cuándo y dónde ocurrió el error que acabamos de experimentar juntos, ¿de acuerdo? Este error, este error 500, ha ocurrido 160 veces para 60 usuarios. Algunos detalles sobre su frecuencia en el último día, 30 días, primera y última vez visto en las versiones. Eso es realmente útil. Y también alguna información de etiquetas agregadas aquí a la derecha. Hemos tomado las 160 veces que ha ocurrido este error, obtenido algunos datos contextuales y los hemos organizado en un mapa de calor. Como puedes ver aquí, el tipo de cliente es plan pequeño, grande, mediano, empresa. Está afectando a todos nuestros usuarios. Así que queremos investigar más a fondo eso.
2. Error Details and Analysis
Enfoquémonos en los detalles de una de las 160 veces que ocurrió este error. Analizaremos las etiquetas, la traza de la pila y la línea de tiempo de las actividades que llevaron al error.
Ahora, centrémonos en el panel central aquí. Estos son los detalles de una de las 160 veces que ocurrió este error. Podemos pasar a otras ocasiones. En cualquier caso, echemos un vistazo a estas etiquetas. Estos son los pares clave-valor para esta ocasión específica: MacOS Chrome, fue un cliente grande, entre otros detalles. Pero lo que más nos importa en este momento es probablemente la traza de la pila. Sin Sentry, estaríamos lidiando más con una traza de pila minificada, no legible por humanos. Pero como hemos subido nuestros mapas de origen durante la compilación, vemos esta traza de pila muy hermosa y legible por humanos, y podemos ver la línea de código exacta donde ocurrió. Parece que la respuesta del backend no fue correcta, así que podemos profundizar un poco más en eso. También tenemos una línea de tiempo de las actividades que llevaron al error.
3. Backend, Performance, and Release Health
Ahora vamos a adentrarnos en el backend y ver la traza de la pila y los detalles del error. Podemos trabajar con nuestro equipo de backend para resolver el problema de inventario. Pasando al rendimiento, analizamos las métricas web y los detalles de la transacción. Identificamos un problema con la métrica web de mayor contenido visible y lo investigamos más a fondo. Al examinar el desglose de la transacción, encontramos una operación lenta del cliente HTTP debido a consultas secuenciales a la base de datos. Podemos colaborar con el equipo de backend para optimizar y mejorar el tiempo de transacción. Por último, exploramos la salud de las versiones, incluyendo las tasas de fallos y detalles específicos. Podemos analizar gráficos, problemas y regresiones para identificar áreas de mejora.
Comments