Surveillance de sites web : surveiller l'accessibilité et les pannes

Un site Web peut tomber en panne à tout moment, même s'il fonctionnait encore parfaitement quelques minutes auparavant. Des problèmes de serveur, des mises à jour défectueuses, des pannes DNS, des certificats expirés ou des problèmes d'application peuvent faire en sorte que les visiteurs ne puissent soudainement plus accéder à un site Web.

Ceux qui ne visitent leur propre site web qu'occasionnellement ne remarquent parfois de telles pannes que des heures plus tard ou par le biais d'une remarque de clients.

La surveillance de sites Web automatise ce contrôle. Un service de surveillance externe appelle régulièrement un site Web et vérifie s'il est accessible et comment le point de terminaison surveillé répond.

Dans cet article, nous expliquons comment fonctionne la surveillance de sites web, quelles sont les méthodes de test disponibles, comment distinguer les fausses alertes des pannes réelles et quelles sont les limites d'un simple contrôle de disponibilité.

En bref : La surveillance de site Web vérifie automatiquement votre site à intervalles réguliers. Si une erreur définie est détectée, la surveillance peut déclencher une alarme afin que vous remarquiez une panne sans avoir à contrôler constamment le site vous-même.

Qu'est-ce que la surveillance de sites Web ? #

La surveillance de sites Web consiste à vérifier régulièrement un site Web ou un service spécifique à l'aide d'un système externe.

Un processus simple ressemble par exemple à ceci :

Système de surveillance
        ↓
appelle le site web
        ↓
le serveur répond
        ↓
la réponse est analysée
        ↓
tout va bien ?
   ↙              ↘
  oui             non
  ↓                ↓
prochain        nouvelle vérification /
contrôle        alerte

Ces examens sont automatisés et peuvent être effectués 24 heures sur 24.

Pourquoi le monitoring externe est-il utile ? #

Un site Web ne peut pas déterminer de manière fiable par lui-même s'il n'est plus accessible de l'extérieur.

Par exemple, si le serveur complet, le réseau ou la résolution DNS tombe en panne, un système de surveillance exécuté au sein de la même infrastructure peut également être affecté.

Un monitoring externe examine en revanche le site web du point de perspective d'un système situé en dehors de l'infrastructure surveillée.

Conseil pratique : Pour la surveillance de l'accessibilité publique, au moins un test doit être effectué depuis l'extérieur de l'infrastructure d'hébergement proprement dite.

Que peut surveiller la surveillance de sites web ? #

Le terme surveillance de sites web englobe différents types de contrôles.

Selon le système de surveillance, il est par exemple possible de surveiller :

Accessibilité HTTP et HTTPS

Code d'état HTTP

Temps de réponse

contenu de page spécifique

Certificat SSL/TLS

Résolution DNS

Port TCP

Ping

points de terminaison d'API individuels

parcours utilisateurs plus complexes

Tous les moniteurs ne doivent pas nécessairement remplir toutes ces tâches. Les contrôles qui sont pertinents dépendent de ce que tu souhaites réellement surveiller.

Le moniteur HTTP ou HTTPS classique #

Pour un site Web normal, un moniteur HTTP ou HTTPS est généralement le contrôle le plus important.

Le système de surveillance appelle par exemple l'URL suivante :

https://example.com

et évalue la réponse.

Une requête réussie peut, par exemple, recevoir le statut HTTP suivant :

200 OK

Si le site Web répond à la place par une erreur de serveur, le monitoring peut évaluer le test comme ayant échoué.

Nous expliquons les principales réponses HTTP sous Codes d'état HTTP expliqués : 200, 301, 404, 403 et 500.

Un statut HTTP réussi ne signifie pas automatiquement que tout fonctionne #

Une site web peut avec 200 OK répondre tout en ayant un problème fonctionnel.

Par exemple, la page d'accueil pourrait être servie, tandis que :

un formulaire de contact ne fonctionne pas

