Diagnósticos de Node.js Listos para Usar

♪ Hola a todos. Gracias por asistir a mi charla titulada Diagnósticos de Node.js Listos para Usar. Entonces, esta charla trata sobre cómo obtener información de diagnóstico de Node.js sin usar muchas herramientas de terceros.

Así que, solo para 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 se dejaba a los módulos de NPM. Así que teníamos cosas como Node.js inspector para depuración, Node.js heap dump para capturar instantáneas de heap, Long John para trazas de pila asincrónicas y cosas así. Pero, a lo largo de los años, se ha trabajado mucho en diagnósticos específicamente y en cómo podemos mejorarlos en Node. Pero muchas personas podrían no estar al tanto de que estas cosas existen todavía. Y para la mayoría de los casos de uso, puedes hacer mucho depurando y obteniendo información de Node, solo usando el ejecutable de Node y Chrome.

Así que, mucho del contenido de esta charla es en realidad de la documentación oficial de la CLI, si quieres consultarla por tu cuenta. Y esta charla también asume la última versión de Node 16.

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 depuración. Así que, si alguien ha usado alguna vez el módulo debug en NPM, es muy similar a eso. Entonces, 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. Así que, está Node debug para obtener información del ámbito de JavaScript y Node debug native para obtener información de la capa C++. Y así, cada vez que 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 así, cada vez que ejecutas tu ejecutable o tu aplicación, volcará mucha información en la salida estándar. Puedes ver un ejemplo aquí. Los subsistemas están prefijados con su nombre. Así que, net y HTTP 2 en este ejemplo. Y luego el ID del proceso y luego, ya sabes, varias informaciones de depuración. Así que, cada vez que, ya sabes, se establece una conexión, se cierra una conexión, y cosas de esa naturaleza.

Entonces, lo siguiente de lo que quería hablar era sobre las advertencias en Node.js. Así que, las advertencias se utilizan para informar al usuario de que están haciendo cosas que son potencialmente riesgosas y que desaconsejamos. Así que, hay un puñado de banderas que puedes usar aquí. La bandera dash dash no warnings desactivará todas las advertencias. Puede que no quieras hacer eso. La bandera dash dash redirect warnings se puede usar para tomar todas las advertencias y volcarlas en un archivo en algún lugar para que puedas revisarlas más tarde. Y luego la bandera dash dash trace warnings imprimirá realmente un seguimiento de pila cada vez que se encuentre una advertencia. Y esto puede ser realmente útil para, ya sabes, una advertencia es omitida, pero no estás realmente seguro de por qué, podría estar viniendo desde lo profundo de tu carpeta de node modules. Así que, el seguimiento de pila realmente te dará más información sobre lo que está pasando. Y así, un ejemplo de eso se muestra aquí. Así que, si fueras a requerir el módulo sys, sys es un, ya sabes, un módulo antiguo del núcleo de Node que ha sido largamente desaprobado, 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 desaprobación, y luego puedes usar la bandera dash dash trace deprecation, como mencioné antes, para, lo siento, la bandera trace warnings para ver de dónde en tu código proviene eso. Así que, si miras la flecha que tengo en el seguimiento de pila aquí, verás que realmente proviene de example.js en la línea uno, y así es muy fácil ver qué está pasando. Así que, una cosa a tener en cuenta aquí es que verás en el mensaje dep 0025, así que todas las desaprobaciones en Node tienen un ID, así que realmente puedes ir a la documentación del núcleo de Node, tenemos una página específica solo para desaprobaciones, puedes buscar ese ID de desaprobación y obtener más información de la que está disponible en el seguimiento de pila aquí.

Entonces, lo siguiente de lo que quiero hablar son las desaprobaciones, que son similares a las advertencias. Es una clase específica de advertencia. Nuevamente, tenemos banderas similares para manejarlas, así que tenemos la bandera node deprecation, si no quieres ver ninguna advertencia de desaprobación en tu código, entonces si sabes lo que estás haciendo, entonces podrías querer usar eso. También tenemos dash dash trace deprecation, que imprime un seguimiento de pila, similar a la bandera de advertencias que mostré hace un momento. Y luego también tenemos throw deprecation, que realmente lanzará una excepción cada vez que uses una característica desaprobada. Ahora, esto probablemente no es algo que quieras ejecutar en producción, pero en tu código CI o cuando estás haciendo pruebas, es muy útil para encontrar cosas que necesitas abordar y mover fuera de tu código.

