Supervision réseau : quoi surveiller, sur quoi alerter

Une alerte n’est utile que si quelqu’un la lit, et personne ne lit un flux fait surtout de bruit. Superviser un réseau, ce n’est pas installer un outil, c’est décider de ce que vous devez savoir, à quelle vitesse, et qui doit agir quand cela arrive.

Pensez au tableau de bord d’une voiture. Il comporte deux sortes d’instruments. Les cadrans (vitesse, carburant, température) affichent une valeur en continu ; vous les regardez quand vous voulez, et leur intérêt est dans l’évolution, comme l’aiguille du carburant qui descend doucement. Les voyants restent éteints jusqu’à ce que quelque chose exige votre attention maintenant : pression d’huile, freins. Un bon tableau de bord a beaucoup de cadrans et peu de voyants. Et chacun sait ce qui arrive à un voyant toujours allumé : au bout d’une semaine, plus personne ne le voit. La supervision réseau fonctionne de même : les graphiques sont les cadrans, les alertes les voyants, et la plupart des installations échouent en transformant des cadrans en voyants.

Ce guide est la carte : ce que les équipements disent déjà et comment, ce qui va dans les graphiques et sur quoi alerter, par où commencer et comment garder des alertes utiles. Les deux protocoles par lesquels les équipements rendent compte d’eux-mêmes ont leurs propres articles : Qu’est-ce que le syslog ? et Qu’est-ce que le SNMP ?

Pourquoi superviser ?

La supervision existe parce que les pannes surviennent quand personne ne regarde. Une liaison qui se remplit à 14 h n’est visible que pour qui regarde à 14 h. Un port qui tombe une minute à trois heures du matin ne laisse aucune trace au matin. Un humain ne peut pas regarder en continu ; un programme, si.

La raison profonde est de langage. « Internet est lent » est une opinion, pas une mesure : quel site, quelle heure, à quel point ? Sans ces trois réponses, aucune décision ne peut s’appuyer dessus. La supervision transforme les opinions en mesures, et un problème mesurable devient soluble avant même d’être résolu. Les problèmes de capacité n’arrivent d’ailleurs pas d’un coup, ils grandissent en silence : les liaisons des agences sont dimensionnées au plus juste, puis tout le monde rejoint en même temps une réunion en ligne, et la liaison sature.

Quand n’en avez-vous pas besoin ? Avec un switch et quelques équipements, serveur, logiciel et tableau de bord peuvent coûter plus qu’ils ne rapportent. Le seuil est franchi avec plus d’un site, une liaison louée payée à la capacité, ou quand vous apprenez les pannes par les utilisateurs. Ce dernier signe est le plus net.

Ce que disent déjà les équipements : journaux et mesures

Avant de choisir un outil, écoutez ce qui se dit déjà. Les équipements réseau rendent compte d’eux-mêmes par deux canaux, qui répondent à des questions différentes.

Les mesures sont des nombres, interrogés régulièrement, le plus souvent via SNMP. Un serveur de supervision demande à chaque équipement ses compteurs toutes les quelques minutes : octets passés par une interface, charge CPU, mémoire, température. Une valeur dit peu de chose ; deux valeurs à quelques minutes d’écart donnent un débit, une série de débits une tendance. SNMP fonctionne aussi dans l’autre sens : un équipement peut envoyer un trap au moment d’un événement.

Les journaux sont des phrases, envoyées par l’équipement quand quelque chose se passe, le plus souvent via syslog : quel port est tombé, qui s’est connecté, quel processus a échoué, quelle configuration a changé. Une analyse d’incident se lit dans les journaux.

Un nombre ne raconte pas d’histoire, une phrase ne montre pas de tendance. SNMP dit que le CPU est à 80 % ; le syslog, quel processus le charge. Une bonne installation collecte les deux. La mécanique, par exemple le sens du nombre en tête d’une ligne syslog, pourquoi la community SNMP est lisible par quiconque sur le réseau, ou une règle de pare-feu Windows qui bloque en silence les récepteurs de traps, est mesurée dans les deux articles de protocole.

Cadrans ou voyants : tendances et alertes

La capacité va dans les graphiques ; la disponibilité et les pannes vont dans les alertes. Cette seule phrase évite la plupart des erreurs de supervision.

La capacité évolue lentement et demande du contexte. Une liaison à 70 % est normale à midi et préoccupante si elle était à 40 % le mois dernier. Inutile de réveiller quelqu’un ; il faut que quelqu’un voie la courbe lors d’une revue hebdomadaire et planifie une montée en débit. Les outils bâtis sur des bases de données circulaires, Cacti en est l’exemple classique, sont faits pour cela : courbes longues, peu d’effort, lecture facile.

