Probleme seit dem Update auf 2.1

Moin,

Wir haben hier seit dem Update auf 2.1 einige Probleme im Zusammenhang mit SNMP. Seitdem bekommen wir bei etlichen, immer wieder unterschiedlichen, unserer Switches die Meldung “[snmp] Success, Got no information from host”. Damit verbunden ist die Anzahl der Services im Zustand “Stale” um ein vielfaches im Vergleich zu Version 2.0 angestiegen. Das Troubleshooting nach den in der Dokumentation angegebenen Tipps brachte bisher keine Ergebnisse, die Switches antworten bei Tests einwandfrei. Hat hier jemand bereits ähnliches beobachtet und/oder irgendwelche Lösungsvorschläge? Wir monitoren übrigens rund 3000 Hosts mit derzeit etwa 70000 Services auf einem einzelnen Server. Mit Version 2.0 war das überhaupt kein Problem…

Gruß

Rainer

Hat sich erledigt…beide Fehler konnten behoben werden. Ich habe zuerst sämtliche Änderungen an den Performance-Einstellungen und SNMP-Konfigurationen auf Standardwerte zurückgesetzt, und anschließend nur die Anzahl Fetcher signifikant erhöht → Läuft! :slightly_smiling_face:

1 Like

Selbes Problem hier. Ich habe mal die Anzahl der Fetcher erhöht und schaue, ob es sich nun bessert

Wir haben dasselbe Problem. Jedoch hat es sich mit dem erhöhen der Fetcher nicht gelöst. Im Gegenteil: CheckMK Analyzer hat sogar empfohlen die Fetcher Anzahl wieder zu minimieren.

Gibt es weitere Möglichkeiten/Ideen dieses Problem zu beheben?

Bei mir das selbe: Erhöhte Fetcheranzahl führt zu höherer Frequenz in den “recent events” ← leider keine Heilung

Schade…bei uns ist seit dieser Maßnahme Ruhe. Ich hatte die Anzahl der Fetcher verfünffacht, seitdem laufen Fetcher und Checker mit etwa 50-60% Last problemlos vor sich hin, und die Konfig-Analyse von CMK ist auch zufrieden. Wenn das bei euch nichts gebracht hat, scheint es wohl durch mehrere unterschiedliche Faktoren beeinflusst zu werden. Ich nehme mal an, dass ihr das ganze SNMP-Troubleshooting auch schon durchprobiert habt?
Wir haben hier vorwiegend HP-Switches im Netz, dazu mehrere Cisco-Router. CMK als einzelner Debian-Server mit 8 Cores und 32GB RAM

Ich habe nun Versucht das Problem bei uns zu debuggen. Bir ist dabei aufgefallen das bei uns die Abfragen nur jedes zweite mal gemacht werden, da sonnst der cache in der letzen Sekunde seiner gültig verwendet wird. Ich habe dann in dieser Zeile das > durch >= ersetzt. Seither scheint das Problem behoben zu sein.

ich denke das ist eher ein Workaround. Das problem ist wohl eher das wenn der Cache noch gültig ist zwar die Daten nicht neu abgefragt werde, aber auch nicht der cache verwendet wird. Im cache unter tmp/check_mk/data_source_cache/snmp/checking/ hat der Inhalt dann jeweils zwischen dem eigentlichen inhalt und “{}” hin und her gewechselt. Sehr wahrscheinlich weil der Fetcher nur die neu geholten Daten zurück gibt und nicht die schon gecachten und das dann in den cache geschrieben wird. Ich weiss aber nicht was da genau das Konzept sein soll wer was holt und wer es mit dem gültigen cache verbinden soll.

Hmmm. Der Codeteil wurde aber offenbar für 2.1 gar nicht angefasst.
Hier der gleich Codeblock aus 2.0.0p25 (auch mit einem “>”)…

       fetched_data: MutableMapping[SectionName, SNMPSectionContent] = {}
        for section_name in self._sort_section_names(section_names):
            try:
                _from, until, _section = persisted_sections[section_name]
                if now > until:
                    raise LookupError(section_name)
            except LookupError:
                self._logger.debug("%s: Fetching data (%s)", section_name, walk_cache_msg)

Das > muss nicht falsch sein, kommt halt immer drauf an was genau geprüft wird, ob das until inklusive oder exklusiv sein soll. Ich würde aber erwarten wenn ich etwas für eine Minute cache und jede Minute Abfrage es auch jede Minute abgefragt wird und nicht nur alle zwei.

Das eigentliche Problem ist das bei einem cache hit der cache danach leer ist. Diese Logik kann aber gut ausserhalb dieser Klasse liegen. Es kann Sinn machen das der Fetcher sich nicht um das Cachen kümmer sondern nur um das Fetchen von dem was im cache fehlt. Oder 2.1 wurde Performanter und hat nun nicht mehr immer einen kleinen delay und es hat darum erst Auswirkungen.

Tatsächlich hab ich auf 2.0p25 bei einem Host sogar das gleiche Problem, dass mir bisher nur noch nicht aufgefallen ist…

Ich frag mich ob das mit eher speziellen SNMP Konfigurationen (Intervall,Tiemouts…) zu tun hat und das Caching in in der 2.1 nur stärker zum tragen kommt.

Das >= hilft leider bei mir nicht. Ich denke auch, dass da irgend ein Caching nicht ordentlich funktioniert