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.

Danach solltest du die Art des Fehlers eingrenzen.

Monitoring meldet Fehler
        ↓
Website selbst aufrufen
        ↓
Fehler reproduzierbar?
        ↓
HTTP-Status prüfen
        ↓
DNS-Auflösung prüfen
        ↓
SSL/HTTPS prüfen
        ↓
nur eine Seite oder
ganze Website betroffen?
        ↓
Hosting / Anwendung /
Netzwerk weiter untersuchen

Browser-Fehlermeldung dokumentieren #

Wenn du eine Störung selbst siehst, dokumentiere die genaue Fehlermeldung.

Ein Screenshot kann dabei hilfreich sein.

Notiere außerdem:

Zeitpunkt

betroffene URL

HTTP-Status, falls bekannt

Dauer der Störung

betroffene Funktionen

verwendetes Netzwerk

wiederholbar oder sporadisch?

Diese Informationen erleichtern eine spätere technische Analyse erheblich.

HTTP-Status bei einer Störung prüfen #

Ein HTTP-Status kann einen wichtigen ersten Hinweis liefern.

Esempi:

403 Forbidden
→ Zugriff wird verweigert

404 Not Found
→ angeforderte URL nicht gefunden

500 Internal Server Error
→ serverseitiger Fehler

502 Bad Gateway
→ Problem zwischen beteiligten Diensten

503 Service Unavailable
→ Dienst aktuell nicht verfügbar

504 Gateway Timeout
→ vorgelagerte Antwort
  nicht rechtzeitig erhalten

Ein Statuscode allein nennt jedoch nicht immer die konkrete Ursache.

DNS-Probleme erkennen #

Wenn ein Domainname nicht korrekt aufgelöst werden kann, kann die Website trotz funktionierendem Webserver nicht über ihren Domainnamen erreicht werden.

Ein Monitoring-Alarm kann deshalb auch durch DNS-Probleme entstehen.

Typische Fragen bei der Diagnose sind:

Wird die Domain aufgelöst?

Welche IP-Adresse wird geliefert?

Sind die autoritativen Nameserver erreichbar?

Wurden DNS-Einträge kürzlich geändert?

Ist nur ein Resolver oder
eine Region betroffen?

DNS sollte jedoch nicht bei jedem Website-Ausfall automatisch als Ursache angenommen werden.

SSL-/TLS-Probleme erkennen #

Bei einer HTTPS-Website kann ein Problem mit dem Zertifikat oder der TLS-Verbindung dazu führen, dass ein Monitor die Prüfung als fehlgeschlagen bewertet.

Le possibili cause possono essere:

Zertifikat abgelaufen

Zertifikat noch nicht gültig

Hostname passt nicht

Zertifikatskette fehlerhaft

TLS-Verbindung scheitert

Wie du HTTPS und Zertifikate systematisch kontrollierst, behandeln wir unter Controllo del certificato SSL e HTTPS: individuare gli errori comuni.

Website nur für einzelne Besucher nicht erreichbar #

Nicht jede gemeldete Nichterreichbarkeit ist ein globaler Website-Ausfall.

Wenn nur ein einzelner Besucher betroffen ist, können beispielsweise lokale Ursachen vorliegen:

Internetverbindung

lokaler DNS-Resolver

Browser

VPN

Firewall

Unternehmensnetzwerk

Routing zwischen Netzen

Ein externes Monitoring aus mehreren Standorten hilft dabei festzustellen, ob die Website allgemein oder nur über bestimmte Netzwerkwege nicht erreichbar ist.

Website nur sporadisch langsam oder nicht erreichbar #

Intermittierende Probleme gehören zu den schwierigsten Fehlern, weil die Website beim manuellen Test häufig bereits wieder funktioniert.

Le possibili cause possono essere, ad esempio:

kurzzeitige Lastspitzen

Ressourcenengpässe

langsame Datenbankabfragen

externe API-Aufrufe

Cron- oder Hintergrundprozesse

Backup-Prozesse

Netzwerkprobleme

sporadische Anwendungsfehler

Welche Ursache tatsächlich vorliegt, lässt sich aus dem Monitoring-Alarm allein nicht ableiten.

Eine systematische Performance- und Fehlerdiagnose erklären wir unter Sito web lento: trovare sistematicamente le cause.

Warum Zeitstempel so wichtig sind #

Bei sporadischen Störungen ist der genaue Zeitpunkt oft entscheidend.

Wenn ein Monitoring beispielsweise meldet:

DOWN: 14:37:22

UP:   14:41:08

können Server-, Anwendungs- oder andere technische Logs gezielt für diesen Zeitraum untersucht werden.

Ohne genaue Zeitangabe ist die Suche nach der Ursache deutlich schwieriger.

