Desmitificando el trazado distribuido: Mejorar el rendimiento de las aplicaciones

Introducción al seguimiento distribuido

En la era tecnológica actual, se ha vuelto más difícil para los equipos de DevOps tener visibilidad de su pila de aplicaciones a medida que las operaciones de servicio adquieren una naturaleza más distribuida. Esto ha hecho que sea más difícil conocer el alcance de un problema relacionado con el rendimiento y cómo afecta a toda la infraestructura. Por ejemplo, las métricas de rendimiento como "Tiempo de respuesta" y "Llamadas externas" nos dicen que probablemente exista un problema dentro del sistema, pero no proporcionan claridad sobre dónde se puede encontrar exactamente el problema.

Dado que las aplicaciones modernas emplean un enfoque de microservicios ampliamente distribuido para gestionar sus operaciones de TI, el equipo de DevOps a menudo se enfrenta a dificultades al tratar de rastrear, aislar y depurar problemas de rendimiento antes de que los usuarios finales se vean afectados. Lo mejor que se puede hacer es averiguar el subsistema en el que existe el problema y luego empezar a profundizar. Sin embargo, este enfoque requiere que los desarrolladores dediquen una gran cantidad de tiempo y esfuerzo que se podría dedicar a los esfuerzos de producción e implementación.

Aquí es donde entra en escena el seguimiento distribuido. A través de la instrumentación, se ha hecho posible que los equipos de TI y DevOps rastreen una solicitud de principio a fin y correlacionen los datos distribuidos para identificar el lugar exacto en el que la aplicación tiene problemas para funcionar.

¿Qué es el seguimiento distribuido?

El seguimiento distribuido es una técnica de monitoreo para comprender el recorrido que una solicitud realiza a través de su pila de aplicaciones. Mediante el uso de etiquetas identificadoras únicas, el seguimiento distribuido captura la información de rendimiento de cada operación por la que pasa la solicitud. Esto ayuda a los desarrolladores a diferenciar las operaciones dentro de un sistema distribuido y cuánto tiempo tarda cada servicio en funcionar. El seguimiento distribuido también correlaciona las diferentes operaciones dentro de la pila de aplicaciones para elaborar una representación visual de todo el recorrido de las trazas para facilitar la depuración.

¿Por qué necesita el seguimiento distribuido?

En una arquitectura monolítica, a menudo es suficiente tener una vista panorámica para lograr la observabilidad en la aplicación, ya que todo el sistema funciona como una sola unidad donde todas las operaciones son locales, ejecutando un número trazable de funciones en un momento dado. En este caso, el seguimiento tradicional realiza el trabajo a medida que la solicitud fluye a través de un solo sistema donde todos los componentes están acoplados.

Sin embargo, las aplicaciones construidas sobre una arquitectura de microservicios tienen una enorme red de servicios que están interconectados para realizar diferentes operaciones. Este enfoque es ampliamente preferido por los equipos administrativos de TI que buscan un entorno de aplicación flexible y fácilmente escalable. Dado que los pequeños equipos de desarrollo pueden gestionar cada uno de los servicios, el enfoque de microservicios les da la flexibilidad para implementar nuevas pilas de tecnología para operaciones individuales y utilizar API bien definidas para garantizar una comunicación fluida entre sí. Además, los equipos también pueden probar e implementar actualizaciones sin interferir con el funcionamiento de otros servicios.

Un entorno de microservicios garantiza la independencia entre los componentes que evitan que el sistema colapse por completo. En su lugar, el problema se reduciría a una sola operación que se puede aislar y depurar fácilmente sin tener un gran impacto. Sin embargo, esto plantea la cuestión de cómo se puede aislar tal problema.

