Monitoraggio di siti web: monitorare la disponibilità e le interruzioni

Un sito web può guastarsi in qualsiasi momento, anche se funzionava perfettamente pochi minuti prima. Problemi al server, aggiornamenti difettosi, interruzioni del DNS, certificati scaduti o problemi con un'applicazione possono far sì che i visitatori improvvisamente non riescano più a raggiungere un sito web.

Chi visita il proprio sito web solo occasionalmente potrebbe accorgersi di tali interruzioni solo ore dopo o tramite una segnalazione da parte dei clienti.

Il monitoraggio dei siti web automatizza questo controllo. Un servizio di monitoraggio esterno visita regolarmente un sito web e verifica se è raggiungibile e come risponde l'endpoint monitorato.

In questo articolo spieghiamo come funziona il monitoraggio dei siti web, quali metodi di controllo esistono, come distinguere i falsi allarmi dai malfunzionamenti reali e quali limiti possiede un semplice controllo di uptime.

Breve spiegazione: Il monitoraggio dei siti web controlla automaticamente il tuo sito a intervalli regolari. Se viene rilevato un errore definito, il monitoraggio può attivare un allarme, permettendoti di accorgerti di un guasto senza dover controllare costantemente il sito web in prima persona.

Cos'è il monitoraggio di un sito web? #

Nel monitoraggio dei siti web, un sito web o un determinato servizio viene controllato regolarmente da un sistema esterno.

Un procedimento semplice appare ad esempio così:

Sistema di monitoraggio
        ↓
visita il sito web
        ↓
il server risponde
        ↓
la risposta viene valutata
        ↓
tutto a posto?
   ↙              ↘
  sì               no
  ↓                ↓
prossimo      nuovo controllo /
controllo        allarme

Questi test vengono eseguiti automaticamente e possono essere effettuati 24 ore su 24.

Perché è utile il monitoraggio esterno? #

Un sito web non può stabilire autonomamente in modo affidabile di non essere più raggiungibile dall'esterno.

Se, ad esempio, l'intero server, la rete o la risoluzione DNS si guastano, anche un sistema di monitoraggio in esecuzione all'interno della stessa infrastruttura potrebbe esserne influenzato.

Un monitoraggio esterno, invece, osserva il sito web dalla prospettiva di un'infrastruttura esterna al sistema monitorato.

Consiglio pratico: Per il monitoraggio della raggiungibilità pubblica, dovrebbe essere eseguito almeno un controllo dall'esterno dell'infrastruttura di hosting effettiva.

Cosa può monitorare il monitoraggio di un sito web? #

Il termine monitoraggio di siti web comprende diversi tipi di controlli.

A seconda del sistema di monitoraggio, è possibile ad esempio monitorare:

Accessibilità HTTP e HTTPS

Codice di stato HTTP

Tempo di risposta

determinato contenuto della pagina

Certificato SSL/TLS

Risoluzione DNS

Porta TCP

Ping

singoli endpoint API

flussi di utenti più complessi

Non tutti i monitor devono svolgere tutte queste attività. Quali controlli siano utili dipende da ciò che desideri effettivamente monitorare.

Il classico monitor HTTP o HTTPS #

Per un sito web normale, un monitor HTTP o HTTPS è solitamente il controllo più importante.

Il monitoraggio richiama ad esempio la seguente URL:

https://example.com

e valuta la risposta.

Una richiesta andata a buon fine può essere ad esempio risposta con il seguente stato HTTP:

200 OK

Se il sito Web risponde invece con un errore del server, il monitoraggio può valutare il controllo come fallito.

Spieghiamo le risposte HTTP più importanti alla pagina Codici di stato HTTP spiegati: 200, 301, 404, 403 e 500.

Un codice di stato HTTP di successo non significa automaticamente che tutto funzioni #

Un sito web può 200 OK rispondere e ciononostante avere un problema funzionale.

Ad esempio, la homepage potrebbe essere servita, mentre:

un modulo di contatto non funziona

