Un collecteur est l’intermédiaire entre vos applications (qui génèrent les signaux) et vos backends (qui les stockent). Son rôle : agréger, filtrer, enrichir et router les données.
À petite échelle, vous pouvez vous en passer. À partir de quelques dizaines de services, un collecteur central devient indispensable pour maîtriser les coûts, uniformiser le format et simplifier les changements de backend.
Guide de décision rapide
Section intitulée « Guide de décision rapide »Répondez à ces 5 questions pour choisir votre collecteur :
| Question | Si oui → |
|---|---|
| Vous voulez OTLP partout (logs + metrics + traces) ? | OpenTelemetry Collector |
| Vous faites surtout des logs Kubernetes ? | Fluent Bit ou Grafana Alloy |
| Vous avez des transformations lourdes / enrichissement avancé logs ? | Vector |
| Vous devez gérer l’auto-instrumentation K8s à l’échelle ? | OpenTelemetry Operator |
| Vous êtes chez un vendor (Datadog, Elastic, Splunk) ? | Agent vendor (mais attention au lock-in) |
Patterns de déploiement
Section intitulée « Patterns de déploiement »| Pattern | Quand | Avantages | Pièges |
|---|---|---|---|
| Sans collecteur | ≤ 10 services, stack simple | Simple, moins de composants | Vite ingérable, couplage fort |
| Gateway central | 10–100 services, multi-backends | Point d’entrée unique, sampling centralisé | SPOF si pas de HA |
| Agent + Gateway | Kubernetes à l’échelle | Collecte locale + routage central, HA | Complexité déploiement |
| Sidecar | Contraintes réseau/tenant strictes | Isolation totale | Overhead ressources, complexité |
Les 3 architectures types
Section intitulée « Les 3 architectures types »
Pattern 1 : Direct — Simple mais couplé au backend, pas de transformation.
Pattern 2 : Gateway central — Point unique, transformations, multi-backends. Prévoir HA (replicas).
Pattern 3 : Agent + Gateway — Collecte locale (DaemonSet) + routage central (Deployment). Enrichissement K8s, scalable, HA.
Matrice de comparaison
Section intitulée « Matrice de comparaison »| Outil | Signaux | Mode | Points forts | Limites |
|---|---|---|---|---|
| OTel Collector | logs + metrics + traces | agent + gateway | Standard OTLP, écosystème OTel, vendor-agnostic | Pipelines logs moins ergonomiques que Vector |
| Grafana Alloy | logs + metrics + traces | agent | Remplace Promtail, OTel-compatible, écosystème Grafana | Lié à Grafana Labs |
| Vector | logs + metrics (+ traces) | agent + aggregator | Transformations puissantes, très performant | Moins “OTel-first” |
| Fluent Bit | logs + metrics + traces | agent | Ultra léger, K8s/edge, CNCF | Transformations moins “data-pipeline” |
| Telegraf | principalement metrics | agent | 300+ plugins, InfluxDB/Prometheus | Faible sur logs/traces |
| Promtail | logs uniquement | agent | Simple pour Loki | ⚠️ Déprécié — migrer vers Alloy |
Compatibilité signaux (récapitulatif)
Section intitulée « Compatibilité signaux (récapitulatif) »| Outil | Logs | Métriques | Traces |
|---|---|---|---|
| OTel Collector | ✅ | ✅ | ✅ |
| Grafana Alloy | ✅ | ✅ | ✅ |
| Vector | ✅ | ✅ | ⚠️ (expérimental) |
| Fluent Bit | ✅ | ✅ | ✅ |
| Telegraf | ⚠️ | ✅ | ❌ |
| Promtail | ✅ | ❌ | ❌ |
Risques & anti-patterns
Section intitulée « Risques & anti-patterns »| Anti-pattern | Conséquence | Solution |
|---|---|---|
:latest en production | Breaking changes, régressions | Pin la version (0.145.0) |
| Labels Loki trop riches | Explosion cardinalité/coûts | 3-5 labels max (service, namespace, level) |
| Sampling trop tôt (côté app) | Traces inutilisables pour debug | Sampler au niveau gateway |
| Un seul collector sans HA | SPOF sur la télémétrie | Replicas + health_check |
Pas de memory_limiter | OOM du collector | Toujours l’activer en premier processor |
| Conflit de ports (4317/4318) | Collector et Jaeger se marchent dessus | Réseau Docker interne |
Observabilité du collecteur
Section intitulée « Observabilité du collecteur »Le collecteur lui-même doit être monitoré. Extensions essentielles :
| Extension | Port | Usage |
|---|---|---|
health_check | 13133 | Readiness/liveness probes |
zpages | 55679 | Debug pipelines (pipelinez, tracez, servicez) |
pprof | 1777 | Profiling Go |
extensions: health_check: endpoint: 0.0.0.0:13133 zpages: endpoint: 0.0.0.0:55679
service: extensions: [health_check, zpages]Métriques internes : le Collector expose ses propres métriques (réception, processing, export, queue, retry). Scrapez-les avec Prometheus.
Outils de cette catégorie
Section intitulée « Outils de cette catégorie »Recommandés (2026)
Section intitulée « Recommandés (2026) » OpenTelemetry Collector Collecteur universel OTLP : receivers, processors, exporters pour tous les signaux.
Telegraf Agent de collecte de métriques avec 300+ plugins (système, Docker, BDD).
Outils prévus : Grafana Alloy, Vector, Fluent Bit, OpenTelemetry Operator.
Legacy (à éviter pour les nouveaux projets)
Section intitulée « Legacy (à éviter pour les nouveaux projets) »| Outil | Statut | Migration recommandée |
|---|---|---|
| Promtail | Déprécié (LTS fév. 2025, EOL ~2026) | Grafana Alloy |
| Logstash | Lourd, remplacé par des solutions plus légères | Vector ou Fluent Bit |
Agents vendor (si stack dédiée)
Section intitulée « Agents vendor (si stack dédiée) »| Outil | Écosystème | Quand l’utiliser |
|---|---|---|
| Elastic Agent | Elastic/ELK | Si vous êtes full Elastic |
| Datadog Agent | Datadog | Si vous êtes chez Datadog |
| Splunk OTel Collector | Splunk Observability | Distro Splunk du Collector |
Outils compagnons
Section intitulée « Outils compagnons » telemetrygen Générateur de trafic OTLP pour valider vos pipelines.
Guides associés
Section intitulée « Guides associés » OpenTelemetry (fondamentaux) Architecture OTLP : receivers, processors, exporters.
Logs (fondamentaux) Bonnes pratiques de structuration et routage des logs.
Formation Observabilité Labs pratiques : déployer une stack complète.