Así que tenemos un ejemplo similar aquí. Nuevamente, esto es require sys porque una advertencia de desaprobación es solo otra advertencia. Así que aquí he usado dash dash throw deprecation para el mismo código que antes. Y en este caso, realmente verás una excepción lanzada, lo cual es agradable porque hace un poco de resaltado del seguimiento de pila. Así que notarás que muchos de los marcos de pila aquí están atenuados. 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 código de donde proviene la desaprobación.

Así que lo siguiente de lo que quería hablar era la E/S sincrónica y cómo puedes encontrarla en tu código. Entonces, la E/S sincrónica bloquea el event loop. Esto solía ser un verdadero asesino del rendimiento. Todavía lo es hasta cierto punto, pero ahora tenemos worker threads que pueden mitigar un poco las cosas. Pero de cualquier manera, probablemente no quieras bloquear tu event loop si no lo necesitas. Especialmente si estás ejecutando una aplicación como un servidor donde tienes múltiples solicitudes siendo manejadas al mismo tiempo. Si bloqueas el event loop en una de las solicitudes, entonces todas las demás solicitudes también sufrirán. Así que cuando estés configurando tu servidor, está bien si estás haciendo E/S sincrónica durante la fase de inicio, pero una vez que comiences a mover tráfico, probablemente no quieras permitir eso. Y así puedes usar la bandera trace sync I.O. de Node para reportar cualquier E/S sincrónica que ocurra después del primer ciclo del event loop.

Así que un ejemplo, que tengo aquí es que estamos usando un set immediate, para que sepamos 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í read file sync realiza un par de operaciones bajo el capó. Abre el archivo, también hará stat del archivo, leerá los datos de él y lo cerrará. Y debido a que todas estas están ocurriendo sincrónicamente, todas resultarán en advertencias individuales. Y así puedes ver en el seguimiento de pila que se proporciona aquí, open sync, try stat sync, read sync y close sync están siendo señalados como E/S sincrónica después del primer ciclo del event loop. Y por supuesto, si quitara el set immediate aquí, esto no reportaría ninguna advertencia porque todavía estaríamos en el primer ciclo del event loop.

A continuación, quería hablar sobre el rastreo de excepciones no capturadas. Así que nuevamente, podrías tener una excepción lanzada en el código de tu aplicación. Podría provenir de tu directorio de node modules, o si simplemente tienes una aplicación grande, podría ser difícil encontrarla. Y la pila en el error en sí misma podría no corresponder realmente a donde la excepción fue lanzada en tu aplicación. Así que puedes usar la bandera trace uncaught siempre que ejecutes tu aplicación.

Y además de imprimir el error en su traza de pila, como ves arriba de la flecha roja aquí, también imprimirá esta información de thrown at y te dará la ruta en tu aplicación donde la excepción fue lanzada. Tenemos una bandera similar para rastrear la salida del proceso. Si un módulo de node llamara a process exit, no tienes idea en tu aplicación de lo que está pasando, puedes usar trace exit y te mostrará de dónde en el código provenía la llamada de salida y también cuál era el código de salida. Así que notarás aquí que salió del entorno con el código cero.

Ahora quiero pasar a hablar sobre los rechazos de promesas no manejados. Así que por defecto en JavaScript los rechazos no manejados son ignorados. Esto es en gran medida aceptable en el navegador, pero esto puede causar muchos problemas serios si estás ejecutando un servidor. Esto fue reportado a node de manera continua y node.js decidió que a partir de node 15 íbamos a cambiar el comportamiento de los rechazos de promesas no manejados para ahora lanzar una excepción. Esto es útil porque sabes 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, sabes que el rechazo simplemente es tragado. Es posible entrar en un estado donde realmente estás filtrando descriptores de archivos y otros recursos y esto puede causar problemas de memoria y simplemente dejar tu servidor en un mal estado.

