Examinando la Observabilidad en Node.js

Esta es la agenda para hoy. Primero, hablaremos sobre qué es la observabilidad, luego por qué es importante la observabilidad, cómo podemos usar los internos de Node.js para la observabilidad, incluyendo ganchos de rendimiento, eventos de trazado, capturas de montón, módulo nativo BA. Y luego veremos algunas herramientas externas, pruebas de rendimiento y conclusiones al final.

Entonces, comencemos por comprender qué es la observabilidad y por qué es importante. La observabilidad es un término de la teoría del control. Una definición simple podría ser que es la medida de cuán bien se pueden inferir los estados internos de un sistema a partir del conocimiento de sus salidas externas. En otras palabras, vemos los resultados o la salida, y podemos saber qué está sucediendo en el interior. Tomemos, por ejemplo, plátanos y aguacates. En Colombia, tenemos muchos plátanos y aguacates. Es increíble. Y solo con mirar por fuera, podemos saber cómo está por dentro, si están maduros o si aún no están listos para consumir. En varios productos y servicios, la observabilidad significa que puedes responder cualquier pregunta sobre lo que está sucediendo dentro del sistema observando o haciendo preguntas desde fuera del sistema sin necesidad de enviar nuevo código para responder preguntas. Y eso es muy importante. No deberíamos necesitar escribir nuevo código para observar lo que está sucediendo en uno de nuestros sistemas. Debido a que la complejidad del sistema está superando nuestra capacidad de predecir qué va a fallar. Hay muchas herramientas útiles que vienen al rescate.

Hablando sobre la complejidad del sistema, el software se está volviendo exponencialmente más complejo. En infraestructura, estamos viendo cosas como microservicios, contenedores, Docker, Kubernetes y otros que descomponen los monolitos en microservicios, lo cual es excelente para los productos pero puede ser difícil para los humanos. El número de productos y herramientas también se está multiplicando. Hay innumerables plataformas y herramientas para empoderar a las personas y brindarles una mejor observabilidad y control sobre su código. Genial para los usuarios. Pero es muy difícil elegir cuál es el mejor.

Ahora que sabes qué es la observabilidad, te preguntarás por qué es importante y por qué deberías preocuparte. Con entornos tan complejos como los que vemos hoy en día, simplemente monitorear los problemas no es suficiente para reconocer, encontrar y solucionar una serie de problemas que surgen. A veces los nuevos problemas son conocidos o no, lo que significa que no conoces el problema y, lo que es peor, no sabes cómo encontrarlo. Por lo tanto, sin herramientas para observar el entorno, es casi imposible solucionar ese problema. Por eso es importante la observabilidad. Te brinda la instrumentación que necesitas para comprender lo que está sucediendo en tu software y solucionarlo. Una buena herramienta de observabilidad te ayuda a encontrar qué y dónde está el problema. No agrega sobrecarga a tu aplicación. No queremos que nuestra aplicación se vuelva lenta. Todo lo contrario. También tiene una mayor seguridad, tiene una integración flexible y no necesita modificar tu código. Y también es muy importante diferenciar entre observar y monitorear. Observar es exponer el estado interno para ser visto externamente, y monitorear es recopilar y mostrar la información que se ha expuesto, y generalmente implica escribir herramientas de automatización alrededor de eso.

Si quieres resolver los problemas de Node.js más complejos, como las fugas de memoria o los problemas de rendimiento, o simplemente seguir las mejores prácticas para mantener tu código saludable, es necesario tener una herramienta de observabilidad. El siguiente paso será elegir una herramienta de observabilidad que sea la mejor para nuestras necesidades. Entonces, al elegir una herramienta de observabilidad, nos centraremos primero en los internos de Node.js y luego revisaremos algunas herramientas externas. En los internos de Node.js para la observabilidad, primero hablaremos sobre los ganchos de rendimiento. Esto es particularmente útil para verificar el rendimiento. Es un objeto que se puede usar para recopilar métricas de rendimiento de la instancia actual de Node.js. El monitoreo de rendimiento no es algo que debas comenzar a considerar una vez que comiences a ver problemas. En cambio, debe formar parte de tu proceso de desarrollo para detectar posibles problemas antes de que sean visibles en producción. Debido a la naturaleza asíncrona de Node.js, el perfilado de código con herramientas regulares puede ser muy desafiante. Especialmente porque parte del tiempo transcurrido podría estar fuera de tu propio código y dentro del ciclo de eventos en sí. Por eso es importante utilizar incluso herramientas internas de Node.js como el gancho de rendimiento o herramientas externas como discutiremos más adelante.

