Stale Service since 15h

Hallo zusammen,

ich habe das Problem, dass ein Service " [Exchange IS Client Type _total]" seit 15 Stunden “stale” ist und ich nicht weiß warum und wie ich das Problem beheben kann. Die Graphen etc sind nur sporadisch mit Werten gefüllt.

Auf einem anderen Server funktioniert der Service ordnungsgemäß. Ich bin also etwas ratlos.

Im Anhang befinden sich zwei Screenshots, die hoffentlich bei der Problembehebung helfen.

Vielen Dank schon einmal!

Viele Grüße
Peer

Da es sich hier um den Check eines Windows Performance Counters handelt kann ich nur vermuten, dass dieser keine Werte oder besser gesagt keine Wertänderung enthält seit 15 Stunden.
Es handelt sich hier ja um einen Exchange Server. Ist dieser ein Frontend, Backend oder Standalone Server?

Hallo,

danke für deine Antwort.

Es ist ein Exchange 2016 in einer DAG aus zwei Servern.

CheckMK scheint nach 16 oder mehr Stunden die Daten zu erneuern, da heute wieder die Benachrichtung ist: Letzter Check vor 14 Stunden.

Auf einem anderen Exchange Server läuft der Dienst tadellos und man kann die Graphen dort auch gut benutzen.

Warum das jetzt auf dem anderen Exchange nicht der Fall ist, kann ich mir nicht erklären.

Viele Grüße
Peer

Naja wenn es eine DAG ist und zur Zeit alle Client Connects auf dem zweiten Host landen dann ist das schon “normal”, dass der Counter auf diesem Host nie was ausgibt oder nur ganz selten.

Hallo Andreas,

der Administrator sagte mir, dass der Fehler beim Backup auftritt und später dann alarmiert wird:

2366.68 RPC Requests (warn/crit at 60/70)

Das Problem ist dann schon 39 Tage alt und zuletzt gecheckt vor 14 / 15 Stunden. Also er scheint einmal am Tag zu checken.

Die Server teilen sich die Zugriffe wohl untereinander auf.

Danke für deine Hilfe!

VG
peer

Ok der eine Server beantwortet nur Anfragen wenn der andere grad Backup macht - scheint jedenfalls so.
Ich würde erstmal die Warn/Crit Werte auf den gleichen Wert setzen wie auf dem zweiten DAG Member.

Hallo Andreas,

ja genau, aber die Schwellwerte sind die selben.

Das Problem ist, dass wenn das Backup läuft merkt sich CheckMK die hohe Anzahl an Requests und geht auf CRIT, anschließend fragt es merkwürdigerweise erst nach 15 / 16 Stunden erneut ab. Das merkwürdige ist, dass alle anderen Dienste alle 30 Sekunden neu abgefragt werden, nur der Exchange IS Client Type _total nicht.
grafik

Der Check ist auf beiden Servern der Selbe, aber er funktioniert nicht auf beiden gleich. Ich komme auch nicht darauf, was es sein könnte. Für mich sieht das identisch aus, nur das CheckMK bei dem einen die Daten nicht abchecken möchte.

Der andere Server wird ganz normal alle 30 Sekunden abgefragt.

VG
Peer

Das ist ein WMI Counter und abgefragt wird er nur wenn er keine Änderung hat dann geht der Check auf Stale. Der Check funktioniert auch auf beiden Systemen gleich. Nur wenn halt ein System keine Counter Änderung meldet dann gibts auch keine aktuellen Check Daten :slight_smile:

1 Like

Vielen Dank noch einmal für deine Hilfe! :slight_smile:

Das Merkwürdige ist einfach, dass ich beim funktionierenden Server auf “Reschedule Check” klicken kann und dann aktuell abgeprüft wird bzw. aktualisiert wird. Mach ich das selbe beim Problemserver, bekomme ich diese Meldung:

CheckMK müsste doch wenigstens sagen Ag: bsp. 15 Stunden, letzter Check vor 2 Sekunden , Status gleich.
Aber es läuft immer in einen Timeout. Die RPC Requests müssten auch jede Minute wechseln. Das ist nämlich auf dem anderen Server auch der Fall. Es ist schlichtweg unmöglich, dass die RPCs über 15 Stunden auf 2300 stehen.

Hast du noch eine Idee?

Beste Grüße,
Peer

Der Counter “_total” scheint in deinen Daten gar nicht vorhanden zu sein. Genaueres würde man hier nur auf der Commandline rausfinden können. Dafür muss dann aber bisl Debug Code in den Check rein.
Ist immer die Frage ob sich der Aufwand lohnt.
Normal sollte der _total Counter eigentlich egal sein :slight_smile:

Hallo Andreas,

ich danke dir sehr für deine Unterstützung.

Der zuständige Admin und ich haben beschlossen, dass wir den Check deaktivieren, da wir keine geeignete Lösung für das Ereignis haben.

Danke schön und viele Grüße
Peer

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