A pesar de las muchas ventajas que ofrece una arquitectura de microservicios, tener tal nivel de personalización y flexibilidad también tiene su propio lado negativo. Este es el porqué:
Por ejemplo, una solicitud puede fluir a través de una variedad de servicios que están conectados a través de diferentes entornos de aplicaciones; y cada servicio puede estar manejando tareas para varias operaciones. Por lo tanto, cuando se produce una transacción, una solicitud puede llamar a varios servicios uno tras otro. En tal caso, si uno de los servicios es lento, las operaciones posteriores se ven afectadas y también se ralentizan. Esta cadena de eventos aumenta colectivamente el tiempo de respuesta general de la transacción o evento en particular, lo que hace que sea más difícil para los administradores de TI determinar en dónde se originó el problema.

Mediante el seguimiento distribuido, los equipos de DevOps pueden visualizar la interacción y la relación entre los servicios para obtener información detallada sobre el problema de rendimiento experimentado por su pila de aplicaciones. Una vez que han identificado el servicio exacto que está tardando demasiado en procesarse, se puede notificar a los equipos de TI relevantes. Luego pueden identificar fácilmente las fallas, depurarlas y realizar optimizaciones en su infraestructura de TI para una colaboración más eficiente en los microservicios.

Sin embargo, esto no significa que los monolitos no se beneficien del seguimiento distribuido. Una estructura monolítica también puede necesitar del distributed tracing para mejorar la velocidad y la calidad de la depuración.

Terminología del seguimiento distribuido:

• Intervalo: Un intervalo representa el tiempo que tarda un servicio en realizar la operación prevista, que puede ser cualquier cosa, como una respuesta del servidor, una solicitud HTTP, llamadas a la API o consultas a la base de datos. A medida que una solicitud viaja a través de cada servicio, se genera un intervalo en el que el primero se denomina "intervalo principal" y los siguientes serían "intervalos secundarios". Esto significa que cada intervalo tendría una versión principal, excluyendo la primera operación.
• Traza: Una traza representa toda la acción realizada por una solicitud de extremo a extremo. Es el tiempo total que tardan todos los servicios por los que pasa una solicitud. Esencialmente, una traza es la colección de uno o más intervalos. Una traza puede comenzar desde el momento en que un usuario interactúa con la aplicación hasta que se procesa la solicitud.
• ID de traza: A cada solicitud se le asigna un identificador único llamado ID de traza. Un ID de traza viaja junto a una solicitud para que podamos seguir todo el flujo de la solicitud para comprender la interacción entre los servicios.
• ID de intervalo: El ID de intervalo se asigna a cada operación de intervalo.
• Intervalo principal y secundario: Los intervalos generalmente se diferencian para comprender las dependencias entre diferentes servicios a medida que fluye una solicitud. El intervalo principal siempre representa la operación de servicio anterior, mientras que el intervalo secundario representa el servicio que sigue. La duración de cada intervalo principal depende de su respectivo intervalo secundario. Entonces, cuando un intervalo principal en particular tarda demasiado en ejecutarse, todos los intervalos anteriores aumentarán simultáneamente. Este enfoque hace que sea más fácil rastrear la zona exacta donde se produce un cuello de botella.

¿Cómo funciona el seguimiento distribuido?

Para entender cómo funciona el seguimiento distribuido, pensemos en un escenario en el que un usuario está tratando de iniciar sesión en su cuenta en una aplicación web:

Cuando el usuario intenta iniciar sesión en su cuenta, se genera una solicitud HTTP desde el front-end de la aplicación web donde viaja a través de una serie de servicios para recuperar datos del servidor de base de datos. Imaginemos que la solicitud HTTP tiene que pasar por una cadena de acciones para ejecutar todo el proceso por completo. En este caso, el flujo de solicitud HTTP sería: front-end → service-1 → service-2 → service-3 → database server and travels back.

Pensemos un caso en el que los usuarios de la aplicación web tuvieron que esperar mucho tiempo solo para agregar el producto al carrito. Un evento de este tipo seguramente frustrará a los usuarios finales que podrían abandonar el proceso de compra, causando un gran impacto en las operaciones comerciales y los ingresos. Tras la inspección, los desarrolladores sólo pueden conocer el tiempo de respuesta de la transacción en su conjunto, sin tener visibilidad de la eficiencia operativa de los servicios involucrados.