Ahora hagamos una pequeña demostración. Aquí estoy usando el servidor de rendimiento de los ganchos de rendimiento y luego tenemos los cuatro motores de búsqueda más grandes: google, yahoo, ping y .co. Tenemos una marca inicial y una marca final y vamos a medir el rendimiento aquí, el tiempo calculado aquí. Y aquí simplemente vamos a imprimir el registro de la consola, imprimir la duración. Si vamos a la terminal, podemos ver que el más rápido en este ejemplo es .co, seguido de google, luego ping y por último yahoo con un segundo y esto es de 447 milisegundos.

Echemos un vistazo a otro ejemplo. Aquí estamos creando simplemente un 'hello world' usando los ganchos de rendimiento, el observador de rendimiento para los ganchos de rendimiento y simplemente voy a imprimir la duración de este 'hello world' y eso es todo. Entonces, si simplemente ejecutamos node, esta aplicación 'hello world' solo tarda 8 milisegundos. Si bien esto es muy informativo, hay algunas compensaciones. Requiere la instrumentación manual de tu código, lo que afecta la confiabilidad. En el caso del observador de rendimiento, hay un costo significativo para el observador, lo cual no es bueno. Hace que la aplicación sea más lenta.

Ahora el perfilado. Si usamos esta bandera de proceso de prop de nodo, generará un archivo de registro como este que se puede utilizar para crear información más legible para los humanos, como gráficos de marcos como este para ver dónde se gasta el tiempo de tu aplicación. Esto puede ser muy productivo para obtener información sobre tu aplicación. La desventaja es que tiene un costo significativo, por lo que generar nuevos archivos puede ser complicado.

Eventos de trazado. El evento de trazado proporciona un mecanismo para centralizar la información de trazado generada por V8, el núcleo de Node.js y el código de espacio de usuario. El trazado se puede habilitar con estas categorías de eventos de trazado que aceptan una lista de nombres de categorías separados por comas o mediante el uso del módulo de eventos de trazado. Entonces, se habilita el trazado asíncrono de Node.js para obtener la salida de varios eventos que ocurren dentro de Node.js, esto puede incluir el acceso al sistema de archivos o datos de rendimiento, ganchos asíncronos y otros. En Chrome, podemos abrir el trazado de Chrome, hacer clic en el botón de grabación rojo que te permite visualizar el trazado como este. Si miras en la parte inferior de la pantalla, puedes ver 'fs sync read', que es la operación de lectura del sistema de archivos. Luego se leen 546 bytes. También es posible ver cuándo se inició el trazado, cuánto tiempo duró y la duración de la CPU, lo cual también es útil para ver qué está sucediendo en tu código. Este otro ejemplo de trazado es un poco más complejo, utilizando más procesos y múltiples hilos. Estamos viendo el hilo principal y diferentes información útil como el tiempo de duración, los procesos dependiendo de otros procesos, argumentos y otros. El trazado tiene un poco menos de costo que el perfilado, pero la gestión de los archivos se vuelve más difícil de manejar porque esto está mirando a un nivel más bajo de instrumentación de los internos de Node.js.

El siguiente es HeapSnapshot. Un HeapSnapshot es una instantánea estática de los detalles del uso de memoria en un momento específico y proporciona una visión del uso de la memoria de V8, el motor JavaScript que impulsa Node.js. Al mirar este HeapSnapshot, puedes comenzar a comprender dónde y cómo se está utilizando la memoria.

Puedes usar la señal incorporada HeapSnapshot como podemos ver aquí para que puedas establecer tantas señales como desees y Node.js simplemente volcará el HeapSnapshot. Chrome DevTools te permite convertir instantáneas y puedes identificar objetos en memoria que te ayudarán a reducir dónde puede estar ocurriendo una fuga de memoria. Así es como se ve un HeapSnapshot en Chrome DevTools a un nivel muy alto. El color de la extrema izquierda aquí representa los objetos en el montón de JavaScript. En la extrema derecha, puedes ver la columna de recuento de objetos que representa cuántos objetos hay en memoria, la columna de tamaño superficial y la columna de tamaño de retención. El tamaño de retención representa la cantidad de memoria que será liberada por el recolector de basura cuando se recolecte el objeto.

El Inspector BA. Esto no es una herramienta de observabilidad, sino una herramienta de desarrollo que te ayuda a monitorear lo que está sucediendo en tu aplicación.

Hace algunos años, Chrome DevTools se integró directamente en BA, ampliando sus capacidades para incluir aplicaciones más nuevas.

