Thematischer Schwerpunkt dieser Ausgabe ist die kontinuierliche Überwachung von Servern, Clients und anderen Geräten im Netzwerk: mit dem IPMI-Plugin, dem ... (mehr)

Nagios-Integration

Die Integration in das eigene Monitoringsystem ist schnell erledigt. Als Beispiel dient hier der Platzhirsch unter den Open-Source-Monitoringsystemen: Nagios. Die Voraussetzung zum Ausführen des Cucumber-Nagios-Plugin ist, wie bereits beschrieben, eine funktionierende Ruby-Installation.

Wer Cucumber-Nagios auf einem anderen als dem Nagios-Server evaluiert hat, muss das Projektverzeichnis rekursiv auf den Nagios-Server kopieren. An welcher Stelle das Verzeichnis liegen sollte, ist abhängig von der eigenen Distribution und der Art, wie Nagios konfiguriert wurde. Debian, Red Hat sowie Suse Linux installieren die Nagios-Plugins mittlerweile alle unter »/usr/lib/nagios/plugins« . Hat man Nagios selbst kompiliert, ist dagegen »/usr/local/nagios/libexec« die Voreinstellung. Eine gute Wahl ist, im Plugin-Verzeichnis ein Unterverzeichnis namens »cucumber-nagios« zu erstellen und dort das Projekt abzulegen. Auch die Datei- und Verzeichnisrechte in dem System müssen stimmen, damit der Nagios-User auf die Dateien zuzugreifen darf.

Oftmals ist eine eigene Variable für das Plugin-Verzeichnis in der »resource.cfg« gesetzt, beispielsweise »$USER1$=/usr/lib/nagios/plugins« . Um den Konfigurationsaufwand möglichst gering zu halten und die Übersichtlichkeit zu wahren, empfiehlt sich eine eigene Variable für den Pfad zum Cucumber-Nagios-Projekt, etwa »$USER2$=/usr/lib/nagios/plugins/cucumber-nagios« . Dann fehlt in der Datei »commands.cfg« noch das Kommando zum Überprüfen des Dienstes:

define command{
 command_name  check_cn
 command_line  $USER2$/checks/bin/cucumber-nagios $ARG1$
 }

Der »command_name« ist frei wählbar. Bei der »command_line« ist dagegen zu beachten, dass sowohl die Pfadvariable korrekt ist, als auch, dass »$ARG1$« an das eigentliche Kommando angehängt wird. Denn Cucumber-Nagios bekommt beim Aufruf genau ein Argument mitgeliefert. Welches das ist, legt die entsprechende Servicedefinition in »services.cfg« fest (Listing 5).

Listing 5

services.cfg

 

Bevor der Admin den Nagios-Daemon nun die Konfiguration neu einlesen lässt, sollte er die definierten Checks zuerst einmal auf der Kommandozeile testen. Hierzu führt er das Plugin am besten im Kontext des Nagios-Users aus:

su nagios -c "/usr/lib/nagios/plugins/cucumber-nagios/checks/bin/cucumber-nagios/usr/lib/nagios/plugins/cucumber-nagios/checks/features/www.xing.com/startpage.feature"
~ $ echo $?

Sollte dies wider Erwarten mit Rückgabewert »2« fehlschlagen, ist er über einen der leider noch vorhandenen, aber einfach zu behebenden Bugs gestolpert. Über die Option »--pretty« gibt das Tool den Backtrace aus, der bei der Fehlersuche hilft.

Wie Zeile 8 des Backtrace in Listing 6 verrät, liegt ein Problem mit den Dateirechten vor: Der Nagios-User möchte die Datei »webrat.log« schreiben, besitzt dazu aber nicht die nötigen Rechte. Die vordergründige Ursache ist der Aufruf. Hätte er »su« mit der Option »-l« aufgerufen, wäre die Umgebungsvariable »$HOME« für den Nagios-User gesetzt gewesen. So allerdings versucht der Nagios-User in das Verzeichnis des »su« ausführenden Users zu schreiben. Besonders problematisch wird dieser Umstand, wenn man Checks mit SSH ausführt, da SSH von Haus aus keine Login-Shell startet.

Listing 6

Fehlersuche mit Backtrace

 

Es erfordert lediglich eine kleine Änderung am Code des als Abhängigkeit in Cucumber-Nagios integrierten Webrat, um dieses Problem aus der Welt zu schaffen. Hierzu öffnet der Admin aus dem Projektverzeichnis heraus die Datei »vendor/gems/ruby/1.8/gems/webrat-0.7.0/lib/webrat/core/logging.rb« und gibt in Zeile 18 den vollen Pfad für das zu schreibende Logfile an. Je nach Homeverzeichnis des Nagios-Users könnte die Zeile wie folgt aussehen:

@logger ||= ::Logger.new("/var/nagios/webrat.log")

Abschließend sollte er den obigen Aufruf für das Plugin manuell testen. Das Ergebnis sieht dann deutlich positiver aus:

CUCUMBER OK - Critical: 0, Warning: 0, 4 okay| passed=4; failed=0; nosteps=0; total=4

Nun sollte dem Überwachen von Funktionen mittels Cucumber-Nagios nichts mehr im Wege stehen. Nach einem Reload des Daemon überwacht Nagios den entsprechend definierten Check. Die Integration im Monitoringsystem ist somit abgeschlossen. Abbildung 1 zeigt das Ergebnis in einem Nagios-Interface

Abbildung 1: Sind alle Cucumber-Tests geschrieben, tauchen die Überwachungsergebnisse in Nagios auf.

Fazit

Cucumber-Nagios ist ohne Zweifel ein mächtiges Werkzeug. Allerdings setzt es einiges an Erfahrung voraus, um brauchbare Ergebnisse zu erzielen. Eine Integration in bestehende Systeme wird in der Regel nur über einen längeren Zeitraum möglich sein. Mitarbeiter wollen in die Systematik von Cucumber und Gherkin behutsam eingeführt werden. Das Erstellen spezifischer Steps für die eigene Plattform ist zudem ohne Ruby-Kenntnisse kaum zu bewerkstelligen.

Umgebungen, in denen Entwicklungs- und Betriebs-Teams eng zusammenarbeiten, machen sich hier bezahlt. Entwickler steuern die Applikationslogik bei, QA-Mitarbeiter definieren Testszenarios, und die Administratoren können sich auf den operativen Betrieb ihrer Monitoringsysteme konzentrieren. Dieses Zusammenwirken erfordert jedoch eine gute Abstimmung zwischen den Teams.

Neben kleineren Bugs und vielen Wünschen [9] zur Erweiterung von Cucumber-Nagios, könnte das Projekt zudem noch einige weitere vordefinierte Steps mitbringen. Hier ist die Open-Source-Gemeinde aufgefordert sich zu beteiligen. Dann hat Cucumber-Nagios durchaus das Potenzial für eine weite Verbreitung und könnte den Weg für "Behavioral Driven Infrastructure" ebnen.

Der Autor

Mike Adolphs arbeitet als Systemadministrator bei der XING AG und sorgt dort unter anderem für einen reibungslosen Betrieb der Ruby-on-Rails-Applikationen. In seiner Freizeit erkundet er seine Wahlheimat Schleswig-Holstein mit dem Motorrad und sucht Perl- sowie Ruby-Entwickler für XING.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019