Definire gli allarmi con evidenze e percorso di risposta
Un esempio di portale svolto collega tasso di errore, responsabilità e primo controllo. Un allarme da solo non prova né la causa né la risoluzione.
Un allarme utile mostra che cosa non funziona in un’applicazione e quale primo percorso di risposta è previsto. Chi lo riceve deve capirlo senza dover indovinare il servizio da un nome di server sconosciuto.
Dal compito dell’utente al segnale
Parta da un compito importante, come caricare l’elenco dei progetti in un portale clienti. Per i servizi interattivi, Prometheus raccomanda fra l’altro errori visibili all’utente e viste adatte a indagare le cause. Un valore di utilizzo delle risorse può dare contesto; non spiega da solo se l’elenco funziona.
Definisca quali richieste e risposte entrano nella misura. Chiamate ripetute sono richieste aggiuntive, non automaticamente altre persone coinvolte. Il tasso di errore richiede quindi un denominatore chiaro.
Un esempio di allarme svolto
Il team software, le misure e le regole seguenti sono fittizi. Non rappresentano un incidente ASES, soglie universali o un impegno di assistenza. Il denominatore comprende tutte le richieste registrate per l’operazione indicata. La regola valuta una finestra di 5 minuti, senza un ulteriore tempo di permanenza.
Campo | Valore di esempio |
|---|---|
Messaggio | L’elenco dei progetti del portale clienti restituisce errori del server. |
Ambito |
|
Finestra | 09:10–09:15, Europe/Berlin |
Evidenza | 100 richieste, di cui 20 con risposta di errore del server |
Regola di esempio | Oltre il 10 % di errori del server nella finestra di 5 minuti, con almeno 50 richieste. |
Responsabile | Reperibilità di |
Avvio | Vista per esattamente questo servizio, operazione e periodo; runbook «Elenco dei progetti». |
Qui sono superati sia il minimo di richieste sia la soglia di errore. Il 20 % descrive richieste in questa finestra. Non dimostra una quota equivalente di utenti coinvolti né una causa precisa.
Preparare la prima risposta
Il runbook è una breve guida al percorso diagnostico previsto. Prima la persona responsabile conferma la presa in carico e verifica se il problema persiste. La conferma non significa che il guasto sia risolto. I filtri iniziali devono mantenere gli stessi dati di servizio, operazione e periodo.
Poi si delimitano istanze, versioni e dipendenze coinvolte. Una pubblicazione alle 09:08 sarebbe qui un evento da indagare, non una prova della causa. Un ripristino della versione precedente richiede un percorso adatto e verificato prima; l’allarme non autorizza riavvii o modifiche arbitrari.
Verificare anche il percorso della notifica
Alertmanager può raggruppare allarmi simili e inviarli ai destinatari configurati. Le istanze coinvolte devono restare visibili. Problemi indipendenti non devono essere unificati solo perché i nomi si somigliano.
Con una notifica chiaramente contrassegnata come prova, verifichi anche ricezione, presa in carico e percorso di riserva. Prometheus richiede esplicitamente di monitorare lo stesso sistema di monitoraggio. Misure tornate normali possono chiudere lo stato di allarme; non sostituiscono la verifica del compito utente né l’analisi delle cause. Risposte riuscite ma errate sul piano funzionale o risposte lente non sono coperte da questa sola regola sugli errori del server.
Fonti
Continuate a leggere
Tutti gli articoli
Cloud & gestione con ASES
Hosting, deployment, manutenzione e assistenza