Tag Archive for 'Nagios'

CeBIT Live 2010: Vortrag auf dem Open Source Forum

Published by Michael Streb on 03.03.2010 in CeBIT. 1 Comment

Nach dem starken Andrang am zweiten Tag auf der CeBIT hatten ich gerade eben auch noch die Chance auf dem CeBIT Open Source Forum des Linux Magazins einen Vortrag über die Online Nagios Schulungen zu halten (wir berichteten bereits hier).

In der Präsentation wurde kurz in 15 Minuten vorgestellt wie die Schulungen aufgebaut sind und welcher Inhalt in den einzelnen Sessions vermittelt wird. Vielen Dank an dieser Stelle noch mal an die Kollegen vom Linux Magazin und von Techcast für die angenehme Zeit in München.

Angemerkt sei auch noch das speziell zur CeBIT eine Rabattaktion für die Schulungen aufgelegt wurde, wer also Interesse hat gleich unter http://academy.linux-magazin.de/ zuschlagen.

Anbei noch ein Bild wie die Schulungen Online präsentiert werden:

Training Screen 300x194 CeBIT Live 2010: Vortrag auf dem Open Source Forum

Hier noch die Präsentation mit den Schulungsinhalten:

Online Training

CeBIT Live 2010: Interesse an Nagios und Icinga ungebremst

Published by Manuela Pirner on 02.03.2010 in CeBIT. 0 Comments

Julian’s erster Vortrag im Open Source Park der CeBIT 2010 zum Thema “Überwachung großer IT-Umgebungen mit Nagios und Icinga” stieß auf großes Interesse und regen Andrang – der Raum war bis auf den letzten Platz belegt! Dieses Jahr finden sich auch im iX Forum hochkarätige Vorträge rund ums Thema. Dort wird auch noch Bernd Erk zum Thema “Ein Open-Source-Data-Warehouse für das IT-Management” Wissen aus seinem Erfahrungsschatz preisgeben. Julian’s Vortrag wurde live gestreamt und ist im Anschluss im Archiv zu finden! Wer schon vorher bei uns am Stand bei einer Tasse Kaffee Erfahrungen austauschen möchte ist herzlich willkommen!

Und hier noch die Beweise: :-)

IMG 50872 CeBIT Live 2010: Interesse an Nagios und Icinga ungebremstIMG 5102 CeBIT Live 2010: Interesse an Nagios und Icinga ungebremst

Interaktives Lernerlebnis: Nagios Monitoring Schulung jetzt online

Published by Manuela Pirner on 01.03.2010 in Schulungen. 2 Comments

Seit kurzem bietet die Linux-Magazin Academy jetzt auch ein Online-Trainingsangebot zum Thema Nagios. In dreizehn www Interaktives Lernerlebnis: Nagios Monitoring Schulung jetzt onlineVideo-Lektionen lehrt unser Trainer Michael Streb Einsteigern Schritt für Schritt Installation, Konfiguration, Überwachung von Linux- und Unix-Rechnern sowie einige AddOns wie NagVis oder EventDB. Das Ganze wird in einem übersichtlichen Web-Interface präsentiert, bei dem der Bildschirm des Trainers parallel zum Video angezeigt wird – der Lernende schaut dem Dozenten sozusagen buchstäblich bei seinen Beispielen auf der Kommandozeile über die Schulter. Vorteil ist, dass das Videotraining jederzeit angehalten, wieder fortgesetzt und die einzelnen Schritte beliebig oft wiederholt werden können. Ort und Zeit der Schulung können somit selbst bestimtm werden.  Eine kostenlose Demo findet sich hier: academy.linux-magazin.de Wir wünschen viel Erfolg!

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

Weekly Snap: Sculio support, Bacula checks and Nagios plugin tests

Published by Amanda Mailer on 22.02.2010 in Diverses and English. 0 Comments

camera Weekly Snap: Sculio support, Bacula checks and Nagios plugin testsFeb 15-19 touched on startup support, Nagios and Bacula monitoring tips for a light blog week.

Always on the lookout for cool projects, Bernd announced our support for Sculio. The young start up we chanced upon at Webmontag, offers project sponsor search and member benefits to students through a partnership program with companies. This year NETWAYS will sponsor Sculio with web hosting.

On the monitoring theme, William offered his quick Nagios tip. A convenient colour coded prompt to take the hassle out of remembering exit codes when testing a Nagios plugin on the command line.

Meanwhile Julian shared two monitoring plugins developed in house for Bacula: check_bacula for individual job monitoring within a specified time frame and count_bacula to view pool utilization. Get them off netways.org under GPL with many other monitoring goodies.

Bacula Monitoring Plugins

Published by Julian Hein on 19.02.2010 in Bacula. 0 Comments

Auf der Bacula Konferenz letztes Jahr hatte ich einen Vortrag gehalten, wie sich Bacula und vor allem auch Bacula Jobs und Pools durch Nagios oder Icinga überwachen lassen. In diesem Vortrag habe ich auch zwei Monitoring Plugins vorgestellt, die wir zum internen Einsatz entwickelt haben. Die beiden Plugins stehen auf unserem Community Portal netways.org zum Download zur Verfügung.

Mit dem Plugin check_bacula lassen sich einzelne Jobs überwachen, insbesondere ob ein Job in den letzten x Stunden erfolgreich abgeschlossen werden konnte. Wenn man den Jobnamen in Bacula gleich dem Nagios/Icinga Hostnamen wählt, spart man sich gleichzeitig auch etwas Konfigurationsarbeit. So wird das ganze konfiguriert:

# Bacula Checkcommand
# -H: hours; -w: Warning; -c: Critical; -j: Job (Jobname=Hostname)
define command {
	command_name	check_bacula
	command_line	$USER1$/check_netways_bacula.pl -H $ARG1$ -w $ARG2$ -c $ARG3$ -j $HOSTNAME$"
}

# bacula jobs
define service {
	use						bacula-template
	hostgroup_name			bacula-win, bacula-linux
	host_name				another_client
	service_description		backup-jobs
	check_command			check_bacula!27!1!1
	servicegroups			backup
}

bacula1 Bacula Monitoring Plugins

Das zweite Plugin count_bacula dient der Überwachung von Poolauslastungen, bzw. Poolgrößen. Damit lässt sich automatisch feststellen, wenn der Platz in einem definierten Pool zur Neige geht. Das Ergebnis kann man dann auch sehr aussagekräftig mit NETWAYS Grapher visualisieren:

define command {
	command_name	check_backup_poolsize
	command_line	$USER1$/count_bacula -pool $ARG1$ -w 75 -c 90
}

define service {
	use			generic-service
	host_name			Bacula_Server
	service_description	backup-pool PoolName
	check_command		check_backup_poolsize!PoolName
}

bacula21 Bacula Monitoring Plugins

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
« Older Entries