Traces OpenTelemetry et Kibana APM

1. Instrumenter #

SDK OTel ou EDOT.

Instrumentation automatique #

# Java : agent EDOT (ou agent OpenTelemetry Java)
export OTEL_SERVICE_NAME=checkout
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318
export OTEL_RESOURCE_ATTRIBUTES=deployment.environment=prod,service.version=1.4.2
java -javaagent:elastic-otel-javaagent.jar -jar checkout.jar

À savoir : Les SDK EDOT sont des distributions des SDK OpenTelemetry avec des réglages par défaut adaptés à Elastic ; les SDK OpenTelemetry standard fonctionnent aussi.

2. Dans Kibana #

Services, transactions, carte.

Vues APM #

Avec le Collector EDOT (connecteur et processeur APM d'Elastic), Kibana affiche pour chaque service la latence, le débit, le taux d'erreur, les dépendances et la carte des services. Une trace s'ouvre en cascade (waterfall) avec ses spans.

FROM traces-*.otel-*
| WHERE resource.attributes.service.name == "checkout" AND status.code == "Error"
| KEEP @timestamp, trace_id, name, duration
| SORT @timestamp DESC | LIMIT 20

3. Échantillonner et corréler #

Garder ce qui compte.

L'échantillonnage par la queue #

processors:
  tail_sampling:
    decision_wait: 10s
    policies:
      - { name: erreurs, type: status_code, status_code: { status_codes: [ERROR] } }
      - { name: lentes, type: latency, latency: { threshold_ms: 800 } }
      - { name: echantillon, type: probabilistic, probabilistic: { sampling_percentage: 10 } }

Erreur courante : Échantillonner dans les SDK ET dans le Collector sans le savoir : on garde 10 % de 10 %, et les métriques APM calculées sur les spans restants deviennent fausses. Calculez les métriques APM avant l'échantillonnage.

Relier logs et traces #

Quand le SDK injecte trace_id et span_id dans les logs (appenders OTel de log4j, logback, Python logging), Kibana passe d'une trace à ses logs et inversement.