Seite wählen

NETWAYS Blog

NETWAYS Webinare: Icinga 2 Serie

NETWAYS Webinare
Heute möchten wir euch darüber informieren, dass wir uns einige Gedanken über unsere beliebten Icinga 2 Webinare gemacht haben. Anders als bisher wollen wir nicht statisch auf einzelne Themen und Inhalte eingehen, sondern einen ganzheitlichen Eindruck der Möglichkeiten von Icinga 2 vermitteln.
In diesem Zuge werden wir gemeinsam in einer Reihe von Webinaren vom Grundaufbau des Monitorings, der Anbindung an Graphite und Grafana bis hin zum Windows Monitoring und der Integration von Rocket.Chat und Request Tracker für die Alarmierung.
Am Ende der Serie soll als Ziel eine fertige Icinga 2 Umgebung bereitstehen, welche vom Grundaufbau im Rahmen der Webinare erstellt wurde und künftig für weitere Themen bereitsteht.
Die geplanten Termine sind alle direkt auf unserer Webinar Seite zu finden. Eine kurze Übersicht möchten wir trotzdem bereitstellen:

Wir freuen uns wie immer auf eine rege Teilnahme!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

InGraph – The ultimate guide 3/5

Im dritten Teil unseres InGraph Guides, wollen wir uns mit Views beschäftigen:
InGraph ermöglicht es Ansichten von Graphen als Views zu speichern um sie immer wieder aufrufen zu können. Vorallem wenn sehr viele Plots gleichzeitig dargestellt werden sollen, können einem vorgefertigte Views sehr viel Aufwand ersparen. Am besten lässt sich das erstellen von Views anhand eines einfachen Beispiels erklären.
Unser Ziel:
Wir wollen eine Übersicht über die CPU-Auslastung und den Speicherverbrauch eines Hosts über den Zeitraum einer Woche.

Erstellen der neuen Ansicht

Zuerst öffnen wir eine neue Ansicht und wählen dazu den Host und den Service aus, den wir beobachten wollen:
 

Hinzufügen zusätzlicher Graphen

Um jetzt zusätzlich noch die CPU-Auslastung darzustellen, muss die erste Ansicht mit der Schaltfläche Clone this panel geklont werden. Im neuen Graphen werden nun die alten Plots entfernt und die neuen hinzugefügt. Zusätzlich ändern wir die Darstellung des neuen Plots so, dass der Raum unterhalb der CPU-Auslastung ausgefüllt wird.
(Tipp: Falls sich die dargestellten Zeiten bei beiden Graphen unterscheiden sollten, kann man diese mit der Funktion synchronisieren bequem anpassen. )

Ausblenden unwichtiger Parameter und Speichern

Um eine bessere Übersichtlichkeit zu erreichen kann man außerdem noch ungewollte Plots ausblenden. In unserem Beispiel wollen wir dass nur die prozentuale Belegung des Hauptspeichers dargestellt wird. Dies erreichen wir indem wir unter Settings den Haken bei Active entfernen.

Wenn die View nun zu unserer Zufriedenheit angepasst ist, können wir diese nun in der Toolbar unter Template und Save As View speichern. Jetzt kann man das View in der linken Seitenleiste, unter InGraph und Views jederzeit wieder aufrufen.

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

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.
[code lang=“bash“]
$ ./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
[/code]
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:
[code lang=“bash“]
$ ./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;
[/code]
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

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:
[code lang=“bash“]
$ ./check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckCPU -a warn=80% crit=95% time=5m ShowAll=long
[/code]
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:
[code lang=“bash“]
$ ./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.
[/code]
Funktionieren diese Abfragen können dazu noch passende Nagios bzw. Icinga Kommandos definiert werden:
[code lang=“bash“]
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$
}
[/code]

Serie NSClient++ – Teil 2: Installation

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:
[code lang=“bash“]
# nsclientpp.exe -install
# net start nsclientpp
[/code]
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:
[code lang=“bash“]
FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NRPEListener.dll
CheckEventLog.dll
CheckHelpers.dll
[/code]
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:
[code lang=“bash“]
allowed_hosts=<Kommaseparierte IP Adressliste der Monitotingserver>
use_file=1
[/code]
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:
[code lang=“bash“]
allow_arguments=1
allow_nasty_meta_chars=1
[/code]
Werden Änderungen an der Konfiguration durchgeführt muss der Dienst durchgestartet werden. Dies erfolgt entweder über den Dienste-Manager oder durch die Kommandozeile:
[code lang=“bash“]
# net stop nsclientpp
# net start nsclientpp
[/code]
Ist die Installation und Konfiguration abgeschlossen und der Dienst erfolgreich gestartet kann vom Monitoringserver aus ein erster Test erfolgen:
[code lang=“bash“]
# /usr/local/nagios/libexec/check_nrpe -H srv-app.int.netways.de -p 5666 -c CheckVersion
[/code]
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.
[code lang=“bash“]
# net stop nsclientpp
# nsclientpp.exe -test
[/code]