Icinga

Objektdefinitionen

Einführung

Eine der Möglichkeiten des Objektkonfigurationsformats von Icinga besteht darin, dass Sie Objektkonfigurationsdefinitionen erstellen können, die Eigenschaften von anderen Objektdefinitionen erben. Eine Erklärung, wie Objektvererbung funktioniert, finden Sie hier. Wir empfehlen Ihnen dringend, dass Sie sich mit Objektvererbung beschäftigen, nachdem Sie die folgende Dokumentation überflogen haben, weil sie Ihnen die Arbeit bei der Erstellung und Wartung der Objektdefinitionen viel einfacher macht. Lesen Sie außerdem die Objekt-Tricks, die Ihnen Abkürzungsmöglichkeiten für andernfalls langwierige Konfigurationsaufgaben bieten.

Wenn Sie Konfigurationsdateien anlegen und/oder editieren, dann behalten Sie das Folgende im Hinterkopf:

  1. Zeilen, die mit einem '#'-Zeichen beginnen, werden als Kommentare angesehen und nicht verarbeitet

  2. Direktivennamen sind "case-sensitive", die Beachtung von Groß- und Kleinschreibung ist wichtig!

  3. Zeichen nach einem Semikolon (;) in Konfigurationszeilen werden als Kommentar angesehen und deshalb nicht verarbeitet

[Anmerkung] Anmerkung

Bitte vermeiden Sie die Verwendung von Sonderzeichen in den Objektdefinitionen. In Icinga <= 1.5.0 gab es einen Fehler, der die Ausführung von "forced reschedules" im Classic UI verhinderte, wobei als Meldung ein "not authorized" angezeigt wurde.

Anmerkungen zur Aufbewahrung (Retention Notes)

Es ist wichtig anzumerken, dass einige Direktiven in Host-, Service- und Kontaktdefinitionen möglicherweise keine Wirkung zeigen, wenn Sie diese in den Konfigurationsdateien ändern. Objektdirektiven, die dieses Verhalten zeigen, sind mit einem Stern gekennzeichnet (*). Der Grund für dieses Verhalten liegt darin, dass Icinga Werte in der Statusaufbewahrungsdatei denen aus den Konfigurationsdateien vorzieht, wenn Sie Statusaufbewahrung auf programmweiter Basis aktiviert haben und den Wert der Direktive während der Laufzeit mit einem externen Befehl geändert haben.

Ein Weg, um dieses Problem zu umgehen, ist das Deaktivieren der Aufbewahrung von nicht-Statusinformationen mit Hilfe der retain_nonstatus_information-Direktive in den Host-, Service- und Kontaktdefinitionen. Durch das Deaktivieren dieser Direktive wird Icinga dazu veranlasst, beim (Neu-)Start die initialen Werte für diese Direktiven aus Ihren Konfigurationsdateien zu nehmen, statt die aus der Statusaufbewahrungsdatei zu verwenden.

Beispielkonfigurationsdatei

Anmerkung: Beispielobjektkonfigurationsdateien werden im /usr/local/icinga/etc/-Verzeichnis installiert, wenn Sie der Schnellstart-Anleitung gefolgt sind.

Objekttypen

Host-Definitionen

Hostgruppen-Definitionen

Service-Definitionen

Servicegruppen-Definitionen

Kontakt-Definitionen

Kontaktgruppen-Definitionen

Zeitfenster-Definitionen

Befehlsdefinitionen

Service-Abhängigkeitsdefinitionen

Service-Eskalationsdefinitionen

Host-Abhängigkeitsdefinitionen

Host-Eskalationsdefinitionen

erweiterte Host-Informationsdefinitionen

erweiterte Service-Informationsdefinitionen

Host-Definition

Beschreibung:

Eine Host-Definition wird benutzt, um einen Server, eine Workstation, ein Gerät usw. zu definieren, die sich in Ihrem Netzwerk befinden.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional. Lesen Sie auf jeden Fall die Anmerkungen zur "address"-, "contacts"- und "contact_groups"-Direktive .

define host{

host_name

host_name

alias alias

display_name

display_name

address address

address6 address6

parents

host_names

hostgroups

hostgroup_names

check_command

command_name

initial_state

[o,d,u]

max_check_attempts

#

check_interval

#

retry_interval

#

active_checks_enabled

[0/1]

passive_checks_enabled

[0/1]

check_period timeperiod_name

obsess_over_host

[0/1]

check_freshness

[0/1]

freshness_threshold

#

event_handler

command_name

event_handler_enabled

[0/1]

low_flap_threshold

#

high_flap_threshold

#

flap_detection_enabled

[0/1]

flap_detection_options

[o,d,u]

failure_prediction_enabled

[0/1]

process_perf_data

[0/1]

retain_status_information

[0/1]

retain_nonstatus_information

[0/1]

contacts contacts

contact_groups contact_groups

notification_interval

#

first_notification_delay

#

notification_period timeperiod_name

notification_options

[d,u,r,f,s]

notifications_enabled

[0/1]

stalking_options

[o,d,u]

notes

note_string

notes_url

url

action_url

url

icon_image

image_file

icon_image_alt

alt_string

vrml_image

image_file

statusmap_image

image_file

2d_coords

x_coord,y_coord

3d_coords

x_coord,y_coord,z_coord

   

}

Beispieldefinition:

 define host{
        host_name                       bogus-router
        alias                           Bogus Router #1
        address                         192.168.1.254
        parents                         server-backbone
        check_command                   check-host-alive
        check_interval                  5
        retry_interval                  1
        max_check_attempts              5
        check_period                    24x7
        process_perf_data               0
        retain_nonstatus_information    0
        contact_groups                  router-admins
        notification_interval           30
        notification_period             24x7
        notification_options            d,u,r
        }

Beschreibung der Direktiven:

host_name:

Diese Direktive wird benutzt, um einen Kurznamen zu definieren, der den Host identifiziert. Er wird in Hostgruppen- und Service-Definitionen benutzt, um auf diesen bestimmten Host zu verweisen. Hosts können mehrere Services haben (die überwacht werden), die mit ihm verbunden sind.

alias:

Diese Direktive wird benutzt, um einen längeren Namen oder eine Beschreibung zu definieren, der/die den Host identifiziert. Er/sie wird angeboten, damit Sie den Host einfacher identifizieren können. Bei korrekter Anwendung wird das $HOSTALIAS$-Makro diesen Alias/diese Beschreibung enthalten.

address:

Diese Direktive wird benutzt, um die Adresse des Hosts zu definieren. Normalerweise ist dies die IP-Adresse des Hosts, obwohl es eigentlich alles sein kann, was Sie wollen (solange es genutzt werden kann, um den Status des Hosts zu prüfen). Sie können einen vollqualifizierten Domänennamen (FQDN) statt einer IP-Adresse benutzen, um den Host zu identifizieren, aber wenn keine DNS-Dienste verfügbar sind, kann dies zu Problemen führen. Bei korrekter Anwendung wird das $HOSTADDRESS$-Makro diese Adresse enthalten. Anmerkung: Wenn Sie keine Adress-Direktive in einer Host-Definition benutzen, wird der Name des Hosts statt der Adresse benutzt. Trotzdem ein Wort der Warnung: wenn DNS ausfällt, werden die meisten Ihrer Service-Prüfungen fehlschlagen, weil die Plugins nicht in der Lage sind, den Host-Namen aufzulösen.

address6:

Diese Direktive wird benutzt, um eine zweite Adresse des Hosts zu definieren. Normalerweise ist dies die IPv6-Adresse des Hosts, obwohl es eigentlich alles sein kann, was Sie wollen (solange es genutzt werden kann, um den Status des Hosts zu prüfen). Sie können einen vollqualifizierten Domänennamen (FQDN) statt einer IP-Adresse benutzen, um den Host zu identifizieren, aber wenn keine DNS-Dienste verfügbar sind, kann dies zu Problemen führen. Bei korrekter Anwendung wird das $HOSTADDRESS6$-Makro diese Adresse enthalten. Anmerkung: Wenn Sie keine Adress6-Direktive in einer Host-Definition benutzen, wird der Name des Hosts statt der Adresse benutzt. Trotzdem ein Wort der Warnung: wenn DNS ausfällt, werden die meisten Ihrer Service-Prüfungen fehlschlagen, weil die Plugins nicht in der Lage sind, den Host-Namen aufzulösen (verfügbar ab Icinga 1.3).

display_name:

Diese Direktive wird benutzt, um einen alternativen Namen zu definieren, der im Web-Interface für den Host angezeigt wird. Wenn nicht angegeben, wird statt dessen der Wert der host_name-Direktive benutzt. Anmerkung: Die CGIs bis einschließlich Icinga 1.0.1 nutzen diese Option nicht.

parents:

Diese Direktive wird benutzt, um eine Komma-separierte Liste von Kurznamen der "Eltern"-Hosts dieses bestimmten Hosts zu definieren. Eltern-Hosts sind typischerweise Router, Switches, Firewalls usw. Ein Router, Switch usw., der am nächsten zum entfernten Host ist, wird als "Eltern" dieses Hosts angesehen. Lesen Sie weitere Informationen im Dokument "Festlegen des Zustands und der Erreichbarkeit von Netzwerk-Hosts", das Sie hier finden. Wenn dieser Host im gleichen Netzwerksegment wie der überwachende Host ist (ohne dazwischen liegende Router usw.), wird der Host als im lokalen Netzwerk befindlich angesehen und hat deshalb keinen Eltern-Host. Lassen Sie diesen Wert leer, wenn der Host keinen Eltern-Host hat (d.h. wenn er im gleichen Segment wie der Icinga-Host ist). Die Reihenfolge, in der Sie Eltern-Hosts angeben, hat keinen Einfluss darauf, wie Dinge überwacht werden.

hostgroups:

Diese Direktive wird benutzt, um den/die Kurznamen der Hostgruppe(n) anzugeben, zu dem/denen der Host gehört. Mehrere Hostgruppen werden durch Kommata von einander getrennt. Diese Direktive kann als Alternative (oder zusätzlich) zur members-Direktive in den hostgroup-Definitionen genutzt werden.

check_command:

Diese Direktive wird benutzt, um den Kurznamen des Befehls anzugeben, mit dem geprüft wird, ob der Host funktioniert oder nicht. Typischerweise wird dieser Befehl versuchen, den Host per "ping" zu prüfen, ob er "lebt". Der Befehl muss den Status OK (0) zurückliefern, denn sonst wird Icinga annehmen, dass der Host "down" ist. Wenn Sie diesen Wert leer lassen, wird der Host nicht aktiv geprüft. Dadurch wird Icinga höchstwahrscheinlich annehmen, dass der Host "up" ist (und ihn ggf. als "PENDING" im Web-Interface anzeigen). Das ist nützlich, wenn Sie Drucker oder andere Geräte überwachen, die regelmäßig ausgeschaltet werden. Die maximale Zeit, die der Prüfbefehl laufen darf, wird durch die host_check_timeout-Option kontrolliert.

initial_state:

Als Default nimmt Icinga an, dass sich alle Hosts im UP-Zustand befinden, wenn es startet. Sie können mit dieser Direktive den initialen Zustand eines Hosts übersteuern. Gültige Optionen sind: o = UP, d = DOWN und u = UNREACHABLE.

max_check_attempts:

Diese Direktive wird benutzt, um zu definieren, wie oft Icinga den Host-Prüfbefehl wiederholt, wenn er einen anderen als einen OK-Zustand zurückliefert. Bei einem Wert von 1 wird Icinga einen Alarm generieren, ohne den Host erneut zu prüfen. Anmerkung: wenn Sie den Zustand des Hosts nicht prüfen wollen, müssen Sie den Wert trotzdem mindestens auf 1 setzen. Lassen Sie die check_command-Option leer, um die Host-Prüfung zu umgehen.

check_interval:

Diese Direktive wird benutzt, um die Anzahl von "Zeiteinheiten" zwischen regelmäßig geplanten Prüfungen zu definieren. Solange Sie die interval_length-Direktive mit einem Default-Wert von 60 nicht verändert haben, wird diese Zahl Minuten bedeuten. Mehr Informationen zu diesem Wert finden Sie in der check scheduling-Dokumentation.

retry_interval:

Diese Direktive wird benutzt, um die Anzahl von "Zeiteinheiten" zu definieren, die zwischen erneuten Überprüfungen gewartet werden sollen. Erneute Überprüfungen für den Host werden mit dem Wiederholungsintervall eingeplant, wenn dieser in einen nicht-UP-Zustand gewechselt ist. Sobald der Host max_check_attempts-Mal ohne eine Zustandsänderung geprüft wurde, wird die Planung zum "normalen" Wert zurückkehren, der durch den check_interval-Wert angegeben wird. Solange Sie die interval_length-Direktive mit einem Default-Wert von 60 nicht verändert haben, wird diese Zahl Minuten bedeuten. Mehr Informationen zu diesem Wert finden Sie in der check scheduling-Dokumentation.

active_checks_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob aktive Prüfungen (entweder regelmäßig geplant oder nach Bedarf) für diesen Host aktiviert sind oder nicht. Werte: 0 = keine aktiven Host-Prüfungen, 1 = aktive Host-Prüfungen.

passive_checks_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob passive Prüfungen für diesen Host aktiviert sind oder nicht. Werte: 0 = passive Host-Prüfungen deaktivieren, 1 = passive Host-Prüfungen aktivieren

check_period:

Diese Direktive wird benutzt, um den Kurznamen des Zeitfensters anzugeben, in dem aktive Prüfungen für diesen Host ausgeführt werden.

obsess_over_host *:

Diese Direktive legt fest, ob Prüfungen für den Host über ochp_command "verfolgt" werden sollen.

check_freshness *:

Diese Direktive wird benutzt, um festzulegen, ob Frische-Prüfungen (freshness checks) für diesen Host aktiviert sind oder nicht. Werte: 0 = Frische-Prüfungen deaktivieren, 1 = Frische-Prüfungen aktivieren.

