Monitoraggio interno o servizio esterno: come scegliere

Uno script di monitoraggio sono venti righe. È esattamente per questo che la domanda merita una risposta onesta invece di un argomentario: per un sito unico e con poco in gioco, scriverselo da sé è spesso la decisione giusta, e nessuno ha interesse a dirtelo.

Il confronto, sui criteri che decidono

Una sola riga di questa tabella è eliminatoria, ed è la quarta. Tutto il resto si recupera con il tempo; una sonda che muore con la macchina che sorveglia, no. Quella riga viene scartata in fase di progetto e ricordata alle tre del mattino: lo scenario per cui il tuo monitoraggio esiste è esattamente quello in cui una sonda ospitata sulla stessa macchina si è già fermata.

Scriverselo da sé: quando è la scelta giusta

Un sito, un server, una persona. Un cron che interroga la tua home e ti manda una email se il codice non è 200 funziona. Costa una serata e nulla al mese.

Un bisogno particolare. Verificare qualcosa dentro la tua applicazione, la lunghezza di una coda, un numero di business, lo stato preciso di un database: nessun servizio esterno può farlo senza un accesso che non andrebbe dato.

Il piacere di farlo. Una ragione legittima, e spesso la più forte. Uno script che hai scritto tu è uno script che saprai riparare.

Una condizione, in tutti e tre i casi: la sonda deve girare altrove rispetto alla macchina sorvegliata. Una macchina da cinque euro al mese presso un altro fornitore, o un'esecuzione pianificata presso un terzo, basta. Senza di questo hai scritto uno strumento che tace esattamente quando dovrebbe parlare.

I tre muri che si finisce per incontrare

La verifica gira sulla macchina sorvegliata. Se il server cade, lo script cade con lui. Il guasto che nessuno rileva è proprio quello in cui tutto è a terra insieme, ed è per quello che l'avevi scritto.

Lo storico sparisce. Sapere che il sito è giù adesso è la metà facile. Rispondere a «quale disponibilità ha avuto il mese scorso» presuppone di memorizzare ogni verifica, gestire la conservazione e saper ricalcolare un tasso quando era prevista una finestra di manutenzione. È lì che un progetto di un fine settimana diventa un piccolo database da mantenere.

Scala male. Un sito, venti righe. Venti siti, una rotazione di intervalli, falsi allarmi da regolare, avvisi che si fermano senza che nessuno se ne accorga, e un cliente che chiede un report mensile. Organizzare un parco è un mestiere a sé, e non è quello per cui lo script era stato scritto. Il passaggio raramente è una decisione; avviene poco a poco, un sito alla volta, finché un pomeriggio sparisce nel mantenere qualcosa che doveva costare una serata.

Le quattro trappole dello script fatto in casa, nell'ordine in cui si incontrano

Nessuna è insormontabile. Tutte si scoprono dopo, ed è questo il problema.

L'email di avviso non arriva. Un server che spedisce posta dal proprio indirizzo IP finisce nello spam, o da nessuna parte. Te ne accorgi il giorno in cui aspettavi l'avviso, cioè troppo tardi. La correzione è semplice, un servizio di invio transazionale, e aggiunge una dipendenza in più da sorvegliare.

Lo script si ferma senza dirlo. Un aggiornamento di linguaggio, un percorso che cambia, una quota raggiunta: l'attività pianificata fallisce in silenzio. Uno script di monitoraggio ha bisogno di essere monitorato, il che è logicamente scomodo e praticamente vero. La difesa sta in una riga: fagli inviare un segno di vita settimanale, la cui assenza ti allerta.

I falsi positivi finiscono per vincere. Senza conferma né memoria dello stato, uno script manda una email a ogni singhiozzo di rete. Dopo tre settimane nessuno le apre più, e il monitoraggio esiste ancora senza servire a nulla.

Nessun altro sa ripararlo. Il giorno in cui sei in vacanza, lo script è una scatola nera scritta in uno stile personale, senza documentazione. È accettabile per un sito personale, molto meno appena un cliente dipende dalla risposta.

Il costo reale, in tempo

È l'unico argomento serio, ed è quello che i confronti evitano perché non entra in una tabella di prezzi.

Scriverlo costa una serata. Il resto arriva a fette: un'ora quando il fornitore di email cambia le regole, due ore il giorno in cui scade il certificato della tua stessa sonda, mezza giornata per aggiungere lo storico quando un cliente lo chiede, e un pomeriggio la prima volta che scopri che lo script non girava più da sei settimane.

Conta uno o due giorni all'anno, distribuiti nel momento peggiore, sempre mentre stavi facendo altro. Da confrontare con un abbonamento, tenendo presente che la tua giornata vale probabilmente più di quanto costi un anno di quello.

Che cosa compra davvero un servizio esterno

Non la verifica in sé: quella sai scriverla. Compra il punto di vista esterno, lo storico che non hai dovuto archiviare, e il fatto che la cosa continui a girare quando la tua infrastruttura non gira più.

E la parte a cui nessuno pensa all'inizio: qualcun altro la mantiene. Uno script di monitoraggio che ha smesso di funzionare tre mesi fa è peggio di nessun monitoraggio, perché continui a crederti coperto. È il guasto silenzioso più comune del settore, e l'unico che la sua vittima non può rilevare per definizione.

Il montaggio ibrido, che è quello che fanno le squadre serie

Non è un compromesso molle, è la risposta giusta appena il sistema supera un sito.

Il monitoraggio dell'infrastruttura resta da te: disco, memoria, code, numeri di business. Vede quello che un esterno non può vedere, e ha il diritto di cadere con la macchina, visto che è la macchina che descrive.

Il monitoraggio del sito parte dall'esterno: il codice di risposta, il tempo di risposta, il certificato, il contenuto atteso nella pagina. Vede quello che vedono i tuoi visitatori, ed è l'unico punto di vista che resta valido quando tutto il resto è a terra. È anche l'unico che risponde alla domanda a cui il tuo hosting non risponderà mai.

I due non si sostituiscono. Rispondono a due domande diverse, e confonderli è la causa più frequente di un monitoraggio che rassicura senza proteggere.

Una regola di decisione onesta

Parti da quello che perderesti in tre ore di guasto, e dal numero di siti di cui ti occupi. La prima cifra si calcola in cinque minuti, la seconda la conosci già.

• Un sito, poco in gioco → scriviselo da te, fallo girare altrove, e verifica una volta a trimestre che scatti ancora.
• Più siti, o un cliente coinvolto → un servizio esterno si ripaga nel tempo che non passi più a mantenerlo.
• Bisogni profondi dentro l'applicazione → entrambi, a compiti diversi.

Lo stesso arbitrato si ripete, identico, su un altro oggetto: seguire i propri backlink in un foglio di calcolo tenuto a mano regge a lungo, poi smette di reggere esattamente per le stesse ragioni. Il foglio, le sue sette colonne e la sua data di scadenza raccontano la stessa storia con altre righe.

E qualunque sia la tua scelta, la questione dell'intervallo resta intera: si risolve a partire dal costo, non dalla tecnica. La prima cosa da fare poi, il giorno in cui qualcosa cade, è la stessa nei due casi: i primi quindici minuti non dipendono dallo strumento.