Résumé

  • La RFC 3014 a défini un journal local permettant de retrouver le contenu d’un Trap ou d’un Inform SNMP que le trajet de notification pouvait ne pas avoir livré.
  • Ce second témoin n’était pas exhaustif : filtre, droits, capacité globale et locale, vieillissement, ressources, redémarrage et gestionnaires concurrents déterminaient ce qui survivait.
  • Les compteurs de notifications enregistrées ou rejetées, l’index croissant et les ruptures de sysUpTime rendaient certaines lacunes visibles sans pouvoir recréer ce qui avait été exclu ou supprimé.

Une notification SNMP était utile précisément parce qu’elle n’attendait pas la prochaine interrogation d’un gestionnaire. Mais cette rapidité avait un envers. Un Trap pouvait disparaître sans accusé de réception. Un Inform pouvait être répété puis abandonné une fois la limite atteinte. Au moment où l’application constatait le silence, l’état fugitif avait déjà pu changer.

Publiée comme Proposed Standard en novembre 2000, la RFC 3014 a ajouté une mémoire locale. La Notification Log MIB permettait de consigner les notifications, puis de les interroger. À partir des variables typées conservées, une application pouvait reconstruire les informations du PDU qui n’était peut-être jamais arrivé par la voie initiale.

Le dispositif créait deux chemins de preuve. Le premier transportait la notification vers son destinataire. Le second gardait une trace auprès d’un moteur SNMP. En cas de perte sur le premier, le second offrait un rattrapage. La RFC ne confondait pourtant pas ce rattrapage avec une archive complète.

Sa structure séparait configuration, statistiques et contenu du journal. La configuration fixait la sélection et la dépense de ressources. Les statistiques comptaient ce qui entrait et ce qui était rejeté. Le journal ne contenait que les entrées encore présentes. Avant de lire une ligne, il fallait donc connaître les décisions qui avaient permis à cette ligne d’exister.

Un journal nommé se référait d’abord à un filtre de la SNMP Notification MIB. L’exemple de la RFC ne retenait que linkUp et linkDown. Une autre notification pouvait être parfaitement réelle et rester absente parce qu’elle ne faisait pas partie de ce champ. Une recherche vide ne signifiait jamais, à elle seule, absence d’événement.

Le contrôle d’accès ajoutait un second cadrage. Les identifiants de sécurité du créateur restaient associés au journal nommé. Pour une notification produite localement, le système devait vérifier que ces identifiants autorisaient l’accès aux objets contenus. Un équipement modeste pouvait n’offrir que le journal par défaut, de nom nul, dépourvu d’identifiants implicites de créateur pour cette admission.

Deux observateurs légitimes pouvaient donc recevoir deux histoires différentes du même équipement. Ce n’était pas nécessairement une falsification : chacun regardait à travers son filtre et ses droits. La question « le journal est-il complet ? » n’avait de sens qu’avec le nom du journal, le filtre, les identifiants, le moteur et le contexte de gestion.

La provenance du message devait elle aussi être conservée. Plusieurs moteurs SNMP pouvaient fonctionner indépendamment dans un même système et chacun pouvait exposer plusieurs contextes. La RFC enregistrait l’identifiant du moteur d’origine et le nom du contexte. Un linkDown sans ces coordonnées ne disait pas quel univers administré avait produit l’affirmation.

Puis venait la rareté. nlmConfigGlobalEntryLimit plafonnait l’ensemble des journaux. nlmConfigLogEntryLimit plafonnait un journal. nlmConfigGlobalAgeOut indiquait au bout de combien de minutes une notification pouvait être retirée. La valeur zéro pouvait retirer une limite configurée ; elle ne créait pas de mémoire physique infinie.

La RFC précisait qu’un plafond ne garantissait pas que ce volume serait réellement disponible. Si la mémoire manquait ou si l’ajout dépassait le plafond global, la plus ancienne entrée de n’importe quel journal pouvait céder sa place. Si le plafond local était dépassé, la plus ancienne entrée du journal concerné pouvait être évincée.

Le plafond global dominait même les autres promesses. Lorsqu’une application l’abaissait, le système devait supprimer les notifications les plus anciennes jusqu’à respecter la nouvelle valeur, y compris lorsqu’elles étaient plus jeunes que le délai d’expiration et que leur journal restait sous sa propre limite. Une écriture de configuration pouvait donc raccourcir rétroactivement la fenêtre de preuve d’un autre lecteur.

Le texte allait plus loin en décrivant la concurrence entre gestionnaires. Plusieurs applications pouvaient tenter d’imposer des valeurs différentes. L’une pouvait faire disparaître des notifications avant que l’autre ne les voie, affectant la fiabilité et l’exhaustivité de ses données. La RFC signalait un possible déni de service et laissait les contre-mesures à des travaux ultérieurs.