freshness_threshold:

Diese Direktive wird benutzt, um den Frische-Schwellwert (freshness threshold) (in Sekunden) für diesen Host festzulegen. Wenn Sie einen Wert von Null für diese Direktive setzen, wird Icinga automatisch einen Frische-Schwellwert festlegen.

event_handler:

Diese Direktive wird benutzt, um den Kurznamen des Befehls anzugeben, der jedes Mal ausgeführt werden soll, sobald ein Statuswechsel für den Host erkannt wird (d.h. er "down" geht oder sich wieder erholt). Lesen Sie die Dokumentation zu Eventhandlern für eine detailliertere Erklärung, wie Scripte zur Behandlung von Ereignissen geschrieben werden. Die maximale Zeit, die ein Eventhandler-Befehl dauern darf, wird durch die event_handler_timeout-Option kontrolliert.

event_handler_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob der Eventhandler für diesen Host aktiviert ist oder nicht. Werte: 0 = Host-Eventhandler deaktivieren, 1 = Host-Eventhandler aktivieren

low_flap_threshold:

Diese Direktive wird benutzt, um den unteren Zustandsänderungsschwellwert zu definieren, der in der Flattererkennung für diesen Host benutzt wird. Mehr Informationen zur Flattererkennung finden Sie hier. Wenn Sie diese Direktive auf 0 setzen, wird der programmweite Wert aus der low_host_flap_threshold-Direktive benutzt.

high_flap_threshold:

Diese Direktive wird benutzt, um den oberen Zustandsänderungsschwellwert zu definieren, der in der Flattererkennung für diesen Host benutzt wird. Mehr Informationen zur Flattererkennung finden Sie hier. Wenn Sie diese Direktive auf 0 setzen, wird der programmweite Wert aus der high_host_flap_threshold-Direktive benutzt.

flap_detection_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob Flattererkennung für diesen Host aktiviert ist. Mehr Informationen zur Flattererkennung finden Sie hier. Werte: 0 = Host-Flattererkennung deaktivieren, 1 = Host-Flattererkennung aktivieren.

flap_detection_options:

Diese Direktive wird benutzt, um festzulegen, welche Host-Zustände die Flattererkennungslogik für diesen Host benutzen wird. Gültige Optionen sind Kombinationen von einem oder mehreren folgender Werte: o = UP-Zustände, d = DOWN-Zustände, u = UNREACHABLE-Zustände.

failure_prediction_enabled:

Diese Direktive wird benutzt, um festzulegen, ob Fehlervorhersage für diesen Host aktiviert ist. Werte: 0 = Fehlervorhersage deaktivieren, 1 = Fehlervorhersage aktivieren.

process_perf_data *:

Diese Direktive wird benutzt, um festzulegen, ob die Verarbeitung von Performance-Daten für diesen Host aktiviert ist. Werte: 0 = Verarbeitung von Performance-Daten deaktiviert, 1 = Verarbeitung von Performance-Daten aktiviert.

retain_status_information:

Diese Direktive wird benutzt, um festzulegen, ob zustandsbezogene Informationen zu diesem Host über Programmneustarts hinweg aufbewahrt wird. Das ist nur sinnvoll, wenn Sie Statusaufbewahrung über die retain_state_information-Direktive aktiviert haben. Werte: 0 = Aufbewahrung von Statusinformationen deaktivieren, 1 = Aufbewahrung von Statusinformationen aktivieren.

retain_nonstatus_information:

Diese Direktive wird benutzt, um festzulegen, ob nicht-zustandsbezogene Informationen zu diesem Host über Programmneustarts hinweg aufbewahrt wird. Das ist nur sinnvoll, wenn Sie Statusaufbewahrung über die retain_state_information-Direktive aktiviert haben. Werte: 0 = Aufbewahrung von nicht-Statusinformationen deaktivieren, 1 = Aufbewahrung von nicht-Statusinformationen aktivieren.

contacts:

Dies ist eine Liste der Kurznamen der Kontakte, die über Probleme (oder Erholungen) dieses Hosts informiert werden sollen. Mehrere Kontakte werden jeweils durch ein Komma voneinander getrennt. Nützlich, wenn Benachrichtigungen nur an ein paar Leute gehen sollen und Sie dafür keine Kontaktgruppen definieren wollen. Sie müssen mindestens einen Kontakt oder eine Kontaktgruppe in jeder Host-Definition angeben, andernfalls wird nie jemand benachrichtigt.

contact_groups:

Dies ist eine Liste der Kurznamen der Kontaktgruppen, die über Probleme (oder Erholungen) dieses Hosts informiert werden sollen. Mehrere Kontaktgruppen werden durch ein Komma voneinander getrennt. Sie müssen mindestens einen Kontakt oder eine Kontaktgruppe in jeder Host-Definition angeben, andernfalls wird nie jemand benachrichtigt.

notification_interval:

Diese Direktive wird benutzt, um die Anzahl von "Zeiteinheiten" anzugeben, die gewartet werden soll, bevor ein Kontakt erneut darüber informiert werden soll, dass dieser Host immer noch "down" oder unerreichbar ist. Solange Sie nicht die interval_length-Direktive auf einen anderen als den Standardwert von 60 verändert haben, bedeutet diese Zahl Minuten. Wenn Sie diesen Wert auf 0 setzen, wird Icinga die Kontakte nicht erneut über Probleme dieses Hosts informieren - nur eine Problembenachrichtigung wird versandt.

first_notification_delay:

Diese Direktive wird benutzt, um die Anzahl von "Zeiteinheiten" anzugeben, die gewartet werden soll, bevor die erste Problembenachrichtigung versandt wird, wenn dieser Host in einen nicht-UP-Zustand wechselt. Solange Sie nicht die interval_length-Direktive auf einen anderen als den Standardwert von 60 verändert haben, bedeutet diese Zahl Minuten. Wenn Sie diesen Wert auf 0 setzen, wird Icinga sofort Benachrichtigungen versenden.

notification_period:

Diese Direktive wird benutzt, um den Kurznamen des Zeitfensters anzugeben, in dem Benachrichtigungen zu Ereignissen dieses Hosts an Kontakte versandt werden. Wenn ein Host zu einer Zeit "down" geht, unerreichbar wird oder sich wieder erholt, die nicht in diesem Zeitfenster liegt, werden keine Benachrichtigungen versandt.

notification_options:

Diese Direktive wird benutzt, um festzulegen, wann Benachrichtigungen für diesen Host versandt werden. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: d = Benachrichtigungen bei einem DOWN-Zustand versenden, u = Benachrichtigungen bei einem UNREACHABLE-Zustand versenden, r = Benachrichtigungen bei Erholungen (OK-Zustand) versenden, f = Benachrichtigungen versenden, wenn der Host mit Flattern anfängt bzw. aufhört und s = Benachrichtigungen versenden, wenn eine geplante Ausfallzeit anfängt oder aufhört. Wenn Sie n (none) als Option angeben, werden keine Host-Benachrichtigungen versandt. Wenn Sie keine Benachrichtigungsoptionen angeben, geht Icinga davon aus, dass Sie Benachrichtigungen zu allen möglichen Zuständen haben möchten. Beispiel: wenn Sie d,r in diesem Feld angeben, werden Benachrichtigungen nur dann versandt, wenn der Host in einen DOWN-Zustand geht und sich wieder von einem DOWN-Zustand erholt.

notifications_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob Benachrichtigungen für diesen Host aktiviert sind oder nicht. Werte: 0 = Host-Benachrichtigungen deaktivieren, 1 = Host-Benachrichtigungen aktivieren.

stalking_options:

Diese Direktive legt fest, für welche Host-Zustände "Verfolgung" (stalking) aktiviert ist. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: o = verfolgen von UP-Zuständen, d = verfolgen von DOWN-Zuständen und u = verfolgen von UNREACHABLE-Zuständen. Mehr Informationen zur Statusverfolgung finden Sie hier.

notes:

Diese Direktive wird benutzt, um optional einen Text mit Informationen zu diesem Host anzugeben. Wenn Sie hier Anmerkungen angeben, werden Sie diese in der extended information-CGI sehen (wenn Sie Informationen zu dem entsprechenden Host ansehen).

notes_url:

Diese Variable wird benutzt, um einen optionalen URL anzugeben, der verwendet werden kann, um weitere Informationen zu diesem Host zu liefern. Wenn Sie einen URL angeben, werden Sie ein rotes Verzeichnis-Icon in den CGIs sehen (wenn Sie Host-Informationen betrachten), das auf den URL verweist, den Sie hier angeben. Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/). Dies kann sehr nützlich sein, wenn Sie detaillierte Informationen zu diesem Host, Notfallkontaktmethoden usw. für anderes Support-Personal zur Verfügung stellen wollen.

action_url:

Diese Direktive wird benutzt, um einen optionalen URL anzugeben, der verwendet werden kann, um weitere Aktionen für diesen Host zu ermöglichen. Wenn Sie einen URL angeben, werden Sie einen roten "Klecks" in den CGIs sehen (wenn Sie Host-Informationen betrachten). Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/).

[Anmerkung] Anmerkung

Seit Icinga 1.0.2 ist es möglich, mehrere URLs für action|notes_url bei Host- und Service-Objektdefinitionen zu anzugeben. Die Syntax ist wie folgt:

notes_url|action_url 'ersteURL' 'zweiteURL' 'dritteURL'

notes_url|action_url nureineURL

Bitte achten Sie darauf, dass mehrere URLs auch gleichzeitig mehrere Icon-Bilder bedeuten. Diese sind hartkodiert, so dass z.B. action|notes.gif zu 1-action|1-notes.gif wird. Stellen Sie sicher, dass diese vorhanden sind. Die letzte URL kann ohne singlequotes angegeben werden und wird dann wie eine einzelne URL betrachtet und verweist auf das normale Icon (action.gif).

icon_image:

Diese Variable wird benutzt, um den Namen eines GIF-, PNG oder JPG-Images anzugeben, das mit diesem Host verbunden werden soll. Dieses Bild wird an verschiedenen Stellen in den CGIs angezeigt. Das Bild wird am besten aussehen, wenn es 40x40 Pixel groß ist. Bilder für Hosts werden im logos/-Unterverzeichnis Ihres HTML-Images-Verzeichnis gesucht (d.h. /usr/local/icinga/share/images/logos).

icon_image_alt:

Diese Variable wird benutzt, um eine optionale Zeichenkette anzugeben, die für den ALT-Tag des Bildes benutzt wird, das durch das <icon_image>-Argument angegeben wurde.

vrml_image:

Diese Direktive wird in Icinga nicht unterstützt.

statusmap_image:

Diese Variable wird benutzt, um den Namen eines Bildes anzugeben, das mit diesem Host im statusmap-CGI verbunden werden soll. Sie können ein JPG-, PNG- oder GIF-Bild angeben, aber wir würden zu einem Bild im GD2-Format raten, weil andere Bildformate zu hohen CPU-Belastungen führen können, wenn die Statusmap generiert wird. PNG-Bilder können mit Hilfe des pngtogd2-Utilitys (das in Thomas Boutell's gd library enthalten ist) ins GD2-Format umgewandelt werden. Die GD2-Bilder werden im unkomprimierten Format erstellt, um die CPU-Belastung zu minimieren, während das Statusmap-CGI das Netzwerkkartenbild erstellt. Das Bild wird am besten aussehen, wenn es 40x40 Pixel groß ist. Sie können diese Option leer lassen, wenn Sie das Statusmap-CGI nicht nutzen. Bilder für Hosts werden im logos/-Unterverzeichnis Ihres HTML-Images-Verzeichnis gesucht (d.h. /usr/local/icinga/share/images/logos).

2d_coords:

Diese Variable wird benutzt, um Koordinaten anzugeben, wenn der Host im statusmap-CGI gezeichnet wird. Koordinaten sollen in positiven Ganzzahlen angegeben werden, weil sie physischen Pixeln im generierten Bild entsprechen. Der Ursprung (0,0) für die Zeichnung ist die linke, obere Ecke des Bildes, das sich in die positive X-Richtung (nach rechts) und in die positive Y-Richtung (nach unten) erstreckt. Die Größe der Icons ist normalerweise etwa 40x40 Pixel (Text benötigt etwas mehr Platz). Die Koordinaten, die Sie angeben, beziehen sich auf die linke, obere Ecke des Icons. Anmerkung: Machen Sie sich keine Sorgen über die maximalen X- und Y-Koordinaten, die Sie benutzen können. Das CGI wird automatisch die maximale Größe des zu erstellenden Bildes aufgrund der größten X- und Y-Koordinaten festlegen, die Sie angegeben haben.

3d_coords:

Diese Direktive wird in Icinga nicht unterstützt.

Hostgruppen-Definition

Beschreibung:

Eine Hostgruppen-Definition wird benutzt, um einen oder mehrere Hosts zu gruppieren, um die Konfiguration mit Objekt-Tricks zu vereinfachen oder für Anzeigezwecke in den CGIs.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define hostgroup{

hostgroup_name hostgroup_name

alias alias

members

hosts

hostgroup_members

hostgroups

notes

note_string

notes_url

url

action_url

url

   

}

Beispieldefinition:

 define hostgroup{
        hostgroup_name          novell-servers
        alias                   Novell Servers
        members                 netware1,netware2,netware3,netware4
        }

Beschreibung der Direktiven:

hostgroup_name:

Diese Direktive wird benutzt, um einen Kurznamen zu definieren, der die Hostgruppe identifiziert.

alias:

Diese Direktive wird benutzt, um einen längeren Namen oder eine Beschreibung zu definieren, der die Hostgruppen identifiziert. Er/sie wird angeboten, damit Sie eine bestimmte Hostgruppe einfacher identifizieren können.

members:

Dies ist eine Liste von Kurznamen der Hosts, die in dieser Gruppe enthalten sein sollen. Mehrere Hostnamen sollten jeweils durch Komma von einander getrennt werden. Diese Direktive kann als Alternative (oder als Zusatz) zu der hostgroups-Direktive in den Host-Definitionen verwendet werden.

hostgroup_members:

Diese optionale Direktive kann genutzt werden, um Hosts aus anderen "sub"-Hostgruppen in diese Hostgruppe aufzunehmen. Geben Sie eine komma-separierte Liste von Kurznamen anderer Hostgruppen an, deren Mitglieder in diese Gruppe aufgenommen werden sollen.

notes:

Diese Direktive wird benutzt, um optional einen Text mit Informationen zu dieser Hostgruppe anzugeben. Wenn Sie hier Anmerkungen angeben, werden Sie diese in der extended information-CGI sehen (wenn Sie Informationen zu der entsprechenden Hostgruppe ansehen).

notes_url:

Diese Variable wird benutzt, um einen optionalen URL anzugeben, der verwendet werden kann, um weitere Informationen zu dieser Hostgruppe zu liefern. Wenn Sie einen URL angeben, werden Sie ein rotes Verzeichnis-Icon in den CGIs sehen (wenn Sie Hostgruppen-Informationen betrachten), das auf den URL verweist, den Sie hier angeben. Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/). Dies kann sehr nützlich sein, wenn Sie detaillierte Infomationen zu dieser Hostgruppe, Notfallkontaktmethoden usw. für anderes Support-Personal zur Verfügung stellen wollen.

