Thomas Kramer

IT-COW | Icinga - erweiterte Konfiguration

Icinga - erweiterte Konfiguration

By Administrator at Mai 28, 2010 21:41
Filed Under: Administration, Anleitungen, Linux, Windows

In diesem Eintrag will ich die erweiterte Konfiguration von Icinga beschreiben - mein vorangegangenes Tutorial zu dem Thema ist hier verlinkt.

 

DokuWiki-Integration

 

Es erschien mir sinnvoll, DokuWiki in Icinga zu integrieren. DokuWiki ist ein dateibasierendes Wiki, die meisten anderen Wiki-Systeme speichern ihre Einträge dagegen in Datenbanken. Da keine Datenbank benötigt wird ist dieses Wiki pflegeleicht und schnell aufzusetzen, ich habe es auf beiden meiner Server installiert.

 

Die DokuWiki-Installation von meinem Linux-Server lasse ich automatisch zeitgesteuert über einen Cronjob und rsync+SSH auf meinen Windows Home Server kopieren, als Backup. Ich selbst bevorzuge mittlerweile mein Blog, das ich automatisch über wget und das FTP-Protokoll auf meinen WHS-Server sichern lasse. Für Server-Dokumentation wollte ich DokuWiki trotzdem einbinden.

 

Das Thema war zunächst etwas schwierig zu recherchieren, weil Icinga noch nicht so weit verbreitet ist wie Nagios (in der deutschen Dokumentation von Icinga wird das Thema nicht behandelt). (Noch) ist das System von den Einstellungen her kompatibel zu Nagios, insofern habe ich mich bei der Suche darauf konzentriert. Dazu hatte ich als erstes diesen Link gefunden. An der Stelle gibt es direkt einen Schwachpunkt in der Dokumentation, denn bei dem Link sieht man nicht in welcher Datei man die Einstellung vornehmen muss (dem System ist das offenbar egal - könnte man vielleicht dazu schreiben).

 

Als weiterführenden Link hatte ich diese Seite gefunden, jedoch gibt es die Dateien hostextinfo.cfg und serviceextinfo.cfg per default nicht bei Icinga. Es besteht aber auch die Möglichkeit diese Dateien gar nicht erst anzulegen sondern z. b. den hostextinfo-Parameter direkt in die Datei windows.cfg im objects-Verzeichnis einzufügen. Konkret habe ich dazu in dieser Datei unter dem define host{}-Parameter folgende Zeilen eingefügt:

 

define hostextinfo{

            host_name         ServerName

            notes_url         http://IP-Adresse-des-DokuWiki-Servers:Port/doku.php?id=Artikelname

}

 

In dem oben genannten Link wird nicht ganz klar, das man als notes_url-Parameter auch direkt eine http-Adresse einbinden kann - diese Quelle sagt dazu folgendes "Any valid URL can be used.".

 

Nachdem ich die genannte Änderung gemacht und Icinga mit /etc/init.d/icinga restart neu gestartet hatte, gab es über den Menüpunkt Host Detail bei dem Windows-Server folgende zusätzliche Icon (siehe Pfeil) zu sehen (obere Zeile, die untere repräsentiert den localhost, also den Icinga-Server):

 

 

Darauf geklickt öffnet sich ein neues Tab im Webbrowser mit dem angegebenen Artikel in DokuWiki. Ergänzung: auf diese Weise können natürlich auch andere Wikis integriert werden.

 

Allgemeines zu Icinga

 

Das Icon rechts daneben öffnet übrigens das Service Detail-Fenster des ausgewählten Hosts - in diesem wird standardmäßig der Status von 7 verschiedenen relevanten Abfragen angezeigt:

 

  • C:\ Drive Space (benutzter/freier Speicher auf Laufwerk C)
  • CPU Load (durchschnittliche CPU-Auslastung über einen Zeitraum von 5 Minuten)
  • Explorer (zeigt auf, ob die Explorer.exe läuft)
  • Memory Usage (benutzter/freier Arbeitsspeicher, wobei der virtuelle Speicher offenbar mitgezählt wird)
  • NSClient++ Version
  • Uptime (seit dem letzten Ausfall)
  • W3SVC (Webserver-Dienst von IIS, siehe hier)

 

