Icinga2 – Den ersten Host überwachen

Logo von Icinga 2

Icinga 2 Logo

Nachdem ich neulich schon einmal einen Artikel zum Thema Icinga2 Installation unter CentOS 7 zum Besten gelassen habe, folg heute der nächste Artikel zu Icinga2. Diesmal will ich zeigen, wie wir den ersten Server (den Icinga2 Server selbst) überwachen können. Ich beschränke mich hier auf ein Minimum der an Dateien. Auf die *.conf die hier vielleicht vermisst werden, gehe ich noch in späteren Artikel ein.

1. Beispiel Dateien sichern bzw. löschen

Nach einer Icinga2 Grundinstallation, gibt es bereits einige Beispiel-Dateien zum Monitoren des lokalen Servers. Diese können sehr hilfreich sein, wenn man einen Einblick in den Aufbau der Konfigurationsdateien bekommen will. Da wir hier aber unsere eigenen Dateien bzw. eine eigene Struktur erarbeiten wollen, müssen diese Dateien erstmal weg.
Der einfachste Weg ist diese zu löschen (ACHTUNG: Die commands.conf auf jeden Fall sichern!). Wenn man sich noch nicht so gut mit Icinga2 auskennt, kann man die Beispiel-Dateien auch einfach zuvor sicher. Ich werde hier mal die Befehle zum Sichern und anschließenden löschen zeigen.

Damit haben wir jetzt die Grundlage geschaffen, unsere Konfigurationen zu erstellen.

2. Anlegen der templates.conf

Um uns später Arbeit zu ersparen, wollen wir zuerst zwei Templates anlegen. Ein Host und ein Service Template. Für diese Templates legen wir zuerst eine Datei mit dem Namen template.con an.

Diese Datei wird anschließend mit einem Editor geöffnet.

Wir beginnen mit dem Template für Hosts.

Als erstes müssen wir sagen, was wir anlegen wollen (Template, Object,etc). Da wir ein Template anlegen starten wir auch mit dem Signalwort Template. Anschließend brauchen wir die Art des Templates (Host, Service, User, Period, etc.). Das ist in diesem Fall ein Host. Als drittes folgt dann noch ein Name für das Template in Anführungszeichen (hier generic-host). Anschließend kommen eine öffnende und eine schließende geschweifte Klammer.

Zwischen diesen beiden Klammern wollen wir nun drei Grundwerte für folgende Hosts definieren. Ich werde diese drei Werte nun nacheinander erläutern.

  • max_check_attempts gibt an, wie oft ein Check fehlschlagen darf, bis eine Reaktion ausgelöst wird (E-Mail, SMS, Jabber, u.v.m.).
  • check_interval gibt an, nach wie viel Minuten/Sekunden ein Check wiederholt werden soll, wenn dieser zuvor nicht fehlgeschlagen ist.
  • retry_interval gibt an, nach wie viel Minuten/Sekunden ein Check wiederholt werden soll, falls dieser zuvor fehlgeschlagen ist.

Nach dem gleichen Prinzip, legen wir nun noch ein Template für Services an.

Ich denke hier muss ich die einzelnen Schritte nicht weiter erläutern.

3. Anlegen der command.conf

Nachdem wir nun die erste Templates angelegt haben, müssen wir als nächstes die command.conf definieren. Hier wird geregelt, welche Skripts/Binarys zu einem Check gehören und wie dieser später aufgerufen wird. Da die Erklärung der ganzen Kommandos den Rahmen dieses Tutorials bei weitem sprengen würde, kopieren wir hier die zuvor gesicherte commands.conf in unser conf.d Verzeichnis.

 4. Anlegen der hosts.conf

Für die Host Konfiguration, legen wir zuerst einen neuen Ordner an. Dies ermöglicht es uns, mehrere Host Dateien anzulegen. Wir können diese auch alle in conf.d legen, aber das würde sehr schnell sehr unübersichtlich werden.

