05.05.2011, 04:11 UTC+2

Sie sind nicht angemeldet.

Flexible Erweiterung von varbinds

KevJon

Anfänger

Beiträge: 4

Anzahl Nagios-Server: 1

Nagios-Version(en): 1

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 641

Anzahl Services: 35

Betriebssystem(e): 5

Plugin-Version(en): 1

NDO-Version: 1

1

21.04.2011, 14:32

Flexible Erweiterung von varbinds

Hi, ich habe folgendes Problem. Ein zu monitorendes System sendet Traps mit 5 varbinds die folgendermaßen definiert sind:

varbind 1
OID : alarmModelDescription OID...
Value: OCTET STRING (Alarm Model Description)

varbind 2
OID : alarmActiveResourceId OID...
: alarmActiveResourceId OID..YY.YY.MM.DD.HH.MM.SS.dS.
...
Value: OBJECT IDENTIFYER (Resource Id)

varbind 3
OID : alarmActiveDescription OID...
: alarmActiveDescription OID..YY.YY.MM.DD.HH.MM.SS.dS.
...
Value: OCTET STRING (Alarm Active Description)

varbind 4
OID : ituAlarmEventType OID...
Value: INTEGER (Event Type)

varbind 5
OID : ituAlarmProbableCause...
Value: INTEGER (Probable Cause)

Die OID Anteile sind in der ausgelieferten MIB korrekt beschrieben und könnten auch von meine Monitoringumgebung aufgelöst werden. Durch diese flexiblen Erweiterungen mit "..." wird das ganze unlesbar. Die Fehlermeldung gegen den Hersteller wird so bentwortet:

Der Teil nach der OID ist als Module definiert, welcher über die SNMP Agent API gemappt werden muss. Dieser veränderliche Anteil wird nicht über eine MIB abgedeckt.

Ich kann mir nicht vorstellen, dass ein solches Vorgehen RFC-konform ist. Entsprechende Argumentation wird mit "works as implemented" zurückgewiesen.

Irgendwelche Vorschläge, wie ich aus dem Problem rauskomme? Gibt es in einem RFC "den einen Satz" mit dem ich den Hersteller überzeugen kann, dass sein Vorgehen nicht korrekt ist?

Gruß
KevJon

bern

Profi

Beiträge: 1 355

Anzahl Nagios-Server: 2-5

Nagios-Version(en): 1-3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 80-200

Anzahl Services: 1400-2000

Betriebssystem(e): Linux

Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)

Sonstige Addon's: n2rrd, PNP, livestatus

2

21.04.2011, 17:26

Ist das sowas, daß man eine OID x.y.z.66.108.97.104 hat und das steht dann für fooBarBaz."Blah" (ASCII Values aneinandergereiht)? Wenn ja, dürftest Du Pech haben; Das heißt INDEX und steht schon in der SNMPv2-SMI MIB drin.

(Und wenn man auf einer nicht allzu neuen ADVA CPE einen ESA Test laufen läßt, der per String (Name) eindeutig identifiziert wird, und dessen Ergebnisse per SNMP abholen will, dann macht man einen snmpwalk auf esaProbeStatsEntry."Name".)

KevJon

Anfänger

Beiträge: 4

Anzahl Nagios-Server: 1

Nagios-Version(en): 1

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 641

Anzahl Services: 35

Betriebssystem(e): 5

Plugin-Version(en): 1

NDO-Version: 1

3

21.04.2011, 20:42

Im Prinzip, ja. Aaaber ein einfacher Index is dat nich.
Beispiel zu Varbind 2:

1.3.6.1.4.1.xxx.yyy.2.666.1.2.2.1.10.4.84.69.68.73.11.7.215.10.5.10.44.51.0.43.2.0

1.3.6.1.4.1.xxx.yyy.2.666.1.2.2.1.10(OID) .4(Length of Module) .84.69.68.73(Module Name) .11.7.215.10.5.10.44.51.0.43.2.0(Date and Time [yy.yy.mm.dd.hh.mm.ss.dss.+/-.hhUtc.mmUtc]) .1(Alarm Sequence Number)

Das Teil hat ungezählte Module und Date and Time in den OID Baum reinzukriegen ist m.E. unmöglich.

