Anmerkungen
Bei der Erstellung und/oder Änderung von Konfigurationsdateien sollten Sie folgendes beachten:
- Zeilen, die mit einem '#'-Zeichen beginnen, werden als Kommentar angesehen und nicht verarbeitet
- Variablennamen müssen am Anfang der Zeile beginnen - "White space" vor dem Namen sind nicht erlaubt
- Variablennamen sind abhängig von Groß- und Kleinschreibung (case-sensitive)
Beispiel-Konfigurationsdatei
Hinweis: eine Beispiel-Hauptkonfigurationsdatei (/usr/local/nagios/etc/nagios.cfg)
wird installiert, wenn Sie der Schnellstartanleitung für Fedora, OpenSuse oder Ubuntu folgen.
Position der Konfigurationsdatei
Die Hauptkonfigurationsdatei heißt üblicherweise nagios.cfg und ist im /usr/local/nagios/etc/-Verzeichnis zu finden.
Variablen der Konfigurationsdatei
Nachfolgend finden Sie Beschreibungen jeder Option der Nagios-Hauptkonfigurationsdatei...
Protokolldatei (Log File) |
Format: |
log_file=<file_name> |
Beispiel: |
log_file=/usr/local/nagios/var/nagios.log |
Diese Variable gibt an, wo Nagios die Hauptprotokolldatei anlegen soll. Dies sollte die erste Variable sein, die Sie in Ihrer Konfigurationsdatei
definieren, weil Nagios versucht, dorthin die Fehler zu schreiben, die es in den übrigen Konfigurationsdaten findet. Wenn Sie
Log-Rotation aktiviert haben, dann wird diese Datei automatisch jede Stunde, jeden Tag, jede Woche oder jeden Monat
rotiert.
Objektkonfigurationsdatei (Object Configuration File) |
Format: |
cfg_file=<file_name> |
Beispiel: |
cfg_file=/usr/local/nagios/etc/hosts.cfg
cfg_file=/usr/local/nagios/etc/services.cfg
cfg_file=/usr/local/nagios/etc/commands.cfg
|
Diese Direktive wird benutzt, um eine Objektkonfigurationsdatei anzugeben, die Objektdefinitionen enthält, die
Nagios zur Überwachung nutzen soll. Objektkonfigurationsdateien enthalten Definitionen für Hosts, Hostgruppen, Kontakte, Kontaktgruppe,
Services, Befehle usw. Sie können Ihre Konfigurationsinformationen in verschiedene Dateien aufteilen und mehrere cfg_file=-Einträge
angeben, um jede einzelne zu verarbeiten.
Objektkonfigurationsverzeichnis (Object Configuration Directory) |
Format: |
cfg_dir=<directory_name> |
Beispiel: |
cfg_dir=/usr/local/nagios/etc/commands
cfg_dir=/usr/local/nagios/etc/services
cfg_dir=/usr/local/nagios/etc/hosts
|
Diese Direktive wird benutzt, um ein Verzeichnis anzugeben, das Objektkonfigurationsdateien enthält, die Nagios
zur Überwachung nutzen soll. Alle Dateien in dem Verzeichnis mit einer .cfg-Endung werden als Objektkonfigurationsdateien verarbeitet.
Zusätzlich wird Nagios rekursiv alle Konfigurationsdateien in den Unterverzeichnissen des Verzeichnisses verarbeiten, das Sie angegeben haben.
Sie können Ihre Konfigurationsinformationen in verschiedene Verzeichnisse aufteilen und mehrere cfg_dir=-Einträge
angeben, um alle Konfigurationsdateien jedes einzelnen Verzeichnisses zu verarbeiten.
Objekt-Cache-Datei (Object Cache File) |
Format: |
object_cache_file=<file_name> |
Beispiel: |
object_cache_file=/usr/local/nagios/var/objects.cache
|
Diese Direktive wird benutzt, um eine Datei anzugeben, in der eine zwischengespeicherte (cached) Kopie der Objektdefinitionen
abgelegt wird. Die Cache-Datei wird jedes Mal (erneut) angelegt, wenn Nagios (erneut) gestartet wird, und wird von den CGIs benutzt. Sie ist dazu
gedacht, die Zwischenspeicherung der Konfigurationsdateien in den CGIs zu beschleunigen und es Ihnen zu erlauben, die
Objektkonfigurationsdateien zu editieren, während Nagios läuft, ohne die Ausgaben der CGIs zu beeinflussen.
vorgespeicherte Objektdatei (Precached Object File) |
Format: |
precached_object_file=<file_name> |
Beispiel: |
precached_object_file=/usr/local/nagios/var/objects.precache
|
Diese Direktive wird benutzt, um eine Datei anzugeben, die eine vorverarbeitete (pre-processed), vorgespeicherte (pre-cached) Kopie von Objektdefinitionen
enthält. Diese Datei kann genutzt werden, um drastisch den Startvorgang in großen/komplexen Nagios-Installationen zu beschleunigen. Lesen
Sie hier, wie der Startvorgang beschleunigt werden kann.
Ressource-Datei (Resource File) |
Format: |
resource_file=<file_name> |
Beispiel: |
resource_file=/usr/local/nagios/etc/resource.cfg |
Dies wird benutzt, um eine optionale Ressource-Datei anzugeben, die $USERn$-Makro-Definitionen enthalten kann. $USER$-Makros
sind sinnvoll zur Speicherung von Benutzernamen, Passwörtern und Objekten, die häufig in Befehlsdefinitionen (wie z.B. Verzeichnispfade)
benutzt werden. Die CGIs werden nicht versuchen, Ressource-Dateien zu lesen, so dass Sie die Berechtigungen beschränken können
(600 oder 660), um sensible Informationen zu schützen. Sie können mehrere Ressource-Dateien angeben, indem Sie mehrere resource_file-Einträge
in die Hauptkonfigurationsdatei aufnehmen. Nagios wird sie alle verarbeiten. Schauen Sie in die resource.cfg-Datei im sample-config/-Unterverzeichnis
der Nagios-Distribution, um ein Beispiel für die Definition von $USER$-Makros zu sehen.
temporäre Datei (Temp File) |
Format: |
temp_file=<file_name> |
Beispiel: |
temp_file=/usr/local/nagios/var/nagios.tmp |
Dies ist eine temporäre Datei, die Nagios periodisch anlegt, wenn Kommentardaten, Statusdaten usw. aktualisiert werden. Die Datei wird gelöscht,
wenn sie nicht länger benötigt wird.
temporärer Pfad (Temp Path) |
Format: |
temp_path=<dir_name> |
Beispiel: |
temp_path=/tmp |
Dies ist ein Verzeichnis, das Nagios als "Schmierblock" (scratch space) benutzen kann, um während des Überwachungsprozesses
temporäre Dateien anlegen zu können. Sie sollten tmpwatch oder ein ähnliches Programm ausführen, um in diesem Verzeichnis
Dateien zu löschen, die älter als 24 Stunden sind.
Status-Datei (Status File) |
Format: |
status_file=<file_name> |
Beispiel: |
status_file=/usr/local/nagios/var/status.dat |
Dies ist die Datei, die Nagios nutzt, um den aktuellen Zustand, Kommentar- und Ausfallzeitinformationen zu speichern. Diese Datei wird von den CGIs
genutzt, so dass der aktuelle Überwachungszustand über ein Web-Interface berichtet werden kann. Die CGIs müssen Lesezugriff auf diese
Datei haben, um richtig funktionieren zu können. Diese Datei wird jedes Mal gelöscht, wenn Nagios endet und neu angelegt, wenn Nagios startet.
Statusdatei-Aktualisierungsintervall (Status File Update Interval) |
Format: |
status_update_interval=<seconds> |
Beispiel: |
status_update_interval=15 |
Diese Einstellung legt fest, wie oft (in Sekunden) Nagios Statusdaten in der Statusdatei aktualisiert. Das kleinste
Aktualisierungsintervall ist eine Sekunde.
Nagios-Benutzer (Nagios User) |
Format: |
nagios_user=<username/UID> |
Beispiel: |
nagios_user=nagios |
Dies wird benutzt, um den "eigentlichen" (effective) Benutzer zu setzen, mit dem der Nagios-Prozess laufen soll. Nach dem anfänglichen
Programmstart und bevor irgendeine Überwachung beginnt, wird Nagios die vorhandenen Berechtigungen "fallen lassen" (drop) und als dieser
Benutzer laufen. Sie können entweder einen Benutzernamen oder eine UID angeben.
Nagios-Gruppe (Nagios Group) |
Format: |
nagios_group=<groupname/GID> |
Beispiel: |
nagios_group=nagios |
Dies wird benutzt, um die "eigentliche" (effective) Gruppe zu setzen, mit der der Nagios-Prozess laufen soll. Nach dem anfänglichen
Programmstart und bevor irgendeine Überwachung beginnt, wird Nagios die vorhandenen Berechtigungen "fallen lassen" (drop) und als diese
Gruppe laufen. Sie können entweder einen Gruppennamen oder eine GID angeben.
Benachrichtigungsoption (Notifications Option) |
Format: |
enable_notifications=<0/1> |
Beispiel: |
enable_notifications=1 |
Diese Option legt fest, ob Nagios Benachrichtigungen versendet. Wenn diese Optionen deaktiviert ist,
wird Nagios nach dem (Neu-) Start keine Benachrichtigungen für irgendeinen Host oder Service versenden.
Anmerkung: Wenn Sie Statusinformationsaufbewahrung (retain state information) aktiviert haben, wird Nagios diese
Einstellung ignorieren, wenn es (erneut) startet und die letzte bekannte Einstellung dieser Option nutzen (wie sie in der
Statusaufbewahrungsdatei abgelegt ist), es sei denn, Sie haben die
use_retained_program_state-Option deaktiviert. Wenn Sie diese Option ändern möchten, während die
Statusaufbewahrung aktiviert ist (und die Option use_retained_program_state aktiviert ist), müssen Sie den
entsprechenden externen Befehl benutzen oder sie über das Web-Interface ändern. Die Werte sind wie folgt:
- 0 = Benachrichtigungen deaktivieren
- 1 = Benachrichtigungen aktivieren (Default)
Option Service-Prüfungen ausführen (Service Check Execution Option) |
Format: |
execute_service_checks=<0/1> |
Beispiel: |
execute_service_checks=1 |
Diese Option legt fest, ob Nagios nach dem (Neu-) Start Service-Prüfungen ausführt. Wenn diese Option deaktiviert ist, wird
Nagios nicht aktiv irgendwelche Service-Prüfungen ausführen und in einer Art von "Schlafmodus" verbleiben (es kann weiterhin
passive Prüfungen empfangen, es sei denn, Sie haben diese deaktiviert).
Diese Option wird oft benutzt, wenn Ersatz-Überwachungs-Server (backup monitoring server) konfiguriert werden, wie dies in der Dokumentation zu
Redundanz beschrieben ist, oder wenn Sie eine verteilte-Überwachungsumgebung
aufbauen.
Anmerkung: wenn Sie Statusinformationsaufbewahrung (retain state information) aktiviert haben, wird Nagios diese Einstellung
ignorieren, wenn es (erneut) startet und die letzte bekannte Einstellung dieser Option nutzen (wie sie in der
Statusaufbewahrungsdatei abgelegt ist), es sei denn, Sie haben die
use_retained_program_state-Option deaktiviert. Wenn Sie diese Option ändern möchten, während die
Statusaufbewahrung aktiviert ist (und die Option use_retained_program_state aktiviert ist), müssen Sie den
entsprechenden externen Befehl benutzen oder sie über das Web-Interface ändern. Die Werte sind wie folgt:
- 0 = keine Service-Prüfungen ausführen
- 1 = Service-Prüfungen ausführen (Default)
Option passive Service-Prüfungen akzeptieren (Passive Service Check Acceptance Option) |
Format: |
accept_passive_service_checks=<0/1> |
Beispiel: |
accept_passive_service_checks=1 |
Diese Option legt fest, ob Nagios nach dem (Neu-) Start passive Service-Prüfungen akzeptiert.
Wenn diese Option deaktiviert ist, wird Nagios keine passiven Service-Prüfungen akzeptieren.
Anmerkung: wenn Sie Statusinformationsaufbewahrung (retain state information) aktiviert haben, wird Nagios diese Einstellung
ignorieren, wenn es (erneut) startet und die letzte bekannte Einstellung dieser Option nutzen (wie sie in der
Statusaufbewahrungsdatei abgelegt ist), es sei denn, Sie haben die
use_retained_program_state-Option deaktiviert. Wenn Sie diese Option ändern möchten, während die
Statusaufbewahrung aktiviert ist (und die Option use_retained_program_state aktiviert ist), müssen Sie den
entsprechenden externen Befehl benutzen oder sie über das Web-Interface ändern. Die Werte sind wie folgt:
- 0 = keine passiven Service-Prüfungen akzeptieren
- 1 = passive Service-Prüfungen akzeptieren (Default)
Option Host-Prüfungen ausführen (Host Check Execution Option) |
Format: |
execute_host_checks=<0/1> |
Beispiel: |
execute_host_checks=1 |
Diese Option legt fest, ob Nagios nach dem (Neu-) Start nach Bedarf oder regelmäßig geplante Host-Prüfungen ausführt.
Wenn diese Option deaktiviert ist, wird Nagios nicht aktiv irgendwelche Host-Prüfungen ausführen, obwohl es weiterhin
passive Host-Prüfungen empfangen wird, es sei denn, Sie haben diese deaktiviert).
Diese Option wird am meisten genutzt, wenn Ersatz-Überwachungs-Server (backup monitoring server) konfiguriert werden, wie dies in der Dokumentation
zu Redundanz beschrieben ist, oder wenn Sie eine verteilte-Überwachungsumgebung
aufbauen.
Anmerkung: wenn Sie Statusinformationsaufbewahrung (retain state information) aktiviert haben, wird Nagios diese Einstellung
ignorieren, wenn es (erneut) startet und die letzte bekannte Einstellung dieser Option nutzen (wie sie in der
Statusaufbewahrungsdatei abgelegt ist), es sei denn, Sie haben die
use_retained_program_state-Option deaktiviert. Wenn Sie diese Option ändern möchten, während die
Statusaufbewahrung aktiviert ist (und die Option use_retained_program_state aktiviert ist), müssen Sie den
entsprechenden externen Befehl benutzen oder sie über das Web-Interface ändern. Die Werte sind wie folgt:
- 0 = keine Host-Prüfungen ausführen
- 1 = Host-Prüfungen ausführen (Default)
Option passive Host-Prüfungen akzeptieren (Passive Host Check Acceptance Option) |
Format: |
accept_passive_host_checks=<0/1> |
Beispiel: |
accept_passive_host_checks=1 |
Diese Option legt fest, ob Nagios nach dem (Neu-) Start passive Host-Prüfungen akzeptiert.
Wenn diese Option deaktiviert ist, wird Nagios keine passiven Host-Prüfungen akzeptieren.
Anmerkung: wenn Sie Statusinformationsaufbewahrung (retain state information) aktiviert haben, wird Nagios diese Einstellung
ignorieren, wenn es (erneut) startet und die letzte bekannte Einstellung dieser Option nutzen (wie sie in der
Statusaufbewahrungsdatei abgelegt ist), es sei denn, Sie haben die
use_retained_program_state-Option deaktiviert. Wenn Sie diese Option ändern möchten, während die
Statusaufbewahrung aktiviert ist (und die Option use_retained_program_state aktiviert ist), müssen Sie den
entsprechenden externen Befehl benutzen oder sie über das Web-Interface ändern. Die Werte sind wie folgt:
- 0 = keine passiven Host-Prüfungen akzeptieren
- 1 = passive Host-Prüfungen akzeptieren (Default)
Eventhandler-Option (Event Handler Option) |
Format: |
enable_event_handlers=<0/1> |
Beispiel: |
enable_event_handlers=1 |
Diese Option legt fest, ob Nagios nach dem (Neu-) Start Eventhandler ausführt. Wenn diese Option
deaktiviert ist, wird Nagios keine Host- oder Service-Eventhandler ausführen.
Anmerkung: wenn Sie Statusinformationsaufbewahrung (retain state information) aktiviert haben, wird Nagios diese Einstellung
ignorieren, wenn es (erneut) startet und die letzte bekannte Einstellung dieser Option nutzen (wie sie in der
Statusaufbewahrungsdatei abgelegt ist), es sei denn, Sie haben die
use_retained_program_state-Option deaktiviert. Wenn Sie diese Option ändern möchten, während die
Statusaufbewahrung aktiviert ist (und die Option use_retained_program_state aktiviert ist), müssen Sie den
entsprechenden externen Befehl benutzen oder sie über das Web-Interface ändern. Die Werte sind wie folgt:
- 0 = Eventhandler deaktivieren
- 1 = Eventhandler aktivieren (Default)
Protokollrotationsmethode (Log Rotation Method) |
Format: |
log_rotation_method=<n/h/d/w/m> |
Beispiel: |
log_rotation_method=d |
Dies ist die Rotationsmethode, die Nagios für Ihre Protokolldatei nutzen soll. Die Werte sind wie folgt:
- n = keine ("none" - die Protokolldatei nicht rotieren, das ist der Standard)
- h = stündlich ("hourly" - die Protokolldatei jede volle Stunde rotieren)
- d = täglich ("daily" - die Protokolldatei jeden Tag um Mitternacht rotieren)
- w = wöchentlich ("weekly" - die Protokolldatei jeden Samstag um Mitternacht rotieren)
- m = monatlich ("monthly" - die Protokolldatei am letzten Tag des Monats um Mitternacht rotieren)
Protokollarchiv-Pfad (Log Archiv Path) |
Format: |
log_archive_path=<path> |
Beispiel: |
log_archive_path=/usr/local/nagios/var/archives/ |
Dies ist das Verzeichnis, in dem Nagios die Protokolldateien ablegen soll, die rotiert wurden. Diese Option wird ignoriert, wenn Sie die
Funktionalität der Protokollrotation (log rotation) nicht nutzen.
Option externe Befehle prüfen (External Command Check Option) |
Format: |
check_external_commands=<0/1> |
Beispiel: |
check_external_commands=1 |
Diese Option legt fest, ob Nagios das command file auf auszuführende Befehle prüfen soll. Diese Option muss
aktiviert sein, wenn Sie planen, das Command-CGI zu nutzen, um Befehle über das Web-Interface zu erteilen.
Mehr Informationen zu externen Befehlen finden Sie hier.
- 0 = nicht auf externe Befehle prüfen
- 1 = auf externe Befehle prüfen (Default)
Prüfintervall externe Befehle (External Command Check Interval) |
Format: |
command_check_interval=<xxx>[s] |
Beispiel: |
command_check_interval=1 |
Wenn Sie eine Zahl mit einem angehängten "s" angeben (z.B. 30s), dann ist dies die Zahl in Sekunden, die zwischen Prüfungen auf
externe Befehle gewartet werden soll. Wenn Sie das "s" weglassen, ist dies die Zahl von "Zeiteinheiten", die zwischen den Prüfungen auf externe
Befehle gewartet werden soll. Solange Sie nicht den Standardwert (60) der interval_length-Direktive geändert haben
(wie weiter unten definiert), bedeutet dieser Wert Minuten.
Anmerkung: durch das Setzen dieses Wertes auf -1 wird Nagios so oft wie möglich auf externe Befehle prüfen. Jedes Mal, wenn Nagios
auf externe Befehle prüft, wird es alle im command file befindlichen Befehle lesen und verarbeiten, bevor es mit
anderen Aufgaben fortfährt. Mehr Informationen zu externen Befehlen finden Sie hier.
externe Befehlsdatei (External Command File) |
Format: |
command_file=<file_name> |
Beispiel: |
command_file=/usr/local/nagios/var/rw/nagios.cmd |
Dies ist die Datei, die Nagios auf zu verarbeitende externe Befehle prüfen wird. Das Command-CGI schreibt
Befehle in diese Datei. Die externe Befehlsdatei ist als "named pipe" (FIFO) implementiert, die beim Start von Nagios angelegt und beim Herunterfahren
wieder gelöscht wird. Wenn die Datei beim Start von Nagios existiert, wird der Nagios-Prozess mit einer Fehlermeldung enden. Mehr Informationen zu
externen Befehlen finden Sie hier.
externe Befehlspuffer-Slots (External Command Buffer Slots) |
Format: |
external_command_buffer_slots=<#> |
Beispiel: |
external_command_buffer_slots=512 |
Anmerkung: dies ist ein fortgeschrittenes Feature. Diese Option legt fest, wie viele Puffer-Slots Nagios für die Zwischenspeicherung von
externen Befehlen reserviert, die von einem "worker thread" aus der externen Befehlsdatei gelesen, aber noch nicht vom "main thread" des Nagios-Daemons
verarbeitet wurden. Jeder Slot kann einen externen Befehl enthalten, so dass diese Option im Wesentlichen bestimmt, wie viele Befehle gepuffert
werden können. Bei Installationen, wo Sie eine große Zahl von passiven Prüfungen verarbeiten (z.B.
verteilten Setups), müssen Sie ggf. diese Zahl erhöhen. Sie sollten den Einsatz von MRTG erwägen, um
die Nutzung der externen Befehlspuffer grafisch darzustellen. Mehr zur Konfiguration der grafischen Darstellung finden Sie hier.
Update-Prüfungen (Update Checks) |
Format: |
check_for_updates=<0/1> |
Beispiel: |
check_for_updates=1 |
Diese Option legt fest, ob Nagios automatisch prüft, ob neue Updates (Versionen) verfügbar sind.
Es wird empfohlen, dass Sie diese Option aktivieren, damit Sie immer über die letzten kritischen Patches für Nagios informiert sind.
Nagios ist kritisch für Sie - stellen Sie sicher, dass es sich in guter Form befindet.
Nagios wird einmal am Tag auf neue Updates prüfen. Daten, die von Nagios Enterprises für den Update-Check gesammelt werden, werden gemäß unserer Privacy-Policy verarbeitet (Details siehe http://api.nagios.org).
Nur Update-Prüfungen (Bare Update Checks) |
Format: |
bare_update_checks=<0/1> |
Beispiel: |
bare_update_checks=0 |
Diese Option legt fest, welche Daten Nagios an api.nagios.org schickt, wenn es auf Updates prüft. Als Standard wird Nagios Informationen über die aktuell installierte Version schicken sowie einen Hinweis, ob es sich hierbei um eine neue oder eine aktualisierte Version handelt. Nagios Enterprises nutzt diese Daten, um die Anzahl der Nutzer bestimmter Versionen zu ermitteln. Aktivieren Sie diese Option, wenn Sie diese Informationen nicht senden möchten.
Format: |
lock_file=<file_name> |
Beispiel: |
lock_file=/tmp/nagios.lock |
Diese Option gibt die Position der Sperrdatei an, die Nagios anlegen sollte, wenn es als Daemon läuft (wenn es mit der -d Kommandozeilenoption
gestartet wurde). Diese Datei enthält die Prozess-ID (PID) des laufenden Nagios-Prozesses.
Statusaufbewahrungsoption (State Retention Option) |
Format: |
retain_state_information=<0/1> |
Beispiel: |
retain_state_information=1 |
Diese Option legt fest, ob Nagios Statusinformationen für Hosts und Services zwischen Programmneustarts aufbewahren soll.
Wenn Sie diese Option aktivieren, sollten Sie ein Wert für die state_retention_file-Variable angeben.
Wenn sie aktiviert ist, wird Nagios alle Statusinformationen für Hosts und Services sichern, bevor es beendet (oder neu gestartet) wird und
vorher gespeicherte Statusinformationen einlesen, wenn es neu gestartet wird.
- 0 = Statusinformationen nicht aufbewahren
- 1 = Statusinformationen aufbewahren (Default)
Statusaufbewahrungsdatei (State Retention File) |
Format: |
state_retention_file=<file_name> |
Beispiel: |
state_retention_file=/usr/local/nagios/var/retention.dat |
Dies ist die Datei, die Nagios für die Speicherung von Status-, Ausfallzeit- und Kommentarinformationen nutzt, bevor es endet. Wenn Nagios
neu startet, wird es die in dieser Datei gespeicherten Informationen nutzen, um die anfänglichen Zustände von Services und Hosts zu setzen,
bevor es mit der Überwachung beginnt. Damit Nagios Statusinformationen zwischen Programmneustarts aufbewahrt, müssen Sie die
retain_state_information-Option aktivieren.
automatisches Statusaufbewahrungs-Aktualisierungsintervall (Automatic State Retention Update Interval) |
Format: |
retention_update_interval=<minutes> |
Beispiel: |
retention_update_interval=60 |
Diese Einstellung legt fest, wie oft (in Minuten) Nagios automatisch während des normalen Betriebs die Aufbewahrungsdaten aktualisiert. Wenn Sie
einen Wert von Null angeben, wird Nagios nicht in regelmäßigen Intervallen die Aufbewahrungsdaten sichern, aber es wird die Aufbewahrungsdaten
vor der Beendigung oder dem Neustart sichern. Wenn Sie die Statusaufbewahrung deaktiviert haben (mit der
retain_state_information-Option), hat diese Option keine Auswirkung.
Option aufbewahrten Programmzustand nutzen (Use Retained Program State Option) |
Format: |
use_retained_program_state=<0/1> |
Beispiel: |
use_retained_program_state=1 |
Diese Einstellung legt fest, ob Nagios verschiedene programmweite Statusvariablen auf Basis der Aufbewahrungsdatei setzen soll. Einige dieser
programmweiten Statusvariablen, die normalerweise über Programmstarts hinweg gesichert werden, wenn Statusaufbewahrung aktiviert ist, umfassen die
enable_notifications-, enable_flap_detection-,
enable_event_handlers-, execute_service_checks- und
accept_passive_service_checks-Optionen.
Wenn Sie Statusaufbewahrung deaktiviert haben, hat diese Option keine Auswirkung.
- 0 = keinen aufbewahrten Programmzustand nutzen
- 1 = aufbewahrten Programmzustand nutzen (Default)
Option aufbewahrte Planungsinformationen nutzen (Use Retained Scheduling Info Option) |
Format: |
use_retained_scheduling_info=<0/1> |
Beispiel: |
use_retained_scheduling_info=1 |
Diese Einstellung legt fest, ob Nagios Planungsinformationen für Hosts und Services aufbewahrt, wenn es neu startet. Wenn Sie eine große
Zahl (oder einen großen Anteil) von Hosts oder Services hinzufügen, empfehle ich diese Option zu deaktivieren, wenn Sie das erste Mal
Nagios neu starten, weil es nachteilig die Verteilung von initialen Prüfungen beeinflussen kann. Andernfalls werden Sie diese Option
wahrscheinlich aktiviert lassen.
- 0 = keine aufbewahrten Planungsinformationen nutzen
- 1 = aufbewahrten Planungsinformationen nutzen (Default)
aufbewahrte Host- und Service-Attributmasken (Retained Host and Service Attribute Masks) |
Format: |
retained_host_attribute_mask=<number>
retained_service_attribute_mask=<number>
|
Beispiel: |
retained_host_attribute_mask=0
retained_service_attribute_mask=0
|
WARNUNG: dies ist ein fortgeschrittenes Feature. Sie müssen den Nagios-Quellcode lesen, um diese Option effizient nutzen zu können.
Diese Option legt fest, welche Host- oder Service-Attribute NICHT über Programmneustarts hinweg aufbewahrt werden. Die Werte für diese
Optionen sind ein bitweises AND der durch die "MODATTR_"-Definitionen angegebenen Werte in den include/common.h-Quellcode-Dateien. Per Default werden alle Host- und
Service-Attribute aufbewahrt.
aufbewahrte Prozessattributmasken (Retained Process Attribute Masks) |
Format: |
retained_process_host_attribute_mask=<number>
retained_process_service_attribute_mask=<number>
|
Beispiel: |
retained_process_host_attribute_mask=0
retained_process_service_attribute_mask=0
|
WARNUNG: dies ist ein fortgeschrittenes Feature. Sie müssen den Nagios-Quellcode lesen, um diese Option effizient nutzen zu können.
Diese Option legt fest, welche Prozessattribute NICHT über Programmneustarts hinweg aufbewahrt werden. Es gibt zwei Masken, weil es oft
separate Host- und Service-Prozessattribute gibt, die geändert werden können. Beispielsweise können Host-Prüfungen auf Programmebene
deaktiviert werden, während Service-Prüfungen weiterhin aktiviert sind. Die Werte für diese Optionen sind ein bitweises AND der durch
die "MODATTR_"-Definitionen angegebenen Werte in den include/common.h-Quellcode-Dateien. Per Default werden alle Prozessattribute aufbewahrt.
aufbewahrte Kontaktattributmasken (Retained Contact Attribute Masks) |
Format: |
retained_contact_host_attribute_mask=<number>
retained_contact_service_attribute_mask=<number>
|
Beispiel: |
retained_contact_host_attribute_mask=0
retained_contact_service_attribute_mask=0
|
WARNUNG: dies ist ein fortgeschrittenes Feature. Sie müssen den Nagios-Quellcode lesen, um diese Option effizient nutzen zu können.
Diese Option legt fest, welche Kontaktattribute NICHT über Programmneustarts hinweg aufbewahrt werden. Es gibt zwei Masken, weil es oft
separate Host- und Service-Prozessattribute gibt, die geändert werden können. Die Werte für diese Optionen sind ein bitweises AND der
durch die "MODATTR_"-Definitionen angegebenen Werte in den include/common.h-Quellcode-Dateien. Per Default werden alle Kontaktattribute aufbewahrt.
Syslog-Protokollierungsoption (Syslog Logging Option) |
Format: |
use_syslog=<0/1> |
Beispiel: |
use_syslog=1 |
Diese Variable legt fest, ob Meldungen im Syslog des lokalen Hosts protokolliert werden sollen. Die Werte sind wie folgt:
- 0 = Syslog nicht nutzen
- 1 = Syslog nutzen [Default]
Benachrichtigungsprotokollierungsoption (Notification Logging Option) |
Format: |
log_notifications=<0/1> |
Beispiel: |
log_notifications=1 |
Diese Variable legt fest, ob Benachrichtungsmeldungen protokolliert werden. Wenn Sie eine Menge von Kontakten oder ständigen Service-Ausfällen
haben, dann wird Ihre Protokolldatei relativ schnell wachsen. Benutzen Sie diese Option, um die Protokollierung von (Kontakt-)Benachrichtigungen zu verhindern.
- 0 = keine Benachrichtigungen protokollieren
- 1 = Benachrichtigungen protokollieren [Default]
Option Service-Wiederholungsprüfungen protokollieren (Service Check Retry Logging Option) |
Format: |
log_service_retries=<0/1> |
Beispiel: |
log_service_retries=1 |
Diese Variable legt fest, ob Service-Wiederholungsprüfungen protokolliert werden. Service-Wiederholungsprüfungen treten auf, wenn ein
Service-Prüfergebnis einen nicht-OK-Status ergibt, Sie Nagios aber so konfiguriert haben, dass die Prüfung mehr als einmal wiederholt wird,
bevor ein Fehler gemeldet wird. Services in diesem Zustand befinden sich in einem "Soft"-Status. Die Protokollierung von Service-Wiederholungsprüfungen
ist meist dann sinnvoll, wenn Sie versuchen, Nagios zu debuggen, oder Service-Eventhandler zu testen.
- 0 = keine Service-Wiederholungsprüfungen protokollieren [Default-H]
- 1 = Service-Wiederholungsprüfungen protokollieren [Default-C]
Option Host-Wiederholungsprüfungen-protokollieren (Host Check Retry Logging Option) |
Format: |
log_host_retries=<0/1> |
Beispiel: |
log_host_retries=1 |
Diese Variable legt fest, ob Host-Wiederholungsprüfungen protokolliert werden. Die Protokollierung von Host-Wiederholungsprüfungen
ist meist dann sinnvoll, wenn Sie versuchen, Nagios zu debuggen, oder Host-Eventhandler zu testen.
- 0 = keine Host-Wiederholungsprüfungen protokollieren [Default-H]
- 1 = Host-Wiederholungsprüfungen protokollieren [Default-C]
Option Eventhandler-protokollieren (Event Handler Logging Option) |
Format: |
log_event_handlers=<0/1> |
Beispiel: |
log_event_handlers=1 |
Diese Variable legt fest, ob Service- und Host-Eventhandlers protokolliert werden. Eventhandler sind optionale Befehle,
die ausgeführt werden können, wenn sich der Zustand eines Hosts oder Service ändert. Die Protokollierung von Eventhandlern
ist meist dann sinnvoll, wenn Sie versuchen, Nagios zu debuggen, oder Ihre Eventhandler-Scripts zu testen.
- 0 = Eventhandler nicht protokollieren
- 1 = Eventhandler protokollieren [Default]
Option initiale Zustände protokollieren (Initial States Logging Option) |
Format: |
log_initial_states=<0/1> |
Beispiel: |
log_initial_states=1 |
Diese Variable legt fest, ob Nagios alle anfänglichen Host- und Service-Zustände protokolliert, selbst wenn sie in einem OK-Zustand sind.
Anfängliche Service- und Host-Zustände werden normalerweise nur dann protokolliert, wenn es bei der ersten Prüfung ein Problem gibt.
Die Aktivierung dieser Option ist sinnvoll, wenn Sie eine Applikation benutzen, die die Protokolldatei abfragt, um Langzeit-Zustandsstatistiken für
Services und Hosts zu erstellen.
- 0 = keine anfänglichen Zusände protokollieren (Default)
- 1 = anfängliche Zustände protokollieren
Option externe Befehle protokollieren (External Command Logging Option) |
Format: |
log_external_commands=<0/1> |
Beispiel: |
log_external_commands=1 |
Diese Variable legt fest, ob Nagios externe Befehle protokolliert, die es aus der externen Befehlsdatei
erhält. Anmerkung: diese Option kontrolliert nicht, ob passive Service-Prüfungen (die eine Art von externen
Befehlen sind) protokolliert werden. Zur Aktivierung oder Deaktivierung der Protokollierung von passiven Prüfungen nutzen Sie die
log_passive_checks-Option.
- 0 = keine externen Befehle protokollieren
- 1 = externe Befehle protokollieren (Default)
Option passive Prüfungen protokollieren (Passive Check Logging Option) |
Format: |
log_passive_checks=<0/1> |
Beispiel: |
log_passive_checks=1 |
Diese Variable legt fest, ob Nagios passive Host- und Service-Prüfungen protokolliert, die es von der
externen Befehlsdatei bekommt. Wenn Sie eine verteilte Überwachungsumgebung aufbauen
oder planen, eine große Zahl von passiven Prüfungen auf einer regelmäßigen Basis zu behandeln, dann können Sie diese Option
deaktivieren, damit Ihre Protokolldatei nicht zu groß wird.
- 0 = keine passiven Prüfungen protokollieren
- 1 = passive Prüfungen protokollieren (Default)
globale Host-Eventhandler Option (Global Host Event Handler Option) |
Format: |
global_host_event_handler=<command> |
Beispiel: |
global_host_event_handler=log-host-event-to-db |
Diese Option erlaubt Ihnen, einen Host-Eventhandler-Befehl anzugeben, der für jeden Host-Zustandswechsel ausgeführt wird. Der globale
Eventhandler wird direkt vor dem Eventhandler ausgeführt, den Sie optional in jeder Host-Definition angeben können. Das
Befehls-Argument ist der Kurzname eines Befehls, den Sie in Ihrer Objektkonfigurationsdatei angeben.
Die maximale Ausführungszeit dieses Befehls kann durch die event_handler_timeout-Option angegeben werden.
Mehr Informationen zu Eventhandlern finden Sie hier.
Globale Service-Eventhandler-Option (Global Service Event Handler Option) |
Format: |
global_service_event_handler=<command> |
Beispiel: |
global_service_event_handler=log-service-event-to-db |
Diese Option erlaubt Ihnen, einen Service-Eventhandler-Befehl anzugeben, der für jeden Service-Zustandswechsel ausgeführt wird. Der globale
Eventhandler wird direkt vor dem Eventhandler ausgeführt, den Sie optional in jeder Service-Definition angeben können. Das
Befehls-Argument ist der Kurzname eines Befehls, den Sie in Ihrer Objektkonfigurationsdatei angeben.
Die maximale Ausführungszeit dieses Befehls kann durch die event_handler_timeout-Option angegeben werden.
Mehr Informationen zu Eventhandlern finden Sie hier.
Ruhezeit zwischen Prüfungen (Inter-Check Sleep Time) |
Format: |
sleep_time=<seconds> |
Beispiel: |
sleep_time=1 |
Dies ist die Anzahl von Sekunden, die Nagios "schlafen" wird, bevor es in der Planungswarteschlange (scheduling queue) nach weiteren auszuführenden
Host- oder Service-Prüfungen schaut. Beachten Sie, dass Nagios nur schlafen wird, nachdem es anstehende Service-Prüfungen erledigt hat, die
in Verzug geraten waren.
Verzögerungsmethode für Service-Prüfungen (Service Inter-Check Delay Method) |
Format: |
service_inter_check_delay_method=<n/d/s/x.xx> |
Beispiel: |
service_inter_check_delay_method=s |
Diese Option erlaubt Ihnen die Kontrolle darüber, wie Service-Prüfungen anfänglich in der Planungswarteschlange "ausgebreitet" werden.
Die Verwendung einer "schlauen" Verzögerungsberechnung (der Standard) veranlasst Nagios, ein durchschnittliches Prüfintervall zu berechnen
und die anfänglichen Prüfungen aller Services über dieses Intervall zu verteilen, um dadurch CPU-Lastspitzen zu eliminieren. Keine
Verzögerung zu benutzen wird nicht empfohlen, weil es dafür sorgt, dass die Ausführung aller Service-Prüfungen zur gleichen
Zeit geplant wird. Das bedeutet, dass Sie generell hohe CPU-Spitzen haben werden, wenn die Services alle parallel ausgeführt werden.
Mehr Informationen dazu, wie die Verzögerung von Service-Prüfungen die Planung dieser Prüfungen beeinflusst, finden Sie
hier. Die Werte sind wie folgt:
- n = keine (none) Verzögerung benutzen - planen, dass alle Service-Prüfungen sofort ausgeführt werden (d.h. zur gleichen Zeit!)
- d = eine "dumme" (dumb) Verzögerung von einer Sekunde zwischen Service-Prüfungen benutzen
- s = eine "schlaue" (smart) Verzögerungsberechnung verwenden, um die Service-Prüfungen gleichmäßig zu verteilen (Default)
- x.xx = eine benutzerdefinierte Verzögerung von x.xx Sekunden zwischen den Prüfungen benutzen
maximale Service-Prüfungsverteilung (Maximum Service Check Spread) |
Format: |
max_service_check_spread=<minutes> |
Beispiel: |
max_service_check_spread=30 |
Diese Option legt die maximale Anzahl in Minuten fest vom Nagios-Start bis zur Ausführung aller (regelmäßig geplanten)
Service-Prüfungen. Diese Option wird automatisch die Verzögerungsmethode für Service-Prüfungen
anpassen (falls notwendig), um sicherzustellen, dass die anfänglichen Prüfungen aller Services in dem Zeitrahmen stattfinden, den Sie angeben.
Generell wird diese Optionen keine Auswirkung auf die Planung von Service-Prüfungen haben, wenn die Planungsinformationen mit Hilfe der
use_retained_scheduling_info-Option aufbewahrt werden. Standardwert ist 30 (Minuten).
Service-Verschachtelungsfaktor (Service Interleave Factor) |
Format: |
service_interleave_factor=<s|x> |
Beispiel: |
service_interleave_factor=s |
Diese Variable legt fest, wie Service-Prüfungen verschachtelt werden. Verschachtelung erlaubt eine gleichmäßigere Verteilung von
Service-Prüfungen, reduzierte Last auf entfernten Hosts und schnellere Erkennung von Host-Problemen. Das Setzen des Wertes auf 1 ist gleichbedeutend
mit keiner Verschachtelung der Service-Prüfungen (so arbeiteten die Nagios-Version bis 0.0.5). Setzen Sie diesen Wert auf s (schlau/smart)
für die automatische Berechnung, solange Sie keinen bestimmten Grund für die Änderung haben. Der beste Weg zum Verständnis, wie
Verschachtelung funktioniert, ist der Blick auf das status CGI (detail view), während Nagios startet.
Sie sollten sehen, dass die Service-Prüfergebnisse verteilt werden, während sie auftauchen. Mehr Informationen dazu, wie Verschachtelung
funktioniert, finden Sie hier.
- x = eine Zahl gleich oder größer 1, die den zu benutzenden Verschachtelungsfaktor angibt. Ein Verschachtelungsfaktor von 1 bedeutet
keine Verschachtelung von Service-Prüfungen
- s = eine "schlaue" (smart) Verschachtelungsberechnung benutzen (Default)
maximale Anzahl gleichzeitiger Service-Prüfungen (Maximum Concurrent Service Checks) |
Format: |
max_concurrent_checks=<max_checks> |
Beispiel: |
max_concurrent_checks=20 |
Diese Option erlaubt Ihnen die Angabe der maximalen Anzahl von Service-Prüfungen, die zu irgendeiner Zeit gleichzeitig ausgeführt werden.
Das Angeben eines Wertes von 1 verhindert grundsätzlich die Ausführung von parallelen Service-Prüfungen. Der Wert 0 (der Standard)
sorgt dafür, dass es keine Beschränkung der Anzahl von gleichzeitig ausgeführten Service-Prüfungen gibt. Sie müssen den Wert
auf der Basis der Systemressourcen anpassen, die Ihr Nagios-Rechner zur Verfügung stellt, da er direkt die maximale Last des System beeinflusst
(Prozessorauslastung, Speicher, usw.). Mehr Informationen dazu, wie viele parallele Prüfungen Sie zulassen sollten, finden Sie
hier.
Prüfergebnis-Erntefrequenz (Check Result Reaper Frequency) |
Format: |
check_result_reaper_frequency=<frequency_in_seconds> |
Beispiel: |
check_result_reaper_frequency=5 |
Diese Option erlaubt Ihnen die Kontrolle über die Frequenz in Sekunden der Prüfergebnis-"Ernte"-Ereignisse.
"Ernte"-Ereignisse verarbeiten die Ergebnisse von Host- und Service-Prüfungen, die beendet wurden. Diese Ereignisse bilden den Kern der
Überwachungslogik von Nagios.
maximale Prüfergebnis-Erntezeit (Maximum Check Result Reaper Time) |
Format: |
max_check_result_reaper_time=<seconds> |
Beispiel: |
max_check_result_reaper_time=30 |
Diese Option erlaubt Ihnen die Kontrolle der maximalen Zeit in Sekunden, die Host- und Service-Prüfergebnis-"Ernte"-Ereignisse laufen
dürfen. "Ernte"-Ereignisse verarbeiten die Ergebnisse von Host- und Service-Prüfungen, die beendet sind. Wenn es eine Menge von Ergebnissen
zu verarbeiten gibt, können Ernte-Ereignisse lange brauchen, um zu enden, was die pünktliche Ausführung von neuen Host- und Service-Prüfungen
verzögern könnte. Diese Variable erlaubt Ihnen die Begrenzung der Zeit, die ein einzelnes Ernte-Ereignis laufen darf, bevor es die Kontrolle
an andere Teile der Nagios-Überwachungslogik zurückgibt.
Prüfergebnis-Pfad (Check Result Path) |
Format: |
check_result_path=<path> |
Beispiel: |
check_result_path=/var/spool/nagios/checkresults |
Diese Option legt fest, welches Verzeichnis Nagios benutzen wird, um temporär Host- und Service-Prüfergebnisse zu speichern, bevor sie
verarbeitet werden. Diese Verzeichnis sollte nicht benutzt werden, um andere Dateien dort zu speichern, weil Nagios dieses Verzeichnis periodisch
von alten Dateien säubern wird (mehr Informationen dazu finden Sie bei der max_check_result_file_age-Option).
Anmerkung: stellen Sie sicher, dass nur eine einzelne Nagios-Instanz Zugriff auf den Prüfergebnispfad hat. Wenn mehrere Nagios-Instanzen Zugriff
auf das gleiche Verzeichnis haben, werden Sie Probleme bekommen, weil Prüfergebnisse von der falschen Nagios-Instanz verarbeitet wurden!
maximales Alter der Prüfergebnisdatei (Max Check Result File Age) |
Format: |
max_check_result_file_age=<seconds> |
Beispiel: |
max_check_result_file_age=3600 |
Diese Option legt das maximale Alter in Sekunden fest, die Daten aus den Prüfergebnisdateien im check_result_path-Verzeichnis
als gültig angesehen werden. Prüfergebnisdateien, die älter als dieser Schwellwert sind, werden von Nagios gelöscht und die darin
enthaltenen Daten werden nicht verarbeitet. Durch die Angabe eines Wertes von Null (0) bei dieser Option wird Nagios alle Prüfergebnisdateien
verarbeiten - selbst wenn sie älter als Ihre Hardware sind :-).
Verzögerungsmethode für Host-Prüfungen (Host Inter-Check Delay Method) |
Format: |
host_inter_check_delay_method=<n/d/s/x.xx> |
Beispiel: |
host_inter_check_delay_method=s |
Diese Option erlaubt Ihnen die Kontrolle darüber, wie Host-Prüfungen, die für eine regelmäßige Prügung geplant sind,
anfänglich in der Planungswarteschlange "ausgebreitet" werden.
Die Verwendung einer "schlauen" Verzögerungsberechnung (der Standard) veranlasst Nagios, ein durchschnittliches Prüfintervall zu berechnen
und die anfänglichen Prüfungen aller Hosts über dieses Intervall zu verteilen, um dadurch CPU-Lastspitzen zu eliminieren. Keine
Verzögerung zu benutzen wird generell nicht empfohlen, weil es dafür sorgt, dass die Ausführung aller Host-Prüfungen zur
gleichen Zeit geplant wird. Mehr Informationen dazu, wie die Verzögerung von Host-Prüfungen die Planung dieser Prüfungen beeinflusst,
finden Sie hier. Die Werte sind wie folgt:
- n = keine (none) Verzögerung benutzen - planen, dass alle Host-Prüfungen sofort ausgeführt werden (d.h. zur gleichen Zeit!)
- d = eine "dumme" (dumb) Verzögerung von einer Sekunde zwischen Host-Prüfungen benutzen
- s = eine "schlaue" (smart) Verzögerungsberechnung verwenden, um die Host-Prüfungen gleichmäßig zu verteilen (Default)
- x.xx = eine benutzerdefinierte Verzögerung von x.xx Sekunden zwischen den Prüfungen benutzen
maximale Host-Prüfungsverteilung (Maximum Host Check Spread) |
Format: |
max_host_check_spread=<minutes> |
Beispiel: |
max_host_check_spread=30 |
Diese Option legt die maximale Anzahl in Minuten fest vom Nagios-Start bis zur Ausführung aller (regelmäßig geplanten)
Host-Prüfungen. Diese Option wird automatisch die Verzögerungsmethode für Host-Prüfungen
anpassen (falls notwendig), um sicherzustellen, dass die anfänglichen Prüfungen aller Hosts in dem Zeitrahmen stattfinden, den Sie angeben.
Generell wird diese Optionen keine Auswirkung auf die Planung von Host-Prüfungen haben, wenn die Planungsinformationen mit Hilfe der
use_retained_scheduling_info-Option aufbewahrt werden. Standardwert ist 30 (Minuten).
Zeitintervalllänge (Timing Interval Length) |
Format: |
interval_length=<seconds> |
Beispiel: |
interval_length=60 |
Dies ist die Zahl von Sekunden pro "Zeitintervall" (unit interval), das für die Steuerung in der Planungswarteschlange, bei erneuten
Benachrichtigungen usw. verwendet wird. "Zeitintervalle" werden in den Objektkonfigurationsdateien benutzt, um festzulegen, wie oft eine Service-Prüfung
ausgeführt, ein Kontakt erneut informiert wird usw.
Wichtig: Der Standardwert hierfür ist auf 60 eingestellt, was bedeutet, dass ein "Zeitwert" von eins (1) in der
Objektkonfigurationsdatei 60 Sekunden bedeutet (eine Minute). Ich habe keine anderen Werte für diese Variable ausprobiert, also machen Sie
Änderungen auf Ihr eigenes Risiko, wenn Sie etwas anderes einstellen!
automatische Wiedereinplanungs-Option (Auto-Rescheduling Option) |
Format: |
auto_reschedule_checks=<0/1> |
Beispiel: |
auto_reschedule_checks=1 |
Diese Option legt fest, ob Nagios versucht, aktive Host- und Service-Prüfungen automatisch erneut einzuplanen, um sie über die Zeit
"auszugleichen" (smooth out). Dies kann helfen, die Last des Überwachungsrechners auszubalancieren, da es versucht, die Zeit zwischen aufeinander
folgenden Prüfungen einheitlich zu halten, auf Kosten der Ausführung von Prüfungen mit einer rigideren Planung.
WARNUNG: DIES IST EIN EXPERIMENTELLES FEATURE UND KÖNNTE IN DER ZUKUNFT ENTFERNT WERDEN. DIE AKTIVIERUNG DIESER OPTION KANN
DIE LEISTUNG REDUZIEREN - STATT SIE ZU ERHÖHEN - WENN SIE UNGEEIGNET BENUTZT WIRD!
automatisches Wiedereinplanungs-Intervall (Auto-Rescheduling Interval) |
Format: |
auto_rescheduling_interval=<seconds> |
Beispiel: |
auto_rescheduling_interval=30 |
Diese Option legt fest, wie oft (in Sekunden) Nagios versuchen wird, automatisch Prüfungen erneut einzuplanen. Diese Option ist nur wirksam,
wenn die auto_reschedule_checks-Option aktiviert ist. Standard ist 30 Sekunden.
WARNUNG: DIES IST EIN EXPERIMENTELLES FEATURE UND KÖNNTE IN DER ZUKUNFT ENTFERNT WERDEN. DIE AKTIVIERUNG DIESER OPTION KANN
DIE LEISTUNG REDUZIEREN - STATT SIE ZU ERHÖHEN - WENN SIE UNGEEIGNET BENUTZT WIRD!
automatisches Wiedereinplanungsfenster (Auto-Rescheduling Window) |
Format: |
auto_rescheduling_window=<seconds> |
Beispiel: |
auto_rescheduling_window=180 |
Diese Option legt das Zeit-"Fenster" fest (in Sekunden), auf das Nagios blickt, wenn es automatisch Prüfungen erneut einplant. Nur Host-
und Service-Prüfungen, die in den nächsten X Sekunden (festgelegt durch diese Variable) stattfinden, werden erneut eingeplant. Diese Option
ist nur wirksam, wenn die auto_reschedule_checks-Option aktiviert ist. Standard ist 180 Sekunden (3 Minuten).
WARNING: DIES IST EIN EXPERIMENTELLES FEATURE UND KÖNNTE IN DER ZUKUNFT ENTFERNT WERDEN. DIE AKTIVIERUNG DIESER OPTION KANN
DIE LEISTUNG REDUZIEREN - STATT SIE ZU ERHÖHEN - WENN SIE UNGEEIGNET GENUTZT WIRD!
Option aggressive Host-Prüfung (Aggressive Host Checking Option) |
Format: |
use_aggressive_host_checking=<0/1> |
Beispiel: |
use_aggressive_host_checking=0 |
Nagios versucht, schlau zu sein, wie und wann es den Status von Hosts prüft. Im Allgemeinen wird die Deaktivierung dieser Option Nagios dazu
veranlassen, einige schlauere Entscheidungen zu treffen und Hosts ein bisschen schneller zu prüfen. Die Aktivierung dieser Option wird den
Zeitaufwand zur Prüfung von Hosts erhöhen, aber es mag die Zuverlässigkeit ein wenig steigern. Solange Sie keine Probleme damit haben,
dass Nagios die Erholung eines Hosts nicht korrekt erkennt, würde ich empfehlen, diese Option nicht zu aktivieren.
- 0 = keine aggressive Host-Prüfung benutzen (Default)
- 1 = aggressive Host-Prüfung benutzen
Option passive Host-Prüfung übersetzen (Translate Passive Host Checks Option) |
Format: |
translate_passive_host_checks=<0/1> |
Beispiel: |
translate_passive_host_checks=1 |
Diese Option legt fest, ob Nagios DOWN/UNREACHABLE-Ergebnisse von passiven Host-Prüfungen in ihre "korrekten" Zustände vom Standpunkt
der lokalen Nagios-Instanz aus übersetzt. Dies kann sehr nützlich in verteilten und Failover-Umgebungen sein. Mehr Informationen zur
Übersetzung von passiven Prüfergebnissen finden Sie hier.
- 0 = Prüfübersetzung deaktivieren (Default)
- 1 = Prüfübersetzung aktivieren
Option passive Host-Prüfungen sind SOFT (Passive Host Checks Are SOFT Option) |
Format: |
passive_host_checks_are_soft=<0/1> |
Beispiel: |
passive_host_checks_are_soft=1 |
Diese Option legt fest, ob Nagios passive Host-Prüfungen als HARD- oder SOFT-Zustände behandelt.
Per Default wird ein passives Prüfergebnis einen Host in einen HARD-Status setzen. Sie können dieses Verhalten
durch aktivieren dieser Option verändern.
- 0 = passive Host-Prüfungen sind HARD (Default)
- 1 = passive Host-Prüfungen sind SOFT
Option vorausschauende Host-Abhängigkeitsprüfung (Predictive Host Dependency Checks Option) |
Format: |
enable_predictive_host_dependency_checks=<0/1> |
Beispiel: |
enable_predictive_host_dependency_checks=1 |
Diese Option legt fest, ob Nagios vorausschauende Prüfungen von Hosts ausführen soll, von denen andere abhängig sind (wie in
Host-Abhängigkeiten definiert) für einen bestimmten Host, dessen Zustand wechselt.
Vorausschauende Prüfungen helfen dabei, die Abhängigkeitslogik so genau wie möglich zu machen. Mehr Informationen darüber, wie
vorausschauende Prüfungen arbeiten, finden Sie hier.
- 0 = vorausschauende Prüfungen deaktivieren
- 1 = vorausschauende Prüfungen aktivieren (Default)
Option vorausschauende Service-Abhängigkeitsprüfung (Predictive Service Dependency Checks Option) |
Format: |
enable_predictive_service_dependency_checks=<0/1> |
Beispiel: |
enable_predictive_service_dependency_checks=1 |
Diese Option legt fest, ob Nagios vorausschauende Prüfungen von Services ausführen soll, von denen andere abhängig sind (wie in
Service-Abhängigkeiten definiert) für einen bestimmten Service, dessen Zustand wechselt.
Vorausschauende Prüfungen helfen dabei, die Abhängigkeitslogik so genau wie möglich zu machen. Mehr Informationen darüber, wie
vorausschauende Prüfungen arbeiten, finden Sie hier.
- 0 = vorausschauende Prüfungen deaktivieren
- 1 = vorausschauende Prüfungen aktivieren (Default)
Horizont für zwischengespeicherte Host-Prüfungen (Cached Host Check Horizon) |
Format: |
cached_host_check_horizon=<seconds> |
Beispiel: |
cached_host_check_horizon=15 |
Diese Option legt die maximale Zeit (in Sekunden) fest, die der Zustand einer vorherigen Host-Prüfung als aktuell angesehen wird. Zwischengespeicherte
Host-Zustände (von Host-Prüfungen, die aktueller sind als die in diesem Wert angegebene Zeit) können die Leistung von Host-Prüfungen
immens steigern. Ein zu hoher Wert für diese Option kann in (vorübergehend) ungenauen Host-Zuständen resultieren, während ein
niedriger Wert zu einem Leistungseinbruch bei Host-Prüfungen führen kann. Benutzen Sie einen Wert von 0, wenn Sie die Zwischenspeicherung
von Host-Prüfungen deaktivieren wollen. Mehr Informationen zu zwischengespeicherten Prüfungen finden Sie hier.
Horizont für zwischengespeicherte Service-Prüfungen (Cached Service Check Horizon) |
Format: |
cached_service_check_horizon=<seconds> |
Beispiel: |
cached_service_check_horizon=15 |
Diese Option legt die maximale Zeit (in Sekunden) fest, die der Zustand einer vorherigen Service-Prüfung als aktuell angesehen wird. Zwischengespeicherte
Service-Zustände (von Service-Prüfungen, die aktueller sind als die in diesem Wert angegebene Zeit) können die Leistung von Service-Prüfungen
steigern, wenn eine Menge von Service-Abhängigkeiten benutzt werden. Ein zu hoher Wert
für diese Option kann in (vorübergehend) ungenauen Service-Zuständen resultieren, während ein niedriger Wert zu einem
Leistungseinbruch bei Service-Prüfungen führen kann. Benutzen Sie einen Wert von 0, wenn Sie die Zwischenspeicherung von
Service-Prüfungen deaktivieren wollen. Mehr Informationen zu zwischengespeicherten Prüfungen finden Sie hier.
Option Verbesserungen für große Installationen (Large Installation Tweaks Option) |
Format: |
use_large_installation_tweaks=<0/1> |
Beispiel: |
use_large_installation_tweaks=0 |
Diese Option legt fest, ob der Nagios-Daemon verschiedene Abkürzungen nimmt, um die Leistung zu steigern. Diese Abkürzungen resultieren im
Verlust einiger Features, aber große Installationen werden wahrscheinlich einen hohen Nutzen davon haben. Mehr Informationen, welche
Optimierungen vorgenommen werden, wenn Sie diese Option aktivieren, finden Sie hier.
- 0 = keine Verbesserungen verwenden (Default)
- 1 = Verbesserungen verwenden
Kindprozess-Speicher-Option (Child Process Memory Option) |
Format: |
free_child_process_memory=<0/1> |
Beispiel: |
free_child_process_memory=0 |
Diese Option legt fest, ob Nagios Speicher in Kindprozessen freigibt, wenn sie vom Hauptprozess ge"fork()"ed werden. Per Default gibt Nagios den
Speicher frei. Wenn allerdings die use_large_installation_tweaks-Option aktiviert ist, wird der Speicher
nicht freigegeben. Durch Definition dieser Option in Ihrer Konfigurationsdatei sind Sie in der Lage, das Verhalten einzustellen, das Sie möchten.
- 0 = Speicher nicht freigeben
- 1 = Speicher freigeben
Kindprozesse zweimal "fork()"en |
Format: |
child_processes_fork_twice=<0/1> |
Beispiel: |
child_processes_fork_twice=0 |
Diese Option legt fest, ob Nagios Kindprozesse zweimal "fork()"ed, wenn es Host- und Service-Prüfungen ausführt. Per Default "fork()"ed
Nagios zweimal. Wenn allerdings die use_large_installation_tweaks-Option aktiviert ist, "fork()"ed
Nagios nur einmal. Durch Definition dieser Option in Ihrer Konfigurationsdatei sind Sie in der Lage, das Verhalten einzustellen, das Sie möchten.
- 0 = nur einmal "fork()"en
- 1 = zweimal "fork()"en
Format: |
enable_environment_macros=<0/1> |
Beispiel: |
enable_environment_macros=0 |
Diese Option legt fest, ob Nagios alle Standard-Makros als Umgebungsvariablen für Prüfungen, Benachrichtigungen,
Eventhandler usw. zur Verfügung stellt. In großen Installationen kann dies problematisch sein, weil es zusätzlichen Speicher (und
wichtiger) mehr CPU benötigt, um die Werte aller Makros zu berechnen und sie der Umgebung zur Verfügung zu stellen.
- 0 = Makros nicht als Umgebungsvariablen verfügbar machen
- 1 = Makros als Umgebungsvariablen verfügbar machen (Default)
Format: |
enable_flap_detection=<0/1> |
Beispiel: |
enable_flap_detection=0 |
Diese Option legt fest, ob Nagios versucht festzustellen, ob Hosts und Services "flattern". Flattern tritt auf, wenn ein Host oder Service zu schnell
zwischen verschiedenen Zuständen wechselt, was in einem Bombardement von Benachrichtigungen resultiert. Wenn Nagios erkennt, dass ein Host oder
Service flattert, wird es vorübergehend Benachrichtigungen für diesen Host/Service unterdrücken, bis das Flattern endet. Flattererkennung
ist sehr experimentell zu diesem Zeitpunkt, also benutzen Sie diese Option mit Vorsicht! Mehr Informationen dazu, wie Flattererkennung und Behandlung
funktionieren, finden Sie hier. Anmerkung: Wenn Sie Statusaufbewahrung aktiviert
haben, wird Nagios diese Einstellung ignorieren, wenn es (erneut) startet und die letzte bekannte Einstellung dieser Option nutzen (wie sie in der
Statusaufbewahrungsdatei abgelegt ist), es sei denn, Sie haben die
use_retained_program_state-Option deaktiviert. Wenn Sie diese Option ändern möchten, während die
Statusaufbewahrung aktiviert ist (und die Option use_retained_program_state aktiviert ist), müssen Sie den
entsprechenden externen Befehl benutzen oder sie über das Web-Interface ändern.
- 0 = Flattererkennung deaktivieren (Default)
- 1 = Flattererkennung aktivieren
niedriger Service-Flatterschwellwert (Low Service Flap Threshold) |
Format: |
low_service_flap_threshold=<percent> |
Beispiel: |
low_service_flap_threshold=25.0 |
Diese Option wird benutzt, um den niedrigen Schwellwert für die Erkennung von Service-Flattern zu setzen. Mehr Informationen dazu, wie
Flattererkennung und Behandlung funktionieren (und wie diese Option Dinge beeinflusst), finden Sie hier.
hoher Service-Flatterschwellwert (High Service Flap Threshold) |
Format: |
high_service_flap_threshold=<percent> |
Beispiel: |
high_service_flap_threshold=50.0 |
Diese Option wird benutzt, um den hohen Schwellwert für die Erkennung von Service-Flattern zu setzen. Mehr Informationen dazu, wie
Flattererkennung und Behandlung funktionieren (und wie diese Option Dinge beeinflusst), finden Sie hier.
niedriger Host-Flatterschwellwert (Low Host Flap Threshold) |
Format: |
low_host_flap_threshold=<percent> |
Beispiel: |
low_host_flap_threshold=25.0 |
Diese Option wird benutzt, um den niedrigen Schwellwert für die Erkennung von Host-Flattern zu setzen. Mehr Informationen dazu, wie
Flattererkennung und Behandlung funktionieren (und wie diese Option Dinge beeinflusst), finden Sie hier.
hoher Host-Flatterschwellwert (High Host Flap Threshold) |
Format: |
high_host_flap_threshold=<percent> |
Beispiel: |
high_host_flap_threshold=50.0 |
Diese Option wird benutzt, um den hohen Schwellwert für die Erkennung von Host-Flattern zu setzen. Mehr Informationen dazu, wie
Flattererkennung und Behandlung funktionieren (und wie diese Option Dinge beeinflusst), finden Sie hier.
Soft-Statusabhängigkeitsoption (Soft State Dependencies Option) |
Format: |
soft_state_dependencies=<0/1> |
Beispiel: |
soft_state_dependencies=0 |
Diese Option legt fest, ob Nagios Soft-Statusinformationen benutzen soll, um Host- und Serviceabhängigkeiten zu
prüfen. Normalerweise wird Nagios nur den letzten Hard-Status des Hosts oder Service verwenden, wenn Abhängigkeiten geprüft werden.
Wenn Sie möchten, dass der letzte Zustand (unabhängig davon, ob es ein Soft- oder Hard-Zustandstyp ist),
dann aktivieren Sie diese Option.
- 0 = keine Soft-Status-Abhängigkeiten benutzen (Default)
- 1 = Soft-Status-Abhängigkeiten benutzen
Service-Prüfungs-Zeitüberschreitung (Service Check Timeout) |
Format: |
service_check_timeout=<seconds> |
Beispiel: |
service_check_timeout=60 |
Dies ist die maximale Zahl von Sekunden, die Service-Prüfungen laufen dürfen. Wenn Prüfungen diese Grenze überschreiten, werden sie
abgebrochen (killed) und ein CRITICAL-Zustand wird zurückgeliefert. Außerdem wird ein Fehler protokolliert.
Es gibt oft eine weitverbreitete Verwirrung, was diese Option wirklich tut. Es ist als allerletzter Versuch gedacht, wenn Plugins sich "daneben benehmen"
und nicht innerhalb einer bestimmten Zeit enden. Sie sollte auf einen hohen Wert (z.B. 60 Sekunden oder mehr) gesetzt werden, so dass jede
Service-Prüfung normalerweise innerhalb dieser Zeit beendet ist. Wenn eine Service-Prüfung länger läuft, dann wird Nagios diese
Prüfung abbrechen, weil es denkt, dass es sich um einen außer Kontrolle geratenen Prozess handelt.
Host-Prüfungs-Zeitüberschreitung (Host Check Timeout) |
Format: |
host_check_timeout=<seconds> |
Beispiel: |
host_check_timeout=60 |
Dies ist die maximale Zahl von Sekunden, die Host-Prüfungen laufen dürfen. Wenn Prüfungen diese Grenze überschreiten, werden sie
abgebrochen (killed), ein CRITICAL-Zustand wird zurückgeliefert und der Host als "DOWN" angesehen. Außerdem wird ein Fehler protokolliert.
Es gibt oft eine weitverbreitete Verwirrung, was diese Option wirklich tut. Es ist als allerletzter Versuch gedacht, wenn Plugins sich "daneben benehmen"
und nicht innerhalb einer bestimmten Zeit enden. Sie sollte auf einen hohen Wert (z.B. 60 Sekunden oder mehr) gesetzt werden, so dass jede
Host-Prüfung normalerweise innerhalb dieser Zeit beendet ist. Wenn eine Host-Prüfung länger läuft, dann wird Nagios diese
Prüfung abbrechen, weil es denkt, dass es sich um einen außer Kontrolle geratenen Prozess handelt.
Eventhandler-Zeitüberschreitung |
Format: |
event_handler_timeout=<seconds> |
Beispiel: |
event_handler_timeout=60 |
Dies ist die maximale Zahl von Sekunden, die Eventhandler laufen dürfen. Wenn ein Eventhandler diese Grenze
überschreitet, wird er abgebrochen (killed) und eine Warnung protokolliert.
Es gibt oft eine weitverbreitete Verwirrung, was diese Option wirklich tut. Es ist als allerletzter Versuch gedacht, wenn Befehle sich "daneben benehmen"
und nicht innerhalb einer bestimmten Zeit enden. Sie sollte auf einen hohen Wert (z.B. 60 Sekunden oder mehr) gesetzt werden, so dass jeder
Eventhandler normalerweise innerhalb dieser Zeit beendet ist. Wenn ein Eventhandler länger läuft, dann wird Nagios diesen
Eventhandler abbrechen, weil es denkt, dass es sich um einen außer Kontrolle geratenen Prozess handelt.
Benachrichtigungs-Zeitüberschreitung |
Format: |
notification_timeout=<seconds> |
Beispiel: |
notification_timeout=60 |
Dies ist die maximale Zahl von Sekunden, die Benachrichtigungsbefehle laufen dürfen. Wenn ein Benachrichtigungsbefehl diese Grenze
überschreitet, wird er abgebrochen (killed) und eine Warnung protokolliert.
Es gibt oft eine weitverbreitete Verwirrung, was diese Option wirklich tut. Es ist als allerletzter Versuch gedacht, wenn Befehle sich "daneben benehmen"
und nicht innerhalb einer bestimmten Zeit enden. Sie sollte auf einen hohen Wert (z.B. 60 Sekunden oder mehr) gesetzt werden, so dass jeder
Benachrichtigungsbefehl normalerweise innerhalb dieser Zeit beendet ist. Wenn ein Benachrichtigungsbefehl länger läft, dann wird Nagios diesen
Benachrichtigungsbefehl abbrechen, weil es denkt, dass es sich um einen außer Kontrolle geratenen Prozess handelt.
Zwangsverfolgungs-Service-Prozessor-Zeitüberschreitung (Obsessive Compulsive Service Processor Timeout) |
Format: |
ocsp_timeout=<seconds> |
Beispiel: |
ocsp_timeout=5 |
Dies ist die maximale Zahl von Sekunden, die ein Zwangsverfolgungs-Service-Prozessor-Befehl (obsessive compulsive service processor command) laufen darf.
Wenn ein Befehl diese Grenze überschreitet, wird er abgebrochen (killed) und eine Warnung protokolliert.
Zwangsverfolgungs-Host-Prozessor-Zeitüberschreitung (Obsessive Compulsive Host Processor Timeout) |
Format: |
ochp_timeout=<seconds> |
Beispiel: |
ochp_timeout=5 |
Dies ist die maximale Zahl von Sekunden, die ein Zwangsverfolgungs-Host-Prozessor-Befehl (obsessive compulsive host processor command) laufen darf.
Wenn ein Befehl diese Grenze überschreitet, wird er abgebrochen (killed) und eine Warnung protokolliert.
Performance-Daten-Prozessorbefehls-Zeitüberschreitung (Performance Data Processor Command Timeout) |
Format: |
perfdata_timeout=<seconds> |
Beispiel: |
perfdata_timeout=5 |
Dies ist die maximale Zahl von Sekunden, die ein Host-Performance-Daten-Prozessorbefehl (host performance data processor command) oder
Service-Performance-Daten-Prozessorbefehl (service performance data processor command) laufen darf.
Wenn ein Befehl diese Grenze überschreitet, wird er abgebrochen (killed) und eine Warnung protokolliert.
Verfolgung-von-Services-Option (Obsess Over Services Option) |
Format: |
obsess_over_services=<0/1> |
Beispiel: |
obsess_over_services=1 |
Dieser Wert legt fest, ob Nagios Service-Prüfergebnisse "verfolgt" (obsess) und den
Zwangsverfolgungs-Service-Prozessorbefehl ausführt, den Sie angeben. Ich weiß - komischer Name, aber das
ist alles, was mir eingefallen ist. Diese Option ist nützlich, um verteilte Überwachung durchzuführen.
Wenn Sie keine verteilte Überwachung machen, dann aktivieren Sie diese Option nicht.
- 0 = Services nicht verfolgen (Default)
- 1 = Services verfolgen
Zwangsverfolgungs-Service-Prozessorbefehl (Obsessive Compulsive Service Processor Command) |
Format: |
ocsp_command=<command> |
Beispiel: |
ocsp_command=obsessive_service_handler |
Diese Option erlaubt Ihnen einen Befehl anzugeben, der nach jeder Service-Prüfung ausgeführt wird, was bei
verteilter Überwachung nützlich sein kann. Dieser Befehl wird nach Eventhandler-
oder Benachrichtigungs-Befehlen ausgeführt. Das command-Argument ist der Kurzname einer
command-Definition, die Sie in Ihrer Objektkonfigurationsdatei angeben. Die maximale Zeit, die dieser
Befehl laufen darf, wird mit der ocsp_timeout-Option kontrolliert. Mehr Informationen zu verteilter Überwachung finden
Sie hier. Dieser Befehl wird nur ausgeführt, wenn die obsess_over_services-Option
global aktiviert ist und wenn die obsess_over_service-Direktive in der Service-Definition aktiviert ist.
Verfolgung-von-Hosts-Option (Obsess Over Hosts Option) |
Format: |
obsess_over_hosts=<0/1> |
Beispiel: |
obsess_over_hosts=1 |
Dieser Wert legt fest, ob Nagios Host-Prüfergebnisse "verfolgt" (obsess) und den
Zwangsverfolgungs-Host-Prozessorbefehl ausführt, den Sie angeben. Ich weiß - komischer Name, aber das
ist alles, was mir eingefallen ist. Diese Option ist nützlich, um verteilte Überwachung durchzuführen.
Wenn Sie keine verteilte Überwachung machen, dann aktivieren Sie diese Option nicht.
- 0 = Hosts nicht verfolgen (Default)
- 1 = Hosts verfolgen
Zwangsverfolgungs-Host-Prozessorbefehl (Obsessive Compulsive Host Processor Command) |
Format: |
ochp_command=<command> |
Beispiel: |
ochp_command=obsessive_host_handler |
Diese Option erlaubt Ihnen einen Befehl anzugeben, der nach jeder Host-Prüfung ausgeführt wird, was bei
verteilter Überwachung nützlich sein kann. Dieser Befehl wird nach Eventhandler-
oder Benachrichtigungs-Befehlen ausgeführt. Das command-Argument ist der Kurzname einer
command-Definition, die Sie in Ihrer Objektkonfigurationsdatei angeben. Die maximale Zeit, die dieser
Befehl laufen darf, wird mit der ochp_timeout-Option kontrolliert. Mehr Informationen zu verteilter Überwachung finden
Sie hier. Dieser Befehl wird nur ausgeführt, wenn die obsess_over_hosts-Option
global aktiviert ist und wenn die obsess_over_hosts-Direktive in der Host-Definition aktiviert ist.
Performance-Daten-Verarbeitungsoption (Performance Data Processing Option) |
Format: |
process_performance_data=<0/1> |
Beispiel: |
process_performance_data=1 |
Dieser Wert legt fest, ob Nagios Performance-Daten von Host- und Service-Prüfungen verarbeitet.
- 0 = keine Performance-Daten verarbeiten (Default)
- 1 = Performance-Daten verarbeiten
Host-Performance-Daten-Verarbeitungsbefehl (Host Performance Data Processing Command) |
Format: |
host_perfdata_command=<command> |
Beispiel: |
host_perfdata_command=process-host-perfdata |
Diese Option erlaubt es Ihnen, einen Befehl anzugeben, der nach jeder Host-Prüfung ausgeführt wird, um
Host-Performance-Daten zu verarbeiten, die von der Prüfung zurückgeliefert worden sein könnten. Das
command-Argument ist der Kurzname einer command-Definition, die Sie in Ihrer Objektkonfigurationsdatei
angeben. Dieser Befehl wird nur ausgeführt, wenn die process_performance_data-Option
global aktiviert ist und wenn die process_perf_data-Direktive in der Host-Definition aktiviert ist.
Service-Performance-Daten-Verarbeitungsbefehl (Service Performance Data Processing Command) |
Format: |
service_perfdata_command=<command> |
Beispiel: |
service_perfdata_command=process-service-perfdata |
Diese Option erlaubt es Ihnen, einen Befehl anzugeben, der nach jeder Service-Prüfung ausgeführt wird, um
Service-Performance-Daten zu verarbeiten, die von der Prüfung zurückgeliefert worden sein könnten. Das
command-Argument ist der Kurzname einer command-Definition, die Sie in Ihrer Objektkonfigurationsdatei
angeben. Dieser Befehl wird nur ausgeführt, wenn die process_performance_data-Option
global aktiviert ist und wenn die process_perf_data-Direktive in der Service-Definition aktiviert ist.
Host-Performance-Daten-Datei (Host Performance Data File) |
Format: |
host_perfdata_file=<file_name> |
Beispiel: |
host_perfdata_file=/usr/local/nagios/var/host-perfdata.dat |
Diese Option erlaubt es Ihnen, eine Datei anzugeben, in die nach jeder Host-Prüfung Performance-Daten geschrieben
werden. Daten werden in die Performance-Datei geschrieben, wie es in der host_perfdata_file_template-Option
angegeben ist. Performance-Daten werden nur in diese Datei geschrieben, wenn die process_performance_data-Option
global aktiviert ist und wenn die process_perf_data-Direktive in der Host-Definition aktiviert ist.
Service-Performance-Daten-Datei (Service Performance Data File) |
Format: |
service_perfdata_file=<file_name> |
Beispiel: |
service_perfdata_file=/usr/local/nagios/var/service-perfdata.dat |
Diese Option erlaubt es Ihnen, eine Datei anzugeben, in die nach jeder Service-Prüfung Performance-Daten geschrieben
werden. Daten werden in die Performance-Datei geschrieben, wie es in der service_perfdata_file_template-Option
angegeben ist. Performance-Daten werden nur in diese Datei geschrieben, wenn die process_performance_data-Option
global aktiviert ist und wenn die process_perf_data-Direktive in der Service-Definition aktiviert ist.
Host-Performance-Daten-Dateivorlage (Host Performance Data File Template) |
Format: |
host_perfdata_file_template=<template> |
Beispiel: |
host_perfdata_file_template=[HOSTPERFDATA]
\t$TIMET$\t$HOSTNAME$\t$HOSTEXECUTIONTIME$
\t$HOSTOUTPUT$\t$HOSTPERFDATA$ |
Diese Option legt fest, welche (und wie) Daten in die Host-Performancedaten-Datei geschrieben werden. Diese Vorlage
kann Makros, Sonderzeichen (\t für Tabulator, \r für Wagenrücklauf (carriage return), \n für
Zeilenvorschub (newline)) und reinen Text enthalten. Nach jedem Schreibvorgang wird ein Zeilenvorschub an die Performancedaten-Datei angehängt.
Service-Performance-Daten-Dateivorlage (Service Performance Data File Template) |
Format: |
service_perfdata_file_template=<template> |
Beispiel: |
service_perfdata_file_template=[SERVICEPERFDATA]
\t$TIMET$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICEEXECUTIONTIME$
\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$ |
Diese Option legt fest, welche (und wie) Daten in die Service-Performancedaten-Datei geschrieben werden. Diese Vorlage
kann Makros, Sonderzeichen (\t für Tabulator, \r für Wagenrücklauf (carriage return), \n für
Zeilenvorschub (newline)) und reinen Text enthalten. Nach jedem Schreibvorgang wird ein Zeilenvorschub an die Performancedaten-Datei angehängt.
Host-Performance-Daten-Dateimodus (Host Performance Data File Mode) |
Format: |
host_perfdata_file_mode=<mode> |
Beispiel: |
host_perfdata_file_mode=a |
Diese Option legt fest, wie die Host-Performance-Datendatei geöffnet wird. Solange die Datei keine "named pipe"
ist, werden Sie diese wahrscheinlich im append-Modus (anhängen) öffnen wollen.
- a = Datei im append-Modus öffnen (Default)
- w = Datei im Write-Modus öffnen
- p = Datei im nicht-blockierenden Schreib-/Lesemodus öffnen (nützlich, wenn man in Pipes schreibt)
Service-Performance-Daten-Dateimodus (Service Performance Data File Mode) |
Format: |
service_perfdata_file_mode=<mode> |
Beispiel: |
service_perfdata_file_mode=a |
Diese Option legt fest, wie die Service-Performance-Datendatei geöffnet wird. Solange die Datei keine "named pipe"
ist, werden Sie diese wahrscheinlich im append-Modus (anhängen) öffnen wollen.
- a = Datei im append-Modus öffnen (Default)
- w = Datei im Write-Modus öffnen
- p = Datei im nicht-blockierenden Schreib-/Lesemodus öffnen (nützlich, wenn man in Pipes schreibt)
Host-Performance-Daten-Dateiverarbeitungsintervall (Host Performance Data File Processing Interval) |
Format: |
host_perfdata_file_processing_interval=<seconds> |
Beispiel: |
host_perfdata_file_processing_interval=0 |
Diese Option erlaubt es Ihnen, das Intervall (in Sekunden) anzugeben, in dem die Host-Performance-Daten-Datei mit dem
Host-Performance-Daten-Dateiverarbeitungsbefehl verarbeitet wird. Ein Wert von 0 gibt an, dass
die Performance-Daten-Datei nicht in regelmäßigen Intervallen verarbeiten werden soll.
Service-Performance-Daten-Dateiverarbeitungsintervall (Service Performance Data File Processing Interval) |
Format: |
service_perfdata_file_processing_interval=<seconds> |
Beispiel: |
service_perfdata_file_processing_interval=0 |
Diese Option erlaubt es Ihnen, das Intervall (in Sekunden) anzugeben, in dem die Service-Performance-Daten-Datei mit dem
Service-Performance-Daten-Dateiverarbeitungsbefehl verarbeitet wird. Ein Wert von 0 gibt an, dass
die Performance-Daten-Datei nicht in regelmäßigen Intervallen verarbeiten werden soll.
Host-Performance-Daten-Dateiverarbeitungsbefehl (Host Performance Data File Processing Command) |
Format: |
host_perfdata_file_processing_command=<command> |
Beispiel: |
host_perfdata_file_processing_command=process-host-perfdata-file |
Diese Option erlaubt es Ihnen, den Befehl anzugeben, der ausgeführt werden soll, um die Host-Performance-Daten-Datei
zu verarbeiten. Das command-Argument ist der Kurzname einer command-Definition, die Sie in Ihrer
Objektkonfigurationsdatei angeben. Das Intervall, in dem dieser Befehl ausgeführt wird, ist durch die
host_perfdata_file_processing_interval-Direktive festgelegt.
Service-Performance-Daten-Dateiverarbeitungsbefehl (Service Performance Data File Processing Command) |
Format: |
service_perfdata_file_processing_command=<command> |
Beispiel: |
service_perfdata_file_processing_command=process-service-perfdata-file |
Diese Option erlaubt es Ihnen, den Befehl anzugeben, der ausgeführt werden soll, um die Service-Performance-Daten-Datei
zu verarbeiten. Das command-Argument ist der Kurzname einer command-Definition, die Sie in Ihrer
Objektkonfigurationsdatei angeben. Das Intervall, in dem dieser Befehl ausgeführt wird, ist durch die
service_perfdata_file_processing_interval-Direktive festgelegt.
verwaiste Service-Prüfungsoption (Orphaned Service Check Option) |
Format: |
check_for_orphaned_services=<0/1> |
Beispiel: |
check_for_orphaned_services=1 |
Diese Option erlaubt es Ihnen, Prüfungen auf verwaiste Service-Prüfungen zu aktivieren oder zu deaktivieren. Verwaiste Service-Prüfungen
sind Prüfungen, die ausgeführt und aus der Ereigniswarteschlange entfernt wurden, aber während langer Zeit keine Ergebnisse geliefert
haben. Weil keine Ergebnisse für den Service zurückgeliefert wurden, wird er nicht erneut in der Ereigniswarteschlange eingeplant. Das kann
dazu führen, dass Service-Prüfungen nicht mehr ausgeführt werden. Normalerweise passiert das sehr selten - es kann dann auftreten, wenn
ein externer Benutzer oder Prozess den Prozess abgebrochen (killed) hat, der benutzt wurde, um eine Service-Prüfung auszuführen. Wenn diese
Option aktiviert ist und Nagios feststellt, dass eine bestimmte Service-Prüfung kein Ergebnis geliefert hat, dann wird es einen Fehler
protokollieren und die Service-Prüfung erneut einplanen. Wenn Sie feststellen, dass Service-Prüfungen anscheinend nie erneut eingeplant werden,
dann aktivieren Sie diese Option und schauen Sie nach Protokollmeldungen zu verwaisten Services.
- 0 = nicht auf verwaiste Service-Prüfungen prüfen
- 1 = auf verwaiste Service-Prüfungen prüfen (Default)
verwaiste Host-Prüfungsoption (Orphaned Host Check Option) |
Format: |
check_for_orphaned_hosts=<0/1> |
Beispiel: |
check_for_orphaned_hosts=1 |
Diese Option erlaubt es Ihnen, Prüfungen auf verwaiste Host-Prüfungen zu aktivieren oder zu deaktivieren. Verwaiste Host-Prüfungen
sind Prüfungen, die ausgeführt und aus der Ereigniswarteschlange entfernt wurden, aber während langer Zeit keine Ergebnisse geliefert
haben. Weil keine Ergebnisse für den Host zurückgeliefert wurden, wird er nicht erneut in der Ereigniswarteschlange eingeplant. Das kann
dazu führen, dass Host-Prüfungen nicht mehr ausgeführt werden. Normalerweise passiert das sehr selten - es kann dann auftreten, wenn
ein externer Benutzer oder Prozess den Prozess abgebrochen (killed) hat, der benutzt wurde, um eine Host-Prüfung auszuführen. Wenn diese
Option aktiviert ist und Nagios feststellt, dass eine bestimmte Host-Prüfung kein Ergebnis geliefert hat, dann wird es einen Fehler
protokollieren und die Host-Prüfung erneut einplanen. Wenn Sie feststellen, dass Host-Prüfungen anscheinend nie erneut eingeplant werden,
dann aktivieren Sie diese Option und schauen Sie nach Protokollmeldungen zu verwaisten Hosts.
- 0 = nicht auf verwaiste Host-Prüfungen prüfen
- 1 = auf verwaiste Host-Prüfungen prüfen (Default)
Service-Frischeprüfungsoption (Service Freshness Checking Option) |
Format: |
check_service_freshness=<0/1> |
Beispiel: |
check_service_freshness=0 |
Diese Option legt fest, ob Nagios regelmäßig die "Frische" (freshness) von Service-Prüfungen prüft. Das Aktivieren dieser
Option ist nützlich, um sicherzustellen, dass passive Service-Prüfungen rechtzeitig empfangen werden.
Mehr Informationen zur Frische-Prüfung finden Sie hier.
- 0 = Service-Frische nicht prüfen
- 1 = Service-Frische prüfen (Default)
Service-Frische-Prüfintervall (Service Freshness Check Interval) |
Format: |
service_freshness_check_interval=<seconds> |
Beispiel: |
service_freshness_check_interval=60 |
Diese Einstellung legt fest, wie oft (in Sekunden) Nagios regelmäßig die "Frische" (freshness) von Service-Prüfergebnissen prüfen
wird. Wenn Sie die Service-Frische-Prüfung (mit der check_service_freshness-Option) deaktiviert haben,
dann hat diese Option keine Auswirkungen. Mehr Informationen zur Frische-Prüfung finden Sie hier.
Host-Frischeprüfungsoption (Host Freshness Checking Option) |
Format: |
check_host_freshness=<0/1> |
Beispiel: |
check_host_freshness=0 |
Diese Option legt fest, ob Nagios regelmäßig die "Frische" (freshness) von Host-Prüfungen prüft. Das Aktivieren dieser
Option ist nützlich, um sicherzustellen, dass passive Host-Prüfungen rechtzeitig empfangen werden.
Mehr Informationen zur Frische-Prüfung finden Sie hier.
- 0 = Host-Frische nicht prüfen
- 1 = Host-Frische prüfen (Default)
Host-Frische-Prüfintervall (Host Freshness Check Interval) |
Format: |
host_freshness_check_interval=<seconds> |
Beispiel: |
host_freshness_check_interval=60 |
Diese Einstellung legt fest, wie oft (in Sekunden) Nagios regelmäßig die "Frische" (freshness) von Host-Prüfergebnissen prüfen
wird. Wenn Sie die Host-Frische-Prüfung (mit der check_host_freshness-Option) deaktiviert haben,
dann hat diese Option keine Auswirkungen. Mehr Informationen zur Frische-Prüfung finden Sie hier.
zusätzliche Frische-Latenzschwellwert-Option (Additional Freshness Threshold Latency Option) |
Format: |
additional_freshness_latency=<#> |
Beispiel: |
additional_freshness_latency=15 |
Diese Option legt die Anzahl von Sekunden fest, die Nagios zu jedem Host- oder Service-Frischeschwellwert hinzurechnet, den es automatisch berechnet
(d.h., die nicht explizit durch den Benutzer angegeben wurden). Mehr Informationen zur Frische-Prüfung finden Sie hier.
eingebetteter-Perl-Interpreter-Option (Embedded Perl Interpreter Option) |
Format: |
enable_embedded_perl=<0/1> |
Beispiel: |
enable_embedded_perl=1 |
Diese Einstellung legt fest, ob der eingebettete Perl-Interpreter auf programmweiter Basis aktiviert ist. Nagios muss mit Unterstützung für
eingebettetes Perl kompiliert sein, damit diese Option eine Auswirkung hat. Mehr Informationen zum eingebauten Perl-Interpreter finden Sie
hier.
Option implizite Nutzung des eingebetteten Perl-Interpreters (Embedded Perl Implicit Use Option) |
Format: |
use_embedded_perl_implicitly=<0/1> |
Beispiel: |
use_embedded_perl_implicitly=1 |
Diese Einstellung legt fest, ob der eingebettete Perl-Interpreter für Perl-Plugins/Scripte benutzt werden soll, die ihn nicht explizit
aktiviert/deaktiviert haben. Nagios muss mit Unterstützung für eingebettetes Perl kompiliert sein, damit diese Option eine Auswirkung hat.
Mehr Informationen zum eingebauten Perl-Interpreter finden Sie hier.
Datumformat (Date Format) |
Format: |
date_format=<option> |
Beispiel: |
date_format=us |
Diese Option erlaubt es Ihnen anzugeben, welche Art von Datums-/Zeitformat Nagios im Web-Interface und in den Datums-/Zeit-Makros
benutzen soll. Mögliche Optionen (zusammen mit einer Beispielausgabe) umfassen u.a.:
Option | Ausgabeformat | Beispielausgabe |
us | MM/DD/YYYY HH:MM:SS | 06/30/2002 03:15:00 |
euro | DD/MM/YYYY HH:MM:SS | 30/06/2002 03:15:00 |
iso8601 | YYYY-MM-DD HH:MM:SS | 2002-06-30 03:15:00 |
strict-iso8601 | YYYY-MM-DDTHH:MM:SS | 2002-06-30T03:15:00 |
Zeitzonen-Option (Timezone Option) |
Format: |
use_timezone=<tz> |
Beispiel: |
use_timezone=US/Mountain |
Diese Option erlaubt es Ihnen, die Standard-Zeitzone zu überschreiben, in der die Nagios-Instanz läuft. Das ist nützlich, wenn Sie
mehrere Nagios-Instanzen haben, die auf dem gleichen Server laufen, aber mit verschiedenen lokalen Zeiten verbunden sind. Wenn nichts angegeben ist,
wird Nagios die Zeitzone des Rechners benutzen.
Anmerkung: wenn Sie diese Option nutzen, um eine eigene Zeitzone anzugeben, müssen Sie auch die Apache-Konfigurationsdirektiven für die CGIs
auf die Zeitzone ändern, die Sie haben möchten. Beispiel:
<Directory "/usr/local/nagios/sbin/">
SetEnv TZ "US/Mountain"
...
</Directory>
Illegale Zeichen für Objektnamen (Illegal Object Name Characters) |
Format: |
illegal_object_name_chars=<chars...> |
Beispiel: |
illegal_object_name_chars=`~!$%^&*"|'<>?,()= |
Diese Option erlaubt es Ihnen, illegale Zeichen anzugeben, die nicht in Host-Namen, Service-Beschreibungen oder Namen anderen Objektarten benutzt
werden können. Nagios gestattet Ihnen, die meisten Zeichen in Objektdefinitionen zu benutzen, aber ich rate Ihnen, die im Beispiel gezeigten
Zeichen nicht zu nutzen. Wenn Sie es dennoch tun, können Sie Probleme im Web-Interface, in Benachrichtigungsbefehlen usw. bekommen.
illegale Zeichen für Makroausgaben (Illegal Macro Output Characters) |
Format: |
illegal_macro_output_chars=<chars...> |
Beispiel: |
illegal_macro_output_chars=`~$^&"|'<> |
Diese Option erlaubt es Ihnen, illegale Zeichen anzugeben, die aus Makros entfernt werden, bevor diese in Benachrichtigungen,
Eventhandlern und anderen Befehlen benutzt werden. Dies betrifft NICHT Makros, die in Service- oder Host-Prüfbefehlen benutzt werden. Sie
können sich entscheiden, die Zeichen im Beispiel nicht zu entfernen, aber ich rate Ihnen, das nicht zu tun. Einige dieser Zeichen werden von der
Shell interpretiert (z.B. der "Backtick") und können zu Sicherheitsproblemen führen. Die folgenden Makros werden von den Zeichen gereinigt,
die Sie angeben:
$HOSTOUTPUT$, $HOSTPERFDATA$, $HOSTACKAUTHOR$, $HOSTACKCOMMENT$, $SERVICEOUTPUT$, $SERVICEPERFDATA$, $SERVICEACKAUTHOR$, und $SERVICEACKCOMMENT$
Option Anpassung regulärer Ausdrücke (Regular Expression Matching Option) |
Format: |
use_regexp_matching=<0/1> |
Beispiel: |
use_regexp_matching=0 |
Diese Option legt fest, ob verschiedene Direktiven in Ihren Objektdefinitionen als reguläre Ausdrücke
verarbeitet werden. Mehr Informationen dazu, wie das funktioniert, finden Sie hier.
- 0 = keine angepassten regulären Ausdrücke benutzen (Default)
- 1 = angepasste reguläre Ausdrücke benutzen
Option wahre reguläre Ausdru;cksanpassung (True Regular Expression Matching Option) |
Format: |
use_true_regexp_matching=<0/1> |
Beispiel: |
use_true_regexp_matching=0 |
Wenn Sie reguläre Ausdrücke von verschiedenen Objektdirektiven mit der use_regexp_matching-Option
aktiviert haben, dann wird diese Option festlegen, wann Objektdirektiven als reguläre Ausdrücke behandelt werden. Wenn diese Option
deaktiviert ist (der Standard), dann werden Direktiven nur dann als reguläre Ausdrücke behandelt, wenn sie *, ?, +
oder \. enthalten. Wenn diese Option aktiviert ist, werden alle entsprechenden Direktiven als reguläre Ausdrücke behandelt - seien
Sie vorsichtig bei der Aktivierung! Mehr Informationen darüber, wie das funktioniert, finden Sie hier.
- 0 = keine Anpassung wahrer regul¨rer Ausdrücke benutzen (Default)
- 1 = Anpassung wahrer regul¨rer Ausdrücke benutzen
Administrator-e-Mail-Adresse (Administrator Email Address) |
Format: |
admin_email=<email_address> |
Beispiel: |
admin_email=root@localhost.localdomain |
Dies ist die e-Mail-Adresse des Administrators der lokalen Maschine (d.h. die, auf der Nagios läuft). Dieser Wert kann mit Hilfe des
$ADMINEMAIL$-Makros in Benachrichtigungsbefehlen benutzt werden.
Administrator-Pager (Administrator Pager) |
Format: |
admin_pager=<pager_number_or_pager_email_gateway> |
Beispiel: |
admin_pager=pageroot@localhost.localdomain |
Dies ist die Pager-Nummer (oder die des Pager-e-Mail-Gateways) des Administrators der lokalen Maschine (d.h. die, auf der Nagios läuft).
Die Pager-Nummer/Adresse kann mit Hilfe des $ADMINPAGER$-Makros in Benachrichtigungsbefehlen benutzt werden.
Ereignisvermittler-Optionen (Event Broker Options) |
Format: |
event_broker_options=<#> |
Beispiel: |
event_broker_options=-1 |
Diese Option kontrolliert, welche Daten an den Ereignisvermittler gesandt werden und damit an jedes geladene Ereignisvermittler-Modul. Dies ist ein
fortgeschrittenes Feature. Falls Sie im Zweifel sind, vermitteln Sie entweder gar nichts (wenn Sie keine Ereignisvermittler-Module benutzen) oder
alles (wenn Sie Ereignisvermittler-Module benutzen). Mögliche Werte sehen Sie nachfolgend.
- 0 = nichts vermitteln
- -1 = alles vermitteln
- # = sehen Sie sich die BROKER_*-Definitionen im Quellcode an (include/broker.h), um andere Werte zu ermitteln
Ereignisvermittler-Module (Event Broker Modules) |
Format: |
broker_module=<modulepath> [moduleargs] |
Beispiel: |
broker_module=/usr/local/nagios/bin/ndomod.o cfg_file=/usr/local/nagios/etc/ndomod.cfg |
Diese wird benutzt, um ein Ereignisvermittler-Modul anzugeben, das beim Nagios-Start geladen werden soll. Benutzen Sie mehrere Direktiven, wenn Sie
mehrere Module laden wollen. An das Modul zu übergebende Argumente werden durch ein Leerzeichen vom Pfad des Moduls getrennt.
!!! WARNUNG !!!
Überschreiben Sie KEINE Module, während sie von Nagios genutzt werden, oder Nagios wird mit einem SEGFAULT-Feuerwerk abstürzen.
Dies ist ein Fehler/eine Begrenzung entweder in dlopen(), dem Kernel, und/oder dem Filesystem. Und vielleicht Nagios...
Der korrekte/sichere Weg, ein Modul zu aktualisieren, ist eine der folgenden Methoden:
- stoppen Sie Nagios, ersetzen Sie das Modul und starten Sie Nagios erneut
- während Nagios läuft... löschen Sie die originale Moduldatei, schieben Sie die neue Moduldatei an den richtigen Platz und starten Sie Nagios erneut
Format: |
debug_file=<file_name> |
Beispiel: |
debug_file=/usr/local/nagios/var/nagios.debug |
Diese Option legt fest, wohin Nagios Debugging-Informationen schreiben soll. Welche Informationen (falls überhaupt) geschrieben werden, wird
durch die debug_level- und debug_verbosity-Optionen festgelegt. Sie können die Debug-Datei
automatisch rotieren lassen, wenn sie eine bestimmte Größe überschreitet, die Sie über die
max_debug_file_size-Option festlegen können.
Debug-Stufe (Debug Level) |
Format: |
debug_level=<#> |
Beispiel: |
debug_level=24 |
Diese Option legt fest, welche Arten von Informationen Nagios in das debug_file schreiben soll. Dieser Wert ist ein
logisches ODER der nachfolgenden Werte:
- -1 = alles protokollieren
- 0 = nichts protokollieren (Default)
- 1 = Informationen zu Funktionsbeginn/Ende
- 2 = Konfigurationsinformationen
- 4 = Prozessinformationen
- 8 = geplante Ereignisinformationen
- 16 = Host-/Service-Prüfinformationen
- 32 = Benachrichtigungsinformationen
- 64 = Ereignisvermittlerinformationen
Debug-Ausführlichkeit (Debug Verbosity) |
Format: |
debug_verbosity=<#> |
Beispiel: |
debug_verbosity=1 |
Diese Option legt fest, wie viel Debugging-Informationen Nagios in das debug_file schreiben soll.
- 0 = grundlegende Informationen
- 1 = detailliertere Informationen (Default)
- 2 = sehr detaillierte Informationen
maximale Debug-Dateigröße (Maximum Debug File Size) |
Format: |
max_debug_file_size=<#> |
Beispiel: |
max_debug_file_size=1000000 |
Diese Option legt die maximale Größe (in Bytes) der Debug-Datei fest. Wenn die Datei die Größe
überschreitet, dann wird ".old" als Erweiterung angehängt. Wenn bereits eine Datei mit der ".old"-Erweiterung existiert, wird diese
gelöscht. Das stellt sicher, dass Ihr Plattenplatz nicht außer Kontrolle gerät, wenn Sie Nagios debuggen.