Alejandría

Busca en Alejandría

Plataformas

Grafana Tempo

Backend de trazas distribuidas que permite seguir solicitudes entre servicios.

01

En pocas palabras

Backend de trazas distribuidas que permite seguir solicitudes entre servicios.

Qué problema resuelve

Latencias y fallos difíciles de localizar en recorridos con muchas dependencias.

Cuándo utilizarlo

Microservicios instrumentados. Ejemplo: descubrir qué llamada externa retrasa una compra.

02

De la idea a la práctica

Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

Recibe spans mediante protocolos compatibles y almacena trazas, utilizando almacenamiento de objetos en arquitecturas escalables. TraceQL permite investigar características de spans y recorridos.

Ejemplo de uso

Instrumentar API, cola y consumidor; buscar trazas lentas y localizar el span con mayor duración. Correlacionar servicio y trace_id con métricas y logs.

TraceQL

# Trazas del servicio de pagos que tardan más de 2 s
{ resource.service.name = "pagos" && duration > 2s }

# Spans con error HTTP 5xx
{ span.http.response.status_code >= 500 }

# Trazas donde el endpoint de pagos llama a PostgreSQL con una consulta lenta
{ name = "POST /v1/pagos" } >> { span.db.system = "postgresql" && duration > 500ms }

# Agregación: trazas con más de 3 spans de error
{ status = error } | count() > 3
Ámbito Ejemplos de atributos
resource. service.name, deployment.environment, k8s.pod.name
span. http.route, db.system, messaging.destination.name
Intrínsecos name, duration, status, kind

El operador >> (descendiente) y > (hijo directo) permiten buscar estructuras de llamada, algo que no se puede expresar con métricas.

Métricas a partir de trazas

El metrics-generator de Tempo produce:

  • Span metrics: tasa, errores y duración (RED) por servicio, operación y atributos elegidos.
  • Service graphs: mapa de dependencias entre servicios con latencias y errores.

Y las TraceQL metrics permiten consultas ad hoc como { resource.service.name = "pagos" } | quantile_over_time(duration, .95) by (span.http.route).

Muestreo

Estrategia Dónde Características
Head sampling En el SDK Barato; decide antes de saber si la traza es interesante
Tail sampling En el Collector o Alloy Conserva todas las trazas con error o lentas y una muestra del resto
Sin muestreo — Posible con almacenamiento de objetos barato; vigilar costes

Una política típica de tail sampling: 100 % de trazas con error, 100 % de las que superan el SLO de latencia y 5–10 % del resto.

Correlación entre señales

Desde Hacia Mecanismo
Métrica Traza Exemplars en Prometheus/Mimir
Traza Logs Consulta a Loki filtrando por trace_id
Traza Perfil Enlace a Pyroscope por span
Log Traza Derived field en Loki

Instrumenta con OpenTelemetry y envía mediante Alloy para mantener atributos consistentes entre señales.

Criterios de implementación

Elegir muestreo y retención según costes y necesidades de investigación. Proteger atributos sensibles y vigilar spans perdidos; Tempo necesita una interfaz de visualización como Grafana.

Continúa en las fuentes

Documentación oficial para verificar detalles y explorar más.