bern

Profi

Beiträge: 1 355

Anzahl Nagios-Server: 2-5

Nagios-Version(en): 1-3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 80-200

Anzahl Services: 1400-2000

Betriebssystem(e): Linux

Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)

Sonstige Addon's: n2rrd, PNP, livestatus

4

21.04.2011, 22:45

Zitat von »KevJon«

Im Prinzip, ja. Aaaber ein einfacher Index is dat nich.
Wo schrieb ich denn 'was von "einfach"? ;)Ich kann das Prinzip auch nicht sonderlich gut leiden, muß aber zugeben, daß die Alternative im genannten ADVA-Szenario (ESA Tests mithilfe einer lfd. Nummer in der OID abbilden und die OID zum Test "FooBarBaz" muß man sich per snmpwalk über den Teilbaum mit den Namen suchen) auch nicht wirklich göttlich wäre.

Zitat von »KevJon«

Beispiel zu Varbind 2:
1.3.6.1.4.1.xxx.yyy.2.666.1.2.2.1.10(OID) .4(Length of Module) .84.69.68.73(Module Name) .11.7.215.10.5.10.44.51.0.43.2.0(Date and Time yy.yy.mm.dd.hh.mm.ss.dss.+/-.hhUtc.mmUtc) .1(Alarm Sequence Number)
Also Modul "TEDI", Zeitstempel 05-Oct-2007 10:44:51.0 UTC+02:00. (Die 11 ist ein VT, das scheint die Desc geschlabbert zu haben. 7*256+215 = 2007.)

Zitat von »KevJon«

Das Teil hat ungezählte Module und Date and Time in den OID Baum reinzukriegen ist m.E. unmöglich.
Wieso, hab' ich doch grad' oben vorgerechnet. Sowohl Strings beschränkter Länge als auch Zeitstempel wie in Deinem Zitat definiert sind endliche Zustandsräume, also auf endliche Bytefolgen abbildbar ...

KevJon

Anfänger

Beiträge: 4

Anzahl Nagios-Server: 1

Nagios-Version(en): 1

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 641

Anzahl Services: 35

Betriebssystem(e): 5

Plugin-Version(en): 1

NDO-Version: 1

5

22.04.2011, 10:58


Zitat

Also Modul "TEDI", Zeitstempel 05-Oct-2007 10:44:51.0 UTC+02:00. (Die 11 ist ein VT, das scheint die Desc geschlabbert zu haben. 7*256+215 = 2007.)

Gut erkannt. War mein Fehler. Hab ich nicht mit abgeschrieben. Die 11 ist tatsächlich beschrieben als "Length of Date and Time".


Zitat


Sowohl Strings beschränkter Länge als auch Zeitstempel wie in Deinem Zitat definiert sind endliche Zustandsräume, also auf endliche Bytefolgen abbildbar ...

OK. Daraus verstehe ich, dass die gelieferten OIDs tatsächlich korrekt sind. Wie bekomme ich das meinem System beigebogen? Diese ganzen Beschreibungen der "flexiblen Erweiterungen" sind NICHT in der MIB beschrieben, sondern innerhalb der System-Doku "HowTo - Understanding the Trap". Ich hab das erste Mal Kontakt mit dieser Art von Alarmierung. Kann ich die MIB ergänzen, so dass die Erweiterungen ausgewertet werden? Ein Link zu 'nem guten Beispiel wäre super.


bern

Profi

Beiträge: 1 355

Anzahl Nagios-Server: 2-5

Nagios-Version(en): 1-3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 80-200

Anzahl Services: 1400-2000

Betriebssystem(e): Linux

Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)

Sonstige Addon's: n2rrd, PNP, livestatus

6

22.04.2011, 18:38

Zitat von »KevJon«

Daraus verstehe ich, dass die gelieferten OIDs tatsächlich korrekt sind. Wie bekomme ich das meinem System beigebogen?
Dir ist schon klar, daß Du bis jetzt mit keinem Wort verraten hast, was für ein "System" Du überhaupt auf der Trap-Empfänger-Seite hast? 'Mal abgesehen davon, daß Du im Unterforum Betriebssysteme/Linux postest ... :whistling:

Die ADVA-Gschicht steht in den MIBs drin, wie gesagt als INDEX, und ich erinnere mich, daß die Net-SNMP Tools das durchaus hinbekommen haben - maW ich habe bei einem snmpwalk/snmpget tatsächlich Ausgaben bekommen so ähnlich wie

covEsa::esaProbeMaxRoundTrip."TestName" = INTEGER: 4711

(Varbinds in einem) Trap(s) sind zugegebenermaßen eine andere Sache, und OID-Konstrukte, die nicht formell korrekt in der MIB definiert sind, auch. In einem Konstrukt aus snmptrapd und snmptt würde ich 'mal schätzen, daß snmptrapd OIDs in Varbinds immer noch numerisch an snmptt gibt und dessen Config-File-Syntax dürfte dann wohl Probleme haben, damit mehr Auswertung zu treiben als per Regexp Match einzelne Modules zu identifizieren ...

KevJon

Anfänger

Beiträge: 4

Anzahl Nagios-Server: 1

Nagios-Version(en): 1

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 641

Anzahl Services: 35

Betriebssystem(e): 5

Plugin-Version(en): 1

NDO-Version: 1

7

26.04.2011, 09:46

Zitat

Dir ist schon klar, daß Du bis jetzt mit keinem Wort verraten hast, was für ein "System" Du überhaupt auf der Trap-Empfänger-Seite hast?
War der Meinung, dass es für den Fall nicht wirklich relevant ist. Es handelt sich um ein OpenMaster Version 7.0.

Zitat

Die ADVA-Gschicht steht in den MIBs drin, wie gesagt als INDEX, und ich erinnere mich, daß die Net-SNMP Tools das durchaus hinbekommen haben
Ich hab nach der angesprochenen MIB gesucht, aber nix (jedenfalls nicht die MIB selbst) gefunden. Dass die Net-SNMP Tools da flexibler sind ist gut, aber ich hab auf meiner Kiste leider keine drauf. Somit hilft mir das im Moment nicht weiter mein Problem zu lösen.

Zitat

(Varbinds in einem) Trap(s) sind zugegebenermaßen eine andere Sache, und OID-Konstrukte, die nicht formell korrekt in der MIB definiert sind, auch.
Genau, drum kann das OpenMaster System die Trap OIDs nicht auswerten.
Der OMC Hersteller sagt dazu folgendes:

Zitat

Das OMC kennt dieses spezielle API nicht.
Vom OMC werden die Trap-Attribute im gelieferten "erweiterten" Format zwar akzeptiert, allerdings nicht aufgelöst. Das führt dazu, dass die eintreffenden Events im Eventlog vollständig angezeigt werden, allerdings werden keine Namen für die Attribute angezeigt, sondern nur die "erweiterten" OIDs. Das OMC kann nur die OIDs auflösen, die auch in einer MIB spezifiziert sind - so wie es im Standard definiert ist.
Bei der weiteren Qualifizierung im OMC werden die nicht auflösbaren Attribute entfernt, so dass diese im Alarmlog nicht mehr angezeigt werden.

Zitat der Mail vom ........... (die mit dem PDF Anhang), dass die -ALARM-MIB.mib auf RFC3877 basiert. Aus dem zitierten RFC ist die von verwendete OID-Bildungsregel nicht ableitbar. Im Gegenteil, dort steht im Abschnitt 3.6 "the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined". Darus folgt, dass
sich NICHT standardkonform verhält. Wir lassen uns gerne eines Besseren belehren, aber dazu sollte mindestens angeben, aus welchem RFC die Bildungsregel abgeleitet ist. Ansonsten ist es weiterhin ein Fehler von .
So haben beide Seiten ihre Meinung korrekt zu arbeiten. Und der OMC-Admin muss nach einer Lösung suchen. Entweder einem von beiden beweisen, dass ein Fehler vorliegt oder eine Lösung in einer OMC bekannten Programmiersprache zu entwickeln. Am liebsten wäre mir 'ne MIB Definition. Nur ohne konkretes Beispiel komme ich nicht weiter. Ne Idee?

bern

Profi

Beiträge: 1 355

Anzahl Nagios-Server: 2-5

Nagios-Version(en): 1-3

