1. Introducción a las Diagnósticos de Node.js
Esta charla trata sobre cómo obtener información de diagnóstico de Node.js sin utilizar muchas herramientas de terceros. A lo largo de los años, se ha trabajado mucho en los diagnósticos específicamente y en cómo podemos mejorarlos en Node. Para la mayoría de los casos de uso, se puede hacer mucho de depuración y obtener información de Node, solo utilizando el ejecutable de Node y Chrome.
Hola a todos. Gracias por venir a mi charla titulada Diagnósticos de
Node.js sin usar muchas herramientas de terceros. Esta charla trata sobre cómo obtener información de diagnóstico de
Node.js sin utilizar muchas herramientas de terceros. Así que, solo un poco de contexto, obtener diagnósticos de
Node.js solía ser bastante difícil.
Node.js solía seguir una filosofía de núcleo pequeño, lo que significaba que mucha funcionalidad quedaba a cargo de los módulos de
NPM. Así que teníamos cosas como el inspector de
Node.js para depurar, el volcado de montón de
Node.js para capturar instantáneas de montón, Long John para trazas de pila asíncronas, y cosas así. Pero, a lo largo de los años, se ha trabajado mucho en los diagnósticos específicamente y en cómo podemos mejorarlos en Node. Pero muchas personas pueden no saber que estas cosas existen todavía. Y para la mayoría de los casos de uso, se puede hacer mucho de depuración y obtener información de Node, solo utilizando el ejecutable de Node y Chrome. Así que gran parte del contenido de esta charla es en realidad de la documentación oficial de la
CLI, si quieres buscarla por tu cuenta. Y esta charla también asume la última versión de Node 16.
2. Depuración con Variables de Entorno
Una de las formas más antiguas de obtener información de diagnóstico de Node era a través de variables de entorno de depuración. Hay dos variantes: Node debug para JavaScript y Node debug native para C++. Al iniciar el ejecutable, se especifica la variable de entorno con los subsistemas a los que escuchar. La aplicación volcará información en la salida estándar, incluyendo eventos de conexión.
Entonces, una de las formas más antiguas de obtener información de diagnóstico de Node era a través de variables de entorno de debug. Así que, si alguien ha utilizado el módulo debug en NPM, es muy similar a eso. Puedes usarlo para registrar mucha información adicional del núcleo de Node durante la ejecución. Y en realidad hay dos variantes de esto. Hay Node debug para obtener información de la parte de JavaScript y Node debug native para obtener información de la capa de C++. Y cuando inicias tu ejecutable, simplemente especificas esta variable de entorno con una lista separada por comas de los subsistemas a los que deseas escuchar, como se muestra en el ejemplo al final de esta diapositiva. Y cada vez que ejecutes tu ejecutable o tu aplicación, volcará mucha información en la salida estándar. Puedes ver un ejemplo aquí. Los subsistemas están precedidos por su nombre. Así que, en este ejemplo, net y HTTP 2. Y luego el ID de proceso y, ya sabes, varias informaciones de depuración. Así que, cada vez que se establece una conexión, se cierra una conexión, y cosas así.
3. Warnings and Deprecations in Node.js
Las advertencias en Node.js se utilizan para notificar a los usuarios sobre acciones potencialmente riesgosas. Hay varias banderas disponibles, como --no-warnings para desactivar todas las advertencias, --redirect-warnings para guardar las advertencias en un archivo y --trace-warnings para imprimir una traza de pila. Por ejemplo, al requerir el módulo sys, se muestra una advertencia de deprecación y al usar --trace-warnings se revela la ubicación de origen. Las deprecaciones en Node se identifican mediante un ID, que se puede consultar en la documentación para obtener más detalles.
de ese tipo. Entonces, lo siguiente de lo que quería hablar son las advertencias en
Node.js. Las advertencias se utilizan para informar al usuario sobre acciones que podrían ser potencialmente riesgosas y que desaconsejamos. Hay varias banderas que puedes usar aquí. La bandera --no-warnings desactivará todas las advertencias. Es posible que no quieras hacer eso. La bandera --redirect-warnings se puede usar para tomar todas las advertencias y guardarlas en un archivo para poder verlas más tarde. Y luego la bandera --trace-warnings imprimirá una traza de pila cuando se encuentre una advertencia. Esto puede ser realmente útil cuando se omite una advertencia, pero no estás seguro de por qué, podría estar viniendo desde lo más profundo de la carpeta de módulos de tu nodo. La traza de pila realmente te dará más información sobre lo que está sucediendo. Y aquí se muestra un ejemplo. Entonces, si requirieras el módulo sys, sys es un módulo antiguo del núcleo de Node que ha sido deprecado desde hace mucho tiempo, pero aún está ahí. No queremos que la gente lo use, así que cada vez que lo requieras, verás que se imprime esta advertencia de deprecación, y luego puedes usar la bandera --trace deprecation, como mencioné antes, para, lo siento, la bandera trace warnings para ver de dónde viene en tu código. Entonces, si miras la flecha que tengo en la traza de pila aquí, en realidad verás que viene de example.js en la línea uno, por lo que es muy fácil entender qué está sucediendo. Entonces, una cosa a tener en cuenta aquí es que verás en el mensaje dep 0025, todas las deprecaciones en node se les asigna un ID, por lo que puedes ir a la documentación del núcleo de node, tenemos una página específica para deprecaciones, puedes buscar ese ID de deprecación y obtener más información
4. Deprecaciones en Node.js
Las deprecaciones en Node.js son similares a las advertencias y tienen banderas para controlar su comportamiento. La bandera de deprecación de Node oculta las advertencias de deprecación, mientras que la bandera de traza de deprecación imprime una traza de pila. La bandera de lanzamiento de deprecación lanza una excepción cuando se utiliza una función obsoleta. Esto puede ser útil para identificar y abordar el código obsoleto durante las pruebas o CI.
información que la disponible en la traza de pila aquí. Entonces, lo siguiente de lo que quiero hablar son las deprecaciones, que son similares a las advertencias. Es una clase específica de advertencia. Nuevamente, tenemos banderas similares para lidiar con ellas, por lo que tenemos la bandera de deprecación de Node, si no quieres ver ninguna advertencia de deprecación en tu código, entonces si sabes lo que estás haciendo, es posible que quieras usar eso. También tenemos dash dash trace deprecation, que imprime una traza de pila, similar a la bandera de advertencias que mostré hace un momento. Y luego también tenemos throw deprecation, que en realidad lanzará una excepción cada vez que uses una función obsoleta. Ahora, esto no es algo que probablemente quieras ejecutar en producción, pero en tu código de
CI o cuando estás haciendo
testing, es muy útil para encontrar cosas que necesitas abordar y eliminar de tu código. Así que aquí tenemos un ejemplo similar. Nuevamente, esto es require sys porque una advertencia de deprecación es solo otra advertencia. Entonces aquí he usado la bandera dash dash throw deprecation para el mismo código que antes. Y en este caso, en realidad verás una excepción lanzada, lo cual es bueno porque resalta la traza de pila. Entonces notarás que muchas de las tramas de pila aquí están en gris. Esas son cosas que provienen del núcleo de Node, por ejemplo. Y la línea que todavía está en negro con la flecha apuntando a ella es la línea en tu
5. Bloqueo de E/S síncrona y Event Loop
La E/S síncrona bloquea el Event Loop, lo cual puede afectar negativamente el rendimiento, especialmente en aplicaciones de servidor con múltiples solicitudes. La bandera de traza de E/S síncrona de Node se puede utilizar para informar sobre la E/S síncrona después del primer ciclo del Event Loop. Un ejemplo es la lectura sincrónica de un archivo, lo cual resulta en advertencias individuales para cada operación. La traza de pila muestra las operaciones de E/S síncrona llamadas después del primer ciclo del Event Loop.
código donde proviene la deprecación. Entonces, lo siguiente de lo que quería hablar es la E/S síncrona y cómo puedes encontrarla en tu código. La E/S síncrona bloquea el Event Loop. Esto solía ser un verdadero asesino del rendimiento. Aún lo es hasta cierto punto, pero ahora tenemos hilos de trabajo que pueden mitigar un poco las cosas. De todos modos, probablemente no quieras bloquear tu Event Loop si no es necesario. Especialmente si estás ejecutando una aplicación como un servidor donde se manejan múltiples solicitudes al mismo tiempo. Si bloqueas el Event Loop en una de las solicitudes, todas las demás solicitudes también se verán afectadas. Entonces, cuando estés configurando tu servidor, está bien si estás realizando E/S síncrona durante la fase de inicio, pero una vez que comiences a servir tráfico, probablemente no quieras permitir eso. Y así puedes usar la bandera de traza de E/S síncrona de Node para informar cualquier E/S síncrona que ocurra después del primer ciclo del Event Loop. Un ejemplo, que tengo aquí, es que estamos usando un setImmediate, para saber que ahora estamos avanzando más allá del primer ciclo del Event Loop, y luego estamos leyendo sincrónicamente un archivo del sistema de archivos. Y así, readFileSync realiza un par de operaciones internamente. Abre el archivo, también lo examina, lee los datos de él y lo cierra. Y debido a que todas estas operaciones ocurren de manera síncrona, todas resultarán en advertencias individuales. Y así, puedes ver en la traza de pila que se proporciona aquí, openSync, tryStatSync, readSync y closeSync se están llamando como E/S síncrona después del primer ciclo del Event Loop. Y, por supuesto, si eliminara el setImmediate aquí, esto no informaría ninguna advertencia porque aún estaríamos en el primer ciclo del Event Loop.
6. Tracing Uncaught Exceptions and Process Exit
A continuación, discutamos el rastreo de excepciones no capturadas y la salida del proceso en Node.js. La bandera de rastreo de excepciones no capturadas ayuda a localizar las excepciones en el código de tu aplicación, proporcionando la ruta donde se lanzaron. De manera similar, la bandera de rastreo de salida muestra dónde se originó la llamada de salida del proceso. Además, hablaremos sobre las promesas no manejadas y cómo Node.js 15 cambió su comportamiento para lanzar excepciones. Puedes configurar este comportamiento utilizando la bandera de rechazos no manejados con diferentes modos: throw, strict, warning, warn con código de error y none.
A continuación, quería hablar sobre el rastreo de excepciones no capturadas. Entonces, nuevamente, es posible que se lance una excepción en el código de tu aplicación. Puede provenir de tu directorio de módulos de Node o, si tienes una aplicación grande, puede ser difícil encontrarla. Y la pila de errores en sí misma puede no corresponder realmente a donde se lanzó la excepción en tu aplicación. Por lo tanto, puedes usar la bandera de rastreo de excepciones no capturadas cada vez que ejecutes tu aplicación. Y además de imprimir el error en su traza de pila, como ves arriba en la flecha roja, también imprimirá esta información de lanzamiento y te dará la ruta hacia tu aplicación donde se lanzó la excepción. Tenemos una bandera similar para el rastreo de salida del proceso. Si un módulo de Node llama a la salida del proceso, no tienes idea de lo que está sucediendo en tu aplicación, puedes usar el rastreo de salida y te mostrará desde qué parte del código se realizó la llamada de salida y también cuál fue el código de salida. Entonces, notarás aquí que salió del entorno con el código cero. Ahora quiero pasar a hablar sobre los rechazos de promesas no manejados. De forma predeterminada, en
JavaScript, los rechazos no manejados se ignoran. Esto está bien en el navegador, pero puede causar muchos problemas graves si estás ejecutando un servidor. Esto se informó a Node de manera continua y
Node.js decidió que a partir de la versión 15 cambiaríamos el comportamiento de los rechazos de promesas no manejados para lanzar una excepción. Esto es útil porque, por ejemplo, digamos que estás sirviendo múltiples solicitudes al mismo tiempo en tu servidor y estás abriendo descriptores de archivos y ocurren rechazos de promesas y nada, el rechazo simplemente se ignora. Es posible llegar a un estado donde realmente estás filtrando descriptores de archivos y otros
7. Handling Promise Rejections in Node.js
El nuevo comportamiento en Node.js lo hace más explícito y permite un mejor manejo de los rechazos de promesas. Puedes configurar este comportamiento desde la CLI utilizando la bandera de rechazos no manejados. Hay cinco modos disponibles: throw, strict, warning, warn con código de error y none. Se muestra un ejemplo con los rechazos no manejados configurados en strict, donde un rechazo de promesa se convierte en una excepción no capturada.
recursos y esto puede causar problemas de memoria y dejar tu servidor en un estado malo. Entonces el nuevo comportamiento hace que sea mucho más explícito lo que está sucediendo y te permite manejar mejor tus rechazos de promesas. Puedes configurar este comportamiento desde la
CLI. Si usas la bandera de rechazos no manejados, puedes cambiar los diferentes comportamientos. Actualmente, admitimos cinco modos diferentes de rechazos no manejados. Throw y strict convierten un rechazo en una excepción no capturada. Throw es el valor predeterminado a partir de Node 15. Throw intenta emitir un evento no manejado antes de lanzar la excepción, mientras que strict pasa directamente a lanzarla. Entonces, uno te brinda una mejor oportunidad de manejar el rechazo primero. Luego está el modo de advertencia, que mostrará una advertencia en la consola. Warn con código de error es lo mismo que warn, pero también establece el código de salida del proceso en uno. Y luego none, que es el valor predeterminado de
JavaScript de ignorar los rechazos no manejados. Aquí tienes un ejemplo rápido con los rechazos no manejados configurados en strict. Si llamo a promise.reject y paso un objeto de error, se convertirá en una excepción no capturada y puedes manejarlo de esa manera, por lo que verás el mensaje de error y la traza de la pila solo
8. Introduction to the Tick Processor in v8
El procesador de ticks en v8 es un perfilador de muestreo basado en línea de comandos que proporciona información completa sobre dónde estás gastando tu tiempo en bibliotecas, código JavaScript y código C++. Al ejecutar tu aplicación con la bandera --prof, puedes generar un archivo de salida del perfilador de v8. Después de recopilar la información, puedes procesarla utilizando la bandera --prof-process en Node. La salida procesada muestra el tiempo invertido en bibliotecas compartidas, código JavaScript (con funciones optimizadas marcadas con un asterisco) y código C++.
Igual que si dijeras throw new error en este caso. A continuación, quería hablar sobre el procesador de ticks que está disponible en v8 y que creo que mucha gente desconoce. Es un perfilador de muestreo basado en línea de comandos y es bueno porque puede mostrarte en su salida dónde estás gastando tu tiempo en bibliotecas, así como en código
JavaScript y código C++. Es bastante completo y la forma en que funciona es ejecutar tu aplicación con la bandera --prof en la línea de comandos y esto volcará la salida del perfilador de v8 en un archivo. Puedes leer el archivo si quieres, pero no está pensado para consumo humano, así que lo que harás es después de recopilar esa información, ejecutar node nuevamente con la bandera --prof-process y pasar el nombre del archivo de registro que se generó. Así que puedes ver un ejemplo de eso en la parte inferior de la diapositiva aquí aquí y esto es un ejemplo de cómo se verá la salida procesada, por lo que verás en la parte superior donde estás gastando tu tiempo en bibliotecas compartidas y luego la siguiente sección muestra dónde estás gastando tu tiempo en código
JavaScript. Aquí notarás que tenemos dos funciones, process immediate y normalize string, y ambas tienen un asterisco delante. El asterisco significa que v8 pudo optimizar el código en esa función. Y luego la sección inferior es solo un desglose de dónde
9. Introducción a v8 Inspector
Node y v8 ahora tienen soporte de primera clase para v8 Inspector, que son las herramientas de desarrollo de Chrome utilizadas con aplicaciones de Node. Para configurarlo, inicia Node con la bandera --inspect y especifica el host y el puerto. Ten cuidado al enlazar a una dirección pública, ya que puede ser una vulnerabilidad de seguridad.
tu aplicación está gastando su tiempo en código C++. Así que hace unos años, Node y v8 comenzaron a tener soporte de primera clase para v8 Inspector, que es básicamente las herramientas de desarrollo de Chrome utilizadas con aplicaciones de Node. Así que si has hecho algún tipo de desarrollo de navegador o incluso desarrollo de Node en los últimos años, es probable que hayas visto las herramientas de desarrollo de Chrome. Incluye cosas como un depurador paso a paso, perfiles con interfaces gráficas en lugar de la basada en
CLI que mostré antes. Y la forma de configurarlo es iniciar Node con la bandera --inspect y luego puedes especificar el host y el puerto en los que deseas que escuche en tu máquina. De forma predeterminada, escuchará en 127.0.0.1 puerto 9229. También puedes configurarlo para que, tan pronto como inicies la aplicación, establezca un punto de interrupción para que no tengas que preocuparte por hacerlo manualmente, y eso se hace con la bandera --inspect-brk, que funciona de la misma manera que el punto de interrupción y un consejo de seguridad es tener cuidado si vas a enlazar a la dirección 0.0.0.0 o cualquier otra dirección pública en tu máquina. Esto solía ser lo predeterminado para Node y se informó como una vulnerabilidad de seguridad porque si tienes un servidor que se puede acceder públicamente y estás enlazado a una dirección expuesta públicamente como esa, entonces técnicamente es posible que un atacante se conecte al depurador y comience a manipular tu código y tiempo de ejecución. Así que eso es algo de lo que debes estar consciente.
10. Using the v8 Inspector and Dev Tools
Continuando con el ejemplo del inspector v8, ejecutar Node con la bandera --inspect se conecta al depurador a través de una URL de WebSocket. Las herramientas de desarrollo proporcionan una vista general de la actividad de la CPU, incluyendo las llamadas a funciones y el uso de memoria. Las capturas de montón son útiles para detectar fugas de memoria, permitiéndote comparar objetos entre capturas.
Así que a continuación quería hablar o lo siento, simplemente continuando con el ejemplo del inspector v8, sabes que el texto en la parte superior te muestra cómo ejecutarlo con node --inspect break ejemplo.js. Imprimirá alguna información que te dirá dónde está escuchando el depurador a través de esta URL de WebSocket y luego te remitirá a la documentación si tienes más preguntas o necesitas leer más. Pero puedes, sabes, la imagen en la parte inferior aquí simplemente te muestra cómo es cuando entras en las herramientas de desarrollo. De nuevo, muchas personas probablemente hayan visto esto antes, pero si no lo has hecho, esto es más o menos cómo es
11. CPU Profiler and Heap Snapshots in Chrome DevTools
Chrome DevTools proporciona un perfilador de CPU y capturas de montón para diagnósticos. El perfilador de CPU te permite recopilar perfiles utilizando indicadores de línea de comandos o manualmente a través de la interfaz de usuario de DevTools. La vista de un perfil de CPU en DevTools muestra una vista general de la actividad de la CPU a lo largo del tiempo y las funciones que se están llamando. Las capturas de montón son útiles para depurar fugas de memoria, comparando las capturas para identificar objetos que no se están limpiando. Las capturas de montón se pueden capturar mediante señales de CLI o automáticamente cerca del límite de montón. También se pueden recopilar manualmente a través de la interfaz de usuario de DevTools.
Lo que puedes esperar ver. Una de las herramientas útiles que está disponible en Chrome
DevTools es un perfilador de CPU. Te muestra qué funciones se están ejecutando a lo largo del tiempo. Quiero señalar que esto no es lo mismo que un gráfico de llamas. Un gráfico de llamas toma trazas de pila a lo largo del tiempo y las consolida en una traza de pila más grande para que puedas ver dónde está gastando generalmente tu aplicación su tiempo. Si estás buscando gráficos de llamas, hay una excelente herramienta en MPM llamada zero x con la que puedes experimentar. Pero en cuanto a la creación de perfiles de CPU, Node tiene en realidad un par de indicadores de línea de comandos que te permiten manipular el perfilador de CPU sin necesidad de hacerlo manualmente. Entonces, si pasas el indicador --cpu-prof, recopilará un perfil de CPU para ti. Iniciará el perfilador cuando la aplicación se inicie y luego escribirá el perfil cuando tu aplicación se cierre. El indicador --cpu-prof-dir te permite especificar dónde quieres que se escriban tus perfiles, si necesitas cambiar desde la ubicación predeterminada. De manera similar, el indicador --cpu-prof-name te permite darle a tu perfil un nombre de archivo diferente. Y luego el indicador --cpu-prof-interval te permite definir el intervalo de muestreo del perfilador. Entonces, si necesitas muestrear la pila con más frecuencia o menos frecuencia, puedes controlarlo allí. Y, por supuesto, también puedes ir a
DevTools en la interfaz de usuario y recopilar perfiles manualmente, si es necesario. Y esto es cómo se ve la vista de un perfil de CPU en
DevTools. Hay una especie de región en la parte superior que muestra una vista general a lo largo del tiempo de la actividad de la CPU. Y luego la ventana resaltada se muestra en la parte inferior, con las trazas de pila coloreadas. Puedes ver qué funciones se están llamando. Entonces, verás muchas, en este ejemplo, module.run main, así como require. Entonces, puedes, ya sabes, al ver esto, puedes entender que esta es la fase de inicio de tu aplicación, donde se requieren y configuran muchos módulos. Y luego el comportamiento cambia después de eso para ser más, ya sabes, más dependiente del tráfico que estás sirviendo.
Otra característica interesante de Chrome DevTools son las capturas de montón. Estas son muy útiles para ver qué está sucediendo en el montón de JavaScript y son realmente útiles si estás tratando de depurar una fuga de memoria. Entonces, puedes tomar una captura en un punto, dejar que el código de tu aplicación se ejecute durante un tiempo y luego tomar otra captura y compararlas. Y puedes, ya sabes, si te das cuenta, como, ya sabes, antes de tu en la primera captura en comparación con la segunda captura, hay un montón de nuevos objetos que no se están limpiando y que podrían, ya sabes, ayudarte a rastrear la fuga de memoria. Y así, también puedes manipular todas estas cosas desde la CLI. Entonces, el indicador --heap-snapshot-signal te permite capturar una captura de montón si envías una señal específica al proceso. Y luego también hay heap snapshot near heap limit, por lo que automáticamente intentará tomar una captura de montón cuando casi te quedes sin memoria. Esto no está garantizado que siempre funcione, porque toma memoria adicional recopilar la captura de montón, pero es definitivamente algo que vale la pena investigar. Y luego, de manera similar a los perfiles de CPU, puedes recopilarlos manualmente a través de la interfaz de usuario de DevTools si tienes un punto de interrupción establecido en tu código.
12. Diagnostics and Debugging Techniques
Muestra una lista de cada tipo de objeto desglosado por su constructor. Puedes rastrear fugas de memoria. El seguimiento de conexiones TLS proporciona información directamente desde Node.js. La depuración post-mortem crea un archivo principal de tu aplicación, pero tiene desventajas. Los informes de diagnóstico ofrecen una alternativa más sencilla a la depuración post-mortem.
Esto es solo un vistazo rápido a la vista de captura de montón. Muestra una lista de cada tipo de objeto desglosado por su constructor. Y luego mostrará cosas como el recuento de objetos. En este ejemplo específico, hay cuatro emisores de eventos en el código. El tamaño superficial te dice cuánta memoria está ocupando el objeto real. Y luego el tamaño retenido sigue los punteros de esos objetos para mostrarte el efecto en cascada de mantener este objeto en memoria. Y así puedes hacer muchas cosas útiles aquí mientras intentas rastrear fugas de memoria.
Lo siguiente de lo que quería hablar es el seguimiento de conexiones TLS. Solía ser que si querías diagnosticar problemas de TLS, tenías que tener configurado el cliente de OpenSSL y pasar algunas banderas de línea de comandos y cosas así. Pero ahora puedes obtener esa información directamente desde Node.js. Entonces, el indicador --trace-tls desde la CLI volcará toda la misma información para todas las conexiones TLS, solo para que lo sepas, esto será muy ruidoso, así que definitivamente no querrás habilitarlo en producción. También puedes establecerlo en el nivel individual del socket con TLS socket.enableTrace. Y luego también puedes establecerlo cuando estás configurando un socket o cuando estás configurando un servidor con la opción enableTrace pasada a createServer y TLS connect. Nuevamente, esto volcará una tonelada de información. Así que prepárate para filtrarla. Lo siguiente de lo que quería hablar es la depuración post-mortem. La forma en que funciona es que realmente usarás la bandera abort-on-unhandled, lo siento, caught exception para crear un archivo principal de tu aplicación. Y esto es muy útil porque obtienes el estado completo de tu aplicación. Pero hay muchas desventajas. Primero, debes configurar tu sistema para recopilar archivos principales, lo cual no suele ser el caso de forma predeterminada. Pero también necesitarás una herramienta externa como llnode para poder inspeccionar el archivo principal y ver qué está sucediendo allí. Y aunque llnode es extremadamente poderoso, está constantemente tratando de ponerse al día con los cambios en la representación del montón dentro de v8. Por lo tanto, puede ser muy acertado o fallido en cuanto a qué tan bien funciona de una versión de Node a la siguiente. Pero en realidad puedes inspeccionar objetos JavaScript. Puedes ver una traza de pila mixta de C++ y JavaScript. Pero definitivamente diría que esto es para casos de uso más avanzados y, como dije, tu suerte puede variar de una versión a otra. Entonces, en Node, queríamos tener una barrera más baja y algo más simple que la depuración post-mortem. Así que introdujimos algo llamado informes de diagnóstico. Este es un informe legible por humanos que contiene todo tipo de información sobre el proceso presentada como un gran bloque de JSON. Y puedes generar estos informes en diferentes condiciones, como un bloqueo, enviando una señal al proceso. Puedes hacerlo programáticamente a través de una API, etc.
13. Generación de Informes de Diagnóstico en Node.js
Esta sección cubre la generación de informes de diagnóstico en Node.js utilizando indicadores de la CLI. Estos informes contienen información sobre el sistema operativo, el proceso, el grupo de subprocesos, las pilas y más. Se debe tener cuidado con la información sensible. La API process.report.getreport se puede utilizar para crear informes, que incluyen versiones, desencadenantes de eventos, nombres de archivos, IDs de proceso y subproceso, y más. Es importante manejar estos informes con cuidado y redactar cualquier información sensible antes de compartirlos. La charla concluye agradeciendo la asistencia y reconociendo el valor de aprender sobre diagnósticos.
Esto incluye muchas cosas como información sobre el sistema operativo, el proceso, lo que está sucediendo en el grupo de subprocesos de LibV en cuanto a manejadores y demás. La pila de C++, la pila de JavaScript y mucho más. Una cosa a tener en cuenta es que esto puede contener información sensible como variables de entorno, así que manejarlas con cuidado.
Para generar un informe de diagnóstico, tenemos una colección de indicadores de la CLI que puedes utilizar. Por ejemplo, report-on-fatal-error es si hay un fallo de C++, puedes crear un informe de diagnóstico. Report-on-uncaught-exception es básicamente lo que dice. Si hay una excepción no capturada en JavaScript, se generará un informe para ti. Report-on-signal, si estás enviando una señal al proceso, puedes configurar qué señal quieres escuchar. Puedes hacerlo a través del indicador report-signal. Report-directory y report-file-name se utilizan para configurar dónde vas a almacenar el informe de diagnóstico y cómo quieres que se llame. Y luego está el indicador --report-compact que lo hará un solo línea de JSON, por lo que es más fácil de consumir para las máquinas. Así que echemos un vistazo rápido a cómo se ve una parte de uno de estos informes. He creado este a través de la API process.report.getreport. Puedes ver una parte de lo que está disponible aquí, como las versiones del informe, esto permite que Node versione los informes por razones de compatibilidad hacia atrás. El evento que lo desencadenó, en este caso fue una llamada a la API getreport en JavaScript, el nombre del archivo, en este caso es nulo porque se volcó en memoria. Cuando se recopiló, el ID del proceso, el ID del subproceso y muchas más cosas, así que definitivamente te animo a que juegues con esto y, como dije antes, estos informes pueden contener información sensible, así que manejarlos con cuidado. Si necesitas compartirlos con otras personas, es posible que debas redactar manualmente alguna información, pero es solo JSON, así que no debería ser demasiado difícil.
Eso es todo lo que tenía para hoy. Nuevamente, gracias por venir a mi charla y no dudes en contactarme en Twitter, GitHub o cualquier otro lugar. Gracias a todos. Espero que todos estén escribiendo muchas cosas en el papel dependiente. Así que hiciste la pregunta, ¿alguna vez has tenido un error en tu aplicación pero no pudiste obtener las métricas adecuadas para solucionar el problema? Y el 82% ha respondido que sí. Sí, así que espero que parte de la información que se obtuvo en la charla de hoy pueda ayudar con eso en el futuro. Creo que si, ya sabes, si la misma encuesta se hubiera realizado hace cinco o seis años, la respuesta probablemente habría sido mucho más cercana al 100%. Solía ser algo realmente difícil de hacer, y sí, el proyecto ha avanzado mucho desde los viejos tiempos de Node. Sí, sí. Quiero decir, incluso el 84% es mucho, pero sí, la mayoría de las personas no, quiero decir, conocen las nuevas cosas que vienen y todo eso. Así que veo muchos buenos comentarios en el canal, que fue mucho conocimiento, charla increíble y no sabía nada de lo que dijo. Así que, quiero decir,
Aprendiendo y Contribuyendo a los Diagnósticos de Node.js
Muchas cosas que no sabía. Wow. Sí. Increíble. Una pregunta de seguimiento sobre tu charla sería, ¿dónde puedo aprender sobre las cosas que mencionaste? Dos lugares: la documentación oficial de Node.js, específicamente la documentación de la CLI, y la sección de Guías del sitio web de Node.js. Para aquellos interesados en trabajar en los diagnósticos de Node.js, tienen la opción de contribuir al proyecto en GitHub o unirse al grupo de trabajo de diagnóstico. Las áreas de mejora en los diagnósticos de Node.js incluyen la depuración postmortem y la integración de gráficos de llama en Node.
muchas personas aprendieron mucho hoy. Fue una sesión genial. Muchas cosas que no sabía. Wow. Sí. Increíble. Entonces, bien. Una pregunta de seguimiento sobre tu charla sería, ¿dónde puedo aprender sobre las cosas que mencionaste en la charla? Sí. Realmente hay dos lugares. Primero, si vas a la documentación oficial de
Node.js, y luego en el lado izquierdo están todos los diferentes, ya sabes, subsistemas dentro de Node. Si te desplazas hacia abajo hasta la línea de comandos, creo que es la documentación de la Interfaz de Línea de Comandos (
CLI), esta charla proviene casi exclusivamente de esa página y toda la información allí. Y luego, si también vas al sitio web de
Node.js, hay una sección llamada Guías, y tenemos guías sobre diferentes cosas como, ya sabes, obtener información de diagnóstico, crear gráficos de llama, ejecutar tu aplicación en
Docker, y muchas otras cosas diferentes. Ok. Así que sí, échale un vistazo. Para cualquiera que esté escuchando aquí, ve a consultar toda la documentación y aprende más al respecto.
Entonces, después de esta charla, muchas personas han aprendido cosas nuevas y estarían interesadas en los diagnósticos. Entonces, digamos que alguien está interesado en trabajar en los diagnósticos de Node.js. ¿Hay alguna forma en la que puedan involucrarse? Absolutamente. Si estás interesado en trabajar en el proyecto, puedes ir a, ya sabes, github.com/Node.js/Node. Ahí es donde realmente vive el proyecto, ya sabes. Pero también tenemos un grupo de trabajo de diagnóstico, que es un equipo de personas que dedican tiempo específicamente a mejorar los diagnósticos en Node. Y creo que la URL para eso es github.com/Node.js/diagnostics. Y, ya sabes, puedes ir allí y si estás realmente interesado, unirte al grupo de trabajo y contribuir o simplemente seguir y ver de qué están hablando las personas. Increíble. Entonces, hay una pregunta de Azentyl1990. ¿Cuáles son algunas de las áreas en las que todavía ves que se podrían hacer mejoras en los diagnósticos con Node.js? Um, eso es interesante. Toqué un poco la depuración postmortem. Me encantaría ver que la depuración postmortem mejore. Desafortunadamente, eso requiere una cooperación considerable con V8. Y, ya sabes, no es que no cooperen, pero no sé si ven tanto valor en ello. Y también me gustaría ver que los gráficos de llama tengan un mayor protagonismo dentro de Node. Actualmente, eso es una de las pocas cosas de las que hablé brevemente en la charla donde aún tendrías que ir fuera de Node y usar las herramientas de desarrollo.
Node.js Diagnostics Q&A
El desarrollador Johta pregunta sobre aplicaciones o bibliotecas de Node.js para diagnósticos. Se recomiendan las herramientas de desarrollo y Clinic de NearForm. En entornos sin servidor, los diagnósticos pueden estar limitados a las ofertas del proveedor. El orador está emocionado por una pequeña mejora en la visibilidad de los registros en las herramientas de desarrollo. La charla pasa de los errores a los diagnósticos en Node.js.
para poder ver. Así que creo que sería una gran adición. Sí, definitivamente parece una gran adición. Uh, el desarrollador Johta pregunta, ¿alguna aplicación o biblioteca de
Node.js que ayude a visualizar o recopilar todos esos diagnósticos localmente que puedas recomendar, como gráficos de llama, aparte de las herramientas de desarrollo de Chrome. Sí. Entonces, las herramientas de desarrollo serán las principales. Estoy tratando de pensar. Sé que Node source tiene una distribución de Node que tiene muchas cosas de diagnóstico integradas. Eso va a ser más propietario. Creo que puede que tengas que pagar por ello o que tengan una prueba gratuita. Creo que hay un módulo de NearForm llamado Clinic que tiene muchas de estas cosas integradas con una bonita interfaz de usuario. Así que primero echaría un vistazo a esas dos cosas. De acuerdo. Gracias. Y CC Chris pregunta, ¿qué técnicas de diagnóstico recomiendas tener en cuenta en
Node.js en un entorno
serverless? ¿En un entorno
serverless? Es un poco complicado porque, probablemente, no tienes acceso a todas las mismas cosas. No puedes simplemente, ya sabes, crear un perfil de CPU y obtenerlo fácilmente. En un entorno
serverless, estás más a merced del proveedor, creo. Por ejemplo, yo trabajo en
AWS, y
Lambda tiene bastante buena información de diagnóstico. Puedes ejecutar
Node.js allí, hacer que los registros se envíen a CloudFormation, lo siento, no puedo recordar de memoria, bajo presión. Hay un sistema de registro al que puedes hacer que se envíen los registros, y simplemente, ya sabes, otras integraciones con los servicios de
AWS de las que puedes aprovecharte. Pero sí, en un entorno
serverless, algunas de estas cosas de esta charla pueden no ser aplicables.
De acuerdo, así que tengo una pregunta para ti porque eres parte del comité TS de Node.js. ¿Cuáles son algunas de las características que están por venir o que esperas con ansias, algo así para compartir? Esto es algo muy pequeño, pero tú y yo estábamos hablando de esto detrás del escenario. A veces, cuando registrabas cosas desde tu aplicación de Node cuando estabas conectado a las herramientas de desarrollo, aparecían en la consola en lugar de en las herramientas de desarrollo. Y recientemente se abrió una solicitud de extracción para intentar mejorar eso. Así que creo que eso es una de esas pequeñas cosas pero una mejora agradable en la experiencia de usuario. Sí, estoy muy emocionado por eso. Eso sería realmente una gran adición, pequeña, pero aún así impactante, supongo. Entonces, de acuerdo. Tocaste muchos puntos sobre diagnósticos y, de hecho, antes de tu charla, tuvimos una charla sobre errores en Node.js, ¿verdad? Así que fue una transición muy buena de los errores a mostrar todos los diagnósticos en Node.js y cómo se pueden hacer cosas así.
Responsabilidades del Comité TS
El Comité de Dirección Técnica (TSC) es el último recurso para resolver conflictos y tomar decisiones técnicas en la comunidad TS. Idealmente, todas las decisiones deberían tomarse en GitHub, pero cuando las opiniones fuertes obstaculizan el progreso, el TSC interviene para tomar una decisión o votar sobre el problema. Se anima a las personas a investigar más en Google y GitHub después de la charla.
Tengo una última pregunta para ti, seguro. ¿Cuáles son algunas de las responsabilidades que tienes como miembro del Comité TS? Realmente me interesa eso.
Entonces, el Comité de Dirección Técnica es un último recurso en cuanto a la resolución de cualquier tipo de conflicto y decisiones técnicas. Idealmente, nada debería llegar al TSC. Todo debería decidirse en GitHub entre los colaboradores. A veces llegamos a un punto en el que las personas tienen opiniones fuertes y un problema simplemente no puede avanzar y a menudo se involucra al TSC para tomar una decisión e incluso a veces votar sobre ello. Pero sí, diría que eso es lo más importante.
Sí, eso es interesante. No veo más preguntas pero estoy seguro de que la gente tiene mucho que explorar después de esta charla. Así que van a hacer muchas búsquedas en Google y GitHub y cosas así. Y entonces, todos... Déjame solo... Todavía veo la encuesta, así que sí. Si tienes alguna otra pregunta para Colin, aún puedes hablar con él en el chat especial. Colin estará disponible en su sala de conferencias. Y muchas gracias, Colin, por una charla tan profunda y maravillosa. Fue genial, y la gente ha aprendido mucho. Muchas gracias por estar aquí con nosotros hoy. Gracias por tenerme. Adiós. Adiós.
