Icinga E-Book

Lennart Betz

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: iX Edition
• Sprache: Deutsch
• Veröffentlichungsjahr: 2022

Seitenzahl: 753

Beschreibung

Icinga – der Standard für Monitoring

• Praktischer Einstieg in die Überwachung mit Icinga
• Überwachung von Linux- und Windows-Systemen
• Verteilte Überwachung mit Einsatz von Icinga-Satelliten

Nach der Einführung in die Komponenten eines Icinga-Umgebung, den wichtigsten Begriffen, der Installation und der Bedienoberfläche Icinga Web 2 folgt sogleich der Praktische Einstieg in die Überwachung mit Icinga. Anhand einer Beispielfirma erfolgt die Einarbeitung in die Konfigurationssprache Icinga DSL. Zentraler Punkt des ersten Bandes ist die Überwachung von Linux- und Windows-Systemen mit dem Icinga-Agenten wie auch generell die verteilte Überwachung mit Einsatz von Icinga-Satelliten. Daran und an praktischen Beispielen wie mit Plugins gängige Netzwerkdienste, Datenbanken wie PostgreSQL, MariaDB, Oracle oder Microsoft SQL werden die bisher erworbenden Icinga-DSL-Kenntnisse weiter vertieft. Weitere Kapitel über Benachrichtigung und Abhängigkeiten, vertiefende Kenntnisse in die Bedienung von Icinga Web 2 und das Modellieren von Businessprozessen runden den ersten Band ab.

Leseprobe

Lennart Betz arbeitet als Consultant und Trainer bei der Nürnberger NETWAYS GmbH. Seine Hauptarbeitsgebiete sind Planung, Aufbau und Betreuung von Monitoringlösungen, Konfigurationsmanagement und weitere Automatisierungsthemen. Schon früh während seines Mathematikstudiums beschäftigte er sich mit Freier Software und verfolgt dies auch seit dem Abschluss in seiner beruflichen Tätigkeit konsequent weiter.

Thomas Widhalm hilft als Lead Support Engineer Kunden der Netways GmbH beim Beheben von Problemen mit Icinga-Installation. Außerdem unterstützt er als Consultant Kunden bei der Planung, Umsetzung und weiteren Betreuung von Projekten im Bereich Monitoring und Logmanagement. Als Trainer zeichnet er sich für die Schulungen im Bereich Logmanagement verantwortlich. Im Icinga-Team arbeitet er an der Online-Dokumentation mit. Er ist überzeugt, dass Freie Software proprietärer Software überlegen ist und ihre Konzepte auch außerhalb der IT mehr Anwendung finden sollten.

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Lennart Betz · Thomas Widhalm

Icinga

Monitoring – Grundlagen und Praxis

Lennart Betz, Thomas Widhalm

[email protected]

Lektorat: Dr. Michael Barabas

Projektkoordinierung: Anja Weimer

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Lennart Betz

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-86490-879-8

PDF

978-3-96910-622-8

ePub

978-3-96910-623-5

mobi

978-3-96910-624-2

1. Auflage 2022

Copyright © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es unswissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autoren noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Wie mache ich es richtig? Ich vermute durchaus, dass dies eine Frage ist, die Sie zum Kauf dieses Buchs bewogen hat. In den vielen Jahren, die wir als Icinga und die Autoren das Produkt begleiten, ist uns diese Frage ebenfalls immer wieder begegnet. Allerdings gibt es für viele Fragestellungen und Szenarien im Bereich der Infrastrukturüberwachung oft nicht die eine richtige Antwort, um ans Ziel zu kommen. Umgebungen sind unterschiedlich und somit verändert sich auch der passende Lösungsansatz.

Dieses aktualisierte Icinga-Buch geht nochmals detaillierter auf die unterschiedlichen Herausforderungen moderner IT und den Einsatz von Icinga ein. Dabei grenzt sich das Werk vor allem durch die geradlinige Führung des Lesers von anderen Werken und zugegebenermaßen auch der Dokumentation ab. Die Autoren nehmen Sie an die Hand und helfen Ihnen beim richtigen Konfigurieren und Betrieb von Icinga. Dabei ist trotz der Balance zwischen der Betrachtung unterschiedlicher Bedürfnisse stets ein roter Faden erkennbar, der dieses Buch besonders macht. So wird es Sie über den Einstieg und die Konfiguration hinaus im täglichen Betrieb begleiten und Ihnen die Überwachung unterschiedlicher Systeme und Umgebungen nahebringen. Außerdem geht das Buch auf Fragestellungen ein, die sich dem erfahrenen Anwender und Administrator von Icinga stellen: Virtualisierte Umgebungen, APIs, Visualisierung zeitlicher Verläufe und das Thema Hochverfügbarkeit sind detailliert und gleichzeitig leicht zugänglich beschrieben.

Dass die Autoren darüber hinaus über jahrzehntelange praktische Erfahrung mit Icinga verfügen, macht das Buch zu einem Standardwerk für den richtigen Einsatz von Icinga. Der Leser profitiert von dieser Erfahrung, die dem gesamten Buch immer wieder zu entnehmen ist. Daher kann ich Sie zum Kauf des Buchs mit bestem Wissen und Gewissen nur beglückwünschen.

Egal ob Einsteiger oder Fortgeschrittener, wünsche ich Ihnen bei der Einrichtung und dem Betrieb von Icinga mindestens genauso viel Freude wie beim Studieren dieses Buchs. Alles, was Sie dafür brauchen, halten Sie in Ihren »Händen«.

Bernd Erk

CEO Icinga

Einige Zeilen zum Buch selbst

Das vorliegende Buch richtet sich an Administratoren, die Icinga einsetzen, mit dem Gedanken spielen, dies zu tun, oder in absehbarer Zeit zu Icinga migrieren möchten. Die zentralen Komponenten einer Überwachung mit Icinga sind Linux-basiert. Daher ist ein Grundwissen von Linux zwingend für das Verständnis der Materie erforderlich. Das Buch richtet sich aber gleichermaßen auch an erfahrene Linux-Administratoren, die Icinga bereits einsetzen. Es behandelt auch Schnittstellen, die es ermöglichen, Icinga mit anderer Software zu verknüpfen, wie die Integration von Messdaten und deren Darstellung (Graphing) über einer Zeitachse oder das Einbinden von Erkenntnissen aus einem Logmanagement. Nebenbei sind viele Vorschläge enthalten, wie die Überwachung selbst erweitert werden kann.

Struktur dieses Buchs

Dieses Buch besteht aus fünf Teilen, die sich wiederum in einzelne Kapitel gliedern. Der erste Teil gibt eine kleine Einführung in das Thema Monitoring und stellt die einzelnen Softwarekomponenten von Icinga vor.

Der zweite Teil stellt den Icinga-Agenten vor und beschreibt, wie mit dem Agenten Linux- und Windows-Systeme zu überwachen sind.

Teil drei ist der praktischen Überwachung mit unterschiedlichen Plugins vorbehalten. Es werden einige Plugins vorgestellt und beschrieben, wie diese zu installieren und in Icinga zu integrieren sind.

In den letzen beiden Teilen wird darauf eingegangen, wie Icinga erweitert wird und sich in andere Systeme integrieren lässt. Aber auch die Realisierung von verteilter Überwachung mit Icinga und die Erhöhung der Ausfallsicherheit des eigenen Monitorings werden thematisiert.

Der Anhang ist nicht nur ein Nachschlagewerk, sondern vertieft und erweitert Ihr Wissen um die Themenkomplexe Tuning, Security, Updates und Datensicherung.

In diesem Buch behandelte Versionen

Dieses Buch behandelt Icinga 2 in der Version 2.13 und Icinga Web 2 Version 2.8 und Version 2.9. Alle Beispiele zu Installationen beziehen sich, wenn nicht anders angegeben, auf die Distributionen RHEL/CentOS 8 bzw. Debian Bullseye. Dabei wird RHEL wie auch CentOS mit RedHat synonym verwendet.

Das in mehreren Kapiteln eingesetzte und in seiner Benutzung beschriebene MySQL wird ebenfalls als Synonym für MariaDB benutzt.

Typografische Konventionen

In diesem Buch werden folgende typografischen Konventionen verwendet:

Nichtproportionalschrift

Wird benutzt für Namen von Programmen, Befehlen sowie für Codebeispiele.

Kursivschrift

Kommt zum Einsatz bei spezifischen Wörtern in Konfigurationen wie Schlüsselwörtern, Objektnamen, deren Attributen oder Custom Variables.

Nichtproportionalschrift kursiv

Wird bei Datei- und Verzeichnisnamen verwendet.

Kommandos oder Codezeilen, die dem Format dieses Buchs geschuldet einem unnötigen oder falschen Zeilenumbruch unterworfen sind, haben am Ende der Zeilen einen Backslash »\«.

Materialien zum Buch

Die Codebeispiele in diesem Buch, die sich auf die Konfiguration von Icinga beziehen, befinden sich auch online zugänglich in einem Repository1 auf GitHub. Kommandos auf der Kommandozeile müssen wohl oder übel abgetippt werden.

$ git clone https://github.com/lbetz/icinga-book

Die Beispiele befinden sich unterhalb des Verzeichnisses /code. Aufgetretene und entdeckte Fehler an den Beispielen werden wir ebenfalls dort korrigieren sowie generelle Korrekturen am Text unterhalb /errata hochladen.

Die Beispiele sind nach Kapiteln in Unterverzeichnisse aufgeteilt und dort als Textdateien abgelegt, deren Namen der jeweiligen Codebeispielnummer entsprechen.

Danksagung

Lennart Betz

Danke an all die lieben und engagierten Menschen, die sich mit Icinga beschäftigen und durch ihre direkte Arbeit, Zuarbeit durch Issues oder in der Community dieses Projekt ermöglichen. Vielen Dank an Bernd als treibende Kraft, der mich auch moralisch immer unterstützte. Mein besonderer Dank geht auch an Thomas, der mir nicht die Freundschaft kündigte, obwohl ich dieses Buch nahezu ohne ihn geschrieben habe.

Servus

Lennart

Thomas Widhalm

Ich möchte mich bei all den Leuten bedanken, die mich zu dem gemacht haben, der ich heute bin. Vor allem bei meiner Frau, auch weil sie die vielen »Ich muss heute unbedingt an diesem Buch arbeiten«-Tage ertragen hat. Ganz besonders bedanken möchte ich mich bei Lennart, weil er mir die Möglichkeit gegeben hat, genug zu dieser Auflage beizutragen, um meinen Namen am Umschlag zu rechtfertigen. Und das, obwohl ich mich aus persönlichen Gründen weitgehend aus dem Projekt zurückziehen musste und er fast alles alleine gestemmt hat.

