Nachdem ich schon die Grundzüge erklärt habe, wie man ein Agent basierendes check_mk Plugin entwickelt (siehe hier) folgt nun ein kleines Update mit der Frage vorweg: Wie entwickelt man einen SNMP basierenden check?
Nun, die gute Nachricht ist, dass ich nicht viel schreiben muss. Es funktioniert genau so wie in meiner ersten Anleitung, Teil 2 und Teil 3. Lediglich Teil 1 muss ich hier neu schreiben, denn die Daten kommen nun natürlich nicht von einem Agent, sondern vom einem SNMP Walk. Also spare ich mir sogar einige Arbeit und muss nur noch angeben was ich denn aus dem Tree haben möchte.
Und das funktioniert über snmp_info
snmp_info['check_name'] = ( #Die Basis OID ".1.3.6.1.4.1.2606.1.2.3", #Die unteren Zweige ["1","3","6"], #ggf. noch mal eine Ebene tiefer: ["1.1","3.2"] )
Aber nun mal langsam was hier passiert: Die Basis OID, die ich angebe, ist der Hauptzweig unter dem alle meine OIDs zu finden sind, die ich brauche. Die unteren Zweige sind die Daten, bei denen ausgehend vom Hauptzweig ein SNMP Walk gemacht wird. Lassen wir mal die noch tiefere Ebene weg, würden folgende OIDs in unserem Beispiel gezogen:
.1.3.6.1.4.1.2606.1.2.3.1 .1.3.6.1.4.1.2606.1.2.3.3 .1.3.6.1.4.1.2606.1.2.3.6
Nehme ich nun noch die tiefere Ebene hinzu, wird jeweils gezogen:
.1.3.6.1.4.1.2606.1.2.3.1.1.1 .1.3.6.1.4.1.2606.1.2.3.1.3.2 .1.3.6.1.4.1.2606.1.2.3.3.1.1 .1.3.6.1.4.1.2606.1.2.3.3.3.2 .1.3.6.1.4.1.2606.1.2.3.6.1.1 .1.3.6.1.4.1.2606.1.2.3.6.3.2
Sprich, es wird verschachtelt.
Und nun gehts einfach weiter. In der info Variable, welche meine Inventur und meine Check-Funktion bekommt, bekomme ich nun eine Liste geliefert, in der alle Werte zu finden sind, welche unter den OIDs gefunden wurden. Geht also weiter wie in Teil 2 und Teil 3 beschrieben. Eben nur mit anderen Daten.
Viel Spass damit… aber nein, da war noch was.
Eine automatische Inventur wäre noch eine schöne Sache. Dazu benötige ich nur eine kleine Funktion, lässt sich meist als lambda Funktion regeln, die ich in snmp_scan_functions[“checkname”] registriere. Dieser wird einfach nur das Objekt oid übergeben und sie muss True oder False zurückliefern. Mit dem Objekt oid kann man nun nämlich eine OID abfragen (wer hätte es für möglich gehalten) und mit der Ausgabe alle möglichen Vergleiche anstellen. Ein Beispiel:
snmp_scan_functions["checkname"] = \ lambda oid: "Test" in oid('1.3.6.1.2606.1.2.3.4.5')
Steht nun in der OID ‘1.3.6.1.2606.1.2.3.4.5 das Wort Test , wird automatisch die Inventurfunktion aufgerufen.
Ohne die scan_function müsste ich bei der Inventur explizit den Checknamen mitgeben, damit der check erkannt wird. Dies geht übrigens mit check_mk –checks checkname -I rechnername .
Das soweit zu SNMP Checks. Jetzt aber wirklich viel Spass! :)
Super coole Anleitung !
Frage,
wenn ich Infos aus 2 unterschiedlichen OID’s verwenden will.
Also wie in deinem Beispiel einmal :
.1.3.6.1.4 aber einmal 1.3.4.1
Muss ich dann als Basis einfach den gemeinsamen Nenner nehmen also .1.3 und dann jeweils die SubID definieren ?
Hi, kannst du mir erklären wo du diesen check überhaupt ablegst ?
Hi Christian,
kommt innerhalb der Site (su – sitename) nach local/share/check_mk/checks.