Statuts des moniteurs et disponibilité

Chaque moniteur affiche l'un de trois statuts — up, dégradé ou down — et suit un % de disponibilité dans le temps. Cette page explique ce que signifie chaque statut, comment la disponibilité est calculée, et comment Servor évite de vous submerger quand un service clignote entre marche et arrêt.

Si vous n'en avez pas encore créé, commencez par créer un moniteur.

Les trois statuts

Up signifie que tout va bien. Down signifie que la vérification a échoué et demande de l'attention. Dégradé se situe entre les deux : le service est joignable mais sous-performant — un avertissement précoce utile avant une panne complète.

Pourcentage de disponibilité

Le % de disponibilité est la part du temps pendant laquelle un moniteur était up sur une fenêtre donnée (par exemple les dernières 24 heures, 7 jours ou 30 jours). Si un moniteur a été down 15 minutes sur une journée de 24 heures, sa disponibilité pour ce jour est d'environ 99,0 %.

Quelques points à connaître :

• La disponibilité est mesurée à partir des vérifications réellement effectuées par Servor, selon votre intervalle de vérification. Un intervalle plus court donne un chiffre plus fin.
• Le temps passé en dégradé n'équivaut pas au temps down — lisez l'historique des statuts, pas seulement le chiffre affiché, pour comprendre ce qui s'est passé.
• Ces mêmes données alimentent les composants de page de statut : votre page publique reflète donc la disponibilité réellement mesurée.

Pourquoi le statut ne bascule pas au moindre soubresaut

Les réseaux sont bruyants. Une seule vérification en échec peut être une perte de paquets passagère, pas une vraie panne — et si chaque soubresaut isolé faisait basculer un moniteur en down et déclenchait une alerte, vous seriez noyé sous les fausses alertes.

Pour l'éviter, Servor confirme un changement avant de le valider. Un moniteur ne change pas de statut à la toute première vérification qui contredit son état actuel — il attend que le changement se maintienne sur plusieurs vérifications consécutives avant de passer officiellement down (et de nouveau avant de revenir up). On parle parfois d'hystérésis : il faut un peu plus de preuves pour changer d'état que pour y rester.

Les effets concrets :

• Moins de fausses alertes. Une vérification en échec isolée qui se rétablit aussitôt ne vous réveillera pas.
• Un léger délai naturel. Comme un changement doit être confirmé, une vraie panne est signalée un peu après la première vérification en échec, pas instantanément — c'est le prix à payer pour ne pas être submergé.
• Le rétablissement est lissé lui aussi. Un service instable qui se rétablit sur une vérification puis échoue à nouveau ne sera pas déclaré sain prématurément.

Lire l'historique

Ouvrez un moniteur depuis vos moniteurs dans Servor pour voir la chronologie de ses vérifications et de ses changements de statut. Servez-vous-en pour distinguer un pic isolé (une vérification dégradée, vite revenue à up) d'un problème durable (échecs répétés). Pour les tendances CPU, RAM et disque d'une machine connectée, voir métriques de ressources.

Étapes suivantes