Vielen Dank für alles,

Thomas Widhlam

Feedback

Die Qualität jedes Fachbuchs misst sich am Nutzen, den es für seine Leser hat. Wir würden uns freuen, davon zu hören, was Sie als Leser nützlich im Buch fanden und wo wir uns noch verbessern können. So wie sich die beschriebene Software weiterentwickelt, soll es auch unser Buch tun und hiermit geben wir Ihnen die Chance, die Richtung zu beeinflussen, in die es geht.

Für Rückmeldungen zum Buch freuen wir uns über E-Mails an [email protected].

Inhaltsverzeichnis

IEinführung

1Einleitung

1.1Monitoring

1.2Das Universum um Icinga

1.3Installation

1.4Sicherheits- und Zugriffskontrolle

2Erste Schritte auf der Benutzeroberfläche

2.1Dashboards

2.2Navigation

2.3Detailansicht von Host- und Servicechecks

2.4Monitoring Health

2.5Aktionen auf Mehrfachauswahl

2.6Benutzereinstellungen

2.7Kommentare

2.8Acknowledges – Bestätigen von Problemen

2.9Downtimes

3Grundkonfiguration von Icinga

3.1Konstanten

3.2Features

3.3Icinga Web 2

4Aufbau des eigenen Monitorings

4.1Kleine Sprachreferenz Icinga-DSL

4.2Host und Hostgruppen

4.3Service und Servicegruppen

4.4Check Commands und die Template Library

4.5Makros und deren Substitution

4.6Timeperiods

4.7Scheduled Downtimes

4.8Debugging

IIBetriebssystemüberwachung

5Der Icinga-Agent

5.1Zonen und Endpunkte

5.2Vorbereiten des Icinga-Servers

5.3Zertifikate beglaubigen

5.4Konfiguration auf Linux

5.5Konfiguration auf Windows

5.6Anbinden der Agenten an den Server

6Linux-Systeme überwachen

6.1Prozessorauslastung

6.2Hauptspeicher

6.3Swap

6.4Dateisysteme

6.5Lokale Zeit

6.6Lauffähige Prozesse

6.7Updates

6.8SSH als Alternative für Unix-Derivate und ältere Linux-Systeme

7Windows-Systeme überwachen

7.1Prozessorauslastung

7.2Hauptspeicher

7.3Dateisysteme

7.4Lokale Zeit

7.5Dienste

7.6Lauffähige Prozesse

7.7Updates

7.8Abfragen von Performance-Counter

IIIFortgeschrittene Themen

8Icinga Web 2 einsetzen, anpassen und erweitern

8.1Filter

8.2Dashboards

8.3Ressourcen

8.4Berechtigungen

8.5Icinga Web 2 von der Kommandozeile

8.6Module

8.7Reporting

9Benachrichtigungen

9.1Das Benachrichtigungssystem

9.2Flapping-Erkennung

9.3Abhängigkeiten

9.4Eskalationen

9.5Events

10Verteilte Überwachung

10.1Zonen und Endpunkte

10.2Installation und Konfiguration eines Workers

10.3Konfiguration auf Zonen aufteilen

10.4Zertifikatsbeglaubigung in verteilten Umgebungen

11Director

11.1Installation

11.2Deployment der Konfiguration

11.3Hosts und Host-Templates

11.4Datenfelder und Listen

11.5Commands

11.6Services und deren Templates

11.7Servicesets

11.8Konfigurationsdateien mittels Fileshipper

11.9Automatisierung und Synchronisation

11.10Benachrichtigungen

11.11Integration der Agenten-Installation mit Powershell

11.12Monitoring des Directors

12Icinga-DSL

12.1Console

12.2Schleifen und Iterationen

12.3Funktionen

12.4Gültigkeitsbereiche

IVPlugins für weitere Dienste

13Allgemeines zu Plugins

13.1Schwellenwerte

13.2Performance-Daten

13.3Plugin-Aufruf und erweiterte Berechtigungen

13.4Repository

13.5Plugins bewerten, selbst entwickeln und veröffentlichen

14Netzwerkdienste

14.1Erreichbarkeit

14.2Zeitserver

14.3Domain Name Service

14.4DHCP

14.5Webserver

14.6Proxyserver

14.7Kerberos

14.8Mailverkehr

14.9Generische Portüberwachung

15Datenbanken

15.1MySQL und MariaDB

15.2PostgreSQL

15.3Oracle

15.4Microsoft SQL

15.5LDAP

16Microsoft-Infrastrukturdienste

16.1Common Internet Filesystem

16.2Terminal Service

16.3Domain Controller und Active Directory

16.4Exchange

16.5Microsoft Cluster

17Hardware

17.1Informationsabfrage mit SNMP

17.2Netzwerk

17.3Server

17.4Storage

18Virtuelle Umgebungen

18.1VMware VSphere

18.2Microsoft Hyper-V

18.3Proxmox VE

18.4Virtuelle Maschinen in der Cloud

19Applikationen

19.1AppServer

19.2SAP

19.3Elastic

19.4Puppet

VIntegration

20Businessprozesse

20.1Einen ersten Businessprozess anlegen

20.2Benachrichtigungen einrichten

20.3Bearbeiten von Prozessen

20.4Simulation von Ausfällen

20.5Ein etwas komplexeres Beispiel

21Graphing

21.1Datenbanken für Zeitreihen

21.2PNP4Nagios

21.3Graphite

21.4InfluxDB

21.5Grafana

22Icinga-2-REST-API

22.1Einfache Abfragen

22.2Komplexe Abfragen

22.3Actions

22.4Verwalten von Objekten

22.5Abonnieren von Event Streams

22.6Ausgabe über den Browser

22.7Eigene Dashboards mit Dashing

23Logmanagement mit Elastic und Icinga

23.1Repository

23.2Logstash

23.3Logshipper

23.4Elasticsearch und Kibana

23.5Elasticsearch-Modul für Icinga Web 2

24Hochverfügbarkeit

24.1Grundlagen und Konzepte

24.2Die einzelnen Komponenten

24.3Icinga 2

24.4Icinga Web 2

24.5Datenbankmanagementsysteme

24.6Time-Series-Datenbanken und ihre Grapher

24.7Beispielszenarien

Anhang

ADas, was du zurücklässt

A.1Goldene Bulle

A.2Tuning

A.3Icinga absichern

A.4Updates

A.5Datensicherung

A.6Troubleshooting

A.7Community

BEs war einmal

CRepositories

DIcinga aus Paketen installieren und konfigurieren

D.1Icinga 2 und Plugins

D.2Datenbank-Backend

D.3Icinga Data Output

D.4API einrichten

D.5Icinga Web 2

D.6Vorbereiten des Icinga-Servers zur verteilten Überwachung

EAusblick auf die IcingaDB

FCheck Commands und Templates

F.1Powershell-Plugins

F.2Visual-Basic-Skripte

F.3Weitere Linux-basierte Plugins

F.4Hardware

F.5Templates für Exchange

Index

IEinführung

1Einleitung

Drei Freunde aus den USA, die als Juniordetektive tätig sind, baten uns um Unterstützung bei der Überwachung der IT-Systeme eines großen Second-handshops. Das »Gebrauchtwarencenter Jonas«, auf dessen Gelände unsere Freunde ihre Zentrale eingerichtet hatten, war ein voller Erfolg und so wurde auch die IT mit der Zeit immer umfangreicher.

Der Erfolg führte zu neuen Services und Applikationen, die natürlich ebenfalls überwacht werden mussten, um rund um die Uhr den reibungslosen Verkauf zu gewährleisten. Dieses Buch beschreibt, wie Icinga im Hintergrund half, diese Ziele zu erreichen, und welchen Weg ich dabei gegangen bin.

Der erste Teil des Buchs definiert, was Monitoring mit Icinga genau bedeutet. Er beschreibt die Architektur von Icinga und führt alle wichtigen Begriffe ein. Nach der Installation werfen wir einen ersten Blick auf die Benutzeroberfläche und gehen anschließend noch auf die Konfiguration der Kernkomponenten ein. Am Ende des ersten Teils wird die Umgebung des Gebrauchtwarencenters vorgestellt und sogleich damit begonnen diese zu überwachen.

Im zweiten Teil steht der Icinga-Agent im Mittelpunkt. Dieser wird zur Überwachung von Linux- und Windows-Systemen verwendet. Mit seiner Hilfe kann beispielsweise die Auslastung der CPU, des Hauptspeichers und der Dateisysteme ermittelt und an Icinga gemeldet werden. Als Alternative zum Agenten, inbesondere für ältere Linux- oder andere Unix-Systeme, wird die Überwachung unter Zuhilfnahme der Secure Shell (SSH) vorgestellt.

Der dritte Teil widmet sich bereits fortgeschritteneren Themen. So startet dieser mit Erläuterungen, wie sich die Benutzeroberfläche Icinga Web 2 weiter ausreizen lässt. Das Formulieren von Filtern und das Anlegen eigener Dashboards wird behandelt, aber auch, wie Icinga Web 2 durch zusätzliche Module erweitert werden oder zur Authentifizierung an ein Microsoft Active Directory (AD) angebunden werden kann. Die Konzepte von Benachrichtigungen und der verteilten Überwachung befinden sich enbenfalls in diesem Teil, wie auch die Einführung in den Icinga Director, der eine grafisch unterstützte Konfiguration ermöglicht.

Ausschließlich um weitere Plugins geht es in Teil vier. Es werden weitere Plugins vorgestellt sowie deren Installation und Anwendung erläutert. Es wird gezeigt, wie Netzwerkdienste der eigenen Infrastruktur überwacht werden, aber auch die zugrunde liegende Hardware sowie Datenbanken und Application Server.

Um Integration geht es im letzten Teil. Hier werden zunächst Businessprozesse eingeführt und gezeigt, wie solche in Icinga definiert und überwacht werden. Die Integration anderer Systeme ist ebenfalls Thema dieses Teils. Kapitel 21 ab Seite 447 beschäftigt sich sehr ausführlich damit, wie von Icinga erfasste Daten in Zeitreihen gespeichert werden können und in die Benutzerobfläche einzubinden sind. Die Überwachung auf bestimmte Logeinträge zeigt Kapitel 23. Zuvor wird jedoch in Kapitel 22 die hiefür erforderliche Schnittstelle von Icinga vorgestellt.

