Delay service notification bei Socket timeout funktioniert nicht richtig

Overlord · July 22, 2021, 7:18am

Hier habe ich direkt noch ein Beispiel:

Event	OK → WARNING
Date / Time	Thu Jul 22 01:50:58 CEST 2021
Summary	RAM: 98.0% - 23.52 GB of 24.00 GBWARN, Commit charge: 64.74% - 31.08 GB of 48.01 GB

Delay sollten 3 Minuten sein - Regel wird angewendet und sollte greifen

Event	WARNING → OK
Date / Time	Thu Jul 22 01:51:58 CEST 2021
Summary	RAM: 97.97% - 23.51 GB of 24.00 GB, Commit charge: 64.75% - 31.08 GB of 48.01 GB

define service {
   check_command                 check_mk-mem_win
   check_interval                1.0
   first_notification_delay      3.0
   max_check_attempts            3
   service_description           Memory
   use                           check_mk_passive_perf
 }

[1626904800] CURRENT SERVICE STATE: server;Memory;OK;HARD;1;RAM: 83.78% - 20.11 GB of 24.00 GB, Commit charge: 63.11% - 30.30 GB of 48.01 GB
[1626911340] SERVICE ALERT: server;Memory;WARNING;SOFT;1;RAM: 98.22% - 23.57 GB of 24.00 GB(!), Commit charge: 64.9% - 31.16 GB of 48.01 GB
[1626911397] SERVICE ALERT: server;Memory;WARNING;SOFT;2;RAM: 98.24% - 23.58 GB of 24.00 GB(!), Commit charge: 64.78% - 31.10 GB of 48.01 GB
[1626911458] SERVICE ALERT: server;Memory;WARNING;HARD;3;RAM: 98.0% - 23.52 GB of 24.00 GB(!), Commit charge: 64.74% - 31.08 GB of 48.01 GB
[1626911458] SERVICE NOTIFICATION: check-mk-notify;server;Memory;WARNING;check-mk-notify;RAM: 98.0% - 23.52 GB of 24.00 GB(!), Commit charge: 64.74% - 31.08 GB of 48.01 GB
[1626911460] EXTERNAL COMMAND: _LOG;SERVICE NOTIFICATION: user,admin@domain.de;server;Memory;WARNING;mail;RAM: 98.0% - 23.52 GB of 24.00 GB(!), Commit charge: 64.74% - 31.08 GB of 48.01 GB
[1626911460] SERVICE NOTIFICATION: user,admin@domain.de;server;Memory;WARNING;mail;RAM: 98.0% - 23.52 GB of 24.00 GB(!), Commit charge: 64.74% - 31.08 GB of 48.01 GB
[1626911518] SERVICE ALERT: server;Memory;OK;HARD;3;RAM: 97.97% - 23.51 GB of 24.00 GB, Commit charge: 64.75% - 31.08 GB of 48.01 GB
[1626911518] SERVICE NOTIFICATION: check-mk-notify;server;Memory;OK;check-mk-notify;RAM: 97.97% - 23.51 GB of 24.00 GB, Commit charge: 64.75% - 31.08 GB of 48.01 GB
[1626911520] EXTERNAL COMMAND: _LOG;SERVICE NOTIFICATION: user,admin@domain.de;server;Memory;OK;mail;RAM: 97.97% - 23.51 GB of 24.00 GB, Commit charge: 64.75% - 31.08 GB of 48.01 GB
[1626911520] SERVICE NOTIFICATION: user,admin@domain.de;server;Memory;OK;mail;RAM: 97.97% - 23.51 GB of 24.00 GB, Commit charge: 64.75% - 31.08 GB of 48.01 GB
[1626911578] SERVICE ALERT: server;Memory;WARNING;SOFT;1;RAM: 98.03% - 23.53 GB of 24.00 GB(!), Commit charge: 64.74% - 31.08 GB of 48.01 GB
[1626911638] SERVICE ALERT: server;Memory;OK;SOFT;2;RAM: 97.51% - 23.40 GB of 24.00 GB, Commit charge: 64.85% - 31.13 GB of 48.01 GB
[1626912480] SERVICE ALERT: server;Memory;WARNING;SOFT;1;RAM: 98.18% - 23.56 GB of 24.00 GB(!), Commit charge: 65.32% - 31.36 GB of 48.01 GB
[1626912541] SERVICE ALERT: server;Memory;WARNING;SOFT;2;RAM: 98.72% - 23.69 GB of 24.00 GB(!), Commit charge: 65.37% - 31.38 GB of 48.01 GB
[1626912601] SERVICE ALERT: server;Memory;WARNING;HARD;3;RAM: 98.85% - 23.72 GB of 24.00 GB(!), Commit charge: 65.38% - 31.39 GB of 48.01 GB
[1626912601] SERVICE NOTIFICATION: check-mk-notify;server;Memory;WARNING;check-mk-notify;RAM: 98.85% - 23.72 GB of 24.00 GB(!), Commit charge: 65.38% - 31.39 GB of 48.01 GB
[1626912603] EXTERNAL COMMAND: _LOG;SERVICE NOTIFICATION: user,admin@domain.de;server;Memory;WARNING;mail;RAM: 98.85% - 23.72 GB of 24.00 GB(!), Commit charge: 65.38% - 31.39 GB of 48.01 GB
[1626912603] SERVICE NOTIFICATION: user,admin@domain.de;server;Memory;WARNING;mail;RAM: 98.85% - 23.72 GB of 24.00 GB(!), Commit charge: 65.38% - 31.39 GB of 48.01 GB
[1626912725] SERVICE ALERT: server;Memory;CRITICAL;HARD;3;RAM: 99.34% - 23.84 GB of 24.00 GB(!!), Commit charge: 65.37% - 31.38 GB of 48.01 GB
[1626912725] SERVICE FLAPPING ALERT: server;Memory;STARTED; Service appears to have started flapping (20.1% change >= 20.0% threshold)
[1626912725] SERVICE NOTIFICATION: check-mk-notify;server;Memory;FLAPPINGSTART (CRITICAL);check-mk-notify;RAM: 99.34% - 23.84 GB of 24.00 GB(!!), Commit charge: 65.37% - 31.38 GB of 48.01 GB
[1626912782] SERVICE ALERT: server;Memory;WARNING;HARD;3;RAM: 98.86% - 23.73 GB of 24.00 GB(!), Commit charge: 65.35% - 31.38 GB of 48.01 GB
[1626912843] SERVICE ALERT: server;Memory;CRITICAL;HARD;3;RAM: 99.05% - 23.77 GB of 24.00 GB(!!), Commit charge: 65.35% - 31.37 GB of 48.01 GB
[1626913023] SERVICE ALERT: server;Memory;WARNING;HARD;3;RAM: 98.95% - 23.75 GB of 24.00 GB(!), Commit charge: 65.51% - 31.45 GB of 48.01 GB
[1626913083] SERVICE ALERT: server;Memory;CRITICAL;HARD;3;RAM: 99.04% - 23.77 GB of 24.00 GB(!!), Commit charge: 65.4% - 31.40 GB of 48.01 GB
[1626913141] SERVICE ALERT: server;Memory;WARNING;HARD;3;RAM: 98.82% - 23.72 GB of 24.00 GB(!), Commit charge: 65.43% - 31.41 GB of 48.01 GB
[1626913202] SERVICE ALERT: server;Memory;CRITICAL;HARD;3;RAM: 99.09% - 23.78 GB of 24.00 GB(!!), Commit charge: 65.5% - 31.45 GB of 48.01 GB
[1626913262] SERVICE ALERT: server;Memory;WARNING;HARD;3;RAM: 98.95% - 23.75 GB of 24.00 GB(!), Commit charge: 65.55% - 31.47 GB of 48.01 GB
[1626913747] SERVICE ALERT: server;Memory;CRITICAL;HARD;3;RAM: 99.06% - 23.77 GB of 24.00 GB(!!), Commit charge: 65.57% - 31.48 GB of 48.01 GB
[1626913801] SERVICE ALERT: server;Memory;OK;HARD;3;RAM: 97.71% - 23.45 GB of 24.00 GB, Commit charge: 65.6% - 31.49 GB of 48.01 GB
[1626913864] SERVICE ALERT: server;Memory;WARNING;SOFT;1;RAM: 98.39% - 23.61 GB of 24.00 GB(!), Commit charge: 65.72% - 31.55 GB of 48.01 GB
[1626913924] SERVICE ALERT: server;Memory;WARNING;SOFT;2;RAM: 98.87% - 23.73 GB of 24.00 GB(!), Commit charge: 65.82% - 31.60 GB of 48.01 GB
[1626913984] SERVICE ALERT: server;Memory;WARNING;HARD;3;RAM: 98.72% - 23.69 GB of 24.00 GB(!), Commit charge: 65.83% - 31.60 GB of 48.01 GB
[1626914040] SERVICE ALERT: server;Memory;CRITICAL;HARD;3;RAM: 99.2% - 23.81 GB of 24.00 GB(!!), Commit charge: 65.79% - 31.58 GB of 48.01 GB
[1626914093] SERVICE ALERT: server;Memory;OK;HARD;3;RAM: 62.71% - 15.05 GB of 24.00 GB, Commit charge: 61.99% - 29.76 GB of 48.01 GB
[1626915233] SERVICE FLAPPING ALERT: server;Memory;STOPPED; Service appears to have stopped flapping (3.8% change < 5.0% threshold)
[1626915233] SERVICE NOTIFICATION: check-mk-notify;server;Memory;FLAPPINGSTOP (OK);check-mk-notify;RAM: 68.18% - 16.36 GB of 24.00 GB, Commit charge: 62.83% - 30.16 GB of 48.01 GB
[1626935975] INITIAL SERVICE STATE: server;Memory;OK;HARD;1;RAM: 77.8% - 18.67 GB of 24.00 GB, Commit charge: 64.48% - 30.96 GB of 48.01 GB
[1626936681] INITIAL SERVICE STATE: server;Memory;OK;HARD;1;RAM: 78.06% - 18.73 GB of 24.00 GB, Commit charge: 64.42% - 30.93 GB of 48.01 GB