Über PlugIns können weitere Abfragen hinzugefügt werden, wobei Icinga zu den Nagios-PlugIns kompatibel ist. Eine Quelle dafür habe ich bereits gefunden: Link. Ob der Host überhaupt erreichbar ist wird in der Host-Übersicht natürlich direkt angezeigt und farblich hervorgehoben (Legende: grün=erreichbar, rot=nicht erreichbar) - ansonsten werden in der Auflistung wie allgemein üblich alternierende Farben benutzt.

 

Logfile-Check über Icinga

 

Der für mich wichtigste Check eines Servers (nach der Uptime) ist der seiner Log-Dateien. Icinga beherrscht dies über NRPE (Nagios Remote Plugin Executor), das ist sowohl ein Programm als auch ein Protokoll. Gemäß Link sollte es irgendwo auf der Icinga-Homepage zu finden sein, aber ich habe es über diese Seite schneller gefunden, wobei dort auch gleich die Installation beschrieben wird. Weiter benötigt das PlugIn ein Pendant auf der Gegenseite, da wie gesagt NRPE sowohl ein Programm als auch ein Protokoll ist kann man NRPE in der Windows-Version oder NSClient++ dafür nehmen. Für meine Tests habe ich NSClient++ benutzt, weil das bereits auf meinem Windows-Server installiert ist.

 

Als nächstes wird darauf aufbauend das PlugIn check_logfiles benötigt, auf jeden Fall für den Windows-Server - der Link enthält auch direkt eine Anleitung. Anmerkung: früher war check_logfiles Windows-seitig wohl ein Perl-Skript, mittlerweile bietet der Autor eine EXE-Datei dafür an - nicht von der Anleitung irritieren lassen, die noch nicht ganz darauf angepasst ist.

 

Als nächstes muss dann die Konfiguration von Icinga angepasst werden. Generell dazu folgender Tipp als Vorangehensweise: immer nur eine Datei auf einmal verändern und direkt den Befehl  

 

/usr/local/icinga/bin/icinga -v /usr/local/icinga/etc/icinga.cfg

 

ausführen, um zu sehen ob die Änderung angenommen wurde. Der Befehl /etc/init.d/icinga restart zeigt nämlich nur an, DAS ein Fehler vorhanden ist.

 

Als erstes wird die Datei windows.cfg im objects-Verzeichnis von Icinga angepasst, indem man folgenden Eintrag hinzufügt:

 

define service{

              use                       generic-service

              service_description       Logfiles

              host_name                 ServerName-oder-IP

              check_command             check_nrpe!check_logfiles

              is_volatile               1

              max_check_attempts        1

              }

 

Als nächstes passt man die Datei commands.cfg an, ebenfalls im objects-Verzeichnis, und fügt folgenden Eintrag hinzu:

 

define command{

              command_name         check_nrpe

              command_line         $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -t 20

              }

 

Der Service ruft den Befehl check_nrpe auf und übergibt ihm den Parameter check_logfiles, das ist der Befehl der auf dem Server ausgeführt werden soll. Dafür werden die zu übergebenden Parameter in der Service-Definition über ! voneinander getrennt, also jedes ! führt einen neuen Parameter an - bei der Command-Definition werden diese Parameter dann an die Variablen $ARG1$, $ARG2$ etc. übergeben.

 

Anschließend passt man die NSC.ini-Datei von NSClient++ auf dem Server an. Dort sollte der Parameter allow_arguments auf 1 gesetzt werden, damit generell Parameter vom Client zum Server hin übergeben werden können. Dann fügt man die Sektion [NRPE Handlers] (übrigens nicht zu verwechseln mit der Sektion [NRPE Client Handlers]) unten an und fügt darunter bspw.

 

check_logfiles=check_logfiles.exe -f c:\temp\lf.cfg

 

