À la fin de ce tutoriel, vous saurez expliquer OpenTelemetry (OTel), distinguer traces / metrics / logs, déployer un Collector en réception OTLP, instrumenter une app minimale, et corréler les signaux — le tout dans un lab ca-central-1 sans facture inutile.

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : OpenTelemetry Collector contrib 0.100+ · OTLP/gRPC · Python SDK 1.27+ (ou Node équivalent) · Docker Compose · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-opentelemetry-stack · Série : WOW (24/50) · Mot-clé SEO : OpenTelemetry · Publish : HOLD

→ Précédent : EventBridge : architectures event-driven · → Suivant : Prometheus + Thanos · Aussi : Grafana Loki Tempo · CloudWatch alarmes

Prérequis

Coût estimé : 0 € sur le lab local (Collector + app en Docker). Si vous exportez vers AWS X-Ray / CloudWatch en ca-central-1, restez Free Tier et détruisez les ressources après le lab. Pas d’EKS « juste pour OTel ».

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity

Ce que nous allons construire

OpenTelemetry stack (WOW 24/50) — ca-central-1
  ├── Signaux : traces · metrics · logs
  ├── API / SDK / Collector / OTLP
  ├── Lab : app instrumentée → Collector → backend
  ├── Corrélation trace_id dans les logs
  ├── Anti-patterns & check-list DEH
  └── Quiz + FAQ + maillage WOW

(Schéma — alt : « App Python envoie OTLP au Collector OpenTelemetry qui exporte traces et métriques vers un backend d’observabilité ».)

Étape 1 — Pourquoi OpenTelemetry en 2026 ?

Avant OTel, chaque vendor imposait son agent (Datadog, New Relic, Elastic APM, X-Ray…). Changer d’outil = réécrire l’instrumentation. OpenTelemetry est le standard CNCF pour générer, collecter et exporter télémétrie de façon vendor-neutral.

En pratique DEH : vous instrumentez une fois (SDK + auto-instrumentation), vous poussez en OTLP vers un Collector, et vous choisissez le backend (Tempo, Jaeger, Prometheus, Loki, CloudWatch, vendor SaaS) sans recoller l’app.

Avant Avec OpenTelemetry
Agent propriétaire dans l’image SDK / auto-instr. standard
Formats incompatibles OTLP (gRPC / HTTP)
Vendor lock-in Collector + exporters
Traces sans logs liés trace_id / span_id partagés
Métriques « à part » Même pipeline

Étape 2 — Les trois signaux (et la corrélation)

Signal Question Exemple
Trace Quel chemin a pris une requête ? Span HTTP → DB → queue
Metric Combien / à quelle vitesse ? http_server_duration p95
Log Que s’est-il passé ici ? Erreur SQL + contexte

La valeur OTel n’est pas « avoir trois outils », c’est corréler : un log d’erreur porte le trace_id, la trace montre le span lent, la métrique alerte sur le p95. Sans corrélation, vous avez trois silos.

Ressources sémantiques utiles : service.name, deployment.environment, cloud.region=ca-central-1, http.route. Gardez un dictionnaire d’attributs dans le golden path plateforme — Platform Engineering.

Étape 3 — Architecture de référence DEH

[ App / Sidecar ]
      │  OTLP (4317 gRPC / 4318 HTTP)
      ▼
[ OpenTelemetry Collector ]
  ├── receivers: otlp
  ├── processors: batch, memory_limiter, resource
  └── exporters: otlp/tempo · prometheus · loki · awsxray (opt)
      ▼
[ Backends ]
  Tempo / Jaeger · Prometheus (+ Thanos) · Loki · Grafana

Règle d’or : l’app ne parle qu’au Collector. Jamais d’exporteur vendor direct dans le code prod si vous pouvez l’éviter — ça simplifie les rotations de backend et les politiques (sampling, PII).

Étape 4 — Lab : Collector + app OTLP

Créez un dossier de lab :

mkdir -p ~/otel-lab && cd ~/otel-lab

otel-collector-config.yaml (récepteur OTLP, export debug + fichier) :

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
  memory_limiter:
    check_interval: 1s
    limit_mib: 256
  resource:
    attributes:
      - key: deployment.environment
        value: lab
        action: upsert
      - key: cloud.region
        value: ca-central-1
        action: upsert

exporters:
  debug:
    verbosity: detailed
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch, resource]
      exporters: [debug]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch, resource]
      exporters: [debug]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch, resource]
      exporters: [debug]

docker-compose.yml (Collector seul pour démarrer) :

services:
  otel-collector:
    image: otel/opentelemetry-collector-contrib:0.100.0
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml:ro
    ports:
      - "4317:4317"
      - "4318:4318"

docker compose up -d
docker compose logs -f otel-collector

App Python minimale (app.py) avec SDK traces :

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

resource = Resource.create({
    "service.name": "deh-payments",
    "service.version": "0.1.0",
    "deployment.environment": "lab",
    "cloud.region": "ca-central-1",
})
provider = TracerProvider(resource=resource)
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="localhost:4317", insecure=True))
)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("deh.lab")

with tracer.start_as_current_span("charge_card") as span:
    span.set_attribute("payment.amount", 42)
    span.set_attribute("payment.currency", "CAD")
    print("span envoyé — regardez les logs du Collector")

python3 -m venv .venv && source .venv/bin/activate
pip install opentelemetry-api opentelemetry-sdk 
  opentelemetry-exporter-otlp-proto-grpc
