Nach Update Interface Daten falsch

Wir arbeiten da sehr intesiv daran. Manchmal hilft ein Core restart, oder das löschen der Caches. Wir wissen im Moment leider noch nicht, was das Verhalten triggert.

1 Like

Ich habe auch ab und an dieses Phänomen …
@moritz wenn ich euch mit Daten etc unterstützen kann laß es mich wissen

Ich habe auch das Problem. Keine Änderung von Einstellungen check/timeout/inline-snmp o.ä. haben Einfluss auf das Problem. Nur Änderungen an einem Host (z.B. invertarisieren) bewirkt, dass sofort alle Host wieder Daten der Interface liefern. Diese sind dann stark summiert. Ein Uplink-Port mit durchschnittlich 10 MBit zeigt dann 700 Mbit an, hat nach 10 Minuten 10 MBit und nach einigen Stunden wieder 0. So als wenn die Daten nicht kontinuierlich geschrieben werden.
Alle anderen Daten im Check wie CPU o.ä. sind korrekt.
Interface der Windows/Linux-host mit Checkmk-Agent sind auch korrekt.

1 Like

Das kann ich gerade nach einem Check bestätigen. Dort trat das Problem immer genau 0 Uhr auf und sobald wie gerade eben eine Änderung irgendeiner Art vorgenommen wurde ist das Problem wieder weg.
Konnte das hier mittels der Graphen dreimal 0 Uhr immer festmachen.

Betroffen sind nicht alle Interface Checks. In dem System waren die folgenden vorhanden.

winperf_if - ok
vsphere_counters_if - ok
lnx_if - ok

interfaces - nicht ok
if64 - nicht ok

@andreas-doehler : Ja, das ist ein SNMP Problem. Ihr solltet es auch an der SNMP Uptime sehen können.

Hi,

wenn Interface-Daten immer im Wechsel korrekt und beim nächsten Check wieder 0 sind, kann es daran liegen, dass z.B. 1 Minute Check-Interval eingestellt ist, aber in den Settings für SNMP-Checks 2 Minuten eingestellt ist. Bei den Interface-Metriken handelt es sich um kumulierte Werte, die checkmk immer mit dem vorherigen Wert vergleichen muss, um den aktuellen Durchsatz zu berechnen. Wenn das Check-Intervall kleiner ist, als das SNMP-Intervall, dann wird der letzte Wert im Cache mit sich selbst verglichen, so dass die Änderung immer 0 ist.

Bin nicht sicher, ob das hier auf dieses Fehlerbild passt, aber hatte dieses Thema in 1.6.0p16 mal. Denkbar wäre, dass bei einem Upgrade von 1.6.x auf 2.0.x ggf. Intervalle auf Default-Werte gesetzt werden, so dass die Einstellungen nicht mehr zusammenpassen.

In meinem Fall war es damals eine manuelle Konfiguration, durch die Check-Intervall und SNMP-Intervall nicht mehr zusammengepasst hatten.

Vielleicht geht das Problem ja auch hier in diese Richtung.

Viele Grüße,
Dirk.

Das hat mit dem Fehler hier nix zu tun. Das Verhalten ist halt recht sporadisch. Es läuft erstmal alles normal und ab Zeitpunkt X werden alle Werte nur noch 0. Dann nach aktivieren einer Änderung ist wieder alles schick bis es wieder passiert.

Ah, ja das ist dann eine andere Ursache. Bei den unstimmigen Timeouts ist es reproduzierbar immer abwechselnd, nicht sporadisch.

Ja wie gesagt. Die Einstellungen habe ich vermutlich alle getestet. Durch unterschiedliche Regeln auf unterschiedliche Host oder Interface (Services) sollte ja mal ein Interface anders reagieren.
Die Interface reagieren aber alle gleich.

Ich habe z.B. auch mal (mit den deutschen “genauen” Bezeichnungen), sowas getestet wie…
Abrufintervalle für SNMP-Abschnitte = 4 Minuten
Normales Intervall für Service-Checks = 5 Minuten
Servicecheck Timeout (Microcore) = 3 Minuten

Oder gibt es noch andere Einstellungen, außerhalb der Regeln?

viele Grüße
Mario

Das Problem hier im Thread hat nix mit irgendwelchen Timeout Werten für die Abfrage zu tun. Es ist wie @moritz schon geschrieben ist es ein internes Problem im CMK beim caching oder anderweitigen verarbeiten der SNMP Daten. Das ist wichtig, es tritt nur bei SNMP Checks auf.
Auf dem einen betroffenen System hab ich mir damit beholfen jetzt erstmal, dass ich Nachts halb 1 oder so einfach einen Core Restart per Cron Job mache da bisher die Fehler immer genau 0 Uhr aufgetreten sind bei diesem einen System.

1 Like

Hat jemand die Möglichkeit zu Bestätigen, dass das Problem im Daily Build vom 07.06. nicht mehr auftritt?

Da ich ja das Backup wiederhergestellt habe, habe ich heute unsere 1.6.0p23-Site gecloned und damit das Update auf check-mk-enterprise-2021.06.15_0.focal_amd64.deb gemacht. Bis jetzt ist das Problem nicht mehr aufgetreten.
Ich hoffe halt dass das clonen einer Site nicht das Problem beseitigt und es deswegen nicht mehr auftritt.

Wenn alles klappt kann ich das diese Woche noch probieren.

Also bei mir funktionierts mit dem daily build bis jetzt.

Hallo Moritz,

… arbeiten da sehr intensiv daran…

Kann man in den nächsten Tagen mit der p6 rechnen oder soll ich produktiv auf die " Daily Builds" gehen.

Ich würde auch noch warten, wenn ich die add-on für “ntopng” gegen die nicht funktionierende “snmp-checks” kostenlos eintauschen kann. :wink:

vg
Mario

Hi Mario,
Ich denke mein Kollege hat Deine Frage beantwortet :slight_smile:

Für alle die eventuell (noch) nicht auf die p6 gehen können/wollen:
Das Verhalten wurde ausgelöst, wenn die Autodiscovery changes erkannt und aktiviert hat. Dabei wurde die Config falsch erzeugt.

4 Likes

So die p6 ist bei mir produktiv .
Mal sehen was Montag zusehen ist. Und nochmal schönen Dank für den Hinweis, dass die p6 da ist. Das hatte ich verpennt.

schönes Wochenende an alle.
Mario

Seit 5 Tagen keine Probleme mehr.
Alle SNMP Interfacedaten werden mit der 2.0.0p6 korrekt angezeigt.

vg
Mario

2 Likes

Kann das von Mario bestätigen. Lediglich für kapp einen Tag, aber ich hatte definitiv schon nach ca. 1 Stunde einen Verlust der Anzeige und nun sind Aufzeichnungen durchgängig. p6 hat den Fix dafür gebracht.

VG

Stefan

1 Like