Monitoraggio

Che cosa copre questa categoria

Sapere che qualcosa non funziona prima che te lo spieghi un cliente: controlli di uptime, tracciamento degli errori, metriche, log, trace e gli alert che svegliano qualcuno.

I prodotti vanno da un singolo controllo che interroga un URL a piattaforme che acquisiscono tutto ciò che un’infrastruttura emette. Il divario tra i due sta soprattutto in volume di dati e prezzo.

Analizzare il comportamento dei clienti appartiene ad analytics. Dove gira l’applicazione è hosting e cloud.

Parti dall’esterno

Il primo acquisto più utile è il più semplice: un controllo che carica il tuo sito da più punti e ti avvisa quando smette di funzionare.

I controlli esterni intercettano i guasti che le dashboard interne non vedono, tra cui certificati scaduti, record rotti e una modifica al firewall che nessuno ha annunciato. Costano poco, e per molti piccoli team coprono gran parte di ciò che conta.

Il tracciamento degli errori viene per secondo. Sapere quali eccezioni raggiungono gli utenti veri, quanto spesso e da quale rilascio trasforma una segnalazione vaga in una correzione. La qualità del raggruppamento è ciò che distingue i prodotti, perché uno strumento che produce quattromila alert quasi identici produce solo rumore.

I quattro tipi di dati

• Controlli di uptime, dall’esterno, sui percorsi che i clienti usano davvero.
• Errori, raggruppati, con rilascio e contesto dell’utente allegati.
• Metriche, numeriche ed economiche da conservare, per tendenze e soglie.
• Log, dettagliati e costosi, per ricostruire che cosa è successo.
• Trace, che mostrano una richiesta attraverso i servizi, per capire dove va il tempo.

La maggior parte dei team ha bisogno dei primi due subito, delle metriche poco dopo e del resto quando un sistema è abbastanza complesso da rendere inutile tirare a indovinare.

La retention è il vincolo silenzioso. Confrontare oggi con lo stesso giorno del mese scorso richiede un mese di dati, e i piani base spesso ne tengono una settimana.

Gli alert sono un problema di progettazione

Un alert su cui nessuno agisce abitua tutti a ignorare il successivo, e quell’abitudine è il modo in cui le interruzioni si allungano.

Segnala ciò che gli utenti sperimentano e non ogni soglia interna. Una pagina che si carica lentamente conta. Un processore all’ottanta per cento, da solo, di solito no.

Ogni alert ha bisogno di tre cose: un responsabile, un’azione documentata e un canale che raggiunga il responsabile quando dorme. Tutto ciò che non supera questa prova dovrebbe essere una voce di dashboard e non una notifica.

Poi rivedi con regolarità. Gli alert si accumulano, le condizioni cambiano e una potatura trimestrale è il lavoro di affidabilità più economico che esista.

Costi e perché le fatture crescono senza preavviso

I prezzi si basano su host, utenti, volume acquisito o eventi, ed è nel modello a volume che si nascondono le sorprese.

Un solo servizio che scrive log in modo prolisso può moltiplicare la fattura mentre il traffico resta piatto. Campionamento, filtraggio alla fonte e retention più breve per i dati di dettaglio sono i controlli abituali, quindi chiedi che cosa offre il prodotto prima di averne bisogno.

Le metriche personalizzate meritano una domanda specifica, perché spesso si pagano per serie univoca e un’etichetta scelta male può crearne migliaia. Chiedi un limite di spesa e non un semplice avviso, e guarda ciò che le pagine dei prezzi nascondono per il resto dello schema.

Gestirlo in proprio

Le implementazioni aperte sono valide e gratuite da licenziare. Il costo operativo è reale: storage, retention, aggiornamenti e qualcuno reperibile per il sistema di monitoraggio stesso.

Quest’ultimo punto è quello da pesare. Uno stack in self hosting tende a guastarsi nello stesso incidente della cosa che stava osservando, cioè proprio quando ti serve di più.

Cominciare in piccolo senza chiudersi in un angolo

Una prima configurazione di monitoraggio dovrebbe essere noiosa e finita in un pomeriggio.

Due controlli esterni sui percorsi che contano, il tracciamento degli errori collegato all’applicazione e un canale di alert che raggiunga una persona. Copre la maggior parte degli incidenti che un piccolo prodotto avrà nel primo anno.

Aggiungi le metriche quando cominci a chiederti perché qualcosa è stato lento e non se fosse guasto. Aggiungi i trace quando il sistema ha abbastanza parti in movimento da rendere la risposta non più ovvia da un log.

L’unica decisione da prendere presto è dove si raccolgono i dati e in che formato. La strumentazione scritta su uno standard aperto può essere puntata più tardi su un altro backend, mentre quella scritta sulla libreria di un singolo fornitore diventa un argomento contro il cambiare mai.

Tieni un documento scritto di che cosa significa ogni alert e di chi risponde. Quella pagina vale alle tre di notte più di qualunque dashboard.