Il tuo sito risponde da fuori: come fai a sapere che dentro non è bloccato niente?
In breve
Un sito pubblico non dice niente sul server, sullo storage o sul gateway, perché nessuno di questi è raggiungibile da fuori. Sorvegliarli vuol dire chiedere da dentro la rete — e il confine onesto è che un apparecchio che risponde non è la stessa cosa di un apparecchio che sta facendo il suo lavoro.
Chiedi alla maggior parte delle persone se i loro sistemi funzionano e ti parleranno del sito. È la parte che ha un indirizzo pubblico, la parte che si può controllare da qualsiasi posto, ed è una piccola frazione di quello su cui l’azienda gira davvero.
Il file server non ha un indirizzo pubblico. Non ce l’hanno nemmeno lo storage, l’host di virtualizzazione, la stampante che produce le bolle di consegna, il gateway nel locale tecnico o la macchina in officina che fa lo stesso lavoro dal 2019. Da internet non se ne vede nessuno. È una decisione di sicurezza voluta e giusta, e ha una conseguenza: non puoi controllarli da fuori, quindi quasi nessuno li controlla affatto.
Che cosa vuol dire «dentro la rete», in pratica?
Qualcosa di piccolo che sta sulla stessa rete e fa le domande al posto tuo: un’apparecchiatura leggera su una macchina che avanza, una macchina virtuale, oppure semplicemente un agente su una macchina Linux che hai già.
È la direzione del traffico a renderlo accettabile. Apre una connessione HTTPS verso l’esterno, come fa un browser, e non si apre niente verso l’interno: nessuna porta inoltrata, nessuna VPN, nessun indirizzo pubblico fisso. Le reti dove «potete aprire una porta?» chiude la conversazione sono esattamente le reti dove questa cosa deve funzionare.
Una volta che è lì, può chiedere la raggiungibilità di qualsiasi cosa abbia un indirizzo e — dove le dai le credenziali — numeri veri: processore, memoria, disco e carico su macchine Linux e Windows, valori SNMP da storage, switch, stampanti e gruppi di continuità, lo stato degli host di virtualizzazione e dei controller di gestione dei server. Se vuoi, può guardarsi intorno negli intervalli di rete che dichiari e proporti quello che trova, così non stai a copiare indirizzi da un foglio di calcolo.
Di quale guasto stiamo parlando davvero?
Dell’apparecchio che risponde perfettamente mentre non fa niente. La raggiungibilità è la metà facile; questa è la metà cara.
Un gateway davanti a un impianto di domotica risponderà tranquillamente al suo indirizzo di rete con il bus dietro di lui morto. Un punto dati lasciato in stato forzato o fuori servizio riporta per sempre un valore plausibile. Un’importazione ferma da tre settimane lascia un servizio che risponde ancora a ogni richiesta all’istante, perché non ha niente da fare. In tutti e tre i casi il pallino è verde e il lavoro non sta succedendo.
C’è un modo onesto di prendere queste cose e uno disonesto. Quello disonesto è sostenere che un sistema di monitoraggio possa capire, da fuori, che un apparecchio sta facendo il suo lavoro. Non può. Quello onesto è fare in modo che sia il lavoro stesso a produrre un numero: quanto è vecchio l’ultimo file elaborato, quanti elementi sono in attesa, quanti minuti sono passati dall’ultima volta che un valore è cambiato. Un comando che lo stampa ce l’hai già, oppure lo scrivi in cinque righe. Un monitor a metriche può far girare fino a otto comandi tuoi e trasformare ogni numero stampato in un valore sorvegliato con una soglia di attenzione e una di allarme.
Il trucco è tutto qui, ed è giusto dirlo chiaramente: noi non rileviamo che il tuo sistema ha smesso di funzionare. Sorvegliamo un numero che il tuo sistema produce, e quel numero smette di muoversi.
Che cosa fare questa settimana
- Scrivi l’elenco di quello senza cui l’azienda si fermerebbe, e segna quali di quelle cose hanno un indirizzo pubblico. Quelle non segnate sono il buco.
- Metti una sonda dentro la rete e comincia dalla raggiungibilità di tutto quello che è in elenco. Ci vuole un pomeriggio e cambia già il discorso.
- Aggiungi le credenziali dove ce le hai, così le macchine importanti riportano numeri invece di un pallino.
- Scegli l’unico processo il cui guasto silenzioso farebbe più male e fagli stampare un numero: età del file, profondità della coda, minuti dall’ultimo cambiamento. Sorveglia quel numero.
- Fai in modo che la sonda stessa sia sorvegliata, così che il silenzio da dentro voglia dire qualcosa.
Il monitoraggio da fuori ti dice che cosa vedono i tuoi clienti. Il monitoraggio da dentro ti dice se l’azienda sta ancora lavorando. Non sono la stessa domanda, e di solito una sola delle due viene fatta.
Cosa non possiamo dirti
- Non possiamo vedere un apparecchio che non pubblica nulla: se non ha un modo per farsi interrogare, tutto quello che possiamo dirti è se risponde in rete oppure no.
- Non possiamo leggere un bus di automazione o di domotica — KNX, BACnet e simili: oggi vediamo il gateway che gli sta davanti, non il bus che gli sta dietro.
- Non possiamo dirti da soli che un valore si è congelato. Se un tuo comando stampa da quanto tempo qualcosa non cambia, quel numero lo sorvegliamo e ti avvisiamo — il calcolo deve arrivare dalla tua parte.
- Non possiamo scoprire quello che non hai dichiarato: la sonda guarda soltanto negli intervalli di rete che le dai, e soltanto se accendi il rilevamento.
Le domande che fanno davvero
Perché un servizio fuori può stare benissimo mentre dentro è morto qualcosa?
Perché sono macchine diverse che fanno lavori diversi. Il sito pubblico è la piccola parte dell'azienda che dà sulla strada. Il file server, lo storage, l'host di virtualizzazione, la macchina che stampa le bolle: nessuno di questi è esposto, ed è voluto, quindi da internet nessuno può dirti niente su di loro. Il loro silenzio non è una prova di salute, è solo la prova che sono irraggiungibili.
Devo aprire delle porte o mettere su una VPN?
No, e non dovresti doverlo fare. Una piccola sonda dentro la rete apre una connessione HTTPS verso l'esterno e nient'altro: nessuna porta in entrata, nessuna VPN, nessun indirizzo fisso. È la stessa direzione di traffico di un browser, ed è il motivo per cui funziona in reti dove aprire qualcosa non è nemmeno in discussione.
Che cosa può chiedere davvero a un server o a un'apparecchiatura?
La raggiungibilità di qualsiasi cosa abbia un indirizzo; e con le credenziali, numeri veri: processore, memoria, disco e carico su Linux via SSH, l'equivalente su Windows, valori SNMP da storage, stampanti, switch e gruppi di continuità, e lo stato degli host di virtualizzazione e dei controller di gestione dei server. Ognuno di questi è un numero con una soglia, un grafico e una storia, non un pallino rosso o verde.
Come prendo la cosa che risponde ma ha smesso di lavorare?
Sorvegliando un numero che si muove solo quando il lavoro sta succedendo davvero: l'età dell'ultimo file elaborato, la profondità di una coda, da quanto tempo un valore non cambia. Su un monitor a metriche puoi far girare fino a otto comandi tuoi, e il numero che ognuno stampa diventa un valore sorvegliato con una soglia di attenzione e una di allarme. È così che un lavoro fermatosi in silenzio diventa visibile.
Quanti monitor servono per un server?
In pratica da due a quattro: uno che copra insieme processore, memoria e disco, più uno per ogni servizio che ci gira sopra e che conta. Come ordine di grandezza, cinquanta monitor coprono qualcosa come quindici-venticinque server — utile quando stai capendo quale piano ti serve prima di installare qualsiasi cosa.
Che succede se la sonda perde la connessione?
Continua a controllare e conserva i risultati in locale, poi li rimanda quando il collegamento torna, così la storia non ha buchi e l'interruzione non viene addebitata ai tuoi servizi. E una sonda che smette di riferire è essa stessa un avviso: il silenzio deve voler dire qualcosa, altrimenti non vuol dire niente.