Serie · 5 articoli

Alertare prima che sia tardi

Dalla saturation predittiva al burn-rate sugli SLO, fino a chi riceve la notifica

Un alert che scatta quando il disco è già pieno ha risposto alla domanda sbagliata. La domanda è sempre la stessa, quando va detto che qualcosa non funziona, e la serie la percorre su tre livelli. Si chiude sul tratto che quasi nessuno cura: cosa succede fra la regola che scatta e la persona che deve agire.

5
Articoli pubblicati
53
Minuti di lettura
Avanzato
Livello
PrometheusAlertmanagerSRESLOPromQLGrafana

Un alert che scatta quando il disco è pieno ha risposto alla domanda sbagliata

La regola copiata dal primo tutorial segnala che il disco è pieno adesso. Quando scatta, l'occupazione è al 90%, i log stanno già fallendo e qualche servizio restituisce ENOSPC. Non è un problema di soglia. La domanda giusta era un'altra: si riempira' entro una finestra in cui posso ancora intervenire senza svegliare nessuno?

La serie percorre tre livelli della stessa domanda. Il primo guarda le risorse fisiche e il trend con cui si consumano. Il secondo sposta il soggetto dalla risorsa all'impatto utente: non quando si satura il disco, ma a che ritmo si sta bruciando l'error budget del servizio. Il terzo si occupa del tratto che quasi nessun repo cura, quello fra la regola che scatta e la persona che deve agire.

Il filo comune è che alertare bene non è una proprietà di una singola query. È una proprietà del sistema intero: dalla metrica alla regola, dalla regola al routing, dal routing al payload, dal payload alla persona che alle tre di notte deve capire cosa fare.

Cosa imparerai

  • Distinguere saturation come stato corrente da saturation come trend, e sapere quale vi serve
  • Riconoscere le quattro trappole della regressione lineare prima di metterla in pager
  • Alertare sul ritmo di consumo dell'error budget invece che su una soglia fissa
  • Installare le tre coppie canoniche del SRE Workbook, e sapere da dove vengono i numeri
  • Instradare per severity, sopprimere i duplicati e mettere un runbook nel payload

Articoli della serie

  1. 01
    USE e Golden Signals non intendono la stessa cosa 11 min

    USE definisce saturation come coda presente, i Golden Signals includono le predizioni. Due framework compatibili, due tipi di alert con profili opposti.

  2. 02
    Quale alert per quale risorsa 11 min

    Cinque esempi PromQL dal TLS al connection pool, le quattro trappole della regressione lineare, e dieci risorse con l'alert che serve a ciascuna.

  3. 03
    La soglia statica risponde alla domanda sbagliata 11 min

    Uno 0,5% sostenuto per un'ora brucia il 30% del budget mensile senza far scattare niente. Alertare sul ritmo di consumo, non sulla soglia.

  4. 04
    Tre coppie di finestre, e perché servono tutte e tre 13 min

    Tabella 5-8 del SRE Workbook riga per riga: 14.4× su 1h+5m, 6× su 6h+30m, 1× su 3d+6h. Da dove vengono i numeri e perché non se ne installa una sola.

  5. 05
    Dopo che l'Alert Scatta: Severity, Routing e il Contratto con Chi lo Riceve 7 min

    Severity come contratto di routing, inhibit rules e runbook_url nel payload: i tre mattoni minimi che rendono un alert Alertmanager azionabile.