09 - eBPF Instrumentation - Low-Overhead Observability Without Code Changes

eBPF Instrumentation: Observability a Livello Kernel

eBPF (extended Berkeley Packet Filter) e una tecnologia del kernel Linux che permette di eseguire programmi sandbox all'interno del kernel, senza modificare il codice sorgente del kernel stesso o caricare moduli kernel. Applicata all'observability, eBPF consente di ottenere tracce distribuite, metriche di performance e visibilità di rete senza modificare il codice applicativo e senza agenti.

Mentre l'auto-instrumentation di OpenTelemetry opera a livello applicativo (intercettando le chiamate alle librerie), eBPF opera a livello kernel, intercettando le syscall, i pacchetti di rete e le operazioni su file system. Questo approccio offre un overhead inferiore e una copertura più ampia, includendo servizi che non possono essere instrumentati tradizionalmente.

Come Funziona eBPF

eBPF permette di caricare piccoli programmi nel kernel Linux che vengono eseguiti in risposta a eventi specifici: syscall, arrivo di pacchetti di rete, context switch tra processi, operazioni su file system. Questi programmi sono verificati dal kernel per garantire sicurezza (nessun crash, nessun loop infinito) e vengono compilati in bytecode efficiente.

Tipi di Probe eBPF

I programmi eBPF possono essere attaccati a diversi punti del kernel, ognuno utile per un aspetto diverso dell'observability:

// Esempio concettuale: probe eBPF per catturare connessioni TCP
// Questo programma si attacca alla syscall connect()

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

struct connection_event {
    __u32 pid;
    __u32 tid;
    __u64 timestamp_ns;
    __u32 src_addr;
    __u32 dst_addr;
    __u16 dst_port;
    char comm[16];  // nome del processo
};

// Buffer per inviare eventi allo user-space
struct {
    __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
    __uint(key_size, sizeof(int));
    __uint(value_size, sizeof(int));
} events SEC(".maps");

// Probe attaccato a tcp_connect
SEC("kprobe/tcp_connect")
int trace_tcp_connect(struct pt_regs *ctx) {
    struct connection_event event = {};

    event.pid = bpf_get_current_pid_tgid() >> 32;
    event.tid = bpf_get_current_pid_tgid();
    event.timestamp_ns = bpf_ktime_get_ns();
    bpf_get_current_comm(&event.comm, sizeof(event.comm));

    // Estrarre indirizzo e porta di destinazione
    // ... (accesso alle strutture del kernel)

    // Inviare l'evento allo user-space
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
                          &event, sizeof(event));
    return 0;
}
      

Pixie: Observability Kubernetes con eBPF

Pixie (ora parte del progetto CNCF) e una piattaforma di observability per Kubernetes che usa eBPF per fornire visibilità automatica su applicazioni, rete e infrastruttura senza richiedere modifiche al codice, agent applicativi o sidecar.

# Installare Pixie su un cluster Kubernetes
# Prerequisiti: Kubernetes 1.21+, kernel Linux 4.14+

# 1. Installare la CLI di Pixie
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)"

# 2. Deploy di Pixie nel cluster
px deploy

# 3. Verificare lo stato
px get viziers

# 4. Eseguire query dal terminale
# Visualizzare le connessioni HTTP tra servizi
px run px/http_data

# Latenza per endpoint
px run px/service_stats

# Traffico DNS
px run px/dns_data

# Profiling CPU (flame graph)
px run px/perf_flamegraph -- --pod=order-service
      

Pixie cattura automaticamente il traffico HTTP, gRPC, MySQL, PostgreSQL, Redis, Kafka e DNS a livello kernel, ricostruendo le richieste e calcolando latenze senza alcuna instrumentazione applicativa.

Cilium e Hubble: Network Observability

Cilium e un progetto CNCF che usa eBPF per il networking e la sicurezza in Kubernetes. Hubble, il componente di observability di Cilium, fornisce visibilità completa sul traffico di rete tra pod, incluse metriche L3/L4/L7, policy di rete e service map automatiche.

# Installare Cilium con Hubble abilitato
# helm install cilium cilium/cilium --version 1.15.0

# Configurazione Cilium con Hubble
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:
  # Abilitare Hubble per observability
  enable-hubble: "true"
  hubble-listen-address: ":4244"
  hubble-metrics-server: ":9965"

  # Metriche L7 per HTTP
  hubble-metrics: >-
    dns
    drop
    tcp
    flow
    icmp
    http
    httpV2:sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity

  # Esportazione verso OpenTelemetry
  hubble-export-file-max-size-mb: "10"
  hubble-export-file-max-backups: "5"

  # Abilitare il relay per la UI
  hubble-relay-enabled: "true"
  hubble-ui-enabled: "true"
      

# Comandi Hubble per network observability

# Osservare il traffico in tempo reale
hubble observe --namespace ecommerce

# Filtrare per protocollo HTTP
hubble observe --namespace ecommerce --protocol http

# Visualizzare solo gli errori (4xx, 5xx)
hubble observe --namespace ecommerce --http-status 400-599

# Traffico tra servizi specifici
hubble observe --from-pod ecommerce/order-service \
               --to-pod ecommerce/payment-service

# Metriche per Prometheus
# Le metriche Hubble sono esposte su :9965/metrics
# e possono essere scrappate da Prometheus
      

eBPF vs Auto-Instrumentation: Confronto

eBPF e auto-instrumentation sono approcci complementari, non alternativi. Ciascuno ha punti di forza e limiti specifici che li rendono adatti a scenari diversi.

Limiti Attuali di eBPF

Nonostante il potenziale rivoluzionario, eBPF ha limiti importanti che ne condizionano l'adozione:

• Solo Linux: eBPF e una tecnologia del kernel Linux, non disponibile su Windows o macOS (in produzione)
• Versione kernel: richiede kernel 4.14+ (5.8+ per le feature avanzate), limitando i sistemi legacy
• Traffico TLS: eBPF vede i dati dopo la decryption solo con uprobe su librerie SSL, con complessità aggiuntiva
• Nessun contesto di business: eBPF vede pacchetti e syscall, non order ID o customer tier
• Complessità di sviluppo: scrivere programmi eBPF personalizzati richiede conoscenze del kernel

Conclusioni e Prossimi Passi

eBPF rappresenta il futuro dell'observability a basso overhead. La capacità di ottenere tracce distribuite, metriche di rete e profiling senza modificare il codice applicativo e rivoluzionaria, specialmente per cluster Kubernetes con centinaia di servizi.

L'approccio ottimale combina eBPF (per la visibilità di rete e infrastruttura) con OpenTelemetry (per il contesto applicativo e di business). Strumenti come Pixie e Cilium/Hubble rendono eBPF accessibile anche a team senza esperienza kernel.

Nel prossimo articolo esploreremo le strategie di sampling, analizzando come ridurre il volume di telemetria e i costi associati senza perdere visibilità sugli eventi critici.