action_url:

Diese Direktive wird benutzt, um einen optionalen URL anzugeben, der verwendet werden kann, um weitere Aktionen für diese Hostgruppe zu ermöglichen. Wenn Sie einen URL angeben, werden Sie einen roten "Klecks" in den CGIs sehen (wenn Sie Hostgruppen-Informationen betrachten). Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/).

Service-Definition

Beschreibung:

Eine Service-Definition wird benutzt, um einen "Service" zu identifizieren, der auf einem Host läuft. Der Begriff "Service" wird sehr locker benutzt. Es kann sich um einen realen Service auf einem Host handeln (POP, SMTP, HTTP, etc.) oder eine andere Art von Metrik, die mit dem Host verbunden ist (Antwort auf einen Ping, Anzahl der angemeldeten Benutzer, freier Plattenplatz usw.). Die verschiedenen Parameter einer Service-Definition sind nachfolgend dargestellt.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional. Lesen Sie auf jeden Fall die Anmerkungen zur "contacts"- und "contact_groups"-Direktive.

define service{

host_name host_name

hostgroup_name

hostgroup_name

service_description service_description

display_name

display_name

servicegroups

servicegroup_names

is_volatile

[0|1|2]

check_command command_name

initial_state

[o,w,u,c]

max_check_attempts

#

check_interval

#

retry_interval

#

active_checks_enabled

[0/1]

passive_checks_enabled

[0/1]

check_period timeperiod_name

obsess_over_service

[0/1]

check_freshness

[0/1]

freshness_threshold

#

event_handler

command_name

event_handler_enabled

[0/1]

low_flap_threshold

#

high_flap_threshold

#

flap_detection_enabled

[0/1]

flap_detection_options

[o,w,c,u]

failure_prediction_enabled

[0/1]

process_perf_data

[0/1]

retain_status_information

[0/1]

retain_nonstatus_information

[0/1]

notification_interval

#

first_notification_delay

#

notification_period timeperiod_name

notification_options

[w,u,c,r,f,s]

notifications_enabled

[0/1]

contacts contacts

contact_groups contact_groups

stalking_options

[o,w,u,c]

notes

note_string

notes_url

url

action_url

url

icon_image

image_file

icon_image_alt

alt_string

   

}

Beispieldefinition:

 define service{
        host_name               linux-server
        service_description     check-disk-sda1
        check_command           check-disk!/dev/sda1
        max_check_attempts      5
        check_interval          5
        retry_interval          3
        check_period            24x7
        notification_interval   30
        notification_period     24x7
        notification_options    w,c,r
        contact_groups          linux-admins
        }

Beschreibung der Direktiven:

host_name:

Diese Direktive wird benutzt, um den Kurznamen des/der Hosts anzugeben, auf denen der Service "läuft" bzw. mit dem/denen er verbunden ist. Mehrere Hosts sind jeweils durch Komma von einander zu trennen.

hostgroup_name:

Diese Direktive wird benutzt, um den/die Kurznamen der Hostgruppe(n) anzugeben, auf der/denen der Service "läuft" bzw. mit der/denen er verbunden ist. Mehrere Hostgruppen werden durch Kommata von einander getrennt. Der hostgroup_name kann anstatt oder zusätzlich zur host_name-Direktive benutzt werden.

service_description:

Diese Direktive wird benutzt, um eine Beschreibung des Service zu definieren, die Leerzeichen, Bindestriche und Doppelpunkte enthalten kann (Semikolon, Apostroph und Fragezeichen sollten vermieden werden). Keine zwei Services des gleichen Hosts können die gleiche Beschreibung haben. Services werden eindeutig durch die host_name und service_description-Direktiven identifiziert.

display_name:

Diese Direktive wird benutzt, um einen alternativen Namen zu definieren, der im Web-Interface für diesen Service angezeigt wird. Falls nicht angegeben, wird der Wert aus der service_description-Direktive benutzt. Anmerkung: Die CGIs bis einschließlich Icinga 1.0.1 nutzen diese Option nicht.

servicegroups:

Diese Direktive wird benutzt, um den/die Kurznamen der Servicegruppe(n) anzugeben, zu der/denen der Service gehört. Mehrere Servicegruppen werden durch Kommata von einander getrennt. Diese Direktive kann als Alternative (oder zusätzlich) zur members-Direktive in den servicegroup-Definitionen genutzt werden.

is_volatile:

Diese Direktive wird benutzt, um zu kennzeichnen, dass der Service "sprunghaft" (volatile) ist. Services sind normalerweise nicht sprunghaft. Mehr Informationen zu sprunghaften Services und wie sie sich von normalen Services unterscheiden, finden Sie hier. Werte: 0 = Service ist nicht sprunghaft, 1 = Service ist sprunghaft, 2 = Service ist sprunghaft, respektiert aber die Einstellung der Direktive notification_interval bei erneuten Benachrichtigungen (Option "2" gibt es seit Icinga 1.0.2).

check_command:

Diese Direktive wird benutzt, um den Kurznamen des Befehls anzugeben, mit dem der Zustand des Service geprüft wird. Die maximale Zeit, die der Prüfbefehl laufen darf, wird durch die service_check_timeout-Option kontrolliert.

initial_state:

Als Default nimmt Icinga an, dass sich alle Services im OK-Zustand befinden, wenn es startet. Sie können mit dieser Direktive den initialen Zustand eines Service übersteuern. Gültige Optionen sind: o = OK, w = WARNING, u = UNKNOWN und c = CRITICAL.

max_check_attempts:

Diese Direktive wird benutzt, um zu definieren, wie oft Icinga den Service-Prüfbefehl wiederholt, wenn er einen anderen als einen OK-Zustand zurückliefert. Bei einem Wert von 1 wird Icinga einen Alarm generieren, ohne den Service erneut zu prüfen.

check_interval:

Diese Direktive wird benutzt, um die Anzahl von "Zeiteinheiten" zwischen "regulär" geplanten Prüfungen zu definieren. "Reguläre" Prüfungen sind solche, die stattfinden, wenn sich der Service in einem OK-Zustand befindet oder wenn sich der Service in einem nicht-OK-Zustand befindet, aber mehr als max_check_attemps-mal erneut geprüft wurde. Solange Sie die interval_length-Direktive mit einem Default-Wert von 60 nicht verändert haben, wird diese Zahl Minuten bedeuten. Mehr Informationen zu diesem Wert finden Sie in der check scheduling-Dokumentation.

retry_interval:

Diese Direktive wird benutzt, um die Anzahl von "Zeiteinheiten" zu definieren, die zwischen erneuten Überprüfungen des Service gewartet werden sollen. Erneute Überprüfungen für Services werden mit dem Wiederholungsintervall eingeplant, wenn diese in einen nicht-OK-Zustand gewechselt sind. Sobald der Service max_check_attempts-Mal ohne eine Zustandsänderung geprüft wurde, wird die Planung zum "normalen" Wert zurückkehren, der durch den check_interval-Wert angegeben wird. Solange Sie die interval_length-Direktive mit einem Default-Wert von 60 nicht verändert haben, wird diese Zahl Minuten bedeuten. Mehr Informationen zu diesem Wert finden Sie in der check scheduling-Dokumentation.

active_checks_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob aktive Prüfungen (entweder regelmäßig geplant oder nach Bedarf) für diesen Service aktiviert sind oder nicht. Werte: 0 = keine aktiven Service-Prüfungen, 1 = aktive Service-Prüfungen.

passive_checks_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob passive Prüfungen für diesen Service aktiviert sind oder nicht. Werte: 0 = passive Service-Prüfungen deaktivieren, 1 = passive Service-Prüfungen aktivieren

check_period:

Diese Direktive wird benutzt, um den Kurznamen des Zeitfensters anzugeben, in dem aktive Prüfungen für diesen Service ausgeführt werden.

obsess_over_service *:

Diese Direktive legt fest, ob Prüfungen für den Service über ocsp_command "verfolgt" werden sollen.

check_freshness *:

Diese Direktive wird benutzt, um festzulegen, ob Frische-Prüfungen (freshness checks) für diesen Service aktiviert sind oder nicht. Werte: 0 = Frische-Prüfungen deaktivieren, 1 = Frische-Prüfungen aktivieren.

freshness_threshold:

Diese Direktive wird benutzt, um den Frische-Schwellwert (freshness threshold) (in Sekunden) für diesen Service festzulegen. Wenn Sie einen Wert von Null für diese Direktive setzen, wird Icinga automatisch einen Frische-Schwellwert festlegen.

event_handler:

Diese Direktive wird benutzt, um den Kurznamen des Befehls anzugeben, der jedes Mal ausgeführt werden soll, sobald ein Statuswechsel für den Service erkannt wird (d.h. er in einen nicht-OK-Zustand geht oder sich wieder erholt). Lesen Sie die Dokumentation zu Eventhandlern für eine detailliertere Erklärung, wie Scripte zur Behandlung von Ereignissen geschrieben werden. Die maximale Zeit, die ein Eventhandler-Befehl dauern darf, wird durch die event_handler_timeout-Option kontrolliert.

event_handler_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob der Eventhandler für diesen Service aktiviert ist oder nicht. Werte: 0 = Service-Eventhandler deaktivieren, 1 = Service-Eventhandler aktivieren

low_flap_threshold:

Diese Direktive wird benutzt, um den unteren Zustandsänderungsschwellwert zu definieren, der in der Flattererkennung für diesen Service benutzt wird. Mehr Informationen zur Flattererkennung finden Sie hier. Wenn Sie diese Direktive auf 0 setzen, wird der programmweite Wert aus der low_service_flap_threshold-Direktive benutzt.

high_flap_threshold:

Diese Direktive wird benutzt, um den oberen Zustandsänderungsschwellwert zu definieren, der in der Flattererkennung für diesen Service benutzt wird. Mehr Informationen zur Flattererkennung finden Sie hier. Wenn Sie diese Direktive auf 0 setzen, wird der programmweite Wert aus der high_service_flap_threshold-Direktive benutzt.

flap_detection_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob Flattererkennung für diesen Service aktiviert ist. Mehr Informationen zur Flattererkennung finden Sie hier. Werte: 0 = Service-Flattererkennung deaktivieren, 1 = Service-Flattererkennung aktivieren.

flap_detection_options:

Diese Direktive wird benutzt, um festzulegen, welche Service-Zustände die Flattererkennungslogik für diesen Service benutzen wird. Gültige Optionen sind Kombinationen von einem oder mehreren folgender Werte: o = OK-Zustände, w = WARNING-Zustände, c = CRITICAL-Zustände, u = UNKNOWN-Zustände.

failure_prediction_enabled:

Diese Direktive wird benutzt, um festzulegen, ob Fehlervorhersage für diesen Service aktiviert ist. Werte: 0 = Fehlervorhersage deaktivieren, 1 = Fehlervorhersage aktivieren.

process_perf_data *:

Diese Direktive wird benutzt, um festzulegen, ob die Verarbeitung von Performance-Daten für diesen Service aktiviert ist. Werte: 0 = Verarbeitung von Performance-Daten deaktiviert, 1 = Verarbeitung von Performance-Daten aktiviert.

retain_status_information:

Diese Direktive wird benutzt, um festzulegen, ob zustandsbezogene Informationen zu diesem Service über Programmneustarts hinweg aufbewahrt werden. Das ist nur sinnvoll, wenn Sie Statusaufbewahrung über die retain_state_information-Direktive aktiviert haben. Werte: 0 = Aufbewahrung von Statusinformationen deaktivieren, 1 = Aufbewahrung von Statusinformationen aktivieren.

retain_nonstatus_information:

Diese Direktive wird benutzt, um festzulegen, ob nicht-zustandsbezogene Informationen zu diesem Service über Programmneustarts hinweg aufbewahrt werden. Das ist nur sinnvoll, wenn Sie Status-Beibehaltung über die retain_state_information-Direktive aktiviert haben. Werte: 0 = Aufbewahrung von nicht-Statusinformationen deaktivieren, 1 = Aufbewahrung von nicht-Statusinformationen aktivieren.

notification_interval:

Diese Direktive wird benutzt, um die Anzahl von "Zeiteinheiten" anzugeben, die gewartet werden soll, bevor ein Kontakt erneut darüber informiert werden soll, dass dieser Service immer noch in einem nicht-OK-Zustand ist. Solange Sie nicht die interval_length-Direktive auf einen anderen als den Standardwert von 60 verändert haben, bedeutet diese Zahl Minuten. Wenn Sie diesen Wert auf 0 setzen, wird Icinga die Kontakte nicht erneut über Probleme dieses Service informieren - nur eine Problembenachrichtigung wird versandt.