il carrello ha un errore

una funzione del database si interrompe

un login non funziona

mancano immagini o JavaScript

un servizio esterno non risponde

Un semplice monitor HTTP conferma quindi inizialmente solo che l'endpoint HTTP monitorato risponde secondo i criteri definiti.

Controllo del contenuto anziché solo del codice di stato #

Un monitoraggio avanzato può inoltre verificare se una determinata stringa è presente nel contenuto restituito.

Supponendo che su una pagina dovrebbe essere sempre presente il seguente titolo:

Benvenuti su Example

Il monitor non potrebbe solo 200 OK ma verificare inoltre se questo testo è effettivamente incluso nella risposta.

Ciò consente di rilevare determinati errori in cui il server web risponde tecnicamente con successo, ma non eroga il contenuto atteso.

Cos'è un monitor di parole chiave o di contenuti? #

Durante un controllo dei contenuti viene cercato un testo o un pattern definito.

In sintesi:

URL raggiungibile?
      ↓
200 OK?
      ↓
testo atteso presente?
      ↓
sì → verifica riuscita

no → possibile guasto

La stringa selezionata dovrebbe essere il più possibile stabile.

Un prezzo in continua evoluzione, una data o un nome utente dinamico, ad esempio, sarebbero spesso inadatti.

Monitoraggio dei reindirizzamenti #

Molti siti web reindirizzano automaticamente determinate varianti di URL.

Per esempio:

http://example.com/

        ↓ 301

https://example.com/

Un sistema di monitoraggio può tracciare automaticamente i reindirizzamenti a seconda della configurazione.

È comunque utile sapere quale URL stai effettivamente monitorando e quale risposta ti aspetti.

Un ciclo di reindirizzamento accidentale o una destinazione di reindirizzamento errata potrebbero altrimenti causare un'interruzione.

Maggiori informazioni sulle reindirizzamenti permanenti sono disponibili alla voce Configurazione del reindirizzamento 301: reindirizzare gli URL in modo permanente.

Quale URL dovrebbe essere monitorato? #

Per un semplice sito aziendale, la home page è un punto di partenza ovvio.

Esempio:

https://example.com

Tuttavia, per applicazioni più importanti, la sola pagina iniziale potrebbe non essere sufficiente.

Inoltre, è possibile monitorare gli endpoint centrali, ad esempio:

Pagina iniziale

importante pagina di destinazione

Negozio

Accedi

Endpoint API

Endpoint di stato o di controllo dello stato

Tuttavia, non dovresti monitorare ciecamente ogni singola sottopagina. Quelli che contano sono gli endpoint la cui interruzione indica un'interruzione rilevante.

Sito Web raggiungibile, ma WordPress è danneggiato #

Un web server può fondamentalmente essere raggiungibile, mentre WordPress stesso causa un errore.

Ad esempio, una richiesta con:

Errore interno del server

o:

503 Servizio non disponibile

essere risposto.

Un monitor HTTP può rilevare un tale errore, sebbene la rete e il server web siano fondamentalmente ancora raggiungibili.

Perché un solo ping non basta #

Un test di ping non verifica se il tuo sito web funziona correttamente.

Usa ICMP e risponde a una domanda diversa rispetto a una chiamata HTTP o HTTPS.

In sintesi:

Ping
→ un host risponde a ICMP?

HTTP-Monitor
→ il servizio web risponde
  a una richiesta HTTP?

Content-Monitor
→ la pagina fornisce anche
  il contenuto previsto?

Un server può rispondere al ping mentre il sito web non funziona.

Viceversa, un sito web può essere raggiungibile anche se i pacchetti ICMP vengono bloccati o non ricevono risposta.

Importante: Non usare il ping come unica prova che un sito web funziona.

Cosa significa l'intervallo di controllo? #

Un sistema di monitoraggio controlla un sito web a intervalli specifici.

Per esempio:

08:00 Esame superato

08:05 Esame superato

08:10 Esame fallito

08:15 Esame fallito

08:20 Esame superato

