irgendwie scheint bei uns der Wurm im System (2.0.0p6) zu sein. Ich hatte heutre die Alarmierung bei uns aktiviert und die bisherigen Critical Meldungen für einen bestimmten Service nochmal manuell zu versenden damit die Verantwortlichen die Info erhalten. Es waren ca. 450 Services und es hat sage und schreibe fast 2h gedauert bis die alle versendet wurden.
Die einzelnen Mails gingen beim Exchange in folgenden Abständen einzeln ein. Ausschnitt
Woran kann es liegen das hier CheckMK Ewigkeiten braucht um die Mails an den Exchange zu übermitteln oder gibt es da eine eingebaute Bremse in der CheckMK Konfiguration?
Unter op5 (Nagios) geht das definitiv flotter und am Exchange wird hier nichts ausgebremst.
Das kommt drauf an wie deine Notification konfiguriert ist.
Ist das ganze ein verteiltes System mit Auslieferung über den Master oder ist dies eine Instanz welche Ihre Notifications selbst einfach versendet?
Schau mal in den Global Settings wie dort “Notification Spooling” konfiguriert ist. Falls da “Asynchronous local delivery…” drin steht würde das dein Problem erklären. Hier einfach “Direct local…” einstellen und die Mails gehen schnell raus.
Wenn so viele Notifications versendet werden ist auch etwas nicht ok in der Konfiguration/Mail Setup. Das schaut sich niemand an und die Mails landen alle in der Rundablage.
Du hattest Recht mit deiner Vermutung und ich frage mich warum unser damaliger Dienstleister das nicht erwähnt hatte. Gestern hatten wir eine reguläre Wartung und durch das zyklische Wartungsfenster bekamen die Systemverantwortlichen eine Mail über die beginnende Downtime. Hier kamen selbst heute morgen noch E-Mails an mit dem Zeitstemple von gestern Abend und das ist mehr als peinlich.
Sobald ich am Exchange wieder die IP zum Senden zulassen kommen weiter die Mails aus dem Spooler an auch wenn in CheckMK alles deaktiviert wurde.
Kann ich den Inhalt aus /omd/sites/site/var/check_mk/notify/backlog.mk löschen oder gibt es einen eleganteren Weg zum leeren vom Spooler?
Ist es hier sinnvoll noch etwas anzupassen wenn wir per SMTP Mails versenden?
Das kann auch am mknotifyd (nur Enterprise Editions) liegen.
Bei uns braucht der ~4-6 Sekunden pro Event. Wenn dann mal etwas mehr los ist kann das dann schon mal ein Weilchen dauern bis alle Spoolfiles verarbeitet sind.
Die eigentlichen Alarmierungsskripte, welche die Events am Ende an das jeweilige Zielsystem versenden brauchen im Vergleich nur ~0.05 Sekunden für die eigentliche Übermittlung.
Wenn sich viele Files im var/check_mk/notify/spool befinden dann ist der mknotifyd noch am abarbeiten der Events.
Ja im Endeffekt darf sich innerhalb des notify Ordners nix mehr befinden, außer den Verzeichnissen @martin.schwarz und @LaSoe haben ja schon das eigentliche Problem genannt - einmal Factory Settings und als zweites die langsame Verarbeitung des Spoolers.
Es werden in den Unterordnern aktuell keine Dateien erstellt da die Alarmierungsregel inaktiv ist.
Ich habe derzeit nur das Problem, das ich beim hinterlegen der IP vom CheckMK System am Exchange weiterhin Mails aus der gestrigen Downtime zugestellt werden.
Was hat es mit dieser Datei auf sich die ich in der Doku nicht gefunden habe?
/omd/sites/site/var/check_mk/notify/backlog.mk
Wenn die niemand braucht kannst das Backlog einfach entsorgen.
Und im System selbst beim MTA schauen ob dort noch Mails in der Queue vorhanden sind die auch mal bereinigen.
ich habe heute unsere Alarmierung wieder eingeschaltet und bei ca. 100 Services eine manuelle Alarmierung ausgelöst damit die Serververantwortlichen die Info per Mails bekommen.
Die Mails werden weiterhin immens langsam abgearbeitet und kommen so bei den Postfächern schleppend an. Wenn ich auf der Appliance im WebConf die “Ausgehende E-Mail-Warteschlange” ansehe, so hängen dort noch sehr viele E-Mails drin die der nullmailer noch nicht versendet hat.
Da sind mitunter 30min vergangen und weshalb schafft es CheckMK nicht die Mails in einem Rutsch an den Exchange Server zu versenden?
Unser altes Monitoringsystem (op5) hat damit keine Probleme und schickt das ASAP an den Exchange der das auch abarbeitet. Der Exchange bremst hier die Zustellung definitiv nicht aus.
In der Enterprise Edition hast sogar noch ne bessere Möglichkeit komplett ohne lokalen Mailer. Gibt im Abschnitt “Notification Method” der Mail Regel den Punkt “Enable synchronous delivery via SMTP” dort kannst gleich deinen Exchange als SmartHost reinwerfen.
Ok das ist natürlich auch ein guter Punkt den ich gleich mal umgesetzt habe. Muss ich jetzt in den Globalen Einstellungen irgendwas zurück bauen (siehe Bild von oben) oder kann das so bleiben?
Gehen die neuen E-Mails auch in die normale Warteschlange die ich im WebConf sehen kann oder geht das ohne Gnade Richtung Exchange
Ich werde weiter berichten wie es sich mit den Mails verhält denn nach der Änderung sind weiterhin noch paar Mails von 13Uhr in der Warteschlange.
MfG Paul
Update:
So sieht es aktuell nun in der Warteschlange aus.
Habe nun einmal einen manuellen Alarm ausgelöst und der kam sofort an was zeigt, das die Einstellungen wirken und ich bin begeistert und bedanke mich sehr bei Dir Andreas.