ein. Damit der Befehl generell so funktioniert sollte sich die Datei check_logfiles.exe über die Windows-Path-Variable finden lassen, also im allgemeinen Suchpfad liegen - ansonsten muss der Pfad zu dieser Datei mit angegeben werden. Im Beispiel habe ich jetzt keine Parameter für den Client-Aufruf definiert, also keine Variablen angegeben.

 

Das Programm check_logfiles.exe kann auf zwei Arten aufgerufen werden: entweder übergibt man ihm die ganzen Parameter direkt über die Kommandozeile, oder man schreibt einen @searches-Eintrag in eine Config-Datei und übergibt diese an check_logfiles über den Parameter -f. Beispiele für Aufrufe vom erstgenannten Typ: 1 2, Beispiele für eine Definition einer solchen Konfigurations-Datei:  1 2 3 4.

 

Übrigens: Wenn eine Konfigurationsdatei benutzt wird, wird ein zusätzlicher -lookback-Parameter in der Kommandozeile ignoriert, man sollte die lookback-Option dann auch in die Konfigurationsdatei hineinschreiben.

 

Der genannte Aufruf in der NSC.ini-Datei kann daher so prinzipiell auch auf der Kommandozeile ausgeführt werden. Grundsätzlich sollte der Aufruf von check_logfiles erst auf dem Server in der Kommandozeile getestet werden. Ich habe in der oben genannten lf.cfg folgendes stehen:

 

@searches = ({
  tag => 'System-Log',
  options => 'winwarncrit',
  type => 'eventlog',
  eventlog => {
    eventlog => 'system',
    include => {
      eventtype => 'error,warning',
    },
  },
  },{
  tag => 'Security-Log',
  options => 'winwarncrit',
  type => 'eventlog',
  eventlog => {
    eventlog => 'security',
    include => {
      eventtype => 'error,warning',
    },
  },
  },{
  tag => 'HomeServer-Log',
  options => 'winwarncrit',
  type => 'eventlog',
  eventlog => {
    eventlog => 'HomeServer',
    include => {
      eventtype => 'error,warning',
    },
  },
  },{
  tag => 'Application-Log',
  options => 'winwarncrit',
  type => 'eventlog',
  eventlog => {
    eventlog => 'application',

    include => {
      eventtype => 'error,warning',
    },
  },
});

 

Grundsätzliches zum Aufbau dieser Konfigurationsdateien: {} kennzeichnen ein Array, damit können mehrere Einträge mit gleicher Bedeutung angegeben werden. Im Beispiel habe ich auf diese Weise vier Abfragen definiert, die die Warnungen und Fehler vierer System-Logs kumuliert zu einer Einheit zusammenfügen: das System, das Security, das HomeServer und das Application-Eventlog. Die Bezeichnungen müssen übrigens klein eingegeben werden, ferner muss bei der Rechtschreibung der Zuweisungen aufgepasst werden - die Parameter selbst dürfen falsch geschrieben werden, werden dann aber ignoriert. Der Eintrag options => 'winwarncrit' ist wichtig, denn ansonsten muss man über criticalpatterns=> Suchfolgen vorgeben - mit 'winwarncrit' als Option wird generell nach Warnungen und Fehlern in den Systemlogs gesucht.

 

Zuerst hatte ich bei dem oben genannten Beispiel übrigens als zusätzliche Parameter

 

computer => 'localhost',
username => 'Administrator',
password => 'Passwort',

 

mit drinstehen und das funktionierte lokal ausgeführt auf dem Windows-Rechner auch, aber vom Linux-Rechner ausgeführt gab es dann Probleme mit der Anmeldung - daher für Testzwecke erst einmal weglassen. Wird aber auch nicht benötigt, wenn es lokal aufgerufen wird. Übrigens: bei meinen Tests wurden IP-Adresse und localhost als Computer-Parameter nicht gleich behandelt, bei IP-Adressen bekam ich keine Fehlermeldungen (außer wenn die IP selbst falsch geschrieben war) und konnte sogar einen falschen Benutzer angeben ohne das ein Fehler kam - daher bei Tests die eh lokal ausgeführt werden besser localhost als Angabe präferieren - oder noch besser den Parameter weglassen.

 

