danke Dir. Das ist für mich so erst einmal nicht wirklich akzeptabel.
Wir betreiben hier ein Monitoring für fast 3000 Server mit Check_MK.
Von einem Limit dieser Art konnte ich bislang nichts lesen.
Wir sprechen das mal auf der Konferenz an. Ich hoffe Check_MK hat dafür eine Lösung (wenigstens aber einen Workaround) parat ….
···
Kind regards /
Mit freundlichen Grüßen
i.A. Fischer, Göran
Senior System Engineer
IMSD Network & Operation Center
/ Systems Operation****
TUI InfoTec GmbH
Karl-Wiechert-Allee 4 | 30625 Hannover | Germany
Phone: 0511 567 5339 | Fax: 0511 567 93 5339
mailto:goeran.fischer@tui.com
www.tui-infotec.com/
Geschäftsführung:
Geschäftsführung: Elke Reichart (Vorsitzende), Michael Ohm, Martin Schreck
Sitz der Gesellschaft: Hannover | Handelsregister: Amtsgericht Hannover HRB 60673
Executive board:
Elke Reichart
(Chief Executive), Michael Ohm, Martin Schreck
Company seat: Hannover | Commercial Register: Amtsgericht Hannover HRB 60673
Von: FRANK Michael [mailto:michael.frank@faurecia.com]
Gesendet: Dienstag, 23. April 2019 13:34
An: Fischer, Göran; checkmk-de@lists.mathias-kettner.de
Betreff: RE: Performance Probleme des Notification spoolers
Hi Göran,
Leider gibt es da keine Möglichkeit. Ich habe das bereits mit dem check_mk support durchgespielt.
Die einzige Möglichkeit ist die Regelsätze zu reduzieren.
Gruß
Michael
From: Fischer, Göran goeran.fischer@tui.com
Sent: Dienstag, 23. April 2019 11:54
To: FRANK Michael michael.frank@faurecia.com; checkmk-de@lists.mathias-kettner.de
Subject: AW: Performance Probleme des Notification spoolers
Hallo Michael,
danke Dir für die Info.
Es würde mich aber wundern, wenn es für ein Enterprise Tool nicht noch irgendwelche Schrauben gibt, die man drehen kann.
40 – 50 Alerts / Minute als Limit scheint mir viel zu wenig. Da muss ja nur mal ein größerer Ausfall kommen und man kann mit dem Monitoring nichts mehr anfangen.
Hat noch jemand Ideen? Was ist der Flaschenhals im Notification Spooler und wie kann man ihn aufbohren???
Kind regards /
Mit freundlichen Grüßen
i.A. Fischer, Göran
Senior System Engineer
IMSD Network & Operation Center / Systems Operation****
TUI InfoTec GmbH
Karl-Wiechert-Allee 4 | 30625 Hannover | Germany
Phone: 0511 567 5339 | Fax: 0511 567 93 5339
mailto:goeran.fischer@tui.com
www.tui-infotec.com/
Geschäftsführung: Geschäftsführung: Elke Reichart (Vorsitzende), Michael Ohm, Martin Schreck
Sitz der Gesellschaft: Hannover | Handelsregister: Amtsgericht Hannover HRB 60673
Executive board: Elke Reichart (Chief Executive), Michael Ohm, Martin Schreck
Company seat: Hannover | Commercial Register: Amtsgericht Hannover HRB 60673
Von: FRANK Michael [mailto:michael.frank@faurecia.com]
Gesendet: Donnerstag, 18. April 2019 14:22
An: Fischer, Göran; checkmk-de@lists.mathias-kettner.de
Betreff: RE: Performance Probleme des Notification spoolers
Hallo,
Wir haben ähnliche Probleme. Es liegt wohl daran das mit jedem Alarm die komplette Konfiguration eingelsen werden muss. Das erzeugt bei vielen Alarmen
eine entsprechende Verzögerung.
Das Spooling der Alarme machen wir in den nachgelagerten systemen (smstools & postfix) lokal auf dem slave, daher ist das spooling in check_mk bei
uns obsolete und wir schalten dass gerade global ab.
Gruß
Michael
From: checkmk-de checkmk-de-bounces@lists.mathias-kettner.de
On Behalf Of Fischer, Göran
Sent: Donnerstag, 18. April 2019 14:02
To: checkmk-de@lists.mathias-kettner.de
Subject: [Check_mk (deutsch)] Performance Probleme des Notification spoolers
Hallo,
ich habe ein Problem mit dem Notification Spooler.
Ab und zu kommt es mal vor, dass etwas mehr Alerts als normal generiert werden, und dann kommt der Spooler nicht mit der Aussendung der Alarme an unseren externen Event Handler nach.
Die Anzahl der Files im spool Verzeichnis wächst an und Alarme werden entsprechend mit einer größeren Verzögerung versendet.
Im letzten Fall hat ein Logfile ca 50 Alarme / Minute erzeugt. Das hat dazu geführt, dass ich weit mehr als 500 Dateien im spool Verzeichnis hatte.
In diesem Fall hatte ich eine Verzögerung von mehr als 10 Minuten beim Aufschlagen der Alarme im Eventhandler.
Das Problem hatte ich auch schon ohne Logwatch.
Nun bin ich der Meinung, dass ein Enterprise Monitoring System nicht bei 50 Alarmen / Minute in die Knie gehen sollte.
Die Logs geben keinerlei Fehlermeldungen wieder.
Ist das ein Limit, dass auch von anderen beobachtet werden kann?
Wenn nicht, gibt es irgendwo noch Stellschrauben, die ich noch nicht gedreht habe?
Mein Env:
Check_MK CEE 1.5 P7
Ich habe 1 Master und 2 Slaves. (ca 2800 Server mit 150K Services)
Die Slaves kommunizieren direkt asynchron zum Eventhandler.
Hat jemand Ideen, wo ich noch tunen kann, oder woran es hängt?
Kind regards /
Mit freundlichen Grüßen
i.A. Fischer, Göran
Senior System Engineer
IMSD Network & Operation C enter
/ Systems Operation****
TUI InfoTec GmbH
Karl-Wiechert-Allee 4 | 30625 Hannover | Germany
Phone: 0511 567 5339 | Fax: 0511 567 93 5339
mailto:goeran.fischer@tui.com
www.tui-infotec.com/
Geschäftsführung: Geschäftsführung: Elke Reichart (Vorsitzende), Michael Ohm, Martin Schreck
Sitz der Gesellschaft: Hannover | Handelsregister: Amtsgericht Hannover HRB 60673
Executive board: Elke Reichart (Chief Executive), Michael Ohm, Martin Schreck
Company seat: Hannover | Commercial Register: Amtsgericht Hannover HRB 60673
This electronic transmission (and any attachments thereto) is intended solely for the use of the addressee(s). It may contain confidential or legally privileged information. If you are not the intended recipient of this message, you must delete it immediately
and notify the sender. Any unauthorized use or disclosure of this message is strictly prohibited. Faurecia does not guarantee the integrity of this transmission and shall therefore never be liable if the message is altered or falsified nor for any virus,
interception or damage to your system.
This electronic transmission (and any attachments thereto) is intended solely for the use of the addressee(s). It may contain confidential or legally privileged information. If you are not the intended recipient of this message, you must delete it immediately
and notify the sender. Any unauthorized use or disclosure of this message is strictly prohibited. Faurecia does not guarantee the integrity of this transmission and shall therefore never be liable if the message is altered or falsified nor for any virus,
interception or damage to your system.