La disponibilité et les pannes exigent une action immédiate. Un switch de cœur qui ne répond plus, une liaison tombée, un disque qui se remplit, un onduleur passé sur batterie : ce sont des voyants. Les outils construits autour de déclencheurs et de notifications, Zabbix en est un exemple répandu, transforment des conditions en alertes.

La frontière est assez nette pour une règle simple : l’un trace la capacité, l’autre transforme la disponibilité en alertes. Les environnements matures font tourner les deux côte à côte, certains y ajoutent un outil d’inventaire, afin que chaque question ait un endroit évident où chercher.

Par où commencer : les premiers graphiques

Avec des dizaines d’équipements et des centaines d’interfaces, la question n’est pas ce qu’on pourrait tracer, mais ce qui va d’abord à l’écran.

D’abord, le port relié au routeur de votre fournisseur d’accès. Tout le trafic Internet de l’organisation passe par cette interface, donc son graphique répond à la fois à la capacité et à « pourquoi Internet est lent ». C’est le premier endroit à regarder pendant une panne, mais sa vraie valeur se révèle les jours ordinaires : voir quelle part d’une liaison à 200 Mbit/s est occupée à chaque heure.

Lisez le maximum, pas la moyenne. Pour décider de la capacité, c’est la valeur de pointe qui compte : si le pic d’une liaison à 100 Mbit/s atteint 95, elle commence à saturer même si la moyenne paraît confortable. Et attention au sens : entrant et sortant se définissent par rapport à l’interface supervisée, pas par rapport à vous.

Comparez ensuite ce qui est comparable. Ne mettez pas cinq propriétés d’un même équipement côte à côte, mais la même propriété du plus grand nombre d’équipements, par exemple la liaison Internet de chaque site. La valeur est dans la comparaison. Le danger est de regarder un seul site et de conclure « ils ont tous 200 Mbit/s, tout va bien », alors que le site absent de l’écran est justement au plafond.

Affichez-les au mur. Un moniteur ou un téléviseur libre au siège, avec une grille de deux colonnes des graphiques les plus critiques, sort la supervision des bureaux pour l’installer dans la pièce. Quand huit graphiques restent toujours visibles, un site au plafond ou un switch devenu muet se remarque sans que personne n’ouvre de tableau de bord.

Au-delà du trafic : la santé des équipements

La bande passante n’est pas la seule chose que SNMP sait tracer. L’état physique et système des équipements compte autant, et c’est là que la supervision trouve des problèmes que personne n’aurait soupçonnés. Vous avez peut-être installé le même modèle de switch dans chaque agence, mais leur santé n’a pas à être identique. Ce qui la décide est souvent l’environnement : propreté, température de la pièce, climatisation, ventilation de la baie.

À suivre en plus du trafic : température, CPU et mémoire des switchs, routeurs et pare-feu ; occupation des disques des serveurs, pour voir des semaines à l’avance quand un disque sera plein ; état des onduleurs, avec charge, taux d’utilisation et autonomie restante ; latence et perte de paquets vers les destinations clés, qui montrent une liaison qui se dégrade bien avant qu’elle ne soit pleine ; capteurs d’environnement de la salle technique, s’ils parlent SNMP.

Écouter le grésillement : repérer les pannes tôt

Avant qu’une liaison radio ne coupe, le grésillement augmente. Les réseaux font pareil. Des compteurs d’erreurs qui montent sur une interface, une mémoire qui grimpe semaine après semaine sur un switch, une température qui gagne quelques degrés chaque été : autant d’avertissements discrets qu’une panne approche. Prenez ces petits signaux au sérieux, mettez l’équipement en maintenance, et la panne n’arrive jamais. Tracez les compteurs qui signalent un problème, pas seulement ceux qui indiquent la charge, et passez en revue les courbes lentes à intervalles réguliers : une montée progressive, personne ne la remarque d’un coup d’œil quotidien.

Le syslog porte le même avertissement précoce, avec une particularité : un message qui se répète toutes les quelques secondes n’est pas une information, c’est un symptôme. Dans le laboratoire de Qu’est-ce que le syslog ?, un switch qui tournait depuis des mois sans plainte jetait toutes les deux secondes un message de protocole qu’il ne comprenait pas, et 99 % de ses journaux étaient cette répétition.

Garder des alertes utiles

La fatigue d’alerte est l’échec de supervision que tout le monde connaît : tant d’alertes se déclenchent que plus personne ne les lit, et celle qui compte se perd dans la masse. Quatre règles gardent les alertes utiles.

N’alerter que sur ce qui demande une action. Si la bonne réaction est « noter et continuer », cela va dans un graphique ou un rapport, pas dans la poche de quelqu’un. Chaque alerte doit répondre à : que fait ensuite la personne qui la reçoit ?

Donner un responsable à chaque alerte. Une notification doit aboutir chez une personne ou une astreinte nommée, pas dans une boîte partagée dont chacun suppose qu’un autre la lit. Une alerte envoyée à tout le monde n’est envoyée à personne.

