Définissez l’objet VPN avant de choisir SNMP ou une API

Trois décisions précèdent le transport : quel objet l’alerte décrit, quelle direction et quelle portée elle couvre, et quelle fraîcheur la lecture doit avoir. SNMP, une API HTTPS et une sonde applicative peuvent tous signaler quelque chose sur un VPN, et ils ne signaleront pas la même chose. Changer de protocole sans trancher ces trois points ne fait que déplacer l’endroit où la confusion s’accumule. L’objet et le sens de l’alerte sont la conception ; le protocole est la livraison.

Un tableau de bord qui transforme quatre observations différentes en une seule icône verte a déjà mal pris cette décision.

Que devrait réellement signifier l’alerte ?

Elle peut signifier qu’un pair ne peut pas s’authentifier, qu’aucun état de données protégé n’existe, qu’une route pointe au mauvais endroit ou qu’une application ne peut pas terminer son travail. Chacun de ces cas a son propre propriétaire, son propre premier contrôle et son propre taux de faux positifs. Un pair qui ne peut pas s’authentifier est un problème d’identité, une association de sécurité absente est un problème d’état de protocole, une route est un problème de configuration, et une défaillance applicative peut n’être aucun de ceux-là. Décidez à quoi sert l’alerte avant de choisir un collecteur.

Écrivez-la comme une phrase sur laquelle l’ingénieur d’astreinte peut agir. Si la phrase exige deux objets, ce sont deux alertes, pas une qui n’est qu’à moitié juste.

Une table TCP décrit TCP

RFC 4022 spécifie tcpConnectionTable, dont les lignes décrivent des connexions TCP établies, indexées par type d’adresse, adresse et port aux deux extrémités. Les lignes disparaissent à la fermeture de la connexion, et les sockets en écoute apparaissent dans une autre table. Faire tourner un VPN sur la même machine ne transforme pas une table TCP en inventaire d’associations de sécurité IPsec. Elle peut décrire une session de gestion, un flux applicatif ou un tunnel transporté sur TCP, et la ligne elle-même ne vous dira pas lequel.

Les compteurs d’interface portent la même ambiguïté à un niveau plus grossier : les octets d’une interface agrègent chaque pair et chaque flux qui l’utilise.

Construisez un petit contrat d’observation

Pour chaque métrique, consignez l’objet ou le champ d’API pris en charge, l’équipement et la version logicielle propriétaires, l’identifiant du pair ou du service, la direction, l’heure de collecte et le comportement d’actualisation attendu. Utilisez ensuite la vue documentée des associations ou sessions de la passerelle pour l’état du protocole, la table de routage pour l’état du chemin et une requête étroite autorisée pour l’état de l’application. Un point de gestion qui fonctionne prouve que le point de gestion fonctionne, et rien sur l’application derrière.

Si l’agent installé ne dispose pas des objets requis, choisissez une autre interface en lecture seule explicitement prise en charge. Inventer un OID, lire un compteur TCP générique comme un compteur de tunnels ou espérer qu’une ancienne API de fournisseur survive sans changement dans un produit frère sont autant d’impasses.

Des données périmées ne sont pas une panne de tunnel

Un délai de collecte, un identifiant expiré ou un chemin d’API modifié produisent une télémétrie manquante. C’est une défaillance de supervision et un incident différent d’un tunnel qui est tombé. Consignez quelle observation est devenue périmée et quand, afin que l’opérateur obtienne un premier contrôle utile au lieu d’une réinitialisation du tunnel. Traiter chaque délai comme une panne VPN apprend aux gens à ignorer les deux.

Gardez aussi les permissions de collecte étroites. Une interface qui peut modifier la configuration ou effacer des sessions porte une frontière de privilèges qu’une tâche de supervision ne devrait pas hériter, et un compte en lecture seule suffit généralement.

La conception utile nomme l’objet, le sens et l’exigence de fraîcheur. Le choix du protocole en découle, et non l’inverse.