Usa el seguimiento distribuido para observar la latencia de los microservicios

Last reviewed 2023-08-11 UTC

Cuando se reescribe una aplicación para usar microservicios, la cantidad de componentes y extremos involucrados en una sola transacción de usuario aumenta. Por lo tanto, la observabilidad es fundamental para operar los servicios de usuarios de manera confiable. En esta arquitectura de referencia, se muestra cómo capturar información de seguimiento en aplicaciones de microservicios mediante OpenTelemetry y Cloud Trace.

Este documento está dirigido a desarrolladores, ingenieros DevOps y SRE que desean comprender los aspectos básicos del seguimiento distribuido y que deseen aplicar esos principios a sus servicios para mejorar su observabilidad.

Arquitectura

En el siguiente diagrama, se muestra la arquitectura de una aplicación que implementa esta arquitectura.

Arquitectura de una implementación de muestra con dos clústeres de GKE.

Como se ilustra en el diagrama anterior, esta arquitectura incluye dos clústeres de GKE. Implementas una aplicación en cada uno de los clústeres. El tráfico de usuarios se envía a la app de frontend en el clúster de frontend. El Pod de frontend del clúster de frontend se comunica con el Pod de backend del clúster de backend. El Pod de backend llama a un extremo de API externo.

Los datos de observabilidad se exportan a Cloud Trace, lo que hace un seguimiento de cómo se propagan las solicitudes a través de las aplicaciones.

Consideraciones del diseño

En el caso de los servicios que se ejecutan en Kubernetes, puedes usar una malla de servicios como Istio para habilitar el seguimiento distribuido de un servicio a otro tráfico de servicio sin necesidad de instrumentación dedicada. Sin embargo, es posible que tengas cualquiera de los siguientes requisitos:

  • Deseas tener más control sobre los seguimientos que lo que proporciona Istio.
  • Es posible que debas capturar los componentes internos de la aplicación en la información de seguimiento.
  • Es posible que debas realizar un seguimiento del código que no se ejecuta en Kubernetes.

Para estos casos de uso, puedes usarOpenTelemetry, que es una biblioteca de código abierto que puede agregar instrumentación a aplicaciones de microservicios distribuidas para recopilar registros, métricas y registros en una amplia variedad de lenguajes, plataformas y entornos.

Información sobre los seguimientos, los intervalos y el contexto

El concepto de seguimiento distribuido se describe en el artículo de investigación de Dapper publicado por Google. Como se describe en el artículo, se muestran cinco intervalos en un seguimiento en el siguiente diagrama.

Seguimiento distribuido con cinco intervalos en un seguimiento

Un seguimiento es el total de información que describe cómo un sistema distribuido responde a una solicitud del usuario. Los seguimientos están compuestos por intervalos, cada uno de los cuales representa un par de solicitud y respuesta específico que está involucrado en la entrega de la solicitud del usuario. En el intervalo superior, se describe la latencia como la observa el usuario final. En cada uno de los intervalos secundarios, se describe cómo se llamó y respondió a un servicio determinado en el sistema distribuido, con información de latencia capturada para cada uno.

El diagrama muestra una sola solicitud al frontend que realiza dos solicitudes al backend. La segunda llamada al backend requiere dos llamadas auxiliares para completarse. Cada llamada está etiquetada con el ID de su intervalo y el ID del intervalo superior.

Un desafío que presenta el seguimiento en sistemas distribuidos es que la información sobre la solicitud de frontend original no se envía de forma automática o inherente cuando se realizan solicitudes posteriores a varios servicios de backend.

Con algunas herramientas (por ejemplo, en el lenguaje Go), puedes realizar solicitudes con contexto: la dirección IP del clúster y las credenciales. OpenTelemetry extiende el concepto del contexto para incluir contexto de intervalo, lo que significa que la información adicional se carga en el encabezado HTTP. La información sobre el intervalo superior se puede incluir en cada solicitud posterior. Luego, puedes adjuntar intervalos secundarios para redactar el seguimiento general, de modo que puedas ver cómo la solicitud del usuario recorrió el sistema y, al final, se entregó al usuario.

Implementación

Para implementar esta arquitectura, consulta Implementa el seguimiento distribuido para observar la latencia de los microservicios.

¿Qué sigue?