first_notification_delay:

Diese Direktive wird benutzt, um die Anzahl von "Zeiteinheiten" anzugeben, die gewartet werden soll, bevor die erste Problembenachrichtigung versandt wird, wenn dieser Service in einen nicht-OK-Zustand wechselt. Solange Sie nicht die interval_length-Direktive auf einen anderen als den Standardwert von 60 verändert haben, bedeutet diese Zahl Minuten. Wenn Sie diesen Wert auf 0 setzen, wird Icinga sofort Benachrichtigungen versenden.

notification_period:

Diese Direktive wird benutzt, um den Kurznamen des Zeitfensters anzugeben, in dem Benachrichtigungen zu Ereignissen dieses Service an Kontakte versandt werden. Zu Zeiten, die nicht in diesem Zeitfenster liegen, werden keine Benachrichtigungen versandt.

notification_options:

Diese Direktive wird benutzt, um festzulegen, wann Benachrichtigungen für diesen Service versandt werden. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: w = Benachrichtigungen bei einem WARNING-Zustand versenden, u = Benachrichtigungen bei einem UNKNOWN-Zustand versenden, r = Benachrichtigungen bei Erholungen (OK-Zustand) versenden, f = Benachrichtigungen versenden, wenn der Service mit Flattern anfängt bzw. aufhört und s = Benachrichtigungen versenden, wenn eine geplante Ausfallzeit anfängt oder aufhört. Wenn Sie n (none) als Option angeben, werden keine Service-Benachrichtigungen versandt. Wenn Sie keine Benachrichtigungsoptionen angeben, geht Icinga davon aus, dass Sie Benachrichtigungen zu allen möglichen Zuständen haben möchten. Beispiel: wenn Sie w,r in diesem Feld angeben, werden Benachrichtigungen nur dann versandt, wenn der Service in einen WARNING-Zustand geht und sich wieder von einem WARNING-Zustand erholt.

notifications_enabled *:

Diese Direktive wird benutzt, um festzulegen, ob Benachrichtigungen für diesen Service aktiviert sind oder nicht. Werte: 0 = Service-Benachrichtigungen deaktivieren, 1 = Service-Benachrichtigungen aktivieren.

contacts:

Dies ist eine Liste der Kurznamen der Kontakte, die über Probleme (oder Erholungen) dieses Service informiert werden sollen. Mehrere Kontakte werden jeweils durch Kommata voneinander getrennt. Nützlich, wenn Benachrichtigungen nur an ein paar Leute gehen sollen und Sie dafür keine Kontaktgruppen definieren wollen. Sie müssen mindestens einen Kontakt oder eine Kontaktgruppe in jeder Service-Definition angeben, andernfalls wird nie jemand benachrichtigt.

contact_groups:

Dies ist eine Liste der Kurznamen der Kontaktgruppen, die über Probleme (oder Erholungen) dieses Service informiert werden sollen. Mehrere Kontaktgruppen werden durch Kommata voneinander getrennt. Sie müssen mindestens einen Kontakt oder eine Kontaktgruppe in jeder Service-Definition angeben, andernfalls wird nie jemand benachrichtigt.

stalking_options:

Diese Direktive legt fest, für welche Service-Zustände "Verfolgung" (stalking) aktiviert ist. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: o = verfolgen von OK-Zuständen, w = verfolgen von WARNING-Zuständen, c = verfolgen von CRITICAL-Zuständen und u = verfolgen von UNKNOWN-Zuständen. Mehr Informationen zur Statusverfolgung finden Sie hier.

notes:

Diese Direktive wird benutzt, um optional einen Text mit Informationen zu diesem Service anzugeben. Wenn Sie hier Anmerkungen angeben, werden Sie diese in der extended information-CGI sehen (wenn Sie Informationen zu dem entsprechenden Service ansehen).

notes_url:

Diese Variable wird benutzt, um einen optionalen URL anzugeben, der benutzt werden kann, um weitere Informationen zu diesem Service zu liefern. Wenn Sie einen URL angeben, werden Sie ein rotes Verzeichnis-Icon in den CGIs sehen (wenn Sie Service-Informationen betrachten), das auf den URL verweist, den Sie hier angeben. Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/). Dies kann sehr nützlich sein, wenn Sie detaillierte Informationen zu diesem Service, Notfallkontaktmethoden usw. für anderes Support-Personal zur Verfügung stellen wollen.

action_url:

Diese Direktive wird benutzt, um einen optionalen URL anzugeben, der benutzt werden kann, um weitere Aktionen für diesen Service zu ermöglichen. Wenn Sie einen URL angeben, werden Sie einen roten "Klecks" in den CGIs sehen (wenn Sie Host-Informationen betrachten). Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/).

[Anmerkung] Anmerkung

Seit Icinga 1.0.2 ist es möglich, mehrere URLs für action|notes_url bei Host- und Service-Objektdefinitionen anzugeben. Die Syntax ist wie folgt:

notes_url|action_url 'ersteURL' 'zweiteURL' 'dritteURL'

notes_url|action_url nureineURL

Bitte achten Sie darauf, dass mehrere Urls auch gleichzeitig mehrere Icon-Bilder bedeuten. Diese sind hartkodiert, so dass z.B. action|notes.gif zu 1-action|1-notes.gif wird. Stellen Sie sicher, dass diese vorhanden sind. Die letzte URL kann ohne singlequotes angegeben werden und wird dann wie eine einzelne URL betrachtet und verweist auf das normale Icon (action.gif).

icon_image:

Diese Variable wird benutzt, um den Namen eines GIF-, PNG oder JPG-Images anzugeben, das mit diesem Service verbunden werden soll. Dieses Bild wird an verschiedenen Stellen in den CGIs angezeigt. Das Bild wird am besten aussehen, wenn es 40x40 Pixel groß ist. Bilder für Services werden im logos/-Unterverzeichnis Ihres HTML-Images-Verzeichnis gesucht (d.h. /usr/local/icinga/share/images/logos).

icon_image_alt:

Diese Variable wird benutzt, um eine optionale Zeichenkette anzugeben, die für den ALT-Tag des Bildes benutzt wird, das durch das <icon_image>-Argument angegeben wurde.

Servicegruppen-Definition

Beschreibung:

Eine Servicegruppen-Definition wird benutzt, um einen oder mehrere Services zu gruppieren, um die Konfiguration mit Objekt-Tricks zu vereinfachen oder für Anzeigezwecke in den CGIs.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define servicegroup{

servicegroup_name

servicegroup_name

alias alias

members

services

servicegroup_members

servicegroups

notes

note_string

notes_url

url

action_url

url

   

}

Beispieldefinition:

 define servicegroup{
        servicegroup_name       dbservices
        alias                   Database Services
        members                 ms1,SQL Server,ms1,SQL Server Agent,ms1,SQL DTC
        }

Beschreibung der Direktiven:

servicegroup_name:

Diese Direktive wird benutzt, um einen Kurznamen zu definieren, der die Servicegruppe identifiziert.

alias:

Diese Direktive wird benutzt, um einen längeren Namen oder eine Beschreibung zu definieren, der die Servicegruppen identifiziert. Er/sie wird angeboten, damit Sie ein bestimmte Servicegruppe einfacher identifizieren können.

members:

Dies ist eine Liste von Kurznamen der Services (und der Namen der entsprechenden Hosts), die in dieser Gruppe enthalten sein sollen. Host- und Service-Namen sollten jeweils durch Komma von einander getrennt werden. Diese Direktive kann als Alternative (oder als Zusatz) zu der servicegroups-Direktive in den Service-Definitionen verwendet werden. Das Format der member-Direktive ist wie folgt (beachten Sie, dass ein Host-Name einem Service-Namen/einer Service-Beschreibung vorangestellt werden muss):

members=<host1>,<service1>,<host2>,<service2>,...,<hostn>,<servicen>

Seit Icinga 1.2 ist es möglich, "*" als Wildcard für alle Hosts zu benutzen. Bitte beachten Sie, dass es NICHT möglich ist, Hosts oder Service über ein vorangestelltes "!" auszuschließen.

servicegroup_members:

Diese optionale Direktive kann genutzt werden, um Services aus anderen "sub"-Servicegruppen in diese Servicegruppe aufzunehmen. Geben Sie eine komma-separierte Liste von Kurznamen anderer Servicegruppen an, deren Mitglieder in diese Gruppe aufgenommen werden sollen.

notes:

Diese Direktive wird benutzt, um optional einen Text mit Informationen zu dieser Servicegruppe anzugeben. Wenn Sie hier Anmerkungen angeben, werden Sie diese in der extended information-CGI sehen (wenn Sie Informationen zu der entsprechenden Servicegruppe ansehen).

notes_url:

Diese Variable wird benutzt, um einen optionalen URL anzugeben, der benutzt werden kann, um weitere Informationen zu dieser Servicegruppe zu liefern. Wenn Sie einen URL angeben, werden Sie ein rotes Verzeichnis-Icon in den CGIs sehen (wenn Sie Servicegruppen-Informationen betrachten), das auf den URL verweist, den Sie hier angeben. Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/). Dies kann sehr nützlich sein, wenn Sie detaillierte Infomationen zu dieser Servicegruppe, Notfallkontaktmethoden usw. für anderes Support-Personal zur Verfügung stellen wollen.

action_url:

Diese Direktive wird benutzt, um einen optionalen URL anzugeben, der benutzt werden kann, um weitere Aktionen für diese Servicegruppe zu ermöglichen. Wenn Sie einen URL angeben, werden Sie einen roten "Klecks" in den CGIs sehen (wenn Sie Servicegruppen-Informationen betrachten). Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/).

Kontakt-Definition

Beschreibung:

Eine Kontakt-Definition wird benutzt, um jemanden zu identifizieren, der im Falle eines Problems in Ihrem Netzwerk informiert werden soll. Die verschiedenen Parameter einer Kontakt-Definition werden nachfolgend beschrieben.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define contact{

contact_name

contact_name

alias

alias

contactgroups

contactgroup_names

host_notifications_enabled

[0/1]

service_notifications_enabled

[0/1]

host_notification_period timeperiod_name

service_notification_period timeperiod_name

host_notification_options

[d,u,r,f,s,n]

service_notification_options

[w,u,c,r,f,s,n]

host_notification_commands command_name

service_notification_commands command_name

email

email_address

pager

pager_number or pager_email_gateway

addressx

additional_contact_address

can_submit_commands

[0/1]

retain_status_information

[0/1]

retain_nonstatus_information

[0/1]

   

}

Beispieldefinition:

 define contact{
        contact_name                    jdoe
        alias                           John Doe
        host_notifications_enabled      1
        service_notifications_enabled   1
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,u,r
        service_notification_commands   notify-by-email
        host_notification_commands      host-notify-by-email
        email                           jdoe@localhost.localdomain
        pager                           555-5555@pagergateway.localhost.localdomain
        address1                        xxxxx.xyyy@icq.com
        address2                        555-555-5555
        can_submit_commands             1
        }

Beschreibung der Direktiven:

contact_name:

Diese Direktive wird benutzt, um einen Kurznamen zu definieren, der den Kontakt identifiziert. Er wird in Kontaktgruppen-Definitionen benutzt. Bei korrekter Anwendung wird das $CONTACTNAME$-Makro diesen Wert enthalten.

alias:

Diese Direktive wird benutzt, um einen längeren Namen oder eine Beschreibung zu definieren, der/die den Kontakt identifiziert. Bei korrekter Anwendung wird das $CONTACTALIAS$-Makro diesen Alias/diese Beschreibung enthalten. Falls nicht angegeben, wird der contact_name als Alias verwendet.

contactgroups:

Diese Direktive wird benutzt, um den/die Kurznamen der Kontaktgruppe(n) anzugeben, zu dem/denen der Kontakt gehört. Mehrere Kontaktgruppen werden durch Kommata von einander getrennt. Diese Direktive kann als Alternative (oder zusätzlich) zur members-Direktive in den contactgroup-Definitionen genutzt werden.

host_notifications_enabled:

Diese Direktive wird benutzt, um festzulegen, ob der Kontakt Benachrichtigungen über Host-Probleme und Erholungen bekommt. Werte: 0 = keine Benachrichtigungen versenden, 1 = Benachrichtigungen versenden

service_notifications_enabled:

Diese Direktive wird benutzt, um festzulegen, ob der Kontakt Benachrichtigungen über Service-Probleme und Erholungen bekommt. Werte: 0 = keine Benachrichtigungen versenden, 1 = Benachrichtigungen versenden

host_notification_period:

Diese Direktive wird benutzt, um den Kurznamen des Zeitfensters anzugeben, in dem der Kontakt über Host-Probleme oder Erholungen informiert wird. Sie können dies als "Bereitschafts"-Zeiten dieses Kontakts für Host-Benachrichtigungen ansehen. Lesen Sie die Dokumentation zu Zeitfenstern, um mehr Informationen darüber zu erhalten, wie diese funktionieren und welche potenziellen Probleme durch unsachgemäßen Gebrauch entstehen können.

service_notification_period:

Diese Direktive wird benutzt, um den Kurznamen des Zeitfensters anzugeben, in dem der Kontakt über Service-Probleme oder Erholungen informiert wird. Sie können dies als "Bereitschafts"-Zeiten dieses Kontakts für Service-Benachrichtigungen ansehen. Lesen Sie die Dokumentation zu Zeitfenstern, um mehr Informationen darüber zu erhalten, wie diese funktionieren und welche potenziellen Probleme durch unsachgemäßen Gebrauch entstehen können.

host_notification_commands:

