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 ; cette page s’en tient à 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 ; chaque saut est contrôlé avant d’être appelé, 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 contrôle interroge directement ce serveur, sans cache intermédiaire. C’est la seule façon de voir qu’un serveur de noms d’un groupe tombe ou répond autrement que ses homologues ; un contrôle sur la zone ne le révélera jamais. Combiné à un recoupement entre deux monitors de ce type, un écart entre deux serveurs devient un incident.

En anycast la question reste honnête, mais la réponse est locale : 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. Savoir quel nœud a répondu n’est possible que si le serveur publie NSID ou id.server.

Intervalles

L’intervalle se règle monitor par monitor ; le plancher dépend de la formule : free 300 s, pulse 60 s, sentinel 30 s, command 15 s, enterprise 10 s. 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.

Les monitors heartbeat

Le type heartbeat inverse le sens : au lieu que nous appelions votre service, c’est votre tâche qui nous appelle. 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. Vous la câblez dans la tâche après avoir créé le monitor, et cela vaut la peine de le faire tout de suite : un heartbeat que personne n’appelle ressemble à de la couverture sans en être.

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. C’est voulu : un calendrier que personne n’a confirmé ne peut pas être enfreint.

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, pas seulement « 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 couvre ce qu’un seuil sur une mesure d’hôte ne peut pas exprimer, par exemple un compte tombé sous sa valeur attendue. Un heartbeat porte une condition, donnez donc des monitors distincts à des affirmations distinctes plutôt que de les replier dans un seul ping.