Archive for the 'Nagios' Category

Monitoring Plugins für HW group Hardware

Published by Martin Krodel on 24.02.2010 in Hardware and Nagios. 1 Comment

hw group messgeräte Monitoring Plugins für HW group HardwareGrundsätzlich lässt sich gut wie jede Monitoring Hardware per SNMP überwachen. Dedizierte Check-Plugins für die jeweiligen Geräte machen aber die Integration in die Überwachung mit Nagios oder Icinga deutlich einfacher.

Daher haben unsere KollegenÜberwachungsplugins für die aktuelle HW group Gerätepalette entwickelt.

Ab sofort stehen diese Plugins unter www.monitoringexchange.org zum Download zur Verfügung.

Aktuell werden folgende Geräte von den Plugins unterstützt:

HW group Hwg-STE
HW group Poseidon 3262/3265/3266/3268/1250/2251/4002
HW group Damocles Mini/2404i

Quick Tip: Testing Nagios Plugins

Published by William Preston on 15.02.2010 in English and Nagios. 1 Comment

Sometimes when testing a Nagios Plugin on the command line, it’s useful to know the exit code.
You can always use echo $?, but that becomes tedious if you have to type it often.
Additionally you have to remember what the exit codes mean.

The following snippet adds a prompt that changes colour according to the exit code; 0 is green, 1 is yellow, 2 is red and 3 is grey. This makes it easy to see at a glance what the exit code was.

Add the following to a file e.g. debug.sh

export colormap=([0]=32 [1]=33 [2]=31 [3]=37)
export PS1='\[\e[${colormap[$?]}m\]\u@\h:\w\$\[\e[30m\] '

Then source it in .bashrc or on the command line with

source debug.sh

and enjoy.


nagios@localhost:~$ ./check_plugin 192.168.0.1
OK - 1824 bytes in 0.002 seconds
nagios@localhost:~$ ./check_plugin 192.168.0.2
Unable to open TCP socket
nagios@localhost:~$

Serie NSClient++ – Teil 4: Eventlog und weiteres!

Published by Michael Streb on 10.02.2010 in ICINGA, Monitoring, Nagios, Open Source and Serien. 1 Comment
Teil 4 von 4 in der Blogserie NSClient++

Im vierten Teil der NSClient++ Serie geht es um die Überwachung des Windows Eventlogs und weitere kleine Features des NSClients wie z.B. check_multiple.

Die Prüfung des Windows Eventlogs kann über mehrere Wege stattfinden.
In unserer Serie erfolgt die Prüfung über CheckEventlog und die dazugehörige Filtersprache, durch Angabe verschiedener Filter sind auch hier komplexe Abfragen möglich. Beispielsweise kann mit folgender Abfrage auf vorkommen von Fehlermeldungen (nicht success) innerhalb des Systemlogs geprüft werden die einen Tag alt sind und von einem Service erzeugt wurden. Eine CRITICAL Meldung wird in diesem Fall ab dem ersten Treffer erzeugt.

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckEventLog -a file=system filter=new filter=out filter-eventType==success filter+eventSource=substr:Service 'filter-generated=>1d' MaxCrit=1

Dabei wird ausgegeben welche Services den Fehler verursacht haben, zur genaueren Diagnose sollte dann das Eventlog herangezogen werden.
Die Ausgabe kann je nach Gusto noch mit verschiedenen Parametern angereichert werden. Zu finden ist die Dokumentation der Filtersprache unter http://www.nsclient.org/nscp/wiki/CheckEventLog/CheckEventLog

Ein weiterer interessanter Check des NSClients ist im Modul CheckHelpers enthalten. Das Kommando CheckMultiple ermöglicht es ähnlich zu check_multi unter Linux/Unix in einem Connect mehrere Abfragen auszuführen. CheckMultiple erwartet als Argumente die auszuführenden Checks, um Beispielsweise die Festplattenauslastung sowohl auf prozentualer als auch auf absoluter Basis zu messen kann beispielsweise dieses Kommando verwendet werden:

$ ./check_nrpe -H srv-ts.int.netways.de -p 5666 -c CheckMultiple -a command=CheckDriveSize Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long command=CheckDriveSize Drive=c MinWarnFree=2G MinCritFree=1G ShowAll=long
WARNING: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%) > warning, OK: c:: Total: 40G - Used: 36G (90%) - Free: 3.99G (10%)|'c:'=90%;80;95; 'c:'=36.00G;37.99;38.99;

