Als NETWAYS schreiben wir uns selbst ein sehr hohes Icinga/Nagios KnowHow auf die eigene Fahne. Aber auch wir haben, wie 99,99% aller Icinga/Nagios Anwender, immer wieder den ein oder anderen Fallstrick zu bewältigen.
Ein Problem, welches sehr häufig Auftritt, das richtige maskieren von Sonderzeichen in Check-Definitionen.
Ein ganz simples Beispiel: Mit wie vielen Backslashes (\) muss man die Pfadangaben eines Shares maskieren, damit Icinga/Nagios diese richtig interpretiert?
Wie ist das vorgehen in einem solchen Szenario? Richtig, man ändert so lange und so oft die Definition, führt jedes mal einen Icinga/Nagios Reload aus und führt den Check neu aus bis man irgenwann das gewünschte Ergebnis hat… Das dies mitunter längere Zeitspannen in Anspruch nimmt ist vielen durchaus bewusst, uns auch!
Icinga/Nagios besitzt im Core ca. 10 Zeilen, welche für das maskieren von Sonderzeichen verantwortlich sind. Dieses kleine Snippet/Wrapperplugin hilft uns nun dabei unsere Checks im vorhinein schon richtig zu bauen und zu testen, um sie anschließend in die jeweilige Definition zu übernehmen.
Ein Aufruf des Wrapperplugins sieht wie folgt aus:
# ./check_executor /opt/icinga/libexec/check_http -H icinga -u "/icinga-web"
Executing command /opt/icinga/libexec/check_http -H icinga -u /icinga-web
Check output: HTTP OK: HTTP/1.1 301 Moved Permanently - 305 bytes in 0.001 second response time |time=0.001075s;;;0.000000 size=305B;;;0
Executing command gibt den eigentlichen Pluginaufruf aus, wie er duch Nagios/Icinga ausgeführt wird.
Check output beschreibt die eigentliche Ausgabe, wie sie u.a. auch in der Weboberfläche sichtbar wäre.
Zu finden ist das ganze in unserem GIT: https://git.netways.org/plugins/collection/trees/master/plugins/check_executor
Um Verwechslungen grundsätzlich aus dem Weg zu gehen: “Der Checker” kümmert sich natürlich um schöne Autos, unser “Checker” um Icinga/Nagios Plugins.
NETWAYS Blog
Serie NSClient++ – Teil 9: Registry
Konfigurationsdatei
Die Konfiguration von NSClient++ wird im Standard in der Datei nsc.ini vorgenommen.
NSClient++ bietet neben dieser Konfigurationsmethode auch die Möglichkeit die Konfiguration in die System Registry auszulagern.
Ein verlagern der Konfiguration aus der Konfigurationsdatein in die Registry bietet u.a. in großen Deployments den Vorteil das man die Konfiguration z.B.: über eine Gruppenrichtlinie verwalten und steuern kann.
Konfigurationsobjekte befinden sich dann unter HKEY_LOCAL_MACHINE\Software\NSClient++ und können von dort aus bearbeitet werden.
Konfiguration auslagern
In der bestehenden Konfigurationdatei muss neben dem Parameter “use_file=1” der Parameter “use_reg=1” ergänzt werden.
Nachdem die nsc.ini diese Option im Bereich “[Settings]” enthält, kann die Konfiguration in die Registry importiert werden.
Für den Import der Konfiguration in die Registry wird das Module RemoteConfiguration verwendet.
C:\Program Files\NSClient++>"nsclient++.exe" -noboot RemoteConfiguration ini2reg
NSCore not loaded...
Archiving crash dumps in: C:\Users\Administrator\AppData\Local\NSClient++\crash dumps
Migrating to registry settings...
importing: modules/FileLogger.dll=
importing: modules/CheckSystem.dll=
...
Nach dem Import finden sich die Objekte, wie bereits erwähnt, unter HKEY_LOCAL_MACHINE\Software\NSClient++ in der Registry wieder.
Damit NSClient++ nun nicht weiterhin die Konfigurationsdatei nutzt muss die Option “use_file=” deaktiviert werden (“use_file=0”) und der NSClient++ Service neugesartet werden.
net stop nsclientpp
net start nsclientpp
Die Einstellungen der Registry können nun auf andere Windows-Server verteilt werden (z.B.: mittels GroupPolicy oder SoftwareDeployment Lösung). NSClient++ benötigt jedoch weiterhin einen gewissen Teil der nsc.ini, die Einstellungen in der Sektion [Settings] und die Auflistung der zu ladenden Module.
Serie NSClient++ – Teil 8: Eigene Skripte
NSClient++ verfügt über eine Vielzahl von Abfragemöglichkeiten um Windows Server zu überwachen.
Viele der Überwachungsmöglichkeiten und Konfigurationsparameter für diese wurden bereits in der NSClient++ Serie vorgestellt.
Immer dann wenn weitere Applikationen, Hardware, Logdateien etc. überwacht werden sollen stoßen die NSClient++ Module überwiegend an die Grenzen ihrer Möglichkeiten. Eigene Skripte müssen her…
Das Modul CheckExternalScripts ist genau für diesen Zweck gedacht und dient als Wrapper um eigene Skripte auszuführen. Vorrausetzung hierfür ist das Windows die Skriptsprache unterstützt und das jeweilige Skript einen validen Icinga/Nagios Returncode zurückliefert.
NSClient++ und externe Skripte
In der NSC.ini beeinflussen die Folgenden Sektionen das verhalten der “ExternalScripts”:
[External Script] beschreibt das verhalten beim ausführen der Skripte. Mit “command_timeout=” wird der maximale Ausführungszeitrahmen (in Sekunden) eines Skripts/Plugins durch NSClient++ definiert. Achtung: NSClient++ bricht danach die Ausführung ab, unter Umständen kann das Skript jedoch weiterlaufen. Die Optionen “allow_arguments=” und “allow_nasty_meta_chars=” definieren ob beim ausführen von Icinga/Nagios Seite aus Argumente mit übergeben werden dürfen und ob “unangenehme” Zeichen übermittelt werden dürfen (z.B.: |`&><'"\[]{} ).
Unter [Script Wrappings] werden die Interpreter für die verschiedenen Dateieindungen der Skripte konfiguriert. Mit den Variablen %SCRIPT% und %ARGS% wird definiert an welcher Stelle das Skript ausgeführt werden soll und wo beim Aufruf die Argumente übergeben werden.
vbs=cscript.exe //T:30 //NoLogo scripts\lib\wrapper.vbs %SCRIPT% %ARGS%
ps1=cmd /c echo scripts\%SCRIPT% %ARGS%; exit($lastexitcode) | powershell.exe -command -
[External Scripts] gibt nun schlussendlich die eigentlichen Skripte und ihre Ausführungsparameter an:
check_icinga.bat=scripts\icinga.bat
Oder auch, ohne den Skriptwrapper zu nutzen:
check_powershell_exchange=cmd /c echo scripts\exchange.ps1 | powershell.exe -command -
Sollen Skripte verwendet werden, die außerhalb des NSClient Verzeichnisses liegen muss jeweils der absolute Pfad verwendet werden.
Perlskripte unter Windows
Um Perl Skripte über den NSClient++ auszuführen benötigt man unter Windows entweder einen Perl Interpreter, z.B.: Strawberry Perl oder man kompiliert die jeweiligen Plugins zuvor mit dem Perl Modul PAR::Packer zu ausführbaren .exe Dateien:
$ perl -MCPAN -eshell
cpan> install Bundle::libwin32
cpan> install PAR::Packer
$ pp -o check_test.exe check_test.pl
Wer bei der Installation von PAR::Packer auf einen Fehler stößt: http://www.nntp.perl.org/group/perl.par/2012/03/msg5306.html
Serie NSClient++ – Teil 7: NSCA
In den vorherigen Teilen der NSClient++ Serie wurden die Möglichkeiten der aktiven Überwachung eines Windows Servers mit NSClient++ aufgezeigt.
NSClient++ verfügt, neben den Modulen für aktive Abfragen (NSClientListener, NRPEListener), auch über ein Module für passive Abfragen, NSCAAgent.
NSCA (Nagios Service Check Acceptor) ist ein Nagios/Icinga Add-On bestehend aus zwei Komponenten:
* NSCA Server: Der NSCA Daemon auf dem Monitoringsystem welcher passive Checkergebnisse an nimmt und diese in die Nagios- bzw. Icinga-Commandpipe schreibt.
* NSCA Agent: Der NSCA Agent auf dem Clientsystem welcher die Checkergebnisse an den NSCA Server weiterleitet.
Eine gute Anleitung für die Installation des NSCA Servers findet man in der Icinga Dokumentation: http://docs.icinga.com/latest/de/nsca.html#id3878652
NSClient++ verlangt einige Einstellungen in der NSC.ini um NSCA zur Aktivierung und Konfiguration.
Zuallererst muss das NSCAAgent Modul geladen werden:
; NSCA Agent if you enable this NSClient++ will talk to NSCA hosts repeatedly (so dont enable unless you want to use NSCA)
NSCAAgent.dll
Anschließend muss NSCA konfiguriert werden. Wichtig ist hierbei zu wissen welche encryption_method und ggf. welches password auf der Seite des NSCA Servers (nsca.cfg) definiert wurde. Beide Optionen, Verschlüsselung und Passwort, müssen mit der NSCA Agent Konfiguration übereinstimmen.
[NSCA Agent]
;# CHECK INTERVALL (in seconds)
; How often we should run the checks and submit the results.
interval=120
;# ENCRYPTION METHOD
encryption_method=1
;# ENCRYPTION PASSWORD
; This is the password/passphrase that should be used to encrypt the sent packets.
password=icinga
;# LOCAL HOST NAME
; The name of this host (if empty "computername" will be used.
hostname=windows-server
;# NAGIOS SERVER ADDRESS
; The address to the nagios server to submit results to.
nsca_host=icinga.training.netways.de
;# NAGIOS SERVER PORT
; The port to the nagios server to submit results to.
nsca_port=5667
Der hostname muss mit dem in Nagios/Icinga definierten Hostobjekt übereinstimmen.
Nach der Konfiguration des NSCA müssen die NSCA Commands definiert werden, jene Checks die NSClient++ ausführen soll und an den Monitoringserver senden soll. Hierbei muss jeweils das Checkcommand mit den dazugehörigen Argumenten angegeben werden:
[NSCA Commands]
CPU=CheckCPU warn=80 crit=90 time=15m time=10m time=5m ShowAll=long
Memory=checkMem MaxWarn=80% MaxCrit=90% ShowAll=long type=physical
Disk-C=CheckDriveSize MaxWarn=80% MaxCrit=90% ShowAll=long Drive=c:
Die Namen der Commands müssen mit den in Nagios/Icinga definierten Serviceobjekte übereinstimmen.
Damit der NSCA Server die empfangenen Checks auch richtig an Nagios/Icinga weiterleiten kann muss dort der jeweilige Service, als passiver Service, definiert werden.
Beispiel:
define service{
use generic-service
host_name windows-server
service_description CPU
check_command check_dummy!3 "No results received, check NSCA"
active_checks_enabled 0
check_freshness 1
freshness_threshold 600
}
Serie NSClient++ – Teil 6: Dateiattribute
Im sechsten Teil der NSClient++ Serie geht es um die Überwachung von verschiedenen Dateiattributen. Hierzu zählen unter anderem Dateigröße, Dateialter sowie Dateiversion.
Das NSClient++ Modul check_disk.dll verfügt über den Befehl CheckFiles, welcher es ermöglicht verschiedene Dateiattribute abzufragen. CheckFiles ist seit NSClient++ 0.3.9 verfügbar.
Dateigröße
Die Dateigröße von Dateien oder Dateien eines Verzeichnisses lässt sich ebenfalls über CheckFiles überwachen. Hierbei können bestimmte Dateien zur Überwachung angegeben werden, Dateien mit einer bestimmten Dateiendung bis hinzu Dateien die in einem Verzeichnis in mehreren Ordnertiefen liegen.
Eine Abfrage auf Dateien die größer als 1 MB im Verzeichnis c:/temp sind sieht wie Folgt aus:
$ ./check_nrpe -H 192.168.119.3 -c CheckFiles -a path=c:\\temp filter="size > 1M" "syntax=%filename%: %size%" MaxWarn=1 MaxCrit=2
vm.log: 2.67M, found files: 1 > warning|'found files'=1;1;2
MaxWarn und MaxCrit definiert den Warning- bzw. Critical-Schwellwert und mit syntax wird das Ausgabeformat vorgegeben.
Dateialter
Das Alter einer Datei oder mehrerer Dateien in einem Verzeichnis lässt sich mit definierten Schwellwerten wie folgt überwachen:
$ ./check_nrpe -H 192.168.119.3 -c CheckFiles -a path=c:\\temp filter="written <-2d" "syntax=%filename%" MaxWarn=1 MaxCrit=2
old_nsc.ini, vm.log_20120521_133739.log, vm.log_20120521_133739.log, found files: 3 > critical|'found files'=3;1;2
Die Filtereinstellungen bewirken, dass Dateien, deren Änderungszeitpunkt älter als 2 Tage ist, herausgefiltert werden. Die Angabe von d steht in diesem Fall für Tage. Folgende Zeitdefinitionen gibt es für die time-expression:
s (second), m (minute), h (hour), d (day), w (week)
Dateiversion
Die Version einer Datei kann über den Filter version abgefragt werden:
$ ./check_nrpe -H 192.168.119.3 -c CheckFiles -a path=c:\\temp pattern=*.exe "filter=version > 1" "syntax=%filename%: %version%" MaxCrit=1
explorer.exe: 6.1.7601.17567, found files: 1 > critical|'found files'=1;0;1
Der Filter für version arbeitet mit numeric-expression.
Die Schwellwerte können entweder über MaxWarn und MaxCrit definiert werden um so auf die Anzahl der Dateien zu schauen oder mit warn und crit definiert werden um so eine genauere Warning- bzw. Criticalschwelle zu definieren:
...warn=gt:1 crit==1...
Weitere Möglichkeiten des Commands CheckFiles sind im NSClient++ Wiki zu finden: http://nsclient.org/nscp/wiki/CheckFiles
