1. Deux approches du stockage #
Index ou pas d'index.
Principe #
Jaeger indexe les spans dans une base de recherche (Elasticsearch, OpenSearch, Cassandra) : recherches rapides par tags, mais un stockage coûteux à grande échelle. Tempo écrit les traces dans un stockage objet en format colonne (Parquet) sans index classique : très économique, avec une recherche par TraceQL qui parcourt les blocs.
2. Comparatif détaillé #
Critère par critère.
Tableau #
| Critère | Jaeger | Grafana Tempo |
|---|---|---|
| Stockage | Elasticsearch, OpenSearch, Cassandra, Badger | Stockage objet (S3, GCS, Azure) |
| Coût à grand volume | Élevé (index) | Faible |
| Recherche | Par service, opération, tags, durée | TraceQL : conditions sur spans, structure, agrégats |
| Interface | Interface Jaeger dédiée | Grafana (Explore, Traces Drilldown) |
| Corrélation logs / métriques / profils | Limitée | Native dans Grafana (exemplars, liens vers Loki et Pyroscope) |
| Métriques dérivées | SPM via spanmetrics | Metrics generator (RED, service graph) |
| Échantillonnage adaptatif | Oui | Via Collector ou Alloy |
| Base | OpenTelemetry Collector (v2) | Architecture distribuée type Mimir/Loki |
| Gouvernance | CNCF graduated | Grafana Labs (AGPLv3) |
3. Recommandations #
Selon le contexte.
Choisir #
| Contexte | Choix |
|---|---|
| Stack Grafana (Prometheus, Loki, Mimir) | Tempo : corrélation native et coût faible |
| Elasticsearch déjà exploité, volume modéré | Jaeger sur Elasticsearch, ou Elastic APM |
| Besoin d'une interface de tracing autonome et neutre | Jaeger |
| Très gros volume de traces, rétention longue | Tempo |
Bonne Pratique : Avec OpenTelemetry, le choix n'est pas définitif : un Collector peut envoyer les mêmes traces aux deux pendant une période d'essai.