Hay varias formas de comenzar. Una es usando la bandera inspect, como podemos ver aquí, que iniciará el inspector. Luego puedes pasar un host y un puerto en los que deseas escuchar, tal como aquí. Y si no se pasan parámetros, se conectará al puerto 127 de forma predeterminada, como podemos ver aquí. Otra forma útil es cuando se realiza un desarrollo local utilizando la bandera inspect break, esta bandera. Esta tiene las mismas opciones para hosts y puertos que la bandera inspect, pero también coloca un punto de interrupción antes de que comience el código del usuario. Así que puedes hacer cualquier tipo de configuración que prefieras sin tener que intentar capturar puntos de interrupción en tu código en tiempo de ejecución.

Ahora, veamos una pequeña demostración. Si creamos esta línea de código aquí, solo un rechazo de promesa, un nuevo error, un error muy genial. Y luego si simplemente hacemos node con la bandera inspect break y el nombre del archivo, podemos ver que Booker está escuchando WS, y luego tenemos una URL de WebSocket. WebSocket permite abrir una sesión de comunicación interactiva bidireccional entre tus usuarios, navegadores y servidores. También podemos ver un mensaje aquí que nos dirige a la documentación de Node.js para que entendamos qué está sucediendo allí y si tenemos alguna pregunta, podemos ir allí. Luego, si vamos a Chrome inspect, esto nos dirigirá a un enlace aquí, enlace de Node.js y si abrimos ese enlace, nos mostrará una ventana emergente para depurar tu sesión de Node.js. Ahora, devtools está conectado a tu Node.js y te proporciona acceso a todas las características de devtools de Chrome que utilizaste, lo que te permite editar páginas sobre la marcha, acceder a mapas de origen, edición en vivo, evaluación de consola, muestra en el perfilador de JavaScript con gráfico de marcos, capturas de heap, pilas asíncronas para promesas nativas y otros.

Sin embargo, los inspectores de VA nunca deben ser utilizados en producción porque las acciones de devtools mantienen eventos. Esto es aceptable en desarrollo, pero no es adecuado para entornos de producción. Para entornos de producción, veremos más adelante cuál es la mejor opción. Pero hay algunos problemas con las cosas que Node.js ya proporciona para la observabilidad, como el perfilado, los ganchos de rendimiento y otros, es que te dice que hay un problema pero no te dice dónde encontrarlo. Además, a veces no es fácil de implementar. No te brinda suficiente información o no se presenta de una manera fácil, como gráficos o una métrica de rendimiento central que proporcionan las herramientas estándar. Además, tiene una sobrecarga significativa. Generalmente, no es viable en producción y solo proporciona sobrecarga de datos, lo que significa que hay una gran cantidad de datos y se requiere experiencia para separar la señal y los datos significativos del ruido.

Pero hay algunas ventajas porque hay herramientas excelentes y tienen una amplia información y conocimiento. Ahora, veremos algunas herramientas externas para la observabilidad de Node.js. Primero está la biblioteca blocked. El paquete npm blocked es un ejemplo conciso de cómo usar temporizadores para la observabilidad. Te ayuda a verificar si el bucle está bloqueado.

Si estás ejecutando Node A o versiones superiores, puedes obtener una traza de la pila que apunte a la función de bloqueo. La función de bloqueo informa cada valor por encima del umbral configurado, que por defecto es de 10 milisegundos. Y puedes hacer lo que quieras con él. Puedes graficarlo, registrarlo, alertarlo y otros. Si bien es útil para comprender la sobrecarga de los bucles de eventos, puede tener falsos positivos en algunos escenarios debido al desfase de tiempo. Además, también puede crear un efecto adormecedor que te alerta sobre bloqueos en el bucle de eventos, pero no indica ni señala qué está causando realmente el bloqueo.

Muchas veces, los desarrolladores simplemente lo ignorarán ya que no hay una acción clara que tomar. Otra herramienta externa es New Relic. New Relic es una plataforma de observabilidad diseñada para ayudar a los ingenieros a crear un mejor software. Desde monolitos hasta sin servidor, te ayuda a instrumentar todo, analizar, solucionar problemas y optimizar toda tu pila de software. También proporciona diferentes soluciones. Así es como aparecen las ideas de New Relic. Puedes ver los tiempos de transacción desperdiciados, la actividad de la aplicación, la tasa de errores, los hosts y otros.

El siguiente es Data Doc. Data Doc es un servicio de monitoreo para aplicaciones a escala en la nube que proporciona monitoreo de servicios, herramientas de bases de datos, una plataforma de análisis de datos basada en verdadero o falso. Con Data Doc, puedes verificar solicitudes, latencia, distribuciones, errores, porcentaje de tiempo transcurrido y otras métricas como podemos ver aquí. Instana es una herramienta de monitoreo del rendimiento de aplicaciones para microservicios. Te permite administrar el rendimiento de tu aplicación en tiempo real y ver todos los detalles sobre el funcionamiento interno y las dependencias internas de los servicios de tu aplicación. Podemos ver algunas de las métricas aquí, como llamadas, tasa de errores, latencia promedio, principales servicios, tiempos de procesamiento y otros.

