Seite wählen

NETWAYS Blog

NSClient++ und darüber hinaus

nsclient-logoFür viele verschiedene Anwendungsgebiete bringt NSClient++ schon Funktionen mit, mit Hilfe derer man direkt und ohne Probleme Dinge wie Festplattenauslastung, CPU, Memory, Services und Logs abfragen kann.
Heute soll es einmal um die Themen gehen, die der NSClient nicht „out of the box“ beherrscht.  Vor allem im Bereich der Client Überwachung gibt es hier noch ungenutztes Potential:

1.) Security Center

Mit Hilfe von WMI ist es auf einfache Weise möglich auf Windows Clients ab Vista zu überprüfen wie der Antivirus Status ist. Hierfür gibt es einen namespace „root\SecurityCenter2“ mit der Klasse AntiVirusProduct. Hier kann man den Schlüssel ProductState überprüfen. Die Interpretation dieses Wertes ist nun leider nicht durchgängig Dokumentiert und sollte gegen das eigene Antivirus Produkt nochmal gegen geprüft werden.
Folgende Artikel können hierbei hilfreich sein:

  • http://neophob.com/2010/03/wmi-query-windows-securitycenter2/
  • Microsoft Blog

2.) Windows Updates

Hierfür gibt es ein Powershell Plugin, dass einem beantwortet ob Updates anstehen oder ein reboot seiner Durchführung harrt. Da es mit dem Original Plugin von Jules ein paar bekannte Performance Probleme gibt empfehle ich hier die verbesserte Version von redbranch[Jonny]

3.) GPO – Gruppenrichtlinien

Bei den Gruppenrichtlinien handelt es sich um ein Server/Client basiertes System zur Verteilung von Windows Konfigurationsobjekten. Auf dem Client sollte man daher überprüfen, ob der Service zur Umsetzung dieser Konfigurationsanweisungen überhaupt läuft. Das lässt sich bequem mit dem NSClient++ erreichen indem man den Service „gpsvc“ überprüft. Ob wirklich alle Richtlinien umgesetzt wurden kann man am besten auf dem Server überprüfen. Dazu im nächsten Teil der Serie mehr.

WMI reparieren

Sollte es einmal Probleme mit dem Windows Management Intrumentarium geben und man weiß nicht wie dieses zu reparieren ist, sollte man sich mal das Diagnose- und Repair-Tool von Microsoft hierfür anschauen.
 
Im nächsten Teil dieser Serie geht es um Advanced Windows Server Monitoring. Insbesondere wird es hierbei um GPOs und Windows Updates aus der Sicht der Servers gehen.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Microsoft Sharepoint Monitoring

Diese Woche habe ich mich mal wieder etwas in der Windows Welt herumgetrieben und einiges zum Thema Sharepoint Monitoring herausgefunden.
Da Sharepoint normalerweise in etwas größeren Firmen eingesetzt wird, und dann in der Regel auch entsprechend viele Mitarbeiter darauf zugreifen, ist der normale Windows Admin dazu angehalten eine wie auch immer topologisch aufgebaute Sharepoint Farm einzurichten. Diese kann aus mehreren Sharepointservern und einem MSSQL-Cluster im Hintergrund aufgebaut werden, aber auch andere Konstrukte und Topologien sind möglich.
Da man als Monitoring Guy aber nicht immer den vollen Einblick in die Planungen/Umsetzugen der Windowsabteilung hat möchte ich euch hier ein Plugin vorstellen, dass einem das Leben vereinfachen kann.
Das Plugin überwacht einem die komplette Sharepoint Farm mit einem einzigen check,
und das beste: Man muss nichts dafür wissen. Man muss sich nicht überlegen welche Komponenten man überwacht und auch nicht, welche Maschinen zu dem Konstrukt gehören. Soweit so gut:
Das Plugin bedient sich des „Sharepoint Health Analyzer“, welcher ab Sharepoint 2010 zur Verfügung steht. Dieser bringt schon einen Schwung an Checks mit, die sich allerdings noch im Nachgang mit der nötigen Expertise durch den Windows Admin erweitern lassen.
Das ganze wird eingebunden in ein ganz kurzes powershellscript, welches sich dann über nsclient++ aufrufen lässt.
Et voilà, c’est tout.
PS: Möchte man auch noch das powershellscript nicht selber schreiben kann man sich hier bedienen. Das Plugin könnte zwar noch ein paar Verbesserungen vertragen (–help usw.) Aber grundsätzlich tut es was es soll.
 
Bildquelle:

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Weekly Snap: DavMail & Lightning, Powershell & jQuery

weekly snap3 – 7 June started the month by beginning the OSMC 2013 countdown alongside tips for developers using Powershell and jQuery-AOP and one for sys admins.
Eva started her countdown to the OSMC 2013 with Bernd’s opening speech from 2012.
Matthias then introduced aspect-oriented programming using jQuery-AOP as Christopf triumphed over Powershell to find the right syntax to write to Array.
Finally Blerim discovered DavMail and Lighting his solution to integrating the Microsoft Exchange Server calendar into Thunderbird.

