En los primeros años de Node.js, los diagnósticos y la depuración eran puntos problemáticos considerables. Las versiones modernas de Node han mejorado considerablemente en estas áreas. Características como seguimiento de pila asíncrono, capturas de montón y perfilado de CPU ya no requieren módulos de terceros o modificaciones en el código fuente de la aplicación. Esta charla explora las diversas características de diagnóstico que se han incorporado recientemente a Node.
Puedes consultar las diapositivas de la charla de Colin aquí.
This talk has been presented at Node Congress 2022, check out the latest edition of this JavaScript Conference.
FAQ
Puedes obtener diagnósticos de Node.js utilizando el ejecutable de Node y Chrome, además de utilizar variables de entorno de debug para registrar información adicional durante la ejecución.
Puedes usar las banderas --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 cuando se encuentre una advertencia.
Node.js utiliza banderas como --no-deprecation para ocultar advertencias de deprecación y --trace-deprecation para imprimir una traza de pila de donde proviene la deprecación.
La E/S síncrona bloquea el Event Loop y puedes usar la bandera --trace-sync-io para informar cualquier E/S síncrona que ocurra después del primer ciclo del Event Loop.
Puedes usar la bandera --trace-uncaught para imprimir el error y su traza de pila, además de información sobre dónde se lanzó la excepción en tu aplicación.
Desde la versión 15, Node.js cambió el comportamiento de los rechazos de promesas no manejados para lanzar una excepción, ayudando a identificar y manejar mejor estos rechazos.
Puedes iniciar Node con la bandera --inspect y conectarlo con las herramientas de desarrollo de Chrome para utilizar capacidades como depurador paso a paso y perfiles de CPU.
Node.js ofrece indicadores como --cpu-prof para recopilar un perfil de CPU automáticamente y --cpu-prof-dir para especificar la ubicación de los perfiles generados.
Puedes usar el indicador --heap-snapshot-signal para capturar montones enviando una señal específica al proceso, y analizar estas capturas para identificar posibles fugas de memoria.
Los informes de diagnóstico son documentos JSON que contienen información detallada sobre el proceso de Node.js. Pueden generarse en situaciones específicas como errores fatales o excepciones no capturadas usando banderas como --report-on-fatal-error o --report-on-uncaught-exception.
Esta charla cubre varias técnicas para obtener información de diagnóstico de Node.js, incluyendo la depuración con variables de entorno, manejo de advertencias y obsolescencias, rastreo de excepciones no capturadas y salida del proceso, uso del inspector v8 y herramientas de desarrollo, y generación de informes de diagnóstico. El orador también menciona áreas de mejora en los diagnósticos de Node.js y proporciona recursos para aprender y contribuir. Además, se discuten las responsabilidades del Comité de Dirección Técnica en la comunidad de TS.
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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,
QnA
Aprendiendo y Contribuyendo a los Diagnósticos de Node.js
Short description:
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
Short description:
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
Short description:
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.
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
Deno aims to provide Node.js compatibility to make migration smoother and easier. While Deno can run apps and libraries offered for Node.js, not all are supported yet. There are trade-offs to consider, such as incompatible APIs and a less ideal developer experience. Deno is working on improving compatibility and the transition process. Efforts include porting Node.js modules, exploring a superset approach, and transparent package installation from npm.
Today's Talk is about logging with Pino, one of the fastest loggers for Node.js. Pino's speed and performance are achieved by avoiding expensive logging and optimizing event loop processing. It offers advanced features like async mode and distributed logging. The use of Worker Threads and Threadstream allows for efficient data processing. Pino.Transport enables log processing in a worker thread with various options for log destinations. The Talk concludes with a demonstration of logging output and an invitation to reach out for job opportunities.
Fastify is a powerful tool for building web applications and APIs in Node.js, with millions of downloads per month. It promotes encapsulation and structuring through plugins and decorators, allowing for code and data segmentation. The talk emphasizes the importance of modularizing applications by domains and features, and showcases a demo of a typical Fastify application. The speaker also discusses the benefits of using Platformattic for refactoring and launching Fastify applications in the cloud. The Q&A section covers topics such as dependency injection and debugging, while also highlighting the importance of separating business logic from API contracts.
¿Alguna vez has tenido dificultades para diseñar y estructurar tus aplicaciones Node.js? Construir aplicaciones que estén bien organizadas, sean probables y extensibles no siempre es fácil. A menudo puede resultar ser mucho más complicado de lo que esperas. En este evento en vivo, Matteo te mostrará cómo construye aplicaciones Node.js desde cero. Aprenderás cómo aborda el diseño de aplicaciones y las filosofías que aplica para crear aplicaciones modulares, mantenibles y efectivas.
Platformatic te permite desarrollar rápidamente APIs GraphQL y REST con un esfuerzo mínimo. La mejor parte es que también te permite aprovechar todo el potencial de Node.js y Fastify cuando lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y complementos adicionales. En el masterclass, cubriremos tanto nuestros módulos de código abierto como nuestra oferta en la nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). En este masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la nube de Platformatic.
Construyendo un Servidor Web Hiper Rápido con Deno
WorkshopFree
2 authors
Deno 1.9 introdujo una nueva API de servidor web que aprovecha Hyper, una implementación rápida y correcta de HTTP para Rust. El uso de esta API en lugar de la implementación std/http aumenta el rendimiento y proporciona soporte para HTTP2. En este masterclass, aprende cómo crear un servidor web utilizando Hyper en el fondo y mejorar el rendimiento de tus aplicaciones web.
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada. Mejoraremos una aplicación JS de pila completa (backend de Node.JS + frontend de React) para autenticar usuarios con OAuth (inicio de sesión social) y contraseñas de un solo uso (correo electrónico), incluyendo:- Autenticación de usuario - Administrar interacciones de usuario, devolver JWT de sesión / actualización- Gestión y validación de sesiones - Almacenar la sesión para solicitudes de cliente posteriores, validar / actualizar sesiones Al final del masterclass, también tocaremos otro enfoque para la autenticación de código utilizando Flujos Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña. Tabla de contenidos- Una breve introducción a los conceptos básicos de autenticación- Codificación- Por qué importa la autenticación sin contraseña Requisitos previos- IDE de tu elección- Node 18 o superior
Cómo construir una aplicación GraphQL fullstack (Postgres + NestJs + React) en el menor tiempo posible. Todos los comienzos son difíciles. Incluso más difícil que elegir la tecnología es desarrollar una arquitectura adecuada. Especialmente cuando se trata de GraphQL. En este masterclass, obtendrás una variedad de mejores prácticas que normalmente tendrías que trabajar en varios proyectos, todo en solo tres horas. Siempre has querido participar en un hackathon para poner algo en funcionamiento en el menor tiempo posible, entonces participa activamente en este masterclass y únete a los procesos de pensamiento del instructor.
Node.js test runner es moderno, rápido y no requiere bibliotecas adicionales, pero entenderlo y usarlo bien puede ser complicado. Aprenderás a utilizar Node.js test runner a su máximo potencial. Te mostraremos cómo se compara con otras herramientas, cómo configurarlo y cómo ejecutar tus pruebas de manera efectiva. Durante la masterclass, haremos ejercicios para ayudarte a sentirte cómodo con el filtrado, el uso de afirmaciones nativas, la ejecución de pruebas en paralelo, el uso de CLI y más. También hablaremos sobre trabajar con TypeScript, hacer informes personalizados y la cobertura de código.
Comments