Activate changes dauert sehr lange

Es nervt mich gerade wieder.
Folgender Screenshot zeigt ne absolut harmlose Variante.
So um die 100 Check_mk_Agent Prozesse die bei einem systemctl oder aber bei einem ps hängen sind keine Seltenheit. Es gibt nun einen lokalen check dafür der die Prozesse wegräumt, aber die verlängerte Checkdauer belastet den OMD enorm.
Anbei der Screenshot zum Thema.

Das hat aber mal nix mit dem “Activate Changes” Problem hier aus dem Thread zu tun.

Ich sag mal so der überwachte Server scheint ein ernsthaftes Problem zu haben wenn ein “systemctl” nicht sauber durchläuft.

Lieber Andreas,
vielen Dank für deine Antwort.
Wie im darüber liegenden Post

dargelegt seh ich durchaus ein Bezug.
Auch hast Du falsch verstanden dass es sich nicht um einen Server mit einem ernsthaften Problem beim systemctl und ps handelt, sondern um alle - und zwar exakt und reproduzierbar nach Upgrade des Agents von 1.6 nach 2.0.

Es tritt dies unabhängig von der Umgebung auf (bare metal, aws, hetzner cloud, proxmox).

Gemeinsamkeit ist der unveränderte Aufruf via ssh wie oben dargestellt.

Was macht denn der Aufruf von systemctl --all --no-pager auf den betroffenen Systemen, unabhängig vom Agenten? Da scheint es ja zu hängen.

Guten Morgen und vielen Dank.
Er läuft in interaktiven shells oder via saltstack cmd.run immer durch, ohne zu hängen.
Der ps auch - er stellt die 2-te Stelle dar an welcher es gern blockiert.

Der Agent 1.6x besitzt die entsprechenden Aufrufe nicht so dass er gar nicht hängen kann.

Welche Version hat der Agent? Evtl hilft ein Update der checkmk-Version.

Wenn Ihr da Regular Expressions benutzt könnte das schon eine Auswirkung haben wenn die RegExen unsauber formuliert sind. Gerade wenn z.B. so etwas wie backtracking eingesetz wird kann dass das System stark belasten.

Gruß

Michael

check-mk-agent_2.0.0p8-1_all.deb
haben das aber brav seit der p-5 erfolglos geupdatet und sind dann bei der geblieben.

Hallo,

wir haben jetzt herausgefunden warum die Aktivierung so lange dauert. Wir haben einige SQL Cluster bei denen sehr viele Services disabled sind ( via Rule – disabled services). Hier wird leider kein regex verwendet, daher sind mehrere 100 Services in den Service Feldern eingetragen.
Gibt es eine Möglichkeit schon auf der Clientseite (beim Agent) die unerwünschten Services zu deaktivieren?

thx

Hallo @JoJo,

mit SQL-Clustern meinst du MSSQL-Server?

Bei den Oracle-Checks gibt es die Möglichkeit einzelne Bereiche über die Konfiguration im Plugin zu deaktivieren. Da ich selbst keine MSSQL-Server betreue (komisches Betriebssystem :stuck_out_tongue:) kann ich nicht genau sagen, ob das dort auch möglich ist.
Alternativ würde mir einfallen die unbeliebten Sektionen im Plugin auszukommentieren und unter ~site/local/share/... abzulegen, damit es beim automatischen agent update (sofern verwendet) nicht wieder auf den Standard geändert wird. Ist aber nur ein Workaround und nicht ganz so schön.

1 Like

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