Wir könnten jetzt die Datei hosts.conf nenne, wie es auch in der Überschrift steht. Allerdings neige ich dazu, die Dateien nach dem Verwendungszweck zu nennen. Da wir hier zuerst den Icinga2 Host prüfen wollen, nenne ich die Datei localhost.conf

Diese Datei öffnen wir nun wieder mit einem Editor unsere Wahl.

Als erste legen wir ein Objekt für unseren Icinga2 Host an. In diesem importieren wir das zuvor angelegte Template generic-host. Danach geben wir die IP Adresse des zu überwachenden Hosts an. Als letztes legen wir noch den ersten Check direkt für den Host an.

Danach legen wir noch vier Services für den Host an. Diese werden immer nach dem gleichen Schema erstellen. Wir beginnen mit object Service gefolgt von dem Service Namen in Anführungszeichen. In den geschweiften Klammern übergeben wir dann als erstes mit dem Signalwort host_name den Namen des Host Objektes. Anschließend wird mit check_command festgelegt, welcher Check für diesen Host angewendet werden soll.

5. Neustarten der Icinga2 Instanz

Nachdem wir alle Konfigurationdateien angelegt haben, müssen wir Icinga2 noch einmal neustarten. Dies macht man mit dem folgenden Befehl:

Wenn wir keinen Fehler in den Konfigurationsdateien haben, funktioniert dies auch einfach. Sollte ein Fehler vorhanden sein, kommt die folgende Meldung:

Um mehr Information über das Problem zu erhalten, kann der folgende Befehl verwendet werden.

In diesem Fall wurde vergessen, in localhost.conf den Namen des Servers in Anführungszeichen zu setzten

Wenn der Neustart erfolgreich war, sehen wir nun auch den Host mit den von uns soeben angelegten Checks im Frontend von Icinga2.icinga2-server-überwachung

About Christian Piazzi

Ich blogge hier über alles, was mir so in meinem ITler Altag über den Weg läuft =)
Man findet mich privat bei Google+ und Twitter

