Monitors et types de checks

Les 13 types

http, http_headers, tcp, dns, dns_hygiene, domain, ssl_cert, smtp, imap, ping, traceroute, agent et heartbeat. La référence des types de checks explique chacun en langage clair. Les sections ci-dessous couvrent la configuration.

Monitors HTTP

• Assertions : code de statut attendu, mot-clé que le corps de la réponse doit contenir, ou expression régulière appliquée au corps.
• Subchecks intégrés : un monitor http embarque des subchecks pour le certificat TLS (expiration, émetteur, détection des certificats auto-signés), pour les en-têtes de sécurité et pour l’hygiène DNS. Un seul monitor couvre ce qui en demandait quatre.
• Redirections : suivies jusqu’à 5 sauts. Perstat contrôle chaque saut avant de l’appeler, pour écarter les cibles SSRF (plages privées, adresses link-local, endpoints de métadonnées).

Comportement dual-stack

Un check parcourt tous les enregistrements A et AAAA et renvoie un résultat par famille d’adresses et par IP. À vous de décider, monitor par monitor, si une défaillance qui ne touche qu’IPv6 compte comme dégradation ou comme panne. dns_ms est indiqué séparément de la latence totale.

DNS en détail

Un monitor dns compare l’ensemble des réponses à ce que vous attendez, et peut le recouper avec les réponses d’un autre monitor. Une divergence passe alors par le traitement d’incident habituel. dns_hygiene vérifie SPF, DMARC et CAA en tant qu’éléments de configuration. domain surveille NS, SOA, DNSSEC et l’expiration WHOIS.

Interroger un serveur de noms précis. Sans autre indication, un monitor dns interroge le résolveur de Perstat : il mesure donc la zone dans son ensemble, cache compris. En renseignant server (un nom comme a.example-ns.net ou une IP), le check interroge directement ce serveur, sans cache intermédiaire. Vous voyez ainsi qu’un serveur de noms d’un groupe tombe ou répond autrement que ses homologues, ce qu’un contrôle sur la zone entière ne peut pas montrer. Combiné à un recoupement entre deux monitors de ce type, un écart entre deux serveurs devient un incident.

En anycast, chaque région de contrôle atteint le nœud le plus proche d’elle, si bien que plusieurs régions couvrent plusieurs nœuds physiques de la même adresse. L’adresse réellement atteinte est consignée avec le résultat. Si le serveur publie NSID ou id.server, vous voyez aussi quel nœud a répondu.

Intervalles

L’intervalle se règle monitor par monitor, jusqu’au plancher de votre formule : Free 300 s, Pulse 60 s, Sentinel 30 s, Command 15 s, Enterprise 10 s. Le formulaire web propose de 30 secondes à 1 heure. L’API REST et MCP règlent tout intervalle entre le plancher de votre formule et 24 heures, y compris 15 s avec Command et 10 s avec Enterprise. Les tableaux de limites complets figurent sur formules et limites.

Monitors agent

Le type agent rattache un monitor à un agent hôte : la disponibilité avec période de grâce, CPU, mémoire et disque comparés à des seuils, et des services nommés, protégés du flapping par leur propre période de grâce. Une donnée manquante compte comme un résultat en attente, jamais comme une fausse alerte. Un agent qui se tait compte comme une panne.

Monitors heartbeat

Le type heartbeat inverse le sens : au lieu que Perstat appelle votre service, c’est votre tâche qui appelle Perstat. C’est le bon type pour un cron, un import par lots, une sauvegarde, tout ce qui n’a pas d’adresse à interroger.

Chaque heartbeat a deux points d’entrée, et votre tâche choisit lequel appeler :

https://api.perstat.io/ping/<token>        # terminé proprement
https://api.perstat.io/ping/<token>/fail   # exécuté, mais quelque chose cloche

Les deux acceptent GET comme POST, un curl dans un script shell suffit donc. L’URL exacte d’un monitor figure sur sa page de détail dans l’application et dans l’API, et un agent la reçoit par MCP en créant le monitor. Câblez-la dans la tâche juste après la création du monitor : la couverture commence au premier ping.

Deux réglages décident du moment où il bascule. period_seconds est la fréquence à laquelle vous attendez la remontée, de 30 secondes à 30 jours. grace_seconds est la tolérance par-dessus, pour qu’une sauvegarde occasionnellement longue ne réveille personne. Donnez à la tolérance une vraie fraction de la période plutôt qu’une minute symbolique.

• Le silence au-delà de la période plus la tolérance fait basculer.
• Un appel au point d’entrée d’échec fait basculer à la prochaine évaluation, soit en une demi-minute environ, sans attendre la fin de la période.

Un heartbeat reste inconnu jusqu’à son premier ping, car un calendrier ne compte qu’une fois que votre tâche l’a confirmé.

Remonter une condition que votre tâche évalue

Comme c’est votre côté qui choisit le point d’entrée, un heartbeat porte n’importe quelle condition qu’un script peut trancher, au-delà de « la tâche a tourné ». Une minuterie qui vérifie une longueur de file, un nombre d’enregistrements ou la taille d’un répertoire, puis appelle le point d’entrée correspondant, transforme une mesure locale en incident :

if [ "$(records)" -ge 1000 ]; then
  curl -fsS -m 10 "https://api.perstat.io/ping/$TOKEN" >/dev/null
else
  curl -fsS -m 10 "https://api.perstat.io/ping/$TOKEN/fail" >/dev/null
fi

Cela exprime ce qu’un seuil sur une mesure d’hôte ne sait pas dire, par exemple un compte tombé sous sa valeur attendue. Un heartbeat porte une condition, donnez donc à chaque affirmation son propre monitor.

Pour aller plus loin

• Quorum et régions : comment les résultats régionaux deviennent un état confirmé.
• Alertes et astreinte : qui est réveillé, et comment.