Prácticas recomendadas de trazado distribuido

Best practices for distributed tracing

El seguimiento distribuido ahora es un elemento básico en el conjunto de observabilidad moderno. Con el cambio a microservicios, necesitábamos una nueva forma de observar cómo interactúan nuestros servicios. El seguimiento distribuido proporciona esa vista al permitirnos hacer un seguimiento de las solicitudes, es decir, trazar una solicitud a través de los componentes de nuestro sistema distribuido. Hoy en día, el seguimiento distribuido se utiliza para identificar cuellos de botella de rendimiento, solucionar problemas y comprender cómo interactúan nuestros sistemas en producción.

Sin embargo, implementar el seguimiento distribuido es complejo y cuánto valor obtienen los equipos de ello depende en gran medida de cómo se implemente. Los aspectos mecánicos de la implementación, como qué componentes están instrumentados, la tasa de muestreo y la calidad de la visualización de las trazas, influyen en el valor que las empresas obtienen del seguimiento, lo que a su vez influye en la adopción por parte de los desarrolladores. Además, este espacio está en constante evolución, con nuevas herramientas y técnicas que surgen todo el tiempo.

En este artículo, examinaremos las mejores prácticas para el seguimiento distribuido en 2023.

¿Qué es el seguimiento distribuido?

El seguimiento distribuido se refiere a un mecanismo que nos permite rastrear una sola solicitud a medida que atraviesa múltiples servicios en un entorno distribuido.

Por qué necesitamos el seguimiento distribuido.

Para habilitar esto, las herramientas de seguimiento distribuido insertan un contexto de traza único (ID de traza) en la cabecera de cada solicitud e implementan mecanismos para garantizar que el contexto de traza se propague a lo largo de la ruta de la solicitud.

Cada llamada de red realizada en la ruta de la solicitud se captura y se representa como un span. Un span es una unidad básica de una traza, representa un evento único dentro de la traza y una traza puede tener uno o varios spans. Un span consta de mensajes de registro, datos relacionados con el tiempo y otros atributos para proporcionar información sobre la operación que rastrea.

Anatomía de una traza distribuida.

A través de su vista única, el seguimiento distribuido desbloquea varios casos de uso nuevos o mejora los casos de uso existentes. Nos permite comprender las interdependencias de los servicios (por ejemplo, quién llama a mi servicio), identificar cuellos de botella de rendimiento (¿qué llamada específica a la base de datos está degradando mi latencia?), identificar rápidamente los puntos de falla para la depuración (¿qué API está causando este problema 500?) y también tener SLO más granulares.

Componentes de un sistema de seguimiento distribuido

Para implementar cualquier sistema de seguimiento distribuido, instalamos cuatro componentes distintos:

Biblioteca de instrumentación
Colector (preprocesador)
Almacenamiento en backend
Capa de visualización

Hoy en día, hay varias opciones disponibles para cada uno de estos componentes; se puede utilizar una única plataforma que haga los cuatro anteriores o se puede armar un marco de seguimiento distribuido utilizando diferentes soluciones para diferentes componentes.

Componentes de un sistema de trazado.

Biblioteca de instrumentación

Esta es la parte integrada en cada aplicación o servicio. Cuando una aplicación se ejecuta, la biblioteca de instrumentación se asegura de que se agreguen los ID de traza en cada solicitud o que el contexto de traza (ID de traza) se propague al siguiente span. La biblioteca envía estos datos a un colector.

Colector

El colector actúa como intermediario entre la biblioteca de instrumentación y el almacenamiento en backend. Recopila trazas, las procesa (por ejemplo, agregando spans, muestreo) y las prepara para el almacenamiento.

Almacenamiento en backend

El almacenamiento en backend persiste e indexa los datos de traza. Típicamente utiliza un sistema de almacenamiento distribuido capaz de manejar grandes volúmenes de datos y permite consultas y recuperación eficientes.

Capa de visualización

Esta es la interfaz de usuario del sistema de seguimiento distribuido. Permite a los desarrolladores y operadores interactuar con los datos de traza. Esta capa proporciona herramientas para consultar, buscar y filtrar datos de traza según diversos criterios. Presenta los datos de traza de manera visualmente significativa, a menudo como un gráfico de traza o una línea de tiempo, lo que permite a los usuarios analizar la secuencia de eventos e identificar cuellos de botella o problemas.

Implementar sistemas de seguimiento distribuido es complejo