Le filet de sécurité contre la perte sur le réseau acquérait ainsi sa propre surface de perte. Une notification pouvait ne pas parvenir au destinataire, ne pas franchir le filtre, être refusée par les droits, être évincée faute de place, disparaître après une réduction de quota ou se retrouver de l’autre côté d’un redémarrage. Ces états ne devaient pas être résumés par un même mot : « absent ».

Les statistiques fournissaient une trace de certaines pertes. Des compteurs globaux et par journal distinguaient les notifications consignées de celles qui avaient été rejetées. Une hausse du compteur de rejet interdisait de présenter les lignes restantes comme l’histoire entière.

Mais le compteur ne remplaçait pas les messages. Savoir que huit notifications avaient été perdues ne révélait ni leur identifiant, ni leurs variables, ni leur gravité. Le nombre rendait le manque visible ; il ne rendait pas son contenu récupérable.

Chaque entrée recevait aussi un index monotone dans son journal. Un collecteur pouvait mémoriser l’index le plus élevé déjà lu et reprendre à partir de là. Il devait surveiller sysUpTime, car une discontinuité indiquait une réinitialisation possible de l’index et une perte possible d’entrées.

Cette continuité répondait à une question limitée : le collecteur avait-il parcouru la séquence encore disponible pendant l’époque actuelle du système de gestion ? Elle ne prouvait pas que toute notification produite avait été admise et gardée. L’absence de trou ne rendait pas visibles les éléments exclus avant la création d’une ligne.

Le redémarrage rendait la notion d’époque explicite. La conservation des entrées après initialisation dépendait de l’implémentation ; en règle générale, la RFC indiquait qu’on ne devait pas s’y attendre. Si des lignes antérieures survivaient, leur temps relatif fondé sur sysUpTime devenait incohérent, et nlmLogTime devait être mis à zéro.

La date civile n’était instanciée que sur les systèmes disposant d’une horloge adaptée. Date locale, temps depuis le démarrage et index de journal constituaient trois coordonnées différentes. Aucun champ isolé ne formait une chronologie certaine à travers redémarrages, corrections d’horloge et moteurs multiples.

Pour une entrée effectivement conservée, la représentation était rigoureuse. Les variables étaient indexées dans la notification et stockées dans l’objet correspondant à leur type SNMP. Le PDU pouvait être reconstruit. Cela prouvait le contenu d’une déclaration sauvegardée, non la réalité physique qu’elle prétendait décrire.

Un agent pouvait avoir mal détecté la condition. Une notification distante pouvait manquer d’authentification adéquate. Le contexte pouvait être mal compris. Une ligne linkDown lue par le collecteur ne prouvait pas non plus qu’un opérateur l’avait vue, qu’il avait choisi la bonne interface, obtenu l’autorisation d’agir, réparé le service et vérifié le résultat côté utilisateur.

Le cadre SNMP environnant a ensuite évolué. RFC 1905 décrivait les opérations SNMPv2. Les RFC 2573 et RFC 2575, utilisées pour les applications et le contrôle d’accès, ont été remplacées par RFC 3413 et RFC 3415. Cette évolution n’a pas transformé une politique d’admission en preuve d’exécution.

Le mécanisme a servi de substrat à d’autres travaux. L’Alarm MIB de la RFC 3877 pouvait faire le lien avec une entrée du Notification Log. La RFC 5676 réutilisait le journal générique pour représenter des messages syslog. Ces références montrent une composition architecturale, pas un taux de déploiement, une exhaustivité mesurée ou une réponse humaine réussie.

À travers la Minimum Initial Specification de Lu Heng, la qualité du texte tient à la minceur de la couche commune. Noms, filtres, limites, compteurs, provenance, index et valeurs typées étaient partagés ; la décision locale sur les ressources demeurait locale.

Running-Code Primacy impose alors de vérifier l’exécution : quel filtre était actif, quelle ligne a été admise, quel quota existait à cet instant, quel compteur appartenait à quelle époque, et quel collecteur a réellement lu. La publication de la MIB ne répond pas à ces questions pour un équipement donné.

Reality Layers empêche enfin le raccourci décisif. Condition, notification, admission, conservation, lecture, interprétation, décision, action et résultat sont des faits reliés, mais distincts. Un journal est un système de preuve situé dans l’exploitation ; il n’est pas l’exploitation elle-même.

La leçon historique de RFC 3014 est donc plus exigeante que « enregistrer les alertes ». Le témoin de secours possède sa propre politique, ses propriétaires, son budget et ses époques. Lorsqu’il avoue une suppression ou une rupture, cette incertitude fait partie du dossier. Lorsqu’il ne sait plus, aucune interface parfaitement propre ne doit parler à sa place.

Sources