Seguimiento distribuido: pasado, presente y futuro

El rastreo distribuido es un tema divisivo. Una vez que el decano de cada KubeCon , se esperaba que la tecnología revolucionara la observabilidad.

Avance rápido 5 años, la exageración ha disminuido un poco, se habla mucho más sobre el dolor y la adopción es moderada. Mientras tanto, sigue habiendo una actividad constante en torno a la expansión y estandarización de la tecnología: Open Telemetry (basada en OpenTracing) es el segundo proyecto CNCF más grande después de Kubernetes. Entonces, ¿cuál es el trato con el rastreo distribuido? ¿Debe uno implementarlo de inmediato o esperar y observar?

En este artículo, exploremos el rastreo distribuido en profundidad.

1. ¿Qué tiene de especial Distributed Tracing y por qué lo necesitamos?
2. ¿Cuáles son los problemas con el rastreo distribuido en la actualidad?
3. ¿Cuáles son los próximos desarrollos y cómo abordan los desafíos existentes?

Introducción: cómo funciona el rastreo distribuido

Para los no iniciados, Distributed Tracing es una tecnología que nos permite rastrear una sola solicitud a medida que atraviesa varios componentes/microservicios diferentes de un entorno distribuido. Cada llamada de red realizada en la ruta de la solicitud se captura y representa como un lapso.

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

Cómo un seguimiento distribuido representa una ruta de solicitud

Por qué necesitamos el rastreo distribuido en primer lugar

El rastreo distribuido es único porque se enfoca en una solicitud como unidad de observabilidad. En una plataforma de monitoreo/métrica, un componente (por ejemplo, un servicio, host) es la unidad fundamental que se observa. Uno puede hacer preguntas a estas plataformas sobre el comportamiento de esta unidad en su conjunto, a lo largo del tiempo. Por ejemplo, ¿cuál es la tasa de estado/rendimiento/error de este servicio en un período de tiempo específico?

Con los registros, la unidad fundamental que se observa es un evento ; por ejemplo, cada vez que ocurre un evento durante la ejecución del código, se imprime alguna información. Estos "eventos" son definidos subjetivamente por los desarrolladores mientras escriben el código. El desafío con los registros es que todos están separados, con cada componente imprimiendo su propia forma de mensajes de registro de forma aislada, sin una forma fácil de conectarlos para que tengan sentido.

Por el contrario, con el rastreo distribuido, lo que se observa es una sola solicitud, ya que atraviesa varios componentes. Esto nos permite hacer preguntas sobre el sistema distribuido como un todo y comprender qué ocurrió en qué lugar de un sistema interconectado complejo.

El caso básico para el rastreo distribuido radica en el argumento de que esta orientación en torno a las solicitudes es la más cercana a la experiencia del usuario final . Y como resultado, también es el más intuitivo sobre cómo nos gustaría examinar y solucionar problemas de arquitecturas distribuidas.

La evolución del rastreo distribuido

Distributed Tracing ha aumentado en importancia debido a la adopción generalizada de arquitecturas de software distribuidas en la última década.

La arquitectura moderna basada en microservicios es una evolución de la historia de crecimiento de Internet de finales de los 90, cuando se hizo común el uso de sistemas de solicitud y respuesta .

"Con finales de los 90 y el crecimiento explosivo de Internet, llegó la enorme proliferación de sistemas de solicitud y respuesta , como sitios web de dos niveles, con una interfaz de servidor web y un backend de base de datos... Las solicitudes fueron una nueva dimensión para el razonamiento sobre los sistemas. , ortogonal a cualquier máquina o proceso en conjunto".

- Seguimiento distribuido en la práctica, O'Reilly Media

En estas arquitecturas de microservicios, cada solicitud individual termina llegando a muchos (10 o incluso 100 de microservicios), realizando varias llamadas de red en el medio. Consulte a continuación la arquitectura de microservicios de Uber, que tiene más de 3000 servicios.

Arquitectura de microservicios de Uber de 2018. Fuente: https://www.uber.com/en-IN/blog/microservice-architecture/

En sistemas tan complejos, el rastreo distribuido se vuelve crítico para cualquier forma de resolución de problemas. Como resultado, Distributed Tracing fue promovido por grandes empresas que fueron las primeras en adoptar entornos grandes, complejos y distribuidos.