Verteiltes Monitoring: Nein

Redundantes Monitoring: Nein

Anzahl-Hosts: 80-200

Anzahl Services: 1400-2000

Betriebssystem(e): Linux

Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)

Sonstige Addon's: n2rrd, PNP, livestatus

8

26.04.2011, 13:21

Zitat von »KevJon«

Der OMC Hersteller sagt dazu folgendes:

Zitat

Zitat der Mail vom ........... (die mit dem PDF Anhang), dass die -ALARM-MIB.mib auf RFC3877 basiert. Aus dem zitierten RFC ist die von verwendete OID-Bildungsregel nicht ableitbar. Im Gegenteil, dort steht im Abschnitt 3.6 "the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined".
Also die Antwort ist 'ne Ver...äppelung. Erstens lautet das vollständige Zitat des RFCs:

In SNMPv1 [RFC1157], the varbinds in the Trap-PDU sent over the wire
map one to one into those varbinds listed in the SMI of the trap in
the MIB in which it was defined [RFC1215].


Zweitens geht's in dem Abschnitt um die Frage, welche Varbinds bei der Definition des Traps anzugeben sind, und keineswegs darum, daß die in einem Varbind vorkommenden OIDs in dieser Definition abschließend und vollzählig aufgeführt werden müssen.

Zitat von »KevJon«

Zitat

Darus folgt, dass sich NICHT standardkonform verhält. Wir lassen uns gerne eines Besseren belehren, aber dazu sollte mindestens angeben, aus welchem RFC die Bildungsregel abgeleitet ist. Ansonsten ist es weiterhin ein Fehler von .
So haben beide Seiten ihre Meinung korrekt zu arbeiten. Und der OMC-Admin muss nach einer Lösung suchen. Entweder einem von beiden beweisen, dass ein Fehler vorliegt oder eine Lösung in einer OMC bekannten Programmiersprache zu entwickeln. Am liebsten wäre mir 'ne MIB Definition. Nur ohne konkretes Beispiel komme ich nicht weiter. Ne Idee?
Jo, das kenn' ich ... die Entwickler bei ADVA haben auch 'mal geglaubt, sie seien im Recht, wenn sie ein Interface als operationally down deklarieren, wenn die vom anderen Ende angebotenen AutoNeg-Optionen ihrer Ansicht nach nicht standardkonform waren. Ergebnis: Interfaces, die "down" sind und über die trotzdem full wirespeed Traffic läuft. :wacko:Hat IIRC zwei Jahre und jede Menge von Markt zuschanden gewatschte Sales-Leute gebraucht, um das zu korrigieren.

Aber zurück zum Thema. Eine direkte Unterstützung für die dargestellte Bauart von OIDs sehe ich dem RFC beim Querlesen auch nicht, wohl aber ausgiebige Darstellung von Varbinds, die lediglich ein Verweis auf Alarm Tables des Trap-Senders sein müssen. Ohne mich zum SNMP-Papst aufzuspielen, würde ich daraus schließen, daß
  • der Trap-Sender in Varbinds durchaus OIDs schicken darf, die es in exakt dieser Form vor dem Alarm noch gar nicht gab und die man per snmpget o.ä. abfragen müßte/soll, um weitere Informationen zum Alarm zu bekommen, und
  • der Trap-Empfänger durchaus das Recht hat, auf solche zusätzlichen Abfragen zu verzichten und auch die Tatsache zu ignorieren, daß solche OIDs auf irgendeine "sprechende" Art gebaut sind (speziell wenn sich diese gar nicht vollständig in ASN.1 Syntax darstellen läßt).
Wobei letzteres immer noch etwas anderes ist als daß ein Monitoring-System hingeht und "unverständliche" OIDs/Varbinds glatt wegschmeißt.

Wenn OMC darauf besteht, daß sie sozusagen "eindeutige und unveränderliche" OIDs für die Varbinds vergekaut kriegen müssen, hast Du mit den realiter eingebauten Timestamps wohl gelitten. Dann wäre ein selbstgebautes Konverter-Plugin - wenn ich Deinen Hinweis auf die "OMC bekannte Programmiersprache" da richtig verstehe? - wohl der gangbarste Weg ...

Ähnliche Themen