Einführung
Nagios Service Check Acceptor (oder kurz NSCA) ist ein Addon, um Prüfergebnisse von einem System zu einem anderen zu übertragen. Es besteht aus zwei Modulen: Dem Sender (send_nsca) und dem Empfänger (nsca). Die Daten werden verschlüsselt übertragen. Trotz des Namens werden auch Host-Prüfergebnisse übertragen.
NSCA läuft als Daemon auf dem Icinga-Server. Er lauscht auf Informationen, die von entfernten Maschinen mit Hilfe des send_nsca-Programms (auf Unix/Linux-Maschinen) oder NSClient++ (oft auf Windows-Maschinen benutzt) gesendet werden. Die Daten werden mit der in send_nsca.cfg (oder nsc.ini im Falle von NSClient++) festgelegten Methode verschlüsselt. Der Daemon wird die Daten in einer *sehr* einfachen Weise validieren, indem die Informationen mit dem in nsca.cfg eingetragenen Passwort entschlüsselt werden. Wenn die Daten so aussehen, als wären sie mit dem gleichen verschlüsselt wurden, dann wird der Daemon versuchen, diese Daten als externen Befehl in die lokale Icinga Command Pipe auszugeben.
Die folgenden Anweisungen basieren hauptsächlich auf dem README aus dem NSCA-Paket.
Voraussetzungen
Icinga sollte laufen
check_external_commands = 1 sollte in
icinga.cfg
gesetzt sein
command_check_interval = <n>[s] sollte in
icinga.cfg
gesetzt sein
log_passive_checks = 1 sollte während der Testphase in
icinga.cfg
gesetzt sein, anderenfalls gibt es keine Meldungen über eintreffende passive Prüfungen
die libmcrypt- und libmcrypt-devel-Pakete sind installiert (die je nach Distribution ggf. anders heißen können), anderenfalls nutzen Sie einen der folgenden Befehle, um die Pakete zu installieren:
#> apt-get install libmcrypt libmcrypt-devel # Debian / Ubuntu #> yum install libmcrypt libmcrypt-devel # RHEL / Fedora / CentOS #> zypper install libmcrypt libmcrypt-devel # SLES / OpenSuSE (oder benutzen Sie Yast)
Download und Compile
Laden Sie die Software vom Icinga-git-Repository, indem Sie auf "tar.gz" klicken oder benutzen Sie
#> wget "https://git.icinga.org/?p=icinga-nsca.git;a=snapshot;h=HEAD;sf=tgz" -O nsca.tgz #> tar xzf nsca.tgz
oder benutzen Sie die aktuelle Version auf dem git-Repository
#> git clone git://git.icinga.org/icinga-nsca.git
Die maximale Länge der zu übertragenen Daten ist auf 2.048 Bytes begrenzt, die maximale Länge von Plugin-Ausgaben auf 512 Bytes.
Falls das nicht ausreicht, dann müssen Sie den entsprechenden Wert in icinga-nsca/include/common.h
anpassen.
#define MAX_INPUT_BUFFER 2048 /* max size of most buffers we use */ #define MAX_PLUGINOUTPUT_LENGTH 512
Bitte denken Sie daran, dass Sie die Programme erneut kompilieren müssen, wenn Sie sich zu einem späteren Zeitpunkt für eine Änderung entscheiden.
Bedingt durch den folgenden Wert in include/common.h (im Icinga-Core) kann der maximale Wert 8.192 Bytes nicht überschreiten.
#define MAX_EXTERNAL_COMMAND_LENGTH 8192 /* max length of an external command */
Nach Änderung des Besitzers wechseln Sie in das neu erstellte Verzeichnis und rufen Sie configure und make auf
#> chown -R icinga icinga-nsca #> cd icinga-nsca #> ./configure #> make all
Anschließend gibt es zwei Programme (send and send_nsca) im src
-Verzeichnis.
![]() |
Achtung |
---|---|
Wenn die libmcrypt-Dateien nicht gefunden werden, dann wird "./configure" sich beschweren, aber NICHT mit einem Return-Code ungleich Null enden, so dass Sie config.log mit dem folgenden Befehl prüfen sollten #> grep mcrypt.h: config.log Dieser Befehl sollte keine Zeilen ausgeben. |
Falls die libmcrypt-Module nicht gefunden werden, Benutzer oder Gruppe vom Wert "icinga" abweichen oder der zu benutzende Port nicht
dem Default 5667 entspricht, dann können Sie dies über verschiedene Optionen beeinflussen. Rufen Sie "./configure -h
"
auf, um mehr über die verfügbaren Optionen zu erfahren.
Nach dem Wechsel in "nsca_tests" können Sie versuchen, "./runtests" auszuführen. Bitte beachten Sie, dass diese Tests verschiedene Perl-Module benötigen, die in der Datei README beschrieben sind.
Anpassen
Das sample-config
-Verzeichnis enthält nsca.cfg
und send_nsca.cfg
.
Mindestens die Einstellungen der Direktiven "password" und "encryption_method" / "decryption_method" sollten Sie ansehen/verändern, bevor
die Dateien kopiert werden. Bitte denken Sie daran, das gleiche Passwort in allen Kopien dieser Konfigurationsdateien zu setzen. Wenn Sie
verschiedene Passworte auf verschiedenen entfernten Servern einsetzen möchten, dann müssen Sie mehrere nsca-Daemons auf dem
Icinga-Server starten, die auf unterschiedlichen Ports lauschen. Das funktioniert nicht, wenn Sie den Daemon über inetd/xinetd
starten.
Erster Test
Wechseln Sie zum Icinga-Benutzer und starten Sie einen ersten Test
#> su - icinga $> cd /usr/src/icinga-nsca/src $> ./nsca -c ../sample-config/nsca.cfg $> echo -e "A\tB\tC\tD\n" | ./send_nsca -H localhost -c ../sample-config/send_nsca.cfg $> exit
Dies sollte die Meldung "1 data packet(s) sent to host successfully." zurückliefern. Eigentlich heißt das nur, dass sich send_nsca
und nsca unter Verwendung der Konfigurationsdateien auf dem lokalen Host miteinander unterhalten können, denn dieser Test funktioniert
auch ohne eine lauffähige Icinga-Instanz. Allerdings ist er trotzdem wichtig: Wenn dieser Test fehlschlägt, dann ist es nicht
sinnvoll fortzufahren. Prüfen Sie stattdessen die Einstellungen nsca.cfg und send_nsca.cfg. Schauen Sie auch im Syslog (z.B.
/var/log/messages
) nach Meldungen.
Wenn die Voraussetzungen erfüllt sind, dann sollten Sie einige Warnungen in icinga.log
sehen, dass Host "A" und
Service "B" nicht in der Icinga-Konfiguration gefunden werden konnten. Dies bedeutet, dass nsca ausreichende Berechtigungen hat, um
in das Icinga-Command-File zu schreiben. Prüfen Sie, ob der nsca-Daemon und Icinga mit unterschiedlichen Benutzern laufen,
wenn es keine Meldugen in icinga.log gibt. Prüfen Sie außerdem die Einstellung von log_passive_checks in icinga.cfg
.
Installation
"make install" macht (im Moment) nichts, so dass Sie selbst einige Dateien kopieren müssen. Die folgenden Befehle kopieren das nsca-Modul in das Verzeichnis, in dem das Icinga-Binary zu finden ist und die Konfigurationsdatei in den Icinga-Konfigurationsordner. Wir nehmen an, dass Sie Icinga nach einem der Schnellstartanleitungen installiert haben.
#> cp -p nsca /usr/local/icinga/bin/ #> cp ../sample-config/nsca.cfg /usr/local/icinga/etc/
nsca daemon
Wenn Sie sich für xinetd entscheiden, dann wird der Daemon automatisch gestartet. Anderenfalls müssen Sie den Daemon manuell starten, nachdem Sie zum Icinga-Benutzer gewechselt haben (was Sie ggf. bereits in "Erster Test" gemacht haben).
#> su - icinga $> /usr/local/icinga/bin/nsca -c /usr/local/icinga/etc/nsca.cfg
inetd/xinetd
Wenn Sie möchten, dass der Daemon von (x)inetd gestartet wird, dann müssen Sie /etc/services erweitern, eine weitere Datei ändern/kopieren und (x)inetd neustarten. Vergessen Sie nicht, den nsca-Daemon zu stoppen, der in "Erster Test" gestartet wurde.
![]() |
Anmerkung |
---|---|
Die Einstellung von "server_port" in nsca.cfg wird ignoriert, wenn Sie inetd/xinetd benutzen. |
#> kill < /var/run/nsca.pid #> echo "nsca 5667/tcp # NSCA" >> /etc/services
Abhängig vom verwendeten Superserver gibt es drei Alternativen
inetd MIT tcpwrappers
Fügen Sie Einträge zu Ihrer /etc/hosts.allow und /etc/hosts.deny hinzu, um TCP wrapper-Protection für den nsca-Service zu aktivieren. Dies ist optional, allerdings sehr empfohlen. Fügen Sie "nsca stream tcp nowait <user> /usr/sbin/tcpd <nsca-binary> -c <nsca-cfg> --inetd" zur /etc/inetd.conf hinzu, z.B.
#> echo "nsca stream tcp nowait icinga /usr/sbin/tcpd /usr/local/icinga/bin/nsca -c /usr/local/icinga/etc/nsca.cfg --inetd" >> /etc/inetd.conf #> /etc/init.d/inetd restart
inetd OHNE tcpwrappers
Fügen Sie "nsca stream tcp nowait <user> <nsca-binary> -c <nsca-cfg> --inetd" zur /etc/inetd.conf hinzu, z.B.
#> echo "nsca stream tcp nowait icinga /usr/local/icinga/bin/nsca -c /usr/local/icinga/etc/nsca.cfg --inetd" >> /etc/inetd.conf #> /etc/init.d/inetd restart
xinetd
Consider editing the config file nsca.xinetd in the sample-config folder and replacing <ipaddress1>... by the IP addresses of your client machines (where send_nsca will be running). This only works if xinetd was compiled with support for tcpwrappers. If you are running DHCP then this will not work and you should delete this line.
Fügen Sie Einträge zu Ihrer /etc/hosts.allow und /etc/hosts.deny hinzu, um TCP wrapper-Protection für den nsca-Service zu aktivieren. Dies ist optional, allerdings sehr empfohlen. Fügen Sie "nsca stream tcp nowait <user> /usr/sbin/tcpd <nsca-binary> -c <nsca-cfg> --inetd" zur /etc/inetd.conf hinzu, z.B.
#> cp -p ../sample-config/nsca.xinetd /etc/xinetd.d/ #> /etc/init.d/xinetd restart
Entfernte/s System/e
Sie sind mit dem lokalen System fertig, aber natürlich muss send_nsca noch auf entfernte Systeme kopiert werden.
Bitte denken Sie daran, dass send_nsca für die Zielplattform kompiliert werden muss, so dass Sie ggf. die libmcrypt-Pakete und configure/make auf mehreren Servern installieren bzw. ausführen müssen.
Dateien kopieren
Sie können frei entscheiden, wo Sie Binary und Konfigurationsdatei ablegen möchten. Wir nehmen an, dass Sie eine Verzeichnisstruktur haben, die ähnlich zum Icinga-Server ist.
#> scp -p <Icinga server>:/usr/local/icinga-nsca/src/send_nsca /usr/local/icinga/bin/ #> scp -p <Icinga server>:/usr/local/icinga-nsca/sample-config/send_nsca.cfg /usr/local/icinga/etc/
Zweiter Test
Nun können Sie den Test auf dem entfernten System ausführen
#> su - icinga $> echo -e "A\tB\tC\tD\n" | /usr/local/icinga/bin/send_nsca -H <Icinga server> -c /usr/local/icinga/etc/send_nsca.cfg
Dies sollte ebenfalls die Meldung "1 data packet(s) sent to host successfully." liefern und es sollte Warnungen im icinga.log auf
dem Icinga-Server geben, die ähnlich zu den o.g. sind. Wenn es keine Meldungen gibt, dann prüfen Sie die Einstellung von log_passive_checks in icinga.cfg
.
Fehlersuche
Wenn der Daemon nicht berechtigt ist, in die Command-Pipe zu schreiben, dann sind die Daten verloren! Der Daemon sollte mit dem gleichen Benutzer laufen wie Icinga.
Wenn das Objekt (Host und/oder Service) nicht in der laufenden Konfiguration enthalten ist, werden die Daten verworfen.
Host-Name (und Service-Beschreibung, falls zutreffend) sind Case-sensitiv und müssen exakt mit den Definitionen in Icinga übereinstimmen.
Prüfen Sie, ob Sie in nsca.cfg und send_nsca.cfg das gleiche Passwort angegeben haben. Anderenfalls wird die Übertragung fehlschlagen.
Prüfen Sie, ob Sie gleiche Verschlüsselungs-/Entschlüsselungsmethode verwenden. Anderenfalls wird die Übertragung fehlschlagen.
Prüfen Sie, ob Ihre Firewall-Einstellungen die Kommunikation über den angegebenen Port zulassen (Default ist 5667)
Wenn Sie xinetd verwenden, dann prüfen Sie, ob die hinter "only_from=" angegebenen IP-Adressen zu den entfernten Systemen passen oder entfernen Sie diese Zeile (und starten Sie xinetd neu).
Aktivieren Sie "debug=1" in nsca.cfg
, starten Sie den Daemon (neu) und schauen Sie nach Meldungen im Syslog / in
nsca.log
.
Sicherheit
Es gibt einige Sicherheitsimplikationen, wenn Sie entfernten Clients erlauben, Prüfergebnisse an Icinga zu senden. Daher gibt es die Möglichkeit, die Pakete zu verschlüsseln, die der NSCA-Client an den NSCA-Daemon sendet. Lesen Sie die SECURITY-Datei, um weitere Informationen über die Sicherheitsrisiken zu erhalten, die durch den Betrieb von NSCA auftreten können, zusammen mit einer Erklärung, welche Art von Schutz die Verschlüsselung Ihnen bietet.
Betrieb
send_nsca wird benutzt, um die Pürfergebnisse vom entfernten Rechner zum Icinga-Server zu senden. Die Syntax hängt vom Objekttyp ab. Um Service-Prüfergebnisse zu versenden, benutzen Sie
<host_name>[tab]<svc_description>[tab]<return_code>[tab]<plugin_output>[newline]
wobei:
<host_name>=der Kurzname des Hosts, mit dem der Service verbunden ist (wie in der host_name-Direktive der Service-Definition angegeben)
<svc_description>=Beschreibung des Service (wie in der service_description-Direktive der Service-Definition angegeben)
<return_code>=numerischer Return-Code (0,1,2,3 wie hier beschrieben)
<plugin_output>=Ausgabe des Service-Check
Host-Prüfergebnisse werden in einer ähnlichen Form versandt - lassen Sie einfach die Service-Beschreibung weg:
<host_name>[tab]<return_code>[tab]<plugin_output>[newline]
Integration in Icinga
Bisher haben Sie lediglich einige Voraussetzungen geschaffen, um passive Prüfergebnisse zu übermitteln, aber Sie haben noch keinen Host oder Service definiert, der diese Funktionalität nutzt.
Obwohl Sie nur Prüfergebnisse empfangen müssen Sie doch die "check_command"-Direktive in Ihren Definitionen angeben. Es gibt ein Plugin namens "check_dummy", das für diesen Zweck benutzt werden kann. Es kann sein, dass Sie die folgende command-Definition einfügen müssen, falls sie noch nicht vorhanden ist. Das zweite Argument ist optional und kann z.B. einen erklärenden Text enhalten.
define command{ command_name check_dummy command_line $USER1$/check_dummy $ARG1$ $ARG2$ }
Vielleicht möchten Sie ein Service-Template anlegen. Das Host-Template könnte ähnlich aussehen (ersetzen Sie einfach "service" durch "host")
define service{ use generic-service # template to inherit from name passive-service # name of this template active_checks_enabled 0 # no active checks passive_checks_enabled 1 # allow passive checks check_command check_dummy!0 # use "check_dummy", RC=0 (OK) check_period 24x7 # check active all the time check_freshness 0 # don't check if check result is "stale" register 0 # this is a template, not a real service }
Zusammen mit dem obigen template könnte die Service-Definition wie folgt aussehen:
define service{ use passive-service # template to inherit from host_name remotehost # host where send_nsca is located service_description Diskspace # service to be checked }
Starten Sie Icinga erneut, damit die Änderungen in der laufenden Konfiguration enthalten sind
#> /etc/init.d/icinga restart
Wechseln Sie auf Ihrem entfernten Host zum Icinga-Benutzer und führen Sie send_nsca aus. Ersetzen Sie dabei <Icinga server> durch die IP-Adresse des Icinga-Servers
#> su - icinga $> echo -e "remotehost\tDiskspace\t0\t/var=78%\n" | /usr/local/icinga/bin/send_nsca -H <Icinga server> -c /usr/local/icinga/etc/send_nsca.cfg
Bitte
denken Sie daran, dass Host-Name und Service-Beschreibung exakt den Angaben in Ihrer Icinga-Definition entsprechen müssen (die Angaben
sind Case-sensitiv). Andernfalls bekommen Sie Meldungen in icinga.log, dass das Objekt nicht gefunden werden kann. Falls es keine
Meldungen gibt, kontrollieren Sie die Einstellung von log_passive_checks in
icinga.cfg
.
Nach einem kurzen Moment sollten Sie Meldungen in icinga.log sehen, dass die gesendeten Informationen verarbeitet wurden. Sie sollten die Daten dann auch im klassischen Web-Interface sehen sowie feststellen, dass der Service-Status von "Pending" auf "OK" gewechselt ist und die Ausgabe die Daten enthält, die Sie versandt haben.
© 2009-2011 Icinga Development Team, http://www.icinga.org