Den Abschluss bildet ein nicht ganz triviales Thema: Hochverfügbarkeit. Es wird erörtert, was wann zu tun ist, um die Fehlertoleranz und damit die Verfügbarkeit einzelner Komponenten oder des Gesamtsystems zu erhöhen. Da das Thema sehr komplex ist und mitunter zusätzliche Software erfordert, nähert sich dieses Kapitel der Problematik auf theoretischer Ebene.

Der Anhang ist nicht nur ein Nachschlagewerk, sondern vermittelt in Abschnitt A viel Wissen über Updates, Datensicherung, Tuning, Troubleshooting und die Absicherung der eigenen Icinga-Umgebung. Die Installation einer Icinga-Umgebung per Hand und aus den Paketquellen beschreibt Anhang D. Der Anhang E gibt hingegen einen kurzen Ausblick auf die IcingaDB, die mittelfristig den IDO als Backend ersetzen soll, wodurch dessen Performanceprobleme der Vergangenheit angehören sollen.

Wer Interesse an der Geschichte rund um Icinga hat, sei hier auf Anhang B verwiesen, der diese kurz zusammengefasst.

Wenn nicht anders beschrieben, sind alle Beispiele, was Installation und Betrieb betrifft, auf RedHat Enterprise Linux (RHEL) in der Version 8 und Debian Bullseye ausgelegt. Mit ein wenig Erfahrung lassen sich die Anleitungen und Beispiele aber auch auf andere Distributionen übertragen.

»Es sind 106 Meilen bis Chicago, wir haben einen vollen Tank, ein halbes Päckchen Zigaretten, es ist dunkel und wir tragen Sonnenbrillen.«

Elwood Blues, 1980

So viel zum Überblick, welche Themen behandelt werden und wo sie zu finden sind. Nun genug der Worte und viel Spaß mit Icinga!

1.1Monitoring

Der Begriff »Monitoring«1 bezeichnet die Überwachung von Vorgängen. Es ist ein Überbegriff für alle Arten von systematischen Erfassungen, Messungen oder Beobachtungen eines Vorgangs oder Prozesses mittels technischer Hilfsmittel oder anderer Beobachtungssysteme.

Eine wichtige Funktion des Monitorings besteht darin, bei einem beobachteten Ablauf oder Prozess festzustellen, ob dieser den gewünschten Verlauf nimmt und bestimmte Schwellenwerte eingehalten werden, um andernfalls steuernd eingreifen zu können. Monitoring ist deshalb ein Sondertyp des Protokollierens.

Übertragen auf die IT definiert Wikipedia den »Service-Monitor«2. Ein Service-Monitor ist ein Programm, das auf einem Server läuft und Systemressourcen von Servern und deren Rechnernetze überwacht. Des Weiteren gibt es Dienste, die verschiedene Funktionen des Servers von extern in kontinuierlichen Zeitabschnitten überprüfen und die Ergebnisse entsprechend aufbereiten. Bei Fehlfunktionen wird der Betreiber des Servers oder der Services benachrichtigt.

Ohne Monitoring können die Betreiber bzw. die verantwortlichen Administratoren von IT-Systemen nur dann reagieren, wenn ein Anwender eine Störung meldet, sie diese Störung selbst zufällig feststellen oder ein abhängiges System einen Fehler meldet. Bei dem heute üblichen Verhältnis zwischen der Anzahl von Systemen zu deren Betreuern ist eine kontinuierlich stattfindende, manuelle Kontrolle nicht mehr zu realisieren. Meldet hingegen ein Anwender einen Ausfall, ist dies nicht nur für genau diesen ärgerlich, sondern auch für alle anderen, die zeitgleich auf das gestörte System zugreifen. Durch die massive Parallelisierung sind dies z. B. bei der Webseite eines Onlineshops viele Tausend potenzielle Kunden, die nun möglicherweise bei einem Marktbegleiter kaufen. Genau solche Ausfälle sollen durch ein Monitoring-System vermieden werden, in dem Probleme frühzeitig erkannt werden und rechtzeitig Gegenmaßnahmen ergriffen werden können.

Gegenmaßnahmen lassen sich nur einleiten, wenn Probleme den Verantwortlichen auch bekannt gemacht werden. Ein Monitoring-System muss über Mechanismen verfügen, Personen oder Gruppen von Personen aktiv zu benachrichtigen.

1.2Das Universum um Icinga

Eine Installation zum Monitoring mit Icinga besteht grundlegend aus vier Komponenten und wird ausschließlich auf Linux unterstützt. Die Überwachung weiterer Plattformen wie Windows ist aber natürlich gegeben. Die Kernkomponente, die alles steuert, ist Icinga 2.

Abbildung 1-1: Die einzelnen Icinga-Komponenten

Die Anzeige des aktuellen Status übernimmt Icinga Web 2, eine Datenbank wird zum Datenaustausch zwischen beiden Komponenten benötigt.

Aus der Benutzeroberfläche Icinga Web 2 heraus steuert der Anwender Icinga 2 interaktiv. Einzelne spezialisierte Plugins übernehmen die Überwachung und Benachrichtigung.

1.2.1Plugins

Der Name Plugin ist irreführend, da es sich jeweils um ein externes Programm oder Skript handelt. Sie nehmen dabei gesonderte Aufgaben wahr und unterteilen sich danach in Check-Plugins, die den Zustand einer zu überwachenden Komponente ermitteln, und Notification-Plugins, die sich um die Benachrichtigung bei erkannten Problemen kümmern.

Check-Plugins

Bei Check-Plugins gibt der Rückgabewert, auch Exit Code oder Return Code (RC) genannt, den Status der Überwachung an. Beendet sich ein Plugin mit »0«, entspricht das einem OK und bedeutet, der überwachte Dienst funktioniert im Rahmen normaler Parameter.

Die Auswahl des Plugins entscheidet darüber, was überwacht wird. Durch Setzen von Optionen beim Plugin-Aufruf wird angegeben, wo der Dienst läuft, wie er zu überwachen ist und welche Schwellen gelten sollen, um den Zustand OK von WARNING mit dem Exit Code »1« und CRITICAL mit »2« abzugrenzen.

$ ./check_http -H www.google.com -w 0.5 -c 1

HTTP OK: HTTP/1.1 200 OK - 13430 bytes in 0.099s response time

$ echo $?

0

Worauf sich Schwellenwerte beziehen, richtet sich nach dem gewählten Plugin. Das Plugin check_http baut eine Verbindung via Hypertext Transfer Protocol (HTTP) zum Zielsystem auf und ermittelt neben der Antwortzeit auch die Größe der angeforderten Webseite, die Schwellenwerte für WARNING von »0.5« und CRITICAL von »1« beziehen sich aber ausschließlich auf die Antwortzeit.

Das HTTP-Protokoll ist weit komplexer und wird entsprechend von check_http unterstützt. Neben der Dokumentation des Plugins sind ebenfalls Kenntnisse des Protokolls von Nutzen. Um z. B. eine durch Transport Layer Security (TLS) abgesicherte Seite auf einem per IP-Adresse spezifizierten namensbasierten Webserver abzufragen, kommen weitere Optionen zum Einsatz:

$ ./check_http -H www.google.com.net -I 172.217.22.228 --ssl

HTTP OK: HTTP/1.1 200 OK - 13430 bytes in 0.101s response time

Eine aussagekräftige Hilfe, die zumeist mit --help auf der Kommandozeile aufgerufen wird, kennzeichnet gute Plugins.

Neben dem Exit Code gibt ein Check-Plugin über seinen Plugin-Output in für Menschen verständlicher Form Auskunft über den aktuellen Zustand. Darüber hinaus können zusätzlich vom Plugin ermittelte Werte angefügt sein. Diese Metriken unterscheiden sich je nach Plugin. Bei check_http sind es die Größe sowie die benötigte Zeit des Lesens der Webseite.

Eine weitere Eigenschaft von Check-Plugins, die bisher unterschlagen wurde, ist nicht nur das Ermitteln von Metriken, sondern auch deren Aufbereitung zu einer möglichen maschinellen Weiterverarbeitung. So gibt check_http zwar Metriken in seinem Output aus, in der erweiterten Ausgabe nach einem »|« werden diese Metriken aber z. B. mit den Schwellenwerten kombiniert. Die Gesamtheit dieser Metriken wird allgemein als Performance-Daten bezeichnet.

Jeder einzelne Satz von Performance-Daten identifiziert ein Label, hier time und size, gefolgt jeweils von einem Gleichheitszeichen. Danach stehen die vom Plugin gemessenen Werte, mittels Semikolon abgetrennt kommen an zweiter und dritter Position die Schwellenwerte. Abschließend können optional noch Minimal- und Maximalwert ausgegeben werden.

$ ./check_http -H www.google.com -w 0.5 -c 1

HTTP OK: HTTP/1.1 200 OK - 13527 bytes in 0.074s response time |\

time=0.074161s;0.500000;1.000000;0.000000 \

size=13527B;;;0

Neben Remote-Check-Plugins, die sich mithilfe eines Netzwerkprotokolls zu einem entfernten Rechner verbinden, existieren auch solche, die Ergebnisse durch einen lokalen Aufruf ermitteln. Erforderlich sind diese Local-Check-Plugins, um Werte zu ermitteln, die nur lokal zur Verfügung stehen, wie z. B.:

CPU-Auslastung

Hauptspeicherbenutzung

Platzverbrauch auf Dateisystemen

Laufende Prozesse

…

Solche Plugins müssen binärkompatibel zur Plattform sein, auf der sie aufgerufen werden, und unterscheiden sich je nach Betriebssystem auch in der Parametrisierung, aber mitunter auch in den zurückgelieferten Werten. Auf Unix-Systemen wird die CPU-Auslastung traditionell mit Load-Werten3 angegeben, die in der Aussagekraft über einen auf Windows üblichen Prozentwert hinausgehen.

$ ./check_load -w 4,6,8 -c 6,8,10

WARNING - load average: 4.46, 5.02, 3.76

Im Gegensatz zu check_http werden hier für die drei Werte unterschiedliche Schwellenwerte berücksichtigt.

Da Check-Plugins die gebräuchlichsten Plugins sind, wird von ihnen meistens in verkürzter Form einfach von Plugins gesprochen. Dabei wird sprachlich selten zwischen Remote und Local unterschieden.

Notification-Plugins

