Documentation

Moniteurs

Un moniteur, c’est une chose que vous voulez surveiller et la règle qui décide si elle va bien. Il en existe trente types. La plupart émettent une requête depuis notre réseau et jugent la réponse ; deux attendent que quelque chose arrive du vôtre, et quatre recueillent ce que vos routeurs exportent vers votre propre sonde privée.

Les types

Web et réseau

Certificats et domaines

Messagerie

Protocoles d’infrastructure

Ceux-là existent parce qu’une vérification tcp sur le port ne prouve presque rien à leur sujet. Un SMSC accepte encore TCP longtemps après avoir cessé d’enregistrer qui que ce soit ; une pile SIP peut être bloquée avec le socket ouvert ; un serveur XMPP dont le certificat a expiré termine parfaitement une poignée de main TCP.

Bases de données

Pro et au-delà. Une vérification tcp sur le 5432 prouve que quelque chose a accepté une socket, et toutes les pannes intéressantes d’une base de données laissent la socket ouverte : Postgres en récupération, une limite de connexions épuisée par une application qui fuit, un rôle dont le mot de passe a expiré, une base renommée, un répertoire de données non monté. Ces vérifications ouvrent donc une connexion, s’authentifient et posent au serveur une question triviale.

Aucune ne lit ni n’écrit quoi que ce soit. C’est une vérification de disponibilité, pas une transaction synthétique : donnez-lui un compte qui ne peut rien faire d’autre que se connecter.

L’identifiant est stocké en clair, car la sonde qui exécute la vérification reçoit la configuration telle quelle. C’est pourquoi ces cinq-là ne s’exécutent que depuis une sonde habilitée pour les données personnelles — la même restriction que portent snmpet smpp.

Cela laisse deux possibilités. Votre propre sonde privée, celle pour laquelle ces vérifications sont conçues : elle tourne sur votre matériel, dans votre réseau, si bien que la configuration ne quitte jamais votre infrastructure — et c’est le plus souvent la seule chose capable d’atteindre une base de données digne d’être surveillée, une base derrière un VPC, un lien privé ou une liste d’autorisation n’étant joignable depuis aucun réseau étranger, y compris le nôtre. À défaut, nos propres points d’observation dans l’UE, pour une base réellement joignable publiquement.

Conteneurs

Pro et au-delà. Un contrôle du port publié d’un conteneur répond pour le proxy placé devant lui. Un conteneur qui plante en boucle derrière une politique de redémarrage est joignable quelques secondes à chaque fois, un HEALTHCHECK en échec laisse le port ouvert, et un arrêt pour manque de mémoire suivi d’un redémarrage ressemble à une seule requête lente. Le moteur Docker connaît les trois.

L’accès à l’API du moteur équivaut à root sur cet hôte : le point de terminaison et ses certificats client sont donc des identifiants, et ce type ne s’exécute que depuis une sonde habilitée pour les données personnelles. Un socket unix n’est ouvert que par une sonde démarrée avec DOCKER_SOCKET_ENABLED=true, ce que vous activez sur votre propre sonde privée à côté de votre propre moteur et que nous n’activons jamais sur les nôtres ; ailleurs, la vérification s’abstient au lieu de déclarer votre conteneur en panne. Un point de terminaison tcp:// ou https:// avec certificats client fonctionne depuis l’une comme l’autre.

Trafic réseau

Business et au-delà. Une vérification de disponibilité vous dit qu’un lien répond ; elle ne peut pas vous dire que le lien est saturé, qu’une sauvegarde l’inonde à midi ou que le trafic vers votre couche web est discrètement tombé à zéro. Vos routeurs et commutateurs comptent déjà tout cela et savent l’exporter. Ces types collectent cet export et en tirent des débits, une répartition par protocole, et les ports et adresses les plus actifs.