• El artículo Dapper de Google publicado en 2010 fue el comienzo del rastreo distribuido

  
  

• En los años siguientes, dos empresas más abrieron sus propios sistemas de rastreo distribuido (Zipkin de código abierto de Twitter en 2012 y Jaeger de código abierto de Uber en 2017). Zipkin y Jaeger continúan estando entre las herramientas de rastreo distribuidas más populares incluso hoy en día.

  
  

• Desde 2016, ha habido un esfuerzo significativo para estandarizar el seguimiento distribuido entre componentes a través del proyecto OpenTracing. OpenTracing finalmente se convirtió en OpenTelemetry en 2019. OpenTelemetry es muy popular y tiene miles de colaboradores en todo el mundo.

  
  

• Ahora Distributed Tracing es ampliamente considerado como el tercer "pilar" de la observabilidad junto con las métricas y los registros. La mayoría de los principales actores de monitoreo y observabilidad brindan herramientas de rastreo distribuidas como parte de sus productos.

Estado del rastreo distribuido: teoría frente a realidad

Sin embargo, a pesar de la promesa, el entusiasmo y el esfuerzo de la comunidad, la adopción del rastreo distribuido en la actualidad es de aproximadamente ~25 %. No es raro encontrar empresas en arquitecturas de microservicios que se las arreglan con registros y métricas, aunque claramente necesitan un seguimiento distribuido.

Al mismo tiempo, los errores de producción de tiempo medio para resolver están aumentando en el mundo actual. El 73% de las empresas informan que hoy en día se tarda más de una hora en resolver los problemas de producción.

Pregúntele a cualquier desarrollador cuáles son los momentos más dolorosos de su vida y le hablarán sobre el tiempo que dedicaron a depurar un error Sev-1 en producción con lo que parecían unos cientos de personas respirándoles por la nuca.

Entonces, parece que cualquier empresa que se preocupe por su MTTR (que es casi todas las empresas) debería usar el rastreo distribuido, y la adopción debería haberse disparado en este entorno. Pero los números reales no lo respaldan, entonces, ¿qué pasa?

Desafíos con el rastreo distribuido hoy

Hay varios problemas con el rastreo distribuido hoy en día que las empresas tienen que superar para obtener valor, todos los cuales no se discuten tan ampliamente en la narrativa principal.

1. ¡La implementación es difícil!

Para implementar el rastreo distribuido en un servicio hoy, necesitamos hacer un cambio de código y un lanzamiento. Si bien hacer cambios en el código es una solicitud bastante común de observabilidad, el desafío específico con el seguimiento distribuido es este: cada servicio o componente debe instrumentarse para obtener un seguimiento distribuido, o el seguimiento se rompe.

Uno no puede simplemente comenzar con un solo servicio, como puede hacerlo con el monitoreo o el registro, y obtener valor. El rastreo distribuido requiere instrumentación en un conjunto colectivo de servicios para generar rastreos utilizables.

Esto requiere la coordinación entre varios equipos y propietarios de servicios para realizar cambios en sus servicios. Por lo tanto, se convierte en un problema organizacional: imagine que cientos de equipos instrumenten sus servicios durante varios meses antes de que pueda obtener valor.

Este es el mayor desafío con el rastreo distribuido en la actualidad.

2. Necesidad de decisiones de muestreo complejas

Además, el volumen de datos de seguimiento generado por Distributed Tracing puede ser abrumador. Imagine cientos de servicios, cada uno de los cuales emite una pequeña cantidad de datos de seguimiento para cada solicitud . Esto va a ser millones de solicitudes por segundo y hace que el rastreo distribuido sea costoso tanto en términos de almacenamiento como de ancho de banda de la red.

Si bien el registro también hace lo mismo (y emite más datos por solicitud, que luego son administrados por herramientas de agregación masiva de registros), la diferencia es que la mayoría de las empresas ya tienen registro. Introducir un tipo de datos más que va a ser casi tan voluminoso como el registro es una tarea abrumadora y probablemente duplique el gasto.

