Observabilidad Integral a través del Rastreo Distribuido en Node.js

Hola a todos. Bienvenidos a la sesión sobre observabilidad integral a través del rastreo distribuido en Node.js. Soy el anfitrión de la sesión. Soy Chinmay Gaikwad, evangelista técnico en Epsigon. Comencemos con la sesión. En esta sesión, analizaremos los nuevos desafíos en microservicios, centrándonos específicamente en la observabilidad. También veremos cómo solucionar problemas en aplicaciones distribuidas utilizando un ejemplo, y finalmente veremos cómo construir una estrategia sostenible de observabilidad para su empresa. Comencemos con los desafíos en microservicios. Sabemos que los microservicios tienen grandes beneficios, incluyendo escalabilidad, velocidad de desarrollo y reducción del tiempo de administración del sistema, pero también han traído nuevos desafíos como la observabilidad en microservicios. Utilizando sistemas de monitoreo tradicionales, puede ser casi imposible saber qué está sucediendo bajo el capó. Exploraremos esto en detalle.

Habrá muchos detalles en las próximas diapositivas. Primero, veamos cómo solucionar problemas en aplicaciones distribuidas. Sabemos que los tres pilares de la observabilidad son los registros y los rastros. Nos sumergiremos en el rastreo más adelante. Comencemos con las métricas. Las métricas son una excelente manera para que los equipos de operaciones descubran si algo ha salido mal. Algunos ejemplos de métricas incluyen el uso de la CPU, el uso de la memoria. También tenemos métricas a nivel empresarial como tasas de rebote, ingresos, tasa de clics, etc. Por otro lado, los registros nos dicen por qué algo salió mal. Entonces, para esta sesión, consideremos un ejemplo de una tienda virtual. Como pueden ver, el servidor SAP autentica las solicitudes utilizando Auth0 y luego las envía al flujo de Kafka. Un contenedor Java extrae el flujo y actualiza una tabla DynamoDB. Digamos que hubo una situación en la que los usuarios se quejaron de que se envió OAuth pero no se manejó. ¿Por dónde empezarías?

Las soluciones de monitoreo tradicionales tienen el inconveniente de un mayor uso de recursos porque tienen múltiples agentes pesados. Y también tienen la capacidad de solo recopilar métricas del host o están impulsadas puramente por métricas. Las métricas, como hemos visto, realmente solo nos indican que algo está roto, pero no cuándo ni por qué. El contexto es absolutamente crítico en los entornos actuales. Usando el método tradicional, primero miras las métricas de Kafka. No ves nada anormal aquí, así que tal vez mires las métricas de DynamoDB a continuación. Vemos algunas fluctuaciones aquí, así que eso es bastante interesante. Entonces, para depurar esto, necesitas más datos. Y más datos significa registros. Pero, ¿son realmente suficientes los registros en un entorno basado en microservicios? Vamos a investigarlo. Todos sabemos cómo se ven los registros. Personalmente, tengo una relación de amor-odio con los registros. Me encanta el hecho de que estén disponibles, pero odio tener que buscar en ellos. Me he pasado horas buscando entre cientos o incluso miles de líneas de registros esperando encontrar ese valor atípico. ¿Y si supiera la ruta exacta que sigue la solicitud a través de los servicios y componentes individuales? Los registros son buenos para depurar en la lista, pero no funcionan realmente como punto de partida en un sistema altamente distribuido. Entonces, en un ejemplo de taller, si tienes mucha suerte, podrás detectar el problema, pero podría llevar mucho tiempo. Así que hagamos un resumen de las cosas que faltan aquí. Básicamente, se reduce a la correlación.