Chaque seuil est facultatif — un débit maximal, un débit minimal, un débit de paquets maximal. Au-dessus ou en dessous de l’un d’eux, c’est dégradé. Sans seuil, le moniteur enregistre et trace le trafic sans alerter sur une valeur. Un exportateur qui cesse d’envoyer plus longtemps que vous ne l’autorisez est en panne, et un exportateur qui envoie le mauvais protocole — du sFlow vers un moniteur NetFlow — est en panne avec un message qui le dit.

Ces types ne s’exécutent que sur votre propre sonde privée. L’export de flux passe par UDP, qui ne porte aucune authentification : un collecteur sur notre réseau partagé devrait se fier à l’adresse de l’expéditeur, que n’importe qui peut falsifier ou revendiquer. Sur une sonde à l’intérieur de votre réseau, seuls vos routeurs peuvent l’atteindre. Vos enregistrements de trafic restent aussi chez vous — ils nomment les adresses des personnes de votre réseau, donc la sonde les agrège là où ils arrivent et ne nous envoie que les débits et les tableaux des dix premiers. Démarrez la sonde avec FLOW_COLLECTOR_ENABLED=true, publiez les ports UDP, dirigez vos routeurs vers elle et choisissez cette sonde en créant le moniteur.

Les choses qui nous font signe

À quelle fréquence il s’exécute

Vous choisissez un intervalle ; votre forfait fixe le plancher. Free vérifie chaque minute, Starter toutes les 45 secondes, Pro toutes les 30, Business toutes les 15, Enterprise toutes les 5.

Quatre types ont leur propre plancher, quel que soit le forfait, parce que la réponse ne change pas d’une minute à l’autre et que demander plus souvent ne serait que du bruit et de la charge sur le serveur de quelqu’un d’autre :

Authentification du courrier, et envoi réel

Un moniteur mail_posture lit SPF, DKIM, DMARC, MTA-STS et TLS-RPT dans le DNS et vous dit ce qui est cassé. Cela détecte un enregistrement qui s’est dégradé, et pas ce dont ces enregistrements sont une prédiction : un domaine peut publier un SPF irréprochable et émettre depuis un serveur que cet enregistrement désavoue, publier une clé DKIM et signer avec une autre déjà remplacée, ou voir une passerelle réécrire un en-tête et casser une signature qui était valide au départ.

Donnez une boîte aux lettres au moniteur — une adresse et des identifiants SMTP et IMAP — et il mesure au lieu de prédire. Chaque heure il remet un message à votre propre serveur sortant, adressé à notre récepteur, qui vérifie le SPF et le DKIM de ce qui est réellement arrivé, puis répond dans la boîte pour que l’exécution suivante confirme en IMAP que votre domaine reçoit aussi du courrier. Les deux trajets doivent aboutir. Un domaine qui émet parfaitement et a cessé d’accepter le courrier en silence est une vraie panne, et une que toute vérification à sens unique déclare saine.

Deux choses à savoir avant de le remplir. Les identifiants sont stockés en clair et remis à la sonde qui exécute la vérification — c’est vrai de la configuration de n’importe quel moniteur, puisque c’est la sonde qui émet la requête — un moniteur avec boîte aux lettres ne s’exécute donc qu’au sein de l’Union européenne, jamais sur nos sondes ailleurs. Utilisez un mot de passe d’application si votre fournisseur en propose. Et la réponse que nous envoyons est supprimée de la boîte dès qu’elle a été lue, pour que le dossier ne se remplisse pas.

Un intervalle n’est pas la vitesse à laquelle vous apprenez une panne

C’est le passage qui mérite deux lectures. Une seule vérification en échec n’ouvre pas d’incident. Un moniteur doit échouer trois fois de suite — c’est le réglage confirmations, et trois est la valeur par défaut — avant que quiconque soit prévenu.

Ce n’est pas trois fois l’intervalle pour autant. Quand une vérification échoue, la suivante est avancée au lieu d’attendre l’intervalle entier : un moniteur à cinq minutes confirme donc une panne en bien moins de quinze minutes. Un résultat ne peut jamais que rapprocher la vérification suivante, jamais la repousser.

Baissez confirmations si vous préférez être réveillé tôt et parfois pour rien. Montez-le pour quelque chose dont vous savez que c’est instable.