le panier d'achat comporte une erreur

une fonction de base de données tombe en panne

une connexion ne fonctionne pas

des images ou du code JavaScript manquent

un service externe ne répond pas

Un simple moniteur HTTP confirme donc d'abord seulement que le point de terminaison HTTP surveillé répond conformément aux critères définis.

Contrôle du contenu au lieu du simple code d'état #

Une surveillance avancée peut en outre vérifier si une chaîne de caractères spécifique est présente dans le contenu renvoyé.

Supposons que la rubrique suivante doive toujours être présente sur une page :

Bienvenue chez Example

Le moniteur pourrait ne pas seulement 200 OK vérifier, mais également contrôler si ce texte est effectivement inclus dans la réponse.

Cela permet de détecter certaines erreurs où le serveur Web répond techniquement avec succès, mais ne délivre pas le contenu attendu.

Qu'est-ce qu'un moniteur de mots-clés ou de contenu ? #

Lors d'une vérification de contenu, on recherche un texte ou un motif défini.

Simplifié :

URL accessible ?
      ↓
200 OK ?
      ↓
texte attendu présent ?
      ↓
oui → test réussi

non → perturbation possible

La chaîne de caractères choisie doit être aussi stable que possible.

Un prix en constante évolution, une date ou un nom d'utilisateur dynamique seraient par exemple souvent inappropriés.

Surveillance des redirections #

De nombreux sites Web redirigent automatiquement certaines variantes d'URL.

Par exemple :

http://example.com/

        ↓ 301

https://example.com/

Un système de surveillance peut suivre automatiquement les redirections selon la configuration.

Il est néanmoins utile de savoir quelle URL vous surveillez réellement et quelle réponse est attendue.

Une boucle de redirection accidentelle ou une mauvaise cible de redirection peut sinon provoquer une perturbation.

Vous trouverez plus d'informations sur les redirections permanentes sur Configurer une redirection 301 : rediriger des URL de manière permanente.

Quelle URL doit être surveillée ? #

Pour un site web d'entreprise simple, la page d'accueil est un point de départ évident.

Exemple :

https://example.com

Cependant, pour des applications plus importantes, la page d'accueil à elle seule peut ne pas suffire.

De plus, des points de terminaison centraux peuvent être surveillés, par exemple :

Page d'accueil
Landing page importante
Boutique
Connexion
Point de terminaison API
Point de terminaison d'état ou de santé

Cependant, vous ne devriez pas surveiller aveuglément chaque sous-page. Les points de terminaison décisifs sont ceux dont la panne indique une perturbation pertinente.

Site web accessible, mais WordPress défectueux #

Un serveur Web peut fondamentalement être accessible, tandis que WordPress lui-même provoque une erreur.

Par exemple, une requête avec :

500 Erreur interne du serveur

ou

503 Service indisponible

être répondu.

Un moniteur HTTP peut détecter une telle erreur, bien que le réseau et le serveur Web soient fondamentalement toujours accessibles.

Pourquoi un seul ping ne suffit pas #

Un test de ping ne vérifie pas si votre site web fonctionne correctement.

Il utilise ICMP et répond à une autre question qu'un appel HTTP ou HTTPS.

Simplifié :

Ping
→ un hôte répond-il au protocole ICMP ?

Moniteur HTTP
→ le service Web répond-il
  à une requête HTTP ?

Moniteur de contenu
→ la page fournit-elle en plus
  le contenu attendu ?

Un serveur peut répondre au ping alors que le site Web ne fonctionne pas.

À l'inverse, un site web peut être accessible bien que les paquets ICMP soient bloqués ou fassent l'objet d'un non-réponse.

Important : N'utilisez pas le ping comme seule preuve qu'un site Web fonctionne.

Que signifie l'intervalle de contrôle ? #

Un système de surveillance contrôle un site Web à intervalles réguliers.

Par exemple :

08:00 Test réussi

