Résumé

  • RFC 1224 bornait l’ensemble des alertes d’un agent par maxAlertsPerTime, windowTime et l’état alertsEnabled.
  • Le franchissement du seuil envoyait une dernière alerte alertsDisabled, puis coupait les rapports ; cette alerte terminale pouvait elle-même se perdre.
  • Un journal local numéroté permettait une récupération par interrogation, mais lecture et suppression ne prouvaient ni traitement humain ni réparation.

L’alarme qui ne vient pas

Publié en mai 1991, RFC 1224 est répertorié comme expérimental par le RFC Editor et conservé dans l’historique officiel de l’IETF Datatracker. Le texte ne choisissait pas les symptômes à surveiller. Il organisait le parcours de l’information une fois une alerte produite.

Deux échecs se faisaient face. Une machine en panne ou un réseau isolé ne pouvait garantir l’annonce de sa propre défaillance. À l’inverse, une liaison oscillante pouvait émettre tant d’avis qu’elle occupait la capacité du gestionnaire et du chemin de gestion. L’absence d’alerte n’était pas rassurante ; son abondance pouvait rendre le système de contrôle moins utile.

Le contexte SNMP explique cette prudence. RFC 1157 utilisait un service de datagrammes non fiable et laissait à l’implémentation le choix des destinations de Trap-PDU. RFC 1215 proposait une convention de définition des traps tout en décourageant fortement leur multiplication. Une définition correcte ne constituait donc pas un reçu.

Le « pin » fermait volontairement le robinet

Le premier mécanisme de RFC 1224 était une butée à fenêtre glissante. maxAlertsPerTime fixait le nombre total admis et windowTime la durée examinée. Le compteur couvrait toutes les alertes de l’agent, sans budget distinct par type.

Au démarrage, alertsEnabled valait vrai. Chaque génération d’alerte consultait cet état. Faux, il interdisait l’envoi ; vrai, il autorisait l’émission et ajoutait son heure au calcul. Quand le nombre fixé tenait dans la fenêtre, l’agent expédiait une seule alertsDisabled et passait l’état à faux.

Cette protection économisait processeur et bande passante, mais elle rendait le silence équivoque. La notification qui annonçait l’arrêt pouvait disparaître. Le gestionnaire devait donc interroger périodiquement alertsEnabled, le rétablir au besoin et noter la perte possible de traps pendant l’interruption. Le calme devenait une donnée d’exploitation, pas une conclusion sanitaire.

Le registre conservait une possibilité de preuve

Le second mécanisme consignait chaque alerte locale dans une table : un alertId croissant et une copie OPAQUE dans alertData. Un gestionnaire pouvait demander l’élément suivant ou un identifiant précis, recevoir l’alerte encapsulée, puis éventuellement retirer l’entrée par SET ou DELETE. RFC 1189 donne le cadre CMOT/CMIP contemporain de ces opérations.

Cette conservation ne dépendait pas de la réussite du message spontané. Après une coupure, le gestionnaire pouvait retrouver des conditions anciennes. Mais la table était bornée : une nouvelle entrée remplaçait la plus ancienne lorsqu’elle était pleine. Servir d’abord la plus vieille réduisait le risque d’effacement sans le supprimer.

Un identifiant prouvait seulement qu’une entrée avait existé dans ce mécanisme. Il ne prouvait ni l’émission d’une copie asynchrone, ni sa livraison, ni la lecture avant écrasement, ni la justesse du diagnostic. De même, effacer une ligne décrivait une modification du journal, non l’acquittement d’un opérateur ou la disparition de la panne.

Dans un environnement à plusieurs gestionnaires, les communautés pouvaient disposer de seuils, d’états et de vues différents. L’un pouvait réactiver son flux pendant que l’autre restait bloqué ; une suppression dans une vue n’épuisait pas l’autorité des autres.

Une chaîne plus longue qu’une icône rouge

Une histoire fiable distingue la condition, la règle locale, la génération, le test de l’état, le calcul de fenêtre, la tentative d’envoi, le transport, la réception, l’écriture du journal, l’interrogation, la restitution, la suppression, la décision humaine et le résultat du service. RFC 1224 précisait par ailleurs qu’il ne traitait pas la sécurité : les GET, SET et DELETE ne prouvaient donc aucune identité authentifiée.

Sources