Grundsätzliches zu check_logfiles: Das Programm überprüft per Default nur die Einträge in den Eventlogs, die es beim letzten Aufruf noch nicht überprüft hat. Daher sollte man sich nicht wundern wenn man immer OK zurückbekommt. Will man das nicht haben, dann übergibt man bei einem Kommandozeilenaufruf als Parameter -lookback 30d, damit für bspw. 30 Tage zurückgeblickt wird. Das geht über die Konfigurationsdatei auch - über den options-Parameter - aber dort ist es eher nicht gewünscht. Über den Tag-Parameter kann ein eindeutiges Präfix für die Ausgabe angegeben werden (Name). In der Ausgabe bedeutet (Name)-Log_lines die Anzahl der Zeilen, die untersucht wurden. Weiterhin legt check_logfiles seine eigenen Log-Dateien standardmäßig in C:\Temp ab.

 

Nachdem man den Aufruf auf dem Server in der Kommandozeile erfolgreich getestet hat, kommt der Test auf dem Icinga-Rechner dran. Dazu gibt man in der Konsole des Linux-Rechners folgendes ein:

 

/usr/local/icinga/libexec/check_nrpe -H IP-Adresse-des-Servers -c check_logfiles

 

Wenn das geklappt hat, kann man Icinga mit /etc/init.d/icinga restart neu starten und das Ergebnis überprüfen. Das habe ich bei mir gemacht und das sieht dann folgendermaßen im Icinga-Webinterface aus:

 

 

Wie man sieht werden die neuen Fehler seit dem letzten Aufruf in der Logfiles-Zeile aufgelistet (Zeile mit dem roten Eintrag).

 

Weitere Links:

 

  • Öffentliches PDF zu check_logfiles von ConSol: Link
  • Download-Quelle (und Anleitung) für check_logfiles: Link
  • Benutzung von check_logfiles mit Domänen-Benutzern: Link
  • Eintrag zu check_logfiles im deutschen Nagios-Wiki: Link
  • Einleitung zu check_logfiles im Linux-Magazin: Link
  • Der Autor von check_logfiles ist im Nagios-Portal aktiv: Link

 

=> Weiter geht es mit einem Überblick des Webinterfaces von Icinga und den Notifications: Link.

 

Update 20.06.2010: Es gibt auch die Möglichkeit die Windows-Logs über das Programm MS Log Parser auszulesen, das funktioniert aber nur lokal weil keine Optionen vorgesehen sind Benutzer und Passwort zu übertragen (beim lesen aus dem Event-Log) und für diese Aktion natürlich Administrator-Rechte benötigt werden. Aber angenommen auf dem zu überprüfenden Rechner ist auch ein Mailserver installiert, ist das natürlich eine weitere Möglichkeit.

---------------------------------------------------------------------------------------------------------------------------------------

Anhang

 

Änderungen bei meinem eigenen System:

 

Da im Webinterface immer nur der letzte Fehler (eines Services) detailliert aufgelistet wird und 8 Services noch recht übersichtlich waren, habe ich nun jeweils für das System, Security, HomeServer und Application-Event-Log doch eigene Services in Icinga definiert, anstatt es kumuliert zu einer Abfrage zusammenzufügen. Der Aufbau sollte nach oben genanntem Beispiel klar sein. Dafür werden dann auch vier separate Config-Dateien für check_logfiles auf dem Server benötigt, die oben genannte Datei habe ich daher aufgesplittet.

 

Zuerst hatte ich überlegt den Namen der Config-Datei jeweils als weiteren Parameter in den Service-Definitionen von Icinga zu übergeben, mit dem Parameter -a in der Commands-Definition. Das funktionierte bei mir jedoch nicht, obwohl ich es richtig gemacht habe. Daher habe ich nun in der NSC.ini von NSClient++ auf dem Windows-Server statt einem check_logfiles-Befehls vier solcher Befehle eingefügt (die Parameter -f und --config können offenbar synonym verwendet werden):

 