Con un intervallo di controllo di cinque minuti, in questo esempio non sai con precisione al secondo quando sia iniziata l'interruzione tra le 08:05 e le 08:10 o quando sia terminata tra le 08:15 e le 08:20.

L'intervallo influenza quindi la risoluzione temporale della tua misurazione.

Intervalli più brevi rilevano le anomalie più rapidamente #

Se viene controllato ogni minuto, un guasto può solitamente essere rilevato più rapidamente rispetto a un controllo ogni 15 minuti.

Tuttavia, un intervallo più breve significa anche un maggior numero di richieste di monitoraggio.

L'intervallo appropriato dipende dall'importanza del servizio monitorato.

Per un negozio online di importanza critica per il business, un rilevamento più rapido può essere più importante che per un piccolo sito informativo.

Non allarmare subito per ogni singolo errore #

Una singola richiesta fallita non significa necessariamente che il sito web sia effettivamente offline.

Possibili cause a breve termine potrebbero essere, ad esempio:

breve interruzione della rete
perdita temporanea di pacchetti
breve timeout
problema in una sede di monitoraggio
sovraccarico temporaneo
breve fase di manutenzione

I sistemi di monitoraggio professionali possono quindi confermare un controllo fallito prima che venga segnalato un guasto.

Perché i controlli periodici sono importanti #

Supponendo che una sede di monitoraggio non riesca a raggiungere il tuo sito web una volta.

Invece di far scattare subito l'allarme, il sistema può effettuare un nuovo controllo o utilizzare una seconda posizione.

Controllo fallito
        ↓
Controllo di verifica
        ↓
ancora errore?
   ↙             ↘
 no             sì
  ↓                ↓
nessun          Guasto
allarme         probabile

Ciò consente di ridurre i falsi allarmi non necessari.

Monitoraggio da più posizioni #

Un servizio di monitoraggio può effettuare controlli da diverse regioni geografiche.

Questo aiuta a distinguere tra un blackout globale e un problema di rete regionale.

Per esempio:

Zurigo      → Errore
Francoforte → OK
Amsterdam   → OK

Questo depone a favore di una situazione diversa rispetto a:

Zurigo      → Errore
Francoforte → Errore
Amsterdam   → Errore

Diverse sedi forniscono quindi un contesto aggiuntivo nella diagnostica degli errori.

Cos'è un timeout? #

Un sistema di monitoraggio non attende indefinitamente una risposta.

Se non si riceve una risposta sufficiente entro un tempo stabilito, il controllo può essere considerato scaduto per timeout.

Tuttavia, un timeout non significa automaticamente:

Server completamente offline

Significa prima di tutto:

la risposta attesa non è stata ricevuta entro il tempo stabilito

La causa deve quindi essere diagnosticata.

Il tempo di risposta non è la stessa cosa del tempo di caricamento #

Molti sistemi di monitoraggio mostrano un tempo di risposta.

Questo numero non deve essere equiparato automaticamente al tempo di caricamento completo di un sito web.

Un semplice controllo HTTP potrebbe non caricare le stesse risorse e non eseguire gli stessi processi del browser di un vero visitatore.

Per l'analisi delle prestazioni effettive del sito web, dovresti quindi utilizzare altri metodi di misurazione.

Ti spieghiamo come analizzare in modo sensato i tempi di caricamento su Misurare e valutare correttamente il tempo di caricamento del sito web.

Il monitoraggio dei siti web e il PageSpeed misurano cose diverse #

Entrambi gli strumenti vengono occasionalmente confusi l'uno con l'altro.

Monitoraggio di siti web	Analisi delle prestazioni
verifica regolarmente la reperibilità e le condizioni definite	esamina l'esperienza di ricarica e utilizzo
funziona continuamente	viene valutato puntualmente o sulla base di dati degli utenti raccolti
può segnalare guasti	mostra problemi di prestazioni e potenziale di ottimizzazione
risponde „Il servizio è raggiungibile?“	risponde „Quanto è performante il sito?“