andreas-doehler · July 22, 2021, 9:59am

Ok hab was in der alten Nagios Doku gefunden oder besser gesagt einfach mal nach “first_notification_delay” gesucht.

The time for “first notification delay” is timed based on the last known OK state not from the first failure
So if you normally check on 5 minute intervals and recheck interval set to 3 minutes with 3 tries, the service would reach a HARD state at

5 + 3 + 3 + 3 = 14

Being you have your “first notification delay” set to 13 it would be sent immediately.
If you want the notification to go out 13 minutes after it goes into a hard state, set it to 27.

Also im Endeffekt noch etwas Rechenarbeit für dieses Setting.

Overlord · July 22, 2021, 10:21am

Danke dir für die Mühe - bedeutet also in dem letzten Fall wäre das:

check_interval                1.0
first_notification_delay      3.0
max_check_attempts            3

1 + 1 + 1 + 1 = 4
Check Interval (1) + Max Check attemps (3)

Heißt ich müsste das Delay dann statt 3 auf 7 stellen? Ist es denn fehlerhaft implementiert? Theoretisch könnte CheckMK das ja selber ausrechnen und den Wert dann einfach + Delay oben drauf. Oder ist das nur “fehlerhaft” beim Nagios Kernel drin und beim Micro Core ist es richtig implementiert - so dass man einfach 3 einträgt für das Delay

