Zusammenfassung

  • RFC 3014 definierte ein lokales Log, aus dem eine Anwendung den Inhalt eines auf dem Benachrichtigungsweg verlorenen SNMP-Traps oder -Informs rekonstruieren konnte.
  • Das zweite Gedächtnis war kein vollständiges Archiv: Filter, Zugriff, globale und lokale Grenzen, Alterung, Ressourcen, Neustarts und konkurrierende Manager bestimmten den Bestand.
  • Zähler für protokollierte und verworfene Meldungen, ein steigender Index und sysUpTime-Brüche zeigten manche Verluste, stellten gelöschte Inhalte aber nicht wieder her.

Eine erzeugte Benachrichtigung war noch keine empfangene Benachrichtigung. Ein Trap konnte ohne Quittung verschwinden. Ein Inform brachte Bestätigung und Wiederholung mit, aber auch eine Wiederholungsgrenze. Beim nächsten Polling konnte der flüchtige Zustand vorbei und seine Nachricht verloren sein.

Die im November 2000 als Proposed Standard veröffentlichte RFC 3014 legte deshalb ein lokales Gedächtnis an. Die Notification Log MIB bewahrte Angaben aus SNMP-Benachrichtigungen. Eine Anwendung konnte die typisierten Variablen später lesen und daraus das Notification-PDU rekonstruieren.

Damit entstanden zwei Beweiswege. Der asynchrone Pfad trug die Meldung zum Empfänger; der lokale Pfad hielt eine abrufbare Spur. Der zweite konnte den Ausfall des ersten ausgleichen. Doch die RFC erklärte ihn nicht zum lückenlosen Archiv, sondern beschrieb seine Aufnahme- und Verlustbedingungen.

Konfiguration, Statistik und Log waren getrennt. Die Konfiguration entschied Auswahl und Ressourcennutzung. Die Statistik zählte Aufnahme und Verwerfen. Im Log standen nur die überlebenden Zeilen. Wer den Bestand ohne die Regeln las, verwechselte Ergebnis und Grundgesamtheit.

Ein benanntes Log verwies auf einen Filter der SNMP Notification MIB. Das Beispiel nahm nur linkUp und linkDown auf. Andere Benachrichtigungen konnten auftreten und korrekt außerhalb dieser Sicht bleiben. Ein leeres Ergebnis bedeutete nicht, dass kein Ereignis stattgefunden hatte.

Zugriffskontrolle schuf eine weitere Grenze. Die Sicherheitsdaten des Erstellers blieben mit dem benannten Log verbunden. Bei lokal erzeugten Meldungen musste das System prüfen, ob der Ersteller die enthaltenen Objekte sehen durfte. Ein kleines System durfte nur das unbenannte Standardlog bereitstellen, ohne implizite Erstellerdaten für die Aufnahme.

Zwei berechtigte Beobachter konnten daher verschiedene Vergangenheiten derselben Anlage sehen. Vollständigkeit war immer relativ zu Name, Filter, Berechtigung, SNMP-Engine und Managementkontext. Da mehrere Engines und Kontexte nebeneinander bestehen konnten, speicherte RFC 3014 Engine-ID und Kontextname der Quelle.

Dann wirkte Knappheit. nlmConfigGlobalEntryLimit begrenzte alle Logs zusammen, nlmConfigLogEntryLimit ein einzelnes Log, nlmConfigGlobalAgeOut die Aufbewahrungsminuten. Null konnte eine konfigurierte Grenze aufheben, nicht aber physischen Speicher erzeugen.

Die Spezifikation warnte, dass eine eingestellte Zahl die Kapazität nicht garantiere. Bei Ressourcenmangel oder Überschreitung konnte der älteste Eintrag weichen. Überschritt ein einzelnes Log seine Grenze, verlor es seine älteste Zeile. Richtlinie und tatsächlich realisierte Aufbewahrung blieben getrennte Tatsachen.

Die globale Grenze hatte Vorrang. Senkte ein Manager sie, musste das System alte Meldungen löschen, bis der neue Wert passte—auch wenn sie jünger als die Altersgrenze waren und ihr Log unter seinem eigenen Limit lag. Eine Konfigurationsänderung konnte das Beweisfenster eines anderen Sammlers rückwirkend verkürzen.

RFC 3014 benannte auch den Konflikt zwischen Managern. Mehrere Anwendungen konnten unterschiedliche Werte setzen; eine konnte Einträge beseitigen, bevor eine andere sie sah. Das beeinträchtigte Zuverlässigkeit und Vollständigkeit und konnte als Denial-of-Service dienen. Gegenmaßnahmen blieben offen.