Consiglio pratico: Bewahre bei wiederkehrenden Störungen immer den exakten Zeitpunkt des Monitoring-Alarms auf. „Die Website war gestern irgendwann langsam“ ist für eine technische Diagnose wesentlich weniger hilfreich als ein konkretes Zeitfenster.

Was bedeutet DOWN? #

Ein Monitoring-Dienst bezeichnet eine Prüfung häufig als DOWN, wenn die definierten Erfolgskriterien nicht erfüllt werden.

Das muss nicht zwingend bedeuten, dass der komplette Server ausgeschaltet war.

Je nach Monitor kann beispielsweise bereits:

HTTP 500

Timeout

DNS-Fehler

SSL-Fehler

fehlender erwarteter Inhalt

ALS DOWN gewertet werden.

Was bedeutet UP? #

SU bedeutet entsprechend, dass die aktuelle Prüfung die definierten Erfolgskriterien erfüllt.

Auch hier gilt:

UP ≠ jede Funktion der Website funktioniert garantiert

Ein einfacher Monitor kann beispielsweise bestätigen, dass die Startseite 200 OK liefert. Ob der komplette Checkout eines Onlineshops funktioniert, wurde damit noch nicht getestet.

Monitoring eines Onlineshops #

Bei einem Onlineshop können neben der Startseite weitere Funktionen geschäftskritisch sein.

Per esempio:

Shop-Seite

Produktseite

Warenkorb

Checkout

Zahlungsanbieter

Bestellprozess

Ein einfacher Uptime-Monitor kann allerdings nicht automatisch beurteilen, ob der gesamte Kaufprozess funktioniert.

Dafür wären weitergehende synthetische Transaktionsprüfungen beziehungsweise funktionale Tests notwendig.

Nicht blind den Checkout mit normalen Requests überwachen #

Dynamische Prozesse wie Warenkorb, Checkout, Login oder Formulare sollten nicht unüberlegt mit simplen Monitoring-Aufrufen getestet werden.

Solche Seiten können Sitzungen, Cookies, CSRF-Schutz, dynamische Tokens oder weitere Anwendungslogik verwenden.

Für funktionale Transaktionsprüfungen muss der Test deshalb gezielt für die jeweilige Anwendung konzipiert werden.

Monitoring von WordPress #

Bei einer WordPress-Website ist die öffentliche Startseite ein sinnvoller Basischeck.

Je nach Bedeutung der Website können zusätzliche öffentliche Seiten überwacht werden.

Den Administrationsbereich solltest du dagegen nicht einfach mit automatisierten Login-Versuchen belasten.

Wenn die öffentliche Website funktioniert, das WordPress-Backend jedoch langsam oder nicht erreichbar ist, handelt es sich möglicherweise um ein anderes Problem als einen vollständigen Website-Ausfall.

Frontend und Backend getrennt betrachten #

Eine WordPress-Website kann beispielsweise folgende Situation zeigen:

Frontend
→ funktioniert

/wp-admin/
→ sehr langsam

oder umgekehrt:

Webserver
→ erreichbar

WordPress
→ Fehler 500

Ein Monitoring-Ergebnis sollte deshalb immer im Kontext des tatsächlich überwachten Endpunkts interpretiert werden.

Cache kann Monitoring-Ergebnisse beeinflussen #

Eine gecachte Startseite kann weiterhin sehr schnell ausgeliefert werden, obwohl ein Problem in einem dynamischen Bereich der Website besteht.

Umgekehrt kann ein ungecachter Endpunkt andere Antwortzeiten zeigen als die öffentliche Startseite.

Das bedeutet nicht, dass Caching das Monitoring „falsch“ macht. Der Monitor misst schlicht den Endpunkt, den du ihm vorgegeben hast.

Deshalb ist die Auswahl repräsentativer Prüfungen entscheidend.

CDN und Monitoring #

Wenn eine Website über ein Content Delivery Network oder einen Reverse Proxy ausgeliefert wird, sieht ein externer Monitor möglicherweise zunächst diese vorgelagerte Infrastruktur.

Das kann zu Situationen führen, in denen:

CDN erreichbar
        ↓
Origin-Server hat Problem
        ↓
gecachter Inhalt teilweise
weiterhin erreichbar

o:

Origin funktioniert
        ↓
CDN / Proxy hat Störung
        ↓
Besucher erreicht Website
trotzdem nicht normal

Bei der Diagnose solltest du deshalb berücksichtigen, welche Infrastruktur zwischen Besucher und eigentlichem Webserver liegt.

Monitoring und Wartungsarbeiten #

Geplante Wartungsarbeiten können absichtlich zu einer vorübergehenden Nichterreichbarkeit führen.

Gute Monitoring-Systeme erlauben deshalb Wartungsfenster beziehungsweise das zeitweise Pausieren von Alarmen.

Dadurch vermeidest du unnötige Benachrichtigungen während einer bekannten geplanten Wartung.