Les vérifications tournent entre les emplacements

Nous vérifions depuis plusieurs endroits, un par intervalle, en rotation. Trois points d’observation sur un moniteur à cinq minutes, cela veut dire que chacun le voit toutes les quinze minutes alors que le moniteur est toujours vérifié toutes les cinq.

C’est ce qui donne son sens à la confirmation : trois échecs de suite sont trois échecs vus depuis trois endroits différents, si bien qu’une sonde qui n’atteint tout simplement pas votre serveur est sans conséquence — la région suivante réussit et la série repart de zéro.

Un échec pendant qu’un autre emplacement va bien vaut dégradé et non en panne. En panne doit vouloir dire que votre site est injoignable, pas qu’un point d’observation ne le voit pas. Cela compte quand même comme un échec et un incident s’ouvre quand même, avec la gravité dégradé.

Un pare-feu n’est pas une panne

Un site bloqué à un emplacement échoue à chaque vérification depuis là-bas tout en fonctionnant partout ailleurs. Compter cela comme de l’indisponibilité ferait de votre taux de disponibilité une affirmation sur notre routage plutôt que sur votre service.

Une région qui n’a jamais atteint un moniteur en est donc exclue après trois échecs. Une région qui l’atteignait autrefois et ne l’atteint plus continue de compter, définitivement — parce que de là-bas c’est une vraie panne, et la masquer serait pire.

Si le monde a changé autour d’un site — un blocage gouvernemental, une route disparue, un filtrage géographique ajouté après coup —, vous pouvez recalibrer un moniteur depuis sa page. Cela efface l’historique de toutes les régions pour ce seul moniteur, de sorte que le comportement actuel devienne la nouvelle référence. C’est par moniteur et délibéré, parce que la mesure seule ne sait pas distinguer un blocage permanent d’une panne permanente.

Où les vérifications s’exécutent, et ce que nous y envoyons

Certains points d’observation sont hors de l’EEE. Une vérification dont la configuration pourrait contenir des données personnelles — un en-tête de requête, un corps de requête — ne s’exécute que depuis l’intérieur. C’est l’ordonnanceur qui l’impose, et non une politique, et c’est testé contre une vraie base de données à chaque build. snmp, smpp et les cinq types de base de données sont confinés de la même façon, parce que chez l’un comme chez l’autre le secret est le protocole.

Non testé n’est pas réussi

Pour tls_audit, chaque sonde a trois issues plutôt que deux : pris en charge, refusé ou non testé. L’OpenSSL 3 de Node ne compile ni RC4 ni 3DES, ces deux familles ne peuvent donc jamais être proposées depuis notre flotte — et le silence sous ces rubriques se lirait comme « nous avons regardé, et c’est désactivé », soit un feu vert mensonger sur exactement les constats pour lesquels on ouvre un audit TLS.

Dépendances

Dites à un moniteur ce dont il dépend — une base de données, une passerelle, une API en amont — et lorsque la dépendance tombe, ce qui se trouve derrière est marqué comme conséquence au lieu d’ouvrir ses propres incidents. Un incident, pas quarante, et la page nomme la cause plutôt que les symptômes.

Fenêtres de maintenance

Planifiez une fenêtre : tant qu’elle est ouverte, personne n’est alerté. À utiliser pour un déploiement dont vous savez qu’il mettra la chose hors ligne. Par défaut, les vérifications continuent de s’exécuter et d’enregistrer : ces minutes comptent dans le taux de disponibilité comme les autres — la fenêtre retire l’alerte, pas l’historique. Désactivez « continuer à vérifier » et rien n’est vérifié tant que la fenêtre est ouverte, ce qui laisse un trou dans l’historique plutôt qu’un creux. Une fenêtre peut se répéter chaque jour, chaque semaine ou chaque mois, et chaque occurrence retient les alertes, pas seulement la première.

Mise en pause

Un moniteur en pause n’est pas vérifié et ne compte contre rien. Il garde son historique : mettre en pause puis reprendre ne perd donc pas le relevé.