Aunque hay varios beneficios, implementar sistemas de seguimiento distribuido (especialmente de manera efectiva) aún no es una tarea fácil o “resuelta”. Requiere que el equipo de implementación tome varias decisiones y esas decisiones tienen un impacto significativo en la cantidad de valor que el resto del equipo de ingeniería obtiene del seguimiento. No es raro que las empresas implementen el seguimiento distribuido y paguen medio millón de dólares al año, solo para que el desarrollador promedio lo use solo dos veces al año. A continuación, se presentan algunas mejores prácticas sobre cómo implementar el seguimiento de manera efectiva.

Mejores prácticas para el seguimiento distribuido

Elegir OTel para Instrumentación

Existen varios marcos de trazabilidad de código abierto populares, como OpenTelemetry, Jaeger y Zipkin. Hoy, en 2023, OTel se ha convertido en una elección bastante obvia por las siguientes razones:

Amplia cobertura: OTel tiene bibliotecas de instrumentación y SDK para diferentes lenguajes de programación y marcos, y ahora tiene una amplia cobertura. Consulta aquí para ver qué soporta OTel.
Neutro respecto al proveedor: Ahora, la mayoría de los proveedores admiten la instrumentación de OTel. Por lo tanto, puedes instrumentar con OTel y enviar los datos a cualquier proveedor de tu elección. Tendrás interoperabilidad y portabilidad de proveedores a lo largo del tiempo (si decides cambiar de proveedor). Esta es una lista de proveedores de observabilidad que admiten nativamente los datos de OTel, y aquí hay un registro de bibliotecas y complementos para conectar OTel con otros proveedores.
Madurez y estabilidad: OTel ha estado madurando durante varios años, con un amplio apoyo de la comunidad. Ahora es el segundo proyecto más grande en el ecosistema de CNCF en términos de contribuyentes, después de Kubernetes. La sólida comunidad garantiza que siga evolucionando y agregando soporte para nuevas tecnologías rápidamente.

Aprovechar la Instrumentación Automática Cuando Sea Posible

OpenTelemetry proporciona dos formas de instrumentar código en aplicaciones y componentes: instrumentación manual e instrumentación automática. Si estás en Kubernetes y la mayoría de tus servicios están en Java, NodeJS o Python, aprovecha la instrumentación automática extensivamente, ya que reduce el esfuerzo de implementación.

Instrumentación manual

El código de OTel debe agregarse a la aplicación por parte del desarrollador, por lo que esto requiere un cambio de código. La instrumentación manual permite una mayor personalización en términos de spans y trazas. La mayoría de los lenguajes están cubiertos para la instrumentación manual: C++, .NET, Go, Java, Python, etc. Consulta aquí la lista más reciente.

Instrumentación automática

Esta es una forma de instrumentar aplicaciones/servicios sin realizar cambios en el código ni tener que recompilar la aplicación. Un agente inteligente se adjunta a una aplicación, lee su actividad y extrae las trazas. Esto es posible si estás en Kubernetes. Actualmente, OTel admite instrumentación automática para Java, NodeJS, Python, etc. (consulta aquí la lista más reciente). La personalización de spans y trazas es limitada con la instrumentación automática (en comparación con la instrumentación manual), pero es suficiente para la mayoría de los casos de uso.

Comienza con los Caminos Críticos y Expándete a Partir de Ahí

Es impráctico instrumentar cada servicio/componente en sistemas distribuidos grandes de una sola vez, por lo que es importante elegir cuidadosamente qué caminos instrumentar primero y cómo expandirse a partir de ahí. Algunas pautas/principios a seguir aquí:

Comienza desde el Exterior y Avanza hacia el Interior

Generalmente, es mejor comenzar desde el exterior y avanzar hacia el interior. Esto significa empezar en los puntos donde una solicitud ingresa a tu aplicación, solicitudes entrantes de usuarios o clientes externos. Al comenzar en los puntos de entrada, es más fácil obtener una vista holística de cómo fluyen las solicitudes a través del sistema.

Elige los Caminos más Críticos del Sistema y Instrumentalos Primero

La guía general es identificar los caminos de solicitud más importantes en tu sistema; estos pueden ser los que se acceden con mayor frecuencia o que tienen un impacto más significativo en el monitoreo del rendimiento de la aplicación en general. Comienza instrumentando estos caminos críticos primero para poder demostrar el valor a la organización en general y luego expandirse a partir de ahí.

Siempre Instrumenta los Caminos de Solicitud de Extremo a Extremo para que una Trazabilidad no se Rompa

Cualquier camino que elijas, asegúrate de que esté instrumentado de extremo a extremo, lo que significa que cada servicio y componente en el camino de solicitud está instrumentado para propagar el contexto (ID de traza) y generar spans según sea necesario. Cualquier brecha resulta en trazas incompletas o rotas, lo que anula el esfuerzo invertido para instrumentar servicios aguas arriba.