recursos y esto puede causar problemas de memoria y simplemente dejar tu servidor en un mal estado. Así que el nuevo comportamiento lo hace mucho más explícito lo que está pasando y te permite manejar mejor tus rechazos de promesas. Así que puedes configurar este comportamiento desde la CLI. Si usas la bandera unhandled rejections puedes cambiar los diversos comportamientos. Así que ahora mismo soportamos cinco modos diferentes de unhandled rejections. Throw y strict ambos convertirán 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 mientras que strict pasa directamente a lanzar. Así que uno te da una mejor oportunidad de manejar el rechazo primero. Y luego está el modo warning que mostrará una advertencia en la consola. Warn with error code que es lo mismo que warn pero también establece el código de salida del proceso a uno. Y luego none que es el valor predeterminado de JavaScript de tragar rechazos no manejados. Así que aquí hay un ejemplo rápido con unhandled rejections configurado en strict. Si llamo a promise.

Así que lo siguiente que quería hacer era hablar sobre el tick processor que está disponible en v8 del que creo que mucha gente no está al tanto. Es un muestreador de perfiles 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++. Así que es bastante completo y la forma en que funciona es que ejecutarás tu aplicación con la bandera de línea de comandos dash dash prof y esto volcará la salida del perfilador de v8 en un archivo. Puedes leer el archivo si quieres, pero realmente no está destinado para el consumo humano, así que lo que harás es que después de recopilar esa información, ejecutarás node nuevamente con el dash dash prof process y pasarás el nombre del archivo de registro que se generó y así puedes ver un ejemplo de eso en la parte inferior de la diapositiva aquí aquí y así este es un ejemplo de cómo se verá la salida procesada, así que verás sabes que en la parte superior te muestra dónde estás gastando tu tiempo en bibliotecas compartidas y luego la siguiente sección te muestra dónde estás gastando tu tiempo en código JavaScript. Notarás aquí que tenemos dos funciones process immediate y normalize string y ambas tienen un asterisco delante de ellas. El asterisco significa que v8 realmente pudo optimizar el código en esa función. Y luego la sección inferior es solo un desglose de dónde tu aplicación está gastando su tiempo en código C++.

Así que comenzando hace unos años, Node y v8 realmente comenzaron a tener soporte de primera clase para el inspector de v8, que es esencialmente solo las herramientas de desarrollo de Chrome utilizadas con aplicaciones Node. Así que si has hecho algún tipo de desarrollo para navegadores o incluso desarrollo en Node en los últimos años, hay una buena probabilidad de que hayas visto las herramientas de desarrollo de Chrome. Incluye cosas como un depurador de pasos, perfiles con interfaces GUI en lugar de la basada en CLI que mostré antes. Y así, la forma en que realmente configuras esto es que inicias Node con la bandera dash dash inspect y luego puedes especificar el host y el puerto en el que quieres que escuche en tu máquina. Por defecto, va a escuchar en 127.0.0.1 puerto 9229. Y luego también puedes configurarlo para que tan pronto como inicies la aplicación, establezca un punto de interrupción para ti, así que no tienes que preocuparte por hacerlo manualmente y eso es con la bandera dash dash inspect dash BRK que funciona, aparte del punto de interrupción, de la misma manera y luego un consejo de seguridad es tener cuidado si vas a vincular a la dirección 0.0.0.0 o cualquier otra que sea realmente una dirección pública en tu máquina. Esto solía ser el valor predeterminado para node y sabes que se informó como una vulnerabilidad de seguridad porque si tienes un servidor que puede ser alcanzado públicamente y estás vinculado a una dirección expuesta públicamente como esa, entonces técnicamente es posible que un atacante realmente se conecte al depurador y comience a interferir con tu código y tiempo de ejecución.

Así que lo siguiente que quería hablar o lo siento, solo continuando con el ejemplo del inspector de v8, sabes, el texto en la parte superior te muestra cómo lo ejecutarías node dash dash inspect break example.js. Imprimirá alguna información, así que te dice dónde está escuchando el depurador sabes a través de esta URL de WebSocket y luego te dirige de nuevo a la documentación si tienes sabes más preguntas o necesitas hacer una lectura adicional. Pero puedes, sabes, la imagen en la parte inferior aquí solo te muestra cómo es cuando entras en las herramientas de desarrollo. Nuevamente, muchas personas probablemente han visto esto antes, pero si no lo has hecho, esto es lo que puedes esperar ver.

