¿Qué es el rastreo distribuido (conocido como Tracing) y cuáles son sus principales componentes? Y, más importante aún: ¿por qué deberías invertir tiempo en integrar el rastreo distribuido en tu stack tecnológico? Aunque hay muchos motivos, en este post vamos a tratar los más significativos.
Revela las dependencias entre servicios
La decisión estratégica está tomada: tu empresa empezó a migrar a una arquitectura distribuida, la cantidad de componentes comenzó a crecer y la capacidad de entender la arquitectura de la organización disminuyó. Con el rastreo distribuido, puedes seguir el camino de una solicitud a medida que atraviesa un sistema complejo. Algunas herramientas incluso calculan y dibujan un grafo de dependencias completo. Puede ser útil tener una visión general de tu arquitectura y profundizar para entender mejor las dependencias.
Descubre la latencia de los componentes a lo largo del camino
Puedes descubrir la latencia monitoreando las solicitudes de los servicios de borde (edge services) con sistemas de monitoreo. OK, recibiste la alerta, pero ahora necesitas descubrir qué componente hace que esa solicitud específica supere el Service Level Objective (SLO). Para eso existe exactamente el rastreo distribuido: para ubicar los componentes del camino que son cuellos de botella o que pueden causar fallas.
Análisis de causa raíz
Imagina el siguiente escenario – te despierta una alerta, son las 2 de la mañana y una solicitud que involucra 5 microservicios distintos está fallando una y otra vez. Buscas desesperadamente en los logs, todavía intentando abrir los ojos frente a la pantalla ultrabrillante, en busca de errores a la hora de la alerta, pero el flujo de datos es demasiado gigantesco para descubrir con precisión y rapidez qué pasó. Está tardando demasiado. Pues bien: con el rastreo distribuido es posible encontrar el primer servicio que falló, obtener los logs de esa falla y algunas cosas más (según la implementación de rastreo del sistema).
Recolecta eventos durante la solicitud
Para ayudar en el proceso de debug, es posible agregar elementos al rastreo. Por ejemplo, puedes agregar al rastreo todas las feature flags evaluadas para que, en caso de falla, sepas exactamente qué flags se evaluaron en cada uno de los servicios del camino de la solicitud.
Pero, ¿qué es exactamente una herramienta de rastreo?
Empecemos por lo básico, por el origen de todas las soluciones de rastreo distribuido. Aunque antes ya existían algunas soluciones de rastreo distribuido, el artículo titulado Google Dapper (2010), de 14 páginas, es la piedra angular del rastreo distribuido, por así decirlo. El documento explica cómo Google desarrolló una herramienta de rastreo de nivel productivo, con 3 objetivos principales:
1) Baja sobrecarga – El sistema de rastreo debe tener un impacto insignificante en el rendimiento de los servicios en ejecución. En algunos servicios altamente optimizados, incluso pequeñas sobrecargas de monitoreo se notan con facilidad. Por ejemplo, una sola query de búsqueda de Google recorre miles de máquinas y servicios; por eso, Google no puede permitir un aumento que no sea despreciable en términos de impacto en el rendimiento para cada una de esas solicitudes.
2) Transparencia a nivel de aplicación – El rastreo no debe exigir la colaboración activa de los programadores, porque puede ser frágil y consumir el valioso (y costoso) tiempo de los programadores para aprenderlo.
3) Escalabilidad – Debe soportar la escala de Google por al menos algunos años.
También hay un requisito que indica que los datos de rastreo estarán disponibles minutos después de la solicitud.
Instrumentación de servicios y terminología
Dapper también introdujo una terminología. Puede variar entre las soluciones disponibles hoy en el mercado, pero estas son las ideas fundamentales en la mayoría de las soluciones sucesoras de Dapper:
Rastreo (Trace): la descripción de una transacción a medida que se mueve por un sistema distribuido.
Span: una operación con nombre y cronometrada que representa una parte del flujo de trabajo. Los spans aceptan tags de clave-valor, así como logs estructurados, con marca de tiempo y granulares, adjuntos a la instancia específica del span.
(Span) Context: la información de identificación del rastreo que acompaña a la transacción distribuida, incluso cuando pasa de servicio en servicio por la red o a través de un bus de mensajes. El span context contiene el identificador del rastreo, el span identifier y cualquier otro dato que el sistema de rastreo necesite propagar al servicio downstream.
Instrumentación (Instrumentation): la instrumentación es el proceso mediante el cual se extiende el código de la aplicación para capturar y reportar spans de rastreo de las operaciones de interés.
Anotaciones (annotations, a veces llamadas baggage): permiten al desarrollador enriquecer el rastreo con datos definidos por el usuario; pueden usarse para guardar contadores, logs relevantes y cualquier dato que ayude a investigar un incidente.
El contexto de rastreo se serializa y se transmite durante la llamada entre los servicios instrumentados, ya sea por RPC, mensaje de evento, SMTP o cualquier otro canal de comunicación que el desarrollador tenga en mente, después de que el cliente envía los datos de rastreo al servidor (por ejemplo, en un header HTTP en llamadas REST). El servidor deserializa el span e inicia uno nuevo que apunta a su span padre, el span recibido del cliente.
La evolución de Dapper
Ahora que pusimos en contexto la historia de la herramienta de rastreo distribuido, vamos a los descendientes disponibles hoy en el mercado – muchos de ellos comparten el mismo concepto o la misma solución que Dapper.
Las soluciones actuales se pueden dividir en 2 grupos:
Soluciones open source:
Soluciones empresariales:
¿Quieres empezar con tracing sin convertirlo en un proyecto de seis meses? El equipo de Elven te ayuda a elegir la instrumentación adecuada para tu escenario y a poner los primeros traces en producción.
El estándar de hoy se llama OpenTelemetry
Cuando se escribió este texto, elegir rastreo distribuido también significaba elegir un agente propietario — y reinstrumentar todo al cambiar de herramienta. OpenTelemetry cerró esa discusión: es un proyecto de la CNCF que estandariza la recolección de traces, métricas y logs, y hoy lo soporta prácticamente todo backend de observabilidad, Elven incluida.
En la práctica, esto cambia el orden de las decisiones. Instrumenta primero con OpenTelemetry y elige el backend después — y conserva la libertad de cambiarlo sin rehacer el trabajo de instrumentación.
¿Ya instrumentaste con OpenTelemetry y buscas un backend para tus datos? Habla con el equipo de Elven.