Fixer les seuils à partir de l’historique, pas des valeurs par défaut. Le graphique des derniers mois montre ce qui est normal pour chaque liaison. Des seuils fondés dessus ne se déclenchent pas sur les pics ordinaires ; les valeurs du constructeur se déclenchent tout le temps ou jamais.

Traiter une alerte ignorée comme un défaut. Si une alerte se déclenche et que personne n’agit, c’est l’alerte ou le processus qui est faux. Corrigez l’un ou l’autre. Même chose pour les alertes qui se déclenchent et disparaissent seules chaque jour : elles apprennent aux gens à ignorer les alertes.

Une catégorie d’alertes mérite une mention, car elle reste si souvent inutilisée : les traps SNMP d’échec d’authentification. Quand quelqu’un interroge un équipement avec une mauvaise community, le demandeur ne reçoit aucune réponse, mais l’équipement peut signaler la tentative au serveur de supervision. Silencieuse pour le mauvais côté, visible seulement pour qui écoute le port 162 : l’un des signaux d’intrusion les moins coûteux d’un réseau.

Vue en direct ou historique enregistré ?

Les outils de supervision offrent en général deux façons de regarder. Par défaut, l’historique : le collecteur mesure toutes les quelques minutes, stocke les valeurs, et vous revenez au graphique au besoin. Beaucoup ont aussi un mode temps réel qui interroge un graphique toutes les quelques secondes. Le bon choix dépend de la présence de quelqu’un devant l’écran. Quand un opérateur suit activement un problème, le temps réel est précieux. Mais la réalité est souvent une petite équipe qui mène plusieurs tâches de front et n’ouvre la supervision qu’au besoin ; pour elle, l’historique enregistré est bien plus pratique.

Dans tous les cas, une interrogation toutes les cinq minutes masque les pics courts. Un pic de quelques secondes disparaît dans la moyenne, et c’est pourquoi une liaison peut couper des appels alors que son graphique paraît sain. Interrogez plus souvent les liaisons critiques, et utilisez les traps pour les événements qui ne peuvent pas attendre.

Les fondations : le temps, l’accès et la conservation

Trois choses sont sous chaque graphique et chaque alerte, et chacune lâche en silence.

Le temps. Graphiques et journaux ne valent que par leurs horloges. Un serveur de supervision dont l’horloge dérive décale chaque courbe, et les graphiques de différents équipements ne concordent plus. Synchronisez le serveur et tous les équipements sur la même source de temps fiable avant de vous fier à une chronologie.

L’accès. Les protocoles de supervision sont puissants et, dans leurs anciennes versions, non protégés : SNMPv2c envoie sa community en clair, le syslog en UDP des lignes que quiconque sur le chemin peut lire. Gardez le trafic de supervision sur un réseau d’administration, utilisez SNMPv3 là où les équipements le permettent, et limitez qui peut interroger les équipements. Comment donner au trafic d’administration son propre segment est expliqué dans le guide de la segmentation réseau.

La conservation. Tout garder indéfiniment coûte cher et ne sert à rien. Décidez combien de temps graphiques et journaux sont conservés, filtrez le bruit à la source avec des seuils raisonnables, regroupez les répétitions et archivez l’ancien. Si vos journaux relèvent d’une obligation de conservation, la décision ne vous appartient pas seule, et durée, protection contre la falsification et horodatages fiables se construisent autour du collecteur, pas par le protocole. Prévoyez l’espace : dans le laboratoire syslog, un seul switch inactif produisait environ 11 Mo de journaux par jour.

Conclusion : installer est facile, regarder est le vrai travail

Installer un outil de supervision, ajouter un équipement et tracer le premier graphique prend une demi-journée. Le vrai travail est de s’assurer que quelqu’un regarde. L’échec le plus courant n’est pas l’absence d’outil, mais un outil installé « pour en avoir un » et laissé sans responsable : un tableau de bord que plus personne n’ouvre six mois plus tard.

Une courte liste pour commencer :

• Tracer d’abord la liaison Internet, puis les liaisons montantes entre switchs, puis la santé des équipements centraux.
• Lire les maximums, pas les moyennes, pour les décisions de capacité.
• Comparer les sites côte à côte sur le même écran.
• Collecter les deux canaux : SNMP pour les nombres, syslog pour les événements.
• N’alerter que sur ce qui demande une action, avec un responsable nommé pour chaque alerte.
• Passer en revue les courbes lentes régulièrement, compteurs d’erreurs et températures compris.
• Synchroniser toutes les horloges avant de se fier aux chronologies.

Les articles de protocole de ce guide montrent ce que ces canaux transportent réellement, mesuré sur un vrai switch : Qu’est-ce que le syslog ? et Qu’est-ce que le SNMP ?