Per un'analisi tecnica con Google PageSpeed Insights, trovi la nostra guida su Usare correttamente Google PageSpeed Insights.

Che cos'è l'uptime? #

L'uptime descrive la percentuale di un determinato periodo di tempo in cui un servizio è stato misurato come disponibile.

Per esempio:

99,9 % Disponibilità

non significa che un sito web non possa mai guastarsi.

Anche in presenza di percentuali molto elevate, dal punto di vista del calcolo risulta un determinato tempo di inattività possibile o misurato.

Trattiamo in modo approfondito come interpretare correttamente questi valori alla pagina Uptime e disponibilità: cosa significa davvero 99,9 %.

Il monitoraggio definisce autonomamente cosa significa „disponibile“ #

Un'importante particolarità: un valore di uptime dipende dal metodo di misurazione utilizzato.

Un monitor potrebbe, ad esempio, stabilire:

HTTP 200
= disponibile

Timeout
= non disponibile

HTTP 500
= non disponibile

Un altro monitor potrebbe accettare reindirizzamenti o eseguire ulteriori controlli dei contenuti.

Ecco perché i valori di uptime di sistemi diversi non sono necessariamente direttamente comparabili.

Un risultato di monitoraggio è una misurazione, non una verità assoluta #

Ogni misurazione avviene da una determinata posizione, in un determinato momento e con determinate regole.

Questo significa:

Sito di monitoraggio

Percorso di rete

Intervallo di controllo

Timeout

stato previsto

Controlli di conferma

influenzano il risultato.

Per una diagnosi affidabile, in caso di anomalia non dovresti quindi limitarti a osservare l'allarme rosso di monitoraggio, ma verificare successivamente la causa a livello tecnico.

Cosa può attivare un allarme di monitoraggio? #

Un allarme può avere numerose cause.

Per esempio:

Server web non raggiungibile
L'applicazione risponde con un errore
Errore PHP
Problema di database
Problema DNS
Problema di rete
Regola del firewall
Timeout
Lavori di manutenzione
Reindirizzamento errato
Problema SSL/TLS
Servizio esterno non disponibile

L'allarme è quindi l'inizio della diagnosi – non automaticamente la diagnosi stessa.

Cosa dovresti fare per primo dopo un allarme di guasto? #

Verifica prima se riesci a riprodurre tu stesso il guasto.

Apri l'URL monitorato e controlla cosa succede effettivamente.

Se possibile, verifica inoltre tramite un'altra connessione Internet o un'altra rete.

Successivamente dovresti circoscrivere il tipo di errore.

Il monitoraggio segnala un errore
        ↓
Visitare autonomamente il sito web
        ↓
Errore riproducibile?
        ↓
Controllare lo stato HTTP
        ↓
Controllare la risoluzione DNS
        ↓
Controllare SSL/HTTPS
        ↓
Interessata solo una pagina o
l'intero sito web?
        ↓
Indagare ulteriormente su hosting / applicazione /
rete

Documentare l'errore del browser #

Se noti tu stesso un'anomalia, documenta il messaggio di errore esatto.

Uno screenshot può essere utile in questo caso.

Nota anche:

Momento
URL interessata
Stato HTTP, se noto
Durata del disservizio
funzioni interessate
rete utilizzata
ripetibile o sporadico?

Queste informazioni facilitano notevolmente una successiva analisi tecnica.

Controllare lo stato HTTP in caso di guasto #

Uno stato HTTP può fornire un primo indizio importante.

Esempi:

403 Forbidden
→ accesso negato

404 Not Found
→ URL richiesto non trovato

500 Internal Server Error
→ errore interno del server

502 Bad Gateway
→ errore di comunicazione tra i servizi

503 Service Unavailable
→ servizio attualmente non disponibile

504 Gateway Timeout
→ risposta del server upstream
  non ricevuta in tempo

Tuttavia, un codice di stato da solo non indica sempre la causa specifica.

Rilevare problemi DNS #