Die Messdaten solltest du dennoch korrekt interpretieren: Ein geplanter Ausfall bleibt technisch eine Phase eingeschränkter oder fehlender Verfügbarkeit, auch wenn dafür kein Alarm notwendig ist.

Welche Benachrichtigungen sind sinnvoll? #

Ein Monitoring-System kann je nach Anbieter unterschiedliche Alarmwege unterstützen.

Per esempio:

E-Mail

Push-Nachricht

SMS

Messenger

Webhook

Incident-System

Entscheidend ist weniger die Anzahl der Kanäle als die Frage, ob eine relevante Meldung tatsächlich von einer zuständigen Person wahrgenommen wird.

Zu viele Alarme sind kontraproduktiv #

Wenn ein Monitoring-System ständig irrelevante Warnungen versendet, entsteht Alarmmüdigkeit.

Wichtige Meldungen werden dann möglicherweise übersehen.

Konfiguriere deshalb:

sinnvolle Prüfintervalle

realistische Timeouts

Bestätigungsprüfungen

relevante Endpunkte

passende Alarmempfänger

Wartungsfenster

mit Blick auf den tatsächlichen Einsatzzweck.

Was ist ein False Positive? #

Ein False Positive ist vereinfacht ein Alarm, obwohl der überwachte Dienst aus Sicht der relevanten Nutzer nicht tatsächlich ausgefallen war.

Beispielsweise könnte nur der Netzwerkweg eines einzelnen Monitoring-Standorts gestört gewesen sein.

Deshalb sind Wiederholungsprüfungen und mehrere Standorte bei wichtigeren Systemen hilfreich.

Was ist ein False Negative? #

Umgekehrt kann ein Monitor einen Dienst als verfügbar bewerten, obwohl für Besucher ein relevantes Problem besteht.

Per esempio:

Startseite liefert 200 OK

aber:

Checkout funktioniert nicht

Der einfache Startseitenmonitor meldet weiterhin SU, obwohl eine geschäftskritische Funktion gestört ist.

Das zeigt eine zentrale Grenze jedes Monitorings: Es kann nur prüfen, wofür es konfiguriert wurde.

Monitoring ersetzt keine Backups #

Website-Monitoring und Backups lösen völlig unterschiedliche Probleme.

Monitoring
→ erkennt eine Störung

Backup
→ ermöglicht Wiederherstellung
  von Daten oder Systemzuständen

Ein Monitor kann dich beispielsweise darüber informieren, dass eine Website nicht erreichbar ist. Er besitzt dadurch aber nicht automatisch eine verwendbare Kopie deiner Website.

Monitoring ersetzt keine Sicherheitsüberwachung #

Eine Website kann technisch erreichbar sein und trotzdem kompromittiert worden sein.

Ein normaler HTTP-Monitor erkennt nicht automatisch:

Schadcode

manipulierte Dateien

gestohlene Zugangsdaten

unerlaubte Administratoren

versteckte Weiterleitungen

Datenabfluss

Uptime-Monitoring ist deshalb nur ein Bestandteil einer umfassenderen technischen Überwachung.

Monitoring ersetzt keine Performance-Analyse #

Eine Website kann 100 Prozent der gemessenen Zeit erreichbar und trotzdem unerträglich langsam sein.

Umgekehrt kann eine sehr schnelle Website gelegentliche Ausfälle besitzen.

Deshalb sollten Verfügbarkeit und Performance getrennt gemessen werden.

Wenn deine Website zwar erreichbar, aber langsam ist, findest du unter Sito web lento: trovare sistematicamente le cause einen Diagnoseablauf.

Monitoring-Daten über längere Zeit auswerten #

Der eigentliche Wert eines Monitorings entsteht nicht nur durch einzelne Alarme.

Über längere Zeit können Muster sichtbar werden.

Per esempio:

Ausfälle immer nachts?

Probleme immer während Backups?

Timeouts nur bei bestimmter Seite?

Fehler nur aus bestimmter Region?

Antwortzeiten zu bestimmten
Zeiten auffällig?

wiederkehrende 5xx-Fehler?

Solche Muster können bei der Ursachenanalyse wesentlich hilfreicher sein als ein einzelner isolierter Alarm.

Statusseiten #

Bei größeren Diensten kann zusätzlich eine öffentliche oder interne Statusseite sinnvoll sein.

Sie kann beispielsweise anzeigen:

Website

API

Kundencenter

E-Mail-Dienste

weitere Systeme

Eine Statusseite sollte jedoch möglichst nicht vollständig von genau derselben Infrastruktur abhängen, deren Ausfall sie kommunizieren soll.

Was sollte ein gutes Basis-Monitoring leisten? #

Für eine normale geschäftliche Website sollte ein Basis-Monitoring mindestens klar beantworten können:

Welche URL wird geprüft?

Wie häufig wird geprüft?

Welcher Zustand gilt als Erfolg?

Wie lange wird auf Antwort gewartet?

Wird ein Fehler bestätigt?

Wann wird alarmiert?

Wann gilt die Website wieder als UP?

Wer erhält den Alarm?

Nur wenn diese Parameter bekannt sind, lassen sich die gemessenen Werte sinnvoll interpretieren.

Monitoring richtig dokumentieren #

Bei wichtigen Websites lohnt sich eine kurze Dokumentation der Überwachung.

Per esempio:

Monitor:
Website Startseite

URL:
https://example.com/

Typ:
HTTPS

Intervall:
5 Minuten

Erwartung:
HTTP 200

Alarm:
nach bestätigtem Fehler

Empfänger:
zuständige Person

Dadurch ist auch später nachvollziehbar, was der Monitor tatsächlich geprüft hat.

Ein typischer Monitoring-Ablauf #

Website definieren
        ↓
wichtigen Endpunkt wählen
        ↓
Prüfmethode bestimmen
        ↓
Prüfintervall festlegen
        ↓
Erfolgskriterien definieren
        ↓
Alarmierung konfigurieren
        ↓
Monitoring starten
        ↓
Fehler erkannt?
        ↓
Kontrollprüfung
        ↓
Alarm
        ↓
Störung reproduzieren
        ↓
Fehler eingrenzen
        ↓
Ursache beheben
        ↓
Wiederherstellung prüfen
        ↓
Monitoring bestätigt UP
        ↓
Vorfall dokumentieren

Häufige Fehler beim Website-Monitoring #

nur Ping verwenden

200 OK mit vollständig
funktionierender Website gleichsetzen

Antwortzeit mit kompletter
Ladezeit verwechseln

nur einen irrelevanten
Endpunkt überwachen

bei jedem einzelnen Timeout
sofort Alarm auslösen

zu viele unwichtige
Monitore konfigurieren

keine Zeitstempel dokumentieren

geplante Wartungen
nicht berücksichtigen

Monitoring als Backup betrachten

Monitoring als Sicherheitslösung betrachten

UP mit "alles funktioniert"
gleichsetzen

DOWN mit "Server ausgeschaltet"
gleichsetzen

Checkliste: Website-Monitoring sinnvoll einrichten #

Was soll überwacht werden?
        ↓
öffentliche URL bestimmen
        ↓
HTTP oder HTTPS verwenden
        ↓
erwarteten Status definieren
        ↓
falls sinnvoll Inhalt prüfen
        ↓
Prüfintervall festlegen
        ↓
Timeout sinnvoll wählen
        ↓
Kontrollprüfung aktivieren
        ↓
ggf. mehrere Standorte nutzen
        ↓
Alarmempfänger festlegen
        ↓
Testalarm durchführen
        ↓
Wartungsfenster berücksichtigen
        ↓
Monitoring-Daten regelmäßig prüfen
        ↓
wiederkehrende Fehler analysieren

Riepilogo #

Website-Monitoring überprüft automatisch, ob eine Website oder ein bestimmter Dienst erreichbar ist und die definierten Erfolgskriterien erfüllt.

Für normale Websites ist ein externer HTTPS-Monitor ein sinnvoller Ausgangspunkt. Je nach Anwendungsfall können zusätzliche Inhaltsprüfungen, weitere Endpunkte oder Prüfungen aus mehreren Regionen sinnvoll sein.

Ein Monitoring-Alarm bedeutet jedoch nicht automatisch, dass der komplette Server ausgefallen ist. Ein Timeout, DNS-Problem, HTTP-Fehler, Zertifikatsproblem oder eine gestörte Anwendung kann ebenfalls einen Alarm verursachen.

Umgekehrt beweist ein grüner SU-Status nicht, dass jede Funktion einer Website einwandfrei arbeitet. Ein einfacher Startseitenmonitor kann beispielsweise keinen vollständigen Bestellprozess beurteilen.

Monitoring ersetzt außerdem weder Backups noch Sicherheitsüberwachung oder Performance-Analyse. Diese Systeme beantworten unterschiedliche technische Fragen.

Besonders wertvoll wird Monitoring durch kontinuierliche Messungen, genaue Zeitstempel und eine sinnvolle Alarmierung. Bei sporadischen Problemen können diese Daten helfen, wiederkehrende Muster zu erkennen und Server- oder Anwendungslogs gezielt für den betroffenen Zeitraum auszuwerten.

Gutes Website-Monitoring bedeutet deshalb nicht, möglichst viele Checks einzurichten. Entscheidend ist, die richtigen Endpunkte mit klar definierten Kriterien zu überwachen und bei einer Abweichung schnell die Informationen zu erhalten, die für eine echte Diagnose benötigt werden.