Alarmierung für bestimmte Services zu bestimmten Zeiten unterdrücken

Nach dem Umstieg auf die CMK2 möchte ich nun auch ein paar alte Baustellen beseitigen :wink:
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

Host vm-xxx01 (vm-xxx01)
Service Service ZkrlSvc
Event OK → CRITICAL
Address vm-xxx01
Date / Time Fri Jun 04 01:15:05 CEST 2021
Summary ISGUS Controller: stopping (start type is auto)
Details ISGUS Controller: stopping (start type is auto)
Host Metrics rta=0.267ms;200.000;500.000;0; pl=0%;40;80;; rtmax=0.300ms;;;; rtmin=0.236ms;;;;
Service Metrics

Und wenn der Dienst wieder angeht CRIT nach OK. Und das für alle Dienste aus dem Backupfenster.
Wo ist mein Denkfehler?

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.

Hallo - Frage am Rande:

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?

1 Like

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.

1 Like

@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.

1 Like

Ich setze für solche Maschinen eine rine wiederkehrende Downtime. Das unterdrückt dann für diese Zeit die Benachrichtigung

1 Like

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)…

1 Like

Damit ist das denke ich schön erklärt wo in den verschiedenen Vorgehen die Vor- u. Nachteile liegen. :slight_smile:

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.

Jörg

Wie man sieht, viele Wege führen nach Rom :grinning:
Ich habe Freitag angefangen die Notifications umzubauen, erstmal mit dem Ergebnis das MEHR eMails kamen :laughing: 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.