Comments

  1. Hallo !

    Also irgendwie habe ich Probleme mit Icinga2. Bei mir werden nur die Files unter /etc/icinga/objects/ angezogen. Aber alles was unter /etc/icinga2/conf.d liegt ignoriert.
    Also das Vorgehen, wie hier beschrieben klappt nicht.
    Die Installation habe ich, wie in Deiner Artikel für Centos7, entsprechend vorgenommen.
    Vielleicht hast Du irgendeine Idee ?

    Viele Grüße Martin

    • Christian Piazzi says:

      Hallo Martin,

      kannst du mir mal die Ausgabe von systemctl status icinga2.service hier posten?
      Ich vermute, dass der Include in /etc/icinga2/icinga2.conf nicht richtig ist. Dort müsste es einen Eintrag dafür geben, wo die Konfigurationsdateien abgelegt sind.

      Gruß

      Christian

  2. Hallo Christian,

    ich habe den Fehler gefunden.
    im Log /var/log/icinga/ido2db.debug sehen ich:
    [1452788222.328145] [001.2] [pid=17946] [tid=140385382893376] ido2db_db_version_check() db version 1.14.0 does not match schema version 1.13.0

    Wenn ich nun diese Versions-Information in der DB umsetze auf 1.13.0:

    MariaDB [(none)]> use icinga;
    Reading table information for completion of table and column names
    You can turn off this feature to get a quicker startup with -A

    Database changed
    MariaDB [icinga]> select * from icinga_dbversion;
    +————–+———-+———+———————+———————+
    | dbversion_id | name | version | create_time | modify_time |
    +————–+———-+———+———————+———————+
    | 1 | idoutils | 1.14.0 | 2016-01-11 13:09:52 | 2016-01-11 13:09:52 |
    +————–+———-+———+———————+———————+
    1 row in set (0.00 sec)

    MariaDB [icinga]> UPDATE icinga.icinga_dbversion SET version=’1.13.0′ WHERE dbversion_id=’1′;

    Dann passiert genau das: es wird dann wohl alles unter /etc/icinga/ aktiv und die Konfiguration unter /etc/icinga2 interessiert dann nicht mehr oder nur noch zum Teil. Der Teil der unter /etc/icinga2/conf.d liegt wird auf jeden Fall dann nicht mehr beachtet.

    ich leben jetzt ohne ido2db – was jetzt für mich erst mal keine negativen Auswirkungen hat.

    Gruss Martin

  3. anonymer Leser says:

    Hallo,

    kann es sein, dass dieser Blogeintrag nicht mehr zur aktuellen (Januar 2016) Icinga2-Version passt? Im Blogeintrag taucht das Verzeichnis /etc/icinga2/repository.d/, in dem die Konfiguration der einzelnen zu überwachenden Hosts abgelegt wird, gar nicht auf. Stattdessen wird das Verzeichnis /etc/icinga2/conf.d/hosts erstellt, welches in einer Standardinstallation nicht existiert und auch nicht im Verzeichnis /etc/icinga2/conf.d liegen sollte.

    • Christian Piazzi says:

      Hallo,

      der Artikel ist tatsächlich schon etwas älter.
      Ich werde das die Tage mal prüfen. Hilfreich wäre es, wenn du mir sagen könntest, welche Paketversion von Icinga2 du installiert hast.

      Gruß

      Christian

      • anonymer Leser says:

        Hallo,

        wie man bestimmt gemerkt hat, bin ich erst in der Kennenlernphase mit Icinga2. Einige Stunden Lektüre später komme ich zu dem Schluss, dass meine Frage wohl Unfug war. Meine Annahmen basierten auf einigen Tutorials und Artikeln, die wohl zu sehr mit Scheuklappen geschrieben waren. Nach meinem heutigen Erkenntnisstand passt jetzt alles viel besser :-)

  4. Thorsten says:

    Hallo,

    vielen Dank für Deinen Blog. Ich versuche mich grade in den ersten Schritten an Icinga2 ranzutasten.
    Du schreibst hier vom Anlegen von zwei Templates, nennst die Datei aber einfach nur templates.conf. Schreibe ich nun beide Inhalte (Host und Services) in diese eine Datei untereinander oder muss ich mehrere templates.conf erstellen?
    Danke für Deine Antwort.

    Gruß Thorsten

  5. Hallo,

    danke für Deine Mühe!

    Kurze Frage noch, wenn ich z.B. für verschiedene HostGroups unterschiedliche Notification Intervalle haben will z.b. für Switches andere wir für VMs –> WO genau mach ich das?

    Mittels template? oder in der Hostgroup direkt?

    Danke vorab 😉

    Grüße

    Alex

    • Christian Piazzi says:

      Hallo Alex,

      Vielen Dank für dein Feedback.

      Zeitintervalle kannst du als Timeperiod definieren. Wenn du für alle Host den selben Zeitintervall willst (Switche/VMs/etc.) dann macht es Sinn diese im Template zu realisieren. Alternativ kannst du auch ein Template für jede Geräteklasse definieren.
      In kleineren Setups (unter 100 Überwachungsobjekte) macht es Sinn die Timeperiod in der entsprechenden Hostgroup zu hinterlegen.

      Beide Varianten funktionieren ohne Probleme. In den Hostgroups wird es nur irgendwann unübersichtlich.

      Ich hoffe ich konnte dir damit weiterhelfen.

      Gruß

      Christian

      • Danke für Deine schnelle Antwort,

        ja ich habe ca. 300 Hosts, ca. 750 Services und 14 Hostgroups
        und ich möchte einfach nur meine Zeitintervalle vom Icinga1 ( die ja vorher weder am Hostobjekt selbst noch, noch in der Hostgroup waren) wieder abbilden.

        Ich weiß mit Icinga2 gibts jetzt viel mehr Möglichkeiten, deshalb frag ich eben nach.

        Ideal sagte mein Chef wäre es eigentlich wenn wir unterschiedliche GEwichtungen hätten sprich wenn z.B. ein DHCP nicht mehr pingbar ist, ist das zwar nicht toll (kann abe rja viele Gründe haben), aber wenn ein DHCP seinen DHCP Service verliert bzw. keine IPs mehr vergeben kann, dann ist das was Schlimmes 😉

        Ich bin jetz eben nur unsicher, ob ich die Intervalle auf die Hostgruppen leg (hab ich schon probiert dann gabs Fehler, weil er sowas wie checkinterval usw. nicht im Hostgroup Objekt haben möchte) oder ob ich die intervalle auf jeden Host leg, aber selbst wenn ich in jedem Hostobjekt verschiedene intervallZeiten hinterlege (Was ja easy geht), hab ich das Problem mit den Gewichtungen noch nicht (oberes Beispiel mit DHCP) abgedeckt…

        Ich hoffe ich konnte es Dir einigermaßen gut erklären 😉

        Danke vorab für jegliche neue Anregungen!

        Gruß

        • Christian Piazzi says:

          Ok. Was soll das Ergebnis der Gewichtung sein? In den meisten fällen ist es ja so, dass Icinga mit einem Ticketsystem gekoppelt ist. Wenn dies der Fall ist, kannst du z.B. Ping und Service Tickets erstellen lassen. Die eine Unterschiedliche Priorität haben.
          Ansonsten kann man auch sowas machen:
          apply Notification "notify-cust-xy-mysql" to Service {
          import "cust-xy-notification"

          assign where match("*has gold support 24x7*", service.notes) && (host.vars.customer == "customer-xy" || host.vars.always_notify == true)
          ignore where match("*internal", host.name) || (service.vars.priority < 2 && host.vars.is_clustered == true)
          }

          In der untere Zeile siehst du, dass man auch eine priority Variable zur Verfügung hat um Gewichtungen zu realisieren.
          damit habe ich selbst aber leider noch keine Erfahrung gesammelt.

          Gruß

          Christian

  6. Daniel says:

    Hallo,
    ich bekomme diesen Fehler und habe keine Idee, wie ich den beheben kann:
    “root@icinga:~# systemctl status icinga2.service
    ● icinga2.service – LSB: icinga2 host/service/network monitoring and management system
    Loaded: loaded (/etc/init.d/icinga2; bad; vendor preset: enabled)
    Active: failed (Result: exit-code) since Mi 2016-06-22 08:41:37 CEST; 8s ago
    Docs: man:systemd-sysv-generator(8)
    Process: 2085 ExecStart=/etc/init.d/icinga2 start (code=exited, status=1/FAILURE)

    Jun 22 08:41:37 icinga systemd[1]: Starting LSB: icinga2 host/service/network monitoring and management system…
    Jun 22 08:41:37 icinga icinga2[2085]: * checking Icinga2 configuration
    Jun 22 08:41:37 icinga icinga2[2085]: * checking Icinga2 configuration. Check ‘/var/log/icinga2/startup.log’ for details.
    Jun 22 08:41:37 icinga systemd[1]: icinga2.service: Control process exited, code=exited status=1
    Jun 22 08:41:37 icinga systemd[1]: Failed to start LSB: icinga2 host/service/network monitoring and management system.
    Jun 22 08:41:37 icinga systemd[1]: icinga2.service: Unit entered failed state.
    Jun 22 08:41:37 icinga systemd[1]: icinga2.service: Failed with result ‘exit-code’.”

  7. patrick says:

    Hallo,

    hab leider das problem das ich beim durchstarten folgende meldung bekomme und den fehler leider nicht finden kann.

    [root@localhost ~]# systemctl status icinga2.service -l
    ● icinga2.service – Icinga host/service/network monitoring system
    Loaded: loaded (/usr/lib/systemd/system/icinga2.service; enabled; vendor preset: disabled)
    Active: failed (Result: exit-code) since Mit 2016-06-22 15:20:32 CEST; 2min 46s ago
    Process: 3027 ExecStart=/usr/sbin/icinga2 daemon -d -e ${ICINGA2_ERROR_LOG} (code=exited, status=1/FAILURE)
    Process: 2967 ExecStartPre=/usr/lib/icinga2/prepare-dirs /etc/sysconfig/icinga2 (code=exited, status=0/SUCCESS)

    Jun 22 15:20:32 localhost.localdomain icinga2[3027]: Location: in /etc/icinga2/icinga2.conf: 50:1-50:26
    Jun 22 15:20:32 localhost.localdomain icinga2[3027]: /etc/icinga2/icinga2.conf(48): * directory. Each of these files must have the file extension “.conf”.
    Jun 22 15:20:32 localhost.localdomain icinga2[3027]: /etc/icinga2/icinga2.conf(49): */
    Jun 22 15:20:32 localhost.localdomain icinga2[3027]: /etc/icinga2/icinga2.conf(50): include_recursive “conf.d”
    Jun 22 15:20:32 localhost.localdomain icinga2[3027]: ^^^^^^^^^^^^^^^^^^^^^^^^^^
    Jun 22 15:20:32 localhost.localdomain icinga2[3027]: /etc/icinga2/icinga2.conf(51):
    Jun 22 15:20:32 localhost.localdomain systemd[1]: icinga2.service: control process exited, code=exited status=1
    Jun 22 15:20:32 localhost.localdomain systemd[1]: Failed to start Icinga host/service/network monitoring system.
    Jun 22 15:20:32 localhost.localdomain systemd[1]: Unit icinga2.service entered failed state.
    Jun 22 15:20:32 localhost.localdomain systemd[1]: icinga2.service failed.
    [root@localhost ~]#

    besten dank für die hilfe,

    Grüße,
    Patrick

    • Christian Piazzi says:

      Hallo Patrick,

      der Fehler sagt dir, dass du eine falsche Konfiguration in /etc/icinga2/icinga2.conf hast. Kannst du mir den Inhalt der Datei irgendwie zur Verfügung stellen. (Hier kommentieren oder irgendwo zum Download freigeben).
      Ansonsten gibt es die Möglichkeit die Konfiguration zu prüfen. Da sagt er dann ziemlich genau was falsch ist. Den Befehl muss ich aber erst raussuchen.

      Gruß

      Christian

  8. patrick says:

    Hallo Christian,

    folgendes steht im icinga2.conf:

    **
    * Icinga 2 configuration file
    * – this is where you define settings for the Icinga application including
    * which hosts/services to check.
    *
    * For an overview of all available configuration options please refer
    * to the documentation that is distributed as part of Icinga 2.
    */

    /**
    * The constants.conf defines global constants.
    */
    include “constants.conf”

    /**
    * The zones.conf defines zones for a cluster setup.
    * Not required for single instance setups.
    */
    include “zones.conf”

    /**
    * The Icinga Template Library (ITL) provides a number of useful templates
    * and command definitions.
    * Common monitoring plugin command definitions are included separately.
    */
    include
    include
    // include

    /**
    * The features-available directory contains a number of configuration
    * files for features which can be enabled and disabled using the
    * icinga2 feature enable / icinga2 feature disable CLI commands.
    * These commands work by creating and removing symbolic links in
    * the features-enabled directory.
    */
    include “features-enabled/*.conf”

    /**
    * The repository.d directory contains all configuration objects
    * managed by the ‘icinga2 repository’ CLI commands.
    */
    include_recursive “repository.d”

    /**
    * Although in theory you could define all your objects in this file
    * the preferred way is to create separate directories and files in the conf.d
    * directory. Each of these files must have the file extension “.conf”.
    */
    include_recursive “conf.d”

Speak Your Mind

*