Letzte Ausfahrt PowersHell

Nachdem ich mich diese Woche mal wieder etwas mit einem meiner „Lieblingsthemen“ beschäftigt habe möchte ich euch die neuesten Erkenntnisse natürlich nicht vorenthalten.
Also . . . Was bringt dir dieser Blogpost?
– Zeitersparnis beim Austüfteln der richtigen Powershell Syntax. Das war’s. Mehr nicht.
Reicht aber auch. Ich hätte mich gefreut wenn ich das so irgendwo gelesen hätte.
Kurze Erklärung: Ich war dabei ein Plugin zu schreiben, dass WMI-Tabellen abfragt, diese Auswertet und ein Ergebnis MIT Performancedaten an Icinga übergibt. Dazu schreibe ich verschiedene Dinge in ein Array und gebe sie am Ende des Plugins aus. An und für sich nicht schwer. Aber wie macht man es mit Powershell?
1.) Deklariere das Array RICHTIG, sonst geht’s nicht:
$perf_list = new-object 'System.Collections.Generic.List[string]'
2.) Schreibe die Daten hinein. Als erstes eine pipe, die die Perfdaten einleitet.
if ($perf) {$perf_list.add(@("`|"))} -> Pipe Zeichen ausgeben ist nicht einfach . . .
3.) Als nächstes dann die Performancedaten selber. Es geht hier um 3 Festplatten, denen jeweil drei Werte zugeordnet sind. Freier Platz, Warn- und kritischer Schwellwert. Die Ausgabe sollte dann so aussehen:
icinga@monitor0815:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.67.21 -p 5666 -c check_stuff -a „scripts\testps.ps1 -diskwarn 40 -diskcrit 30 -perf“
OK: |’DiskFree_Y:’=3025MB;1227.2;920.4 ‚DiskFree_X:’=3006MB;1227.2;920.4 ‚DiskFree_Q:’=467MB;203.2;152.4

4.) Und wird folgendermaßen korrekt ins Array geschrieben.
if ($perf) {$perf_list.add(@("DiskFree_"+$i.path+"="+$i.FreeSpace+"MB`;"+($i.TotalSize*$diskWarn/100)+"`;"+($i.TotalSize*$diskCrit/100)+" "))}
5.) Und so am Ende ausgegeben.
foreach ($i in $perf_list) {
#write-host "l"
write-host -NoNewLine $i
}

Doch leider hat es ziemlich lange gedauert bis ich zu diesem Ergebnis gekommen bin und mich vermutlich 5 Jahre meines lebens und 153 graue Haare gekostet.
Also spielen wir mal eine kurze Runde Fehlersuche: Wo ist der Unterschied zu oben ?
So hat’s nicht geklappt
icinga@monitor0815:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.67.21 -p 5666 -c check_stuff -a „scripts\testps.ps1 -diskwarn 40 -diskcrit 30 -perf“
OK: |’DiskFree’=0 ‚Y:’=3025MB;1227.2;920.4 ‚DiskFree’=0 ‚X:’=3006MB;1227.2;920.4 ‚DiskFree’=0 ‚Q:’=467MB;203.2;152.4

if ($perf) {$perf_list.add(@("DiskFree "+$i.path+"="+$i.FreeSpace+"MB`;"+($i.TotalSize*$diskWarn/100)+"`;"+($i.TotalSize*$diskCrit/100)+" "))}
Und so auch nicht . . .
icinga@monitor0815:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.67.21 -p 5666 -c check_stuff -a „scripts\testps.ps1 -diskwarn 40 -diskcrit 30 -perf“
OK: |’DiskFree_Y:’=3025MB;1227.2;920.4;1227.2;920.4

if ($perf) {$perf_list.add(@("DiskFree_"+$i.path+"="+$i.FreeSpace+"MB`;"+($i.TotalSize*$diskWarn/100)+"`;"+($i.TotalSize*$diskCrit/100)))}
Und so erst recht nciht . . . .
icinga@monitor0815:/usr/lib/nagios/plugins# ./check_nrpe -H 192.168.67.21 -p 5666 -c check_stuff -a „scripts\testps.ps1 -diskwarn 40 -diskcrit 30 -perf“
OK: |’DiskFree’=0 ‚Y:’=3025MB;1227.2;920.4 ‚X:’=3006MB;1227.2;920.4 ‚Q:’=467MB;203.2;152.4

if ($perf) {$perf_list.add(@("DiskFree "+$i.path+"="+$i.FreeSpace+"MB`;"+($i.TotalSize*$diskWarn/100)+"`;"+($i.TotalSize*$diskCrit/100)))}
Es gab noch mehr verrückte Formatierungen, auf die ich gestoßen bin. Aber ich will euch nicht langweilen . . .
Letztendlich war ich positiv überrascht, das man mit etwas Aufwand doch recht angenehm unter Windows scripten kann.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

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