Desmitificando el rastreo distribuido: mejorando el desempeño de las aplicaciones

Noticias y Novedades

Introducción al rastreo 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 se han vuelto de naturaleza más distribuida. Esto ha hecho que sea más difícil conocer el alcance total de un problema relacionado con el rendimiento y cómo afecta a toda la infraestructura. Por ejemplo, métricas de rendimiento como «Tiempo de respuesta» y «Llamadas externas» nos indican que probablemente existe 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 microservicio ampliamente distribuido para administrar sus operaciones de TI, el equipo de DevOps a menudo enfrenta dificultades para rastrear, aislar y depurar problemas de rendimiento antes de que los usuarios finales se vean afectados. Lo mejor que se puede hacer es descubrir el subsistema en el que existe el problema y luego empezar a profundizar más. Sin embargo, este enfoque requiere que los desarrolladores dediquen una gran cantidad de tiempo y esfuerzo que pueden reorientarse hacia los esfuerzos de producción e implementación.

Aquí es donde el rastreo distribuido entra en escena. A través de la instrumentación, los equipos de TI y DevOps han podido rastrear una solicitud de principio a fin y correlacionar los datos distribuidos para identificar el punto exacto donde la aplicación tiene dificultades para funcionar.

 

¿Qué es el rastreo distribuido?

 

El seguimiento distribuido es una técnica de monitoreo para comprender el recorrido que realiza una solicitud a través de su pila de aplicaciones. Al utilizar etiquetas de identificación ú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 lleva realizar cada servicio. El rastreo distribuido también mapea la relación entre diferentes operaciones dentro de la pila de aplicaciones para dibujar una representación visual de todo el recorrido del rastreo para facilitar la depuración.

¿Por qué necesita seguimiento distribuido?

 

En una arquitectura monolítica, una vista panorámica suele ser suficiente para obtener observabilidad de la aplicación, ya que todo el sistema opera como una sola unidad donde todas las operaciones son locales y ejecutan una cantidad rastreable de funciones en cualquier momento dado. En este caso, el rastreo tradicional hace el trabajo ya que la solicitud fluye a través de un único sistema donde todos los componentes están acoplados.

Sin embargo, las aplicaciones creadas sobre una arquitectura de microservicios tienen una enorme red de servicios que están interconectados para realizar diferentes operaciones. Este enfoque es el preferido por los equipos administrativos de TI que buscan un entorno de aplicaciones flexible y fácilmente escalable. Dado que los pequeños equipos de desarrollo pueden administrar cada uno de los servicios, el enfoque de microservicios les brinda la flexibilidad de 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, lo que evita que el sistema colapse por completo. En cambio, el problema se limitaría a una única 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 aislar tal cuestión.

A pesar de las muchas ventajas que ofrece una arquitectura de microservicios, tener tanta personalización y flexibilidad también tiene su propia desventaja. He aquí por qué:
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. Entonces, cada vez que ocurre una transacción, una solicitud puede llamar a múltiples servicios uno tras otro. En tal caso, si hay lentitud en alguno de los servicios, 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 dificulta que los administradores de TI señalen dónde se originó el problema.

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

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

Terminologías en el rastreo distribuido:

 

  • Intervalo: un intervalo representa el tiempo que tarda un único servicio en realizar la operación prevista, que puede ser cualquier cosa como una respuesta del servidor, una solicitud HTTP, llamadas API o consultas de bases 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 «intervalo secundario». Esto significa que cada tramo tendría una versión principal, excluyendo la primera operación.
  • Seguimiento: un seguimiento representa la acción completa realizada por una solicitud de un extremo a otro. Es el tiempo total que tardan todos los servicios por los que pasa una solicitud. Básicamente, una traza es la colección de uno o más tramos. Un seguimiento puede comenzar en el momento en que un usuario interactúa con la aplicación hasta el momento en que se procesa la solicitud.
  • ID de seguimiento: a cada solicitud se le asigna un identificador único llamado ID de seguimiento. Un ID de seguimiento viaja junto con una solicitud para que podamos mapear todo el flujo de la solicitud para comprender la interacción entre los servicios.
  • ID de tramo: SpanID se asigna a cada operación de tramo.
  • Intervalo entre padres e hijos: los intervalos generalmente se diferencian para comprender las dependencias entre los diferentes servicios a medida que fluye una solicitud. Un 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 secundario en particular tarda demasiado en ejecutarse, todos los intervalos anteriores aumentarán simultáneamente. Este enfoque facilita la localización de la zona exacta donde se produce un cuello de botella.

 

¿Cómo funciona el rastreo distribuido?

 

