Eskalation von Benachrichtigungen


Einleitung

Nagios unterstützt optional die Eskalation bei der Benachrichtigung der Kontaktpersonen für Hosts und Dienste. In diesem Abschnitt wird beschrieben, wie diese funktionieren, obwohl dieses Feature eigentlich fast selbst erklärend sein sollte...

Eskalation von Dienst-Benachrichtigungen

Die Eskalation von Dienst-Benachrichtigungen wird durch die Definition der Dienst-Eskalationen in den Objekt-Konfigurationsdateien erreicht. Diese werden benutzt um die Eskalation für einen einzelnen Dienst zu definieren.

Eskalation von Host-Benachrichtigungen

Eskalationen bei Host-Benachrichtigungen werden entweder durch die Definition von Host- oder ganzen Hostgruppen-Eskalationen in den Objekt-Konfigurationsdateien ermöglicht. Host-Eskalationen werden für die Eskalation von Benachrichtigungen für einen spezifischen Host benutzt, während die Definition Hostgruppen-Eskalationen für alle Rechner der definierten Hostgruppe gilt. Die hier gezeigten Beispiele benutzen alle Dienst-Eskalationen, aber Host- und Hostgruppen-Eskalationen arbeiten in der gleichen Art und Weise (ausser das hierbei die Eskalation von Host-Benachrichtigungen und nicht von Dienst- Benachrichtigungen definiert werden).

Wann werden Benachrichtigungen eskaliert?

Benachrichtigungen werden nur eskaliert, wenn einer oder mehrere Eskalations-Definitionen mit der aktuellen Benachrichtigungen übereinstimmen. Falls für eine Host- oder Dienst-Benachrichtigung keine gültige Eskalations-Definition vorliegt, werden für den Versand der Benachrichtigung die Kontakte aus der entsprechenden Hostgruppen- oder Dienst-Definition benutzt. Werfen wir einen Blick auf das folgende Beispiel:

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	3
	last_notification	5
	notification_interval	90
	contact_groups		nt-admins,managers
	}

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	6
	last_notification	10
	notification_interval	60
	contact_groups		nt-admins,managers,everyone
	}

Man beachte dass es "Löcher" in der Definition der Benachrichtigungs-Eskalationen gibt. Genauer gesagt werden die Benachrichtigungen 1 und 2 nicht von den Eskalationen behandelt, genauso wie die Benachrichtigungen ab der 10. Alarmierung der Administratoren. Für die erste und zweite Benachrichtigung gelten genauso wie für alle Benachrichtigungen nach der zehnten die Standard-Kontaktinformationen, die in der Dienst-Definition angegeben wurden. Für alle hier genutzten Beispiele nehmen wir an, dass die Standard-Kontaktgruppe für die Dienst-Informationen nt-admin heisst.

Kontaktgruppen

Wenn man Eskalationsstufen für Benachrichtigungen definiert ist es wichtig, dass man beachtet, dass alle Mitglieds-Kontaktgruppen von "niedrigeren" Eskalationsstufen auch Mitglieder in "höheren" Eskalations-Definitionen enthalten sein sollten. Dies sollte man machen, um sicherzustellen, dass alle Personen auch weiterhin benachrichtigt werden, wenn das Problem eskaliert wird.
Beispiel:

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	3
	last_notification	5
	notification_interval	90
	contact_groups		nt-admins,managers
	}

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	6
	last_notification	0
	notification_interval	60
	contact_groups		nt-admins,managers,everyone
	}

Die erste (oder "niedrigste") Eskalationsstufe beinhaltet die nt-admins und managers Kontaktgruppe. Die letzte (oder "höchste") Eskalationsstufe beinhaltet die nt-admins, managers und everyone Kontaktgruppe. Man beachte, dass die nt-admins Kontaktgruppe Mitglied in beiden Eskalationsstufen ist. Nur so wird diese Kontaktgruppe auch dann weiter benachrichtigt, wenn das Problem auch noch nach den ersten beiden Dienst-Benachrichtigungen noch besteht. Die managers Kontaktgruppe ist das erste Mal in der "niedrigsten" Eskalationsstufe enthalten, sie werden also erst benachrichtigt, wenn die dritte Benachrichtigung versandt wird. Da die managers-Gruppe auch noch nach der fünften Benachrichtigungen über das Problem informiert werden sollen, sind sie auch Mitglied der "höchsten" Eskalationsstufe.

Überlappende Eskalationen

Die Definition von Benachrichtigungs-Eskalationen können sich gegenseitig überlappen. Hier ein Beispiel:

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	3
	last_notification	5
	notification_interval	20
	contact_groups		nt-admins,managers
	}

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	4
	last_notification	0
	notification_interval	30
	contact_groups		on-call-support
	}