Se un nome di dominio non può essere risolto correttamente, il sito Web non può essere raggiunto tramite il suo nome di dominio nonostante il server Web funzioni.

Un allarme di monitoraggio può quindi essere causato anche da problemi DNS.

Le domande tipiche durante la diagnosi sono:

Il dominio viene risolto?

Quale indirizzo IP viene restituito?

I nameserver autorevoli sono raggiungibili?

I record DNS sono stati modificati di recente?

È interessato un solo resolver o una sola regione?

Tuttavia, non si dovrebbe presumere automaticamente che il DNS sia la causa di ogni guasto del sito web.

Rilevare problemi SSL/TLS #

Su un sito web HTTPS, un problema con il certificato o con la connessione TLS può fare sì che un monitor valuti il controllo come non riuscito.

Le possibili cause possono essere:

Certificato scaduto

Certificato non ancora valido

L'hostname non corrisponde

Catena di certificati non valida

Connessione TLS fallita

Trattiamo come controllare sistematicamente HTTPS e certificati in Controllo del certificato SSL e HTTPS: individuare gli errori comuni.

Sito web non accessibile solo ai singoli visitatori #

Non ogni irraggiungibilità segnalata è un'interruzione globale del sito web.

Se è interessato un solo visitatore, potrebbero esserci cause locali, ad esempio:

Connessione internet

risolutore DNS locale

Browser

VPN

Firewall

Rete aziendale

Routing tra reti

Il monitoraggio esterno da più posizioni aiuta a determinare se il sito web non è raggiungibile in generale o solo attraverso determinati percorsi di rete.

Il sito web è solo sporadicamente lento o non raggiungibile #

I problemi intermittenti sono tra gli errori più difficili perché spesso il sito web funziona già di nuovo durante il test manuale.

Le possibili cause possono essere, ad esempio:

picchi di carico a breve termine
carenze di risorse
interrogazioni del database lente
chiamate API esterne
processi cron o in background
processi di backup
problemi di rete
errori applicativi sporadici

Quale sia la causa effettiva non può essere dedotto dal solo allarme di monitoraggio.

Spieghiamo una diagnosi sistematica delle prestazioni e degli errori su Sito web lento: trovare sistematicamente le cause.

Perché i timestamp sono così importanti #

In caso di guasti sporadici, il momento esatto è spesso cruciale.

Se un monitoraggio, ad esempio, segnala:

GIÙ: 14:37:22

SU: 14:41:08

è possibile analizzare in modo mirato i log di server, di applicazioni o di altro tipo tecnico per questo periodo.

Senza un'indicazione temporale precisa, la ricerca della causa è molto più difficile.

Consiglio pratico: Conserva sempre l'orario esatto dell'allarme di monitoraggio in caso di guasti ricorrenti. „Il sito web è stato lento a un certo punto ieri“ è molto meno utile per una diagnosi tecnica rispetto a una finestra temporale concreta.

Cosa significa DOWN? #

Un servizio di monitoraggio definisce spesso un controllo come GIÙ, se i criteri di successo definiti non vengono soddisfatti.

Questo non significa necessariamente che l'intero server fosse spento.

A seconda del monitor, ad esempio, può già:

HTTP 500

Timeout

Errore DNS

Errore SSL

contenuto atteso mancante

ALS GIÙ essere valutati.

Che cosa significa UP? #

SU significa di conseguenza che l'esame attuale soddisfa i criteri di successo definiti.

Anche in questo caso vale la regola:

SU ≠ la garanzia che ogni funzione del sito web funzioni

Un monitor semplice può, ad esempio, confermare che la pagina iniziale 200 OK fornisce. Se il checkout completo di un negozio online funzioni, non è stato ancora testato con questo sistema.

Monitoraggio di un negozio online #

In un negozio online, oltre alla pagina iniziale, altre funzioni possono essere critiche per il business.

Per esempio:

Pagina del negozio

Pagina del prodotto

Carrello

Cassa

Metodo di pagamento

Processo di ordine