Das Versenden von Benachrichtigungen deligiert Icinga ebenfalls an externe Programme, meistens Skripte. In der Regel kümmert sich jedes Notification-Plugin um einen Benachrichtigungsweg, üblich sind Mail- und SMS-Versand, aber es erfreuen sich inzwischen auch Anbindungen an Messaging-Systeme großer Beliebtheit.

Mit Optionen wird den Plugins übergeben, wer zu benachrichtigen ist und welche Informationen mitgeteilt werden sollen. Das Plugin bereitet die Informationen in der Regel entsprechend zum Übertragungsweg vor dem Versand noch optisch auf.

Damit ist Icinga, wie auch mit den Check-Plugins, einfach und schnell erweiterbar. Notification-Plugins sind im Allgemeinen noch viel leichter selbst zu schreiben als Check-Plugins, da erstere z. B. nur den erfolgten Versand mit einem RC von »0« zu bestätigen haben und nicht zwischen Schwellenwerten unterscheiden müssen. Die Programmlogik ist damit einfacher.

1.2.2Icinga 2

Beim Projekt4 Icinga 2 handelt es sich um die unverzichtbare Kernkomponente eines Icinga-Monitoring-Systems. Auf Basis der in den Konfigurationen definierten Überwachung steuert Icinga 2, wann etwas wie zu prüfen ist, wertet den Rückgabewert der entsprechenden Check-Plugins aus und entscheidet, wer im Fehlerfall wie zu benachrichtigen ist. Vereinfacht betrachtet handelt es sich bei Icinga 2 somit um einen »großen« Scheduler5 zur Transaktionsverarbeitung.

Zusammen mit den Plugins erfüllt Icinga 2 die in Abschnitt 1.1 festgelegten Anforderungen an einen »Service-Monitor«.

Host, Service und andere Objekte

Die zu überwachenden Server und die auf ihnen laufenden Dienste werden Icinga 2 in Konfigurationsdateien bekannt gemacht. Neben diesen Hosts und Services werden auch Benachrichtigungen als Objekte definiert, im Icinga-Umfeld Notification genannt. Zu beachten ist, dass für Icinga auch alles, was mit Local-Check-Plugins überwacht werden soll, ein Service ist. Der Host selbst wird »nur« geprüft, ob er erreichbar ist. Standardmäßig wird so ein Hostalive-Check mittels Ping durchgeführt.

Objekte besitzen je nach Typ unterschiedliche Attribute, die ihre Eigenschaften definieren. Die eben angesprochene Referenzierung zu einem Check Command und damit indirekt zu einem Plugin wird z. B. an einem Service über das Attribut check_command hergestellt. Darüber hinaus sind einige Objekttypen mittels sogenannter Custom Variables erweiterbar. Sie können frei gewählt werden und können so zusätzliche Informationen enthalten, wie den Hersteller eines überwachten Geräts oder zur Durchführung der Überwachung benötigte Passwörter.

All diese Objekte stehen in Beziehung zueinander, so gehört ein Service immer zu genau einem Host, eine Notification zu einem Service oder Host. Für jedes Plugin gibt es genau ein Check-Command-Objekt, das beschreibt, mit welchen Optionen das Plugin ausgeführt werden kann. Im Host und Service wird demnach ein Check Command referenziert, das die Überwachung steuert. Bei Benachrichtigungen übernimmt dies zwischen Notification und Plugin das Notification Command mit gleichen Eigenschaften.

Abbildung 1-2: Zusammenhang zwischen Konfigurationsobjekten

Zusammen mit weiteren Sprachelementen, wie »if-else«-Conditions zur Ablaufsteuerung, Variablen und Funktionen, ist die Konfiguration eine eigene Sprache, die die Spezifikationen einer Domain Specific Language (DSL) erfüllt.

Features

Icinga 2 ist modular aufgebaut und kann durch Features im Funktionsumfang erweitert werden. So lassen sich Informationen von Icinga 2 zu anderen Systemen übertragen. Um beispielsweise einen Graphen für die zeitliche Entwicklung von Festplattenauslastungen zu visualisieren, liefert Icinga 2 Features zur Übertragung von Metriken an diverse nicht zum Icinga-Projekt gehörende Systeme. Die beliebtesten sind InfluxDB und Graphite, PNP4Nagios und openTSDB werden jedoch ebenfalls unterstützt.

Aber selbst die grundlegenden Eigenschaften sind in Features ausgelagert und können damit deaktiviert werden. Sollen keine Benachrichtigungen bearbeitet werden, wird das Feature notification abgeschaltet. Auch der Scheduler selbst ist im Feature checker implementiert.

Aktive und passive Checks

Werden Hosts und Services in regelmäßigen Abständen mit einem Check-Plugin geprüft, wird von einem aktiven Check gesprochen.

Icinga kennt jedoch auch passive Checks. Hierbei tut Icinga 2 nichts und wartet, dass ihm der Status oder Check-Result von außen mitgeteilt wird. Damit muss Icinga 2 eine Schnittstelle zur Einlieferung solcher Ergebnisse bereitstellen. Genau diese Aufgabe übernimmt das Feature api. Es stellt ein REST6-Application Programming Interface (API) bereit, das eine verschlüsselte Kommunikation von anderen Servern übers Netzwerk erlaubt.

Abbildung 1-3: Icinga 2 – aktive und passive Checks

Bei passiven Checks ist Folgendes zu bedenken: Erfolgt keine regelmäßige Lieferung von Ergebnissen, sondern z. B. nur im Fehlerfall, kann nicht gewährleistet werden, dass der Kommunikationsweg noch funktioniert oder das sendende System noch läuft.

Host- und Servicestatus

Die Überwachung teilt sich wie oben beschrieben in Host und Service auf. Beide werden mit Plugins geprüft, zumindest bei aktiven Checks. Dabei kennt jedes Plugin vier Zustände, OK, WARNING, CRITICAL und UNKNOWN, die es an Icinga 2 übermittelt. Für passive Checks gilt die Beschränkung auf diese vier Zustände verständlicherweise ebenfalls, da Icinga 2 bei der weiteren Verarbeitung keinen Unterschied mehr zwischen aktiv und passiv macht.

Der vierte und letzte Status, den ein Plugin zurückliefern darf, ist UNKNOWN. Er besagt, dass das Plugin nicht in der Lage war, den abzufragenden Zustand zu ermitteln. Das passiert, wenn das Plugin in einen Timeout läuft, weil es den Zustand in der gesetzten Zeit nicht abfragen konnte. Ein weiterer Grund könnte sein, dass Icinga 2 das Plugin beim Aufruf nicht ausführen darf, da der Icinga-Benutzer nicht die Berechtigungen besitzt.

Bei einem Service erschließt sich die Einteilung in WARNING als Vorwarnstufe und CRITICAL für höchste Gefährdung der Produktion, aber was soll dies bei einem Host bedeuten?

Nun, Icinga unterscheidet bei einem Host auch nur zwischen UP und DOWN. Der Grund ist die Überlegung, dass ein Service zu einem Host, der ausgeschaltet bzw. nicht mehr erreichbar ist, mit an absoluter Sicherheit grenzender Wahrscheinlichkeit ebenfalls nicht mehr erreichbar ist. Deshalb muss der Hostalive-Check auch entsprechend hoch angesetzte Schwellenwerte haben, um sicherzustellen, dass der Host wirklich DOWN ist. Standardmäßig liefert ein Ping dann CRITICAL, wenn er Antwortzeiten von jenseits von 5 Sekunden misst oder eine Verlustrate von 100 Prozent bei fünf gesendeten Pings aufweist. Ein Schwellenwert für WARNING ist bei Hosts unerheblich, da Icinga dies als OK auffasst und den Host für UP erklärt.

Return Code

Servicestatus

Hoststatus

0

OK

UP

1

WARNING

UP

2

CRITICAL

DOWN

3

UNKNOWN

DOWN oder UNREACHABLE wird aus Abhängigkeiten berechnet

Tabelle 1-1: Plugin-Return-Code, Service- und Hoststatus

Die Tabelle fasst den Zusammenhang zwischen dem RC des Plugins zum Host- und Servicesatus nochmals zusammen. Dort findet sich auch, dass ein UNKNOWN an einem Host einem DOWN entspricht, UNREACHABLE ist hingegen ein Status, den Icinga berechnet. Ein Host ist nicht erreichbar, wenn Icinga ein Problem auf dem Weg vom Icinga-Server zum Zielhost bekannt ist, z. B. der Ausfall eines Routers. Icinga weiß damit, dass der Host nicht erreicht werden kann, und kann deshalb auch keinen Status ermitteln und »kennzeichnet« ihn als UNREACHABLE.

1.2.3Icinga Web 2

Um die Überwachung und Benachrichtigung kümmert sich Icinga 2 im Zusammenspiel mit den Plugins. Jetzt fehlt noch eine adäquate visuelle Aufbereitung und Präsentation. Icinga Web 2 ist das Graphical User Interface (GUI) aus dem Icinga-Projekt, eine in Hypertext Preprocessor (PHP) implementierte Anwendung, die neben PHP einen Webserver zur Interaktion benötigt.

Abbildung 1-4: Icinga Web 2 mit Host- und Service-Ansicht

Als Schnittstelle von Icinga 2 zu Icinga Web 2 muss eine Datenbank eingesetzt werden. Icinga 2 schreibt seine Daten mithilfe eines Features in die Datenbank, von wo Icinga Web 2 sie ausliest und anzeigt. Diese Schnittstelle wird als Icinga Data Output (IDO) bezeichnet.

Abbildung 1-5: Icinga 2 – IDO-Anbindung

Als Datenbank werden MySQL/MariaDB oder PostgreSQL unterstützt. Im Icinga-Umfeld wird häufig von MySQL gesprochen, auch wenn MariaDB eingesetzt wird. Aus Sicht von Icinga sind die Unterschiede nicht entscheidend und so wird es auch in diesem Buch gehandhabt. Entsprechend tragen die Features die Namen ido-mysql und ido-pgsql.

Für den Rückkanal von der GUI ins Icinga 2 wird nicht die Datenbank benutzt, sondern Icinga Web 2 sendet Kommandos, wie führe jetzt unmittelbar einen Check aus, setze eine Downtime oder einen Kommentar, indem die Anwendung diese Befehle an die API von Icinga 2 schickt.