In dem obigen Beispiel:

Entwarnungs-Benachrichtigungen

Benachrichtigungen über Entwarnungen unterscheiden sich leicht von den Problem-Benachrichtigungen, wenn es um Eskalationen geht. Betrachten wir das folgende Beispiel:

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	3
	last_notification	5
	notification_interval	20
	contact_groups		nt-admins,managers
	}

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	4
	last_notification	0
	notification_interval	30
	contact_groups		on-call-support
	}

Wer wird informiert, wenn, nach drei Problem-Benachrichtigungen, für einen Dienst eine Benachrichtigung über die Entwarnung verschickt werden soll? Die Entwarnung ist genau gezählt insgesamt die vierte Benachrichtigung, die versandt wird. Die Benachrichtigungs-Logik ist so intelligent nur die Kontaktpersonen eine Benachrichtigung über die Entwarnung erhalten, die auch zuvor eine Benachrichtigung über das Problem erhalten haben. In diesem Falle erhalten also die nt-admins und managers Kontaktgruppen über die Entwarnung benachrichtigt werden.

Benachrichtigungs-Intervalle

Man kann mit den eskalierten Benachrichtigung auch die Frequenz der erneuten Benachrichtigung mit Hilfe der notification_interval-Option verändern. Ein Beispiel:

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	3
	last_notification	5
	notification_interval	45
	contact_groups		nt-admins,managers
	}

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	6
	last_notification	0
	notification_interval	60
	contact_groups		nt-admins,managers,everyone
	}

In diesem Beispiel sehen wir dass das Standard-Interval für Benachrichtigungen für diese Dienste bei 240 Minuten liegt (dies ist der Wert in der Dienst-Definition). Wenn die Dienst-Benachrichtigung auf die zweite Stufe (mit der dritten, vierten und fünften Benachrichtigung ) eskaliert wird, wird ein Benachrichtigungs-Interval von 45 Minuten gesetzt. Ab der sechsten Benachrichtigung wird das Benachrichtigungs-Interval, wie in der zweiten Eskalationsstufe definiert, auf 60 Minuten gesetzt.

Da es möglich es Eskalations-Definitionen zu überlappen und der Umstand das ein Host Mitglied von mehreren Hostgruppen sein kann, muss Nagios die Entscheidung fällen, was zu tun ist, wenn sich aufgrund von überlappenden Eskalationen unterschiedliche Angaben über das Benachrichtigungs-Interval vorliegen. In diesem Fall wählt Nagios immer das geringere Benachrichtigungs-Interval. Werfen wir einen Blick auf das folgende Beispiel:

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	3
	last_notification	5
	notification_interval	45
	contact_groups		nt-admins,managers
	}

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	4
	last_notification	0
	notification_interval	60
	contact_groups		nt-admins,managers,everyone
	}

Wir sehen das sich diese beiden Eskalations-Definitionen bei der vierten und fünften Benachrichtigung überschneiden. Für diese Benachrichtigungen wird Nagios ein Interval von 45 Minuten annehmen, da dies das gerigere Interval aus den gültigen Definitionen ist.

Ein letzter Hinweis noch über Benachrichtigungs-Intervalle von 0. Ein Interval von 0 bedeutet, das Nagios nur eine Benachrichtigung in dieser definierten Eskalationsstuge versendet. Alle folgenden Benachrichtigungen für diese Hostgruppe oder Dienst werden unterdrückt. Schauen wir auf das folgende Beispiel:

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	3
	last_notification	5
	notification_interval	45
	contact_groups		nt-admins,managers
	}

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	4
	last_notification	6
	notification_interval	0
	contact_groups		nt-admins,managers,everyone
	}

define serviceescalation{
	host_name		webserver
	service_description	HTTP
	first_notification	7
	last_notification	0
	notification_interval	30
	contact_groups		nt-admins,managers
	}

In dem obigen Beispiel liegt die maximale Anzahl von Problem-Benachrichtigungen die für den HTTP-Dienst versandt werden bei vier. Dies wird erreicht, da das Benachrichtigungs-Interval in der zweiten Eskalations-Definition auf 0 gesetzt wurde. D.h. es wird nur eine Benachrichtigung für diese Stufe ausgesandt, sprich die vierte Benachrichtigung, alle weiteren Benachrichtigungen werden unterdrückt. Dadurch bleibt die dritte Eskalations-Definition aber absolut wirkungslos, da es nie mehr als vier Benachrichtigungen geben wird und die dritte Stufe erst ab der siebenten Benachrichtigung greifen würde.