Aquí, el seguimiento distribuido se puede aprovechar recopilando datos en cada paso por el que fluyen las solicitudes hasta llegar al punto final. Al analizar los datos del seguimiento distribuido, los equipos de DevOps podrían identificar visualmente el servicio específico que ha consumido una gran parte del tiempo de respuesta y ha causado un enorme aumento en el tiempo de respuesta general.

Según el escenario anterior, el seguimiento distribuido funciona asignando un ID de traza a la solicitud de tal manera que siga los servicios y el servidor de base de datos. El intervalo para cada servicio se calcula en función del tiempo que tarda en recibir una solicitud y completarla.

Como tal, el intervalo D representa el momento en que el servidor recibe la solicitud HTTP desde el servicio-3. Mientras que el intervalo C comienza cuando se envía una solicitud al servidor de base de datos y termina cuando se recibe una respuesta. Del mismo modo, el intervalo B finaliza cuando la respuesta HTTP es recibida por el servicio-2 y el intervalo A finaliza cuando la respuesta HTTP es recibida por el servicio-1. En este escenario, A sería el intervalo principal del intervalo secundario B. Del mismo modo, B sería el intervalo principal de C y así sucesivamente.

Cuando se detecta un aumento repentino en el tiempo de respuesta de una transacción, los administradores de TI pueden seguir las trazas de cada intervalo. Al recorrer cada intervalo, encuentran que todos los intervalos de A hasta C tienen un tiempo de respuesta alto, mientras que el intervalo D está libre de anormalidades. Dado que C sería el intervalo secundario inferior, solucionar el error en esta etapa generalmente resolvería el problema, ya que los intervalos principales son solo dependencias. Este problema podría deberse a múltiples motivos, como picos de tráfico, aumento de uso, errores, superposiciones de tareas y más.

Cómo realizar el seguimiento distribuido con Applications Manager:

Ahora, si una acción tarda demasiado en ejecutarse, normalmente se utiliza un sistema que realiza un seguimiento distribuido para recopilar métricas de rendimiento importantes en cada servicio. Con una herramienta de monitoreo del rendimiento de las aplicaciones como Applications Manager, puede realizar un seguimiento distribuido para obtener un desglose visual de cada intervalo y descubrir dónde se está retrasando.

Con solo unos sencillos pasos, es fácil descargar Applications Manager y configurarlo en su sistema. En el dashboard del panel, puede crear un nuevo monitor para aplicaciones web que se ejecutan en Java, node js, .Net, Ruby on Rails, Python, PHP, o .Net Core. Una vez que haya configurado su propio monitor de aplicaciones, realizar el seguimiento distribuido es pan comido.

Applications Manager tiene un panel dedicado de "APM" que consolida todos los monitores de aplicaciones en un solo lugar. Al navegar por cada monitor de aplicaciones, así es como puede realizar un seguimiento distribuido con Applications Manager:

1. Vaya a la pestaña "Resumen general" del monitor de aplicaciones. El dashboard proporciona una visión general del rendimiento de las transacciones.
2. Puede encontrar un gráfico de barras que enumera en orden las "5 trazas de rendimiento más lento".

3. Para realizar el seguimiento distribuido, puede seleccionar la transacción que tiene un rendimiento inferior. Esto lo llevará a un mundo completamente nuevo de análisis de trazas con un desglose detallado de los pasos que sigue su llamada, solicitud o consulta.
4. Cada tramo tiene un color según el tipo de componente para que a los administradores les resulte más fácil diferenciar y solucionar problemas.
5. La opción de trazabilidad distribuida cuenta con una vista en cascada donde se enumeran todas las trazas en orden. Aquí, los desarrolladores y los administradores de TI pueden seguir cada intervalo desde la parte superior hasta llegar al punto en el que hay un retraso de rendimiento.
6. Para cada traza, obtiene el tiempo de respuesta correspondiente.

