Enforced services Prozessanzahl in Clustern

Hallo,

ich habe testweise meine Site kopiert und von Version 1.6.0p24 auf 2.0.0p5 aktualisiert.
Dabei habe ich ein Problem bei Clustern die zwei Nodes haben.
An den Clustern gibt es nur Manual Checks vom Typ State and count of processes.

Ausgabe bei Version 1.6:
clustername
STATE SERVICE ICONS STATUS DETAIL AGE CHECKED PERF-O-METER
OK Check_MK OK - execution time 0.1 sec 2021-05-17 16:10:39 - 23 d 2021-06-09 15:30:38 - 4.32 s
63.0 ms
CRIT Process BlaName CRIT - 0 processes: (ok from 1 to 1)CRIT 2021-06-09 09:29:07 - 6 h 2021-06-09 15:30:38 - 4.33 s
OK Process FaselName OK - 2 processes running on winnode1, winnode2, 784.99 MB virtual, 209.81 MB physical, 0.0% CPU, 1123 process handles, youngest running for: 15 d, oldest running for: 22 d

Bei Version 2.0 kommt die Fehlermeldung „Got no information from host“ beim Check_mk Service. Die Checks sind stale.
CRIT
Check_MK [agent] Version: 1.6.0p24, OS: windows, [piggyback] Valid sources: lxvcenter, winveeamserv, [agent] Version: 1.6.0p24, OS: windows, [piggyback] Valid sources: lxvcenter, winveeamserv, Got no information from host, execution time 9.1 sec

Ich habe schon versucht die Konfiguration zu ändern, sodass ich keine Enforced services mehr habe, also über Discovery rules → Process discovery (aber an den Nodes, nicht dem Cluster) in Kombination mit Service monitoring rules → Clustered services die Informationen an den Nodes sammeln und an den Cluster kleben…

…ABER: dann gilt die Warngrenze nicht mehr auf die Summe der Prozesse aller Nodes im Cluster sondern pro Node. Das Summary ist dann nur noch die Summe der Prozesse über alle Nodes ohne die Detailinformationen auf welcher Node der Prozess läuft.

In meinem Anwendungsfall muss ich aber bei den meisten Prozessen verhindern, dass sie in der Summe mehr als einmal laufen.

Die Frage lautet also: Wurde dieses Feature in der Version 2.0 gestrichen oder handelt es sich um einen Bug?

Vielen Dank schonmal
Wolfgang

Gestrichen wurde da nix meines Wissens nach. Es gibt zur Zeit nur noch ein Problem mit Clustern welches eigentlich nur die Ausführungszeit des Check_MK Checks auf der Clusterressource betrifft.
Aus der Ausgabe bei dir sehe ich, dass das Ausführungsproblem auch bei dir zutrifft.

1.6      Check_MK OK - execution time 0.1 sec
2.0      Check_MK ... execution time 9.1 sec

Der kleine feine Unterschied beträgt hier 9 Sekunden. Wie lange brauchen deine Clusternodes jeweils für Ihre CMK Abfrage? Weil 9 Sekunden ist für nen Zweinode Cluster schon arg lang wenn der Agent ordentlich konfiguriert ist. Sollte maximal so 2-3 Sekunden sein.

Hallo,

von den betroffenen Clustern habe ich ca. 10 Stück. Der im Beispiel ist tatsächlich etwas lahm und braucht bis zu 14 Sekunden.
Die anderen Cluster brauchen ca. 1,3 Sekunden pro Node was am Cluster zu einer execution time von 2,6 Sekunden führt. Und zur gleichen Fehlermeldung Got no information from host
Bei der 1.6 Version ist die execution Time der Agenten natürlich die gleiche. Die Zeit am Cluster allerdings nur ein paar Millisekunden. Bei 2.0 ist es die Summe der Zeiten der Agenten.

Ich habe noch andere Cluster die nur den Zustand von DRBD Cluster darstellen. Mit den Zeiten verhält es sich gleich, aber es funktioniert alles bei 2.0 ohne Fehlermeldung, weshalb ich glaube, dass die Zeiten zwar unschön aber nicht das Problem sind.

Das Problem scheint mit den Enforded services → State an count of processes zusammen zu hängen.

Ja die Zeiten sind nicht direkt das Problem aber die können zum Problem werden (hab Cluster wo jeder Node 45 Sekunden braucht - große Netapp).
Die Enforced Services scheinen sich so zu verhalten wie das Problem bis zur p5 auch mit Special Agents war. Die liefen gar nicht auf Clustern :slight_smile:
Die Münchner Kollegen sind gerade dabei das Cluster Problem noch richtig zu fixen. Ich selbst hab mit Enforced Services noch nix probiert kann ich aber mal machen da ich das Ticket wegen den Cluster Problemen aufgemacht hab und eh heute noch nen Nightly Build testen muss ob da noch Probleme sind mit Clustern. Ich setz mal @mathias.laurin hier mit in “Kopie” das könnte relevant sein für das Ticket.