Die Verknüpfung der von CheckMultiple ausgeführten Prüfungen ist immer oder, d.h. der schlechteste Status der ausgeführten Subprüfungen wird immer in das Ergebniss übernommen. In unserem Testfall ist die Prüfung also ein WARNING Status. Die Textuelle Ausgabe der beiden Prüfungen wird ausschließlich bei den Performancedaten kombiniert, so bleibt jede Information der eigentlichen Prüfungen erhalten.

Serie NSClient++ – Teil 3: Basisüberwachung

Published by Michael Streb on 03.02.2010 in ICINGA, Monitoring, Nagios, Open Source and Serien. 0 Comments
Teil 3 von 4 in der Blogserie NSClient++

Nachdem in Teil eins und zwei der Blogserie über den NSClient++ die Grundlagen und Installation durchgeführt wurden kann es nun ans Überwachen der ersten Komponenten gehen. Ziel dieses Teils ist es eine Basisüberwachung des Betriebssystems abzudecken, daraus ableiten lässt sich dann auch eine erweiterte Überwachung diverser Dienste, Festplattten oder Prozesse.

Die Kommunikation hin zum Client erfolgt über das Plugin check_nrpe, wichtig hierbei ist NRPE mit aktivierten Kommandoargumenten übersetzt zu haben. Die benötigte Option hierfür heißt “–enable-command-args” und muss zur Kompilezeit angegeben werden.

Generell funktionieren die verschiedenen Abfragen ähnlich, einzig das auszuführende Kommando (Parameter “-c”) und die dazugehörigen Argumente (Parameter “-a” für check_nrpe) unterscheiden sich je nach Prüfung.

Ein Beispielhafter Aufruf für die Prüfung der CPU Auslastung über einen Zeitraum von 5 Minuten sieht wie folgt aus:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long

Sieht das Ergebnis wie gewünscht aus können wir uns den weiteren Checks widmen. Als Basisüberwachung werden folgende Prüfungen auf jedem Windowssystem eingerichtet:

  • CPU Auslastung (80% Warning, 95% Critical, 5 Minuten Messintervall)
  • Festplattenauslastung (80% Warning, 95% Critical)
  • Speicherauslastung (70% Warning 85% Critical)
  • Uptime
  • Server Dienst

Die Kommandozeilen für die genannten Prüfungen:

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long
OK: 5m: average load 1%|'5m'=1%;80;95; 

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckDriveSize -a Drive=c MaxWarnUsed=80% MaxCritUsed=95% ShowAll=long
OK: c:: Total: 40G - Used: 24.6G (61%) - Free: 15.4G (39%)|'c:'=61%;80;95; 

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckMEM -a MaxWarn=70% MaxCrit=85% type=physical ShowAll=long
OK: physical memory: Total: 2G - Used: 840M (41%) - Free: 1.18G (59%)|'physical memory'=41%;70;85; 

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckUpTime -a ShowAll=long
OK: uptime: 0:13

$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckServiceState -a Server
OK: All services are in their apropriate state.

Funktionieren diese Abfragen können dazu noch passende Nagios bzw. Icinga Kommandos definiert werden:

define command {
        command_name    check_win_load
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckCPU -a warn=$ARG1$ crit=$ARG2$ time=$ARG3$ ShowAll=long
}

define command {
        command_name    check_win_drive
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckDriveSize -a Drive=$ARG1$ MaxWarnUsed=$ARG2$ MaxCritUsed=$ARG3$ ShowAll=long
}

define command {
        command_name    check_win_mem
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckMEM -a MaxWarn=$ARG1$ MaxCrit=$ARG2$ type=physical ShowAll=long
}

define command {
        command_name    check_win_uptime
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckUpTime -a ShowAll=long
}

define command {
        command_name    check_win_service
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c CheckServiceState -a $ARG1$
}

Serie NSClient++ – Teil 2: Installation

Published by Michael Streb on 27.01.2010 in ICINGA, Monitoring, Nagios, Open Source and Serien. 2 Comments
Teil 2 von 4 in der Blogserie NSClient++

Für die Installation des NSClient++ zur Windowsüberwachung gibt es generell zwei Möglichkeiten.

Variante eins ist die Installation auf Basis von zum Download bereitstehenden MSI Paketen. Bei dieser Installationsweise werden während des Installationsvorgangs die benötigten Parameter abgefragt.

Bei der zweiten Installationsvariante wird das ZIP Archiv heruntergeladen und auf die Systeme ausgerollt. Vorab sollte allerdings eine Anpassung der globalen Konfigurationsdatei “nsc.ini” erfolgen um die gewünschten Parameter zu setzen. Danach kann dieses Archiv einfach auf beliebig viele Rechner verteilt werden, wobei nach Entpacken des Archives manuell der Windows-Dienst registriert und gestartet werden muss.