Para manejar este problema de costo, todos los sistemas de rastreo distribuidos hoy en día usan muestreo y registran solo un subconjunto de rastreos. Las tasas de muestreo comunes en la práctica hoy en día están entre 0,1% y 2%. La razón es que incluso el 1% de las muestras es suficiente para dar una imagen agregada decente de dónde están los cuellos de botella en el rendimiento.

La mayoría de las plataformas actuales permiten a los clientes elegir su estrategia de muestreo y hacer sus propias compensaciones de visibilidad de costos. Sin embargo, este proceso de decisión se suma a la ya compleja sobrecarga de instrumentar y administrar un sistema de rastreo distribuido.

3. Pero el muestreo disminuye significativamente el valor

Supongamos que una empresa se esfuerza por instrumentar cada servicio/componente y luego decide la estrategia de muestreo para asegurarse de no arruinarse.

¿Y ahora qué? ¿Deberíamos esperar que el MTTR caiga drásticamente? No, porque los desarrolladores no pueden usar el seguimiento distribuido para solucionar problemas, debido al muestreo.

Imagine la experiencia de un desarrollador: "No puedo encontrar el problema que sé que está ahí. Generé el error, pero no puedo encontrar el seguimiento correspondiente".

¿Así que lo que ocurre? Los desarrolladores dejan de confiar en la calidad de los datos de seguimiento distribuidos y vuelven a sus métodos habituales para la depuración/solución de problemas (es decir, el uso de registros)

4. El uso del desarrollador es de baja frecuencia

Dadas estas limitaciones, hoy Distributed Tracing se vende principalmente como una forma de solucionar problemas de rendimiento .

Recuerde que un seguimiento distribuido básico realmente solo nos dice quién llamó a quién y cuánto tiempo tomó cada lapso. Los seguimientos distribuidos no nos dicen qué sucedió dentro del servicio que causó el error o la latencia alta. Para eso, los desarrolladores todavía tienen que mirar el mensaje de registro y/o reproducir el problema localmente para depurar.

En una empresa típica, es probable que los problemas de rendimiento sean <10 % del total. Entonces, en realidad, el rastreo distribuido solo es útil para este pequeño segmento de problemas.

El desarrollador promedio que envía y es propietario de un servicio usa una herramienta de rastreo distribuido quizás 2 o 3 veces al año.

Impacto de todos estos desafíos

En resumen:

1. El rastreo distribuido es difícil de implementar
2. Distributed Tracing necesita un muestreo extenso para controlar los costos
3. Pero el muestreo reduce considerablemente el valor.
4. Como resultado, los desarrolladores solo utilizan el seguimiento para casos de uso de rendimiento excepcionales.

Todo esto hace que el caso de RoI para el rastreo distribuido sea bastante confuso.

En un ciclo de exageración típico, lo que podemos decir es que ya hemos pasado la etapa de expectativas infladas y la desilusión está comenzando a asentarse.

Sin embargo, si pensamos en términos de estado final, si el futuro de los sistemas informáticos es distribuido, entonces el rastreo distribuido es naturalmente el vector más fundamental para la observabilidad. En ese mundo, cualquier empresa con una arquitectura distribuida utiliza el rastreo como el mecanismo principal para solucionar cualquier problema que ocurra en la producción (verdadera "observabilidad") frente al monitoreo pasivo de los sistemas que tenemos hoy.

Sin embargo, antes de que podamos llegar a ese estado final, necesitaremos varias mejoras sobre el status quo. La buena noticia es que gran parte de esto ya está en marcha. Veamos cada uno de ellos. Entonces, ¿qué podemos esperar ver en el futuro?

Futuro del rastreo distribuido

Instrumentación instantánea sin cambios de código

Imagine colocar un agente y poder cubrir un sistema distribuido completo (todos los servicios, componentes) de una sola vez sin cambios de código.

Esto parece realistamente posible en los próximos 2-3 años.

Las bibliotecas de instrumentación automática de OpenTelemetry ya permiten esto para algunos lenguajes de programación (sin embargo, se quedan cortos en lenguajes compilados como Go). Paralelamente, tecnologías como eBPF están evolucionando para permitir la instrumentación de todo el sistema sin cambios de código . Entre los dos, podemos esperar con seguridad que el problema de la instrumentación se resuelva en unos pocos años.