Un semplice monitor di uptime non può tuttavia valutare automaticamente se l'intero processo di acquisto funzioni.

Per farlo, sarebbero necessari ulteriori controlli delle transazioni sintetiche o test funzionali.

Non monitorare ciecamente il checkout con normali richieste #

I processi dinamici come il carrello, il checkout, il login o i moduli non dovrebbero essere testati in modo avventato con semplici chiamate di monitoraggio.

Tali pagine possono utilizzare sessioni, cookie, protezione CSRF, token dinamici o altra logica applicativa.

Per i controlli di transazione funzionali, il test deve quindi essere concepito in modo mirato per la rispettiva applicazione.

Monitoraggio di WordPress #

Per un sito web WordPress, la homepage pubblica rappresenta un utile controllo di base.

A seconda dell'importanza del sito web, è possibile monitorare ulteriori pagine pubbliche.

D'altra parte, non dovresti sovraccaricare l'area di amministrazione con tentativi di accesso automatizzati.

Se il sito web pubblico funziona, ma il backend di WordPress è lento o non accessibile, potrebbe trattarsi di un problema diverso rispetto a un'interruzione completa del sito web.

Considerare separatamente frontend e backend #

Ad esempio, un sito Web WordPress può mostrare la seguente situazione:

Frontend
→ funziona

/wp-admin/
→ molto lento

o viceversa:

Server web
→ raggiungibile

WordPress
→ Errore 500

Un risultato di monitoraggio dovrebbe pertanto essere sempre interpretato nel contesto dell'endpoint effettivamente monitorato.

La cache può influenzare i risultati del monitoraggio #

Una homepage memorizzata nella cache può continuare a essere caricata molto velocemente, nonostante vi sia un problema in una sezione dinamica del sito web.

Viceversa, un endpoint non memorizzato nella cache può mostrare tempi di risposta diversi rispetto alla homepage pubblica.

Questo non significa che la memorizzazione nella cache renda il monitoraggio „sbagliato“. Il monitor si limita a misurare l'endpoint che gli hai assegnato.

Ecco perché la scelta di test rappresentativi è fondamentale.

CDN e monitoraggio #

Se un sito web viene distribuito tramite una Content Delivery Network o un reverse proxy, un monitor esterno potrebbe vedere inizialmente questa infrastruttura a monte.

Ciò può portare a situazioni in cui:

CDN accessibile
        ↓
Il server di origine ha un problema
        ↓
I contenuti memorizzati nella cache sono ancora parzialmente accessibili

o:

Origine funziona
        ↓
CDN / Proxy ha un guasto
        ↓
Il visitatore comunque non raggiunge il sito normalmente

Durante la diagnosi dovresti quindi prendere in considerazione quale infrastruttura si trova tra il visitatore e il server web vero e proprio.

Monitoraggio e interventi di manutenzione #

Gli interventi di manutenzione pianificata possono causare intenzionalmente una temporanea inaccessibilità.

I buoni sistemi di monitoraggio consentono pertanto finestre di manutenzione o la messa in pausa temporanea degli allarmi.

In questo modo eviti notifiche inutili durante una manutenzione programmata nota.

Dovresti comunque interpretare correttamente i dati di misurazione: un'interruzione pianificata rimane tecnicamente una fase di disponibilità limitata o assente, anche se non è necessario alcun allarme per essa.

Quali notifiche sono utili? #

Un sistema di monitoraggio può supportare diversi canali di allarme a seconda del fornitore.

Per esempio:

E-Mail

Notifica push

SMS

Messenger

Webhook

Sistema di incidenti

Ciò che conta meno è il numero di canali, quanto piuttosto la questione se una segnalazione rilevante venga effettivamente percepita da una persona competente.

Troppi allarmi sono controproducenti #

Quando un sistema di monitoraggio invia costantemente avvisi irrilevanti, si genera stanchezza da allarme.

I messaggi importanti potrebbero quindi essere ignorati.

Configura quindi:

intervalli di controllo sensati

timeout realistici

