RousselTMLEARNING

Observabilité

Beyla et Alloy : métriques RED et traces sans code avec beyla.ebpf

Activer l'instrumentation eBPF de Beyla dans Alloy : découverte des services, métriques RED vers Mimir, traces vers Tempo, privilèges nécessaires.

1. Instrumenter sans modifier le code #

Le principe de Beyla.

Le principe #

Beyla observe les appels HTTP/S, gRPC et SQL des services Linux grâce à des sondes eBPF dans le noyau : pas de SDK, pas de redéploiement. Le composant beyla.ebpf lance Beyla comme processus enfant d'Alloy (Beyla v3.38.1 dans la documentation actuelle), qui produit des métriques RED (débit, erreurs, durée) et des traces.

Beyla observe les services par eBPF et Alloy route métriques et traces

2. La configuration #

Métriques et traces.

config.alloy #

beyla.ebpf "default" {
  discovery {
    instrument {
      open_ports = "8080,9000-9100"
    }
  }

  metrics {
    features = ["application", "application_service_graph"]
  }

  output {
    traces = [otelcol.processor.batch.default.input]
  }
}

prometheus.scrape "beyla" {
  targets      = beyla.ebpf.default.targets
  honor_labels = true
  forward_to   = [prometheus.remote_write.mimir.receiver]
}

otelcol.processor.batch "default" {
  output {
    traces = [otelcol.exporter.otlp.tempo.input]
  }
}

otelcol.exporter.otlp "tempo" {
  client {
    endpoint = "tempo:4317"
    tls {
      insecure = true
    }
  }
}

prometheus.remote_write "mimir" {
  endpoint {
    url = "http://mimir:9009/api/v1/push"
  }
}

Configuration validée avec alloy validate (Alloy v1.21.3, novembre 2026).

  • discovery.instrument : quels processus instrumenter, par ports ouverts (open_ports), nom d'exécutable ou sélecteurs Kubernetes.
  • metrics.features : application (RED), application_service_graph, network, application_runtime…
  • targets : Beyla expose ses métriques ; prometheus.scrape les collecte avec honor_labels = true pour garder job et instance.
  • output.traces : sans lui, les traces sont abandonnées.
Sélection des processus et familles de métriques

3. Privilèges et déploiement #

Le point délicat.

Les capacités nécessaires #

eBPF exige des privilèges élevés. La documentation recommande de tourner en root avec privileged: false et uniquement les capacités utiles, pour garder seccomp et AppArmor actifs :

securityContext:
  privileged: false
  capabilities:
    add: [BPF, NET_ADMIN, NET_RAW, PERFMON, DAC_READ_SEARCH, SYS_PTRACE, CHECKPOINT_RESTORE]
# Pod Kubernetes : hostPID: true et profil AppArmor Unconfined
Non testé ici en fonctionnement. Notre environnement de test ne permet pas de charger des programmes eBPF : la configuration a été validée par alloy validate, pas exécutée.

Sources #

Articles liés

Alloy et l'écosystème Grafana Labs : quel composant pour quel outil ?

La carte des intégrations d'Alloy avec Faro, Beyla, k6, Loki, Mimir, Tempo, Pyroscope, Database Observability…

Faro et Alloy : recevoir le RUM front-end avec faro.receiver

Configurer faro.receiver : CORS, clé d'API, limite de débit, source maps, puis envoyer erreurs, Web Vitals et…

Database Observability : suivre requêtes et plans MySQL et PostgreSQL avec Alloy

Les composants database_observability.mysql et .postgres d'Alloy : collecteurs, plans d'exécution, verrous, e…

Pour aller plus loin

Soutenir

♥ SOUTENIR

Soutenez RousselTM Learning

Les formations, articles, TP et attestations restent gratuits et sans publicité intrusive. Une contribution libre, du montant de votre choix, finance l’hébergement, les environnements de TP et l’écriture de nouveaux contenus.

Contribuer avec PayPal Montant libre · carte bancaire ou compte PayPalEn savoir plus
QR code PayPal
Ou scannez ce QR code avec votre téléphone

Merci, chaque contribution compte !