Icinga Web 2 unterstützt als moderne Benutzeroberfläche mehrere unterschiedliche, gleichzeitig angemeldete Benutzer. Durch ein auf Rollen basierendes Berechtigungskonzept können so Benutzern unterschiedliche Berechtigungen erteilt werden. Die Benutzer werden dabei standardmäßig in einer eigenen Datenbank verwaltet, können aber anstatt oder zusätzlich durch Anbindungen an ein Lightweight Directory Access Protocol (LDAP) wie z. B. ein Microsoft AD ersetzt oder ergänzt werden.

1.2.4Datenbanken

Voraussetzung für den Einsatz von Icinga Web 2 ist der IDO und damit einhergehend wird eine PostgreSQL- oder MariaDB/MySQL-Datenbank benötigt.

Je größer die zu überwachende Umgebung, desto wichtiger ist ein schnelles Plattensubsystem mit geringen Latenzen. Jeder mit einem Plugin ermittelte Wert überschreibt den letzten ermittelten, dies zieht eine Vielzahl von SQL-Updates nach sich, die IO-Last verursachen. Verkleinert man die Check-Intervalle, steigt die Last linear an. Als Plattensubsystem ist hierfür Direct Attached Storage (DAS), also lokal angebundene Festplatten, nach wie vor am besten geeignet.

Für große Installationen, ab ca. 30.000 Checks pro Minute, empfiehlt sich eine MySQL-Datenbank. Der Grund liegt im unterschiedlichen Verhalten der beiden Systeme, was Updates angeht. Für PostgreSQL sei in diesem Zusammenhang »Vaccum« erwähnt. Auch ist MySQL in der Community weiter verbreitet und man erhält auf dem Icinga-Community-Board7 wahrscheinlicher und schneller Hilfe. Dies soll jedoch niemanden abhalten, PostgreSQL als Backend zu verwenden, es sollten jedoch fachkundige Anpassungen an »AUTOVACUUM« und ggf. »fillfactor« vorgenommen werden.

Somit ist zuerst die Entscheidung zu treffen, welches Database Management System (DBMS) zum Einsatz kommen soll. Dieses lässt sich auf einem dedizierten System, aber auch auf dem Icinga-Server selbst betreiben. Bei getrennten Systemen für Icinga und das DBMS ist beim Einsatz des IDO darauf zu achten, dass das Netzwerk eine ausreichend hohe Bandbreite und geringe Latenz bietet. Ein anderer Standort ist in den seltesten Fällen geeignet.

1.3Installation

Im Rahmen dieses Buchs hat das Icinga-Installer8-Projekt zum Ziel, zum jetzigen Zeitpunkt eine vereinfachte Installation der im vorherigen Abschnitt beschriebenen Grundkomponenten anzubieten. Der Installer basiert auf Puppet9 und erfordert damit zusätzlich nur noch einen auf dem System befindlichen Puppet-Agenten. Die Installation für das Gebrauchtwarencenter wird auf dem Linux-Server fornax.gwc-jonas.local durchgeführt.

Eine ausführliche Schritt-für-Schritt-Anleitung der Installation ohne Automatisierung auf RHEL 8 und Debian 11 »Bullseye« ist in Anhang D dieses Buchs zu finden. Für andere Systeme sei auf die Onlinekokumentation10 von Icinga verwiesen.

Leider hat sich Icinga, zumindest vorrübergehend, dazu entschieden, Installationspakete für RHEL-Version-8-basierte Systeme nicht mehr frei und kostenlos zum Download anzubietena. Betroffen sind Icinga 2 ab Version 2.12.6 bzw. Version 2.13.2 und Icinga Web 2 ab Version 2.9.5.

ahttps://icinga.com/blog/2022/04/06/releasing-icinga-web-v2-10-1

Das alles heißt nun nicht, dass man sich nicht selbst Pakete bauen kann. Dazu wird einfach das Quellpaket von Fedora hergenommen und mit dessen Hilfe11 ein neues Paket gebaut.

»Fetischsammler sind ähnlich wie Pornofreaks: an ihnen zu verdienen ist eigentlich mies, aber irgendwo … bin ich ja auch einer von denen.«

Rob Gordon, 2000

1.3.1Software-Repositories

Grundsätzlich ist für die hier beschriebene Installation ein Zugang ins Internet und zu den offiziellen Software-Repositories erforderlich. Andernfalls sind neben den Distributions-Repositories noch folgende zusätzlich zu spiegeln und intern zur Verfügung zu stellen:

Icinga-Release

Erfordert für aktuelle Pakete auf Systemen, die auf

RHEL

Version 8 basieren, eine Icinga Subscription

12

.

Puppet 6 oder 7

RHEL

-basierte Systeme:

Extra Packages for Enterprise Linux (

EPEL

)

Code Ready Builder

bei RHEL bzw.

PowerTools

nur CentOS

NETWAYS-Extras

Die automatische Einbindung vom Icinga-Repository wie auch EPEL lässt sich im interaktiven Modus des Installers abschalten. Alternativ kann dies mit der Option --no-enable-install-repos beim Aufruf erledigt werden. Dann sind allerdings im Vorfeld alle Software-Repositories per Hand oder durch sonstige Automatismen dem System hinzuzufügen.

RedHatIn der Version 8 von RHEL müssen neben den Repositories für Puppet und dem Icinga-Installer zusätzlich die eigenen Optional- und Code-Ready-Builder-Repositories aktiviert werden:

$ subscription-manager repos --enable rhel-8-server-optional-rpms

$ subscription-manager repos \

--enable codeready-builder-for-rhel-8-x86_64-rpms

Bei einem CentOS-System heißt das zusätzliche Repository hingegen Power-Tools:

$ dnf config-manager --enable powertools

Sowohl für das Icinga- wie auch das NETWAYS-Extras-Repository ist keine Unterscheidung nötig:

$ dnf install https://packages.netways.de \

/extras/epel/8/noarch/netways-extras-release \

/netways-extras-release-8-1.el8.netways.noarch.rpm

$ dnf install https://yum.puppet.com \

/puppet6/puppet6-release-el-8.noarch.rpm

Die Installation des Installers wird wie folgt durchgeführt, erfordert jedoch noch jeweils eine Bestätigung des GPG-Keys der Puppet, und Netways-Repositories:

$ dnf install -y icinga-installer

DebianHingegen benötigt Debian neben den Repositories für den Puppet-Agenten und dem Icinga-Installer keine weiteren. Dafür muss hier der Import der GPG-Keys gesondert erfolgen und ein abschließendes apt-get update vor der eigentlichen Installation ausgeführt werden:

$ wget -O - https://apt.puppetlabs.com/DEB-GPG-KEY-puppet-20250406 \

| sudo apt-key add -

$ echo "deb http://apt.puppetlabs.com bullseye puppet6" \

> /etc/apt/sources.list.d/puppet6.list

$ wget -qO - \

https://packages.netways.de/netways-repo.asc |apt-key add -

$ echo "deb https://packages.netways.de/extras/debian bullseye main" \

> /etc/apt/sources.list.d/netways-extras-release.list

$ apt update

$ apt install -y icinga-installer

1.3.2Icinga-Installer

Mit dem Installer wird auf dem Server ein Icinga-Basissystem aufgesetzt. Neben Icinga 2 wird ein MySQL, Icinga Web 2 mit PHP und ein Apache-Webserver installiert und konfiguriert.

$ icinga-installer -S server-ido-mysql --enable-director false

Mit der Option -S wird das Setup-Szenario festgelegt, server-ido-mysql beschreibt, dass alles Notwendige auf einem Rechner zu installieren ist. Soll anstatt MySQL ein PostgreSQL verwendet werden, ist das Szenario serverido-pgsql zu wählen.

Die Option enable-director false unterbindet, dass das Feature Director mit installiert wird.

$ icinga-installer -S server-ido-pgsql --enable-director false

Die Installation und Konfiguration des Dirctors, als grafische Unterstützung zur Konfiguration, wird in Kapitel 11 ausfürlich beschrieben und könnte hiermit zunächst unterbleiben.

Der Aufruf mit --help offenbahrt eine Vielzahl von Optionen, die den Installer beeinflussen. Alle diese Einstellungen können ebenfalls im interakiven Modus vorgenommen werden:

$ icinga-installer -S server-ido-mysql -i

Sind Konfigurationen am Apache, des DBMS, Icinga 2, PHP oder Icinga Web 2 vorgenommen worden, darf der Installer nicht erneut ausgeführt werden, wenn die Änderungen erhalten bleiben sollen. Der Installer ist ohne tiefergreifende Kenntnisse nicht als Konfigurationstool einsetzbar. Er kann aber demzufolge dazu verwendet werden, den Ursprungszustand wiederherzustellen.

Beispielkonfiguration

Im Softwarepaket von Icinga 2 wird zwar eine Beispielüberwachung des eigenen Hosts mitgeliefert, aber der Installer bindet diese nicht ein. Die Beispiele befinden sich im Verzeichnis /etc/icinga2/conf.d und lassen sich durch eine kurze Zeile in die aktuelle Konfiguration aufnehmen:

$ echo 'include_recursive "../../conf.d"' \

> /etc/icinga2/zones.d/main/default.conf

$ systemctl reload icinga2

Icinga 2 ist für die Konfiguration in Bezug auf zu überwachende Server und Dienste zuständig und wie üblich bei Änderungen muss der zugehörige Systemdienst »neu gestartet« werden. Bei Icinga 2 genügt zum erneuten Einlesen der Konfigurationsdateien üblicherweise ein reload.

1.4Sicherheits- und Zugriffskontrolle

Zur Erhöhung der Sicherheit setzen Linux-Systeme auf klassische Paketfilter und Kernel-nahe Zugriffskontrollsysteme wie SELinux oder AppArmor. Paketfilter beschränken die IP-gestützte Kommunikation über das Netzwerk bzw. den lokalen IP-Stack. Die Zugriffskontrollsysteme erweitern die traditionelle Beschränkung von Benutzer (Owner) und Gruppenzugehörigkeit (Group) auf Unix um Rollen, Domänen und Abstufungen deren Sensibilität.

Um erste Gehversuche mit Icinga zu unternehmen, kann auf einen Paketfilter und eine Zugriffskontrolle verzichtet werden, im produktiven Einsatz sieht dies anders aus. Selbst wenn auf netzwerkseitige Sicherheit gesetzt wird, empfiehlt es sich, die Zugriffskontrolle zu verwenden. Für SELinux stellt das Icinga-Projekt über sein Repository die Pakete bereit, die alle benötigten Profile mitbringen und diese gleich aktivieren. Beide lassen sich einfach über den Paketmanager auch noch im Nachhinein installieren.

