Strategie di riverifica: confermare un nuovo stato prima di avvisare

Perché un singolo controllo fallito non è un'interruzione

Un risultato di controllo descrive una richiesta, da un luogo, in un momento. Ciascuno di questi tre elementi può essere sbagliato riguardo al sito nel suo insieme. La rete tra una singola postazione di controllo e il tuo server può essere interrotta mentre ogni altro percorso è perfettamente funzionante. Un record DNS può essere ancora in fase di propagazione in una regione ed essere già corretto in quella successiva. L'ambiente di una postazione di controllo può essere incompatibile con qualcosa che il tuo server fa.

Se un sistema di monitoraggio agisse su ogni primo risultato, ti avviserebbe per tutti questi casi e corromperebbe anche le tue statistiche di uptime, poiché l'interruzione registrata non si è mai verificata per i tuoi utenti. Perciò lo stato rilevato, UP o DOWN, viene trattenuto come non verificato finché non viene confermato, e solo allora succede qualcosa a valle: un avviso inviato, un episodio che si apre, il numero di uptime che si muove.

Cosa individua una riverifica

Riverificare da altre ubicazioni è ciò che distingue un cambiamento reale, valido per l'intero sito, da un artefatto locale. I casi che filtra più spesso sono:

• Breve interruzione durante un nuovo deployment, dove il sito torna attivo prima che parta un secondo controllo
• Indisponibilità DNS mentre una modifica di configurazione si propaga, per cui alcuni resolver rispondono e altri no
• Un inserimento locale in blacklist del sito o dell'indirizzo della postazione di controllo, visibile da una sola rete
• Un agente di controllo il cui ambiente è incompatibile con le tecnologie usate dal server
• Problemi di instradamento o di peering sul percorso tra una singola postazione di controllo e il server

I controlli di conferma vengono estratti dalla regione geografica configurata per l'attività di monitoraggio, così che la seconda opinione arrivi dalla stessa parte del mondo in cui si trovano i tuoi utenti, invece che da una postazione qualsiasi disponibile in quel momento.

Le tre strategie di riverifica

HostTracker supporta tre modi per decidere se un nuovo stato è reale.

1. Voto della maggioranza. Quando un controllo restituisce un nuovo stato, il sistema assegna fino a 7 nuove ubicazioni dalla regione geografica dell'attività di monitoraggio per confermarlo. I risultati restituiti vengono raggruppati per stato, e vince il gruppo più numeroso. Supponiamo che un controllo da Miami segnali DOWN, e le riverifiche da New York, Boston e Chicago tornino UP, DOWN, UP. Il DOWN non è confermato e viene scartato, e Miami viene penalizzata: non sarà usata per i controlli di quel sito. Ripeti lo stesso esempio al contrario, con Miami che segnala UP dopo un DOWN e New York e Chicago che confermano UP, e la transizione DOWN-UP viene registrata.

2. Un numero fisso di ubicazioni che confermano DOWN. Qui configuri il numero minimo di riverifiche necessarie per confermare un DOWN, mentre un UP richiede comunque il voto della maggioranza. Con quel numero impostato a 1, nello stesso esempio, basta che Boston da sola riporti DOWN per confermare il DOWN di Miami, anche se New York e Chicago erano in disaccordo.

3. Nessuna riverifica. Il nuovo stato viene sempre confermato non appena viene rilevato. Questo presuppone piena fiducia nel server e negli ambienti delle postazioni di monitoraggio. Si adatta ad alcune esigenze di monitoraggio specifiche, e va scelto con attenzione, perché ogni problema di rete transitorio in una singola postazione diventa un falso avviso e intacca la cifra di uptime.

Scegliere una strategia

1. Parti dal voto della maggioranza. È l'opzione predefinita ed equilibrata: costa qualche secondo in più di tempo di conferma e rimuove quasi tutto il rumore di una singola postazione.
2. Abbassa la soglia di conferma per DOWN quando un avviso rapido vale più di una casella di posta silenziosa. Un'interruzione regionale che solo due ubicazioni possono vedere ti raggiunge comunque, al costo di più falsi positivi.
3. Mantieni il voto della maggioranza per le transizioni UP, qualunque cosa tu imposti per DOWN. Un UP prematuro chiude un incidente ancora in corso e nasconde la coda dell'interruzione dalle tue statistiche.
4. Riserva l'assenza di riverifica a obiettivi che controlli end to end, dove preferisci indagare un avviso spurio piuttosto che attendere la conferma.

Qualunque strategia scegli, puoi riprodurre tu stesso un disaccordo da due reti diverse e confrontare cosa vede ciascuna:

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/

Un 503 da una rete e un 200 da un'altra è lo stesso schema che la riverifica è pensata per risolvere. Se lo stato di fallimento è un 5xx invece di un timeout, il server ha risposto, il che è un problema diverso: vedi 503 Service Unavailable.

Cosa ti offre la conferma

Le riverifiche sono ciò che permette a un sistema di monitoraggio di eseguire controlli frequenti da molti luoghi senza trasformare quella sensibilità in rumore. HostTracker controlla da oltre 300 postazioni in 158 città, quindi ci sono sempre ubicazioni indipendenti disponibili per la seconda opinione, e solo una transizione confermata attiva un avviso via email, SMS, chiamata vocale, Slack, Telegram e altro. Le strategie sopra descritte non sono l'intero insieme possibile, e l'assistenza può valutarne una nuova per una futura versione se il tuo monitoraggio ha un'esigenza che nessuna di esse copre. Vedi monitoraggio distribuito della disponibilità per come viene usata la rete di postazioni di controllo, e il resto della sezione dei concetti di monitoraggio per i termini che ne stanno alla base.