Nach dem Umstieg auf die CMK2 möchte ich nun auch ein paar alte Baustellen beseitigen
Ich habe einen (Windows) Server, bei dem Nachts zwischen 1 und 3 Uhr einige Dienste angehalten werden, damit ein Backup gemacht werden kann. Dafür habe ich mir eine Zeitperiode angelegt: jeden Tag 00:00 - 00:50 03:10 - 23:59. In der Alarmierungsregel habe ich diese Periode unter “Nur während Zeitperiode” ausgewählt. Ich habe alle Service Ereignisse ausgewählt. Unter “Matche Servives” habe ich die Services mittlerweile in allen Schreibweisen hinzugefügt:
Als Beispiel hier einer in seinen drei Schreibweisen: .*ZkrlSvc.* / ZkrlSvc / Service ZkrlSvc
Trotzdem bekomme ich jeden Tag eine eMail wenn der Dienst gestoppt wird:
Check_MK: vm-xxx01/Service ZkrlSvc OK → CRIT
Ich würde dies genau anders herum angehen. Du hast deine normale Benachrichtigung und erstellst nun eine Zeitperiode von 00:50-03:10 jeden Tag.
Mit dieser Zeitperiode versiehst du nun eine “Cancel Notification” Regel welche nach deiner normalen Regel kommt. In der Regel kannst noch über die üblichen Bedingungen einzelne Services oder Hosts auswählen. Danach sollte alle Notifications welche Nachts erstellt werden in der Zeit wieder abgebrochen werden und nicht versendet.
Hi Andreas, ich habe alle Benachrichtigungen nach dem Muster…
Wobei die meisten anderen auf Host und nicht auf Service gehen, um in der Regel Meldungen beim regelmäßigen Reboot auszuschließen.
Mal schauen wie groß der Umbauaufwand ist.
Danke.
Wir haben auch einige Alarmregeln mit diesem Muster. Wir haben hier aber regelmäßig das Problem, dass nur der cmk Admin Einblick in die Alarmregeln (bzw. ins Regelwerk generell) hat und ggf. im Nachhinein in der Bringschuld ist, um eine Alarmlogik zu erklären, wenn Alarme vermeintlich nicht rausgingen - v.a. weil der Nutzer im GUI für den Service ja zB in der notification period (for host / service) sieht, dass zB die time period 24x7 eingetragen ist, und von einer etwaigen Cancel Notification erst einmal nichts weiß, geschweige denn, diese Art von Regel(n) sehen / recherchieren kann.
Deswegen ist unser Plan dahingehend, dass wir solche Fälle eher über die WATO Regeln “notification period for host / service” abbilden wollen, um somit mehr Transparenz für alle User zu schaffen anstelle einer “blackbox Alarmregelwerk” - zumal beides (also cancel notification wie notification period) ja die dafür angelegte time period nutzen würde.
Für uns ist das wie gesagt eine Art lesson learned - vllt sieht das jmd gleich … oder anders?
Ich habe zum Testen das Ganze mal mit einem Dienst am meinem PC ausprobiert.
Beides funktioniert dort. Eine Zeitperiode die den Zeitraum ausschließt und auch die Cancel Regel in diesem Zeitraum.
Bei den Cancel Regeln hat man immer zwei Regeln wenn man einen Zeitraum ausschließen möchte, finde ich unschön. Das Problem von @brm haben wir hier nicht. Nur die meine Jungs und ich schauen in den CMK und wir sehen eh alle Regeln.
Stellt sich die Frage warum es mit dem “richtigen” Zeitraum für die Benachrichtigungen für die Dienste von dem einen Server nicht klappt.
@brm ist das nicht ähnlich schwer ersichtlich wie die Cancel Regeln?
Ich kann beiden verschiedenen Vorgehen was abgewinnen. @brm hat schon recht wenn man die Regelwerke im ganzen betrachtet dann ist die Lösung mit der Notification Period leichter ersichtlich da diese bei jedem Object sichtbar ist sobald ich das Objekt selbst sehen kann oder es bearbeiten darf.
Das kann ich nicht nachvollziehen. Es wird doch pro auszuschließenden Zeitraum nur eine Regel erstellt. Die allgemeine Benachrichtigungsregel ist ja eh da.
Ich nutze Cancel Regeln halt nicht nur für Zeiträume sondern auch für andere Aufgaben deshalb werden die bei mir gern genutzt.
Für den Nutzer ist nur sichtbar im Logfile ob auch endgültig eine Nachricht raus ging aber nicht wenn die abgebrochen wurde und dann warum.
@andreas-doehler Ja ich glaube ich habe mein Problem so langsam auch erkannt.
Irgendwie war ich der Ansicht ich muss eine explizite “Erzeugungsregel” für die Benachrichtigungen haben und die dann für den entsprechenden Zeitraum wieder canceln.
Wiederkehrende Downtimes (oder Cancel notifications) waren auch lange Zeit unser Mittel der Wahl (anstelle von notification periods), weil schnell, einfach und von jedem eintragbar - bis wir an den Punkt kamen, dass…
ab einer kritischen Größe überwachter Hosts manuelle Einträge wie Downtimes Pflegeaufwand bedeuten oder sogar zu Inkonsistenzen führen
neue Anforderungen gestellt werden wie zB sicherheitsrelevante Services immer (24x7) alarmieren zu lassen im Vgl. zu “Standardservices” wie CPU usw., die über eine notificaiton period gesteuert werden sollen
(wiederkehrende) Downtimes im Sinne von Maintenance im Vgl. zu einer (ggf. vertraglich definierten) Alarmzeit (also service notification period) einfach nicht das gleiche sind und man irgendwann ohne Unterscheidung in einer Art Sackgasse landet
(wiederkehrende) Downtimes sowie Cancel notifications im Vgl. zu (im WATO) definierten service notification periods je nach Usergroup schlecht bis gar nicht einsehbar sind / abgefragt werden können
Vermutlich ist das je nach Handhabe eines jeden Nutzers/Admins oder Ausrichtung des Monitorings unterschiedlich zu beurteilen - für die einen ist es Haarspalterei, warum man zwischen den 3 Varianten unterscheidet, für die anderen ist es aufgrund von Vorgaben zwingend erforderlich (geworden)…
Vollkommen richtig, hier geht es aber darum gezielt drei Services mit definierten Namen zu erwischen. Daher halte ich in diesem Fall die Downtimes für das einfachste Mittel.
Wie man sieht, viele Wege führen nach Rom
Ich habe Freitag angefangen die Notifications umzubauen, erstmal mit dem Ergebnis das MEHR eMails kamen Leider auch genau die, die ich weg haben wollte.
Da werde ich mich jetzt langsam rantasten müssen. Das ganze Thema ist bei uns relativ stiefmütterlich behandelt worden und seit Urzeiten nicht mehr groß beachtet.
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.
Leider auch genau die, die ich weg haben wollte.