Diese Direktive wird benutzt, um Kurznamen von Befehlen anzugeben, die zur Benachrichtigung von Kontakten über Host-Probleme oder Erholungen benutzt werden. Mehrere Benachrichtigungsbefehle sollten durch Kommata von einander getrennt werden. Alle Benachrichtigungsbefehle werden ausgeführt, wenn der Kontakt informiert werden muss. Die maximale Zeit, die der Benachrichtigungsbefehl laufen darf, wird durch die notification_timeout-Option kontrolliert.

host_notification_options:

Diese Direktive wird benutzt, um die Host-Zustände festzulegen, bei denen Benachrichtigungen an den Kontakt versandt werden. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: d = Benachrichtigungen bei einem DOWN-Zustand versenden, u = Benachrichtigungen bei einem UNREACHABLE-Zustand versenden, r = Benachrichtigungen bei Erholungen (UP-Zustand) versenden, f = Benachrichtigungen versenden, wenn der Host mit Flattern anfängt bzw. aufhört und s = Benachrichtigungen versenden, wenn eine geplante Ausfallzeit anfängt oder aufhört. Wenn Sie n (none) als Option angeben, werden keine Host-Benachrichtigungen versandt.

service_notification_options:

Diese Direktive wird benutzt, um die Service-Zustände festzulegen, bei denen Benachrichtigungen an den Kontakt versandt werden. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: w = Benachrichtigungen bei einem WARNING-Zustand versenden, c = Benachrichtigungen bei einem CRITICAL-Zustand versenden, u = Benachrichtigungen bei einem UNKNOWN-Zustand versenden, r = Benachrichtigungen bei Erholungen (OK-Zustand) versenden, f = Benachrichtigungen versenden, wenn der Service mit Flattern anfängt bzw. aufhört und s = Benachrichtigungen versenden, wenn eine geplante Ausfallzeit anfängt oder aufhört. Wenn Sie n (none) als Option angeben, werden keine Service-Benachrichtigungen versandt.

service_notification_commands:

Diese Direktive wird benutzt, um Kurznamen von Befehlen anzugeben, die zur Benachrichtigung von Kontakten über Service-Probleme oder Erholungen benutzt werden. Mehrere Benachrichtigungsbefehle sollten durch Kommata von einander getrennt werden. Alle Benachrichtigungsbefehle werden ausgeführt, wenn der Kontakt informiert werden muss. Die maximale Zeit, die der Benachrichtigungsbefehl laufen darf, wird durch die notification_timeout-Option kontrolliert.

email:

Diese Direktive wird benutzt, um ein e-Mail-Adresse für den Kontakt zu definieren. Abhängig von Ihren Benachrichtigungsbefehlen kann sie benutzt werden, um eine Alarm-Mail an den Kontakt zu versenden. Bei korrekter Anwendung wird das $CONTACTEMAIL$-Makro diesen Wert enthalten.

pager:

Diese Direktive wird benutzt, um eine Pager-Nummer für den Kontakt zu definieren. Sie kann auch eine e-Mail-Adresse eines Pager-Gateways (z.B. pagejoe@pagenet.com) sein. Abhängig von Ihren Benachrichtigungsbefehlen kann sie benutzt werden, um eine Alarm-Page an den Kontakt zu versenden. Bei korrekter Anwendung wird das $CONTACTPAGER$-Makro diesen Wert enthalten.

addressx:

Adress-Direktiven werden benutzt, um zusätzliche "Adressen" für den Kontakt zu definieren. Diese Adressen können alles sein - Mobiltelefonnummern, Instant-Messaging-Adressen usw. Abhängig von Ihren Benachrichtigungsbefehlen kann sie benutzt werden, um einen Alarm an den Kontakt zu versenden. Bis zu sechs Adressen können mit Hilfe dieser Direktiven definiert werden (address1 bis address6). Das $CONTACTADDRESSx$-Makro wird diesen Wert enthalten.

can_submit_commands:

Diese Direktive wird benutzt, um festzulegen, ob dieser Kontakt über die CGIs externe Befehle an Icinga erteilen kann. Werte: 0 = dem Kontakt die Erteilung von Befehlen verweigern, 1 = dem Kontakt die Erteilung von Befehlen erlauben.

retain_status_information:

Diese Direktive wird benutzt, um festzulegen, ob zustandsbezogene Informationen zu diesem Kontakt über Programmneustarts hinweg aufbewahrt wird. Das ist nur sinnvoll, wenn Sie Statusaufbewahrung über die retain_state_information-Direktive aktiviert haben. Werte: 0 = Aufbewahrung von Statusinformationen deaktivieren, 1 = Aufbewahrung von Statusinformationen aktivieren.

retain_nonstatus_information:

Diese Direktive wird benutzt, um festzulegen, ob nicht-zustandsbezogene Informationen zu diesem Kontakt über Programmneustarts hinweg aufbewahrt wird. Das ist nur sinnvoll, wenn Sie Statusaufbewahrung über die retain_state_information-Direktive aktiviert haben. Werte: 0 = Aufbewahrung von nicht-Statusinformationen deaktivieren, 1 = Aufbewahrung von nicht-Statusinformationen aktivieren.

Kontaktgruppen-Definition

Beschreibung:

Eine Kontaktgruppen-Definition wird benutzt, um einen oder mehrere Kontakte zu gruppieren, um Alarm-/Erholungs-Benachrichtigungen zu versenden.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define contactgroup{

contactgroup_name

contactgroup_name

alias alias

members

contacts

contactgroup_members

contactgroups

   

}

Beispieldefinition:

 define contactgroup{
        contactgroup_name       novell-admins
        alias                   Novell Administrators
        members                 jdoe,rtobert,tzach
        }

Beschreibung der Direktiven:

contactgroup_name:

Diese Direktive wird benutzt, um einen Kurznamen zu definieren, der die Kontaktgruppe identifiziert.

alias:

Diese Direktive wird benutzt, um einen längeren Namen oder eine Beschreibung zu definieren, der die Kontaktgruppe identifiziert.

members:

Dies ist eine Liste von Kurznamen der Kontakte, die in dieser Gruppe enthalten sein sollen. Mehrere Kontaktnamen sollten jeweils durch Komma von einander getrennt werden. Diese Direktive kann als Alternative (oder als Zusatz) zu der contactgroups-Direktive in den Kontakt-Definitionen verwendet werden.

contactgroup_members:

Diese optionale Direktive kann genutzt werden, um Kontakte aus anderen "sub"-Kontaktgruppen in diese Kontaktgruppe aufzunehmen. Geben Sie eine komma-separierte Liste von Kurznamen anderer Kontaktgruppen an, deren Mitglieder in diese Gruppe aufgenommen werden sollen.

Zeitfenster-Definition (timeperiod)

Beschreibung:

Ein Zeitfenster ist eine Liste von Zeiten an verschiedenen Tagen, die als "gültige" Zeiten für Benachrichtigungen und Service-Prüfungen angesehen werden. Es besteht aus Zeitbereichen für jeden Tag der Woche. Verschiedene Ausnahmen zu den normalen wöchentlichen Zeiten werden unterstützt, u.a.: bestimmte Wochentage, bestimmte Tage eines Monats, Tage eines bestimmten Monats und Kalendertage.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define timeperiod{

timeperiod_name

timeperiod_name

alias alias

[weekday]

timeranges

[exception]

timeranges

exclude

[timeperiod1,timeperiod2,...,timeperiodn]

   

}

Beispiel-Definitionen:

 define timeperiod{
        timeperiod_name         nonworkhours
        alias                   Non-Work Hours
        sunday                  00:00-24:00                     ; jeder Sonntag jeder Woche
        monday                  00:00-09:00,17:00-24:00         ; jeder Montag jeder Woche
        tuesday                 00:00-09:00,17:00-24:00         ; jeder Dienstag jeder Woche
        wednesday               00:00-09:00,17:00-24:00         ; jeder Mittwoch jeder Woche
        thursday                00:00-09:00,17:00-24:00         ; jeder Donnerstag jeder Woche
        friday                  00:00-09:00,17:00-24:00         ; jeder Freitag jeder Woche
        saturday                00:00-24:00                     ; jeder Samstag jeder Woche
        }
 define timeperiod{
        timeperiod_name         misc-single-days
        alias                   Misc Single Days
        1999-01-28              00:00-24:00             ; 28. Januar 1999
        monday 3                00:00-24:00             ; 3. Montag im Monat
        day 2                   00:00-24:00             ; 2. Tag im Monat
        february 10             00:00-24:00             ; 10. Februar im Jahr
        february -1             00:00-24:00             ; letzter Tag im Februar
        friday -2               00:00-24:00             ; vorletzer Freitag im Monat
        thursday -1 november    00:00-24:00             ; letzter Donnerstag im November
        }
 define timeperiod{
        timeperiod_name         misc-date-ranges
        alias                   Misc Date Ranges
        2007-01-01 - 2008-02-01         00:00-24:00             ; 1. Januar 2007 bis zum 1. Februar 2008
        monday 3 - thursday 4           00:00-24:00             ; 3. Montag bis 4. Donnerstag
        day 1 - 15                      00:00-24:00             ; 1. bis 15. Tag
        day 20 - -1                     00:00-24:00             ; 20. Tag bis Monatsende
        july 10 - 15                    00:00-24:00             ; 10. - 15. Juli
        april 10 - may 15               00:00-24:00             ; 10. April bis zum 15. Mai
        tuesday 1 april - friday 2 may  00:00-24:00             ; 1. Dienstag im April
                                                                ; bis zum 2. Freitag im Mai
        }
 define timeperiod{
        timeperiod_name         misc-skip-ranges
        alias                   Misc Skip Ranges
        2007-01-01 - 2008-02-01 / 3             00:00-24:00     ; jeder dritte Tag vom 1. Januar 2008 bis zum 1. Februar 2008
        2008-04-01 / 7                          00:00-24:00     ; jeder 7. Tag ab dem 1. April 2008 (ohne Endedatum)
        monday 3 - thursday 4 / 2               00:00-24:00     ; jeder zweite Tag vom 3. Montag bis zum 4. Donnerstag des Monats
        day 1 - 15 / 5                          00:00-24:00     ; jeder 5. Tag vom 1. bis zum 15. Tag des Monats
        july 10 - 15 / 2                        00:00-24:00     ; jeder zweite Tag vom 10. Juli bis zum 15.Juli
        tuesday 1 april - friday 2 may / 6      00:00-24:00     ; jeder sechste Tag vom 1. Dienstag im April 
                                                                ; bis zum 2. Freitag im Mai
        }

Beschreibung der Direktiven:

timeperiod_name:

Diese Direktive ist der Kurzname, der benutzt wird, um das Zeitfenster zu identifizieren.

alias:

Diese Direktive ist ein längerer Name oder eine Beschreibung zur Identifizierung des Zeitfensters.

[weekday]:

Die Wochentags-Direktiven ("sunday" bis "saturday") sind komma-separierte Listen von Zeitbereichen, die "gültige" Zeiten für einen bestimmten Tag der Woche sind. Beachten Sie, dass es sieben verschiedene Tage gibt, für die Sie Zeitbereiche angeben können ("Sunday" bis "Saturday"). Jeder Zeitbereich hat die Form HH:MM-HH:MM, wobei die Stunden in einem 24-Stunden-Format angegeben werden. Wenn Sie einen kompletten Tag aus dem Zeitfenster ausschließen wollen, dann geben Sie ihn einfach nicht an.

[exception]:

Sie können verschiedene Arten von Ausnahmen zum Standard-Wochentagsplan angeben. Ausnahmen können eine Reihe von verschiedenen Formen annehmen, u.a. einzelne Tage eines bestimmten oder jeden Monats, einzelne Wochentage eines Monats oder einzelner Kalenderdaten. Sie können auch einen Bereich von Tagen/Daten und sogar bestimmte Intervalle überspringen, um Funktionalitäten wie "alle drei Tage zwischen diesen Daten" zu erreichen. Statt alle möglichen von Ausnahmen anzugeben, zeigen wir Ihnen anhand der o.g. Beispieldefinitionen, was möglich ist. :-) Wochentage und verschiedene Arten von Ausnahmen haben alle verschiedene Vorrangebenen, so dass es wichtig ist zu verstehen, wie sie sich gegenseitig beeinflussen. Mehr Informationen dazu finden Sie in der Dokumentation zu Zeitfenstern.

exclude:

Diese Direktive wird benutzt, um die Kurznamen von anderen Zeitfenstern abzugeben, deren Zeitbereiche in diesem Zeitfenster ausgeschlossen werden sollen. Mehrere Zeitfensternamen sind durch Kommata von einander zu trennen.

Befehls-Definition (command)

Beschreibung:

Eine Befehls-Definition ist genau das. Sie definiert einen Befehl. Befehle, die definiert werden können, umfassen u.a. Service-Prüfungen, Host-Benachrichtigungen und Host-Eventhandler. Befehls-Definitionen können Makros enthalten, aber Sie müssen sicherstellen, dass Sie nur solche Makros verwenden, die unter den gegebenen Umständen "gültig" sind. Mehr Informationen dazu, welche Makros verfügbar und wann sie "gültig" sind, finden Sie hier. Die verschiedenen Argumente einer Befehls-Definition sehen Sie nachfolgend.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define command{

command_name

command_name

command_line

command_line

   

}

Beispieldefinition:

 define command{
        command_name    check_pop
        command_line    /usr/local/icinga/libexec/check_pop -H $HOSTADDRESS$    
        }

Beschreibung der Direktiven:

command_name:

Diese Direktive ist der Kurzname, der zur Identifizierung des Befehls benutzt wird. Er wird u.a. in Kontakt-, Host- und Service-Definitionen (in notification-, check-, und event handler-Direktiven) verwendet.

command_line:

Diese Direktive wird benutzt, um zu definieren, was wirklich durch Icinga ausgeführt wird, wenn der Befehl für Service- oder Host-Prüfungen, Benachrichtigungen oder Eventhandler benutzt wird. Vor der Ausführung der Kommandozeile werden alle gültigen Makros durch die entsprechenden Werte ersetzt. Lesen Sie die Dokumentation, um festzustellen, welche verschiedenen Makros Sie benutzen können. Beachten Sie, dass die Kommandozeile nicht von Anführungszeichen eingeschlossen wird. Achten Sie auch darauf, dass Sie bei der Übergabe eines Dollarzeichens ($) ein weiteres Dollarzeichen zur Maskierung benutzen müssen (aus bar$foo muss bar$$foo werden).

ANMERKUNG: Sie dürfen kein Semikolon (;) in der command_line-Direktive einsetzen, weil alles danach als Kommentar angesehen wird. Sie können diese Begrenzung umgehen, indem Sie eines der $USER$ -Makros in Ihrem resource file mit einem Semikolon füllen und dann in der command_line-Direktive auf das entsprechende $USER$-Makro verweisen.

Wenn Sie während der Laufzeit Parameter an Befehle übergeben wollen, können Sie die $ARGn$-Makros in der command_line-Direktive der Befehlsdefinition benutzen und in den Objektdefinitions-Direktiven (Host-Prüfbefehl, Service-Eventhandler, usw.), die auf den Befehl verweisen, einzelne Argumente durch Ausrufezeichen (!) vom Befehlsnamen (und von einander) trennen. Mehr Informationen, wie Argumente in Befehlsdefinitionen während der Laufzeit verarbeitet werden, finden Sie in der Dokumentation zu Makros.

Service-Abhängigkeits-Definition (servicedependency)

Beschreibung:

Service-Abhängigkeiten sind ein fortgeschrittenes Feature von Icinga, das es Ihnen erlaubt, Benachrichtungen und aktive Prüfungen von Services in Abhängigkeit vom Status eines oder mehrerer Services zu unterdrücken. Service-Abhängigkeiten sind optional und zielen hauptsächlich auf fortgeschrittene Benutzer mit komplizierten Überwachungsumgebungen. Mehr Informationen, wie Service-Abhängigkeiten arbeiten (lesen Sie dies!), finden Sie hier.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional. Trotz allem müssen Sie mindestens ein Kriterium angeben, damit die Definition von Nutzen ist.

define servicedependency{

dependent_host_name

host_name

dependent_hostgroup_name

hostgroup_name

dependent_service_description service_description

host_name host_name

hostgroup_name

hostgroup_name

service_description service_description

inherits_parent

[0/1]

execution_failure_criteria

[o,w,u,c,p,n]

notification_failure_criteria

[o,w,u,c,p,n]

dependency_period

timeperiod_name

   

}

Beispieldefinition:

 define servicedependency{
        host_name                       WWW1
        service_description             Apache Web Server
        dependent_host_name             WWW1
        dependent_service_description   Main Web Site
        execution_failure_criteria      n
        notification_failure_criteria   w,u,c
        }

Beschreibung der Direktiven:

dependent_host:

Diese Direktive wird benutzt, um den/die Kurznamen des/der Hosts anzugeben, auf dem der abhängige Service "läuft" oder mit dem er verbunden ist. Mehrere Hosts werden durch Kommata von einander getrennt. Bleibt die Direktive leer, so kann dadurch eine "same host"-Abhängigkeit erstellt werden.

dependent_hostgroup:

Diese Direktive wird benutzt, um den/die Kurznamen der Hostgruppe(n) anzugeben, auf der/denen der abhängige Service "läuft" oder mit dem er verbunden ist. Mehrere Hostgruppen werden durch Kommata von einander getrennt. Die dependent_hostgroup-Direktive kann statt der (oder zusätzlich zur) dependent_host-Direktive benutzt werden.

dependent_service_description:

Diese Direktive wird benutzt, um die Beschreibung des abhängigenService anzugeben.

host_name:

Diese Direktive wird benutzt, um den/die Kurznamen des/der Hosts anzugeben, auf dem/denen der Service "läuft" oder mit dem/denen er verbunden ist, von dem "es" abhängt (auch als Master-Service bezeichnet). Mehrere Hosts werden durch Kommata von einander getrennt.

hostgroup_name:

Diese Direktive wird benutzt, um den/die Kurznamen der Hostgruppe(n) anzugeben, auf der/denen der Service "läuft" oder mit der/denen er verbunden ist, von dem "es" abhängt (auch als Master-Service bezeichnet). Mehrere Hostgruppen werden durch Kommata von einander getrennt. Der hostgroup_name kann statt oder zusätzlich zur host_name-Direktive benutzt werden.

service_description:

Diese Direktive wird benutzt, um die Beschreibung des Service anzugeben, von dem "es" abhängt (auch als Master-Service bezeichnet).

inherits_parent:

Diese Direktive gibt an, ob die abhängige Definition Abhängigkeiten von dem Service erbt, von dem sie abhängt (auch als Master-Service bezeichnet). In anderen Worten, wenn der Master-Service von anderen Services abhängt und eine der Abhängigkeiten fehlschlägt, dann wird auch diese Abhängigkeit fehlschlagen.

execution_failure_criteria:

Diese Direktive wird benutzt, um die Kriterien festzulegen, wann der abhängige Service nicht aktiv geprüft werden soll. Wenn der Master-Service in einem der Zustände ist, die wir angeben, wird der abhängige Service nicht aktiv geprüft. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte (mehrere Werte werden durch Kommata von einander getrennt): o = fehlschlagen bei einem OK-Zustand, w = fehlschlagen bei einem WARNING-Zustand, u = fehlschlagen bei einem UNKNOWN-Zustand, c = fehlschlagen bei einem CRITICAL-Zustand und p = fehlschlagen bei einem PENDING-Zustand (d.h. der Service wurde bisher noch nie geprüft). Wenn Sie n (none) als Option angeben, wird die Ausführungsabhängigkeit nie fehlschlagen und die Prüfungen des abhängigen Service werden immer erfolgen (falls andere Bedingungen das erlauben). Beispiel: wenn Sie o,c,u in diesem Feld angeben, dann wird der abhängige Service nicht aktiv geprüft, wenn der Master-Service sich in einem OK-, CRITICAL- oder UNKNOWN-Zustand befindet.

notification_failure_criteria:

Diese Direktive wird benutzt, um die Kriterien festzulegen, wann keine Benachrichtigungen für den abhängigen Service versandt werden sollen. Wenn der Master-Service in einem der Fehler-Zustände ist, die wir angeben, werden keine Benachrichtigungen für den abhängigen Service an die Kontakte versandt. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: o = fehlschlagen bei einem OK-Zustand, w = fehlschlagen bei einem WARNING-Zustand, u = fehlschlagen bei einem UNKNOWN-Zustand, c = fehlschlagen bei einem CRITICAL-Zustand und p = fehlschlagen bei einem PENDING-Zustand (d.h. der Service wurde bisher noch nie geprüft). Wenn Sie n (none) als Option angeben, wird die Benachrichtigungsabhängigkeit nie fehlschlagen und die Benachrichtungen für den abhängigen Service werden immer erfolgen. Beispiel: wenn Sie w in diesem Feld angeben, dann werden die Benachrichtigungen für den abhängigen Service nicht versandt, wenn der Master-Service sich in einem WARNING-Zustand befindet.

dependency_period:

Diese Direktive wird benutzt, um den Kurznamen eines Zeitfensters anzugeben, in welchem diese Abhängigkeit gültig ist. Wenn diese Direktive nicht angegeben wird, ist die Abhängigkeit zu allen Zeiten gültig.

Serviceeskalations-Definition

Beschreibung:

Serviceeskalationen sind komplett optional und werden benutzt, um Benachrichtigungen für einen bestimmten Service zu eskalieren. Mehr Informationen, wie Eskalationen arbeiten, finden Sie hier.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define serviceescalation{

host_name host_name

hostgroup_name

hostgroup_name

servicegroup_name

servicegroup_name

service_description service_description

contacts contacts

contact_groups contactgroup_name

first_notification

#

last_notification

#

notification_interval

#

escalation_period

timeperiod_name

escalation_options

[w,u,c,r]

escalation_condition

<condition> ( [ & / | ] <condition> )*

first_warning_notification

#

last_warning_notification

#

first_critical_notification

#

last_critical_notification

#

first_unknown_notification

#

last_unknown_notification

#

   

}

Beispieldefinition:

 define serviceescalation{
        host_name               nt-3
        service_description     Processor Load
        first_notification      4
        last_notification       0
        notification_interval   30
        contact_groups          all-nt-admins,themanagers
        }

Beschreibung der Direktiven:

host_name:

Diese Direktive wird benutzt, um den/die Kurznamen des/der Hosts anzugeben, für den die Service-Eskalation gilt oder mit dem/denen er verbunden ist.

hostgroup_name:

Diese Direktive wird benutzt, um den/die Kurznamen der Hostgruppen anzugeben, für den die Service-Eskalation gilt oder mit der/denen er verbunden ist. Mehrere Hostgruppen werden durch Kommata von einander getrennt. Der hostgroup_name kann statt oder zusätzlich zur host_name-Direktive benutzt werden.

servicegroup_name:

Diese Direktive wird benutzt, um den/die Kurznamen der Servicegruppen anzugeben, für den die Service-Eskalation gilt oder mit der/denen er verbunden ist. Mehrere Servicegruppen werden durch Kommata von einander getrennt. Der servicegroup_name kann statt oder zusätzlich zur service_name-Direktive benutzt werden.

service_description:

Diese Direktive wird benutzt, um die Beschreibung des Service zu identifizieren, auf den die Eskalation zutreffen soll.

first_notification:

Diese Direktive ist eine Zahl, die die erste Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 3 setzen, dann wird diese Eskalation nur dann benutzt, wenn der Service lang genug in einem nicht-OK-Zustand ist, damit eine dritte Benachrichtigung versandt wird.

last_notification:

Diese Direktive ist eine Zahl, die die letzte Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 5 setzen, dann wird diese Eskalation nicht benutzt, wenn mehr als fünf Benachrichtigungen für den Service versandt werden. Wenn der Wert auf Null gesetzt wird, wird dieser Eskalationseintrag immer benutzt (unabhängig davon, wie viele Benachrichtigungen versandt werden.)

contacts:

Dies ist eine Liste von Kurznamen der Kontakte, die informiert werden sollen, wenn es Probleme (oder Erholungen) für diesen Service gibt. Mehrere Kontakte werden durch Kommata von einander getrennt. Das ist nützlich, wenn Sie Benachrichtigungen nur an ein paar Leute verschicken wollen und keine Kontaktgruppen definieren wollen. Sie müssen mindestens einen Kontakt oder eine Kontaktgruppe in jeder Serviceeskalations-Definition angeben.

contact_groups:

Dies ist eine Liste von Kurznamen der Kontaktgruppen, die informiert werden sollen, wenn die Service-Benachrichtigung eskaliert. Mehrere Kontaktgruppen werden durch Kommata von einander getrennt. Sie müssen mindestens einen Kontakt oder eine Kontaktgruppe in jeder Serviceeskalations-Definition angeben.

notification_interval:

Diese Direktive wird benutzt, um das Intervall festzulegen, in dem Benachrichtigungen versandt werden, wenn diese Eskalation gültig ist. Wenn Sie einen Wert von 0 für dieses Intervall angeben, wird Icinga die erste Benachrichtigung versenden, wenn diese Eskalation gültig wird, dann aber verhindern, dass weitere Benachrichtigungen versandt werden. Benachrichtigungen werden wieder versandt, bis sich der Host erholt. Dies ist nützlich, wenn Sie nach einer bestimmten Zeit keine weiteren Benachrichtigungen versenden wollen. Anmerkung: Wenn mehrere Eskalationseinträge eines Hosts für ein oder mehr Benachrichtigungsbereiche überlappen, wird das kürzeste Benachrichtigungsintervall aller Eskalationseinträge benutzt.

escalation_period:

Diese Direktive wird benutzt, um den Kurznamen des Zeitfensters anzugeben, in dem diese Eskalation gültig ist. Wenn diese Direktive nicht angegeben wird, ist diese Eskalation zu allen Zeiten gültig.

escalation_options:

Diese Direktive wird benutzt, um die Kriterien festzulegen, wann diese Service-Eskalation benutzt wird. Diese Eskalation wird nur benutzt, wenn der Service in einem der Zustände ist, die in dieser Direktive angeben werden. Wenn diese Direktive nicht in einer Service-Eskalation angegeben wird, ist die Eskalation für alle Service-Zustände gültig. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: r = eskalieren bei einem OK-(Erholungs)-Zustand, w = eskalieren bei einem WARNING-Zustand, u = eskalieren bei einem UNKNOWN-Zustand, und c = eskalieren bei einem CRITICAL-Zustand. Beispiel: wenn Sie w in diesem Feld angeben, dann wird die Eskalation nur benutzt, wenn sich der Service in einem WARNING-Zustand befindet.

escalation_condition:

Diese Direktive ist ab Icinga 1.0.1 verfügbar. Nähere Einzelheiten finden Sie hier.

first_warning_notification:

Diese Direktive ist eine Zahl, die die erste WARNING-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 3 setzen, dann wird diese Eskalation nur dann benutzt, wenn der Service lang genug in einem nicht-OK-Zustand ist, damit eine dritte WARNING-Benachrichtigung versandt wird. Diese Direktive ist ab Icinga 1.0.2 verfügbar.

last_warning_notification:

Diese Direktive ist eine Zahl, die die letzte WARNING-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 5 setzen, dann wird diese Eskalation nicht benutzt, wenn mehr als fünf WARNING-Benachrichtigungen für den Service versandt werden. Wenn der Wert auf Null gesetzt wird, wird dieser Eskalationseintrag immer benutzt (unabhängig davon, wie viele Benachrichtigungen versandt werden). Diese Direktive ist ab Icinga 1.0.2 verfügbar.