andreas-doehler · July 22, 2021, 11:17am

Würde ich sagen stimmt.

Nö ist halt im Nagios Core schon immer so - hat sich nur niemand von uns hier genau die alte Doku durchgelesen

Ob der MicroCore das anders macht kann ich gar nicht sagen. Ich nutze normal kein Delay First Notification sondern nur die Check Attempts um ein Delay until Hard State zu bauen. Das reicht mir in 99% der Fälle völlig aus und ist auch eindeutig nachvollziehbar.

Overlord · July 30, 2021, 6:44am

Ganz so scheint die Lösung vllt. noch nicht zu sein:

Event	OK → WARNING
Date / Time	Fri Jul 30 01:53:15 CEST 2021

Event	WARNING → OK
Date / Time	Fri Jul 30 01:55:13 CEST 2021

Differenz: 1:58

Delay service notifications: 7 minutes
Normal check interval for service checks: 1 minutes
Retry check interval for service checks: 1 minutes
Current check attempt: 1/3

Müsste doch dann 1 + 3 sein und mit 7 dann 3 Minuten Delay.

andreas-doehler · July 30, 2021, 7:10am

Das Einzige was hier zählt und wichtig ist, ist das Logfile vom Nagios von der ersten Meldung (Soft State) bis wieder ok ist.