08:05 Test réussi

08:10 Test échoué

08:15 Test échoué

08:20 Test réussi

Avec un intervalle de vérification de cinq minutes, vous ne savez pas, à la seconde près, dans cet exemple, quand l'incident a commencé entre 08h05 et 08h10 ou s'est terminé entre 08h15 et 08h20.

L'intervalle influence ainsi la résolution temporelle de ta mesure.

Des intervalles plus courts détectent les pannes plus rapidement #

En effectuant une vérification chaque minute, une panne peut généralement être détectée plus rapidement qu'avec une vérification toutes les 15 minutes.

Cependant, un intervalle plus court signifie également davantage de requêtes de surveillance.

L'intervalle approprié dépend de l'importance du service surveillé.

Pour une boutique en ligne critique pour l'activité, une détection plus rapide peut être plus importante que pour un petit site d'information.

Ne pas alerter immédiatement à chaque petite erreur #

Une seule requête échouée ne signifie pas nécessairement que le site Web est réellement en panne.

Les causes possibles à court terme peuvent être, par exemple :

courte perturbation réseau
perte de paquets temporaire
court délai d'attente
problème sur un site de surveillance
surcharge temporaire
courte phase de maintenance

Les systèmes de surveillance professionnels peuvent ainsi confirmer un contrôle infructueux avant de signaler une panne.

Pourquoi les contrôles sont importants #

Supposons qu'un site de surveillance ne puisse pas joindre votre site Web une fois.

Au lieu de déclencher immédiatement une alarme, le système peut effectuer une nouvelle vérification ou utiliser un deuxième site.

Échec du test
        ↓
Test de contrôle
        ↓
toujours une erreur ?
   ↙             ↘
 non             oui
  ↓                ↓
aucune         Panne
alarme         probable

Cela permet de réduire les fausses alarmes inutiles.

Surveillance depuis plusieurs emplacements #

Un service de surveillance peut effectuer des contrôles à partir de différentes régions géographiques.

Cela aide à faire la différence entre une panne mondiale et un problème de réseau régional.

Par exemple :

Zürich      → Erreur
Frankfurt   → OK
Amsterdam   → OK

Cela plaide pour une situation différente de :

Zürich      → Erreur
Frankfurt   → Erreur
Amsterdam   → Erreur

Plusieurs sites fournissent donc un contexte supplémentaire pour le diagnostic des pannes.

Qu'est-ce qu'un délai d'attente ? #

Un système de surveillance n'attend pas indéfiniment une réponse.

Wird innerhalb einer festgelegten Zeit keine ausreichende Antwort empfangen, kann die Prüfung als Timeout gewertet werden.

Ein Timeout bedeutet jedoch nicht automatisch:

Server komplett offline

Er bedeutet zunächst:

erwartete Antwort wurde innerhalb der vorgegebenen Zeit nicht erhalten

Die Ursache muss anschließend diagnostiziert werden.

Antwortzeit ist nicht dasselbe wie Ladezeit #

Viele Monitoring-Systeme zeigen eine Response Time beziehungsweise Antwortzeit an.

Diese Zahl darf nicht automatisch mit der vollständigen Ladezeit einer Website gleichgesetzt werden.

Ein einfacher HTTP-Check lädt möglicherweise nicht dieselben Ressourcen und führt nicht dieselben Browserprozesse aus wie ein echter Besucher.

Für die Analyse der tatsächlichen Website-Performance solltest du deshalb andere Messmethoden verwenden.

Wie du Ladezeiten sinnvoll untersuchst, erklären wir unter Mesurer et évaluer correctement le temps de chargement d'un site web.

Website-Monitoring und PageSpeed messen unterschiedliche Dinge #

Beide Werkzeuge werden gelegentlich miteinander verwechselt.