first_critical_notification:

Diese Direktive ist eine Zahl, die die erste CRITICAL-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 3 setzen, dann wird diese Eskalation nur dann benutzt, wenn der Service lang genug in einem nicht-OK-Zustand ist, damit eine dritte CRITICAL-Benachrichtigung versandt wird. Diese Direktive ist ab Icinga 1.0.2 verfügbar.

last_critical_notification:

Diese Direktive ist eine Zahl, die die letzte CRITICAL-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 5 setzen, dann wird diese Eskalation nicht benutzt, wenn mehr als fünf CRITICAL-Benachrichtigungen für den Service versandt werden. Wenn der Wert auf Null gesetzt wird, wird dieser Eskalationseintrag immer benutzt (unabhängig davon, wie viele Benachrichtigungen versandt werden). Diese Direktive ist ab Icinga 1.0.2 verfügbar.

first_unknown_notification:

Diese Direktive ist eine Zahl, die die erste UNKNOWN-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 3 setzen, dann wird diese Eskalation nur dann benutzt, wenn der Service lang genug in einem nicht-OK-Zustand ist, damit eine dritte UNKNOWN-Benachrichtigung versandt wird. Diese Direktive ist ab Icinga 1.0.2 verfügbar.

last_unknown_notification:

Diese Direktive ist eine Zahl, die die letzte UNKNOWN-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 5 setzen, dann wird diese Eskalation nicht benutzt, wenn mehr als fünf UNKNOWN-Benachrichtigungen für den Service versandt werden. Wenn der Wert auf Null gesetzt wird, wird dieser Eskalationseintrag immer benutzt (unabhängig davon, wie viele Benachrichtigungen versandt werden). Diese Direktive ist ab Icinga 1.0.2 verfügbar.

Host-Abhängigkeits-Definition (hostdependency)

Beschreibung:

Host-Abhängigkeiten sind ein fortgeschrittenes Feature von Icinga, das es Ihnen erlaubt, Benachrichtungen von Hosts in Abhängigkeit vom Status eines oder mehrerer Hosts zu unterdrücken. Host-Abhängigkeiten sind optional und zielen hauptsächlich auf fortgeschrittene Benutzer mit komplizierten Überwachungsumgebungen. Mehr Informationen, wie Host-Abhängigkeiten arbeiten (lesen Sie dies!), finden Sie hier.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define hostdependency{

dependent_host_name

host_name

dependent_hostgroup_name

hostgroup_name

host_name host_name

hostgroup_name

hostgroup_name

inherits_parent

[0/1]

execution_failure_criteria

[o,d,u,p,n]

notification_failure_criteria

[o,d,u,p,n]

dependency_period

timeperiod_name

   

}

Beispieldefinition:

 define hostdependency{
        host_name                       WWW1
        dependent_host_name             DBASE1
        notification_failure_criteria   d,u
        }

Beschreibung der Direktiven:

dependent_host_name:

Diese Direktive wird benutzt, um den/die Kurznamen des/der abhängigenHosts zu identifizieren. Mehrere Hosts werden durch Kommata von einander getrennt.

dependent_hostgroup_name:

Diese Direktive wird benutzt, um den/die Kurznamen der abhängigenHostgruppe(n) zu identifizieren. Mehrere Hostgruppen werden durch Kommata von einander getrennt. Der dependent_hostgroup_name kann statt oder zusätzlich zur dependent_host_name-Direktive benutzt werden.

host_name:

Diese Direktive wird benutzt, um den/die Kurznamen des/der Hosts anzugeben, von dem "es" abhängt (auch als Master-Host bezeichnet). Mehrere Hosts werden durch Kommata von einander getrennt.

hostgroup_name:

Diese Direktive wird benutzt, um den/die Kurznamen der Hostgruppe(n) anzugeben, von dem "es" abhängt (auch als Master-Host bezeichnet). Mehrere Hostgruppen werden durch Kommata von einander getrennt. Der hostgroup_name kann statt oder zusätzlich zur host_name-Direktive benutzt werden.

inherits_parent:

Diese Direktive gibt an, ob die abhängige Definition Abhängigkeiten von dem Host erbt, von dem sie abhängt (auch als Master-Host bezeichnet). In anderen Worten, wenn der Master-Host von anderen Hosts abhängt und eine der Abhängigkeiten fehlschlägt, dann wird auch diese Abhängigkeit fehlschlagen.

execution_failure_criteria:

Diese Direktive wird benutzt, um die Kriterien festzulegen, wann der abhängige Host nicht aktiv geprüft werden soll. Wenn der Master-Host in einem der Zustände ist, die wir angeben, wird der abhängige Host nicht aktiv geprüft. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte (mehrere Werte werden durch Kommata von einander getrennt): o = fehlschlagen bei einem UP-Zustand, u = fehlschlagen bei einem UNREACHABLE-Zustand und p = fehlschlagen bei einem PENDING-Zustand (d.h. der Host wurde bisher noch nie geprüft). Wenn Sie n (none) als Option angeben, wird die Ausführungsabhängigkeit nie fehlschlagen und die Prüfungen des abhängigen Host werden immer erfolgen (falls andere Bedingungen das erlauben). Beispiel: wenn Sie u,d in diesem Feld angeben, dann wird der abhängige Host nicht aktiv geprüft, wenn der Master-Service sich in einem UNREACHABLE- oder DOWN-Zustand befindet.

notification_failure_criteria:

Diese Direktive wird benutzt, um die Kriterien festzulegen, wann keine Benachrichtigungen für den abhängigen Host versandt werden sollen. Wenn der Master-Host in einem der Fehler-Zustände ist, die wir angeben, werden keine Benachrichtigungen für den abhängigen Host an die Kontakte versandt. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: o = fehlschlagen bei einem UP-Zustand, d = fehlschlagen bei einem DOWN-Zustand, u = fehlschlagen bei einem UNREACHABLE-Zustand, und p = fehlschlagen bei einem PENDING-Zustand (d.h. der Host wurde bisher noch nie geprüft). Wenn Sie n (none) als Option angeben, wird die Benachrichtigungsabhängigkeit nie fehlschlagen und die Benachrichtungen für den abhängigen Host werden immer erfolgen. Beispiel: wenn Sie d in diesem Feld angeben, dann werden die Benachrichtigungen für den abhängigen Host nicht versandt, wenn der Master-Host sich in einem DOWN-Zustand befindet.

dependency_period:

Diese Direktive wird benutzt, um den Kurznamen eines Zeitfensters anzugeben, in welchem diese Abhängigkeit gültig ist. Wenn diese Direktive nicht angegeben wird, ist die Abhängigkeit zu allen Zeiten gültig.

Host-Eskalations-Definition

Beschreibung:

Host-Eskalationen sind komplett optional und werden benutzt, um Benachrichtigungen für einen bestimmten Host zu eskalieren. Mehr Informationen, wie Eskalationen arbeiten, finden Sie hier.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define hostescalation{

host_name

host_name

hostgroup_name

hostgroup_name

contacts contacts

contact_groups contactgroup_name

first_notification

#

last_notification

#

notification_interval

#

escalation_period

timeperiod_name

escalation_options

[d,u,r]

escalation_condition

<condition> ( [ & / | ] <condition> )*

first_down_notification

#

last_down_notification

#

first_unreachable_notification

#

last_unreachable_notification

#

   

}

Beispieldefinition:

 define hostescalation{
        host_name               router-34
        first_notification      5
        last_notification       8
        notification_interval   60
        contact_groups          all-router-admins
        }

Beschreibung der Direktiven:

host_name:

Diese Direktive wird benutzt, um den/die Kurznamen des/der Hosts anzugeben, für den die Eskalation gilt.

hostgroup_name:

Diese Direktive wird benutzt, um den/die Kurznamen der Hostgruppen anzugeben, für den die Eskalation gilt. Mehrere Hostgruppen werden durch Kommata von einander getrennt. Wenn diese Direktive benutzt wird, trifft die Eskalation auf alle Hosts zu, die Mitglied der angegebenen Hostgruppe(n) sind.

first_notification:

Diese Direktive ist eine Zahl, die die erste Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 3 setzen, dann wird diese Eskalation nur dann benutzt, wenn der Host lang genug "down" oder unerreichbar ist, damit eine dritte Benachrichtigung versandt wird.

last_notification:

Diese Direktive ist eine Zahl, die die letzte Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 5 setzen, dann wird diese Eskalation nicht benutzt, wenn mehr als fünf Benachrichtigungen für den Host versandt werden. Wenn der Wert auf Null gesetzt wird, wird dieser Eskalationseintrag immer benutzt (unabhängig davon, wie viele Benachrichtigungen versandt werden.)

contacts:

Dies ist eine Liste von Kurznamen der Kontakte, die informiert werden sollen, wenn es Probleme (oder Erholungen) für diesen Host gibt. Mehrere Kontakte werden durch Kommata von einander getrennt. Das ist nützlich, wenn Sie Benachrichtigungen nur an ein paar Leute verschicken wollen und keine Kontaktgruppen definieren wollen. Sie müssen mindestens einen Kontakt oder eine Kontaktgruppe in jeder Hosteskalations-Definition angeben.

contact_groups:

Dies ist eine Liste von Kurznamen der Kontaktgruppen, die informiert werden sollen, wenn die Host-Benachrichtigung eskaliert. Mehrere Kontaktgruppen werden durch Kommata von einander getrennt. Sie müssen mindestens einen Kontakt oder eine Kontaktgruppe in jeder Hosteskalations-Definition angeben.

notification_interval:

Diese Direktive wird benutzt, um das Intervall festzulegen, in dem Benachrichtigungen versandt werden, wenn diese Eskalation gültig ist. Wenn Sie einen Wert von 0 für dieses Intervall angeben, wird Icinga die erste Benachrichtigung versenden, wenn diese Eskalation gültig wird, dann aber verhindern, dass weitere Benachrichtigungen versandt werden. Benachrichtigungen werden wieder versandt, bis sich der Host erholt. Dies ist nützlich, wenn Sie nach einer bestimmten Zeit keine weiteren Benachrichtigungen versenden wollen. Anmerkung: Wenn mehrere Eskalationseinträge eines Hosts für ein oder mehr Benachrichtungsbereiche überlappen, wird das kürzeste Benachrichtigungsintervall aller Eskalationseinträge benutzt.

escalation_period:

Diese Direktive wird benutzt, um den Kurznamen des Zeitfensters anzugeben, in dem diese Eskalation gültig ist. Wenn diese Direktive nicht angegeben wird, ist diese Eskalation zu allen Zeiten gültig.

escalation_options:

Diese Direktive wird benutzt, um die Kriterien festzulegen, wann diese Host-Eskalation benutzt wird. Diese Eskalation wird nur benutzt, wenn der Host in einem der Zustände ist, die in dieser Direktive angeben werden. Wenn diese Direktive nicht in einer Host-Eskalation angegeben wird, ist die Eskalation für alle Host-Zustände gültig. Gültige Optionen sind eine Kombination von einem oder mehreren folgender Werte: r = eskalieren bei einem UP-(Erholungs)-Zustand, d = eskalieren bei einem DOWN-Zustand und u = eskalieren bei einem UNREACHABLE-Zustand. Beispiel: wenn Sie d in diesem Feld angeben, dann wird die Eskalation nur benutzt, wenn sich der Host in einem DOWN-Zustand befindet.

escalation_condition:

Diese Direktive ist ab Icinga 1.0.1 verfügbar. Nähere Einzelheiten finden Sie hier.

first_down_notification:

Diese Direktive ist eine Zahl, die die erste DOWN-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 3 setzen, dann wird diese Eskalation nur dann benutzt, wenn der Host lang genug "down" ist, damit eine dritte Benachrichtigung versandt wird. Diese Direktive ist ab Icinga 1.0.2 verfügbar.

last_down_notification:

Diese Direktive ist eine Zahl, die die letzte DOWN-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 5 setzen, dann wird diese Eskalation nicht benutzt, wenn mehr als fünf Benachrichtigungen für den Host versandt werden. Wenn der Wert auf Null gesetzt wird, wird dieser Eskalationseintrag immer benutzt (unabhängig davon, wie viele Benachrichtigungen versandt werden). Diese Direktive ist ab Icinga 1.0.2 verfügbar.

first_unreachable_notification:

Diese Direktive ist eine Zahl, die die erste UNREACHABLE-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 3 setzen, dann wird diese Eskalation nur dann benutzt, wenn der Host lang genug unerreichbar ist, damit eine dritte Benachrichtigung versandt wird. Diese Direktive ist ab Icinga 1.0.2 verfügbar.

last_unreachable_notification:

Diese Direktive ist eine Zahl, die die letzte UNREACHABLE-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 5 setzen, dann wird diese Eskalation nicht benutzt, wenn mehr als fünf Benachrichtigungen für den Host versandt werden. Wenn der Wert auf Null gesetzt wird, wird dieser Eskalationseintrag immer benutzt (unabhängig davon, wie viele Benachrichtigungen versandt werden). Diese Direktive ist ab Icinga 1.0.2 verfügbar.

erweiterte Hostinformations-Definition (hostextinfo)

Beschreibung:

Einträge für erweiterte Hostinformationen sind grundsätzlich dazu gedacht, die Ausgaben der status-, statusmap- und extinfo-CGIs schöner aussehen zu lassen. Sie haben keinen Einfluss auf die Überwachung und sind vollständig optional.

Hinweis: Alle Direktiven der erweiterten Hostinformations-Definition sind auch in den Host-Definitionen verfügbar. Dadurch können Sie entscheiden, die nachstehenden Direktiven in Ihren Host-Definitionen zu benutzen, wenn es Ihre Konfigurationen vereinfacht. Separate erweiterte Hostinformations-Definitionen werden weiterhin unterstützt, um Rückwärtskompatibilität zu gewährleisten.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional. Trotz allem müssen Sie mindestens ein Kriterium angeben, damit die Definition von Nutzen ist.