Para comprender cómo funciona el seguimiento distribuido, consideremos un escenario en el que un usuario intenta 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 la base de datos. Consideremos 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 → servicio-1 → servicio-2 → servicio-3 → servidor de base de datos y regresa.

Consideremos un caso en el que se descubrió 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 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 de seguimiento distribuidos, los equipos de DevOps podrían identificar visualmente el servicio específico que ha consumido una gran parte del tiempo de respuesta y ha dado lugar a un enorme aumento en el tiempo de respuesta general.

Según el escenario anterior, el seguimiento distribuido funciona asignando un ID de seguimiento a la solicitud de modo que siga los servicios y el servidor de la base de datos. La duración de cada servicio se calcula en función del tiempo que les lleva recibir una solicitud y completarla por completo.

Como tal, el lapso D representa el momento en que el servidor recibe la solicitud HTTP del servicio 3. Mientras que el intervalo C comienza cuando se envía una solicitud al servidor de la base de datos y finaliza cuando se recibe una respuesta. De manera similar, el intervalo B finaliza cuando el servicio 2 recibe la respuesta HTTP y el intervalo A finaliza cuando el servicio 1 recibe la respuesta HTTP. En este escenario, A sería el intervalo principal del intervalo secundario, B. De manera similar, B sería el intervalo principal 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 el rastro de cada tramo. Al recorrer cada tramo, encontrarían que todos los tramos desde A hasta C tendrían un tiempo de respuesta alto, mientras que el tramo D está libre de anomalías. Como C sería el intervalo secundario más inferior, solucionar el problema 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 trabajos y más.

Cómo realizar un seguimiento distribuido con el Administrador de aplicaciones:

 

Ahora, si una acción completa 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 tramo y descubrir dónde se está retrasando.

Con sólo unos sencillos pasos, es fácil descargar el Administrador de aplicaciones y configurarlo en su sistema. En el panel 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.

El Administrador de aplicaciones tiene un panel ‘APM’ dedicado 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 el Administrador de aplicaciones:

 

  1. Visite la pestaña ‘Descripción general’ del monitor de aplicaciones. El panel ofrece 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 un seguimiento distribuido, puede seleccionar la transacción que tiene un rendimiento inferior. Esto lo llevará a un mundo completamente nuevo
de análisis de seguimiento 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 seguimiento distribuido presenta una vista en cascada donde todos los seguimientos se enumeran en orden. Aquí, los desarrolladores y
administradores de TI pueden seguir cada tramo desde arriba hasta llegar al punto en el que hay un retraso en el rendimiento.

6. Para cada seguimiento, obtienes su 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, el Administrador de aplicaciones también cuenta con una función de botón de alternancia. Al activar la palanca,
resalta inmediatamente los rastros que la herramienta sospecha que son los culpables del problema de rendimiento. De esta manera, puedes saltar
inmediatamente a la sección donde se puede encontrar el rastro lento.

 

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

 

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

Solución de problemas más rápida : dado que los equipos pueden ver todos los pasos del seguimiento de la transacción, resulta más fácil identificar los componentes defectuosos. Los desarrolladores no tendrán que revisar cada registro y dedicar horas a la depuración. En lugar de eso, reciben una notificación instantánea en qué deben concentrarse y se ponen a trabajar directamente. Esto reduce significativamente el MTTR, reduciendo así el tiempo de inactividad. Por ejemplo, si el problema es agregar al carrito, el seguimiento distribuido puede ayudar con el problema de rendimiento del backend allí.

Productividad mejorada a través de la colaboración en equipo : dado que los microservicios suelen ser administrados 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 enfrenta un problema en todo su flujo de solicitudes, puede identificar y notificar al equipo relevante que es responsable de la causa de la lentitud. Luego podrán ayudar a solucionar el problema.

Flexibilidad : emplear el seguimiento distribuido en la estrategia de gestión de aplicaciones puede facilitar que las organizaciones escale cuando sea necesario. Esto les permite ampliar su entorno de microservicios con nuevas operaciones de servicios sin dudarlo, ya que cuentan con el respaldo del rastreo distribuido.

Mejorar la experiencia del usuario final : siempre que 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 en una única operación de servicio. Como resultado, todo el proceso se ralentiza afectando el nivel de satisfacción (puntuación APDEX) de los usuarios de la aplicación. El rastreo distribuido es una forma de reducir el problema sin permitir que afecte la experiencia digital de los usuarios finales.

Manténgase por encima de sus competidores con el seguimiento distribuido:

 

A medida que más aplicaciones web avanzan 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 su 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 seguimiento distribuido es uno de los elementos centrales que deben ofrecer las herramientas de instrumentación 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 garantizar que las aplicaciones comerciales cumplan con las expectativas del usuario final.

 

Fuente: Manageengine.com

 

×