{"id":22919,"date":"2026-08-30T09:38:48","date_gmt":"2026-08-30T07:38:48","guid":{"rendered":"https:\/\/www.curiaweb.ch\/?post_type=docs&p=22919"},"modified":"2026-08-30T09:38:49","modified_gmt":"2026-08-30T07:38:49","password":"","slug":"surveillance-de-la-disponibilite-de-site-web","status":"publish","type":"docs","link":"https:\/\/www.curiaweb.ch\/fr\/hilfe\/seo-monitoring\/website-monitoring-erreichbarkeit\/","title":{"rendered":"Surveillance de sites web : surveiller l'accessibilit\u00e9 et les pannes"},"content":{"rendered":"

Un site Web peut tomber en panne \u00e0 tout moment, m\u00eame s'il fonctionnait encore parfaitement quelques minutes auparavant. Des probl\u00e8mes de serveur, des mises \u00e0 jour d\u00e9fectueuses, des pannes DNS, des certificats expir\u00e9s ou des probl\u00e8mes d'application peuvent faire en sorte que les visiteurs ne puissent soudainement plus acc\u00e9der \u00e0 un site Web.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

La surveillance de sites Web automatise ce contr\u00f4le. Un service de surveillance externe appelle r\u00e9guli\u00e8rement un site Web et v\u00e9rifie s'il est accessible et comment le point de terminaison surveill\u00e9 r\u00e9pond.<\/p>\n\n\n\n

Dans cet article, nous expliquons comment fonctionne la surveillance de sites web, quelles sont les m\u00e9thodes de test disponibles, comment distinguer les fausses alertes des pannes r\u00e9elles et quelles sont les limites d'un simple contr\u00f4le de disponibilit\u00e9.<\/p>\n\n\n\n

\n

En bref :<\/strong> La surveillance de site Web v\u00e9rifie automatiquement votre site \u00e0 intervalles r\u00e9guliers. Si une erreur d\u00e9finie est d\u00e9tect\u00e9e, la surveillance peut d\u00e9clencher une alarme afin que vous remarquiez une panne sans avoir \u00e0 contr\u00f4ler constamment le site vous-m\u00eame.<\/p>\n<\/blockquote>\n\n\n\n

Qu'est-ce que la surveillance de sites Web ?<\/h2>\n\n\n\n

La surveillance de sites Web consiste \u00e0 v\u00e9rifier r\u00e9guli\u00e8rement un site Web ou un service sp\u00e9cifique \u00e0 l'aide d'un syst\u00e8me externe.<\/p>\n\n\n\n

Un processus simple ressemble par exemple \u00e0 ceci :<\/p>\n\n\n\n

Syst\u00e8me de surveillance\n        \u2193\nappelle le site web\n        \u2193\nle serveur r\u00e9pond\n        \u2193\nla r\u00e9ponse est analys\u00e9e\n        \u2193\ntout va bien ?\n   \u2199              \u2198\n  oui             non\n  \u2193                \u2193\nprochain        nouvelle v\u00e9rification \/\ncontr\u00f4le        alerte<\/code><\/pre>\n\n\n\n
Ces examens sont automatis\u00e9s et peuvent \u00eatre effectu\u00e9s 24 heures sur 24.<\/p>\n\n\n\n
Pourquoi le monitoring externe est-il utile ?<\/h2>\n\n\n\n
Un site Web ne peut pas d\u00e9terminer de mani\u00e8re fiable par lui-m\u00eame s'il n'est plus accessible de l'ext\u00e9rieur.<\/p>\n\n\n\n
Par exemple, si le serveur complet, le r\u00e9seau ou la r\u00e9solution DNS tombe en panne, un syst\u00e8me de surveillance ex\u00e9cut\u00e9 au sein de la m\u00eame infrastructure peut \u00e9galement \u00eatre affect\u00e9.<\/p>\n\n\n\n
Un monitoring externe examine en revanche le site web du point de perspective d'un syst\u00e8me situ\u00e9 en dehors de l'infrastructure surveill\u00e9e.<\/p>\n\n\n\n
\n
Conseil pratique :<\/strong> Pour la surveillance de l'accessibilit\u00e9 publique, au moins un test doit \u00eatre effectu\u00e9 depuis l'ext\u00e9rieur de l'infrastructure d'h\u00e9bergement proprement dite.<\/p>\n<\/blockquote>\n\n\n\n
Que peut surveiller la surveillance de sites web ?<\/h2>\n\n\n\n
Le terme surveillance de sites web englobe diff\u00e9rents types de contr\u00f4les.<\/p>\n\n\n\n
Selon le syst\u00e8me de surveillance, il est par exemple possible de surveiller :<\/p>\n\n\n\n
Accessibilit\u00e9 HTTP et HTTPS\n\nCode d'\u00e9tat HTTP\n\nTemps de r\u00e9ponse\n\ncontenu de page sp\u00e9cifique\n\nCertificat SSL\/TLS\n\nR\u00e9solution DNS\n\nPort TCP\n\nPing\n\npoints de terminaison d'API individuels\n\nparcours utilisateurs plus complexes<\/code><\/pre>\n\n\n\n
Tous les moniteurs ne doivent pas n\u00e9cessairement remplir toutes ces t\u00e2ches. Les contr\u00f4les qui sont pertinents d\u00e9pendent de ce que tu souhaites r\u00e9ellement surveiller.<\/p>\n\n\n\n
Le moniteur HTTP ou HTTPS classique<\/h2>\n\n\n\n
Pour un site Web normal, un moniteur HTTP ou HTTPS est g\u00e9n\u00e9ralement le contr\u00f4le le plus important.<\/p>\n\n\n\n
Le syst\u00e8me de surveillance appelle par exemple l'URL suivante :<\/p>\n\n\n\n
\nhttps:\/\/example.com\n<\/div><\/figure>\n\n\n\n
et \u00e9value la r\u00e9ponse.<\/p>\n\n\n\n
Une requ\u00eate r\u00e9ussie peut, par exemple, recevoir le statut HTTP suivant :<\/p>\n\n\n\n
200 OK<\/code><\/p>\n\n\n\n
Si le site Web r\u00e9pond \u00e0 la place par une erreur de serveur, le monitoring peut \u00e9valuer le test comme ayant \u00e9chou\u00e9.<\/p>\n\n\n\n
Nous expliquons les principales r\u00e9ponses HTTP sous Codes d'\u00e9tat HTTP expliqu\u00e9s : 200, 301, 404, 403 et 500<\/a>.<\/p>\n\n\n\n
Un statut HTTP r\u00e9ussi ne signifie pas automatiquement que tout fonctionne<\/h2>\n\n\n\n
Une site web peut avec 200 OK<\/code> r\u00e9pondre tout en ayant un probl\u00e8me fonctionnel.<\/p>\n\n\n\n
Par exemple, la page d'accueil pourrait \u00eatre servie, tandis que :<\/p>\n\n\n\n
un formulaire de contact ne fonctionne pas\n\nle panier d'achat comporte une erreur\n\nune fonction de base de donn\u00e9es tombe en panne\n\nune connexion ne fonctionne pas\n\ndes images ou du code JavaScript manquent\n\nun service externe ne r\u00e9pond pas<\/code><\/pre>\n\n\n\n
Un simple moniteur HTTP confirme donc d'abord seulement que le point de terminaison HTTP surveill\u00e9 r\u00e9pond conform\u00e9ment aux crit\u00e8res d\u00e9finis.<\/p>\n\n\n\n
Contr\u00f4le du contenu au lieu du simple code d'\u00e9tat<\/h2>\n\n\n\n
Une surveillance avanc\u00e9e peut en outre v\u00e9rifier si une cha\u00eene de caract\u00e8res sp\u00e9cifique est pr\u00e9sente dans le contenu renvoy\u00e9.<\/p>\n\n\n\n
Supposons que la rubrique suivante doive toujours \u00eatre pr\u00e9sente sur une page :<\/p>\n\n\n\n
Bienvenue chez Example<\/code><\/p>\n\n\n\n
Le moniteur pourrait ne pas seulement 200 OK<\/code> v\u00e9rifier, mais \u00e9galement contr\u00f4ler si ce texte est effectivement inclus dans la r\u00e9ponse.<\/p>\n\n\n\n
Cela permet de d\u00e9tecter certaines erreurs o\u00f9 le serveur Web r\u00e9pond techniquement avec succ\u00e8s, mais ne d\u00e9livre pas le contenu attendu.<\/p>\n\n\n\n
Qu'est-ce qu'un moniteur de mots-cl\u00e9s ou de contenu ?<\/h2>\n\n\n\n
Lors d'une v\u00e9rification de contenu, on recherche un texte ou un motif d\u00e9fini.<\/p>\n\n\n\n
Simplifi\u00e9 :<\/p>\n\n\n\n
URL accessible ?\n      \u2193\n200 OK ?\n      \u2193\ntexte attendu pr\u00e9sent ?\n      \u2193\noui \u2192 test r\u00e9ussi\n\nnon \u2192 perturbation possible<\/code><\/pre>\n\n\n\n
La cha\u00eene de caract\u00e8res choisie doit \u00eatre aussi stable que possible.<\/p>\n\n\n\n
Un prix en constante \u00e9volution, une date ou un nom d'utilisateur dynamique seraient par exemple souvent inappropri\u00e9s.<\/p>\n\n\n\n
Surveillance des redirections<\/h2>\n\n\n\n
De nombreux sites Web redirigent automatiquement certaines variantes d'URL.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
http:\/\/example.com\/\n\n        \u2193 301\n\nhttps:\/\/example.com\/<\/code><\/pre>\n\n\n\n
Un syst\u00e8me de surveillance peut suivre automatiquement les redirections selon la configuration.<\/p>\n\n\n\n
Il est n\u00e9anmoins utile de savoir quelle URL vous surveillez r\u00e9ellement et quelle r\u00e9ponse est attendue.<\/p>\n\n\n\n
Une boucle de redirection accidentelle ou une mauvaise cible de redirection peut sinon provoquer une perturbation.<\/p>\n\n\n\n
Vous trouverez plus d'informations sur les redirections permanentes sur Configurer une redirection 301 : rediriger des URL de mani\u00e8re permanente<\/a>.<\/p>\n\n\n\n
Quelle URL doit \u00eatre surveill\u00e9e ?<\/h2>\n\n\n\n
Pour un site web d'entreprise simple, la page d'accueil est un point de d\u00e9part \u00e9vident.<\/p>\n\n\n\n
Exemple :<\/p>\n\n\n\n
\nhttps:\/\/example.com\n<\/div><\/figure>\n\n\n\n
Cependant, pour des applications plus importantes, la page d'accueil \u00e0 elle seule peut ne pas suffire.<\/p>\n\n\n\n
De plus, des points de terminaison centraux peuvent \u00eatre surveill\u00e9s, par exemple :<\/p>\n\n\n\n
Page d'accueil\nLanding page importante\nBoutique\nConnexion\nPoint de terminaison API\nPoint de terminaison d'\u00e9tat ou de sant\u00e9<\/code><\/pre>\n\n\n\n
Cependant, vous ne devriez pas surveiller aveugl\u00e9ment chaque sous-page. Les points de terminaison d\u00e9cisifs sont ceux dont la panne indique une perturbation pertinente.<\/p>\n\n\n\n
Site web accessible, mais WordPress d\u00e9fectueux<\/h2>\n\n\n\n
Un serveur Web peut fondamentalement \u00eatre accessible, tandis que WordPress lui-m\u00eame provoque une erreur.<\/p>\n\n\n\n
Par exemple, une requ\u00eate avec :<\/p>\n\n\n\n
500 Erreur interne du serveur<\/code><\/p>\n\n\n\n
ou<\/p>\n\n\n\n
503 Service indisponible<\/code><\/p>\n\n\n\n
\u00eatre r\u00e9pondu.<\/p>\n\n\n\n
Un moniteur HTTP peut d\u00e9tecter une telle erreur, bien que le r\u00e9seau et le serveur Web soient fondamentalement toujours accessibles.<\/p>\n\n\n\n
Pourquoi un seul ping ne suffit pas<\/h2>\n\n\n\n
Un test de ping ne v\u00e9rifie pas si votre site web fonctionne correctement.<\/p>\n\n\n\n
Il utilise ICMP et r\u00e9pond \u00e0 une autre question qu'un appel HTTP ou HTTPS.<\/p>\n\n\n\n
Simplifi\u00e9 :<\/p>\n\n\n\n
Ping\n\u2192 un h\u00f4te r\u00e9pond-il au protocole ICMP ?\n\nMoniteur HTTP\n\u2192 le service Web r\u00e9pond-il\n  \u00e0 une requ\u00eate HTTP ?\n\nMoniteur de contenu\n\u2192 la page fournit-elle en plus\n  le contenu attendu ?<\/code><\/pre>\n\n\n\n
Un serveur peut r\u00e9pondre au ping alors que le site Web ne fonctionne pas.<\/p>\n\n\n\n
\u00c0 l'inverse, un site web peut \u00eatre accessible bien que les paquets ICMP soient bloqu\u00e9s ou fassent l'objet d'un non-r\u00e9ponse.<\/p>\n\n\n\n
\n
Important :<\/strong> N'utilisez pas le ping comme seule preuve qu'un site Web fonctionne.<\/p>\n<\/blockquote>\n\n\n\n
Que signifie l'intervalle de contr\u00f4le ?<\/h2>\n\n\n\n
Un syst\u00e8me de surveillance contr\u00f4le un site Web \u00e0 intervalles r\u00e9guliers.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
08:00 Test r\u00e9ussi\n\n08:05 Test r\u00e9ussi\n\n08:10 Test \u00e9chou\u00e9\n\n08:15 Test \u00e9chou\u00e9\n\n08:20 Test r\u00e9ussi<\/code><\/pre>\n\n\n\n
Avec un intervalle de v\u00e9rification de cinq minutes, vous ne savez pas, \u00e0 la seconde pr\u00e8s, dans cet exemple, quand l'incident a commenc\u00e9 entre 08h05 et 08h10 ou s'est termin\u00e9 entre 08h15 et 08h20.<\/p>\n\n\n\n
L'intervalle influence ainsi la r\u00e9solution temporelle de ta mesure.<\/p>\n\n\n\n
Des intervalles plus courts d\u00e9tectent les pannes plus rapidement<\/h2>\n\n\n\n
En effectuant une v\u00e9rification chaque minute, une panne peut g\u00e9n\u00e9ralement \u00eatre d\u00e9tect\u00e9e plus rapidement qu'avec une v\u00e9rification toutes les 15 minutes.<\/p>\n\n\n\n
Cependant, un intervalle plus court signifie \u00e9galement davantage de requ\u00eates de surveillance.<\/p>\n\n\n\n
L'intervalle appropri\u00e9 d\u00e9pend de l'importance du service surveill\u00e9.<\/p>\n\n\n\n
Pour une boutique en ligne critique pour l'activit\u00e9, une d\u00e9tection plus rapide peut \u00eatre plus importante que pour un petit site d'information.<\/p>\n\n\n\n
Ne pas alerter imm\u00e9diatement \u00e0 chaque petite erreur<\/h2>\n\n\n\n
Une seule requ\u00eate \u00e9chou\u00e9e ne signifie pas n\u00e9cessairement que le site Web est r\u00e9ellement en panne.<\/p>\n\n\n\n
Les causes possibles \u00e0 court terme peuvent \u00eatre, par exemple :<\/p>\n\n\n\n
courte perturbation r\u00e9seau\nperte de paquets temporaire\ncourt d\u00e9lai d'attente\nprobl\u00e8me sur un site de surveillance\nsurcharge temporaire\ncourte phase de maintenance<\/code><\/pre>\n\n\n\n
Les syst\u00e8mes de surveillance professionnels peuvent ainsi confirmer un contr\u00f4le infructueux avant de signaler une panne.<\/p>\n\n\n\n
Pourquoi les contr\u00f4les sont importants<\/h2>\n\n\n\n
Supposons qu'un site de surveillance ne puisse pas joindre votre site Web une fois.<\/p>\n\n\n\n
Au lieu de d\u00e9clencher imm\u00e9diatement une alarme, le syst\u00e8me peut effectuer une nouvelle v\u00e9rification ou utiliser un deuxi\u00e8me site.<\/p>\n\n\n\n
\u00c9chec du test\n        \u2193\nTest de contr\u00f4le\n        \u2193\ntoujours une erreur ?\n   \u2199             \u2198\n non             oui\n  \u2193                \u2193\naucune         Panne\nalarme         probable<\/code><\/pre>\n\n\n\n
Cela permet de r\u00e9duire les fausses alarmes inutiles.<\/p>\n\n\n\n
Surveillance depuis plusieurs emplacements<\/h2>\n\n\n\n
Un service de surveillance peut effectuer des contr\u00f4les \u00e0 partir de diff\u00e9rentes r\u00e9gions g\u00e9ographiques.<\/p>\n\n\n\n
Cela aide \u00e0 faire la diff\u00e9rence entre une panne mondiale et un probl\u00e8me de r\u00e9seau r\u00e9gional.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
Z\u00fcrich      \u2192 Erreur\nFrankfurt   \u2192 OK\nAmsterdam   \u2192 OK<\/code><\/pre>\n\n\n\n
Cela plaide pour une situation diff\u00e9rente de :<\/p>\n\n\n\n
Z\u00fcrich      \u2192 Erreur\nFrankfurt   \u2192 Erreur\nAmsterdam   \u2192 Erreur<\/code><\/pre>\n\n\n\n
Plusieurs sites fournissent donc un contexte suppl\u00e9mentaire pour le diagnostic des pannes.<\/p>\n\n\n\n
Qu'est-ce qu'un d\u00e9lai d'attente ?<\/h2>\n\n\n\n
Un syst\u00e8me de surveillance n'attend pas ind\u00e9finiment une r\u00e9ponse.<\/p>\n\n\n\n
Si aucune r\u00e9ponse ad\u00e9quate n'est re\u00e7ue dans un d\u00e9lai d\u00e9termin\u00e9, le test peut \u00eatre consid\u00e9r\u00e9 comme expir\u00e9 (timeout).<\/p>\n\n\n\n
Cependant, un d\u00e9lai d'attente ne signifie pas automatiquement :<\/p>\n\n\n\n
Serveur compl\u00e8tement hors ligne<\/code><\/p>\n\n\n\n
Il signifie d'abord :<\/p>\n\n\n\n
la r\u00e9ponse attendue n'a pas \u00e9t\u00e9 re\u00e7ue dans le d\u00e9lai imparti<\/code><\/p>\n\n\n\n
La cause doit ensuite \u00eatre diagnostiqu\u00e9e.<\/p>\n\n\n\n
Le temps de r\u00e9ponse n'est pas le m\u00eame que le temps de chargement<\/h2>\n\n\n\n
De nombreux syst\u00e8mes de surveillance affichent un temps de r\u00e9ponse.<\/p>\n\n\n\n
Cette valeur ne doit pas \u00eatre automatiquement assimil\u00e9e au temps de chargement complet d'un site Web.<\/p>\n\n\n\n
Une simple v\u00e9rification HTTP peut ne pas charger les m\u00eames ressources et n'ex\u00e9cuter pas les m\u00eames processus de navigateur qu'un vrai visiteur.<\/p>\n\n\n\n
Vous devriez donc utiliser d'autres m\u00e9thodes de mesure pour analyser les performances r\u00e9elles du site web.<\/p>\n\n\n\n
Nous vous expliquons comment analyser judicieusement les temps de chargement sur Mesurer et \u00e9valuer correctement le temps de chargement d'un site web<\/a>.<\/p>\n\n\n\n
Le contr\u00f4le de sites Web et la vitesse de chargement mesurent des choses diff\u00e9rentes<\/h2>\n\n\n\n
Les deux outils sont parfois confondus.<\/p>\n\n\n\n
Surveillance de sites web<\/th>Analyse des performances<\/th><\/tr><\/thead>
v\u00e9rifie r\u00e9guli\u00e8rement la disponibilit\u00e9 et les conditions d\u00e9finies<\/td>examine l'exp\u00e9rience de recharge et d'utilisation<\/td><\/tr>
fonctionne en continu<\/td>est \u00e9valu\u00e9 au cas par cas ou sur la base de donn\u00e9es utilisateurs collect\u00e9es<\/td><\/tr>
peut signaler des pannes<\/td>montre des probl\u00e8mes de performance et un potentiel d'optimisation<\/td><\/tr>
r\u00e9pond \u201e Le service est-il accessible ? \u201c<\/td>r\u00e9pond \u00e0 \u201e Quelle est la performance de la page ? \u201c<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Pour une analyse technique avec Google PageSpeed Insights, vous trouverez nos instructions sur Comment utiliser correctement Google PageSpeed Insights<\/a>.<\/p>\n\n\n\n
Qu'est-ce que l'uptime ?<\/h2>\n\n\n\n
L'uptime d\u00e9crit la proportion d'une p\u00e9riode consid\u00e9r\u00e9e pendant laquelle un service a \u00e9t\u00e9 mesur\u00e9 comme disponible.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
99,9 % % Disponibilit\u00e9<\/code><\/p>\n\n\n\n
ne signifie pas qu'un site Web ne doit jamais tomber en panne.<\/p>\n\n\n\n
M\u00eame pour des pourcentages tr\u00e8s \u00e9lev\u00e9s, il en r\u00e9sulte math\u00e9matiquement un certain temps d'arr\u00eat possible ou mesur\u00e9.<\/p>\n\n\n\n
Nous expliquons en d\u00e9tail comment interpr\u00e9ter correctement ces valeurs sous Temps de fonctionnement et disponibilit\u00e9 : ce que signifie r\u00e9ellement \u00ab 99,9 % \u00bb<\/a>.<\/p>\n\n\n\n
Le monitoring d\u00e9finit lui-m\u00eame ce que signifie \u201e disponible \u201c<\/h2>\n\n\n\n
Une particularit\u00e9 importante : une valeur de disponibilit\u00e9 (uptime) d\u00e9pend de la m\u00e9thode de mesure utilis\u00e9e.<\/p>\n\n\n\n
Un moniteur pourrait par exemple stipuler :<\/p>\n\n\n\n
HTTP 200\n= disponible\n\nTimeout\n= indisponible\n\nHTTP 500\n= indisponible<\/code><\/pre>\n\n\n\n
Un autre moniteur pourrait accepter des redirections ou effectuer des contr\u00f4les de contenu suppl\u00e9mentaires.<\/p>\n\n\n\n
C'est pourquoi les taux de disponibilit\u00e9 de diff\u00e9rents syst\u00e8mes ne sont pas n\u00e9cessairement directement comparables.<\/p>\n\n\n\n
Un r\u00e9sultat de surveillance est une mesure, pas une v\u00e9rit\u00e9 absolue<\/h2>\n\n\n\n
Chaque mesure a lieu \u00e0 partir d'un emplacement sp\u00e9cifique, \u00e0 un moment pr\u00e9cis et selon des r\u00e8gles d\u00e9termin\u00e9es.<\/p>\n\n\n\n
Cela signifie :<\/p>\n\n\n\n
Emplacement de surveillance\nChemin r\u00e9seau\nIntervalle de contr\u00f4le\nD\u00e9lai d'attente\nStatut attendu\nV\u00e9rifications de confirmation<\/code><\/pre>\n\n\n\n
influencent le r\u00e9sultat.<\/p>\n\n\n\n
Pour un diagnostic fiable, vous ne devez donc pas seulement examiner l'alarme de surveillance rouge en cas de dysfonctionnement, mais ensuite v\u00e9rifier techniquement la cause.<\/p>\n\n\n\n
Qu'est-ce qui peut d\u00e9clencher une alarme de surveillance ?<\/h2>\n\n\n\n
Une alarme peut avoir de nombreuses causes.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
Serveur Web inaccessible\nApplication r\u00e9pond avec une erreur\nErreur PHP\nProbl\u00e8me de base de donn\u00e9es\nPanne DNS\nProbl\u00e8me r\u00e9seau\nR\u00e8gle de pare-feu\nD\u00e9lai d'attente d\u00e9pass\u00e9 (Timeout)\nTravaux de maintenance\nRedirection d\u00e9fectueuse\nProbl\u00e8me SSL\/TLS\nService externe perturb\u00e9<\/code><\/pre>\n\n\n\n
L'alarme est donc le d\u00e9but du diagnostic \u2013 et non automatiquement le diagnostic lui-m\u00eame.<\/p>\n\n\n\n
Que devez-vous faire en premier apr\u00e8s une alerte de panne ?<\/h2>\n\n\n\n
V\u00e9rifiez d'abord si vous pouvez reproduire vous-m\u00eame le dysfonctionnement.<\/p>\n\n\n\n
Ouvrez l'URL surveill\u00e9e et v\u00e9rifiez ce qui se passe r\u00e9ellement.<\/p>\n\n\n\n
Si possible, v\u00e9rifiez \u00e9galement via une autre connexion Internet ou un autre r\u00e9seau.<\/p>\n\n\n\n
Ensuite, vous devez cerner la nature de l'erreur.<\/p>\n\n\n\n
La surveillance signale une erreur\n        \u2193\nVisiter le site web soi-m\u00eame\n        \u2193\nErreur reproductible ?\n        \u2193\nV\u00e9rifier le statut HTTP\n        \u2193\nV\u00e9rifier la r\u00e9solution DNS\n        \u2193\nV\u00e9rifier SSL\/HTTPS\n        \u2193\nUne seule page ou\ntout le site web concern\u00e9 ?\n        \u2193\nExaminer plus en d\u00e9tail l'h\u00e9bergement \/ l'application \/\nle r\u00e9seau<\/code><\/pre>\n\n\n\n
Documenter le message d'erreur du navigateur<\/h2>\n\n\n\n
Si tu vois toi-m\u00eame une panne, documente le message d'erreur exact.<\/p>\n\n\n\n
Une capture d'\u00e9cran peut s'av\u00e9rer utile.<\/p>\n\n\n\n
Note \u00e9galement :<\/p>\n\n\n\n
Heure \/ Date\nURL concern\u00e9e\nCode d'\u00e9tat HTTP, si connu\nDur\u00e9e de la panne\nFonctionnalit\u00e9s concern\u00e9es\nR\u00e9seau utilis\u00e9\nReproductible ou sporadique ?<\/code><\/pre>\n\n\n\n
Ces informations facilitent consid\u00e9rablement une analyse technique ult\u00e9rieure.<\/p>\n\n\n\n
V\u00e9rifier le code d'\u00e9tat HTTP en cas de dysfonctionnement<\/h2>\n\n\n\n
Un statut HTTP peut fournir un premier indice important.<\/p>\n\n\n\n
Exemples :<\/p>\n\n\n\n
403 Forbidden\n\u2192 Acc\u00e8s refus\u00e9\n\n404 Not Found\n\u2192 URL demand\u00e9e introuvable\n\n500 Internal Server Error\n\u2192 Erreur interne du serveur\n\n502 Bad Gateway\n\u2192 Mauvaise passerelle\n\n503 Service Unavailable\n\u2192 Service actuellement indisponible\n\n504 Gateway Timeout\n\u2192 D\u00e9lai d'attente de la passerelle d\u00e9pass\u00e9<\/code><\/pre>\n\n\n\n
Cependant, un code d'\u00e9tat \u00e0 lui seul ne donne pas toujours la cause exacte.<\/p>\n\n\n\n
D\u00e9tecter les probl\u00e8mes DNS<\/h2>\n\n\n\n
Si un nom de domaine ne peut pas \u00eatre r\u00e9solu correctement, le site Web ne peut pas \u00eatre atteint via son nom de domaine, malgr\u00e9 un serveur Web fonctionnel.<\/p>\n\n\n\n
Une alarme de surveillance peut donc \u00e9galement \u00eatre d\u00e9clench\u00e9e par des probl\u00e8mes de DNS.<\/p>\n\n\n\n
Les questions types lors du diagnostic sont :<\/p>\n\n\n\n
La zone est-elle r\u00e9solue ?\n\nQuelle adresse IP est renvoy\u00e9e ?\n\nLes serveurs de noms autoritaires sont-ils accessibles ?\n\nDes enregistrements DNS ont-ils \u00e9t\u00e9 modifi\u00e9s r\u00e9cemment ?\n\nUn seul r\u00e9solveur ou une seule r\u00e9gion est-il concern\u00e9 ?<\/code><\/pre>\n\n\n\n
Cependant, il ne faut pas automatiquement supposer que le DNS est la cause de chaque panne de site Web.<\/p>\n\n\n\n
D\u00e9tecter les probl\u00e8mes SSL\/TLS<\/h2>\n\n\n\n
Sur un site Web HTTPS, un probl\u00e8me de certificat ou de connexion TLS peut amener un moniteur \u00e0 consid\u00e9rer le test comme un \u00e9chec.<\/p>\n\n\n\n
Les causes possibles peuvent \u00eatre :<\/p>\n\n\n\n
Certificat expir\u00e9\n\nCertificat pas encore valide\n\nLe nom d'h\u00f4te ne correspond pas\n\nCha\u00eene de certificats invalide\n\n\u00c9chec de la connexion TLS<\/code><\/pre>\n\n\n\n
Nous abordons la mani\u00e8re de contr\u00f4ler syst\u00e9matiquement HTTPS et les certificats dans V\u00e9rification du certificat SSL et de HTTPS : identifier les erreurs courantes<\/a>.<\/p>\n\n\n\n
Site Web inaccessible uniquement pour les visiteurs individuels<\/h2>\n\n\n\n
Toutes les indisponibilit\u00e9s signal\u00e9es ne constituent pas une panne de site Web mondiale.<\/p>\n\n\n\n
Si un seul visiteur est concern\u00e9, il peut y avoir des causes locales, par exemple :<\/p>\n\n\n\n
Connexion Internet\n\nr\u00e9solveur DNS local\n\nNavigateur\n\nVPN\n\nPare-feu\n\nR\u00e9seau d'entreprise\n\nRoutage entre r\u00e9seaux<\/code><\/pre>\n\n\n\n
Une surveillance externe \u00e0 partir de plusieurs emplacements aide \u00e0 d\u00e9terminer si le site Web est inaccessible de mani\u00e8re g\u00e9n\u00e9rale ou seulement par certains chemins r\u00e9seau.<\/p>\n\n\n\n
Site web seulement sporadiquement lent ou inaccessible<\/h2>\n\n\n\n
Les probl\u00e8mes intermittents comptent parmi les bugs les plus difficiles car, lors des tests manuels, le site Web refonctionne souvent d\u00e9j\u00e0.<\/p>\n\n\n\n
Les causes possibles peuvent \u00eatre, par exemple :<\/p>\n\n\n\n
pics de charge de courte dur\u00e9e\ngoulets d'\u00e9tranglement des ressources\nrequ\u00eates de base de donn\u00e9es lentes\nappels d'API externes\nprocessus cron ou d'arri\u00e8re-plan\nprocessus de sauvegarde\nprobl\u00e8mes de r\u00e9seau\nerreurs d'application sporadiques<\/code><\/pre>\n\n\n\n
La cause r\u00e9elle ne peut pas \u00eatre d\u00e9duite de la seule alarme de surveillance.<\/p>\n\n\n\n
Nous expliquons un diagnostic syst\u00e9matique des performances et des erreurs sur Site web lent : identifier les causes de mani\u00e8re syst\u00e9matique<\/a>.<\/p>\n\n\n\n
Pourquoi les horodatages sont si importants<\/h2>\n\n\n\n
En cas de pannes sporadiques, l'heure exacte est souvent d\u00e9cisive.<\/p>\n\n\n\n
Par exemple, si un syst\u00e8me de surveillance signale :<\/p>\n\n\n\n
DESCENTE : 14:37:22\n\nMONT\u00c9E : 14:41:08<\/code><\/pre>\n\n\n\n
les journaux de serveurs, d'applications ou d'autres journaux techniques peuvent \u00eatre examin\u00e9s de mani\u00e8re cibl\u00e9e pour cette p\u00e9riode.<\/p>\n\n\n\n
Sans indication pr\u00e9cise de l'heure, la recherche de la cause est nettement plus difficile.<\/p>\n\n\n\n
\n
Conseil pratique :<\/strong> En cas de pannes r\u00e9currentes, conservez toujours l'heure exacte de l'alerte de surveillance. \u201e Le site Web \u00e9tait lent \u00e0 un moment donn\u00e9 hier \u201c est beaucoup moins utile pour un diagnostic technique qu'une plage horaire pr\u00e9cise.<\/p>\n<\/blockquote>\n\n\n\n
Que signifie DOWN ?<\/h2>\n\n\n\n
Un service de surveillance qualifie souvent un contr\u00f4le de BAS<\/code>, si les crit\u00e8res de succ\u00e8s d\u00e9finis ne sont pas remplis.<\/p>\n\n\n\n
Cela ne signifie pas n\u00e9cessairement que le serveur complet \u00e9tait \u00e9teint.<\/p>\n\n\n\n
Selon le moniteur, il est par exemple d\u00e9j\u00e0 possible de :<\/p>\n\n\n\n
HTTP 500\n\nD\u00e9lai d\u00e9pass\u00e9\n\nErreur DNS\n\nErreur SSL\n\ncontenu attendu manquant<\/code><\/pre>\n\n\n\n
als BAS<\/code> \u00eatre pris en compte.<\/p>\n\n\n\n
Que signifie UP ?<\/h2>\n\n\n\n
HAUT<\/code> signifie par cons\u00e9quent que l'examen actuel r\u00e9pond aux crit\u00e8res de r\u00e9ussite d\u00e9finis.<\/p>\n\n\n\n
C'est \u00e9galement le cas ici :<\/p>\n\n\n\n
UP \u2260 garantie que chaque fonction du site Web fonctionne<\/code><\/p>\n\n\n\n
Un moniteur simple peut par exemple confirmer que la page d'accueil 200 OK<\/code> liefert. Ob der komplette Checkout eines Onlineshops funktioniert, wurde damit noch nicht getestet.<\/p>\n\n\n\n
Monitoring eines Onlineshops<\/h2>\n\n\n\n
Bei einem Onlineshop k\u00f6nnen neben der Startseite weitere Funktionen gesch\u00e4ftskritisch sein.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
Shop-Seite\n\nProduktseite\n\nWarenkorb\n\nCheckout\n\nZahlungsanbieter\n\nBestellprozess<\/code><\/pre>\n\n\n\n
Ein einfacher Uptime-Monitor kann allerdings nicht automatisch beurteilen, ob der gesamte Kaufprozess funktioniert.<\/p>\n\n\n\n
Daf\u00fcr w\u00e4ren weitergehende synthetische Transaktionspr\u00fcfungen beziehungsweise funktionale Tests notwendig.<\/p>\n\n\n\n
Nicht blind den Checkout mit normalen Requests \u00fcberwachen<\/h2>\n\n\n\n
Dynamische Prozesse wie Warenkorb, Checkout, Login oder Formulare sollten nicht un\u00fcberlegt mit simplen Monitoring-Aufrufen getestet werden.<\/p>\n\n\n\n
Solche Seiten k\u00f6nnen Sitzungen, Cookies, CSRF-Schutz, dynamische Tokens oder weitere Anwendungslogik verwenden.<\/p>\n\n\n\n
F\u00fcr funktionale Transaktionspr\u00fcfungen muss der Test deshalb gezielt f\u00fcr die jeweilige Anwendung konzipiert werden.<\/p>\n\n\n\n
Monitoring von WordPress<\/h2>\n\n\n\n
Bei einer WordPress-Website ist die \u00f6ffentliche Startseite ein sinnvoller Basischeck.<\/p>\n\n\n\n
Je nach Bedeutung der Website k\u00f6nnen zus\u00e4tzliche \u00f6ffentliche Seiten \u00fcberwacht werden.<\/p>\n\n\n\n
Den Administrationsbereich solltest du dagegen nicht einfach mit automatisierten Login-Versuchen belasten.<\/p>\n\n\n\n
Wenn die \u00f6ffentliche Website funktioniert, das WordPress-Backend jedoch langsam oder nicht erreichbar ist, handelt es sich m\u00f6glicherweise um ein anderes Problem als einen vollst\u00e4ndigen Website-Ausfall.<\/p>\n\n\n\n
Frontend und Backend getrennt betrachten<\/h2>\n\n\n\n
Eine WordPress-Website kann beispielsweise folgende Situation zeigen:<\/p>\n\n\n\n
Frontend\n\u2192 funktioniert\n\n\/wp-admin\/\n\u2192 sehr langsam<\/code><\/pre>\n\n\n\n
oder umgekehrt:<\/p>\n\n\n\n
Webserver\n\u2192 erreichbar\n\nWordPress\n\u2192 Fehler 500<\/code><\/pre>\n\n\n\n
Ein Monitoring-Ergebnis sollte deshalb immer im Kontext des tats\u00e4chlich \u00fcberwachten Endpunkts interpretiert werden.<\/p>\n\n\n\n
Cache kann Monitoring-Ergebnisse beeinflussen<\/h2>\n\n\n\n
Eine gecachte Startseite kann weiterhin sehr schnell ausgeliefert werden, obwohl ein Problem in einem dynamischen Bereich der Website besteht.<\/p>\n\n\n\n
Umgekehrt kann ein ungecachter Endpunkt andere Antwortzeiten zeigen als die \u00f6ffentliche Startseite.<\/p>\n\n\n\n
Das bedeutet nicht, dass Caching das Monitoring \u201efalsch\u201c macht. Der Monitor misst schlicht den Endpunkt, den du ihm vorgegeben hast.<\/p>\n\n\n\n
Deshalb ist die Auswahl repr\u00e4sentativer Pr\u00fcfungen entscheidend.<\/p>\n\n\n\n
CDN und Monitoring<\/h2>\n\n\n\n
Wenn eine Website \u00fcber ein Content Delivery Network oder einen Reverse Proxy ausgeliefert wird, sieht ein externer Monitor m\u00f6glicherweise zun\u00e4chst diese vorgelagerte Infrastruktur.<\/p>\n\n\n\n
Das kann zu Situationen f\u00fchren, in denen:<\/p>\n\n\n\n
CDN erreichbar\n        \u2193\nOrigin-Server hat Problem\n        \u2193\ngecachter Inhalt teilweise\nweiterhin erreichbar<\/code><\/pre>\n\n\n\n
ou<\/p>\n\n\n\n
Origin funktioniert\n        \u2193\nCDN \/ Proxy hat St\u00f6rung\n        \u2193\nBesucher erreicht Website\ntrotzdem nicht normal<\/code><\/pre>\n\n\n\n
Bei der Diagnose solltest du deshalb ber\u00fccksichtigen, welche Infrastruktur zwischen Besucher und eigentlichem Webserver liegt.<\/p>\n\n\n\n
Monitoring und Wartungsarbeiten<\/h2>\n\n\n\n
Geplante Wartungsarbeiten k\u00f6nnen absichtlich zu einer vor\u00fcbergehenden Nichterreichbarkeit f\u00fchren.<\/p>\n\n\n\n
Gute Monitoring-Systeme erlauben deshalb Wartungsfenster beziehungsweise das zeitweise Pausieren von Alarmen.<\/p>\n\n\n\n
Dadurch vermeidest du unn\u00f6tige Benachrichtigungen w\u00e4hrend einer bekannten geplanten Wartung.<\/p>\n\n\n\n
Die Messdaten solltest du dennoch korrekt interpretieren: Ein geplanter Ausfall bleibt technisch eine Phase eingeschr\u00e4nkter oder fehlender Verf\u00fcgbarkeit, auch wenn daf\u00fcr kein Alarm notwendig ist.<\/p>\n\n\n\n
Welche Benachrichtigungen sind sinnvoll?<\/h2>\n\n\n\n
Ein Monitoring-System kann je nach Anbieter unterschiedliche Alarmwege unterst\u00fctzen.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
E-Mail\n\nPush-Nachricht\n\nSMS\n\nMessenger\n\nWebhook\n\nIncident-System<\/code><\/pre>\n\n\n\n
Entscheidend ist weniger die Anzahl der Kan\u00e4le als die Frage, ob eine relevante Meldung tats\u00e4chlich von einer zust\u00e4ndigen Person wahrgenommen wird.<\/p>\n\n\n\n
Zu viele Alarme sind kontraproduktiv<\/h2>\n\n\n\n
Wenn ein Monitoring-System st\u00e4ndig irrelevante Warnungen versendet, entsteht Alarmm\u00fcdigkeit.<\/p>\n\n\n\n
Wichtige Meldungen werden dann m\u00f6glicherweise \u00fcbersehen.<\/p>\n\n\n\n
Konfiguriere deshalb:<\/p>\n\n\n\n
sinnvolle Pr\u00fcfintervalle\n\nrealistische Timeouts\n\nBest\u00e4tigungspr\u00fcfungen\n\nrelevante Endpunkte\n\npassende Alarmempf\u00e4nger\n\nWartungsfenster<\/code><\/pre>\n\n\n\n
mit Blick auf den tats\u00e4chlichen Einsatzzweck.<\/p>\n\n\n\n
Was ist ein False Positive?<\/h2>\n\n\n\n
Ein False Positive ist vereinfacht ein Alarm, obwohl der \u00fcberwachte Dienst aus Sicht der relevanten Nutzer nicht tats\u00e4chlich ausgefallen war.<\/p>\n\n\n\n
Beispielsweise k\u00f6nnte nur der Netzwerkweg eines einzelnen Monitoring-Standorts gest\u00f6rt gewesen sein.<\/p>\n\n\n\n
Deshalb sind Wiederholungspr\u00fcfungen und mehrere Standorte bei wichtigeren Systemen hilfreich.<\/p>\n\n\n\n
Was ist ein False Negative?<\/h2>\n\n\n\n
Umgekehrt kann ein Monitor einen Dienst als verf\u00fcgbar bewerten, obwohl f\u00fcr Besucher ein relevantes Problem besteht.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
Startseite liefert 200 OK\n\naber:\n\nCheckout funktioniert nicht<\/code><\/pre>\n\n\n\n
Der einfache Startseitenmonitor meldet weiterhin HAUT<\/code>, obwohl eine gesch\u00e4ftskritische Funktion gest\u00f6rt ist.<\/p>\n\n\n\n
Das zeigt eine zentrale Grenze jedes Monitorings: Es kann nur pr\u00fcfen, wof\u00fcr es konfiguriert wurde.<\/p>\n\n\n\n
Monitoring ersetzt keine Backups<\/h2>\n\n\n\n
Website-Monitoring und Backups l\u00f6sen v\u00f6llig unterschiedliche Probleme.<\/p>\n\n\n\n
Monitoring\n\u2192 erkennt eine St\u00f6rung\n\nBackup\n\u2192 erm\u00f6glicht Wiederherstellung\n  von Daten oder Systemzust\u00e4nden<\/code><\/pre>\n\n\n\n
Ein Monitor kann dich beispielsweise dar\u00fcber informieren, dass eine Website nicht erreichbar ist. Er besitzt dadurch aber nicht automatisch eine verwendbare Kopie deiner Website.<\/p>\n\n\n\n
Monitoring ersetzt keine Sicherheits\u00fcberwachung<\/h2>\n\n\n\n
Eine Website kann technisch erreichbar sein und trotzdem kompromittiert worden sein.<\/p>\n\n\n\n
Ein normaler HTTP-Monitor erkennt nicht automatisch:<\/p>\n\n\n\n
Schadcode\n\nmanipulierte Dateien\n\ngestohlene Zugangsdaten\n\nunerlaubte Administratoren\n\nversteckte Weiterleitungen\n\nDatenabfluss<\/code><\/pre>\n\n\n\n
Uptime-Monitoring ist deshalb nur ein Bestandteil einer umfassenderen technischen \u00dcberwachung.<\/p>\n\n\n\n
Monitoring ersetzt keine Performance-Analyse<\/h2>\n\n\n\n
Eine Website kann 100 Prozent der gemessenen Zeit erreichbar und trotzdem unertr\u00e4glich langsam sein.<\/p>\n\n\n\n
Umgekehrt kann eine sehr schnelle Website gelegentliche Ausf\u00e4lle besitzen.<\/p>\n\n\n\n
Deshalb sollten Verf\u00fcgbarkeit und Performance getrennt gemessen werden.<\/p>\n\n\n\n
Wenn deine Website zwar erreichbar, aber langsam ist, findest du unter Site web lent : identifier les causes de mani\u00e8re syst\u00e9matique<\/a> einen Diagnoseablauf.<\/p>\n\n\n\n
Monitoring-Daten \u00fcber l\u00e4ngere Zeit auswerten<\/h2>\n\n\n\n
Der eigentliche Wert eines Monitorings entsteht nicht nur durch einzelne Alarme.<\/p>\n\n\n\n
\u00dcber l\u00e4ngere Zeit k\u00f6nnen Muster sichtbar werden.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
Ausf\u00e4lle immer nachts?\n\nProbleme immer w\u00e4hrend Backups?\n\nTimeouts nur bei bestimmter Seite?\n\nFehler nur aus bestimmter Region?\n\nAntwortzeiten zu bestimmten\nZeiten auff\u00e4llig?\n\nwiederkehrende 5xx-Fehler?<\/code><\/pre>\n\n\n\n
Solche Muster k\u00f6nnen bei der Ursachenanalyse wesentlich hilfreicher sein als ein einzelner isolierter Alarm.<\/p>\n\n\n\n
Statusseiten<\/h2>\n\n\n\n
Bei gr\u00f6\u00dferen Diensten kann zus\u00e4tzlich eine \u00f6ffentliche oder interne Statusseite sinnvoll sein.<\/p>\n\n\n\n
Sie kann beispielsweise anzeigen:<\/p>\n\n\n\n
Website\n\nAPI\n\nKundencenter\n\nE-Mail-Dienste\n\nweitere Systeme<\/code><\/pre>\n\n\n\n
Eine Statusseite sollte jedoch m\u00f6glichst nicht vollst\u00e4ndig von genau derselben Infrastruktur abh\u00e4ngen, deren Ausfall sie kommunizieren soll.<\/p>\n\n\n\n
Was sollte ein gutes Basis-Monitoring leisten?<\/h2>\n\n\n\n
F\u00fcr eine normale gesch\u00e4ftliche Website sollte ein Basis-Monitoring mindestens klar beantworten k\u00f6nnen:<\/p>\n\n\n\n
Welche URL wird gepr\u00fcft?\n\nWie h\u00e4ufig wird gepr\u00fcft?\n\nWelcher Zustand gilt als Erfolg?\n\nWie lange wird auf Antwort gewartet?\n\nWird ein Fehler best\u00e4tigt?\n\nWann wird alarmiert?\n\nWann gilt die Website wieder als UP?\n\nWer erh\u00e4lt den Alarm?<\/code><\/pre>\n\n\n\n
Nur wenn diese Parameter bekannt sind, lassen sich die gemessenen Werte sinnvoll interpretieren.<\/p>\n\n\n\n
Monitoring richtig dokumentieren<\/h2>\n\n\n\n
Bei wichtigen Websites lohnt sich eine kurze Dokumentation der \u00dcberwachung.<\/p>\n\n\n\n
Par exemple :<\/p>\n\n\n\n
Monitor:\nWebsite Startseite\n\nURL:\nhttps://example.com\/\n\nTyp:\nHTTPS\n\nIntervall:\n5 Minuten\n\nErwartung:\nHTTP 200\n\nAlarm:\nnach best\u00e4tigtem Fehler\n\nEmpf\u00e4nger:\nzust\u00e4ndige Person<\/code><\/pre>\n\n\n\n
Dadurch ist auch sp\u00e4ter nachvollziehbar, was der Monitor tats\u00e4chlich gepr\u00fcft hat.<\/p>\n\n\n\n
Ein typischer Monitoring-Ablauf<\/h2>\n\n\n\n
Website definieren\n        \u2193\nwichtigen Endpunkt w\u00e4hlen\n        \u2193\nPr\u00fcfmethode bestimmen\n        \u2193\nPr\u00fcfintervall festlegen\n        \u2193\nErfolgskriterien definieren\n        \u2193\nAlarmierung konfigurieren\n        \u2193\nMonitoring starten\n        \u2193\nFehler erkannt?\n        \u2193\nKontrollpr\u00fcfung\n        \u2193\nAlarm\n        \u2193\nSt\u00f6rung reproduzieren\n        \u2193\nFehler eingrenzen\n        \u2193\nUrsache beheben\n        \u2193\nWiederherstellung pr\u00fcfen\n        \u2193\nMonitoring best\u00e4tigt UP\n        \u2193\nVorfall dokumentieren<\/code><\/pre>\n\n\n\n
H\u00e4ufige Fehler beim Website-Monitoring<\/h2>\n\n\n\n
nur Ping verwenden\n\n200 OK mit vollst\u00e4ndig\nfunktionierender Website gleichsetzen\n\nAntwortzeit mit kompletter\nLadezeit verwechseln\n\nnur einen irrelevanten\nEndpunkt \u00fcberwachen\n\nbei jedem einzelnen Timeout\nsofort Alarm ausl\u00f6sen\n\nzu viele unwichtige\nMonitore konfigurieren\n\nkeine Zeitstempel dokumentieren\n\ngeplante Wartungen\nnicht ber\u00fccksichtigen\n\nMonitoring als Backup betrachten\n\nMonitoring als Sicherheitsl\u00f6sung betrachten\n\nUP mit \"alles funktioniert\"\ngleichsetzen\n\nDOWN mit \"Server ausgeschaltet\"\ngleichsetzen<\/code><\/pre>\n\n\n\n
Checkliste: Website-Monitoring sinnvoll einrichten<\/h2>\n\n\n\n
Was soll \u00fcberwacht werden?\n        \u2193\n\u00f6ffentliche URL bestimmen\n        \u2193\nHTTP oder HTTPS verwenden\n        \u2193\nerwarteten Status definieren\n        \u2193\nfalls sinnvoll Inhalt pr\u00fcfen\n        \u2193\nPr\u00fcfintervall festlegen\n        \u2193\nTimeout sinnvoll w\u00e4hlen\n        \u2193\nKontrollpr\u00fcfung aktivieren\n        \u2193\nggf. mehrere Standorte nutzen\n        \u2193\nAlarmempf\u00e4nger festlegen\n        \u2193\nTestalarm durchf\u00fchren\n        \u2193\nWartungsfenster ber\u00fccksichtigen\n        \u2193\nMonitoring-Daten regelm\u00e4\u00dfig pr\u00fcfen\n        \u2193\nwiederkehrende Fehler analysieren<\/code><\/pre>\n\n\n\n
R\u00e9sum\u00e9<\/h2>\n\n\n\n
Website-Monitoring \u00fcberpr\u00fcft automatisch, ob eine Website oder ein bestimmter Dienst erreichbar ist und die definierten Erfolgskriterien erf\u00fcllt.<\/p>\n\n\n\n
F\u00fcr normale Websites ist ein externer HTTPS-Monitor ein sinnvoller Ausgangspunkt. Je nach Anwendungsfall k\u00f6nnen zus\u00e4tzliche Inhaltspr\u00fcfungen, weitere Endpunkte oder Pr\u00fcfungen aus mehreren Regionen sinnvoll sein.<\/p>\n\n\n\n
Ein Monitoring-Alarm bedeutet jedoch nicht automatisch, dass der komplette Server ausgefallen ist. Ein Timeout, DNS-Problem, HTTP-Fehler, Zertifikatsproblem oder eine gest\u00f6rte Anwendung kann ebenfalls einen Alarm verursachen.<\/p>\n\n\n\n
Umgekehrt beweist ein gr\u00fcner HAUT<\/code>-Status nicht, dass jede Funktion einer Website einwandfrei arbeitet. Ein einfacher Startseitenmonitor kann beispielsweise keinen vollst\u00e4ndigen Bestellprozess beurteilen.<\/p>\n\n\n\n
Monitoring ersetzt au\u00dferdem weder Backups noch Sicherheits\u00fcberwachung oder Performance-Analyse. Diese Systeme beantworten unterschiedliche technische Fragen.<\/p>\n\n\n\n
Besonders wertvoll wird Monitoring durch kontinuierliche Messungen, genaue Zeitstempel und eine sinnvolle Alarmierung. Bei sporadischen Problemen k\u00f6nnen diese Daten helfen, wiederkehrende Muster zu erkennen und Server- oder Anwendungslogs gezielt f\u00fcr den betroffenen Zeitraum auszuwerten.<\/p>\n\n\n\n
Gutes Website-Monitoring bedeutet deshalb nicht, m\u00f6glichst viele Checks einzurichten. Entscheidend ist, die richtigen Endpunkte mit klar definierten Kriterien zu \u00fcberwachen und bei einer Abweichung schnell die Informationen zu erhalten, die f\u00fcr eine echte Diagnose ben\u00f6tigt werden.<\/strong><\/p>","protected":false},"excerpt":{"rendered":"
Eine Website kann jederzeit ausfallen \u2013 auch wenn sie wenige Minuten zuvor noch problemlos funktioniert hat. Serverprobleme, fehlerhafte Updates, DNS-St\u00f6rungen, abgelaufene Zertifikate oder Probleme mit einer Anwendung k\u00f6nnen dazu f\u00fchren, dass Besucher eine Website pl\u00f6tzlich nicht mehr erreichen. Wer die eigene Website nur gelegentlich selbst aufruft, bemerkt solche St\u00f6rungen m\u00f6glicherweise erst Stunden sp\u00e4ter oder durch […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"doc_category":[85],"doc_tag":[],"class_list":["post-22919","docs","type-docs","status-publish","hentry","doc_category-seo-monitoring"],"year_month":"2026-09","word_count":3699,"total_views":"4","reactions":{"happy":"0","normal":"0","sad":"0"},"author_info":{"name":"Silvio Mazenauer","author_nicename":"admin-curia","author_url":"https:\/\/www.curiaweb.ch\/fr\/author\/admin-curia\/"},"doc_category_info":[{"term_name":"SEO & Monitoring","term_url":"https:\/\/www.curiaweb.ch\/fr\/hilfe-kategorie\/seo-monitoring\/"}],"doc_tag_info":[],"knowledge_base_info":[],"knowledge_base_slug":[],"_links":{"self":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs\/22919","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/comments?post=22919"}],"version-history":[{"count":1,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs\/22919\/revisions"}],"predecessor-version":[{"id":22921,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/docs\/22919\/revisions\/22921"}],"wp:attachment":[{"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/media?parent=22919"}],"wp:term":[{"taxonomy":"doc_category","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/doc_category?post=22919"},{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/fr\/wp-json\/wp\/v2\/doc_tag?post=22919"}],"curies":[{"name":"Bien jou\u00e9","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}