Die Registrierung und der Start des Dienstes erfolgt in einer Kommandozeile mit den Befehlen:

# nsclientpp.exe -install
# net start nsclientpp

Beiden Installationswegen gemein ist jedoch der automatische Start des “nsclientpp” genannten Dienstes beim nächsten Neustart des Systems. Wer sich für den manuellen Installationsweg entscheidet muss in der NSC.ini folgende Parameter an die vorhandene Umgebung

Aktivieren der gewünschten Checks in derr [modules] Sektion:

FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NRPEListener.dll
CheckEventLog.dll
CheckHelpers.dll

Durch die Aktivierung der oben genannten DLL’s wird die Funktionalität des NSClient++ bestimmt, eine Erklärung der Funktionen innerhalb der Bibliotheken findet sich in der Dokumentation unter http://www.nsclient.org/nscp/wiki/CheckCommands

Anpassungen im [settings] Abschnitt:

allowed_hosts=<Kommaseparierte IP Adressliste der Monitotingserver>
use_file=1

Die Direktive use_file weist den NSClient an die Konfigurationsdatei anstatt von Registryeinträgen zu verwenden. Bei der Installation wird also lediglich der Dienst registriert, weitere Einstellungen werden nicht in die Windows Registrierung geschrieben.

Zusätzlich müssen noch Kommandoargumente und Sonderzeichen für diese freigeschalten werden, dazu gibt es in der Sektion [NRPE] folgende Parameter die jeweils auf 1 zu setzen sind:

allow_arguments=1
allow_nasty_meta_chars=1

Werden Änderungen an der Konfiguration durchgeführt muss der Dienst durchgestartet werden. Dies erfolgt entweder über den Dienste-Manager oder durch die Kommandozeile:

# net stop nsclientpp
# net start nsclientpp

Ist die Installation und Konfiguration abgeschlossen und der Dienst erfolgreich gestartet kann vom Monitoringserver aus ein erster Test erfolgen:

# /usr/local/nagios/libexec/check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckVersion

Als Antwort des Clients wird hierbei die Versionsnummer der aktuell Installierten NSClient Version zurückgegeben. Sollten hier Fehler auftreten bietet der NSClient die Möglichkeit den Dienst über eine Kommandozeilenoption in den Debugmodus zu schalten und so eventuell auftretenden Fehler zu lokalisieren. Dazu wird als erstes der Dienst gestoppt und der NSClient manuell mit der Option “-test” gestartet.

# net stop nsclientpp
# nsclientpp.exe -test

Serie NSClient++ – Teil 1: Grundlagen

Published by Michael Streb on 20.01.2010 in German and Nagios. 0 Comments
Teil 1 von 4 in der Blogserie NSClient++

nswide Serie NSClient++ Teil 1: GrundlagenZur Überwachung von Windows Servern mit Nagios oder Icinga hat sich mittlerweile der NSClient++ als Agent auf dem System etabliert.

Er bietet die Möglichkeit sowohl per “check_nt” als altes Verfahren und auch mittels NRPE Abfragen auf dem Windows System durchzuführen. Grundsätzlich sind die Abfragen in verschiedene Module gegeliedert, nennenswert an dieser Stelle sind:

  • CheckDisk – prüft die Festplattenauslastung
  • CheckEventLog – prüft Einträge im Eventlog
  • CheckSystem – prüft Prozesse, Dienste, CPU Auslastung, …

sowie

  • CheckHelpers – biete weitergehende Möglichkeiten zur Prüfungsausführung

Jedes dieser genannten Module bietet diverse Sub-Module um Abfragen auszuführen, die Parametrisierung der einzelnen Checks ist hierbei ähnlich.

Im weiterem Verlauf der Blogserie werden die Installation und Konfiguration wie auch diverse Checks und deren Aufruf vorgestellt. Die Kommunikation zum überwachten System findet hierbei ausschließlich per verschlüsseltem NRPE statt.

Schnelle Datenabfrage für Nagios und Icinga

Published by Birger Schmidt on 08.01.2010 in ICINGA and Nagios. 1 Comment

check mk.200 Schnelle Datenabfrage für Nagios und IcingaMit der Version 1.1.0 des check_mk Plugins zur Serverüberwachung ist auch das AddOn LiveStatus stable geworden. Dieses Tool bietet eine sehr effiziente Möglichkeit aktuelle Statusdaten direkt aus dem Nagios Kern abzufragen und anderen Anwendungen, wie beispielsweise NagVis (Support seit V1.4.5) zur Verfügung zu stellen.