verifiche di conferma

endpoint pertinenti

destinatari di allarme idonei

finestre di manutenzione

in considerazione dell'effettivo utilizzo.

Che cos'è un falso positivo? #

Un falso positivo è, in parole semplici, un allarme, sebbene il servizio monitorato non fosse effettivamente interrotto dal punto di vista degli utenti rilevanti.

Ad esempio, potrebbe essere stato interrotto solo il percorso di rete di una singola posizione di monitoraggio.

Ecco perché gli esami ripetuti e le sedi multiple sono utili per i sistemi più importanti.

Cos'è un falso negativo? #

Al contrario, un monitor può valutare un servizio come disponibile, sebbene esista un problema rilevante per i visitatori.

Per esempio:

La homepage restituisce 200 OK

ma:

Il checkout non funziona

Il monitor della home page semplice continua a segnalare SU, sebbene una funzione critica per il business sia compromessa.

Questo mostra un limite centrale di qualsiasi monitoraggio: può verificare solo ciò per cui è stato configurato.

Il monitoraggio non sostituisce i backup #

Il monitoraggio dei siti web e i backup risolvono problemi completamente diversi.

Monitoraggio
→ rileva un guasto

Backup
→ consente il ripristino
  di dati o stati del sistema

Un monitor può, ad esempio, informarti che un sito web non è raggiungibile. Tuttavia, ciò non significa che possieda automaticamente una copia utilizzabile del tuo sito web.

Il monitoraggio non sostituisce la sorveglianza di sicurezza #

Un sito web può essere tecnicamente raggiungibile ed essere stato ciononostante compromesso.

Un normale monitor HTTP non rileva automaticamente:

Codice dannoso
file manipolati
credenziali rubate
amministratori non autorizzati
reindirizzamenti nascosti
esfiltrazione di dati

Il monitoraggio dell'uptime è quindi solo una componente di un monitoraggio tecnico più ampio.

Il monitoraggio non sostituisce l'analisi delle performance #

Un sito web può essere raggiungibile per il 100 percento del tempo misurato ed essere comunque insopportabilmente lento.

Al contrario, un sito web molto veloce può avere interruzioni occasionali.

Ecco perché la disponibilità e le prestazioni dovrebbero essere misurate separatamente.

Se il tuo sito web è raggiungibile ma lento, lo trovi su Sito web lento: trovare sistematicamente le cause un processo diagnostico.

Analizzare i dati di monitoraggio per un lungo periodo #

Il vero valore di un monitoraggio non deriva solo dai singoli allarmi.

Sul lungo periodo possono diventare visibili dei pattern.

Per esempio:

Interruzioni sempre di notte?

Problemi sempre durante i backup?

Timeout solo su una pagina specifica?

Errori solo da una determinata regione?

Tempi di risposta anomali in determinati orari?

Errori 5xx ricorrenti?

Tali modelli possono essere molto più utili nell'analisi delle cause rispetto a un singolo allarme isolato.

Pagine di stato #

Per i servizi più grandi, può essere utile anche una pagina di stato pubblica o interna.

Ad esempio, può mostrare:

Sito web

API

Area clienti

Servizi di posta elettronica

ulteriori sistemi

Tuttavia, una pagina di stato non dovrebbe possibilmente dipendere completamente esattamente dalla stessa infrastruttura di cui deve comunicare il guasto.

Cosa dovrebbe garantire un buon monitoraggio di base? #

Per un normale sito web aziendale, un monitoraggio di base dovrebbe poter rispondere chiaramente almeno a:

Quale URL viene controllato?

Con quale frequenza viene effettuato il controllo?

Quale stato è considerato un successo?

Quanto tempo si attende per una risposta?

Un errore viene confermato?

Quando viene inviato un allarme?

Quando il sito web vienenuovamente considerato UP?

Chi riceve l'allarme?

Solo se questi parametri sono noti, i valori misurati possono essere interpretati in modo sensato.

Documentare correttamente il monitoraggio #

