Mit den im Abschnitt Abschnitt „Aktives Monitoring“ beschriebenen Anweisungen kann man konfigurieren, wohin Traps gesendet werden sollen, nicht aber, wann solche Traps gesendet werden sollen (oder welche Traps erzeugt werden sollen). Dies ist die Aufgabe der Event MIB, die durch die Arbeitsgruppe Distributed Management (DisMan) der IETF entwickelt wurde und deren Anweisungen nachfolgend beschrieben sind.
iquerySecName NAME
agentSecName NAME
Gibt den Standard SNMPv3-Benutzernamen an, der für interne Anfragen zum Suchen nach beliebigen notwendigen Informationen verwendet werden soll (entweder um den überwachten Ausdruck auszuwerten oder eine Inhalt einer Nachricht
zusammenzustellen). Diese internen Anfragen nutzen immer SNMPv3, und zwar auch dann, wenn normale Anfragen des Agenten per SNMPv1 oder SNMPv2c erfolgen.
Bitte beachten Sie, dass dieser Benutzer ebenfalls explizit erzeugt (createUser) und mit passenden Rechten (z.B. rouser) ausgestattet werden muss. D.h. diese Anweisung dient nur zum Festlegen, welcher Benutzer verwendet werden soll, nicht zum eigentlichen Einrichten des Benutzers.
monitor [OPTIONS] NAME EXPRESSION
Definiert ein MIB-Objekt zum Überwachen. Falls die im Ausdruck EXPRESSION (siehe unten) definierte Bedingung zutrifft, dann initiiert dies das zugehörige Ereignis und es wird entweder eine Benachrichtigung verschickt oder ein SET-Auftrag gegeben (oder beides). Bitte beachten Sie, dass das Ereignis nur einmal angestoßen wird, wenn die Bedingung zum ersten Mal erfüllt ist. Das bedeutet, dass diese monitor-Anweisung erst dann wieder aktiv wird, nachdem die Bedingung einmal nicht mehr erfüllt ist und danach wieder erfüllt wird.
NAME ist ein zu Administrationszwecken verwendeter Name für diesen Ausdruck und dient zum Indizieren der Tabelle mteTriggerTable (sowie Tabellen, die sich auf diese beziehen). Bitte beachten Sie, dass solche monitor-Anweisungen einen internen SNMPv3-Auftrag anstoßen, um die überwachten Werte zu ermitteln (auch dann, wenn normale Anfragen des Agenten per SNMPv1 oder SNMPv2c erfolgen). Siehe Anweisung iquerySecName oben.
EXPRESSION
Die Event MIB unterstützt drei Typen von monitor-Ausdrücken:
existence-Tests, Boolean-Tests und threshold Tests.
OID | ! OID | != OID
Definiert einen existence(0) Überwachungstest. Eine reine OID definiert einen present(0) Test, der dann aktiv wird, wenn (eine Instanz) der überwachten OID erzeugt wird. Ein Ausdruck der Form ! OID definiert einen absent(1) Test, der dann aktiv wird, wenn die überwachte OID gefunden wird. Ein Ausdruck der Form != OID definiert einen changed(2) Test, der dann aktiv wird, wenn sich der überwachte Wert ändert. Bitte beachten Sie, dass vor dem Parameter OID ein Leerzeichen stehen muss.
OID OP VALUE
Definiert einen Boolean(1) Überwachungstest. OP sollte einer der definierten Vergleichsoperatoren (!=, ==, <, <=, >, >=) sein, VALUE sollte ein ganzzahliger Wert sein, mit dem vergleichen wird. Bitte beachten Sie, dass vor und hinter dem Parameter OP Leerzeichen stehen müssen. Ein Vergleich wie z.B. OID !=0 wird nicht korrekt verarbeitet.
OID MIN MAX [DMIN DMAX]
Definiert einen threshold(2) Überwachungstest. MIN und MAX sind ganzzahlige Werte und definieren den unteren und oberen Schwellwert. Falls der Wert der überwachten OID unter den unteren Schwellwert fällt (MIN) oder den oberen Schwellwert übersteigt (MAX), dann stößt die monitor-Anweisung das
zugehörige Ereignis an.
Bitte beachten Sie, dass das für das Überschreiten des Schwellwertes definierte Ereignis erst dann wieder reaktiviert wird, wenn der überwachte Wert unter den unteren Schwellwert (MIN) fällt. Analog dazu wird das Ereignis zum unteren Schwellwert erst wieder durch den oberen Schwellwert (MAX) reaktiviert.
Die optionalen Parameter DMIN und DMAX konfigurieren ein zwei ähnliche Schwellwert-Tests, benutzen aber die Differenzen zwischen zwei
aufeinanderfolgenden Überwachungswerten.
OPTIONS
Das Verhalten des überwachten Ausdrucks kann mit verschiedenen Optionen gesteuert werden. Dazu gehören:
-D
Gibt an, dass der Ausdruck anhand der Differenzen zwischen
Überwachungswerten (anstelle der Werte selbst) ausgewertet werden soll.
-d OID
-di OID
Gibt eine Diskontinuitätsmarkierung für die Bestätigung von Differenzwerten an. Eine -di Objektinstanz wird genau wie angegeben verwendet.
Für ein -d Objekt werden die Instanz-Sub-Ids aus dem entsprechenden (mit Wildcard versehenen) Ausdrucksobjekt angehängt. Wird die Option -I
angegeben, dann gibt es keinen Unterschied zwischen den beiden Optionen.
Diese Option impliziert auch -D.
-e EVENT
Definiert das Ereignis, das initiiert wird, wenn diese monitor-Anweisung | |
-I | Legt fest, dass der überwachte Ausdruck für die angegebene OID als einzelne |
-i OID
-o OID
Definiert zusätzliche varbinds, die zu den Nutzdaten der Benachrichtigung hinzugefügt werden, wenn die Überwachung anschlägt. Für Wildcard-Ausdrücke wird das Suffix der passenden Instanz an alle mit -o spezifizierten OIDs angehängt, während mit -i spezifizierte OIDs als exakte Instanzen behandelt werden. Wird die Option -I angegeben, dann gibt es keinen Unterschied zwischen den beiden Optionen.
Details zum Anordnen von Benachrichtigungs-Nutzdaten siehe strictDisman.
-r FREQUENCY
Überwacht den angegebenen Ausdruck alle FREQUENCY Sekunden.
Standardmäßig wird der Ausdruck alle 600s (10 Minuten) überwacht.
-S
Gibt an, dass der monitor-Ausdruck beim ersten Start des Agenten nicht | |
-s | |
Gibt an, dass der monitor-Ausdruck schon beim ersten Start des Agenten |
-u SECNAME
gibt den Security-Benutzernamen an, der anstelle des Standard iquerySecName zum Scannen des lokalen Hosts verwendet wird. Auch hier gilt, dass dieser Benutzer explizit erzeugt und mit den passenden Rechten ausgestattet werden muss.
notificationEvent ENAME NOTIFICATION [-m] [-i OID | -o OID ]*
Definiert ein Benachrichtigungs-Ereignis namens ENAME. Dieses kann durch eine monitor-Anweisung angestoßen werden, in welcher die Option -e ENAME angegeben wurde (siehe oben). NOTIFICATION sollte die OID der NOTIFICATION-TYPE Definition sein, für welche die Benachrichtigung erzeugt wird.
Wird die Option -m angegeben, dann enthalten die Nutzdaten der Benachrichtigung die Standard varbinds wie sie in der OBJECTS-Klausel der MIB Definition angegeben sind. Diese Option muss nach der NOTIFICATION OID kommen (und die betreffende MIB muss verfügbar und durch den Agent geladen sein). Andernfalls müssen diese varbinds explizit aufgelistet werden (entweder hier oder in der entsprechenden monitor-Anweisung).
Die Optionen -i OID und -o OID geben zusätzliche varbinds an, die an die Nutzdaten der Benachrichtigung angehängt werden sollen (nach der Standardliste). Wenn die monitor-Anweisung, die dieses Ereignis angestoßen hat, einen Wildcard-Ausdruck enthält, dann wird das Suffix der passenden Instanz zu allen mit -o spezifizierten OIDs hinzugefügt, während OIDs, die mit -i spezifiziert sind, als exakte Instanz behandelt werden. Wurde bei monitor die Option -I angegeben, dann gibt es keinen Unterschied zwischen diesen beiden Optionen.
setEvent ENAME [-I] OID = VALUE
Definiert das Setzen eines Ereignisses ENAME, indem der angegebenen OID der ganzzahlige Wert VALUE zugeordnet wird. Dieses Ereignis kann durch eine monitor-Anweisung ausgelöst werden, in der die Option -e ENAME (siehe oben) angegeben wurde.
Falls die monitor-Anweisung, die dieses Ereignis angestoßen hat, einen Wildcard-Ausdruck enthält, dann wird das Suffix der passenden Instanz normalerweise zur OID hinzugefügt. Wurde bei der monitor- oder setEvent-Anweisung die Option -I angegeben, dann wird die angegebene OID als exakte Instanz behandelt.
strictDisman yes
Die Definition der SNMP-Benachrichtigungen besagt, dass die in der OBJECT-Klausel definierten varbinds zuerst kommen sollten (in der angegebenen Reihenfolge), gefolgt von beliebigen "zusätzlichen" varbinds, die der Benachrichtigungs-Generator für nützlich hält. Der plausibelste Ansatz wäre:
diese Pflicht-varbinds mit der notificationEvent Anweisung zu verbinden
und dann die varbinds an das Ende der Liste anzuhängen, die mit derjenigen monitor-Anweisung verknüpft sind, die die Benachrichtigung ausgelöst hat.
Dies ist das Standardverhalten der Net-SNMP Event MIB Implementierung. Unglücklicherweise besagen die DisMan Event MIB Spezifikationen jedoch, dass die Auslöser-bezogenen varbinds zuerst kommen sollten, gefolgt von den Ereignisbezogenen.
Diese Anweisung kann dazu verwendet werden, dieses grundsätzlich korrekte (aber unangebrachte) Verhalten wiederherzustellen.
Falls es keine monitor-Anweisungen mit varbinds für Nutzdaten gibt (weder -i noch -o in monitor), dann ist die Angabe dieser Anweisung irrelevant.
linkUpDownNotifications yes
konfiguriert die Event MIB Tabellen zum Überwachen von ifTable für Netzwerk-Schnittstellen, sodass beim Aktivieren oder Deaktivieren eine entsprechende linkUp oder linkDown Benachrichtigung ausgelöst wird.