Das Sicherheitsnetz gegen verlorene Übertragung erhielt so seine eigene Verlustfläche. Die Meldung konnte unterwegs fehlen, am Filter scheitern, an Rechten abgewiesen, durch Kapazität verdrängt, gealtert, nach einer Grenzänderung gelöscht oder durch einen Neustart in eine andere Epoche versetzt werden. „Nicht vorhanden“ bezeichnete keinen eindeutigen Zustand.

Zähler machten einen Teil der Blindheit sichtbar. Global und pro Log wurden protokollierte und verworfene Benachrichtigungen getrennt gezählt. Steigende Verwerfungen widerlegten die Behauptung, die sichtbaren Zeilen seien die ganze Geschichte.

Ein Zähler ersetzte die fehlende Meldung jedoch nicht. Die Zahl fünf verriet weder Kennung noch Variablen noch Bedeutung. Sie konnte wiederholte Linkwechsel oder den einzigen Vorboten eines Stromausfalls umfassen. Der Zähler bewies die Lücke, nicht ihren Inhalt.

Jede Zeile erhielt im benannten Log einen monoton steigenden Index. Ein Sammler konnte seinen höchsten gelesenen Wert merken. Zusätzlich musste er sysUpTime auf Diskontinuität prüfen, weil eine Initialisierung Index und Bestand zurücksetzen konnte.

Indexkontinuität bedeutete nur, dass die erhaltenen Zeilen der laufenden Managementepoche durchlaufen wurden. Sie bewies nicht, dass jede erzeugte Meldung Filter, Zugriff und Speicher überstand. Eine Lücke konnte Verlust zeigen; eine lückenlose Folge zeigte nicht, was nie aufgenommen wurde.

Ob Zeilen eine Initialisierung überstanden, war implementierungsspezifisch und normalerweise nicht zu erwarten. Blieben alte Zeilen erhalten, verlor die auf sysUpTime beruhende Zeit ihren Bezug; nlmLogTime musste für sie null werden. Inhalt konnte überleben, während seine ursprüngliche Zeitkoordinate starb.

Kalenderzeit gab es nur bei Systemen mit entsprechender Uhr. Index, Laufzeit und lokales Datum waren verschiedene Koordinaten. Keine allein bildete über Neustarts, Uhrkorrekturen und mehrere Engines eine sichere Chronologie.

Für erhaltene Zeilen war die Darstellung sorgfältig. Variablen wurden mit eigenem Index und dem passenden SNMP-Typobjekt gespeichert. Das PDU ließ sich rekonstruieren. Das bewies, was die gespeicherte Meldung behauptete, nicht den tatsächlichen physischen Zustand.

Der Agent konnte falsch erkennen, eine entfernte Meldung unzureichend authentisiert oder der Kontext missverstanden sein. Auch eine gelesene linkDown-Zeile bewies keine menschliche Wahrnehmung, Diagnose, Freigabe, Reparatur oder Nutzerwirkung.

Das SNMP-Umfeld änderte sich weiter. RFC 1905 beschrieb SNMPv2-Operationen. RFC 2573 und RFC 2575 lieferten Anwendungen und sichtbasierte Zugriffskontrolle; RFC 3413 und RFC 3415 ersetzten sie später. Der Rahmenwechsel machte aus Konfiguration keinen Ausführungsnachweis.

Spätere Arbeiten verwendeten die Schicht weiter. Die Alarm MIB aus RFC 3877 konnte auf einen passenden Logeintrag verweisen. RFC 5676 nutzte den allgemeinen Mechanismus für Syslog-Nachrichten. Solche Verweise zeigen Wiederverwendung, nicht Verbreitung oder vollständige Reaktion.

Durch Lu Hengs Minimum Initial Specification betrachtet, standardisierte RFC 3014 bewusst wenig: Namen, Filter, Grenzen, Zähler, Quelle, Indizes und typisierte Werte. Die Ressourcenzuteilung blieb lokal.

Diese Freiheit verlangt Running-Code Primacy. Entscheidend ist, welcher Filter tatsächlich lief, ob die Zeile aufgenommen wurde, welche Grenze galt, zu welcher Epoche der Zähler gehörte und ob der Sammler las. Das RFC-Dokument beweist kein Gerä­teergebnis.

Reality Layers hält schließlich Bedingung, Meldung, Aufnahme, Aufbewahrung, Lesen, Deutung, Entscheidung, Maßnahme und Ergebnis auseinander. Das Log ist Zeuge im Betriebssystem, nicht die Wirklichkeit selbst.

Das bleibende Erbe von RFC 3014 lautet daher nicht bloß „Alarme speichern“. Auch das Ersatzgedächtnis hat Auswahl, Eigentümer, Budget und Epochen. Manchmal rettet es die Meldung. Manchmal bleibt nur der Zähler, der seinen eigenen Verlust eingesteht. Diese Grenze gehört in den Befund.

Quellen