Una de las herramientas agradables 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 en realidad 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 tu aplicación generalmente está gastando 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 en realidad tiene un par de banderas de línea de comandos que te permiten manipular el perfilador de CPU sin necesidad de hacerlo manualmente. Así que si pasas la bandera dash dash 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. La bandera CPU prof dir te permite especificar dónde quieres que se escriban tus perfiles, si necesitas cambiar desde, ya sabes, la ubicación predeterminada. De manera similar, la bandera CPU prof name te permite dar a tu perfil un nombre de archivo diferente. Y luego la bandera dash dash CPU prof interval te permite definir el intervalo de muestreo del perfilador. Así que, si necesitas, ya sabes, muestrear la pila con más frecuencia o menos frecuencia, puedes controlarlo allí. Y luego, por supuesto, también puedes ir a DevTools en la interfaz de usuario y recopilar perfiles manualmente, si es necesario.

Y así, esto es lo que parece la vista de DevTools de un perfil de CPU. Así que, hay una especie de región en la parte superior que muestra una vista de alto nivel 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 realmente qué funciones se estaban llamando. Así que, verás mucho, en este ejemplo, module.run main, así como require. Así que, ya sabes, al mirar esto, puedes entender que esta es la fase de inicio de tu aplicación, donde se están requiriendo y configurando 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.

Así que, otra característica agradable de Chrome DevTools son las capturas del montón. Así que, estas son muy útiles para ver qué está pasando en el montón de JavaScript, y son realmente, realmente útiles si estás tratando de depurar una fuga de memoria. Así que, puedes realmente tomar una captura en un punto, dejar que tu código de aplicación se ejecute por un tiempo, y luego tomar otra captura y compararlas. Y puedes, ya sabes, si notas, como, ya sabes, antes de que estés en la primera captura en comparación con la segunda captura, hay un montón de nuevos objetos que no se están limpiando que podrían, ya sabes, ayudarte a rastrear la fuga de memoria. Y así, puedes manipular todas estas cosas desde la CLI también. Así que, la señal dash-dash heap snapshot te permite capturar una captura del montón si envías una señal específica al proceso. Y luego también hay heap snapshot near heap limit, así que intentará automáticamente tomar una captura del montón para ti cuando estés casi sin memoria. Esto no está garantizado para siempre funcionar, porque toma memoria adicional para recopilar la captura del montón, pero es definitivamente algo que vale la pena investigar. Y luego, de manera similar a los perfiles de CPU, puedes recopilar estos manualmente a través de la interfaz de usuario de DevTools si tienes un punto de interrupción establecido en tu código. Esto es solo un vistazo rápido a la vista de captura del montón.

Muestra una lista de cada tipo de objeto desglosado por su constructor. Y luego mostrará cosas como el conteo 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á reteniendo ese objeto en particular. Y luego el tamaño retenido sigue los punteros desde 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 era el rastreo de conexiones TLS. Antes, si querías diagnosticar problemas de TLS, tenías que tener el cliente open SSL configurado y pasar algunas banderas de línea de comandos y cosas así. Pero ahora puedes obtener esa información directamente desde Node.js. Así que la bandera dash dash trace TLS desde la CLI volcará toda la misma información para todas las conexiones TLS, solo para que sepas que esto será muy ruidoso, así que definitivamente no querrás habilitar esto en producción. También puedes configurarlo a nivel de socket individual con TLS socket dot enable trace. Y luego también puedes configurarlo cuando estés configurando un socket o cuando estés configurando un servidor con la opción enable trace pasada a create server y TLS connect. Nuevamente, esto volcará una tonelada de información. Así que prepárate para examinarla.

Lo siguiente que quería mencionar era la depuración post-mortem. Así que la forma en que esto funciona es que realmente usarás la bandera abort on unhandle, lo siento, caught exception para crear un archivo core de tu aplicación. Y esto es muy útil porque obtienes el estado completo de tu aplicación. Pero hay muchas desventajas. Así que primero, tienes que configurar tu sistema para recopilar volcados de núcleo, lo cual no suele ser el caso por defecto. Pero también necesitarás una herramienta externa como llnode para poder inspeccionar el archivo core y ver qué está pasando 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. Así que puede ser muy variable en cuanto a qué tan bien funciona de una versión de Node a la siguiente. Pero realmente 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 versión a versión. Así que en Node, queríamos tener una especie de 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 presentado como un gran blob de JSON. Y puedes generar estos bajo diferentes condiciones como un bloqueo, enviando una señal al proceso. Puedes hacerlo programáticamente a través de una API, etc.