7. La herramienta de seguimiento distribuido de Applications Manager también permite a los usuarios expandir y contraer los menús desplegables para que puedan obtener una mejor vista de la región de seguimiento que está causando el problema de rendimiento.
8. Para una solución de problemas más rápida, Applications Manager también cuenta con un botón selector. Al activar el botón, inmediatamente resalta las trazas que la herramienta sospecha que causaron el problema de rendimiento. De esta manera, puede saltar inmediatamente a la sección donde se puede encontrar la traza lenta.

Cuando el monitoreo de aplicaciones se combina con el seguimiento distribuido:

Tener una herramienta de monitoreo del rendimiento de aplicaciones con funciones de seguimiento distribuido incorporadas tiene las siguientes ventajas:

Solución de problemas más rápida - Dado que los equipos pueden ver todos los pasos de la traza de transacción, es más fácil identificar los componentes defectuosos. Los desarrolladores no tendrán que revisar cada log y pasar horas depurando. En su lugar, reciben notificaciones instantáneas sobre dónde necesitan enfocarse y empiezan a trabajar directamente. Esto reduce significativamente el MTTR, reduciendo así el tiempo de inactividad. Por ejemplo, si el problema ocurre al añadir elementos al carrito, el seguimiento distribuido puede ayudar a solucionar el problema de rendimiento del backend.

Mejorar la productividad a través de la colaboración en equipo - Dado que los microservicios suelen ser gestionados por diferentes equipos, el seguimiento distribuido ayuda a identificar el módulo de servicio específico que requiere atención. De esta manera, cuando un equipo se enfrenta a un problema en todo su flujo de solicitudes, puede identificar y notificar al equipo relevante que es responsable de la lentitud. A continuación, puede ayudar a solucionar el problema.

iFlexbilidad - Usar el seguimiento distribuido en la estrategia de gestión de aplicaciones puede permitir a las organizaciones escalar fácilmente cuando sea necesario. Esto les permite ampliar su entorno de microservicios con nuevas operaciones de servicio sin dudarlo, ya que cuentan con el respaldo del seguimiento distribuido.

Mejorar la experiencia del usuario final - Cuando un usuario final tiene dificultades para navegar a través de una aplicación web, la mayoría de las veces, el problema generalmente se origina a partir de una operación de servicio único. Como resultado, todo el proceso se ralentiza afectando el nivel de satisfacción (puntuación APDEX) de los usuarios de la aplicación. El seguimiento distribuido es una forma de reducir el problema sin dejar que afecte la experiencia digital de sus usuarios finales.

Manténgase por encima de sus competidores con el trazabilidad distribuida:

A medida que más aplicaciones web se están moviendo hacia una arquitectura de microservicios, se vuelve esencial tener también visibilidad distribuida. Con el seguimiento distribuido, los equipos de TI y DevOps pueden identificar, optimizar y solucionar problemas para garantizar un entorno de servicio confiable en toda la pila de aplicaciones. Les da la confianza para tomar decisiones informadas sobre la optimización del rendimiento y abordar los problemas a un ritmo más rápido.

En resumen, el trazabilidad distribuida es uno de los elementos centrales que las herramientas de instrumentación deben ofrecer para obtener una imagen completa de las interdependencias dentro de una pila de aplicaciones. Applications Manager es una de esas herramientas que combina el seguimiento distribuido con el monitoreo del rendimiento de las aplicaciones, que las empresas pueden utilizar de manera efectiva para asegurarse de que las aplicaciones empresariales cumplan con las expectativas del usuario final.

¿Necesita monitorear sus aplicaciones e infraestructura de TI?

Comience ahora descargando nuestra prueba gratis por 30 días para experimentar todas las funciones de nuestra solución de monitoreo o programar una demostración personalizada para realizar un recorrido guiado.