Per i siti web importanti vale la pena fare una breve documentazione del monitoraggio.

Per esempio:

Monitor:
Sito web Homepage

URL:
https://example.com/

Tipo:
HTTPS

Intervallo:
5 minuti

Aspettativa:
HTTP 200

Allarme:
dopo errore confermato

Destinatario:
persona responsabile

Ciò consente anche in seguito di comprendere cosa il monitor abbia effettivamente controllato.

Un tipico flusso di monitoraggio #

Definire il sito web
        ↓
Selezionare l'endpoint importante
        ↓
Determinare il metodo di controllo
        ↓
Stabilire l'intervallo di controllo
        ↓
Definire i criteri di successo
        ↓
Configurare gli avvisi
        ↓
Avviare il monitoraggio
        ↓
Errore rilevato?
        ↓
Controllo di verifica
        ↓
Allarme
        ↓
Riprodurre il guasto
        ↓
Isolare l'errore
        ↓
Risolvere la causa
        ↓
Verificare il ripristino
        ↓
Il monitoraggio conferma UP
        ↓
Documentare l'incidente

Errori frequenti nel monitoraggio dei siti web #

usare solo il ping

confondere 200 OK con un sito web
completamente funzionante

confondere il tempo di risposta con il
tempo di caricamento completo

monitorare solo un
endpoint irrilevante

far scattare un allarme
subito a ogni singolo timeout

configurare troppi
monitor unimportant

non documentare alcun timestamp

non tenere conto della
manutenzione programmata

considerare il monitoraggio come un backup

considerare il monitoraggio come una soluzione di sicurezza

confondere UP con "tutto funziona"

confondere DOWN con "server spento"

Checklist: Configurare il monitoraggio del sito web in modo sensato #

Cosa deve essere monitorato?
        ↓
determinare l'URL pubblico
        ↓
usare HTTP o HTTPS
        ↓
definire lo stato atteso
        ↓
se opportuno verificare il contenuto
        ↓
stabilire l'intervallo di controllo
        ↓
scegliere un timeout sensato
        ↓
attivare il controllo di verifica
        ↓
eventualmente utilizzare più sedi
        ↓
definire i destinatari degli allarmi
        ↓
effettuare un allarme di test
        ↓
considerare le finestre di manutenzione
        ↓
verificare regolarmente i dati di monitoraggio
        ↓
analizzare gli errori ricorrenti

Riepilogo #

Il monitoraggio dei siti web verifica automaticamente se un sito web o un determinato servizio è raggiungibile e soddisfa i criteri di successo definiti.

Per i siti web normali, un monitor HTTPS esterno è un punto di partenza sensato. A seconda del caso d'uso, possono essere utili controlli di contenuto aggiuntivi, ulteriori endpoint o verifiche da più regioni.

Tuttavia, un allarme di monitoraggio non significa automaticamente che l'intero server sia guasto. Anche un timeout, un problema DNS, un errore HTTP, un problema di certificato o un'applicazione non funzionante possono causare un allarme.

Viceversa, un verde SU-Lo stato non garantisce che ogni funzione di un sito web funzioni perfettamente. Un semplice monitor della pagina iniziale, ad esempio, non può valutare un processo d'ordine completo.

Inoltre, il monitoraggio non sostituisce né i backup, né il monitoraggio della sicurezza, né l'analisi delle prestazioni. Questi sistemi rispondono a diverse questioni tecniche.

Il monitoraggio diventa particolarmente prezioso grazie a misurazioni continue, timestamp precisi e un sistema di allerta sensato. In caso di problemi sporadici, questi dati possono aiutare a riconoscere modelli ricorrenti e ad analizzare in modo mirato i log del server o delle applicazioni per il periodo di tempo interessato.

Un buon monitoraggio del sito web non significa quindi configurare quanti più controlli possibili. Ciò che conta è monitorare gli endpoint giusti con criteri chiaramente definiti e, in caso di anomalia, ricevere rapidamente le informazioni necessarie per una diagnosi reale.