Durch die Beschränkung auf die im Nagios oder Icinga Core vorhandenen Daten, kann das Tool leider keine historischen Daten liefern, punktet dafür aber mit einem gehörigen Geschwindigkeitsvorteil. Diesen Nachteil hat es mit der anderen, ebenfalls performanten Alternative ndo2fs gemein. Dafür fällt die Notwendigkeit einer Datenbank und man spart sich damit den Zusatzaufwand.

Leider fehlt die generische API um auf alle möglichen Datenquellen zuzugreifen, aber die Icinga API soll neben der MySQL, Oracle, icinga logo4 Schnelle Datenabfrage für Nagios und IcingaPostgreSQL Fähigkeit auch für LiveStatus angepasst werden. Um aber nicht für alle AddOns den Support für jedes Backend implementieren zu müssen, ist die API auf jeden Fall ein Schritt in die richtige Richtung. Der größte Teil der Arbeit dafür ist auch schon getan und via GIT verfügbar.

Übrigens kann man LiveStatus natürlich nicht nur als Nagios Event Broker Module betreiben sondern auch mit Icinga.

check_interface_table_v2.pl – nun auch mit VLANs

Published by Birger Schmidt on 22.12.2009 in Monitoring, MonitoringExchange, Nagios and NagiosGrapher. 3 Comments

Die letzte Version des Plugins zur einfachen Überwachung von Switchports ist nun schon fast ein halbes Jahr alt. Nach Anregungen aus verschiedenen Richtungen haben wir auch noch VLANs mit integriert. Man kann also in der generierten Übersichtstabelle sehen auf welchen Ports welche VLANs konfiguriert sind.

Ausserdem haben wir das Plugin nun auch in unser Demo System integriert.

Die aktuelle Version ist natürlich auf Monitoringexchange.org und Netways.org verfügbar.

check interface table v2 check interface table v2.pl – nun auch mit VLANs

Sensation des Tages – Überwacht durch NAGIOS

Published by Michael Streb on 17.12.2009 in Kunden & Projekte, Monitoring, NETWAYS and Nagios. 2 Comments

Neckermann Logo

Heute bekamen wir von einem unserer Kunden einen etwas individuellen Consultingauftrag.

Der neckermann.de Webshop bietet zur Weihnachtszeit eine “Sensation des Tages” also ein Produkt das sich häufig ändert und besonders günstig zu erwerben ist an.

Verständlicherweise wird dieser Artikel sehr stark nachgefragt und dadurch auch häufig ausverkauft. Die Verfügbarkeit dieser Sensation wird nun mit Nagios überwacht per HTTP Abfrage minütlich überwacht, im Falle des Ausverkaufs eines Artikels kann so schnell reagiert und eine neue Sensation nachgelegt werden.

HW group HWg-STE: Netzwerkthermometer

Published by Martin Krodel on 19.11.2009 in Hardware and Nagios. 1 Comment

HWg STE IP SNMP Thermometer 800 300x265 HW group HWg STE: NetzwerkthermometerDie HW group hat ein Einstiegsgerät für die Temperaturüberwachung von Serverräumen und einzelnen Racks in Rechenzentren entwickelt – das HW group HWg-STE. Das Gerät hat einen Netzwerkanschluss für die Integration in das bestehende Netzwerk und die Abfrage der Daten und zwei Anschlüsse für Temperatur- und Luftfeuchtigkeitssensoren. Das HWg-STE kann bei Über- oder Unterschreitung von im Gerät definierten Schwellwerten per Email alarmieren. Weiterhin kann man die Messdaten per SNMP vom Gerät ablesen.

Die komplette Konfiguration geschieht über das Webfrontend, wobei man auch die SNMP-MIBS direkt im Webfrontend herunterladen kann. Im Lieferumfang ist ein Temperatursensor, das Netzteil und eine CD inkl. einer Software für Windows enthalten. Diese Software kann die Messdaten aus dem HWg-STE speichern und nach MS-Excel exportieren. Somit kann man eine Basisüberwachung der Umweltparameter in seinem Serverraum sicherstellen.

Hier sehen Sie die Funktionsweise nochmals bildlich dargestellt:

HWg STE Thermometer icons HW group HWg STE: Netzwerkthermometer

Folgende Sensoren sind für das HWg-STE verfügbar:

Weiterhin kann das Gerät per SNMP oder mit dem von uns entwickelten Nagios Plugin problemlos in Nagios integriert werden. Weiter Informationen finden Sie bei uns im Shop. Ein Demo des Webfrontends können Sie hier einsehen.

« Older Entries