define hostextinfo{

host_name

host_name

hostgroup_name

hostgroup_name

notes

note_string

notes_url

url

action_url

url

icon_image

image_file

icon_image_alt

alt_string

vrml_image

image_file

statusmap_image

image_file

2d_coords

x_coord,y_coord

3d_coords

x_coord,y_coord,z_coord

   

}

Beispieldefinition:

 define hostextinfo{
        host_name       netware1
        notes           This is the primary Netware file server
        notes_url       http://webserver.localhost.localdomain/hostinfo.pl?host=netware1
        icon_image      novell40.png 
        icon_image_alt  IntranetWare 4.11
        statusmap_image novell40.gd2
        2d_coords       100,250
        3d_coords       100.0,50.0,75.0
        }

Variablenbeschreibungen:

host_name:

Diese Variable wird benutzt, um den/die Kurznamen des/der Hosts zu identifizieren, mit dem/denen diese Daten verbunden sind.

hostgroup_name:

Diese Direktive wird benutzt, um den/die Kurznamen der Hostgruppen anzugeben, für den diese Definition gilt. Mehrere Hostgruppen werden durch Kommata von einander getrennt. Wenn diese Direktive benutzt wird, trifft die Definition auf alle Hosts zu, die Mitglied der angegebenen Hostgruppe(n) sind.

notes:

Diese Direktive wird benutzt, um eine optionale Zeichenkette mit Anmerkungen zu definieren, die den Host betreffen. Wenn Sie hier eine Anmerkung angeben, werden Sie diese im extended Information-CGI sehen (wenn Sie Informationen zu dem bestimmten Host ansehen).

notes_url:

Diese Variable wird benutzt, um einen optionalen URL zu definieren, der mehr Informationen zu diesem Host bereitstellt. Wenn Sie einen URL angeben, werden Sie im extended information-CGI einen Link namens "Extra Host Notes" sehen (wenn Sie Informationen zu dem bestimmten Host ansehen). Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/). Dies kann sehr nützlich sein, wenn Sie detaillierte Informationen zu diesem Host, Notfallkontaktmethoden usw. für anderes Support-Personal zur Verfügung stellen wollen.

action_url:

Diese Variable wird benutzt, um einen optionalen URL zu definieren, der mehr Aktionen für diesen Host bereitstellt. Wenn Sie einen URL angeben, werden Sie im extended information-CGI einen Link namens "Extra Host Notes" sehen (wenn Sie Informationen zu dem bestimmten Host ansehen). Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/). Dies kann sehr nützlich sein, wenn Sie detaillierte Informationen zu diesem Host, Notfallkontaktmethoden usw. für anderes Support-Personal zur Verfügung stellen wollen.

[Anmerkung] Anmerkung

Seit Icinga 1.0.2 ist es möglich, mehrere URLs für action|notes_url bei Host- und Service-Objektdefinitionen anzugeben. Die Syntax ist wie folgt:

notes_url|action_url 'ersteURL' 'zweiteURL' 'dritteURL'

notes_url|action_url nureineURL

Bitte achten Sie darauf, dass mehrere URLs auch gleichzeitig mehrere Icon-Bilder bedeuten. Diese sind hartkodiert, so dass z.B. action|notes.gif zu 1-action|1-notes.gif wird. Stellen Sie sicher, dass diese vorhanden sind. Die letzte URL kann ohne singlequotes angegeben werden und wird dann, wie eine einzelne URL betrachtet und verweist auf das normale Icon (action.gif).

icon_image:

Diese Variable wird benutzt, um den Namen eines GIF-, PNG- oder JPG-Images anzugeben, das mit diesem Host verbunden werden soll. Dieses Bild wird in den status- und extended information-CGIs angezeigt. Das Bild wird am besten aussehen, wenn es 40x40 Pixel groß ist. Bilder für Hosts werden im logos/-Unterverzeichnis Ihres HTML-Images-Verzeichnis gesucht (d.h. /usr/local/icinga/share/images/logos).

icon_image_alt:

Diese Variable wird benutzt, um eine optionale Zeichenkette anzugeben, die für den ALT-Tag des Bildes benutzt wird, das durch das <icon_image>-Argument angegeben wurde. Das ALT-Tag wird in den status-, extended information- und statusmap-CGIs benutzt.

statusmap_image:

Diese Variable wird benutzt, um den Namen eines Bildes anzugeben, das mit diesem Host im statusmap-CGI verbunden werden soll. Sie können ein JPG-, PNG- oder GIF-Bild angeben, aber wir würden zu einem Bild im GD2-Format raten, weil andere Bildformate zu hohen CPU-Belastungen führen können, wenn die Statusmap generiert wird. PNG-Bilder können mit Hilfe des pngtogd2-Utilitys (das in Thomas Boutell's gd library enthalten ist) ins GD2-Format umgewandelt werden. Die GD2-Bilder werden im unkomprimierten Format erstellt, um die CPU-Belastung zu minimieren, während das Statusmap-CGI das Netzwerkkartenbild erstellt. Das Bild wird am besten aussehen, wenn es 40x40 Pixel groß ist. Sie können diese Option leer lassen, wenn Sie das Statusmap-CGI nicht nutzen. Bilder für Hosts werden im logos/-Unterverzeichnis Ihres HTML-Images-Verzeichnis gesucht (d.h. /usr/local/icinga/share/images/logos).

2d_coords:

Diese Variable wird benutzt, um Koordinaten anzugeben, wenn der Host im statusmap-CGI gezeichnet wird. Koordinaten sollen in positiven Ganzzahlen angegeben werden, weil sie physischen Pixeln im generierten Bild entsprechen. Der Ursprung (0,0) für die Zeichnung ist die linke, obere Ecke des Bildes, das sich in die positive X-Richtung (nach rechts) und in die positive Y-Richtung (nach unten) erstreckt. Die Größe der Icons ist normalerweise etwa 40x40 Pixel (Text benötigt etwas mehr Platz). Die Koordinaten, die Sie angeben, beziehen sich auf die linke, obere Ecke des Icons. Anmerkung: Machen Sie sich keine Sorgen über die maximalen X- und Y-Koordinaten, die Sie benutzen können. Das CGI wird automatisch die maximale Größe des zu erstellenden Bildes aufgrund der größten X- und Y-Koordinaten festlegen, die Sie angegeben haben.

erweiterte Serviceinformations-Definition (serviceextinfo)

Beschreibung:

Einträge für erweiterte Serviceinformationen sind grundsätzlich dazu gedacht, die Ausgaben der status- und extinfo-CGIs schöner aussehen zu lassen. Sie haben keinen Einfluss auf die Überwachung und sind vollständig optional.

Hinweis: Alle Direktiven der erweiterten Serviceinformations-Definition sind auch in den Service-Definitionen verfügbar. Dadurch können Sie entscheiden, die nachstehenden Direktiven in Ihren Service-Definitionen zu benutzen, wenn es Ihre Konfigurationen vereinfacht. Separate erweiterte Serviceinformations-Definitionen werden weiterhin unterstützt, um Rückwärtskompatibilität zu gewährleisten.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional. Trotz allem müssen Sie mindestens ein Kriterium angeben, damit die Definition von Nutzen ist.

define serviceextinfo{

host_name

host_name

service_description service_description

hostgroup_name

hostgroup_name

notes

note_string

notes_url

url

action_url

url

icon_image

image_file

icon_image_alt

alt_string

   

}

Beispieldefinition:

 define serviceextinfo{
        host_name               linux2
        service_description     Log Anomalies
        notes                   Security-related log anomalies on secondary Linux server
        notes_url               http://webserver.localhost.localdomain/serviceinfo.pl?host=linux2&service=Log+Anomalies
        icon_image              security.png 
        icon_image_alt          Security-Related Alerts
        }

Variablenbeschreibungen:

host_name:

Diese Variable wird benutzt, um den/die Kurznamen des/der Hosts zu identifizieren, mit dem/denen der Service verbunden sind.

service_description:

Diese ist die Beschreibung des Service, mit dem/denen diese Daten verbunden sind.

hostgroup_name:

Diese Direktive wird benutzt, um den/die Kurznamen der Hostgruppen anzugeben, für den diese Definition gilt. Mehrere Hostgruppen werden durch Kommata von einander getrennt. Wenn diese Direktive benutzt wird, trifft die Definition auf alle Hosts zu, die Mitglied der angegebenen Hostgruppe(n) sind.

notes:

Diese Direktive wird benutzt, um eine optionale Zeichenkette mit Anmerkungen zu definieren, die den Service betreffen. Wenn Sie hier eine Anmerkung angeben, werden Sie diese im extended Information-CGI sehen (wenn Sie Informationen zu dem bestimmten Service ansehen).

notes_url:

Diese Variable wird benutzt, um einen optionalen URL zu definieren, der mehr Informationen zu diesem Service bereitstellt. Wenn Sie einen URL angeben, werden Sie im extended information-CGI einen Link namens "Extra Service Notes" sehen (wenn Sie Informationen zu dem bestimmten Service ansehen). Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/). Dies kann sehr nützlich sein, wenn Sie detaillierte Informationen zu diesem Host, Notfallkontaktmethoden usw. für anderes Support-Personal zur Verfügung stellen wollen.

action_url:

Diese Variable wird benutzt, um einen optionalen URL zu definieren, der mehr Aktionen für diesen Service bereitstellt. Wenn Sie einen URL angeben, werden Sie im extended information-CGI einen Link namens "Extra Service Notes" sehen (wenn Sie Informationen zu dem bestimmten Service ansehen). Jeder gültige URL kann benutzt werden. Wenn Sie relative Pfade benutzen, wird der Basis-Pfad der gleiche sein, der benutzt wird, um auf die CGIs zuzugreifen (d.h. /cgi-bin/icinga/). Dies kann sehr nützlich sein, wenn Sie detaillierte Informationen zu diesem Host, Notfallkontaktmethoden usw. für anderes Support-Personal zur Verfügung stellen wollen.

[Anmerkung] Anmerkung

Seit Icinga 1.0.2 ist es möglich, mehrere URLs für action|notes_url bei Host- und Service-Objektdefinitionen anzugeben. Die Syntax ist wie folgt:

notes_url|action_url 'ersteURL' 'zweiteURL' 'dritteURL'

notes_url|action_url nureineURL

Bitte achten Sie darauf, dass mehrere Urls auch gleichzeitig mehrere Icon-Bilder bedeuten. Diese sind hartkodiert, so dass z.B. action|notes.gif zu 1-action|1-notes.gif wird. Stellen Sie sicher, dass diese vorhanden sind. Die letzte URL kann ohne singlequotes angegeben werden und wird dann wie eine einzelne URL betrachtet und verweist auf das normale Icon (action.gif).

icon_image:

Diese Variable wird benutzt, um den Namen eines GIF-, PNG- oder JPG-Images anzugeben, das mit diesem Service verbunden werden soll. Dieses Bild wird in den status- und extended information-CGIs angezeigt. Das Bild wird am besten aussehen, wenn es 40x40 Pixel groß ist. Bilder für Service werden im logos/-Unterverzeichnis Ihres HTML-Images-Verzeichnis gesucht (d.h. /usr/local/icinga/share/images/logos).

icon_image_alt:

Diese Variable wird benutzt, um eine optionale Zeichenkette anzugeben, die für den ALT-Tag des Bildes benutzt wird, das durch das <icon_image>-Argument angegeben wurde. Das ALT-Tag wird in den status-, extended information- und statusmap-CGIs benutzt.

Module-Definition

Beschreibung:

Eine Module-Definition wird benutzt, um Informationen zu einem Modul anzugeben. Sie kann anstatt eines broker_module-Eintrags in der Hauptkonfigurationsdatei verwendet werden und ist deshalb flexibler (Sie können cfg_file/cfg_dir-Einträge benutzen, um sie einzuschließen).

[Anmerkung] Anmerkung

Moduldefinitionen sind seit Icinga 1.4 verfügbar.

Definition:

Anmerkung: "Direktiven" werden benötigt, die anderen sind optional.

define module{

module_name

module name

path

path

args

arguments

module_type

neb

}

Beispieldefinitionen:

 define module{
        module_name    ido_mod
        path           /usr/local/icinga/bin/idomod.o
        module_type    neb
        args           config_file=/usr/local/icinga/etc/idomod.cfg
        }

Basierend auf der MKLiveStatus-Dokumentation könnte die module-Definition wie folgt aussehen:

 define module{
        module_name    mklivestatus
        path           /usr/local/lib/mk-livestatus/livestatus.o
        module_type    neb
        args           /var/lib/nagios/rw/live
        }

Beschreibung der Direktiven:

module_name:

Diese Direktive legt den eindeutigen Namen des Moduls fest, so dass Sie den Modulnamen nicht mehrfach vergeben können. Die Direktive ist notwendig, anderenfalls wird die Konfiguration nicht akzeptiert und das Modul nicht geladen.

module_type:

Diese optionale Direktive gibt den Typ des Moduls an, z.B. 'neb' für Eventbroker-Module. Diese Direktive gedacht, um weitere Filterung beim Laden des Moduls zu erlauben.

path:

Diese notwendige Direktive gibt den kompletten Pfad des zu ladenden Moduls an. Bei Eventbroker-Modulen wie z.B. idomod muss der Benutzer des Icinga-Prozesses berechtigt sein, das Modul lesen und ausführen zu dürfen.

args:

Diese Direktive definiert optionale Argumente, die an das Modul übergeben werden. idomod benötigt config_file=.../idomod.cfg während andere Module ihre eigene Syntax haben. Der Wert der Direktive wird als Argument-String an den Eventbroker-Modul-Lader übergeben, wenn es als neb-Modul benutzt wird.

[Anmerkung] Anmerkung

Die Nutzung von Templates sollte möglich sind, aber das wurde noch nicht ausgiebing mit Icinga 1.4 getestet.