Types de checks

L’offre fixe les intervalles et les régions

Selon l’offre, les intervalles descendent jusqu’à 10 secondes. Le formulaire web propose 30 secondes et plus. Les intervalles plus courts se règlent par MCP. La page des tarifs indique l’intervalle minimal de chaque offre.

Les 11 types de checks régionaux utilisent les régions incluses dans l’offre : 2 avec Free, 3 avec Pulse et les 6 à partir de Sentinel. Leur politique régionale est configurable et utilise par défaut un quorum de 2 régions. La page sur le monitoring d’uptime explique la règle régionale.

agent et heartbeat ne sont rattachés à aucune région et n’ont pas besoin de quorum, parce que le signalement vient de votre hôte ou de votre job.

Vérifiez les URL et les en-têtes de sécurité

http appelle une URL et vérifie le résultat par des assertions : un code de statut attendu, un mot-clé que le corps doit contenir ou une expression régulière appliquée au corps. Il suit les redirections jusqu’à 5 sauts et vérifie, avant de l’appeler, que chaque saut ne vise pas une cible SSRF. Un monitor http peut aussi porter les sous-checks optionnels certificat TLS, en-têtes de sécurité et hygiène DNS : un seul monitor couvre ce qui en demandait quatre. Seul le sous-check de certificat exige https.

http_headers vérifie les en-têtes de sécurité dans un monitor distinct, avec son propre registre.

Vérifiez DNS, domaines et certificats

dns résout un nom et compare l’ensemble des réponses à ce que vous attendez. Un monitor DNS peut aussi croiser ses réponses avec celles d’un autre monitor. Une divergence passe par le circuit d’incident habituel.

dns_hygiene vérifie SPF, DMARC et CAA en tant que configuration. Ces enregistrements décident si vos e-mails sont distribués et qui peut émettre des certificats en votre nom.

domain surveille la couche d’enregistrement : cohérence des NS et du SOA, DNSSEC et expiration WHOIS. Un domaine dans sa fenêtre d’alerte, 14 jours par défaut, passe en dégradé.

ssl_cert surveille un certificat directement, indépendamment de tout monitor http. Il vérifie la validité, la chaîne, l’expiration et l’émetteur, et détecte les certificats auto-signés.

Vérifiez les serveurs de messagerie

smtp et imap vérifient le chemin des e-mails dont dépendent les réinitialisations de mot de passe et les factures. Depuis les régions de sondes de votre offre, ils vérifient que le serveur accepte les connexions et parle son protocole.

Vérifiez l’accessibilité et le chemin réseau

ping vérifie si l’hôte est joignable. tcp vérifie si un port accepte une connexion, avec en option le certificat TLS servi sur ce port. traceroute enregistre le chemin, et c’est la preuve qu’il vous faut quand la faute revient à un réseau intermédiaire, pas à votre service.

Surveillez un hôte avec l’agent

agent rattache un monitor à l’agent hôte. Il vérifie la disponibilité avec une période de grâce, ainsi que le CPU, la mémoire et le disque par rapport à des seuils. Il surveille aussi des services nommés, avec un délai de grâce contre le flapping. Une métrique sans données récentes ne produit aucun résultat plutôt qu’une fausse alerte, et un monitor de disponibilité marque un agent silencieux comme en panne.

Une seule ligne installe l’agent depuis le point de distribution, sous Linux (x86_64, aarch64) et sous macOS en binaire universel. Sous Linux, il tourne comme unité systemd durcie. Il ne collecte jamais les lignes de commande, les variables d’environnement ni les noms d’utilisateur.

L’agent se met à jour avec des releases signées en ed25519. Il vérifie chaque release avant le remplacement, applique le principe fail-closed et se passe de tout assistant root. Il se désinstalle proprement et se désinscrit du cockpit.

Surveillez les jobs avec un heartbeat

heartbeat inverse le sens : votre job appelle Perstat, au lieu que Perstat appelle votre service. Cela couvre une exécution cron, une sauvegarde nocturne, un import de données ou tout autre traitement sans adresse à sonder.

Vous recevez une URL secrète, et le job l’appelle quand il se termine. Si cet appel n’arrive pas avant la fin de la période augmentée du délai de grâce que vous avez défini, le monitor passe en panne. Un job qui n’a jamais tourné est la panne que le monitoring ordinaire ne voit pas, parce que rien de joignable ne s’est cassé.

Chaque heartbeat possède un endpoint de succès et un endpoint d’échec. Un job qui a tourné et échoué peut appeler l’endpoint d’échec : le monitor passe alors en panne dès l’évaluation suivante, sans attendre la fin de la période. Votre script choisit l’endpoint qu’il appelle, et peut donc signaler toute condition qu’il sait tester, pas seulement l’exécution du job.

La documentation des monitors donne les URL exactes.

Les résultats régionaux incluent un diagnostic

• IPv4, IPv6 ou les deux, par IP. Chaque check d’accessibilité s’exécute sur les familles d’adresses que vous choisissez, et sur IPv4 si vous n’en choisissez aucune. Les résultats restent séparés par famille et par IP. Vous décidez si un échec dans une famille est classé dégradé ou en échec.
• Le temps DNS à part. Le cas échéant, dns_ms est remonté séparément de la latence totale, pour qu’un résolveur lent ne passe pas pour une application lente.
• Attribution de la cause. Lorsqu’un check de sonde pris en charge produit une attribution, il nomme la couche : votre application ou votre DNS, le réseau, ou notre résolveur ou notre propre nœud. Unknown reste valide tant que la cause n’est pas établie, et tous les résultats ne portent pas une couche de cause.

Lancez le monitoring gratuitement ou suivez la visite guidée. La visite ne demande pas d’inscription.