Il modo tradizionale di profilere un problema di produzione ha una dipendenza imbarazzante: devi già sospettare che accada. Qualcosa sembra lento, alleghi un profiler, provi a riprodurre la condizione, e — se sei fortunato e il problema sta ancora accadendo — catturi i dati. La modalità di fallimento è ovvia e comune. L''incidente è accaduto alle 3 del mattino, è durato quattro minuti, e nel momento che qualcuno ha guardato, l''evidenza era scomparsa. Aggiungi logging, spera che si ripeta, e aspetta.
eBPF ha cambiato l''economia abbastanza da invertire quel workflow. Perché i programmi eBPF vengono eseguiti dentro il kernel in una sandbox verificata, possono osservare syscall, scheduling e stack trace attraverso ogni processo su una macchina con overhead abbastanza basso — consistentemente sotto l''1% — da lasciare in esecuzione permanentemente. Questo trasforma il profiling da qualcosa che inizi in qualcosa che interroghi: i dati per le 3 del mattino già esistono. Questa guida copre quel cambiamento attraverso Parca Agent per il profiling continuo, e un''applicazione più nuova che è emersa mentre gli agenti autonomi proliferano — usando la stessa visibilità a livello kernel per vedere cosa un agente IA ha realmente fatto, via tool come AgentSight.
Perché eBPF ha reso il sempre-acceso pratico
La ragione tecnica per cui il profiling continuo era impraticabile prima è che le opzioni più vecchie imponevano tutte una tassa che non pagheresti permanentemente. I profiler di campionamento basati su perf sono economici ma richiedono setup per target e producono dati che devi gestire te stesso. I profiler strumentati richiedono cambiamenti di codice e aggiungono overhead per-chiamata. Gli agenti specifici della lingua coprono un runtime e spesso introducono il loro costo di performance. Nessuno di loro erano cose che eseguiresti su ogni processo su ogni nodo per sempre.
Il contributo di eBPF è che i programmi vengono eseguiti nello spazio kernel, quindi raccogliere una stack trace non richiede context-switching a un agente userspace per ogni campione, e il verifier del kernel prova staticamente che il programma non può far crashare il sistema o fare loop forever prima che sia permesso di caricarsi. Il risultato è visibilità a livello kernel con garanzie di sicurezza e overhead nel rumore. Crucialmente è anche zero-strumentazione: non modifichi, ricompili o riavvii le applicazioni che vengono profilete, che rimuove l''attrito organizzativo che ha ucciso la maggior parte dei tentativi precedenti ("avremmo bisogno che ogni team aggiungesse un agente").
C''è un prerequisito reale che vale la pena affermare: questo dipende da un kernel ragionevolmente moderno con supporto BTF, e la qualità di unwinding dello stack dipende dai tuoi binari che hanno simboli. I binari di produzione privati producono profili pieni di indirizzi hex, che è un problema risolvibile ma uno che dovresti risolvere prima di concludere che il tool non funziona.
Profiling continuo nella pratica
Parca Agent è l''espressione più chiara dell''idea. Distribuito come DaemonSet su Kubernetes (o un processo su un nodo), campiona stack trace da ogni processo su quel nodo, continuamente, li etichetta con metadati di pod, container e namespace, e li spedisce a un server dove sono archiviati come metriche — interrogabili per intervallo di tempo e etichetta.
Quel modello di archiviazione è quello che lo rende utile piuttosto che meramente interessante. Perché i profili sono serie etichettate nel tempo, puoi fare domande che il profiling on-demand non può rispondere. Cosa stava consumando CPU nello spazio dei nomi dei pagamenti tra le 03:04 e le 03:08? Il profilo esiste; filtra alla finestra. Ancora più prezioso è il confronto: diff il profilo da prima di un deployment contro dopo, e la regressione appare come una funzione che è cresciuta. Non avevi bisogno di prevedere che avresti voluto il profilo "prima" — la raccolta continua significa che è sempre lì.
Parca gestisce stack di linguaggio misto, che importa più di quanto sembri. Un servizio moderno potrebbe essere Go che chiama librerie C, o Python che invoca estensioni native, e un profilo che risolve solo uno strato racconta una storia fuorviante. L''unwinding a livello kernel vede l''intero stack. Per un''analisi profonda una tantum ricorrerai ancora a perf o async-profiler — il profiling continuo ottimizza per copertura e storia, non il massimo dettaglio per-run — ma la domanda di tutti i giorni di "su cosa questo cluster sta spendendo CPU" è risposta continuamente e economicamente.
Il nuovo problema: cosa ha fatto l''agente?
La seconda applicazione è più nuova e, nel 2026, sempre più pressante. I team stanno eseguendo agenti di codifica autonoma e agenti LLM con accesso a tool su sistemi reali. Questi agenti leggono file, eseguono comandi, installano pacchetti e fanno chiamate di rete. L''osservabilità che quei sistemi forniscono è a livello di applicazione: prompt, chiamate di tool, conteggi di token, span. Tool come Langfuse e Arize Phoenix fanno questo bene e sono genuinamente utili per capire il ragionamento di un agente.
Ma il tracing a livello di applicazione ha una limitazione strutturale: mostra quello che il framework dell''agente ha scelto di segnalare. Se uno strumento esegue un comando shell, la traccia registra la stringa di comando — non i diciassette processi che il comando ha generato, i file che hanno toccato o l''host che hanno contattato. Se l''agente è compromesso da iniezione di prompt e prende un''azione al di fuori del suo scopo previsto, la traccia mostra l''azione che ha narrato, che è esattamente la fonte di verità sbagliata per una domanda di sicurezza.
AgentSight applica eBPF qui: osserva il comportamento del sistema reale dell''agente a livello kernel — esecuzione di processi, accesso ai file, connessioni di rete — senza alcuna strumentazione dell''agente. L''agente non può omettere o misreportare questi eventi perché non è colui che li riporta. Per un agente di codifica che opera su un repository, ottieni la risposta reale a "quali file ha modificato", "cosa ha eseguito" e "ha raggiunto al di fuori dello workspace".
La postura corretta è che questi sono strati complementari, non competitori. Il tracing di applicazione ti dice l''intenzione e il ragionamento dell''agente; il tracing del kernel ti dice i suoi effetti. Correlando loro per timestamp ti dà entrambe le metà: questo è quello che l''agente stava cercando di fare, e questo è quello che è effettivamente accaduto sulla macchina. Per qualsiasi cosa con permessi reali, avere solo la prima metà è un gap.
Sicurezza, non solo performance
Quel framing indica al più ampio uso. La stessa base eBPF sottostante a tool di sicurezza di runtime — Tracee, Falco, Tetragon — che guardano il comportamento a livello kernel sospetto e, nel caso di Tetragon, possono applicare la politica nel kernel. Una volta che stai raccogliendo evento di processo, file e rete su ogni nodo, la differenza tra "osservabilità" e "rilevamento" è principalmente quali domande fai dei dati.
Per workload di agente specificamente, quella convergenza è utile. Le domande "perché questo è lento", "cosa ha cambiato l''agente" e "ha sfuggito qualcosa alla sua sandbox" sono tutte risposte dallo stesso stream di evento. Praticamente, questo significa che un''organizzazione che distribuisce agenti con accesso al sistema dovrebbe trattare la visibilità a livello kernel come parte della distribuzione, non un afterthought — è l''unico livello che produce evidenza auditable di cosa un processo autonomo ha realmente fatto.
La caveat onesta è il volume. Il tracing a livello kernel può generare stream di evento enormi, e il logging ingenuo di ogni syscall su un nodo occupato soprafffarà la tua archiviazione e la tua capacità di trovare qualsiasi cosa. Filtrare alla fonte — per percorso, per processo, per tipo di evento — non è un''ottimizzazione ma un requisito, ed è dove vive la maggior parte del lavoro operativo in questi tool.
Lettura di un profilo senza ingannare te stesso
Il profiling continuo produce molti dati, e ci sono alcuni modi affidabili di leggerlo male. Vale la pena sapere prima che agisci su un flame graph.
La larghezza è campioni, non latenza wall-clock. Un profilo CPU mostra dove è andato il tempo di CPU. Se il tuo servizio è lento perché sta aspettando — su un database, un lock, una chiamata di rete — il profilo CPU può sembrare perfettamente sano, perché un thread bloccato non consuma CPU. Questa è la singola diagnosi scorretta più comune: concludendo che non c''è un problema perché il profilo CPU è piatto, quando il problema è il tempo off-CPU. Il profiling wall-clock o off-CPU risponde a quella domanda.
Gli hotspot aggregati non sono necessariamente il tuo problema di latenza. Una funzione che consuma il 30% della CPU del cluster potrebbe essere completamente previsto lavoro di background — serializzazione, compressione, raccolta dei rifiuti. Il segnale interessante è solitamente un cambiamento: questa funzione era del 5% la settimana scorsa e è del 30% ora. È il motivo per cui il confronto importa più del ranking assoluto, e il motivo per cui la raccolta continua batte un singolo snapshot.
La qualità dei simboli forma le conclusioni. I simboli mancanti fanno collapse degli stack in indirizzi hex non utili, e peggio, possono misattribuire il tempo al frame risolvibile più vicino — producendo una risposta sicura e sbagliata. Se un profilo accusa una funzione che non ha senso, sospetta l''unwinding prima di sospettare il codice.
Il campionamento ha un floor. Una funzione che viene eseguita frequentemente ma molto brevemente potrebbe essere sottorepresentata rispetto al suo costo reale, e gli eventi rari ma costosi potrebbero non apparire affatto in una finestra breve. La raccolta continua mitiga questo aggregando su lunghi periodi, che è un altro argomento per sempre-acceso su on-demand.
L''abitudine pratica: usa il profilo per formare un''ipotesi, poi confermala con una misura mirata prima di spendere uno sprint a ottimizzare.
Adottare questo con senso
Una sequenza pragmatica evita il fallimento comune di distribuire tutto e affogare. Inizia con il profiling continuo su un sottoinsieme di nodi. È l''introduzione più a basso rischio, fornisce valore immediatamente (troverai qualcosa di sorprendente nella prima settimana), e ti insegna come si comportano i tuoi kernel e simboli prima che nulla dipenda da esso. Conferma che gli stack si risolvono in nomi di funzione reali; correggi la disponibilità di simboli se non lo fanno.
Poi aggiungi workflow di confronto, perché è dove il payoff si concentra: collega la diffing del profilo nel tuo processo di rilascio in modo che una regressione di CPU sia catturata come un cambiamento di profilo piuttosto che come un avviso di latenza tre giorni dopo.
Aggiungi il tracing a livello di agente quando effettivamente esegui agenti con accesso al sistema. Se i tuoi agenti solo chiamano API e restituiscono testo, il tracing del kernel è eccessivo. Se eseguono comandi, scrivono file o operano su repository, il gap di visibilità è reale e vale la pena chiudere.
E filtra aggressivamente fin dall''inizio. Decidi in anticipo quali percorsi, processi e tipi di evento importano e escludi il resto. È molto più facile ampliare un filtro stretto più tardi che retrofittare il filtraggio su un firehose che stai già archiviando.
Infine, mantieni i tool on-demand affilati. Il profiling continuo ti dice che una funzione è diventata hot e quando; perf, bpftrace e async-profiler rimangono migliori per l''immersione profonda nel perché. Il workflow che funziona è dati continui per rilevamento e storia, tool mirati per diagnosi.
La linea di fondo
eBPF ha spostato l''osservabilità da "allega un profiler quando sospetti un problema" a "i dati già esistono, interrogali", perché l''esecuzione sul lato del kernel con una sandbox verificata ha reso la raccolta sempre-accesa costare meno dell''1% e non richiedere cambiamenti all''applicazione. Parca Agent fornisce questo come profiling CPU continuo, interrogabile per etichetta, di linguaggio misto la cui vera superpotenza è il confronto prima e dopo. La nuova frontiera è applicare la stessa visibilità agli agenti autonomi: AgentSight mostra cosa un agente ha realmente fatto a livello di syscall, chiudendo il gap lasciato dalle tracce di applicazione che solo riportano quello che l''agente ha scelto di narrare. Inizia con il profiling su pochi nodi, verifica i tuoi simboli, costruisci il confronto nei rilasci, aggiungi il tracing dell''agente quando gli agenti toccano sistemi reali, filtra duro fin dall''inizio, e mantieni perf e bpftrace per le immersioni profonde.
Riferimenti e Risorse
Tool
Background e analisi
- 8 Best Open-Source eBPF Tracing Tools in 2026 — Better Stack
- eBPF.io — what is eBPF
- Brendan Gregg on eBPF performance tools
Cheatsheet correlati di 1337skills