Icinga 2 ist immer dann mit restart neu zu starten, wenn sich Einstellungen bezüglich des Benutzers oder der Gruppen ändern. Wird der Benutzer, unter dem Icinga ausgeführt wird, einer anderen Gruppe hinzugefügt, muss restart verwendet werden. Gleiches gilt auch, wenn sich Kernel-seitig prozessbezogene Limits ändern. In allen anderen Fällen reicht ein reload.

RedHatInstallationen unter RedHat kommen meistens mit aktiviertem SELinux13, das den erfolgreichen Zugriff auf installierte Komponenten wie Icinga Web 2 unterbindet, aber auch die Kommunikation mit der REST-API von Icinga 2.

Der aktuelle Zustand von SELinux wird mit getenforce ermittelt, Änderungen lassen sich zur Laufzeit mit setenforce vornehmen. Ist der ermittelte Wert Disabled oder Permissive, ist SELinux abgeschaltet bzw. protokolliert nur mehr, was es im Modus Enforcing blockieren würde, und erlaubt somit alle benötigten Zugänge. Läuft Icinga 2 zu diesem Zeitpunkt bereits, muss es neu gestartet werden.

$ getenforce

Enforcing

$ setenforce Permissive

Im Gegensatz zu anderen Services muss SELinux für den Systemstart in /etc/sysconfig/selinux deaktiviert werden. Dort ist der Wert zu SELinux auf permissive zu setzen.

Über das öffentlich verfügbare Icinga-Repository werden Policies für Icinga 2 und Icinga Web 2 als Pakete zur Verfügung gestellt. Die Anwendung und Konfiguration werden in der zugehörigen Onlinedokumentation zu icinga2-selinux14 und icingaweb2-selinux15 beschrieben.

Zusätzlich blockt ein Paketfilter hereinkommende Anfragen auf TCP-Port 80. Dieser muss entsprechend konfiguriert oder aber komplett abgeschaltet werden. Letzteres zieht sicherlich sicherheitstechnische Bedenken nach sich, soll jedoch ebenfalls zum jetzigen Zeitpunkt genügen.

$ systemctl stop firewalld.service

$ systemctl disable firewalld.service

DebianAuf einem Server installiert Debian in der Basisversion im Allgemeinen keine Zugriffskontrolle oder Firewall. Ist nach der Installation Icinga Web 2 nicht unter der Adresse des Servers mit der URI /icingaweb2 erreichbar, wird die Anfrage womöglich doch durch eine eingeschaltete Firewall geblockt. Bei folgendem iptables-Aufruf sind keine Filterregeln aktiv:

$ iptables -L -n

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain FORWARD (policy ACCEPT)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Für Debian existieren eine Vielzahl von Firewall-Projekten16. Je nachdem, welches verwendet wird, ist die Konfiguration dahingehend anzupassen, dass eingehende Verbindungen auf TCP-Port 80 erlaubt sind. Alternativ kann die Firewall auch komplett deaktiviert werden.

2Erste Schritte auf der Benutzeroberfläche

Beim Design von Icinga Web 2 wurde ein problem- und kontextorientierter Ansatz verfolgt. Informationen werden hierbei in einem übersichtlichen Zusammenhang optisch ansprechend aufbereitet, zudem werden nur passende ausführbare Aktionen dazu angezeigt. Ein weiteres Hauptaugenmerk der Entwickler galt dabei einer möglichst performanten GUI, was auch in der täglichen Arbeit spürbar ist.

In diesem Kapitel befassen wir uns mit den grundlegenden Elementen von Icinga Web 2, wie das Navigieren auf der Oberfläche und welche Ansichten verfügbar sind und wo sie zu finden sind.

Abbildung 2-1: Anmeldung an Icinga Web 2

Die Login-Seite wird über die Zusammensetzung des Hostnamens des Servers und der URI /icingaweb2 erreicht. Der Icinga-Installer hat einen Admin-Account icingaadmin mit dem Passwort icinga angelegt.

2.1Dashboards

Nach erfolgter Anmeldung wird zuerst das im Installationsumfang enthaltene Standard-Dashboard Current Incidents dargestellt, das die zurzeit bestehenden Probleme der überwachten Systeme mitteilt. Es setzt sich aus drei sogenannten Dashlets zusammen: Service und Host für erkannte Probleme, nach Services und Hosts aufgeteilt, und Recently Recovered Services, das sind Services, die vor kurzer Zeit noch ein Problem gemeldet haben, sich aber in der Zwischenzeit erholt haben.

Abbildung 2-2: Das Standard-Dashboard

Die Anordnung der Dashlets, wie auch jegliche andere Anzeige, richtet sich nach gewählter Bildschirmauflösung sowie den Abmessungen des Fensters. So werden in Abbildung 2-2 zwei Dashlets untereinander dargestellt und das dritte weiter rechts in einer eigenen Spalte. Ist das Fenster breiter, kann es sogar zu einer Aufteilung in drei Spalten kommen.

Weitere vorinstallierte Dashboards werden in dem horizontal angeordneten Menü am oberen Fensterrand angezeigt.

Das zweite Dashboard Overdue listet alle Host- bzw. Servicechecks auf, deren erwartete Antworten noch immer nicht eingetroffen und damit überfällig sind. Dies erhält später eine starke Relevanz bei der Überwachung mit dem Icinga-Agenten oder in verteilten Umgebungen. Das letzte Dashboard Muted informiert über Checks, deren Benachrichtigung zurzeit deaktiviert ist.

2.2Navigation

Die Navigation in Icinga Web 2 ist sehr intuitiv gehalten. Das Hauptmenü zur Steuerung der Anzeige befindet sich am linken Bildschirmrand unterhalb des Icinga-Logos. Dieses Hauptmenü lässt sich durch Betätigen von « am unteren Fensterrand, wie in Abbildung 2-5 zu sehen, platzsparend auf Symbole reduzieren. Das Wiederaufklappen erfolgt dann mit », das bei reduziertem Menü an gleicher Stelle zu finden ist.

Abbildung 2-3: Ausklappen eines Untermenüs

Die einzelnen Punkte im Hauptmenü können jeweils eigene Untermenüs besitzen, die durch Anwahl ausgeklappt angezeigt werden oder sich durch ein »Mouseover« als Kontextmenü öffnen lassen.

Beim Wechsel durch eine Auswahl eines Haupt- oder Untermenüpunkts ändert sich nicht nur die Anzeige im Hauptbereich des Fensters, sondern auch die horizontal ausgerichtete Darstellung am oberen Bildschirmrand direkt rechts vom Logo. Die dort angezeigten Punkte bilden ein weiteres kontextbezogenes Untermenü.

Beim Punkt Dashboard werden die einzelnen Dashboards aufgeführt. Für die Statusanzeige des Monitorings in Abbildung 2-14 auf Seite 28 wechselt das Kontextmenü zu Punkten mit unterschiedlichen Statusinformationen.

Abbildung 2-4: Einen Service auswählen

Host- und Servicenamen sind in Auflistungen immer auch Links zu jeweiligen Detailinformationen. So führt das Anklicken von http im Dashlet Service Problems zur Detailansicht des Services wie in Abbildung 2-5.

Abbildung 2-5: Detailansicht des Services http

2.3Detailansicht von Host- und Servicechecks

Bei dargestellten Service-Ergebnissen können immer zwei unterschiedliche Links zu einer detaillierteren Ansicht angewählt werden, einer zum entsprechenden Service und einer zum zugehörigen Host. Wird ein Link angeklickt, teilt sich der Bildschirm. Die bisherige Anzeige, die sich auf die gesamte Fläche erstreckte, wird auf den linken Bereich reduziert bzw. verschoben und die ausgewählte Detailansicht erscheint im rechten Fensterbereich. Auch hier arbeitet Icinga Web 2 je nach Größe des Fensters mit einer, zwei oder mehr Spalten, auf denen Informationen verteilt werden.

Die Detailansicht zu einem Host oder Service gliedert sich in mehrere Abschnitte. Der erste ist immer die Ausgabe des hinter dem Host oder Service liegenden Plugins.

Abbildung 2-6: Abschnitt Plugin-Ausgabe der Detailansicht

Der zweite Abschnitt befasst sich mit der Problembehandlung. Hierzu zählen das Setzen von Kommentaren und Downtimes, aber auch die Information über Gruppenzugehörigkeiten. Die Bestätigung (Acknowledge) wird kontextbezogen nur zur Auswahl angeboten, wenn der Check auch wirklich zurzeit ein Problem meldet.

Abbildung 2-7: Abschnitt Problembehandlung der Detailansicht

Liefert das Plugin zusätzliche Metriken, die sogenannten Performance-Daten, werden die jeweils ermittelten Werte aufgelistet. Außerdem werden diese Daten, wenn möglich, auch als Tortendiagramme direkt neben den aufgelisteten Check-Ergebnissen dargestellt.

Abbildung 2-8: Abschnitt Performance-Daten der Detailansicht

Nur wenn eine Benachrichtigung konfiguriert ist, wird dies angezeigt. Zusätzliche Informationen, z. B. wer zu benachrichtigen ist, werden ebenfalls in diesem Abschnitt mitgeteilt. Sollten schon Nachrichten versendet worden sein, stehen hier auch solche Informationen.

Abbildung 2-9: Abschnitt Benachrichtigungen der Detailansicht

Bei aktiven Checks folgen Daten, die den Plugin-Aufruf betreffen: neben der Information in Check Source, auf welchem Host der Plugin-Aufruf erfolgte, auch die Information, wann der letzte Check ausgeführt wurde und der kommende Aufruf erfolgen soll. Die Check execution time gibt die Laufzeit des Plugins an und die Check latency informiert darüber, wie hoch die zeitliche Abweichung von geplanter zur tatsächlich erfolgten Ausführung war.

Abbildung 2-10: Abschnitt Check-Ausführung der Detailansicht

Alle Abschnitte bieten in ihrem Bereich auch immer gleich die Möglichkeit, passende Aktionen anzustoßen, so z. B. in Check execution das neue Einplanen, wann der Check das nächste Mal erneut ausgeführt werden soll, oder mit Check now der unmittelbare Aufruf des Plugins. Im Abschnitt Notifications kann eine erneute Benachrichtigung ausgelöst werden oder wie oben beschrieben in Problem handling das Hinzufügen von Kommentaren.

Damit zum Erreichen der einzelnen Aktionen nicht immer zu dem entsprechenden Abschnitt gescrollt werden muss, sind die am häufigsten zu benutzenden Aktionen als zusätzliche Links gleich oben noch vor der Plugin-Ausgabe untergebracht.

