Cuando se solucionan problemas en aplicaciones complejas de Node.js, siempre es útil recopilar información sobre la red, el sistema de archivos o las dependencias externas. Incluso al trabajar con una nueva base de código, es importante tener información sobre cómo se construye la aplicación, qué llamadas asíncronas se están utilizando y con qué frecuencia. En esta charla, quiero presentar "instrument", una herramienta que he creado para esto y que también es de código abierto.
Video Summary and Transcription
La charla trata sobre la solución de problemas en aplicaciones de Node.js y el uso de una herramienta para mejorar la visibilidad y obtener información. La herramienta puede recopilar información sobre las URL y las importaciones de módulos en un servidor. Sin embargo, no se recomienda su uso en entornos no locales debido a la sobrecarga de rendimiento y posibles errores.
Available in English
1. Troubleshooting Node.js Applications
Short description:
Mi charla trata sobre la solución de problemas de aplicaciones Node.js. Intentaré descomponer las partes de la aplicación para identificar el problema. Desarrollé una herramienta que proporciona una mayor visibilidad e información útil. Se puede utilizar para recopilar información sobre las URL utilizadas por una aplicación Node.js e identificar las importaciones de módulos en un servidor. Sin embargo, no se recomienda utilizar esta herramienta en entornos no locales debido a la sobrecarga de rendimiento y posibles errores.
¡Hola a todos! Antes de continuar, primero quiero agradecer a todos los organizadores y voluntarios que hicieron esto posible, dedicaron su tiempo y también me dieron la oportunidad de presentarles hoy. Mi charla trata sobre la solución de problemas de aplicaciones Node.js.
Antes de eso, una pequeña introducción sobre mí. Soy Alejandro. Soy de Buenos Aires, Argentina. Trabajo como ingeniero de backend en X-Team y también contribuyo con un par de comunidades, Entonces, en el tema de esta charla, supongamos que tienes una aplicación Node.js que se está ejecutando, pero algo no funciona. No hay ninguna excepción. No tienes registros. ¿Por dónde empezarías? Lo que intentaría hacer es descomponer las partes de la aplicación para identificar más fácilmente dónde está exactamente el problema. Supongamos que es un servidor, verificaría la parte de inicio del proceso. Un punto de interrupción justo después de que se inicialice para ver si el error ocurre antes o después de eso.
Muchas veces estaría en el proceso de solución de problemas de una aplicación y pensaría que no tengo idea de por qué está sucediendo eso. Sería como este perro. Así que muchas veces, esto también sucedería en mi entorno de desarrollo, donde tengo control total, acceso total y también debería tener una buena observabilidad sobre lo que está sucediendo. Esta última parte fue una de las motivaciones que tuve para trabajar en una herramienta que prácticamente sin cambios en su aplicación podría permitir una mayor visibilidad y potencialmente convertirte en Ironman, como en esta escena. Ver mucha información útil de una vez. Repasaré algunos ejemplos específicos que se me ocurrieron en una demostración corta. En el escenario número uno, imagina que tienes un script o una aplicación que se está ejecutando a través de Node. Queremos poder saber si está utilizando la red y, en ese caso, recopilar más información sobre qué URL está utilizando y posiblemente más información al respecto. Así que vamos a mi demostración y para esto digamos que queremos intentar hacer eso con NPM. Y vamos a intentar obtener la última versión de un paquete, en este caso Mocha. Obtenemos el resultado 802.1. Digamos que queríamos hacer eso con esta herramienta con NPM podemos requerir instrumento pasar los mismos argumentos que estábamos pasando antes y en primer lugar veremos la misma salida que antes 802.1 y y después un resumen breve de la herramienta. En este caso, para estos dos módulos nativos que están habilitados HTTP y HTTPS. Específicamente, estos dos están configurados aquí en la lista de módulos. y también puedes agregar otros como FS, Require y otros también. Esta configuración se agrega en la parte instrument.config.js. Así que podemos ver que esto se dirige a registry.npmjs.org. Vemos que el método es get en los encabezados user agent npm en CI y demás. Así que todo lo que tuve que hacer para requerir esa herramienta es agregarla como una dependencia de desarrollo.
Para otro ejemplo, supongamos que estás refactorizando un servidor HTTP y quieres identificar qué archivos están importando el módulo A.js. El módulo solo se carga dinámicamente mediante una sonda específica en tu servidor. Y en este caso, sería prácticamente imposible hacer esta tarea con análisis estático. Tendrías que instrumentar tu aplicación o tu servidor para obtener esa información. Entonces, al agregar el módulo requerido en la lista que vimos anteriormente, también podrías obtener esa información utilizando esta herramienta.
Un pequeño detalle sobre esto y una recomendación si debes ejecutar esto en otros entornos que no sean tus entornos locales y la respuesta es no, definitivamente no. Hay una sobrecarga de rendimiento al agregar esta instrumentación y estoy seguro de que encontrarás algunos errores si lo pruebas por tu cuenta, por lo que no se recomienda hacerlo. Puedes encontrar esta herramienta en GitHub y ver el código, ver un problema abierto, una solicitud de extracción, y si tienes más preguntas sobre cómo se hace esto u otras preguntas técnicas, realizaremos una sesión de preguntas y respuestas o no dudes en enviarlas a través de las redes sociales, twitter. Eso es todo lo que tenía para ustedes hoy. Muchas gracias.