Y esto incluye muchas cosas como información sobre el sistema operativo, el proceso, lo que está sucediendo en el grupo de hilos de LibV en cuanto a manejadores y demás. La pila de C++, la pila de JavaScript y mucho más. Supongo que una cosa a tener en cuenta es que esto puede contener información sensible como variables de entorno, así que manéjalos con cuidado.

Para generar un informe de diagnóstico, tenemos una colección de banderas de CLI que puedes usar. Así que 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 pasando, ya sabes, señalando el proceso, puedes configurar qué señal quieres escuchar. Así que puedes hacer eso a través de la bandera report signal. Report directory y report file name se usan para configurar dónde vas a almacenar el informe de diagnóstico y cómo quieres que se llame. Y luego hay una bandera dash dash report compact que lo hará una sola línea de JSON, por lo que es un poco más fácil para las máquinas consumir.

Así que solo una mirada rápida a lo que, ya sabes, una parte de uno de estos se ve como. He creado este a través de la API process.report.getreport. Puedes ver, ya sabes, un subconjunto de lo que está disponible aquí, por lo que tiene cosas como las versiones del informe, esto permite a Node versionar los informes por razones de compatibilidad hacia atrás. El evento que desencadenó esto, así que esta fue una llamada de API de JavaScript para obtener el informe, el nombre del archivo, en este caso es nulo porque esto solo se volcó a la memoria. Cuando fue recopilado, ID de proceso, ID de hilo, un montón de cosas más, así que definitivamente te animo a jugar con estos y, como dije antes, ya sabes, estos pueden contener información sensible, así que manéjalos con cuidado. Si necesitas compartirlos con otras personas, es posible que necesites redactar alguna información a mano, pero es solo JSON, así que no debería ser demasiado difícil.

Así que eso es todo lo que tenía para hoy. Nuevamente, gracias por venir a mi charla, y siéntete libre de contactarme en Twitter, GitHub, donde sea. Gracias a todos. Espero que todos estén, como, 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 salió de la charla de hoy pueda ayudar con eso en el futuro. Creo que si, ya sabes, si la misma encuesta se hubiera hecho hace cinco o seis años, la respuesta probablemente habría estado mucho más cerca del 100%. Solía ser algo realmente difícil de hacer, y sí, el proyecto ha progresado mucho desde los viejos tiempos de Node. Sí, sí. Quiero decir, incluso el 84% es mucho, pero sí, la mayoría de la gente no, quiero decir, sabe sobre las nuevas cosas que vienen y todo. 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, la gente aprendió mucho hoy. Así que fue una sesión genial.

Muchas cosas que no sabía. Guau. Sí. Increíble. Entonces, bien. Entonces, una pregunta de seguimiento sobre tu charla sería, ¿dónde puedo aprender sobre las cosas que mencionaste en la charla? Sí. Entonces, dos lugares realmente. 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 desplazas hacia abajo hasta la línea de comandos, creo que es CLI o documentación de la Interfaz de Línea de Comandos, esta charla vino 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 llamas, ejecutar tu aplicación en Docker, y solo una variedad de cosas diferentes como esa. Bien. Así que, sí, échale un vistazo. Para cualquiera que esté escuchando aquí, revisa toda la documentación y aprende más al respecto.