Zudem verfügt die Detailansicht in ihrer Spalte über ein eigenes Menü am oberen Fensterrand. Auch diese Elemente sind kontextbezogen, so kann von der Detailansicht eines Services direkt zum zugehörigen Host gewechselt werden oder auch gleich zu einer vollständigen Liste aller Services dieses Hosts.

Abbildung 2-11: Kontextmenü der Detailansicht

Mit History erhält man Daten zur zeitlichen Abfolge erfolgter Statuswechsel, gesendeter Benachrichtigungen und vom Benutzer ausgeführter Aktionen, wie z. B. das Einstellen von Kommentaren oder das Setzen von Bestätigungen von erkannten Problemen.

Abbildung 2-12: Abschnitt mit Custom Variables

Vor den abschließenden Funktionsbefehlen werden die vom verantwortlichen Admin für die Konfiguration gesetzten Variablen für diesen Service bzw. Host angezeigt. Das bewirkt bei diesem HTTP-Check, dass der Host auf seiner IP-Adresse ohne Uniform Resource Locator (URL)-Zusatz geprüft wird.

Abbildung 2-13: Abschnitt Funktionsbefehle der Detailansicht

Mit den Funktionsbefehlen können die in den Konfigurationsdateien von Icinga 2 gemachten Einstellungen zur Überwachung des Services bzw. Hosts überschrieben werden. So kann z. B. per Hand die Benachrichtigung abgeschaltet werden.

2.4Monitoring Health

Dieselben Funktionsbefehle gibt es auch global für alle Host- und Servicechecks. Zu erreichen sind sie im Hauptmenü mit Monitoring Health unterhalb von System. Dort finden sich auch Informationen zur Version von Icinga 2, seit wann der Prozess läuft und vor allem aber, ob in der IDO-Datenbank aktuelle Daten stehen. Wurde seit mehr als 60 Sekunden nichts mehr in die Datenbank geschrieben, wird die untere Balkenanzeige rot und meldet »Backend icinga is not running«. Ist dies der Fall, werden auch bald alle Hosts und Services im Dashboard Overdue auftauchen.

Abbildung 2-14: Statusanzeige des Monitorings

Im Kontextmenü Stats werden weitere statistische Daten zusammengefasst, z. B. gemittelte Werte zu Ausführungsdauern und Latenz von Checks sowie auch deren Gesamtanzahl.

2.5Aktionen auf Mehrfachauswahl

In Overview werden einfache Listenansichten zu allen Hosts, Services, Host- und Servicegruppen, Kontakten, Kontaktgruppen, Downtimes und Kommentaren angeboten.

Alle anwählbaren Objekte wie z. B. Host oder Service lassen sich zusammenfassend mithilfe der Mehrfachauswahl anwählen. Eine Abfolge von Objekten wird durch Klicken auf das erste Objekt und erneutes Klicken mit gleichzeitig gedrückter Shift-Taste auf das letzte Element angewählt.

Es ist aber darauf zu achten, dass sich die Maus auch beim zweiten Klick nicht über einem Link befindet.

Abbildung 2-15: Mehrfachauswahl

Sollen hingegen einzelne Objekte ausgewählt werden, die nicht aufeinanderfolgend angeordnet sind, muss bei jedem weiteren Element die Steuerungstaste oder je nach Plattform die Command-Taste benutzt werden.

Abbildung 2-16: Mehrfachauswahl

Die angezeigte Detailansicht fasst dann z. B. bei Host und Service jeweils die Statusansicht, Problembehandlung, Benachrichtigung, Check-Ausführung und den Abschnitt mit den Funktionsbefehlen zusammen. Alle in diesen Bereichen zur Verfügung stehenden Aktionen werden dann bei Ausführung auf alle ausgewählten Objekte angewendet.

Abbildung 2-17: Aktionen auf eine Mehrfachauswahl

2.6Benutzereinstellungen

Das Passwort oder die Sprache und Zeitzone für den gerade angemeldeten Benutzer können im Hauptmenü mit dem Punkt, der dem Benutzer entspricht, unterhalb von My Account geändert werden. Die Änderungen lassen sich persistent oder nur für den aktuellen Anmeldezeitraum speichern.

Abbildung 2-18: Benutzereinstellungen anpassen

Mit Default page size wird die Länge von Listenansichten auf den gesetzten Wert beschränkt. Möchte man ein anderes Look & Feel verwenden, kann unter Theme ein anderes ausgewählt werden.

Da in diesem Buch, Beschreibungen und Bilder ausschließlich in englischer Sprache verwendet werden, empfiehlt es sich hier die Spracheinstellungen entsprechend zu setzen.

2.7Kommentare

Ein probates Mittel zur Kommunikation mit Kollegen bzgl. Informationen zu Host oder Service ist der Kommentar.

Abbildung 2-19: Icinga Web 2 – Kommentare

Ein Kommentar lässt sich auf zwei Wegen einem Host oder Service hinzufügen. Beide sind über die jeweilige Detailansicht erreichbar. Ein Link findet sich im Abschnitt Problem handling und lautet Add comment. Der alternative Link steht unmittelbar unter der farbigen Statusanzeige und lautet Comment.

Abbildung 2-20: Einen Kommentar hinzufügen

Mit Betätigen eines dieser beiden Links gelangt man in die Maske Add Service Comment bzw. Add Host Comment. Hier muss nun zwangsweise ein Kommentar in dem zugehörigen Feld hinterlegt werden.

Nach Bestätigen mit Add comment wird der Kommentar dann ebenfalls im Bereich Problem handling mit dem eingegebenen Kommentartext angezeigt. Ein Kommentar wird nicht automatisch entfernt, dies muss per Hand durch einen Benutzer erfolgen. Bewegt man die Maus über die Kommentarinformation, die enthält, von wem und vor wie viel verstrichener Zeit der Kommentar eingestellt wurde, erscheint wie in Abbildung 2-21 dargestellt ein Kreuz rechts neben der Informationszeile. Mit Anwahl dieses Symbols kann der Kommentar wieder entfernt werden.

Abbildung 2-21: Kommentarinformation und Löschung

Über die Mehrfachauswahl von Host oder Services ist auch das gleichzeitige Setzen desselben Kommentars durchführbar.

2.8Acknowledges – Bestätigen von Problemen

Um für sich oder andere zu zeigen, dass ein Problem bereits bekannt ist, kann es mit Acknowledge gekennzeichnet werden. Üblicherweise bedeutet dies nicht nur, dass jemand das Problem gesehen hat, sondern auch, dass er sich darum kümmert. Wurde ein Alarm so bestätigt, schickt Icinga 2 keine weiteren Benachrichtigungen zu diesem speziellen Problem. Ist ein Problem bestätigt, wird dieser Check in einem blasseren Farbton dargestellt als vorher.

Eine Bestätigung wird gesetzt durch das Anwählen des Links Acknowledge im Abschnitt Problem handling der Detailansicht oder des gleichnamigen Links oberhalb von Plugin Output, siehe Abbildung 2-21.

Dabei gibt es verschiedene Einstellungen, die sich unterschiedlich auf die Unterdrückung von Benachrichtigungen auswirken. Ein Kommentar ist aber auf jeden Fall zu hinterlegen. Das kleine Icon mit dem »i« bietet beim »Mouseover« mit dem Mauszeiger Informationen zu dem jeweiligen Punkt.

Ein persistenter Kommentar bleibt als Kommentar erhalten, auch wenn die Bestätigung wieder entfernt wird. Eine Acknowledge mit einem Verfallsdatum wird beim Erreichen dieses automatisch entfernt und es werden wieder Benachrichtigungen versendet. Unter einem Sticky Acknowledgement wird verstanden, dass die Bestätigung auch dann bestehen bleibt, wenn beim Check der Problemstatus in einen anderen wechselt, der ebenfalls nicht einem OK entspricht.

Abbildung 2-22: Bestätigen eines Problems

Die letzte vorausgewählte Checkbox sorgt dafür, dass alle, die eine Benachrichtigung bekamen, nun auch darüber informiert werden, dass das Problem bestätigt wurde und jemand daran arbeitet.

Mithilfe der Mehrfachauswahl ist auch hier das gleichzeitige Bestätigen einer Vielzahl von Hosts oder Services möglich, was eine erhebliche Arbeitserleichterung bei Folge- oder abhängigen Problemen darstellt.

2.9Downtimes

Bei geplanten Wartungsarbeiten ist es natürlich nicht wünschenswert, über resultierende Ausfälle benachrichtigt zu werden, da diese vorher bekannt sind und erwartet werden.

Abbildung 2-23: Definieren einer festen Downtime

Hierfür bietet Icinga neben den in Abschnitt 4.7 ab Seite 75 behandelten Scheduled Downtimes auch die Möglichkeit, Downtimes zur Laufzeit zu setzen. Diese bleiben ebenfalls über einen Neustart von Icinga hinaus erhalten. Icinga Web 2 sendet die Informationen zu einer Downtime mittels eines API-Requests an Icinga 2.

Den Link zum Setzen einer Downtime erreicht man über die jeweilige Detailansicht zum Host oder Service. Er befindet sich entweder in der oberen Zeile direkt unter der Anzeige zum Status oder im Bereich, der als Problem handling gekennzeichnet ist.

Icinga kennt zwei Arten von Downtimes. Die erste wird als feste Downtime bezeichnet und hat fest definierte Start- und Endzeitpunkte, d. h., die Unterdrückung von Benachrichtigungen beginnt zu einer fest gewählten Zeit und endet zu einem feststehenden Zeitpunkt. Ist eine Downtime verstrichen, werden wieder Benachrichtigungen gesendet.

Abbildung 2-24: Setzen einer flexiblen Downtime

Wird hingegen mit Type eine flexible Downtime ausgewählt, beziehen sich die Werte bei Anfangs- und Endzeitpunkt auf einen Zeitraum, in dem die Downtime starten soll. Wechselt der Host oder Service in diesem angegebenen Zeitfenster in einen Problemzustand, gilt dieser Zeitpunkt als Start der Downtime. Die Downtime endet dann nach Ablauf der angegebenen Zeitspanne, z. B. nach dreißig Minuten wie in Abbildung 2-24.

Ein Kommentar muss bei beiden Varianten gesetzt sein. Der Schalter All Services in Abbildung 2-23 setzt automatisch dieselbe Downtime bei allen dem Host zugehörigen Services. Der Punkt Child Hosts erweitert die Downtime auf alle abhängigen Hosts. Beide letztgenannten Auswahlmöglichkeiten gibt es nur bei Hosts!

