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
51
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 10 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 12 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.

    →