Skip to content

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

text
your apps (OTLP gRPC/HTTP)


edge:
  otelcol (subprocess plugin)
    └─ remote OTLP → tempo:4317

                          ├─ trace storage (S3-compatible blob)

                          └─ metrics_generator → traces_spanmetrics_*


                                                 prometheus:9090

otelcol 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érieSource
traces_spanmetrics_calls_totalun compteur par (service, operation, status_code)
traces_spanmetrics_latency_buckethistogramme de durée de span
traces_spanmetrics_size_bucketoptionnel, 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

json
{
  "kind": "trace_latency",
  "scope_type": "global",
  "conditions_json": {
    "service": "payments-api",
    "operation": "POST /v1/charge",
    "quantile": "p95",
    "window": "5m",
    "threshold_ms": 800
  }
}

Compile en :

promql
histogram_quantile(
  0.95,
  sum by (le) (rate(traces_spanmetrics_latency_bucket{
    service_name="payments-api", span_name="POST /v1/charge"
  }[5m]))
) * 1000 > 800

operation 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

json
{
  "kind": "trace_error_rate",
  "scope_type": "global",
  "conditions_json": {
    "service": "payments-api",
    "window": "5m",
    "operator": ">",
    "threshold_pct": 1.0
  }
}

Compile en :

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

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

text
{ resource.service.name="payments-api" } | duration > 800ms

Le 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