Ciao a tutti, Chris qui da agntlog.com. È aprile 2026 e ultimamente ho affrontato alcune sfide interessanti nel monitoraggio degli agenti. In particolare, mi sono concentrato sul mondo dell’‘alerting’ – non solo impostare attivatori di base, ma cercare di rendere gli avvisi utili in un ambiente distribuito e multi-agente. Sai, quel tipo di luogo in cui un singolo agente che va offline non è la fine del mondo, ma un gruppo di essi che colpisce un errore specifico sì.
Per anni, penso che tutti noi siamo stati colpevoli di quello che chiamo “fatica da allerta per difetto.” Attivi un nuovo servizio, aggiungi qualche metrica e poi imposti un avviso per ognuna di esse. CPU oltre l’80%? Allerta! Memoria oltre il 90%? Allerta! Disco pieno? Allerta! E non farmi nemmeno iniziare sui tassi di errore. Cosa succede? La tua casella di posta diventa un cimitero, il tuo canale Slack è un flusso costante di rosso e, abbastanza presto, inizi a silenziare le notifiche perché il 90% di esse sono falsi positivi o rumore non azionabile.
Ho avuto un’esperienza particolarmente negativa con questo l’anno scorso quando abbiamo onboardato un nuovo cliente con una vasta flotta di agenti edge. La loro soluzione di monitoraggio esistente era… diciamo che era entusiasta. Ogni agente aveva circa 20 avvisi individuali configurati. Quando li abbiamo integrati, il loro team operativo riceveva una media di circa 150 avvisi al giorno. Immagina di cercare un vero problema in quel pagliaio. Era impossibile. La mia missione è diventata chiara: dovevamo passare da un sistema di allerta reattivo e ricco di rumore a qualcosa di più intelligente, qualcosa che ci fornisse reali informazioni, non solo ping.
Oltre ai Semplici Soglie: Il Potere dell’Allerta Contestuale
Il problema principale con l’alerting tradizionale è la sua mancanza di contesto. Un picco della CPU su un agente potrebbe essere perfettamente normale durante un lavoro batch specifico. Alcune richieste fallite potrebbero essere solo problemi di rete transitori. Un agente che va offline per 30 secondi potrebbe essere un riavvio programmato. L’avviso stesso non ti dice nulla di tutto ciò. Urla solo “PROBLEMA!”
Il mio focus è cambiato drasticamente su quello che chiamo “alerting contestuale.” Non si tratta solo di guardare una singola metrica in isolamento; si tratta di combinare più segnali, comprendere le basi e persino incorporare logica aziendale nelle tue definizioni di avviso. Si tratta di chiedersi: “Questo è davvero un problema, date tutte le altre informazioni che ho?”
Aggregazione dei Segnali: Non Solo “Un Agente Cattivo,” Ma “Molti Agenti Cattivi”
Una delle prime cose che abbiamo affrontato con quel nuovo cliente è stato l’avviso “singolo agente offline.” Individualmente, un agente che esce dalla rete per un minuto o due non era critico. Avevamo la ridondanza integrata. Ma se il 10% degli agenti di una specifica regione andasse offline simultaneamente? Quella è una questione seria. Il vecchio sistema avrebbe generato 20 avvisi individuali per 20 agenti singoli. Il nuovo approccio aggrega questi.
Invece di allertare su agent_status == 'offline' per un singolo host, abbiamo iniziato a guardare la percentuale di agenti offline all’interno di un gruppo o regione specifica. La maggior parte degli strumenti di monitoraggio moderni supporta questo tipo di aggregazione. Ecco un esempio concettuale utilizzando una query simile a Prometheus, anche se la sintassi esatta varierà:
sum(agent_status{region="us-east-1", status="offline"}) by (region) / count(agent_status{region="us-east-1"}) by (region) > 0.10
Questo avviso si attiverebbe solo se più del 10% degli agenti nella regione ‘us-east-1’ fosse offline. All’improvviso, quegli 20 avvisi individuali diventano uno, altamente azionabile. Questo cambia le regole del gioco per ridurre il rumore e concentrarsi su problemi sistemici piuttosto che su singole anomalie.
Rilevamento delle Anomalie: Cos’è “Normale” Comunque?
Le soglie sono spesso arbitrarie. È cattivo un utilizzo della CPU dell’80%? Dipende. Per un server database, magari. Per una fattoria di rendering, potrebbe essere al 100% tutto il tempo. È qui che il rilevamento delle anomalie brilla davvero. Invece di impostare una soglia fissa, si lascia che il sistema di monitoraggio impari com’è il “normale” per una metrica specifica su un agente o un gruppo di agenti specifici.
Ho fatto molti esperimenti con strumenti di baselining integrati nel nostro stack attuale di osservabilità. Ad esempio, se un agente di solito elabora 100 richieste al secondo e improvvisamente ne elabora 10.000, quella è un’anomalia. Al contrario, se scende a 10 richieste al secondo quando dovrebbe essere a 100, anche quella è un’anomalia. Questi non sono necessariamente “errori” nel senso tradizionale, ma indicano una deviazione significativa dal comportamento atteso che richiede un’indagine.
Il mio team ha recentemente catturato un bug sottile in cui un servizio di agente specifico, dopo una patch, occasionalmente entrava in uno stato in cui elaborava richieste a circa 1/10 della sua normale capacità. Non sono stati registrati errori, la CPU era normale, la memoria era OK. Un semplice avviso sulla soglia non l’avrebbe catturato. Ma un algoritmo di rilevamento delle anomalie, addestrato sul throughput storico, lo ha segnalato immediatamente perché il tasso era sceso significativamente sotto la sua baseline appresa. Non era ‘0’, semplicemente non era ‘normale’. Questo ci ha risparmiato molti mal di testa in seguito.
Il Potere degli Avvisi Compositi: Unire i Punti
Qui è dove l’alerting contestuale diventa davvero interessante. E se combinassi molteplici condizioni per creare un avviso davvero significativo? Ad esempio:
- Allerta se:
CPU > 90% AND memory > 95% AND error_rate > 5%. Questo suggerisce un problema di esaurimento delle risorse più critico, piuttosto che un semplice picco transitorio in una metrica. - Allerta se:
agent_health == 'degraded' AND last_successful_config_update > 24h. Questo indica un problema di gestione della configurazione, non solo un problema di salute generale. - Allerta se:
number_of_agents_offline_in_region > 5 AND external_api_dependency_status == 'healthy'. Questo distingue tra un problema interno dell’agente e un’interruzione del servizio esterno upstream.
Il mio avviso composito recente preferito riguarda un tipo specifico di agente che interagisce con un’API di terze parti. A volte, la loro API restituiva risposte 200 OK, ma il payload era malformato in un modo che il nostro agente non poteva elaborare, portando a errori interni dell’applicazione. Un avviso su solo ‘tasso di errore’ lo avrebbe catturato, ma non ci avrebbe detto perché. Un avviso su ‘tasso di errore’ combinato con ‘numero di risposte API malformate rilevate’ (una metrica personalizzata che abbiamo aggiunto) ci ha immediatamente indicato il problema dell’API esterna, piuttosto che farci prima debug del nostro codice.
# Definizione concettuale dell'avviso composito
# Si supponga di avere metriche:
# agent_app_errors_total (counter)
# external_api_malformed_responses_total (counter)
# Allerta se il tasso di errore dell'applicazione del nostro agente è alto E vediamo risposte malformate
ALERT AgentAppErrorDueToMalformedAPI
IF rate(agent_app_errors_total[5m]) > 0.1 AND rate(external_api_malformed_responses_total[5m]) > 0.05
FOR 1m
LABELS { severity = "critical", team = "backend" }
ANNOTATIONS {
summary = "Alto tasso di errore dell'applicazione dell'agente potenzialmente dovuto a risposte malformate dell'API esterna",
description = "L'agente {{ $labels.instance }} sta riscontrando un alto tasso di errori applicativi, in correlazione con un numero elevato di risposte malformate dall'API esterna. Indagare sull'API upstream e sulla logica di parsing dell'agente."
}
Questo tipo di avviso è incredibilmente potente perché fornisce un contesto immediato per chi risponde all’incidente. Non devono cercare di scavare attraverso dashboard per collegare i punti; l’avviso stesso dice loro da dove cominciare a cercare.
Takeaway Azionabili per un Alerting più Intelligente
Quindi, come inizi a muoverti verso un alerting più intelligente e contestuale senza sentirti sopraffatto? Ecco i miei tre principali takeaway azionabili:
-
Audita i Tuoi Avvisi Esistenti (Senza Pietà): Vai attraverso ogni singolo avviso che hai. Per ognuno, chiediti: “>Quale problema significa davvero questo avviso?” e “Questo avviso è azionabile?” Se non riesci a rispondere chiaramente a entrambe, è un candidato per la rimozione o il perfezionamento. Raccomando una “modalità silenziosa” per i nuovi avvisi inizialmente – inviali a un canale a bassa priorità per una settimana e vedi quanti avrebbero generato rumore.
-
Dai Priorità all’Aggregazione e al Rilevamento delle Anomalie: Dove possibile, allontanati dagli avvisi di soglia a livello di host per servizi non critici. Concentrati sulle metriche a livello di gruppo (es. percentuale di agenti interessati, salute complessiva del servizio). Inizia a sperimentare con il rilevamento delle anomalie per indicatori chiave di prestazione dove soglie statiche non hanno senso. Molte piattaforme di monitoraggio offrono ormai questo di default o come plug-in.
-
Progetta per la Risposta agli Incidenti: Ogni avviso dovrebbe avere un chiaro percorso verso la risoluzione o l’indagine. Quali informazioni ha bisogno chi risponde? Puoi includerle nella notifica dell’avviso stesso? Pensa a come arricchire gli avvisi con link a dashboard, runbook o log specifici. L’obiettivo è ridurre il “tempo per comprendere” un avviso, non solo il “tempo per riceverlo”. Gli avvisi compositi sono eccellenti per questo perché pre-processano il contesto per te.
Passare all’alerting contestuale non è un’interruzione unica. È un processo continuo di perfezionamento, apprendimento e collaborazione tra i team di sviluppo e operazioni. Ma posso dirti per esperienza personale che la riduzione della fatica da avviso e l’aumento delle informazioni significative ne valgono decisamente la pena. La mia casella di posta è notevolmente più silenziosa e, quando un avviso arriva, so che è qualcosa di cui vale la pena occuparsi.
Quali sono le tue maggiori difficoltà con l’alerting? Hai trovato modi ingegnosi per rendere i tuoi avvisi più utili? Fammi sapere nei commenti!
🕒 Published: