SNMP Problem - Service Check Timeout (HPE FF 5700-48G )

Hallo zusammen,

ich möchte mich direkt am Anfang dafür entschuldigen, dass ich ggf. Begriffe unsauber verwende oder sie verwechsle. Was die ganze Thematik angeht, bin ich leider noch nicht so bewandert.

Zu meinem Problem:

Ich habe einen Kunden, der einen Switch-Cluster mit dem Modell HPE FF 5700-48G betreibt. Genauere Informationen zu dem Cluster, wie viele Switches etc., liefere ich noch nach.

In check_MK werden von diesem Cluster rund 78 Services überwacht. Das Problem ist, dass diese Meldungen immer mal wieder alle zusammen einen „Timeout“ erleben. Meine Aufgabe ist es nun, genau das Problem zu beheben.

Wir haben uns in etwa folgendes gedacht:

Wir passen das snmpwalk-Skript, welches von check_MK genutzt wird an, so dass lediglich die 78 Services über den snmpwalk abgefragt werden. Hierfür gibt es ja die MIB, bzw. OID, mit der man gezielt einen aktuellen Wert auslesen kann.

Weiter Informationen:

Über die Konsole habe ich einen snmpwalk ausgeführt, die Syntax war folgende:

cmk --snmpwalk IP

Ich hätte erwartet, dass Zeile für Zeile ausgegeben wird. Allerdings tut sich erstmal nichts und nach ca. 950 Sekunden kommt ein Timeout. Ziemlich lang … und das ist wohl auch der Grund warum in check_MK die Services ab und zu ihren Wert nicht erhalten.

Mittels eines MIB-Browsers habe ich ebenfalls ein snmpwalk durchführen können. Dort erhalte ich tatsächlich in Echtzeit jede abgefragte Zeile. Ich glaube es dauert tatsächlich ca. 10 Minuten bis auch dieser seine Arbeit vollendet hat. Ich glaube es waren 36000+ Einträge.

Ich verstehe nicht warum der cmk snmpwalk über die Konsole nicht durchläuft. Eine Datei liegt auch nicht in dem in der Hilfe beschriebenen Pfad.

Führe ich in der Konsole einen snmpwalk mit einer MIB/OID und ohne „cmk“ aus, so erhalte ich den erwarteten Wert zurück:

snmpwalk -v 2c -c public IP .1.3.6.1.2.1.1.1.0

Versuche ich es mit einem vorangestellten „cmk“ funktioniert es nicht, ich erhalte nur einen Fehler und die Beschreibung mit der Syntax kommt zum Vorschein. Ich habe meine Syntax-Versuche mal protokolliert:

Führt zum Timeout:
cmk --snmpwalk IP

Funktioniert:
snmpwalk -v 2c -c public IP .1.3.6.1.2.1.1.1.0

snmpwalk -v 2c -c public IP .1.3.6.1.2.1.1.4.0

snmpwalk -v 2c -c public IP .1.3.6.1.2.1.1.5.0

"Funktioniert" - Ich erhalte lediglich eine Angabe für die Ausführungsdauer:
cmk bulkwalk IP

cmk snmpwalk IP

cmk --oid .1.3.6.1.2.1.1.1.0 snmpwalk IP

Läuft durch aber keine Rückmeldung (| less → leifert auch keinen Mehrwert, dort steht nichts drin):
cmk --oid .1.3.6.1.2.1.1.5.0 --snmpwalk IP

cmk --snmpwalk IP --oid .1.3.6.1.2.1.1.5.0

cmk --snmpwalk --oid .1.3.6.1.2.1.1.1.0 IP

Funktioniert nicht:
cmk --snmpwalk -v 2c -c public IP .1.3.6.1.2.1.1.1.0

cmk --snmpwalk IP .1.3.6.1.2.1.1.1.0

cmk snmpwalk IP .1.3.6.1.2.1.1.1.0

cmk snmpwalk IP --oid .1.3.6.1.2.1.1.1.0

cmk snmpwalk IP oid .1.3.6.1.2.1.1.1.0

cmk oid .1.3.6.1.2.1.1.1.0 snmpwalk IP

Meine Fragen:

  • Warum kommt es beim cmk --snmpwalk über die Konsole zu einem Timeout und ist die Syntax korrekt: cmk --snmpwalk IP

  • Warum bekomme ich kein cmk --snmpwalk mit einer MIB/OID hin? Wie lautet die korrekte Syntax?

  • Ist es möglich das snmpwalk-Skript zu kopieren, anzupassen und in check_MK dem Host mitzuteilen, dass das abgeänderte Skript genutzt werden soll?

  • Hat jemand sonst eine Idee, warum es zum Timeout kommt? Der MIB-Browser braucht aber wie gesagt auch gefühlt knapp 10 Minuten, bis er alle Einträge beisammen hat.

  • Weiß jemand zufällig wie ich zu den in check_MK aufgeführten Services die MIB bzw. OID herausfinden kann?

Über Hilfe würde ich mich sehr freuen, da ich in dem Thema wirklich etwas verloren bin und mit meinem Wissen und den Ideen am Ende bin.

Das alles brauchst für die Fehlersuche und Problem Behebung eigentlich nicht.

Wichtig um das Timing abschätzen zu können wäre die Ausführungzeit eines

snmpbulkwalk -v2c -c public <IP des Switches> .1.3.6.1.2.1.2.2
Dies ist der komplette Interface Table und wird normal von CMK abgeholt.

Es gibt im CMK keine Scripte die dies machen und angepasst werden können.
In der Enterprise Edition gibt es das Feature aus einem kompletten Table sich bestimmte Bereiche zu holen. Das wäre hilfreich wenn nur die ersten 50 oder 100 Einträge des Tables abgeholt werden sollen. Aber halt Enterprise Only.

Die für die einzelnen Checks abgeholten OIDs stehen alle im den Checks selbst drin “~/share/check_mk/checks” innerhalb der Info Sektion.

Abschließend glaube ich nicht, dass du bei einem Stack aus low Budget Switchen im Monitoring glücklich wirst. Als einzelne Switche sind die bestimmt ok so im Edge Bereich aber nicht als Stack oder Virtual Switch. Wichtig wäre die Ausführungszeit von oben dem SNMPbulkwalk Command. Damit kann man sagen ob du eine Chance hast oder nicht :wink:

1 Like

Die Ausführungszeit liegt bei genau 140 Sekunden. Er läuft auch durch ohne irgendwo richtig “hängen zu bleiben”.

Das ist lang. Wie viele Switche sind das in dem Stack?

Insgesamt sind es 9.

Ich habe dann auch mal die Bulk-Size angepasst von 5 - 60 (Standard war 10). Leider konnte ich aber keine Änderungen in den Laufzeiten spüren. Eine Bulk-Size von 5-8 hat eher zur Verschlechterung beigetragen.
Auch das anpassen der Response Timeout-Werte von 1 - 8 Sekunden in Kombination mit verschiedenen Bulk-Sizes hat zu keiner Verbesserung geführt. Zuvor habe ich noch das Inline-SNMP deaktiviert. snmpbulkwalk -v2c -c public IP .1.3.6.1.2.1.2.2 lieferte wieder eine Laufzeit um die 2 Minuten.

Gefühlt werden wirklich viele Services abgefragt und ab und zu bleibt er vielleicht mal 1-2 Sekunden irgendwo stehen, rattert danach aber munter weiter. Längere Standzeiten/Abfragezeiten sind für mich nicht zu erkennen…

10 ist schon ok in der Bulksize. Es ist selten, dass ein höherer Wert was bringt.

Damit wirst du diesen Stack nie sauber mit einem Interface Monitoring versehen können. Wie ich schon gesagt hab low Budget Switche und daraus große Stacks bauen ist keine gute Idee. Das kannst halt nicht beeinflussen wenn für das Monitoring verantwortlich :wink:
In der Enterprise Edition könnte man etwas mit den Einstellungen spielen um nur bestimmte Bereiche abfragen zu können das geht aber nicht in der RAW Edition.

Für die Bereichsauswahl würde ich mir den SNMP Walk holen welcher bei dir da 140 Sekunden gedauert hat und nur die Interfaces raussuchen welche für Uplink verantwortlich sind und diese dann überwachen.

In der RAW Edition bleibt dir nur generellen Check Timeout auf mindestens 180 Sekunden zu setzen und dann den Checkinterval für diesen Host auch auf mindestens 3 Minuten zu legen oder auch länger.