Entonces, Dynetrix, Dynetrix produce una plataforma de inteligencia de software basada en inteligencia artificial para monitorear y optimizar el rendimiento y desarrollo de aplicaciones, infraestructura de TI y experiencia del usuario. Para la observabilidad de Node.js, puede decirte el número de procesos, el uso de la CPU y la memoria, el porcentaje de conectividad y disponibilidad, el tráfico, las solicitudes más consumidas y otras métricas de Node.js. Pero hay un problema con todas estas soluciones, todas estas herramientas externas. La forma en que funciona el APM es que se convierten en agentes, como podemos ver aquí. Se convierten en intermediarios entre la aplicación y el tiempo de ejecución de Node.js. El APM se inyecta en tu código y encapsula tu aplicación para poder extraer la información y, por lo tanto, tiene un costo significativo conocido como sobrecarga. Otro problema es que a veces tienes que modificar tu propio código para implementar el APM. Pero pueden ser herramientas muy útiles que te brindan información adicional y datos extensos. Ahora veamos una herramienta que no tiene este problema porque no es un APM. Es un tiempo de ejecución empresarial para Node.js y agrega una sobrecarga mínima, nSolid. nSolid es una alternativa lista para usar al tiempo de ejecución de Node.js.

Está mejorada para brindar información de rendimiento de baja entrada y una mayor seguridad para aplicaciones críticas de Node.js. Tiene una resolución de tiempo rápida, una infraestructura más sólida y una mejor seguridad. Esto es importante porque las herramientas APM tradicionales se sitúan en la capa de tiempo de ejecución de Node.js y tienen una sobrecarga de rendimiento que puede variar de una aplicación a otra según la arquitectura.

Node.solid fue construido específicamente para Node.js porque es el propio tiempo de ejecución de Node.js, no es un agente. Esta es la vista general de la consola que proporciona información valiosa sobre los grupos de procesos de Nsolid que se ejecutan en diversas configuraciones. Puedes ver el número de procesos, la vulnerabilidad, el host y el número de aplicaciones. En la vista de clúster, donde puedes ver cada proceso, la CPU, el porcentaje de CPU, el recolector de basura, los recuentos y otros.

Es importante aclarar que las diapositivas anteriores muestran y todas contienen bibliotecas que te ayudan a exponer datos, pero la función principal es como monitor. Por ejemplo, puedo exportar datos utilizando la API de New Relic y consumirlos a través de AWS. Aquí es donde Nsolid tiene una ventaja. Las métricas adicionales que proporciona Nsolid pueden ser consumidas por muchas soluciones de monitoreo sin ninguna sobrecarga adicional. Esto es lo mejor de ambos mundos.

Y finalmente, veremos algunas pruebas de referencia. Si vamos a verificar los tiempos de carga, que es el tiempo que tarda el proceso de Node.js en estar disponible para recibir una solicitud de proceso, podemos ver que Vanilla Node.js aquí es el más rápido con 30 milisegundos, seguido de Nsolid con 40 milisegundos. Luego podemos ver Instana con 210 milisegundos, que es un aumento del 600%, New Relic, Datadog y finalmente AppDynamics, que es un aumento del 3600%. Los tiempos estándar que podemos ver que Node.js toma, Vanilla Node.js tarda 30 milisegundos en el tiempo de inicio, seguido de Nsolid con 35 milisegundos. Luego 150 y 250 milisegundos por AppDynamics y Datadog, que es un aumento del 600%. La sobrecarga de memoria o carga adicional de Nsolid solo agrega 2MB de memoria, mientras que New Relic agrega 15 y Datadog agrega 57MB de sobrecarga. Finalmente, midiendo la velocidad, Nsolid es el más rápido con casi 10000RPS. Luego AppDynamics con 2000RPS y finalmente Datadog con 1500RPS aquí.

Como conclusión, la observabilidad en Node.js es muy importante para la seguridad y el rendimiento. Te permite solucionar errores más rápido y si te estás enfocando en Node.js específicamente, Nsolid es la mejor herramienta de observabilidad disponible. Las otras herramientas son excelentes, pero tienen un costo porque agregan una sobrecarga notable al envolver el código del usuario en sus propias bibliotecas. Nsolid evita estas penalizaciones al observar la aplicación a un nivel inferior, lo que permite que Nsolid haga observaciones sin afectar directamente cómo se ejecuta el programa. Para otros tipos de aplicaciones y según tus necesidades, hay otras excelentes herramientas de observabilidad que agregan mucho valor. Muchas gracias. Aquí es donde puedes encontrarme en las redes sociales y si tienes alguna pregunta, por favor avísame. Gracias.