Guadagni:
- Capacità di comprendere i tre pilastri dell'osservabilità (metrica, log, traccia) e i quattro segnali d'oro e di fare in modo che l'intelligenza artificiale generi query PromQL, regole di allarme e dashboard
- Capacità di prevenire l'affaticamento degli allarmi mantenendo gli allarmi orientati all'azione e alla giusta urgenza e testando le soglie rispetto ai dati storici del proprio sistema
- Capacità di prevenire la privacy e la fuga di informazioni segrete mascherando le aree sensibili prima di fornire i registri all'intelligenza artificiale
Anche se può sembrare che un sistema funzioni, potrebbe morire al suo interno: la memoria si riempie lentamente, i tempi di risposta aumentano, il tasso di errore aumenta. L'unico modo per accorgersene è monitorare costantemente il sistema. Un concetto più avanzato è l'osservabilità: la capacità di capire cosa sta succedendo all'interno del sistema osservandone i segnali esterni. Esistono tre pilastri dell’osservabilità e il professionista DevOps li utilizza tutti e tre:
- Metrica: valori numerici misurati nel tempo: utilizzo della CPU, numero di richieste, tempo di risposta, tasso di errore. "Quanto?" risponde alla domanda.
- Log: record di eventi di testo prodotti dal sistema: "utente connesso", "connessione al database persa". "Cosa è successo esattamente?" risponde alla domanda.
- Traccia: il percorso seguito da una richiesta nel passaggio da un servizio all'altro all'interno del sistema e la durata di ogni passaggio. “Dov’è la lentezza?” risponde alla domanda.
Strumenti più comuni: Prometheus per le metriche, Grafana per la visualizzazione, Loki/ELK per il log, Jaeger/OpenTelemetry per la traccia. L'intelligenza artificiale è molto abile nella scrittura dei linguaggi di query (in particolare PromQL di Prometheus), delle regole di allarme e delle configurazioni del dashboard per questi strumenti. È anche il luogo in cui l'intelligenza artificiale è più forte: riassume grandi porzioni di log e parametri e segnala anomalie.
Chiariamo la differenza tra monitoraggio e osservabilità in una frase: monitorare è porre domande che già conosci ("La CPU ha superato il 90%?"); l'osservabilità è la capacità di porre domande che non sapevi già ("perché questa strana lentezza si verifica solo per un determinato cliente in un determinato momento?"). I sistemi moderni sono così complessi che non è possibile prevedere tutte le modalità di fallimento; Pertanto, la capacità di raccogliere parametri, log e tracce avanzati e quindi interrogarli in modo approfondito, ovvero l’osservabilità, diventa fondamentale. È qui che l'intelligenza artificiale entra in gioco quando risponde alla "domanda precedentemente sconosciuta": analizza rapidamente i dati grezzi in tuo possesso, suggerisce modelli e anomalie e, verificando questi indizi, arrivi alla causa principale.
Passo dopo passo: cosa e come monitorare?
- Scegli le metriche giuste. Nel settore vengono presi come base i "quattro segnali d'oro": latenza, traffico, errori, saturazione: quanto è piena la risorsa. Questi riepilogano lo stato della maggior parte dei servizi.
- Raccogli le metriche. Consentire all'applicazione di presentare un endpoint che Prometheus può leggere.
- Configura dashboard. Visualizza queste metriche in Grafana.
- Scrivere regole di allarme. Chi verrà avvisato quando viene superata una soglia e come?
- Centralizza i log. Rendi ricercabili tutti i log di servizio in un unico posto.
- Ridurre il rumore. Troppo allarme crea “stanchezza di allerta”; L'allarme importante scompare.
Suggerimento: un buon allarme soddisfa due caratteristiche: è utilizzabile e ha la giusta urgenza. Un allarme che sveglia qualcuno alle 3 del mattino deve essere qualcosa che richiede effettivamente un intervento notturno. Non svegliare nessuno per qualcosa che non richiede un'azione autonoma, come "CPU 70%"; visualizzalo sulla lavagna.
Come scrivere una regola di allarme?
Un avviso è costituito da tre componenti: condizione (quale metrica supera quale soglia e per quanto tempo), durata (“per 5 minuti” per evitare di innescare fluttuazioni momentanee) e importanza/azione (a chi, attraverso quale canale). L’intelligenza artificiale stabilisce magistralmente questi tre con il giusto contesto. Ad esempio, tradurre una regola come "allarme critico se il tasso di errore supera il 5% per 5 minuti" in PromQL è un compito in una frazione di secondo per l'intelligenza artificiale, ma sei tu a decidere se la soglia è adatta al tuo sistema.
Attenzione: le soglie di allarme suggerite dall'AI sono ipotesi generali. Il carico normale, la tolleranza e l'impatto sul lavoro del sistema sono diversi. Prima di inserire una soglia direttamente in produzione, guardi i tuoi dati storici e chiedi "quante volte questa soglia è stata attivata in passato, quante di queste erano problemi reali?" Rispondi alla domanda.
Privacy dei registri: avviso critico
I log sono la fonte di perdite più frequentemente trascurata. Una riga di registro può contenere accidentalmente una password, un numero di carta di credito o dati personali (secondo KVKK/GDPR). Quando incolli i log in un'intelligenza artificiale per l'analisi:
- Maschera le aree sensibili. Sostituisci valori come token, password, email, numero ID con <REDACTED>.
- Fornisci esempi, non tutti. Invece di un milione di righe, spesso sono sufficienti poche centinaia di righe rappresentative.
- Scegli un veicolo approvato dall'istituzione. Soprattutto per i registri di produzione, utilizzare uno strumento i cui dati non vanno alla formazione.
Quattro segnali dorati e tabelle di allarme
segnale
misurato da
Esempio di soglia di allarme
urgenza
latenza
tempo di risposta
p95 > 800 ms, 5 min
alto
traffico
Richiesta/sec
Aumento/diminuzione improvviso del 300%.
medio
Errore
Tasso di richieste non riuscite
> 5%, 5 minuti
critico
Saturazione
occupazione delle risorse
Disco > 85%
alto
tre mini custodie
Caso 1: 400 righe di registro riepilogate in 30 secondi. Un servizio era rallentato. L'ingegnere ha consegnato le 400 righe di registro mascherate all'intelligenza artificiale e ha detto: "riassumi i modelli di errore ricorrenti e l'intensità temporale". L'intelligenza artificiale ha dimostrato che una particolare chiamata API esterna scade ogni 30 secondi. Causa principale trovata in 30 secondi; La scansione manuale dei registri richiederebbe mezz'ora.
Caso 2: problema dell'allarme risolto. Un team riceveva 200 allarmi al giorno e li ignorava tutti, finché non passava inosservato anche un allarme di interruzione reale. Dai all'IA tutte le regole di allerta e chiedi "quali non sono utilizzabili e quali possono essere combinate?" hanno chiesto. Il numero degli allarmi è sceso a 12 al giorno; Ogni allarme veniva ormai preso sul serio.
Caso 3: soglia errata rilevata in anticipo. YZ ha suggerito "Avvisa quando è pieno al 95%" per il disco. L'ingegnere ha guardato i dati storici: una volta che il disco ha raggiunto il 95% c'era poco tempo per intervenire. Ha abbassato la soglia all’80% e ha aggiunto un secondo allarme basato sul “tasso di crescita”. La verifica ha impedito un'effettiva interruzione di mezzanotte.
Quattro modelli copiabili
1) Riepilogo del registro (mascherato):
Analizza l'esempio di log qui sotto (ho mascherato i valori sensibili con <REDACTED>). Dammi: (1) schemi di errore ricorrenti, (2) concentrazione nel tempo, (3) causa principale più probabile e (4) 3 parametri che esaminerò per verificare. Registro: [LINEE]
2) Generazione regole di allarme:
Scrivere una regola di allarme per Prometheus/Alertmanager: Genera allarme [SEVERITÀ] se [SOGLIA] supera [METRICO][DURATA]. La regola deve essere orientata all'azione e includere un campo di annotazione e collegamento al runbook. Spiega PromQL e scrivi perché questa soglia è ragionevole.
3) Scrittura/dichiarazione della query PromQL:
Scrivi una query PromQL che misuri: [EX. 5xxpercentuale di tasso di errore negli ultimi 5 minuti]. Spiega la domanda passo dopo passo. Allora dimmi quale dovrebbe essere l'intervallo salutare per questo valore.
4) Progettazione del cruscotto:
Progetta una dashboard Grafana per [SERVIZIO]: con quali pannelli dovrei visualizzare i quattro segnali d'oro (latenza, traffico, errore, saturazione)? Suggerisci metrica, tipo di visualizzazione e soglia ragionevole per ciascun pannello. Scopo: vedere lo stato di salute di una guardia in 10 secondi.
Prompt debole / Prompt forte
Debole: "Cosa c'è in quel registro?" (seguito da 5000 righe di registro grezzo, token al suo interno)
Risultato: si trapelano segreti e l'intelligenza artificiale fornisce un riassunto superficiale e non mirato.
Forte: "Trova modelli di errore ricorrenti e intensità temporale nell'esempio di registro mascherato di 300 righe di seguito; dimmi la causa principale più probabile e le metriche che esaminerò per verificare. Ho creato i token <REDACTED>."
Differenza: il secondo prompt fornisce un esempio mascherato e focalizzato, chiedendo un chiaro output dell'analisi; È sicuro e utile.
Errori comuni
- Incollare il log in AI senza mascherarlo. La fuga di dati segreti/personali più comune.
- Impostazione allarmi per tutto. La fatica dell’allarme nasconde l’allarme reale.
- Allarme non attivabile. È un rumore di avvertimento contro il quale nessuno può fare nulla.
- Accettare la soglia dell’IA senza fare domande. La soglia deve essere impostata in base alla cronologia del sistema.
- Basta guardare la metrica. Senza registrazione e tracciamento, nella maggior parte dei casi non è possibile individuare la causa principale.
- Non impostare l'ora della sveglia (per). Le fluttuazioni momentanee producono falsi allarmi.
In sintesi
Osservabilità; È la capacità di comprendere l’interno del sistema dall’esterno con metriche, log e tracce. I quattro segnali dorati (latenza, traffico, errore, saturazione) riassumono lo stato della maggior parte dei servizi. L'intelligenza artificiale è molto potente nella scrittura di query PromQL, regole di allarme e dashboard, nonché nel riepilogo di grandi porzioni di registri e nell'individuazione di anomalie. Ma è tua responsabilità verificare le soglie di allarme rispetto alla cronologia del tuo sistema, mantenere gli allarmi orientati all'azione e non condividere mai i registri senza mascherarli.
Compito dell'applicazione
Per un servizio (o un servizio di esempio): (1) Generare una regola di allarme per il tasso di errore con il modello "Generazione di regole di allarme" e impostare la soglia suggerita su "quante volte si è attivata in passato?" Mettilo alla prova con la domanda; (2) mascherare un campione di log in tuo possesso e farlo analizzare con il modello "Riepilogo log"; (3) annota quale metrica esaminerai per confermare la causa principale più probabile.
lista di controllo
- [ ] Ho scelto le metriche da monitorare in base a quattro segnali d'oro.
- [ ] Ho mascherato tutti i log che ho fornito all'IA in termini di aree sensibili.
- [ ] Ho verificato che ciascun allarme fosse orientato all'azione e della corretta urgenza.
- [ ] Ho testato le soglie di allarme rispetto ai dati storici del mio sistema.
- [ ] Ho filtrato le fluttuazioni istantanee aggiungendo for (durata) agli allarmi.
- [ ] Ho usato metrica + log + traccia insieme per la causa principale.