Surveillance de disponibilité
Méthode de requête
GET ou POST. POST te permet de vérifier un point de terminaison qui n'accepte que les écritures (par exemple, le contrôle de santé propre à un récepteur de webhook).
Vérifications de port TCP
Tout ne parle pas HTTP — une base de données, un serveur de mail, un serveur de jeu. Saisissez tcp://host:port comme URL au lieu de http(s)://, et Dumza vérifiera si ce port accepte une connexion plutôt que d'envoyer une requête HTTP. La méthode, le code de statut attendu, le mot-clé et le seuil de temps de réponse ne s'appliquent pas à une vérification TCP et sont masqués dans le formulaire ; les alertes, les incidents et tout le reste fonctionnent exactement de la même façon.
Code de statut attendu
Tout point de terminaison qui renvoie autre chose que le code attendu compte comme en panne. Ce n'est pas limité à 200 — de nombreuses API renvoient légitimement 201, 204, voire 401/503 pour une vérification saine (un point de terminaison censé exiger une authentification, par exemple). Définis le statut que renvoie ton point de terminaison quand il est réellement en bonne santé.
Vérification par mot-clé
Exige (ou interdit) éventuellement la présence d'un texte précis quelque part dans le corps de la réponse — utile pour les points de terminaison qui renvoient 200 même quand quelque chose est cassé à l'intérieur de la page (un CMS qui sert une page d'erreur générique avec un statut 200, par exemple). Choisis « contient » pour exiger le texte, ou « ne contient pas » pour échouer quand il apparaît (pratique pour détecter une bannière de mode maintenance que ton application affiche tout en renvoyant 200).
Seuil de temps de réponse
Définis un temps de réponse maximal acceptable : une vérification qui répond correctement mais trop lentement est marquée « dégradé » plutôt que « en panne » — c'est visible sur ton tableau de bord et compté dans tes statistiques de disponibilité, mais cela n'ouvre PAS d'incident et n'envoie PAS d'alerte. Dégradé est un signal à surveiller, pas à faire remonter à quelqu'un.
Intervalle de vérification
La fréquence à laquelle Dumza vérifie le point de terminaison. Le forfait gratuit vérifie toutes les 5 minutes ; les forfaits payants peuvent descendre jusqu'à toutes les 1 minute. Un intervalle plus court signifie une détection plus rapide d'une panne, au prix de davantage de requêtes vers ton serveur.
Minutage des alertes : notifyAfter et réalertes
« Alerter après N échecs consécutifs » contrôle combien de vérifications défaillantes d'affilée ouvrent un incident (minimum 2, pour éviter les fausses alertes causées par un simple accroc). Séparément, « réalerter toutes les N minutes » (optionnel, minimum 30) répète la notification tant que le moniteur reste en panne — utile si la première alerte de ton équipe passe inaperçue.
Signification des statuts de moniteur
up (opérationnel) — la dernière vérification a réussi. down (en panne) — un incident est ouvert. degraded (dégradé) — répond, mais plus lentement que ton seuil. pending (en attente) — aucune vérification n'a encore eu lieu (moniteur tout juste créé, ou en pause). auth_error (erreur d'authentification) — le jeton de connexion d'un moniteur authentifié a été rejeté ; voir Surveillance authentifiée.
Mettre un moniteur en pause
Un moniteur en pause cesse entièrement d'être vérifié, et tout incident ouvert le concernant se referme automatiquement — il ne continuera pas à t'alerter pour quelque chose que tu as délibérément mis hors ligne (maintenance planifiée, mise hors service). Reprends-le à tout moment pour relancer la surveillance.