Overlord · August 3, 2021, 10:26am

Weißt du wie das im Microcore ist? Ist das Verhalten da auch so? Ich habe jetzt auf den Microcore umgestellt, dennoch habe ich weiterhin Meldungen drin, die nicht so sein dürften:

Event	OK → CRITICAL
Date / Time	Mon Aug 02 16:30:07 CEST 2021

Event	CRITICAL → OK
Date / Time	Mon Aug 02 16:30:41 CEST 2021

Delay sind auf 1 Minute 30 Sekunden.

andreas-doehler · August 3, 2021, 11:31am

Beim Microcore ist das Logfile meines Wissens nach auch entscheidend.
Also dort mal schauen was da an Einträgen wirklich vorhanden ist.

Overlord · August 5, 2021, 7:53am

Event	OK → CRITICAL
Date / Time	Wed Aug 04 23:08:56 CEST 2021

Event	CRITICAL → OK
Date / Time	Wed Aug 04 23:09:23 CEST 2021

Delay service notifications: 3 minutes
Maximum number of check attempts for service: 3
Normal check interval for service checks: 1 minutes
Retry check interval for service checks: 1 minutes
Service check timeout (Microcore): 1 minutes

cmc.log:

2021-08-04 23:09:01 [5] [core 172012] Executing external command: LOG;SERVICE NOTIFICATION: overlord,admin@domain.tld;server;Service Servicename;CRITICAL;mail;Password Safe Service: stopped (start type is auto)
2021-08-04 23:09:02 [5] [core 172012] Executing external command: LOG;SERVICE NOTIFICATION RESULT: overlord,admin@domain.tld;server;Service Servicename;OK;mail;Spooled mail to local mail transmission agent;Spooled mail to local mail transmission agent
2021-08-04 23:09:27 [5] [core 172012] Executing external command: LOG;SERVICE NOTIFICATION: overlord,admin@domain.tld;server;Service Servicename;OK;mail;Password Safe Service: running (start type is auto)
2021-08-04 23:09:28 [5] [core 172012] Executing external command: LOG;SERVICE NOTIFICATION RESULT: overlord,admin@domain.tld;server;Service Servicename;OK;mail;Spooled mail to local mail transmission agent;Spooled mail to local mail transmission agent

andreas-doehler · August 5, 2021, 7:58am

Das ist bisl wenig auch hier ist wichtig wann trat der erste Soft-State auf usw.
Die Meldung des Crit und danach des OK kann ja durchaus in Ordnung sein wenn der erste Soft-State mindestens 3 Minuten vorher war.

Bei deiner Einstellung oben wird doch eh sobald ein Hard-State erreicht wird die Mail versendet.
3 Minuten Delay und 3 Attempts sind doch beides der gleiche Zeit Intervall ca.
Wenn die Mail nicht schon zum Hard-State raus soll dann muss beim Delay mindestens ne 4 oder höher stehen.

Overlord · August 5, 2021, 8:01am

Das ist ja die Frage, ob der Microcore auch so reagiert wie der Nagios Core. Wenn ja, finde ich auch die Implementierung hier fragwürdig.

Theoretisch kann sich CheckMK das ja selber ausrechnen - wenn ich das jetzt mache und irgendwann mittels Regel z. B. das Retry Interval geändert wird (von 2 auf 3), müsste man überall das Delay anpassen. Einfacher wäre es, wenn CheckMK die Berechnung selber anpasst. Dann trägt man hier z. B. 1 Minute ein und CheckMK setzt davor noch die Berechnung von “Normal Check + Retry Interval”

andreas-doehler · August 5, 2021, 8:08am

Ich würde immer dafür plädieren entweder Check Attempts oder Delay first Notification zu verwenden.
Beide Settings gemeinsam führen nur zu “Hirnproblemen” wenn man nachvollziehen will was warum passiert ist in Bezug auf Notifications. Nicht vergessen, dass im Notification System selbst auch noch Delays einbaubar sind.

system · August 5, 2022, 8:08am

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.