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.
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.