RousselTMLEARNING

Observabilité

Instrumenter sans code avec Grafana Beyla (OpenTelemetry eBPF Instrumentation)

Obtenir métriques RED et traces HTTP/gRPC de n'importe quelle application sans la modifier : Grafana Beyla et OpenTelemetry eBPF Instrumentation, configuration, export Prometheus et OTLP, Kubernetes.

1. Le principe #

Les métriques RED de n'importe quel service.

Ce que fait Beyla #

Fonctionnement de Beyla
Aucune bibliothèque à ajouter, aucun redémarrage de l'application.

Beyla s'attache aux processus ciblés et observe leurs requêtes HTTP, HTTP/2, gRPC, SQL, Redis ou Kafka (côté serveur et client). Il en déduit les métriques RED (Rate, Errors, Duration) et des spans au format OpenTelemetry.

À savoir : En 2025, Grafana Labs a donné le cœur de Beyla au projet OpenTelemetry sous le nom OpenTelemetry eBPF Instrumentation (OBI). Beyla reste la distribution de Grafana, avec la même configuration ; Alloy l'embarque dans le composant beyla.ebpf.

2. Configurer Beyla #

Cibler, exporter.

Variables d'environnement #

docker run --rm --privileged --pid=host \
  -e BEYLA_OPEN_PORT=8080 \
  -e BEYLA_PROMETHEUS_PORT=9400 \
  -e OTEL_EXPORTER_OTLP_ENDPOINT=http://alloy:4318 \
  -e BEYLA_TRACE_PRINTER=text \
  grafana/beyla:latest
VariableRôle
BEYLA_OPEN_PORTInstrumenter le processus qui écoute sur ce port
BEYLA_EXECUTABLE_NAMEOu cibler par nom d'exécutable
BEYLA_PROMETHEUS_PORTExposer les métriques sur /metrics
OTEL_EXPORTER_OTLP_ENDPOINTEnvoyer métriques et traces en OTLP
BEYLA_TRACE_PRINTERAfficher les spans dans la console (diagnostic)
OTEL_SERVICE_NAMEForcer le nom du service

Fichier de configuration #

# beyla.yml
discovery:
  instrument:
    - open_ports: 8080-8089
    - exe_path: "*/java"
routes:
  patterns: [/api/orders/{id}, /api/users/{id}]   # éviter la cardinalité des URL
  unmatched: heuristic
prometheus_export:
  port: 9400
otel_traces_export:
  endpoint: http://tempo:4318
Erreur Courante : Sans routes, chaque URL distincte (/orders/123, /orders/124...) peut devenir une valeur de label. Déclarez les gabarits de routes ou laissez l'heuristique les regrouper.

3. Métriques et traces produites #

Les conventions OpenTelemetry.

Métriques #

Métrique PrometheusContenu
http_server_request_duration_secondsDurée des requêtes HTTP reçues (histogramme)
http_client_request_duration_secondsDurée des requêtes HTTP émises
rpc_server_duration_secondsDurée des appels gRPC
db_client_operation_duration_secondsDurée des requêtes SQL
# Taux d'erreurs 5xx par route
sum by (http_route) (rate(http_server_request_duration_seconds_count{http_response_status_code=~"5.."}[5m]))
/ sum by (http_route) (rate(http_server_request_duration_seconds_count[5m]))

Côté traces, Beyla propage le contexte W3C (traceparent) pour plusieurs langages, ce qui permet des traces distribuées entre services instrumentés par eBPF.

Bonne Pratique : Commencez par Beyla pour couvrir tous les services en une journée, puis ajoutez un SDK OpenTelemetry là où vous avez besoin de spans métier détaillés.

4. Sur Kubernetes #

DaemonSet et découverte.

Helm #

helm install beyla grafana/beyla -n beyla --create-namespace -f values.yaml
# values.yaml (extrait)
config:
  data:
    discovery:
      instrument:
        - k8s_namespace: boutique
    attributes:
      kubernetes: { enable: true }
    prometheus_export: { port: 9090, path: /metrics }

Beyla ajoute les métadonnées Kubernetes (namespace, pod, deployment) aux métriques et traces : c'est elles qui servent de service_name par défaut.

Articles liés

eBPF expliqué : des programmes dans le noyau Linux pour observer sans instrumenter

Ce qu'est eBPF, comment un programme est vérifié puis exécuté dans le noyau, les points d'accroche (kprobes, …

Diagnostiquer avec bpftrace et les outils bcc

Les outils eBPF du diagnostic au quotidien : one-liners bpftrace (appels système, fichiers, latences), outils…

Observer le réseau Kubernetes avec Cilium Hubble

Rendre visibles les flux réseau d'un cluster Kubernetes avec Cilium Hubble : architecture, CLI hubble observe…

Pour aller plus loin