Monitoring · Disponibilité

Monitoring de site web : surveiller la disponibilité et le parcours utilisateur

Construisez un monitoring utile : disponibilité, contenu attendu, TLS, DNS, performance, transactions et alertes actionnables.

Lecture : environ 6 minGuide pratiquePar l’équipe technique Au P'tit Serveur
Illustration d’une infrastructure de serveurs, de supervision et de sauvegarde
Illustration éditoriale dédiée à l’hébergement, Linux et aux sauvegardes.

Le problème à résoudre

Un ping réussi ne prouve pas qu’un site fonctionne. Le serveur peut répondre alors que la page affiche une erreur, que le paiement échoue ou que le certificat expire demain.

Un bon monitoring combine signaux techniques et parcours métier, depuis plusieurs points de mesure. Chaque alerte doit indiquer qui agit, avec quelle urgence et à partir de quelle procédure.

Reconnaître les bons signaux

Signal observéInterprétation probablePremier contrôle
HTTP 200 avec page d’erreurTest trop superficielChercher un contenu attendu
Alerte intermittente uniqueRéseau de la sondeConfirmer depuis un second point
Paiement indisponibleDépendance externe ou applicationTester une transaction synthétique

Les notions à maîtriser

  • Disponibilité et performance sont deux objectifs différents.
  • Une sonde externe détecte ce que voit un visiteur ; une métrique interne explique souvent pourquoi.
  • Les seuils statiques provoquent du bruit si la saisonnalité n’est pas prise en compte.
  • Certificats, domaines et sauvegardes ont besoin d’alertes avant échéance.

Méthode de diagnostic

1. Lister les parcours qui créent réellement de la valeur.
2. Définir SLI, seuil, durée de confirmation et fréquence.
3. Placer des sondes externes et collecter métriques serveur/applicatives.
4. Tester l’escalade et la documentation lors d’un exercice planifié.

Plan d’action recommandé

  1. Commencer par accueil, connexion, formulaire et paiement selon le site.
  2. Vérifier code HTTP, contenu et temps de réponse.
  3. Ajouter TLS, DNS, espace disque, erreurs PHP et file de workers.
  4. Regrouper les alertes liées pour éviter une tempête de notifications.
  5. Examiner chaque mois les alertes inutiles et les incidents non détectés.

Erreurs fréquentes à éviter

  • Alerter à la première seconde lente sans confirmation.
  • Envoyer toutes les alertes au même canal sans priorité.
  • Surveiller le serveur mais pas le service rendu à l’utilisateur.

Indicateurs à suivre

IndicateurRepèrePourquoi le suivre
DisponibilitéObjectif défini par serviceMesure le résultat
Latence p95Seuil selon parcoursDétecte les dégradations
Temps d’acquittementCompatible avec la criticitéMesure la réaction

Checklist avant validation

  • Une mesure de référence est conservée.
  • Le changement est testé hors production lorsque c’est possible.
  • Une sauvegarde ou un retour arrière est disponible.
  • Les dépendances web, e-mail et DNS ont été contrôlées.
  • Les journaux et alertes sont surveillés après intervention.
  • Le résultat est documenté avec date et responsable.

Questions fréquentes

Quelle fréquence choisir ?

Une à cinq minutes convient souvent au web ; les parcours lourds peuvent être moins fréquents.

Faut-il plusieurs sondes ?

Oui pour distinguer une panne réelle d’un problème local à une région ou un opérateur.

Que surveiller en priorité ?

Le parcours le plus critique et les dépendances dont l’expiration peut provoquer une panne.

Sources techniques

Pour vérifier les règles et approfondir le sujet :

Besoin d’un diagnostic sur votre environnement ?

Décrivez le symptôme, le contexte et l’impact : vous recevrez une réponse cadrée avant toute intervention.

Échanger sur votre besoin