La surveillance de la disponibilité d’un site web répond sans cesse à une seule question : mon site web est-il joignable en ce moment ? Un moniteur interroge votre site à intervalles réguliers, enregistre ce qui est revenu et vous prévient quand la réponse change. Ce guide explique comment cela fonctionne, ce que les résultats peuvent et ne peuvent pas vous dire, et comment décider de ce dont vous avez besoin.

Il porte sur la méthode. Pour les définitions, voir disponibilité (« uptime ») et temps d’arrêt dans le glossaire. Pour la mise en place concrète, voir Comment surveiller la disponibilité d’un site web.

Ce qu’est la surveillance de la disponibilité d’un site web

La surveillance est une boucle en quatre parties :

  1. Vérifier. Un système extérieur à votre site web interroge une adresse que vous avez choisie.
  2. Juger. Il décide si la réponse compte comme un bon fonctionnement.
  3. Alerter. Si la réponse est mauvaise, il prévient les personnes que vous avez désignées.
  4. Enregistrer. Chaque résultat est conservé, pour que vous puissiez revenir en arrière.

Les deux premières parties déterminent l’utilité des autres. Un moniteur qui vérifie la mauvaise adresse, ou qui accepte les mauvaises réponses, annoncera le calme pendant que vos visiteurs voient des erreurs.

Pourquoi la disponibilité compte

Quand un site web est injoignable, les visiteurs ne peuvent ni acheter, ni se connecter, ni lire, ni vous contacter. La plupart des propriétaires apprennent une panne par un client, un collègue ou une commande manquante. Chacun de ces signaux arrive tard et ne dit rien sur le moment où le problème a commencé.

La surveillance change deux choses. Vous apprenez un problème dès son début, et vous gardez une trace de sa durée. Cette trace sert aussi après coup : elle montre si un problème est un cas isolé ou une tendance.

Comment fonctionne la surveillance HTTP

La plupart des moniteurs de sites web parlent HTTP, le même langage que les navigateurs. À chaque vérification, le moniteur :

  1. Recherche l’adresse dans le DNS.
  2. Ouvre une connexion et, pour les adresses https://, une connexion TLS sécurisée.
  3. Envoie une requête HTTP, généralement GET.
  4. Lit le code d’état de la réponse.

Le code d’état est le verdict. Un 200 indique que le serveur a traité la requête. Un 503 indique que le serveur est en marche mais ne peut pas la servir. L’absence totale de réponse, parce que le DNS a échoué ou que la connexion a dépassé le délai d’attente, est aussi un échec.

Les redirections demandent une règle. Si http://example.com envoie les visiteurs vers https://www.example.com, le moniteur peut suivre la redirection et juger la réponse finale, ou juger la redirection elle-même. UptimeWire suit un nombre limité de redirections et juge la réponse finale : un code d’état final de 200 à 399 compte comme disponible, et tout autre code compte comme un échec. Une chaîne qui ne se stabilise jamais est aussi un échec.

Ce qu’une vérification mesure vraiment

Une vérification mesure une requête vers une adresse depuis un endroit à un instant donné. C’est plus étroit qu’il n’y paraît :

  • Elle mesure l’adresse que vous lui avez donnée, pas tout votre site web. Un moniteur sur la page d’accueil ne dit rien de /checkout/.
  • Elle mesure la réponse, pas ce que fait la page dans un navigateur. Les scripts, les images et les widgets tiers ne sont pas exécutés.
  • Elle mesure un instant. Ce qui s’est passé entre deux vérifications est invisible.

La vérification enregistre aussi le temps que la réponse a mis à arriver. Voir temps de réponse pour ce que ce chiffre inclut et pourquoi il diffère d’un outil à l’autre.

Choisir un intervalle de surveillance

L’intervalle est le temps entre deux vérifications. Un intervalle plus court trouve les problèmes plus tôt, car une panne ne peut être remarquée que par une vérification qui s’exécute pendant qu’elle a lieu.

Intervalle Ce que cela signifie en pratique
1 minute Un problème est repéré en une minute ou deux environ. Adapté aux sites où les minutes coûtent de l’argent.
5 minutes Une valeur par défaut raisonnable pour la plupart des sites d’entreprise.
15 à 30 minutes Suffisant pour les sites à faible trafic où une courte panne est tolérable.
1 heure ou plus Ne détecte que les longues pannes. Une courte panne peut passer entre deux vérifications sans être vue.

Deux précautions. D’abord, l’intervalle n’est pas le délai de détection : la confirmation (section suivante) en ajoute un peu. Ensuite, plus court n’est pas toujours mieux. Si une vérification déclenche aussi un traitement lourd sur votre serveur, exécutez-la moins souvent ou dirigez-la vers une adresse plus légère.

Les offres limitent la brièveté de l’intervalle. Dans UptimeWire, le plus court est de 5 minutes avec Free, 3 avec Starter, et 1 avec Business et Agency.

Confirmer une panne

Les réseaux sont bruyants. Une requête isolée peut échouer à cause d’un paquet perdu, d’une brève surcharge ou d’un problème du côté du moniteur, alors que le site va bien pour tout le monde. Si chaque vérification en échec déclenchait une alerte, vous apprendriez à les ignorer.

La confirmation règle ce problème. Le moniteur répète une vérification en échec, à courte distance, et n’ouvre un incident que si les échecs continuent. UptimeWire fonctionne ainsi et, quand un second point de vue est disponible, il peut aussi l’interroger. Cela coûte un peu de temps de détection, un prix raisonnable pour des alertes auxquelles on peut se fier.

Note

La confirmation signifie qu’une alerte n’arrive pas à l’instant où le site tombe. Le délai de détection dépend de l’intervalle, des vérifications répétées et de la rapidité avec laquelle la notification vous parvient. Aucun moniteur ne peut promettre un délai exact.

Surveiller depuis l’extérieur

Il existe deux grandes façons de surveiller un système. Le livre SRE de Google les appelle surveillance en boîte noire et surveillance en boîte blanche. La surveillance en boîte noire teste ce qu’un utilisateur peut voir, de l’extérieur. La surveillance en boîte blanche lit les signaux propres au système, comme la charge du processeur, la mémoire et les journaux.

La surveillance de la disponibilité d’un site web est en boîte noire. C’est sa force : elle voit ce que voient les visiteurs, y compris des échecs que votre propre serveur ne peut pas signaler de lui-même, comme un réseau injoignable ou un enregistrement DNS cassé. C’est aussi sa limite : elle vous dit que quelque chose ne va pas, pas pourquoi.

Les deux approches se complètent. Les vérifications externes disent « les visiteurs n’arrivent pas jusqu’au site ». Les métriques internes aident à expliquer pourquoi.

Temps de réponse

Un site lent est un site partiellement en panne. Suivre le temps de réponse en plus de la disponibilité révèle les ennuis avant qu’ils deviennent une panne : une base de données qui commence à peiner, un déploiement qui a ajouté une requête lente, un serveur à court de ressources.

Maniez ce chiffre avec prudence. C’est le temps d’une requête simple, pas le temps qu’une page met à devenir utilisable dans un navigateur. Comparez-le à son propre historique plutôt qu’au chiffre d’un autre outil.

Certificats, domaines et DNS

Un site web peut tomber en panne sans que le serveur web soit en cause. Trois éléments distincts doivent continuer à fonctionner :

  • Le certificat SSL/TLS. Quand il expire, les navigateurs affichent un avertissement plein écran. Voir Comment éviter l’expiration d’un certificat SSL.
  • L’enregistrement du domaine. Si le renouvellement est oublié, le domaine cesse de fonctionner et peut être perdu.
  • La résolution DNS. Si le nom ne se résout plus, les visiteurs ne trouvent plus le serveur, aussi sain soit-il.

Ces éléments tombent en panne lentement, puis soudainement. Ils demandent des vérifications à eux, selon leur propre calendrier, car la vérification HTTP ne vous préviendra pas à l’avance. Un certificat qui expire demain répond encore 200 aujourd’hui.

UptimeWire vérifie le certificat, la date d’expiration du domaine et la résolution DNS de chaque site web, séparément de la vérification de disponibilité. Les alertes de certificat, de domaine et de DNS partent par e-mail et par Telegram.

Historique des incidents et pages de statut

Un incident est une période d’échec confirmé, de la première mauvaise vérification confirmée jusqu’au rétablissement. Conserver un historique des incidents répond aux questions qui arrivent plus tard : quand cela a-t-il commencé, combien de temps cela a-t-il duré, à quelle fréquence cela arrive-t-il ?

Une page de statut est une page publique qui montre aux visiteurs si votre service fonctionne. Elle fait gagner du temps au support pendant une panne et renforce la confiance ensuite. Que vous en ayez besoin ou non dépend de votre public. Une boutique ou un produit SaaS dont les clients attendent des réponses en profite. Un blog personnel, non.

Ce que la surveillance ne peut pas faire

Soyez clair sur les limites, pour qu’un tableau de bord silencieux ne soit pas pris pour la preuve que tout va bien.

  • Un 200 ne veut pas dire « ça marche ». Un serveur peut répondre 200 alors que la base de données est en panne, que le paiement est cassé ou que la page affiche un message d’erreur. Une simple vérification de requête ne peut pas le voir. Pour le détecter, le moniteur doit chercher quelque chose de précis dans la réponse, ou vous devez surveiller une adresse plus profonde, comme un point de contrôle d’état.
  • Seules les adresses configurées sont surveillées. Une adresse n’est qu’une adresse. Surveiller example.com ne couvre pas shop.example.com ni /api/. Ajoutez chacune de celles qui comptent.
  • Elle ne remplace pas la surveillance interne. Elle vous dit que le site est en panne, pas quel composant a lâché.
  • Ce n’est pas une preuve contractuelle. Les chiffres d’un outil de surveillance sont une estimation vue d’un seul point. Ils sont utiles pour vos propres registres, mais un accord de niveau de service définit sa propre façon de mesurer. Voir SLA.
  • Les vérifications échantillonnent le temps. Une panne d’une minute entre deux vérifications espacées de cinq minutes peut ne jamais être vue.

Choisir ce qu’il faut surveiller

Partez de ce qui ferait le plus mal en cas de panne, pas de ce qui est le plus facile à vérifier.

  1. Listez les adresses dont dépendent les visiteurs. La page d’accueil, la page de connexion, le paiement, un point d’accès d’API. Chacune peut tomber indépendamment.
  2. Choisissez un intervalle pour chacune. Plus le coût d’une panne grandit vite, plus l’intervalle doit être court.
  3. Décidez qui est prévenu, et comment. L’e-mail touche tout le monde ; un canal de messagerie atteint plus vite la personne d’astreinte. Assurez-vous que l’alerte va à quelqu’un qui la verra.
  4. Ajoutez les pannes lentes. L’expiration du certificat, l’expiration du domaine et le DNS font partie de la liste.
  5. Décidez si les visiteurs ont besoin d’une page de statut.

Une liste de contrôle pratique

  • Chaque adresse importante est surveillée, pas seulement la page d’accueil.
  • L’adresse surveillée renvoie une réponse significative, pas une réponse générique.
  • L’intervalle correspond au coût d’une panne.
  • Les alertes parviennent à une personne qui agira.
  • Les vérifications de certificat, de domaine et de DNS sont activées.
  • Vous avez testé qu’une alerte arrive réellement.
  • Vous examinez de temps en temps l’historique des incidents.

Quand vous serez prêt à mettre tout cela en place, Comment surveiller la disponibilité d’un site web détaille les étapes dans UptimeWire.