Entonces, después de esta charla, como, muchas personas han aprendido cosas nuevas, y estarían interesadas más en diagnósticos. Entonces, digamos que alguien está interesado en trabajar en diagnósticos de Node.js. Entonces, ¿hay una manera de que puedan involucrarse con eso? Absolutamente. Entonces, si estás interesado en realmente trabajar en el proyecto, puedes ir a, ya sabes, github.com slash Node.js slash Node. Ahí es donde el proyecto, ya sabes, realmente vive. Pero también tenemos un grupo de trabajo de diagnósticos, 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 slash Node.js slash diagnostics. Y, ya sabes, puedes ir allí y si realmente estás 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 que aún ves que podrían mejorarse en los diagnósticos con Node.js? Um, esa es una buena. Entonces, mencioné un poco la depuración postmortem. Me encantaría ver que la depuración postmortem mejore. Desafortunadamente, eso requiere bastante cooperación con V8. Y, ya sabes, no es que no cooperen, pero no sé si ven tanto valor en ello. Y luego también me gustaría ver que los gráficos de llamas tengan una especie de más primera clase de ciudadanía dentro de Node. Entonces, ahora mismo, esa es una de las pocas cosas que mencioné brevemente en la charla donde realmente tendrías que salir de Node y las herramientas de desarrollo para poder mirar.

Así que creo que sería una gran adición. Sí, definitivamente parece una gran adición. Uh, Johta developer pregunta, ¿alguna aplicación o biblioteca de Node.js que ayude a visualizar o recopilar todos esos diagnósticos localmente que podrías recomendar como gráficos de llamas, aparte de Chrome dev tools. Sí. Entonces, dev tools será el principal. Estoy tratando de pensar. Entonces, sé que Node source tiene una distribución de Node que tiene muchas cosas de diagnósticos integradas. Eso va a ser más propietario. Creo que puede que tengas que pagar por ello o que puedan tener una prueba gratuita. Creo que hay un módulo de NearForm llamado Clinic que tiene muchas de estas cosas integradas con una pequeña interfaz de usuario agradable. Así que miraría esas dos cosas primero.

Bien. Gracias. Y un CC Chris pregunta, ¿qué técnicas de diagnóstico recomiendas tener Node.js en un entorno serverless? ¿En un entorno serverless? Entonces, es un poco complicado allí porque probablemente no tengas acceso a todas las mismas cosas. Como que no puedes simplemente, ya sabes, crear un perfil de CPU y obtenerlo fácilmente. Para un serverless, estás más a merced del proveedor, creo. Entonces, por ejemplo, trabajo en AWS, y Lambda tiene bastante buena información de diagnósticos. Puedes ejecutar Node.js allí, hacer que los registros vayan a CloudFormation, lo siento, no CloudFormation. No puedo recordar de memoria, presión. Hay un sistema de registro allí al que puedes hacer que los registros se envíen, y solo, ya sabes, otras integraciones con servicios de AWS de las que puedes aprovecharte. Pero sí, en un entorno serverless, algunas de estas cosas de esta charla pueden no aplicarse.

Bien, entonces 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 estás esperando, emocionado por, algo así para compartir? Entonces, esto es algo realmente pequeño, pero tú y yo estábamos hablando de esto entre bastidores. A veces, cuando registrabas cosas desde tu aplicación node cuando estás conectado a dev tools, aparecía en la consola en lugar de en dev tools. Y en realidad hubo una solicitud de extracción abierta recientemente para tratar de mejorar eso. Así que creo que es una de esas, ya sabes, una pequeña cosa pero una agradable mejora de UX. Sí, estoy realmente emocionado por eso. Eso realmente sería una gran adición, pequeña, pero aún así será impactante, supongo. Así que, bien. 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 agradable de errores a mostrar todos los diagnósticos y en Node.js y cómo podrías hacer cosas así.

Tengo una última pregunta para ti, seguro. ¿Cuáles son algunas de las responsabilidades para ti como miembro del comité TS? Estoy realmente interesado en eso.

Entonces, el Comité de Dirección Técnica es como el último recurso en cuanto a resolver cualquier tipo de conflictos 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 donde las personas tienen opiniones fuertes y un problema simplemente no puede progresar y el TSCO a menudo entonces es llamado para tomar una decisión y ocasionalmente incluso tiene que votar sobre ello. Pero sí, diría que eso es lo más importante.

Sí, eso es interesante. Así que 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 estoy viendo la encuesta, así que sí. Si tienes alguna otra pregunta para Colin, aún puedes hablar con él en el chat especial. Así que, Colin estará disponible en su sala de oradores. Y muchas gracias, Colin, por una charla tan profunda y maravillosa. Fue genial, y la gente ha aprendido mucho. Muchas gracias por estar con nosotros aquí hoy. Gracias por invitarme. Adiós.