Traces
Le tracing distribué est le troisième backend L1 après Prom et Loki. Comme eux, il suit ADR-014 : les edges poussent en direct, le manager ne fait qu'interroger.
Le plan de données
your apps (OTLP gRPC/HTTP)
│
▼
edge:
otelcol (subprocess plugin)
└─ remote OTLP → tempo:4317
│
├─ trace storage (S3-compatible blob)
│
└─ metrics_generator → traces_spanmetrics_*
│
▼
prometheus:9090otelcol tourne comme plugin sous l'agent edge (même modèle de supervision que promtail — voir Logs). Le collecteur accepte à la fois gRPC (:4317) et HTTP (:4318) sur le host, batch, et transmet au Tempo du cloud sur HTTPS.
Les apps n'ont pas besoin de connaître Ongrid
Configurez l'exporteur OTel de votre application pour pointer vers http://localhost:4318 (ou l'équivalent gRPC). L'otelcol local gère l'auth + le batching + le voyage vers le cloud. Retirer Ongrid signifie retirer une variable d'env — votre code reste intact.
Le générateur spanmetrics
Le déploiement Tempo dans le compose a metrics_generator activé. Chaque batch de spans produit trois métriques dérivées émises de retour dans le même Prom :
| Série | Source |
|---|---|
traces_spanmetrics_calls_total | un compteur par (service, operation, status_code) |
traces_spanmetrics_latency_bucket | histogramme de durée de span |
traces_spanmetrics_size_bucket | optionnel, off par défaut |
C'est l'astuce porteuse qui fait que les alertes de trace ressemblent à des alertes métriques : l'evaluator d'alertes interroge Prom, les données vivent dans Tempo.
Types d'alerte
trace_latency
{
"kind": "trace_latency",
"scope_type": "global",
"conditions_json": {
"service": "payments-api",
"operation": "POST /v1/charge",
"quantile": "p95",
"window": "5m",
"threshold_ms": 800
}
}Compile en :
histogram_quantile(
0.95,
sum by (le) (rate(traces_spanmetrics_latency_bucket{
service_name="payments-api", span_name="POST /v1/charge"
}[5m]))
) * 1000 > 800operation est optionnel — droppez-le pour la latence service-wide. Voir compileTraceLatencyRule.
Quantiles supportés : p50 / p95 (défaut) / p99. La forme string existe pour que le picker de form UI reste concis ; le compilateur mappe vers le float que histogram_quantile attend.
trace_error_rate
{
"kind": "trace_error_rate",
"scope_type": "global",
"conditions_json": {
"service": "payments-api",
"window": "5m",
"operator": ">",
"threshold_pct": 1.0
}
}Compile en :
100 * (
sum by (service_name) (rate(traces_spanmetrics_calls_total{
service_name="payments-api", status_code="STATUS_CODE_ERROR"
}[5m]))
/ sum by (service_name) (rate(traces_spanmetrics_calls_total{
service_name="payments-api"
}[5m]))
) > 1.0Le littéral STATUS_CODE_ERROR est ce que le générateur spanmetrics émet ; les conventions de statut de span alternatives nécessitent leur propre type.
Outils
query_traceql
Passthrough direct vers l'endpoint TraceQL de Tempo (query_traceql_basetool.go). Utilisé par la persona investigator quand l'opérateur demande des IDs de trace spécifiques — par ex. « trouve une trace lente pour payments-api dans les 30 dernières minutes ».
{ resource.service.name="payments-api" } | duration > 800msLe client sous-jacent est internal/pkg/tracequery ; nom de package découplé du backend exprès — les clients Jaeger / Zipkin peuvent drop in plus tard sans renommer la surface.
correlate_incident
L'outil composite par lequel la persona investigator commence. Tire les signaux Prom + Loki + Tempo autour de la fenêtre de fire de l'incident en un seul appel fan-out. Réduit 4-5 appels d'outils séquentiels en un — important quand le budget par investigation est de 10 appels d'outils.
Voir correlate_incident_basetool.go.
Voir aussi
- Alertes — les types de règles.
- Monitoring — le backend Prom que les alertes de trace interrogent.
- Topologie — arêtes service-à-service que le
metrics_generatorde Tempo infère automatiquement. - Plan de données de télémétrie — ADR-014 dans son intégralité.