La correlación entre métricas y registros y entre diferentes servicios es crucial para encontrar el problema exacto. ¿Entonces, cómo correlacionamos estas piezas? Ahí es donde entra en juego el rastreo distribuido. Estoy seguro de que muchos de ustedes han escuchado hablar del rastreo últimamente. Muchos proveedores ofrecen alguna forma de rastreo distribuido. Incluso las mallas de servicios ahora están construyendo soporte para ello. Este rastreo ayuda a encontrar la aguja en el pajar que los registros o las métricas pueden pasar por alto. Solo porque tu aplicación tenga 15 o 20,000 servicios no significa que una solicitud pase por todos y cada uno de ellos. Como máximo, pasará por una fracción de ellos. Entonces, utilizando el rastreo distribuido en nuestro ejemplo de trabajo virtual, ahora puedes ver dónde está el problema. El problema es la falta de un ID de clave. Con el ID de clave, cuando te enfocas en el flujo de Kafka, ves que falta el nombre de usuario. Y luego, cuando te enfocas en el microservicio Auth0, puedes ver por qué exactamente falta. Es debido a un token expirado. Entonces, específicamente para Auth0, ahora sabes que deberías usar tokens de actualización en lugar de tokens de acceso. En resumen, esto ha reducido significativamente tu tiempo medio de resolución y detección en comparación con las soluciones de monitoreo tradicionales.

Las soluciones de monitoreo tradicionales tienen una serie de limitaciones. El rastreo distribuido tiene varios beneficios. Veamos algunos de ellos. Una arquitectura típica involucra varios microservicios, y una de las características más importantes de una solución de observabilidad es la visualización. Los usuarios también deben esperar datos accionables dentro de estas visualizaciones complejas y mapas de servicios. Por ejemplo, en estas visualizaciones, deberías poder ver la latencia entre los componentes, así como las áreas donde se han cruzado los umbrales. Como has visto en el ejemplo anterior de una tienda virtual, una solución basada en el rastreo distribuido también puede ayudar a reducir el alcance de los servicios. Esto elimina la incertidumbre al determinar qué salió mal. Sin estas capacidades de filtrado inteligente, el mapa de arquitectura se convierte en nada más que un ejercicio de teoría del caos. Otro gran beneficio de una solución de rastreo distribuido es identificar dónde se está invirtiendo tiempo en el código. Aquí tienes un ejemplo de trazas que componen un rastreo. Estas esencialmente te pueden decir si una parte significativa del tiempo se gasta esperando una llamada a una API externa o si tienen una llamada ineficiente a la base de datos que necesita refactorización. En Epsilon, hemos diseñado nuestro producto siguiendo las mejores prácticas para la observabilidad al hablar con expertos de la industria y nuestros clientes. Por ejemplo, deberíamos tener un enfoque automatizado que consista en agentes ligeros que no consuman muchos recursos. Además, estos agentes deben admitir diferentes entornos, como máquinas virtuales, contenedores o sin servidor. Deberíamos poder hacer esto con un contexto completo en métricas, eventos, registros y trazas que te permita buscar la carga completa o etiquetas personalizadas. La observabilidad no solo debe decirte si algo salió mal, sino también señalar dónde y por qué exactamente para ayudar a reducir tu tiempo medio de detección y resolución.

Y finalmente, si tienes que construir una estrategia de observabilidad, debes planificar con anticipación. En primer lugar, ten claridad sobre tus objetivos comerciales y modelo de arquitectura y determina tu enfoque, ya sea de bricolaje o gestionado. Ambos tienen sus pros y contras. Por ejemplo, utilizando el enfoque de bricolaje, puedes utilizar una de las soluciones de código abierto, pero requerirá un esfuerzo de desarrollo significativo para hacerlo correctamente, si lo haces correctamente. Luego implementa la solución de observabilidad y finalmente asegura la escalabilidad, porque los microservicios pueden escalar muy rápido. La escalabilidad de la solución de observabilidad es sumamente crítica. Por último, me gustaría terminar esta sesión diciendo que debes elegir una estrategia que te permita ser proactivo y no reactivo. Gracias por asistir a la sesión. Visita la URL en la diapositiva para obtener una oferta especial. Gracias de nuevo.