Sé Intencionado con el Muestreo

En el 99% de los casos, las empresas desean muestrear sus trazas. Esto se debe a que si almacenas cada traza, podrías estar almacenando y gestionando una gran cantidad de datos.

Pongamos un ejemplo. Supongamos que cada span ocupa 500 bytes (incluyendo etiquetas y registros). Si tu aplicación está atendiendo 2000 solicitudes por segundo y tiene 20 servicios diferentes, terminarás generando 20 MB de datos cada segundo, o 72 GB por hora, o 1 TB cada día, para una configuración simple de 20 servicios.

Por eso, la mayoría de las empresas acaban almacenando una muestra de las trazas distribuidas. Es importante seleccionar la estrategia de muestreo adecuada para seguir teniendo visibilidad sobre lo que te importa y al mismo tiempo tener control sobre los costos.

En términos generales, existen dos categorías de muestreo:

1. Muestreo de inicio o basado en la cabecera

Esta es una forma sencilla de decidir qué spans mantener antes de que se generen los spans para una solicitud determinada. Se llama muestreo basado en la cabecera, ya que la decisión se toma al principio o “cabeza” de la solicitud. A veces, se le conoce como muestreo imparcial cuando las decisiones se toman sin siquiera mirar la solicitud. Dentro del muestreo basado en la cabecera, hay varios mecanismos comúnmente utilizados, como los siguientes.

Muestreo probabilístico o de tasa fija: Selección aleatoria de un subconjunto de trazas para mantener en función de una tasa de muestreo fija, por ejemplo, 1%
Muestreo con límite de tasa: Establecer un límite fijo en el número de solicitudes a rastrear por unidad de tiempo. Por ejemplo, si el límite de tasa se establece en 100 solicitudes por minuto, solo se rastrearán las primeras 100 solicitudes de ese minuto.
Muestreo basado en prioridad: El muestreo basado en prioridad asigna diferentes prioridades a las solicitudes y la tasa de muestreo se ajusta en consecuencia. Las solicitudes con mayor prioridad (por ejemplo, transacciones críticas) tienen una tasa de muestreo más alta, mientras que las solicitudes de menor prioridad tienen una tasa más baja.

2. Muestreo basado en la cola

El muestreo basado en la cola es donde se toma la decisión de muestrear en función de las respuestas dentro de la traza, por ejemplo, latencia alta y errores. Este método garantiza que las solicitudes “interesantes” se rastreen, incluso cuando las tasas de muestreo generales son bajas. Sin embargo, el muestreo basado en la cola es mucho más difícil de implementar (en comparación con otros métodos más simples), ya que se tendría que almacenar en un búfer todas las trazas hasta que se reciba la respuesta. Esta guía cubre el muestreo basado en la cola con cierta profundidad.

La mayoría de las organizaciones suelen recurrir a un mecanismo de muestreo probabilístico basado en la cabecera, con una tasa de muestreo del 1-3%. Consulta aquí cómo configurar el muestreo de tasa fija en OTel.

Sé selectivo al implementar el rastreo personalizado

El rastreo distribuido es poderoso porque nos permite informar sobre spans de rastreo personalizados. Los spans personalizados nos permiten enriquecer las trazas distribuidas con información adicional específica del dominio, lo que hace que los datos de rastreo sean más significativos.

Es posible capturar y registrar estados de error como parte de un span o crear spans secundarios que describan aún más el funcionamiento de un servicio. Los spans etiquetados de manera efectiva pueden reducir significativamente la cantidad de declaraciones de registro requeridas por tu código.

En el contexto del rastreo, la amplitud se refiere al número de servicios o componentes que se están instrumentando, mientras que la profundidad se refiere al nivel de detalle capturado dentro de cada span. Encontrar el equilibrio adecuado entre amplitud y profundidad es crucial para implementar un mecanismo de rastreo efectivo y al mismo tiempo controlar los costos.

En general, es una buena idea ser lo más amplio posible y ser selectivo en los lugares donde profundizas.

Integra el rastreo con tus sistemas de monitoreo y registro

Asegúrate de conectar el rastreo con los sistemas de monitoreo y registro existentes para que sea más fácil para los desarrolladores correlacionar los tres conjuntos de datos durante la solución de problemas. Por lo general, esto se hace a través de:

Inyección de registros: Inyecta IDs de trazas/IDs de spans directamente en los registros utilizando frameworks o bibliotecas de registro. De esta manera, cada mensaje de registro tiene un traceID que se puede utilizar para consultar fácilmente los registros específicos.
Anotación de métricas: Se pueden incluir etiquetas o etiquetas relacionadas con la traza al registrar métricas. Estas etiquetas pueden ser traceIDs, nombres de spans u otros metadatos específicos de la traza. Esto permite a los desarrolladores filtrar y agregar métricas en torno a los datos de rastreo y facilita la comprensión de los sistemas distribuidos.

Protocolos como OpenTelemetry ya te permiten hacer esto fácilmente.

Elige una interfaz de visualización de trazas moderna

Hay una diferencia significativa entre las soluciones en términos de la interfaz de usuario. Después de recopilar datos de rastreo, es necesario poder visualizarlos. Una buena visualización de trazas te permitirá ver el flujo de las solicitudes de rastreo a través de un sistema e identificar cuellos de botella de rendimiento.

Sin embargo, no todas las soluciones de rastreo proporcionan una forma intuitiva y fácil de usar para visualizar y analizar estos datos directamente. Algunas herramientas sobresalen en la recopilación y almacenamiento de datos de rastreo pero tienen una visualización básica (por ejemplo, Jaeger, Zipkin, AWS XRay), mientras que otras se centran más en proporcionar información a partir de los datos de rastreo y, como resultado, han invertido en visualización y análisis más sofisticados (por ejemplo, Honeycomb, Lighstep, Helios).

Las buenas herramientas de visualización deben ofrecer paneles prediseñados que automáticamente te proporcionen mapas de dependencia de servicios, visualizaciones de seguimiento Gantt y waterfall, y permitan realizar consultas detalladas y filtrado de seguimientos. Este artículo ofrece una perspectiva bien fundamentada sobre la visualización en el seguimiento distribuido.

Explora herramientas de próxima generación que combinan IA y seguimiento

Con OTel madurando rápidamente, la instrumentación se ha vuelto bastante estandarizada. De manera similar, el almacenamiento y la consulta también se han vuelto ampliamente comoditizados en la industria de la observabilidad en los últimos años. Hoy en día, hay alguna diferenciación en la capa de visualización y análisis, aunque incluso eso no es significativo.

Existe una clase emergente de soluciones que utilizan IA en los datos de seguimiento distribuido para generar inferencias sobre las causas de los problemas. Estas soluciones también tienen la pila de seguimiento más moderna y hacen que la implementación y gestión sean mucho más sencillas. Por ejemplo, soluciones como ZeroK te permiten hacer lo siguiente:

Instalar el seguimiento distribuido en todos tus componentes de una sola vez sin ningún cambio de código; todos los servicios, bases de datos y colas se cubren de inmediato utilizando OTel y eBPF.
Eliminan la necesidad de muestreo: procesan el 100% de los seguimientos y utilizan IA para identificar automáticamente los que son anómalos o “interesantes” para almacenar (por ejemplo, seguimientos con errores, seguimientos de alta latencia).
Añaden a los seguimientos anómalos un contexto adicional (por ejemplo, registros) para ayudar en la depuración según sea necesario.
Aplican modelos de aprendizaje automático a estos seguimientos para identificar automáticamente las posibles causas de los problemas en producción.

Invierte en la incorporación de desarrolladores

Este es un factor a menudo pasado por alto pero crítico que impulsará el éxito del seguimiento distribuido en tu organización. Recuerda que el seguimiento distribuido es complejo y es difícil para los nuevos desarrolladores familiarizarse con cómo utilizarlo de manera efectiva. No es raro que las empresas tengan solo unos pocos usuarios avanzados que utilicen la plataforma de seguimiento, y eso solo un par de veces al trimestre.

Es necesario enseñar a los desarrolladores cómo interpretar los datos de seguimiento, comprender las relaciones entre diferentes microservicios y solucionar problemas utilizando herramientas de seguimiento distribuido. Deben recibir orientación sobre las mejores prácticas, como convenciones de nomenclatura consistentes, instrumentación adecuada y comprensión de la propagación del contexto de seguimiento. Planificar la incorporación de desarrolladores al seguimiento distribuido es una inversión estratégica. No solo acelera la integración del seguimiento en el sistema, sino que fomenta una cultura en la que los desarrolladores son participantes activos en la mejora continua de la visibilidad, confiabilidad y rendimiento del sistema.

Conclusión

Hemos analizado las mejores prácticas de seguimiento distribuido y lo que puedes hacer para que el proceso sea más fácil. El seguimiento distribuido ya no es una novedad; se ha convertido en una parte crucial de la pila de observabilidad.