Stale Service since 15h - FUP

[kernal (Kai Nothdurft)]

CMK version: check-mk-raw:2.0.0-latest
OS version: VMware Photon OS / Docker (Debian GNU/Linux 10 (buster))

Error message: keine

Output of “cmk --debug -vvn hostname”: Exchange IS Store _total Average latency: 0.00 ms

Hallo zusammen,

es gab das Thema schonmal unter Stale Service since 15h .

Es wurde leider ergebnislos geschlossen. Ich habe genau dasselbe Phänomen. Zwei Exchange-Host. Nur alle zig Stunden gibt es ein Update von dem Check. Alle anderen Checks sind aktuell. In Edit Service sieht es auch immer gut und aktuell aus. Ich habe testweise den Dienst deaktiviert, die Änderungen aktiviert, den Dienst reaktiviert und die Änderungen erneut aktiviert. Seitdem (ca. 2 Stunden) steht der Dienst im Status PENDing.

Wenn ich mit netcat von Port 6556 die Daten vom Exchange-Server ziehe, bekomme ich aktuelle Daten für den Server:

<<<msexch_isclienttype:sep(124)>>>
AdministrativeRPCrequestsPersec|AdminRPCRequests|Caption|Description|DirectoryAccessLDAPSearchesPersec|Frequency_Object|Frequency_PerfTime|Frequency_Sys100NS|JetDatabaseReadsPersec|JetLogRecordBytesPersec|JetLogRecordsPersec|JetLVPageCacheMissesPersec|JetLVPageCacheMissLatencyusPersec|JetLVReadsPersec|JetMetaCacheDatabaseHitRatio|JetMetaCacheDatabaseHitRatio_Base|JetMetaCacheDatabaseMissesPersec|JetMetaCacheDatabaseRequestsPersec|JetPageCacheMissesPersec|JetPageCacheMissLatencyusPersec|JetPageCacheUniqueHitRatio|JetPageCacheUniqueHitRatio_Base|JetPageCacheUniqueHitsPersec|JetPageCacheUniqueRequestsPersec|JetPagesModifiedPersec|JetPagesPrereadPersec|JetPagesReadPersec|JetPagesReferencedPersec|JetPagesRemodifiedPersec|LazyindexescreatedPersec|LazyindexesdeletedPersec|LazyindexfullrefreshPersec|LazyindexincrementalrefreshPersec|MessagescreatedPersec|MessagesdeletedPersec|MessagesopenedPersec|MessagesupdatedPersec|Name|PropertypromotionsPersec|RPCAverageLatency|RPCAverageLatency_Base|RPCBytesReceivedPersec|RPCBytesSentPersec|RPCOperationsPersec|RPCPacketsPersec|RPCRequests|Timestamp_Object|Timestamp_PerfTime|Timestamp_Sys100NS|WMIStatus
[…]
124206|0|||771|0|2533111|10000000|19|0|0|7|37466|304|0|0|0|0|17|104692|675394|675423|675394|675423|0|20|9|699504|0|0|0|0|0|0|0|42|0|_total|0|5717|3134|6958|16694834|4123|3134|2147524453|0|12444024531755|133185170454720000|OK

Demnach liefert WMI, als auch der Checkmk-Agent offenbar aktuelle Werte und der Checkmk-Server erkennt die (meistens) nicht.

Hat jemand eine Idee?

Danke und VG
Kai

[gstolz (Gerd Stolz)]

Hi Kai, hab noch keine Lösung, nur auch gerade ne Umgebung wo das passiert. Evtl. komme ich heute zur genaueren Analyse. Somit zumindest ein “Du bist nicht allein”

Gerd

[rprengel (Ralf Prengel)]

Hallo,
ggf. ein Problem dank der reichlichen Patches für Exchange in letzter Zeit?
Gruß

[gstolz (Gerd Stolz)]

also mein aktueller Stand:

Der Check gegen “Exchange IS Client Type _total” funktioniert nicht, weil er auf einem Counter basiert, der entgegen aller Doku mal steigt und mal sinkt.

D.h. Checkmk versucht normal zwischen Messpunkt Alt und Messpunkt Neu den Unterschied zu berechnen und diesen dann auf RPC Requests / Sekunde herunterzurechnen, das geht aber nicht, wenn der Counter sinkt, denn wenn der neue Counter niedriger als der alte ist, dann weist dies normalerweise immer auf einen Counter Overflow hin und die Berechnung muss resettet werden.

Wenn der Counter nun weiter sinkt geht das gleiche von vorne los.

Wenn der counter immer sinken würde, könnte man drum rum rechnen, tut er aber leider nicht, manchmal steigt er auch.

Habe den Fall auch in alten internen Diskussionen gefunden, das betrifft wohl mehrere Kunden mit verschiedenen Exchange Versionen

Microsofts Exmon Tool kommt irgendwie damit klar (closed source Magie?)

Tatsächlich war bisher jedoch keinem Kunden dieser Wert “Exchange IS Client Type _total” wichtig genug um das Problem beim Microsoft-Support durchzudiskutieren, daher war die Lösung bisher wohl “Der Wert ist nicht so wichtig, wir ignorieren ihn im Monitoring”

[kernal (Kai Nothdurft)]

Hallo Gerd,

vielen Dank für die Rückmeldung mit der ausführlichen und leicht verständlichen Erklärung. Ohne genaues Wissen der Interna (closed source magie) läßt sich dann von Monitoring-Seite wohl nichts machen. Dann werde ich den Wert wohl auch ignorieren, weiss aber wenigstens warum und habe kein schlechtes Gefühl dabei.

Ich habe deine Antwort als “Lösung” markiert.

VG
Kai