El muestreo da paso a la selección basada en IA de solicitudes de interés

En un mundo LLM, el muestreo aleatorio comienza a parecer una reliquia de la edad oscura. Idealmente, deberíamos poder ver el 100 % de los rastros, identificar cualquier cosa que parezca anómala y almacenarla para examinarla en el futuro. No más muestreo aleatorio.

Si lo pensamos bien, realmente no nos importa el ~95% de "solicitudes felices". Solo nos preocupamos por el ~5 % de los seguimientos anómalos: errores, excepciones, alta latencia o algún tipo de error leve. Entonces, solo necesitamos una forma de ver el 100% y seleccionar el 5% interesante.

Hay mecanismos como el muestreo basado en la cola que apuntan a hacer esto hoy. En el muestreo basado en la cola, el sistema espera hasta que se hayan completado todos los tramos de una solicitud y luego, basándose en el seguimiento completo, decide si debe retenerse.

El principal desafío con el muestreo basado en la cola es que tiene que almacenar todos los tramos de un seguimiento hasta que se completa la solicitud completa y luego decidir si desea conservar o descartar el seguimiento. Esto significa que almacenamos cada solicitud individual, con todos los lapsos, durante un cierto período (hasta que se completa la solicitud); esto requiere una arquitectura de datos separada con componentes para balanceo de carga, almacenamiento y procesamiento, lo cual es muy complejo y costoso.

OpenTelemetry tiene un colector de muestreo basado en la cola , sin embargo, aún no está maduro y tiene varios desafíos de escalabilidad (debido al problema mencionado anteriormente). Mientras tanto, varias empresas, incluida ZeroK.ai , están trabajando en el uso de IA para hacer que la detección de anomalías sea eficiente y escalable.

Con el rápido ritmo de desarrollo en este espacio, podemos esperar razonablemente que este problema también se resuelva en los próximos 3 a 5 años.

La aparición de rastros distribuidos "ricos" que permiten toda la depuración

Un verdadero salto hacia la próxima generación de rastreo será cuando el rastreo evolucione del ámbito de "solo problemas de rendimiento" a "todos los problemas". Es entonces cuando se desata el verdadero poder del rastreo distribuido.

Para que esto sea posible, cada rastro debe tener un contexto rico.

Imagine un escenario en el que cada tramo de cada seguimiento tenga:

• Cargas útiles de solicitud y respuesta (con enmascaramiento de PII)

• Apilar seguimientos para cualquier excepción

• Registros

• Eventos de Kubernetes

• Estados de pod

• Y cualquier otra cosa que ocurrió a lo largo de ese lapso

  
  

Todo en un flujo integrado y continuo.

E imagine si el rastro que está buscando es muy fácil de encontrar: no hay brechas de datos relacionadas con el muestreo, los problemas se deduplican y agrupan, y se pueden filtrar en varias dimensiones.

Entonces, esto es todo lo que un desarrollador necesita para depurar cualquier problema de software. Y potencialmente, todo lo que un modelo de IA necesita para diagnosticar y señalar a un desarrollador lo que está fallando.

En este mundo, la traza se convierte en el eje principal de la observabilidad, en sustitución del registro . Así es como podría verse el estado final del rastreo distribuido: aunque todavía no está aquí, es visible desde donde estamos hoy.

La principal barrera para hacer esto posible es la explosión en el volumen de datos que causará el almacenamiento de todos estos datos de contexto. Necesitaremos una profunda innovación en el procesamiento de datos y las arquitecturas de almacenamiento para que esto sea posible. Todavía es pronto y tenemos que esperar y ver qué sucede aquí.

Resumen

En resumen, Distributed Tracing es una vista necesaria e intuitiva para poder observar arquitecturas de aplicaciones distribuidas en producción.

La primera generación de rastreo distribuido, aunque prometedora, se ha visto acosada por varios desafíos que han dificultado que las empresas obtengan valor del rastreo, lo que ha obstaculizado un poco la adopción.

Sin embargo, se están produciendo varios desarrollos emocionantes en el espacio que se espera que hagan que el rastreo sea más fácil, más simple y más poderoso que lo que tenemos hoy, haciendo que la observabilidad sea más fluida en el futuro.