Abbildung 2-25: Löschen einer gesetzten Downtime

Informationen zur Downtime wie auch der dazugehörige Kommentar werden in der Detailansicht im Abschnitt Problem handling angezeigt. Entfernt werden kann eine Downtime durch Bewegen der Maus auf die Information der zu löschenden Downtime und das Klicken auf das dann rechts erscheinende Kreuz.

Wurde eine Downtime an einem Service über den Host automatisch gesetzt, wird dies nicht automatisch durch Entfernen der Downtime am Host mit gelöscht. Dann müssen die Downtimes einzeln oder über die Mehrfachauswahl entfernt werden. Mit der Mehrfachauswahl können selbstverständlich ebenfalls eine Vielzahl von Downtimes gleichzeitig angelegt oder entfernt werden.

3Grundkonfiguration von Icinga

Dieses Kapitel behandelt zuerst die Konfiguration von Icinga 2 und dann die von Icinga Web 2.

»Manöverdüsen voraus, Mr. Sulu. Bringen Sie uns raus.«

Capt. Kirk, 1979

Alle Konfigurationsdateien für Icinga 2 liegen unterhalb des Verzeichnisses /etc/icinga2. Die zentrale Konfigurationsdatei heißt icinga2.conf. Alle anderen Dateien werden (direkt oder indirekt) über die Anweisung include eingebunden.

include "constants.conf"

Im obigen Beispiel wird also die Datei constants.conf eingebunden. Nutzt man doppelte Anführungszeichen und gibt keinen absoluten Pfad an, erfolgt die Suche nach der einzubindenden Datei im gleichen Verzeichnis, hier also /etc/icinga2.

include <itl>

include <plugins>

include "features-enabled/*.conf"

Verwendet man spitze Klammern, <...>, anstelle von Anführungszeichen, wird in einem vordefinierten Pfad wie /usr/share/icinga2/include nach der entsprechenden Datei gesucht. Der genaue Pfad variiert je nach Installationspaket bzw. Plattform. Im obigen Beispiel werden einzelne Dateien der Icinga Template Library (ITL) eingebunden.

include_recursive "../../conf.d"

Eine schon bekannte Direktive ist include_recursive, bei der keine Datei, sondern ein Verzeichnis angegeben wird. Alle Dateien mit der Endung .conf in diesem Verzeichnis und allen darunterliegenden Verzeichnissen werden rekursiv eingebunden.

3.1Konstanten

Wie in icinga2.conf zu sehen, ist constants.conf die erste der Konfigurationsdateien, die gelesen wird. In ihr werden Konstanten gesetzt, die damit in den nachfolgenden Konfigurationsdateien zur weiteren Benutzung zur Verfügung stehen.

Codebeispiel 3.1:/etc/icinga2/constants.conf

3.2Features

Vieles der Funktionalität von Icinga 2 ist in sogenannte Features ausgelagert, die bei Bedarf hinzugeladen werden. Alle zur Auswahl stehenden Features können über einen CLI-Aufruf angezeigt werden. Die Ausgabe zeigt zusätzlich an, ob diese zurzeit aktiviert oder deaktiviert sind.

$ icinga2 feature list

Disabled features: command debuglog icingastatus compatlog ...

Enabled features: api checker mainlog notification

In der Datei icinga2.conf werden mittels »include« alle Dateien mit der Endung .conf im Verzeichnis /etc/icinga2/features-enabled eingebunden. Die dort liegenden Dateien enthalten die Konfiguration des jeweiligen Features mit demselben Namen.

$ ls -l /etc/icinga2/features-enabled/

insgesamt 0

lwrx... api.conf -> ../features-available/api.conf

lrwx... checker.conf -> ../features-available/checker.conf

lwrx... mainlog.conf -> ../features-available/mainlog.conf

lwrx... notification.conf -> ../features-a.../notification.conf

Ist ein Feature aktiviert, zeigt ein Link aus diesem Verzeichnis auf die entsprechende Datei in /etc/icinga2/features-available.

$ ls /etc/icinga2/features-available/

api.conf command.conf gelf.conf

ido-mysql.conf mainlog.conf statusdata.conf

compatlog.conf perfdata.conf graphite.conf

ido-pgsql.conf notification.conf ...

Aktiviert man beispielsweise das Feature api mit icinga2 feature enable api oder deaktiviert es entsprechend mit icinga2 feature disable api, muss Icinga 2 danach jeweils dazu veranlasst werden, seine Konfiguration neu einzulesen.

Hier folgen eine Auflistung und eine Kurzbeschreibung der Features und ihrer Funktion. Die Features sind jeweils eigene Objekte und werden entsprechend über Attribute konfiguriert. Standardmäßig sollte die Konfiguration über oben stehende Dateien erfolgen.

CheckerComponent

Das Feature checker regelt das Ausführen der aktiven Checks, also den Aufruf der Plugins und das Entgegennehmen der Ergebnisse, d. h. den Exit Code und den Output. Zusätzlich obliegt ihm die Verantwortung, wann was zu geschehen hat und dieses einzuplanen (Scheduling), z. B. auch das Handling von Downtimes.

Mit der Konstanten MaxConcurrentChecks wird die Anzahl gleichzeitig laufender Checks beschränkt, der Default steht auf 512.

NotificationComponent

Das An- oder Abschalten von notification aktiviert bzw. deaktiviert das Benachrichtigungssystem von Icinga 2.

FileLogger

Mit mainlog wird das Logfile in die Datei icinga2.log geschrieben. Der Standardpfad, der in LogDir hinterlegt ist, lautet per Default /var/log/icinga2. Das Logging lässt sich in den Abstufungen error, warning, notice, information und debug konfigurieren.

Codebeispiel 3.2: /etc/icinga2/feature-enabled/mainlog.conf

Über das Feature debuglog kann das Logfile debug.log für Debug-Meldungen angeschaltet werden. Es befindet sich ebenfalls im Verzeichnis /var/log/icinga2.

Die Logfiles werden nicht automatisch durch Icinga 2 rotiert, hier muss auf einen externen Mechanismus zurückgegriffen werden. Bei der Installation aus Paketen ist logrotate hierfür vorkonfiguriert.

SyslogLogger

Mit der Aktivierung von syslog werden die Logeinträge in ein syslog-Target umgeleitet. Die Verwendung von syslog anstelle von mainlog reduziert den Plattenzugriff. Das Feature syslog schreibt nicht unmittelbar auf die Platte, sondern puffert Einträge erst, um sie dann gesammelt zu schreiben, und kann auch genutzt werden, um die Logs nicht »nur« am Icinga-Host abzulegen, sondern auch an einen zentralen Loghost zu senden.

Die Abstufungen für Logeinträge lauten wie beim FileLogger und werden ebenfalls durch ein Attribut mit dem Namen severity gesetzt.

IdoMysqlConnection

Dieses Feature ist aus dem Paket icinga2-ido-mysql gesondert zu installieren. Mit ido-mysql werden die anfallenden Daten, wie aktueller Status, Statuswechsel und vieles mehr, in eine MySQL-Datenbank geschrieben. Von dort können sie dann von Icinga Web 2 oder Add-ons wie NagVis1 ausgelesen werden.

Das Datenbankschema wurde bereits durch den Icinga-Installer eingespielt. Es ist Bestandteil des Installationspakets icinga2-ido-mysql und ist in der Datei /usr/share/icinga2-ido-mysql/schema/mysql.sql hinterlegt.

Codebeispiel 3.3: /etc/icinga2/feature-enabled/ido-mysql.conf

Neben den üblichen Zugangsdaten und dem Namen der Datenbank stehen die Werte zu enable_ssl und enable_ha per Default auf »false«. Es wird empfohlen, eine Verbindung zu einer entfernt laufenden Datenbank mittels TLS (Anhang A.3.3 auf Seite 625) zu verschlüsseln. Ist die Datenbank entsprechend vorbereitet, baut Icinga 2 eine gesicherte Verbindung auf sobald enable_ssl den Wert »true« aufweist und für Icinga 2 ein Reload ausgeführt wurde.

Der Parameter enable_ha erlangt erst dann Bedeutung, falls dieser Icinga-Knoten in einem Cluster zur Hochverfügbarkeit betrieben wird. Ein Thema, das in Kapitel 24 besprochen wird.

IdoPgsqlConnection

Das Feature ido-pgsql dient zum Ablegen derselben Daten wie bei IdoMysqlConnection in eine PostgreSQL-Datenbank. Für dieses Feature ist das Paket icinga2-ido-pgsql zusätzlich zu installieren.

Auch hier gilt, das Datenbankschema wurde bereits durch den Icinga-Installer eingespielt. Es ist Bestandteil des Installationspakets und ist in der Datei /usr/share/icinga2-ido-pgsql/schema/pgsql.sql zu finden.

ApiListener

Mit api lässt sich der API Listener steuern. Dieser öffnet einen TCP-Socket, der sowohl Hypertext Transfer Protocol Secure (HTTPS) für die REST-API als auch JSON-RPC für die Clusterkommunikation versteht. Letzteres ist Voraussetzung für den Datenaustausch mit anderen Icinga-Instanzen. Andere Instanzen können dabei Satellitensysteme (Worker) oder auch Icinga-Agenten sein.

An die REST-API sendet Icinga Web 2 Kommandos, wie das Setzen einer Downtime oder das unmittelbare Anstoßen eines Checks. Der hierfür erforderliche API-User icingaweb2 ist vom Installer im Verzeichnis /etc/icinga2/zones.d/main in der Datei api-users.conf abgelegt worden:

Die Berechtigungen sind auf das Nötigste eingeschränkt.

GelfWriter

Das Feature gelf (Graylog Extended Log Format) bietet mit dem Objekt vom Typ GelfWriter eine Schnittstelle fürs Logmanagement mit Graylog2.

GraphiteWriter

Das Objekt GraphiteWriter im Feature graphite schreibt Performance-Daten als Metriken in den TCP-Socket, den der Carbon-Cache des Graphite-Projekts3 oder einer alternativen Implementierung bereitstellt.

InfluxdbWriter

Stellt im Feature influxdb eine Schnittstelle zu InfluxDB4 zur Weiterverarbeitung von Metriken und Performance-Daten bereit.

ElasticsearchWriter

Mit dem Feature elasticsearch wird eine weitere Schnittstelle zur Verfügung gestellt, die Metriken im geforderten Format für Elasticsearch5 weiterreicht.

OpenTsdbWriter