python app.py

Vous devez voir le span charge_card dans les logs debug du Collector. C’est le happy path OTel : SDK → OTLP → Collector.

Étape 5 — Sampling, cardinality et coûts

Sans garde-fous, OTel peut exploser le volume (et la facture backend).

Levier Pratique DEH
Sampling head (SDK) ou tail (Collector) — commencez 10–20 % hors incident
Cardinality jamais user_id / UUID en label métrique
Batch processor batch obligatoire en prod
PII redaction processor avant export
Region tags cloud.region=ca-central-1 pour FinOps

En incident : montez temporairement le sampling, puis redescendez. Documentez ça dans le runbook — Incident runbooks · SRE error budgets.

Étape 6 — Vers la stack Grafana / AWS

Deux chemins fréquents chez DEH :

  1. OSS : Collector → Tempo (traces) + Prometheus (metrics) + Loki (logs) + Grafana — voir wow-grafana-loki-tempo et wow-prometheus-thanos.
  2. AWS natif : Collector → AWS Distro for OpenTelemetry (ADOT) → X-Ray / CloudWatch en ca-central-1. Utile si vous êtes déjà all-in AWS ; gardez OTLP côté app.

Sur Kubernetes : DaemonSet ou Gateway Collector, service.name via Downward API / resource processor, et pas de credentials longs — OIDC / IRSA / Pod Identity — wow-eks-pod-identity.

Check-list golden path observabilité

  1. service.name stable et unique par service
  2. Export uniquement vers le Collector (OTLP)
  3. deployment.environment + cloud.region=ca-central-1
  4. Logs structurés avec trace_id / span_id
  5. Sampling documenté + processor batch
  6. Dashboard Grafana « RED/USE » ou équivalent dès le jour 1
  7. Alerte sur SLO (pas sur chaque métrique brute) — wow-sre-error-budgets
  8. Destruction lab : docker compose down -v
docker compose down -v
deactivate 2>/dev/null || true
rm -rf ~/otel-lab/.venv

Erreurs fréquentes

Erreur Impact Correction
Exporter vendor dans le code Lock-in OTLP → Collector
service.name = hostname Chaos dashboards Nom logique stable
Labels haute cardinalité Coût / perf Attributs bornés
Pas de trace_id dans les logs Debug lent Logger instrumenté OTel
Collector sans memory_limiter OOM Limiter + batch
Region oubliée FinOps flou Forcer ca-central-1

Quiz (5 questions)

1. OpenTelemetry sert surtout à :
– A. Remplacer Kubernetes
– B. Standardiser génération / collecte / export de télémétrie
– C. Stocker des secrets

2. Le protocole d’export recommandé app → Collector est :
– A. Syslog UDP seul
– B. OTLP (gRPC ou HTTP)
– C. FTP

3. Pourquoi un Collector devant le backend ?
– A. Pour ralentir les traces
– B. Sampling, batch, redaction, multi-export sans toucher l’app
– C. Obligatoire par la loi

4. Region lab DEH :
– A. us-east-1
– B. ca-central-1
– C. ap-south-1

5. Mettre user_id en label Prometheus :
– A. Bonne idée
– B. Anti-pattern (explosion de cardinalité)
– C. Requis par OTel

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

OpenTelemetry remplace-t-il Prometheus ?

Non. OTel génère et route ; Prometheus (ou un backend compatible) stocke et requête les métriques. Souvent : SDK → Collector → Prometheus remote-write / exporter.

Traces + logs : comment les lier ?

Injectez trace_id / span_id dans le logger (handlers OTel). Dans Grafana, un clic trace → logs filtrés.

Faut-il instrumenter à la main ou en auto ?

Les deux. Auto-instrumentation pour HTTP/DB courants ; spans manuels pour le métier (charge_card, settle_payment).

Collector en DaemonSet ou Gateway ?

DaemonSet proche des nœuds (logs/agents) ; Gateway central pour sampling / export. Beaucoup d’équipes combinent les deux.

Pourquoi ca-central-1 ?

Standard lab DevOps Elastic Hayway : cohérence IAM, FinOps et maillage entre tutos.

ADOT ou Collector upstream ?

ADOT si vous ciblez surtout AWS (X-Ray, CloudWatch, EMF). Upstream contrib si stack Grafana OSS / multi-cloud. L’app reste en OTLP dans les deux cas.

Pour aller plus loin

Maillage série WOW
← Précédent EventBridge : architectures event-driven
→ Suivant Prometheus + Thanos
Aussi Grafana Loki Tempo · SRE error budgets · Incident runbooks · Lambda Powertools

Meta publication (SEO)

  • Title SEO : OpenTelemetry : traces, metrics et logs unifiés (guide FR)
  • Meta description : OpenTelemetry : unifier traces, metrics et logs avec Collector OTLP. Lab ca-central-1, corrélation, FAQ, quiz et check-list DEH.
  • Focus keyword : OpenTelemetry
  • Secondary : OTLP, OpenTelemetry Collector, traces metrics logs, observability
  • Image : assets/web/devopelastichayway/cover-wow-opentelemetry-stack-1200x630.webp (à générer)
  • Catégorie : WOW / Observability · Niveau : Intermédiaire
  • URL cible : https://devopelastichayway.com/tutoriels/wow-opentelemetry-stack/
  • Post live : N/A (nouveau) · slug wow-opentelemetry-stack · Publish : HOLD (draft only — feu vert Maître requis)

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.