check_logfiles_system=check_logfiles.exe --config c:\Pfad\lf_system.cfg
check_logfiles_security=check_logfiles.exe --config c:\Pfad\lf_security.cfg
check_logfiles_homeserver=check_logfiles.exe --config c:\Pfad\lf_homeserver.cfg
check_logfiles_application=check_logfiles.exe --config c:\Pfad\lf_application.cfg

 

In den Service-Definitionen von Icinga wird nun nicht der Name der Config-Datei direkt angegeben, sondern der Name des Befehls unterscheidet. Das ist insofern auch geschickter, weil der Ort/Name der Config-Dateien meiner Meinung nach nicht auf dem Icinga-Server angegeben sein sollte - man sollte besser die Abhängigkeiten reduzieren. Die Command-Definition musste ich dafür nicht ändern, da der Name des Befehls vom Service bereits als Variable übergeben wurde.

 

Nach einem Ändern der NSC.ini-Datei muss der Dienst NSClient++ natürlich neu gestartet werden.


Update 01.06.2010: Natürlich wollte ich es dann so erweitern das nicht nur mein Server, sondern zusätzlich mein Arbeitsrechner überwacht wird. Zuerst habe ich dazu versucht mit check_logfiles remote über den WHS die Logfiles von meinem Arbeits-PC auszulesen, das funktionierte aber nicht - die Funktion von check_logfiles dazu ist aber auch erst am 12.04.2010 mit der Version 3.2 hinzugefügt worden, demnach noch sehr neu.

 

Dann habe ich NSClient++ und check_logfiles direkt auf meinem Arbeitsrechner installiert. Anschließend bin ich bei der Umsetzung auf ein (triviales) Problem gestoßen, was mich dann wieder ein paar Stunden Fehlersuche gekostet hat. In der NSC.ini-Datei von NSClient++ sollte man auch die verschiedenen DLL-Dateien inkludieren - also die Auskommentierung wegnehmen - von den Funktionen die man benutzen will. Ansonsten funktionieren die Abfragen natürlich nicht. Gemäß Link sollte man also am besten direkt die Dateien

 

CheckSystem.dll

CheckDisk.dll

NRPEListener.dll

FileLogger.dll

 

mit einbeziehen. Etwas unglücklich ist das die FileLogger.dll standardmäßig auskommentiert ist, denn so kann man lange versuchen die eingebaute Log-Funktion von NSClient++ zu aktivieren. Aber wenn man es weiß ist es ja kein Problem die Einstellungen zu korrigieren. Nach der Entfernung der Semikolons (und einem Neustart des Dienstes) funktionierte es wie erwartet.

 

Kommentare (2) -

03.06.2010 22:20:57 #

Gerhard Laußer

Dazu zwei Tips:
Bei den Searches angeben: options => 'winwarncrit,noprotocol'
dann fällt in der Ausgabe das "2 errors in ....protocol...zeitstempel" weg.

Als globale Option die lange Ausgabe einschalten:
$options = "report=long";
dann gibt's mehrzeiligen Output und bei Klick auf "Service Detail" bekommt man die einzelnen Trefferzeilen untereinander angezeigt. (report=html geht auch, dann wird's bunt)


Noch was: "funktionierte lokal ausgeführt auf dem Windows-Rechner auch, aber vom Linux-Rechner ausgeführt gab es dann Probleme mit der Anmeldung "
Die Remote-Abfrage mittels computer/username/password funktioniert prinzipiell nicht, wenn das Plugin auf Linux ausgeführt wird, da hier reine Windows-Transportmechanismen dahinterstecken, um ein entferntes Eventlog auszulesen.

Gerhard Laußer Deutschland | Antwort

03.06.2010 23:03:11 #

Admin

Interessant, danke für den Hinweis. Der erste vernünftige Kommentar hier Smile (außer Werbe-Spam)

Admin Deutschland | Antwort

Kommentar schreiben




  Country flag
biuquote
  • Kommentar
  • Live Vorschau
Loading


Monats-Liste