2 Likes

An dieser Stelle erstmal vielen lieben Dank Andreas!
Ich weiß deine Hilfe wirklich zu schätzen und mich freut es immer, wenn es noch Leute gibt, die sich aktiv beteiligen und versuchen zu helfen!

Tatsächlich ist dort die Enterprise Edition vorhanden und das “Heraussuchen und Begrenzen” der notwendigen Interfaces war anfangs ja auch unsere Idee. Leider kenne ich mich in check_MK nicht so gut aus und auch Google konnte mir diesbezüglich nicht viel weiterhelfen.

Wäre es evtl. möglich zu erklären wie und wo man die Einstellungen vornehmen kann?

Wenn ich mir das Cluster unter “Hosts ->All Hosts” ansehe, dann sehe ich eine Tabelle mit den Services, die meine Kollegen zur Überwachung eingerichtet haben.

Dort gibt es ja die Spalten “STATE | SERVICE | ICONS | STATUS DETAIL | AGE CHECKED | PERF-O-METER”.

Kann ich mir die Namen/Bezeichnungen aus der Spalte “SERVICE”, z.B. “CPU utilization Module 1” kopieren und dann folgendes tun:

WATO - CONFIGURATION

  • Host & Service Parameters → Monitoring Configuration → Enable/disable active checks for services
  • Host & Service Parameters → Monitoring Configuration → Enable/disable passive checks for services

In beiden Optionen einfach eine Regel für den “Host” erstellen und die rund 70 überwachten Services, die ich zuvor aus der “Hosts-Übersicht” (z.B. CPU utilization Module 1) kopiert habe, eintragen. Zudem den Negate-Haken setzten, damit alle anderen Services für diesen Host deaktiviert werden.

Ich bin mir nur unschlüssig ob ich so den richtigen Service-Namen erwische und ob ich das in die active oder passive checks eintragen muss, oder einfach in beide.

image

hier kannst du die Services eintragen und auch mit regex arbeiten z.B.

1 Like

Danke ich werde es demnächst ausprobieren.
Mich würde aber auch interessieren, ob @andreas-doehler das mit den bestimmten Bereichen meint.

Das was @BH2005 geschrieben hat ist richtig/wichtig für Services welche gar nicht überwacht werden sollen. Ich meine mit den Bereichen ganz besonders die Interface Checks. Die Herausforderung bei so einem Stack ist die große Anzahl an physischen und virtuellen Interfaces. Deshalb dauert auch der komplette Walk hier so lange.
Einige Checks wie der Interface Check bieten die Möglichkeit die Abfragen zu begrenzen um nicht den kompletten Table zu pullen.

Hier ist die Regel mit welcher der Interface Table eingegrenzt werden kann.


Mit dieser Einstellung würden nur die ersten 10 Interfaces abgefragt was natürlich sinnlos ist bei einem großen Stack. Ist ja nur das Beispiel.
image
Das wären als Beispiel zwei 24er Switche wo ich jeweils nur die letzten 4 Interfaces mir abhole.

1 Like

Vielen Dank!

Mein einziges Problem ist gerade, dass ich nicht weiß an welcher Stelle die OIDs für die Services stehen, die ich abfragen möchte. Es gibt zwar die MIB-Datei aber dort werden unzählige Sachen aufgeführt und welche Position es dann tatsächlich ist, bzw. ob es den abgefragten Services zugeordnet werden kann, kann ich nicht sagen.

Ich denke das ist wirklich der letzte Schritt - hat da jemand eine Idee, wie ich leicht an die OIDs komme? Unter den Eigenschaften der Services bin ich nicht fündig geworden.

https://www.thomas-krenn.com/de/wiki/SNMP_Informationen_per_MIB_Browser_auslesen

schau mal hier … Gruß Bernd

1 Like

Es geht bei deinem Problem nur um den Interface Table und dort musst du selber schauen an welcher Stelle die für dich relevanten Interfaces kommen.
Probiere einfach mal aus was bei der Laufzeit passiert wenn für den “if64” Check nur die ersten 10 OIDs ausgewählt werden. Wie lang ist dann die Laufzeit noch?

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.