Surveillance de sites web	Performance-Analyse
prüft regelmäßig Erreichbarkeit und definierte Bedingungen	untersucht Lade- und Nutzungserlebnis
läuft kontinuierlich	wird punktuell oder anhand gesammelter Nutzerdaten ausgewertet
kann Ausfälle alarmieren	zeigt Performance-Probleme und Optimierungspotenzial
beantwortet „Ist der Dienst erreichbar?“	beantwortet „Wie performant ist die Seite?“

Für eine technische Analyse mit Google PageSpeed Insights findest du unsere Anleitung unter Comment utiliser correctement Google PageSpeed Insights.

Was ist Uptime? #

Uptime beschreibt den Anteil eines betrachteten Zeitraums, in dem ein Dienst als verfügbar gemessen wurde.

Par exemple :

99,9 % % Disponibilité

bedeutet nicht, dass eine Website niemals ausfallen darf.

Auch bei sehr hohen Prozentwerten ergibt sich rechnerisch eine bestimmte mögliche beziehungsweise gemessene Ausfallzeit.

Wie diese Werte richtig interpretiert werden, behandeln wir ausführlich unter Temps de fonctionnement et disponibilité : ce que signifie réellement « 99,9 % ».

Monitoring definiert selbst, was „verfügbar“ bedeutet #

Eine wichtige Besonderheit: Ein Uptime-Wert hängt von der verwendeten Messmethode ab.

Ein Monitor könnte beispielsweise festlegen:

HTTP 200
= verfügbar

Timeout
= nicht verfügbar

HTTP 500
= nicht verfügbar

Ein anderer Monitor könnte Weiterleitungen akzeptieren oder zusätzliche Inhaltsprüfungen durchführen.

Deshalb sind Uptime-Werte verschiedener Systeme nicht zwangsläufig direkt miteinander vergleichbar.

Ein Monitoring-Ergebnis ist eine Messung, keine absolute Wahrheit #

Jede Messung findet von einem bestimmten Standort, zu einem bestimmten Zeitpunkt und mit bestimmten Regeln statt.

Cela signifie :

Monitoring-Standort

Netzwerkweg

Prüfintervall

Timeout

erwarteter Status

Bestätigungsprüfungen

beeinflussen das Ergebnis.

Für eine belastbare Diagnose solltest du deshalb bei einer Störung nicht nur den roten Monitoring-Alarm betrachten, sondern die Ursache anschließend technisch überprüfen.

Was kann einen Monitoring-Alarm auslösen? #

Ein Alarm kann zahlreiche Ursachen besitzen.

Par exemple :

Webserver nicht erreichbar

Anwendung antwortet mit Fehler

PHP-Fehler

Datenbankproblem

DNS-Störung

Netzwerkproblem

Firewall-Regel

Timeout

Wartungsarbeiten

fehlerhafte Weiterleitung

SSL-/TLS-Problem

externer Dienst gestört

Der Alarm ist damit der Beginn der Diagnose – nicht automatisch die Diagnose selbst.

Was solltest du nach einem Ausfallalarm zuerst tun? #

Prüfe zunächst, ob du die Störung selbst reproduzieren kannst.

Öffne die überwachte URL und kontrolliere, was tatsächlich passiert.

Wenn möglich, prüfe zusätzlich über eine andere Internetverbindung beziehungsweise ein anderes Netzwerk.

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.

Exemples :

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.

Les causes possibles peuvent être :

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 Vérification du certificat SSL et de HTTPS : identifier les erreurs courantes.

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.

Les causes possibles peuvent être, par exemple :

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 Site web lent : identifier les causes de manière systématique.

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.

Conseil pratique : 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? #

HAUT 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.

Par exemple :

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

ou

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.

Par exemple :

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.

Par exemple :

Startseite liefert 200 OK

aber:

Checkout funktioniert nicht

Der einfache Startseitenmonitor meldet weiterhin HAUT, 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 Site web lent : identifier les causes de manière systématique 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.

Par exemple :

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.

Par exemple :

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

Résumé #

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 HAUT-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.