Icinga 2 E-Book

Lennart Betz

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

Seitenzahl: 724

Beschreibung

"Icinga 2" gibt eine umfassende Einfuhrung in das gleichnamige Monitoringprodukt, das als Fork einer etablierten Lösung für Verfügbarkeitsmonitoring entstanden ist, in Version 2 jedoch einen kompletten Rewrite mit vielen, meist massiven, Verbesserungen erhalten hat. Dabei zeigt es Umsteigern von anderen freien Monitoringlösungen genauso wie Monitoring-Neulingen, wie eine Umgebung aufgebaut und Schritt fur Schritt immer umfangreicher und umfassender gestaltet wird. Die Beispiele haben einen sehr starken Praxisbezug und sollen nicht nur Wege zeigen, wie übliche Probleme irgendwie gelöst werden können, sondern welcher Ansatz sich vielfach in unterschiedlichsten Setups bewährt hat. Dabei bekommt der Leser aber nicht nur ganz konkrete Losungen für immer wieder auftretende Aufgaben an die Hand, sondern erfährt auch, wie er sich selbst weiterhelfen kann, wenn eine Anforderung einmal nicht vom Buch abgedeckt ist. Gezeigt werden die Überwachung von Linux, Unix und MS Windows Hosts, Netzwerkgeraten, Virtualisierungsplattformen, Netzwerkdiensten wie Web- und Mailserver, Verzeichnisdiensten, Datenbanken etc. Für die Überwachung werden bewährte Plugins vorgestellt, darüber hinaus aber auch Losungen für Logmanagement und Perfomance-Graphing aufgezeigt. In der zweiten, umfassend erweiterten Ausgabe dieses Praxisbuchs wurde nicht nur der Inhalt komplett überarbeitet und an die seit dem Vorläufer erschienenen neuen Versionen der behandelten Programme angepasst, sondern es wurden auch neue Kapitel über den Icinga Director, die API von Icinga und Hochverfügbarkeit für Icinga-Setups hinzugefügt.

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.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Lennart Betz · Thomas Widhalm

Icinga 2

Ein praktischer Einstieg ins Monitoring

2., aktualisierte und erweiterte Auflage

Lennart Betz

[email protected]

Thomas Widhalm

[email protected]

[email protected]

Lektorat: Dr. Michael Barabas

Copy-Editing: Petra Kienle, Fürstenfeldbruck

Satz: Lennart Betz, Thomas Widhalm

Herstellung: Stefanie Weidner

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-556-8

PDF      978-3-96088-425-5

ePub    978-3-96088-426-2

mobi    978-3-96088-427-9

2. Auflage 2018

Copyright © 2018 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

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 Autor 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

This Book is the Property of the Half-Blood Prince.

Vorwort

Als wir Icinga im April 2009 zum Leben erweckten, konnten wir nur erahnen, wohin uns das Projekt führen würde. Natürlich waren wir von dem Potenzial des Projekts und der beteiligten Menschen überzeugt. Die Frage war jedoch, ob wir auch die Open-Source-Community von Icinga überzeugen können.

Das Feedback war schlichtweg überwältigend. Bereits nach den ersten Versionen erreichten uns unglaublich viel positives Feedback und viele User Stories über den erfolgreichen Einsatz von Icinga. Ausschlaggebend für den Einsatz von Icinga waren in der Praxis meist nicht das ein oder andere neue Feature, sondern das Vertrauen unserer Anwender. Vertrauen der Anwender in das Projekt, die Menschen dahinter und die Überzeugung, eine zukunftssichere Technologie einzusetzen.

Dieses Vertrauen war und ist seitdem unser Antrieb und auch die Hauptmotivation hinter Icinga 2. Zu behaupten, die Neuentwicklung von Icinga war rein altruistischi, wäre sicherlich etwas übertrieben, aber gegenüber unseren bestehenden Anwendern haben wir immer die größte Verantwortung. Icinga 2 und Icinga Web 2 sind die Folge unzähliger Entwicklungsjahre, aber auch zweier Grundfesten unserer Arbeit: das Bestreben, die Stärken von Icinga beizubehalten und gleichzeitig auch die aktuellen Bedürfnisse hinsichtlich Performance und Skalierbarkeit zu befriedigen.

Das Ergebnis dieser Arbeit wird in dem Buch, das Sie in Ihren Händen halten, vortrefflich beschrieben und erläutert. Dabei ist es weit mehr als eine Erweiterung der bestehenden Dokumentation. Es dient Ihnen als Nachschlagewerk und als roter Faden beim Einsatz von Icinga 2 in Ihrer Organisation. Bereits nach einigen Zeilen Lektüre werden Sie als Leser bemerken, dass keine Theoretiker für dieses Buch verantwortlich sind. Lennart und Thomas arbeiten seit vielen Jahren in den unterschiedlichsten Einsatzgebieten mit Icinga und wissen, worum es geht. Die Community kann sich glücklich schätzen, dass sie ihr Wissen mit diesem Buch weitergeben. Ich wünsche Ihnen damit mindestens genauso viel Freude wie mit Icinga selbst.

Bernd Erk

Icinga Co-Founder

Vorwort zur 2. Auflage

Als mich Lennart und Thomas bei der ersten Auflage dieses Buchs um ein Vorwort gebeten haben, bin ich dem natürlich sehr gerne nachgekommen. Dass ich bei der nun bereits zweiten Auflage wieder die Gelegenheit habe, freut mich ganz besonders und daher gilt mein Dank dafür den beiden Autoren. Sowohl für die Möglichkeit, aber vor allem für den hohen persönlichen Einsatz und die endlosen Abend- und Wochenendstunden für dieses Werk.

Dass der Untertitel »Ein praktischer Einstieg ins Monitoring« dem Inhalt des Buchs nicht gerecht wird, zeigt sich in der aktualisierten Ausgabe noch deutlicher als beim ersten Buch. Denn genau dieser Einstieg ist nach einem Drittel eigentlich erledigt und die Autoren gehen auf viele Spezialfälle, Anbindung externer Komponenten und erweiterte HA-Szenarien ein. Auch dem Icinga Director, der sich in den letzten Jahren quasi zum Standard für Konfiguration und Verwaltung der Monitoring-Umgebung entwickelt, wurden ebenso wie Graphing und der REST-API viel Zeit und Detailtiefe gewidmet.

Was das Buch jedoch wirklich besonders macht, ist die Tatsache, dass es sich nicht um eine erweiterte Dokumentation der Software handelt. Die Autoren haben neben dem Schreiben viel Zeit in Szenarien, Installation und praktische Ausarbeitung der Komponenten investiert. Das macht dieses Buch zu einem praktischen Nachschlagewerk für die Installation, aber auch die fortwährende Pflege und Erweiterung von Icinga 2 und seinen Komponenten.

Sollten Sie zu meiner großen Überraschung nicht bereits die erste Ausgabe dieses Buchs besitzen, wünsche ich Ihnen viel Freunde beim Erlernen und der praktischen Umsetzung des in diesem Buch erarbeiteten Wissens. Der Wiederholungstäter erhält jedoch nicht nur eine überarbeitete Version, sondern auch viele hundert Seiten, auf denen er Icinga 2 und seine Welt wieder oder neu entdecken kann. Dabei wünsche ich Ihnen ein glückliches Händchen und viel Freude!

Bernd Erk

CEO – Icinga

Einige Zeilen zum Buch selbst

Das vorliegende Buch richtet sich vorwiegend an Administratoren, die Icinga 2 einsetzen, mit dem Gedanken spielen, dies zu tun, oder in absehbarer Zeit von Icinga in der ersten Version auf die aktuelle migrieren wollen. Aber wir hoffen, mit der zweiten Auflage auch erfahrene Monitorverantwortliche zu unterstützen und mit dem ein oder anderen Wissen zu bereichern.

Struktur dieses Buchs

Dieses Buch besteht aus vier Teilen, die sich wiederum in einzelne Kapitel gliedern. Der erste Teil gibt eine kleine Einführung in das Thema Monitoring und stellt die einzelnen Software-Komponenten vor, die Icinga 2 als Gesamtheit bilden. Von der Installation über die grundsätzliche Konfiguration und einen ersten Blick auf die Benutzeroberfläche Icinga Web 2 werden alle wichtigen Begrifflichkeiten erkärt.

Im zweiten Teil geht es um zu ermittelnde Daten auf unterschiedlichen Betriebsystemen, vor allem Linux und Windows. Es befasst sich überwiegend damit, wie diese Daten lokal auf dem zu überwachenden System ermittelt werden und dem Transport zum Icinga-Server. Dies sind grundlegende Werte wie die CPU-, Hauptspeicher- oder Festplattenauslastung. Hier unterstützt Icinga 2 unterschiedliche Transportverfahren wie den mit Icinga 2 eingeführten Icinga-Agenten, aber auch alte Methoden wie NRPE, SSH oder SNMP.

Der dritte Teil vertieft Wissen, z. B. was Icinga 2 betrifft, erweitert dies aber auch durch die Themenkomplexe Benachrichtigungen, Verteilte Überwachung und Hochverfügbarkeit. Einen großen Abschnitt nehmen Beispiele aus der Praxis ein. Dort wird an Beispielen erläutert, wie Dienste bzw. Services mittels unterschiedlicher Plugins überwacht werden können.

Integration ist das Thema des vierten Teils. Es werden einige Erweiterungen vorgestellt, sowie andere Software, die mit Icinga 2 zusammenarbeitet. Auch die REST-API von Icinga 2 als Schnittstelle zum Datenaustausch mit beliebigen anderen Komponenten wird eingehend vorgestellt. Das Kapitel stellt einige Projekte aus dem Bereich Graphing vor, die Icinga 2 mit Daten beliefern kann, und erklärt, wie diese wiederum in Icinga Web 2 visualisiert werden. In Logmanagement geht es um die Alarmierung bei Anomalien, die in Logfiles erscheinen und ausgewertet werden müssen. Der Director als grafisches Konfigurationswerkzeug wird ebenfalls in diesem Teil behandelt, da er in der Lage ist, Daten aus unterschiedlichen Datenquellen zu beziehen, um daraus eine Überwachungskonfiguration zu erzeugen.

Den Abschluss bildet der Anhang mit Tipps zum Troubleshooting, durchzuführenden Updates und wichtigen anzustellenden Überlegungen. Zusätzlich befinden sich hier viele Codebeispiele, die die vorangegangenen Kapitel unterstützen.

Neues in der zweiten Auflage

Alle Kapitel wurden überarbeitet und größenteils komplett neu geschrieben. Dies hatte massive Umstrukturierungsmaßnahmen zur Folge. So befindet sich der Themenkomplex rund um Icinga Web 2 nicht mehr in einem Kapitel, sondern er verteilt sich auf deren drei in unterschiedlichen Teilen dieses Buchs. Umfangreiche Erweiterungen erfuhren z. B. Icinga Web 2 und Graphing. Neu hinzugekommen sind die Themen Director, Hochverfügbarkeit und die REST-API. All diesem ist der Umstand geschuldet, dass die zweite Auflage den doppelten Umfang im Vergleich zum Vorgänger hat.

In diesem Buch behandelte Versionen

Dieses Buch behandelt hauptsächlich Icinga 2 in der Version 2.8 und Icinga Web 2 2.5. Alle Beispiele zu Installationen beziehen sich, wenn nicht anders angegeben, auf die Distributionen RHEL/CentOS 7 bzw. Debian 9. 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 Attribute oder Custom-Attribute.

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 »\«.

Danksagungen

Thomas Widhalm

Ich möchte die Chance nutzen und folgenden Leuten danken: Dr. Michael Barabas, Stefanie Weidner und Miriam Metsch vom dpunkt.verlag für die Unterstützung beim Schaffen dieses Buchs. Sie ließen uns alle Freiheiten und waren doch da, wenn wir Hilfe brauchten. Das ging sogar so weit, dass sie oft vermittelnd eingriffen, wenn weitere Leute benötigt wurden, um das Projekt voranzutreiben. Daher kennen wir teilweise die guten Geister nicht namentlich, denen wir es verdanken, dass dieses Buch nun gedruckt vor uns liegt. Das betrifft insbesondere einige der Reviewer und Lektoren, denen ich gerne ganz besonders danken möchte. Es war sicher nicht immer leicht, dieselben missachteten Rechtschreibregeln immer und immer wieder ausbessern zu müssen. Vielen Dank für das Feedback und die Geduld.

Im Weiteren möchte ich mich bei der Firma NETWAYS GmbH bedanken, die es uns nicht nur ermöglicht, uns täglich mit Projekten rund um Icinga 2 und die anderen in diesem Buch erwähnten Tools zu beschäftigen, sondern uns auch sehr aktiv beim Schaffen dieses Buchs unterstützt hat, sei es durch Zeit zum Schreiben oder Hardware für Teststellungen. Aber die NETWAYS hat auch indirekt ihren Teil zum Buch beigetragen: Ohne einen Arbeitgeber und Kollegen, bei denen man sich derartig wohlfühlt, hätte zumindest ich nicht die Muße, noch Freizeit in ein Projekt dieser Größenordnung zu stecken. NETWAYS – just awesome.

Auch das Icinga-Team hat natürlich seinen Anteil an der Entstehung dieses Buchs. Ohne seine Arbeit gäbe es nichts, worüber wir schreiben könnten. Aber einige der Teammitglieder haben uns auch direkter unterstützt: mit Reviews und dem Beantworten einiger Fragen, die sich im Laufe des Schreibens ergeben haben. Ihren Teil beigetragen haben alle, aber namentlich nennen möchte ich vor allem Bernd, Michi, Gunnar, Eric und Tom, die besonders unter uns zu leiden hatten.

Bedanken möchte ich mich ebenfalls bei einigen meiner Kunden, mit denen ich mich ausgiebig über das Buch unterhalten habe und in deren Umgebung der eine oder andere Codeschnipsel seinen Ursprung hat. Ihr wisst hoffentlich, dass ich euch meine.

Nicht vergessen möchte ich meine Eltern. Sie haben immerhin viel dazu beigetragen, dass ich zu dem geworden bin, der ich heute bin. Ohne ihre Unterstützung hätte ich mich nicht dahin entwickeln können, wo ich jetzt stehe. Vielen Dank dafür, dass ihr mir geholfen habt, wo ich es brauchte, ohne mich daran zu hindern, meinen Weg zu gehen.

Ebenso danke ich meinen Freunden aus früherer und heutiger Zeit. Auch sie haben ihren Anteil daran, dass ich jetzt in der Lage bin, zu tun, was ich tue. Dankbar bin ich vielen, aber namentlich erwähnen möchte ich den Hias, Asi und Babsi, die mir gezeigt haben, wie schön es ist, enge Freunde zu haben. Andi danke ich dafür, dass er mir in einer sehr dunklen Zeit beigestanden hat und immer noch mein Freund ist. Max dafür, dass er so vieles nachvollziehen konnte. Und Benny »sleepless« dafür, dass er mir bewiesen hat, dass enge Freundschaften auch über das Internet möglich sind. Joe dafür, dass er ein lebendes Beispiel dafür ist, dass man verwandt und befreundet zugleich sein kann. Pazi dafür, dass sie einem immer das Gefühl gibt, willkommen und geschätzt zu sein, egal, wie lang man sich mal wieder nicht gesehen hat. Dem Plainer dafür, dass er die ritterlichste Person ist, die ich kenne. Daniel dafür, dass er mir gezeigt hat, dass man Gleichgesinnte in den unterschiedlichsten Menschen finden kann. Meinen Schwiegereltern dafür, dass sie mich so offen aufgenommen haben.

Danken möchte ich den »Drei ???« für endlose Stunden voller Hörspiele während Zugfahrten und beim Einschlafen, George Lucas für »Star Wars« und Extrema Ratio für die besten Messer der Welt.

Natürlich möchte ich auch Lennart dafür danken, dass wir gemeinsam dieses Projekt gestemmt haben. Es war sicher nicht immer leicht mit mir und ohne ihn wäre das Buch wohl nie Realität geworden. Danke dafür und beileibe nicht nur dafür! Unter anderem auch für viele erheiternde und erhellende Gespräche, gemeinsame Videoabende und Diskussionen über den Unterschied zwischen Deutsch und Österreichisch. Dafür, dass du Kollege und Freund bist.

Auch unserer Hündin Afra möchte ich danken. Sie hilft mir immer wieder, den Kopf bei einem Spaziergang freizubekommen oder mich aufzuheitern, wenn mich mal wieder was »anzipft«.

Zu guter Letzt möchte ich mich bei meiner Frau Ina bedanken. Für mehr, als ich hier aufzählen kann, aber vor allem auch dafür, dass sie meinen Job als Consultant akzeptiert und dabei so oft auf mich verzichtet. Dass sie immer da ist, wenn ich Unterstützung und ein offenes Ohr brauche, und nie gemurrt hat, wenn es wieder mal »ums Buch« ging. Aber auch für die vielen wunderbaren gemeinsamen Jahre, weshalb auch sie maßgeblich daran beteiligt ist, dass ich so ein Projekt überhaupt angehen konnte. Vielen, vielen Dank!

Danke euch allen, dass ihr euch meine endlosen »Ich schreib jetzt mein eigenes Buch!«- und »Ja, es ist eh bald fertig«-Vorträge angehört und ertragen habt. Und danke auch einigen von euch für die Kommentare, Meinungen und Reviews, die alle dieses Buch besser gemacht haben, als es ohne euch geworden wäre.

Für die zweite Auflage möchte ich noch mal all jenen danken, die unser erstes »Baby« so aufmerksam gelesen und uns unheimlich wertvolles Feedback gegeben haben. Ich hoffe, wir haben alles erwischt und berücksichtigt. Es ist immer wieder schön, mit Lesern zu reden und zu sehen, wenn es tatsächlich jemandem genützt hat.

Vielen Dank für alles.

Thomas Widhalm

Lennart Betz

Da hat mir der Thomas nicht viel übrig gelassen. Ich möchte all denen in meiner Familie und meinem Freundeskreis danken, die unter diesem Projekt gelitten haben.

Ein besonderen Dank an Bernd, Michael und Bodo. An Bernd, der das Vorwort auch zur zweiten Auflage verfasste, Michael Friedrich, der das Kapitel über Dashing beisteuerte, und Bodo Schulz, der sich mit einem Abschnitt über die von ihm geschriebene Ruby-Bibliothek beteiligte.

Servus

Lennart

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.1Es war einmal…

1.2Software-Komponenten

1.3Grundlagen

2Installation

2.1Repositories

2.2Sicherheits- und Zugriffskontrolle

2.3Icinga 2 und Plugins

2.4Icinga Data Output

2.5API einrichten

2.6Icinga Web 2

3Erste Schritte auf der Benutzeroberfläche

3.1Dashboards

3.2Navigation

3.3Detailansicht von Host- und Service-Checks

3.4Monitoring Health

3.5Aktionen auf Mehrfachauswahlen

3.6Benutzereinstellungen

4Grundkonfiguration von Icinga 2

4.1Konstanten

4.2Icinga Template Library

4.3Features

5Überwachen mit Icinga 2

5.1Kleine Sprachreferenz

5.2Check Commands

5.3Host und Hostgroups

5.4Service und Servicegroups

5.5Makros und deren Substitution

5.6Timeperiods

5.7Scheduled Downtimes

5.8Debugging der Konfiguration

5.9Funktionen

6Informationsabfrage mit SNMP

6.1Internet Standard Management Framework

6.2Die Management Information Base

6.3SNMP-Versionen

6.4Tools zur SNMP-Abfrage

IIBetriebssystemüberwachung

7Der Icinga-Agent

7.1Konfiguration des Masters

7.2Zertifikate beglaubigen

7.3Konfiguration des Icinga-Agenten auf Linux

7.4Konfiguration des Icinga-Agenten auf Windows

7.5Anbindung von Agenten an den Master

7.6Überwachen von Linux mittels Icinga-Agent

7.7Überwachen von Windows mittels Icinga-Agent

7.8Automatisierung der Installation

8Überwachung mittels Secure Shell

8.1Schlüsselpaar und Client-Konfiguration

8.2Unix-Überwachen mittels SSH am Beispiel von Solaris

9Überwachung mit NRPE

9.1Linux-Überwachung per NRPE

9.2Windows-Überwachung per NRPE

10SNMP

10.1NET-SNMP-Agent auf Unix-Systemen

10.2Plugins für SNMP-Abfragen

IIIFortgeschrittene Überwachung

11Icinga Web 2 einsetzen und anpassen

11.1Filter

11.2Dashboards

11.3Kommentare

11.4Acknowledgements – Bestätigen von Problemen

11.5Downtimes

12Benachrichtigungen

12.1Das Benachrichtigungssystem

12.2Flapping-Erkennung

12.3Abhängigkeiten

12.4Eskalationen

12.5Events

12.6Benachrichtigung über Telegram

13Verteilte Überwachung

13.1Zonen und Endpunkte

13.2Installation und Konfiguration eines Satelliten

13.3Konfiguration auf Zonen aufteilen

13.4Zertifikatsbeglaubigung in Verteilten Umgebungen

13.5Dezentrale Benachrichtigung

14Beispielumgebung aus der Praxis

14.1Analyse der Ausgangslage

14.2Planung der Monitorumgebung

14.3Implementation der Grundüberwachung

15Applikationen und Dienste überwachen

15.1Netzwerkdienste

15.2Datenbanken

15.3Application Server

15.4SAP

15.5Microsoft-Infrastrukturdienste

15.6Elastic Stack

15.7VMware vSphere

15.8Hardware

15.9Datensicherung

15.10Puppet

15.11Plugins entwickeln und veröffentlichen

15.12Bewerten von Plugins

16Hochverfügbarkeit

16.1Icinga 2 hochverfügbar

16.2IDO hochverfügbar

16.3Icinga Web 2 hochverfügbar

16.4Director hochverfügbar

16.5Grapher hochverfügbar

16.6Split Brain

16.7Externe Komponenten

IVIntegration

17Erweiterung der Funktionalität von Icinga Web 2

17.1Ressourcen

17.2Berechtigungen

17.3Icinga Web 2 auf der Kommandozeile

17.4Module

18Businessprozesse

18.1Einen ersten Businessprozess anlegen

18.2Benachrichtigungen einrichten

18.3Bearbeiten von Prozessen

18.4Simulation von Ausfällen

18.5Ein komplexes Beispiel

19Director

19.1Installation

19.2Deployment der Konfiguration

19.3Hosts und Host-Templates

19.4Services und deren Templates

19.5Servicesets

19.6Datenfelder und Listen

19.7Commands

19.8Kombination mit Konfigurationsdateien mittels Fileshipper

19.9Automatisierung und Synchronisation

19.10Benachrichtigungen

19.11Integration der Agenten-Installation mit Powershell

19.12Monitoring des Director

20Graphing

20.1Datenbanken für Zeitreihen

20.2PNP4Nagios

20.3Graphite

20.4InfluxDB

20.5Grafana

20.6Wachsende Zähler

21Icinga 2 REST-API

21.1ApiUser

21.2curl

21.3Einfache Abfragen

21.4Komplexe Abfragen

21.5Actions

21.6Verwalten von Objekten

21.7Abonnieren von Event Streams

21.8Browser-Output

21.9Ruby-Bibliothek

21.10Dashboards für Gesamtübersichten mit Dashing

22Logmanagement

22.1Elastic Stack

22.2Icinga 2 Logs

Anhang

ATroubleshooting

A.1Do it yourself

A.2Professionelle Hilfe

A.3Vorbereitung ist alles

A.4Ein Treffen mit Freunden

BErgänzungen zur Konfiguration

B.1Check Commands

B.2Templates für Exchange

CGoldene Bulle

C.1Benachrichtigungen

C.2Autarkes Monitoring

C.3Überwachung der Monitoring-Infrastruktur

C.4Aussagekraft der Überwachung

C.5Passive Checks nur in Kombination mit aktiven Checks

C.6Hinterfragen von bestehenden Systemen

C.7Vererbung

DDas, was du zurücklässt

D.1Updates

EAbkürzungsverzeichnis

Index

Teil I

Einführung

1Einleitung

Mit dem Begriff »Monitoring« werden Systeme bezeichnet, die den Zustand von Geräten und Programmen überwachen und beim Abweichen vom gewünschten Zustand Alarmmeldungen verschicken.1

Ohne Monitoring können die Betreuer von IT-Systemen nur dann reagieren, wenn ein Anwender eine Störung meldet oder sie selbst durch sehr zeitaufwendige manuelle Kontrolle oder per Zufall ein Problem feststellen. Beim heute üblichen Zahlenverhältnis zwischen Systemen und Betreuern ist eine manuelle Kontrolle nicht mehr zu realisieren und wenn ein Anwender ein Problem feststellt, ist es eigentlich schon zu spät, da genau diese Probleme ja verhindert werden sollen.

Um diese Problematik zu lösen, werden Monitoring-Systeme benötigt, die versuchen, Schwierigkeiten frühzeitig zu bemerken, damit sie behoben werden können, bevor sie größeren Schaden anrichten können oder bevor Benutzer davon betroffen sind. Dafür gibt es verschiedene Ansätze:

Ermitteln von Ergebnissen einer eigenen Statusprüfung und Logs von Anwendungen oder Hardware.

Ende-zu-Ende-Checks wie das Versenden einer E-Mail und Prüfen, ob sie auch ankommt.

Simulieren einer Nutzung eines Dienstes wie das Aufrufen einer Website.

Prüfen von Eckdaten eines Systems wie das Abfragen der Festplattenauslastung mit Bordmitteln.

Icinga 2 bietet dabei die Möglichkeit, alle oben genannten Verfahren abzudecken, spezialisiert sich jedoch auf die letzten beiden Ansätze. Diese Flexibilität rührt daher, dass Icinga 2 selbst keine Funktionalität zur direkten Überwachung enthält, aber sehr gut darin ist, »Plugins«, also ausführbare Dateien, die ein paar Anforderungen erfüllen, laufen zu lassen und die Ausgabe zu interpretieren. Falls sich also eine Überwachungsmöglichkeit in einer ausführbaren Datei realisieren lässt, kann sie auch in Icinga integriert werden.

1.1Es war einmal…

Icinga 2 ist ein sehr modernes Monitoring-System, das keinen Code von seinen geistigen Vorgängern enthält, aber fast alle bewährten Konzepte weiterverwendet. Diese Ähnlichkeit erleichtert vor allem Umsteigern die Arbeit mit Icinga 2 deutlich. Die folgenden Zeilen sollen einen kurzen Überblick über die bisherige Entwicklung geben.

1.1.1Icinga

Im April 2009 wurde das Icinga-Projekt gegründet, das einen Fork des Nagios-Monitoring-Systems entwickeln sollte, da viele Community-Mitglieder unglücklich über den Umgang mit eingereichten Patches und den Umgang von Nagios Enterprises mit der Nagios-Community waren. Bei einem Fork wird der aktuelle Stand des Quellcodes eines Programms von verschiedenen Entwicklerteams in unterschiedliche Richtungen weiterentwickelt. Häufig wird dabei das bisherige Team aufgespalten und je ein Teil entwickelt vom gleichen Ausgangspunkt aus in verschiedene Richtungen weiter. Üblicherweise behält dabei ein Team den Namen des Produkts bei und das andere sucht sich einen neuen. Beim Icinga-Team fiel die Wahl auf »Icinga«, das Zulu-Wort für »Ausschau halten«.

Der Fork, und damit auch die weiteren Schritte wie die Evolution von Icinga zu Icinga 2, war insbesondere auch möglich, da einige Firmen bereit waren, Entwicklern Zeit zu sponsern, um die Entwicklung von Icinga voranzutreiben. Dies geschah meist aus Eigeninteresse, da sie Monitoring auf Nagios-Basis bei sich oder ihren Kunden erfolgreich einsetzten und eine Lösung für die schleppende Entwicklung suchten. Der Fork war nötig, da zuvor zwar entwickelt wurde, die daraus resultierenden Patches jedoch nicht in Nagios einflossen. Das Icinga-Team bemüht sich, schneller auf Input aus der Community zu reagieren, und hat auch genug »Stammmitglieder«, um die Entwicklung voranzutreiben. Eine dieser Firmen ist die NETWAYS GmbH2 aus Nürnberg in Deutschland, die einige der Icinga-Kernentwickler angestellt hat, die entweder im Kundenauftrag oder als Dienst an der Community weiter an Icinga, Icinga 2 und anderen Tools aus diesem Ökosystem arbeiten. Auch die Autoren dieses Buchs haben von der NETWAYS GmbH Zeit gesponsert bekommen, um dieses Projekt zu verwirklichen.

1.1.2Icinga 2

Um einige sehr tief im Code verwurzelte Einschränkungen aufzulösen, hat sich das Icinga-Team entschlossen, mit dem Code bei null zu beginnen und alles komplett neu zu schreiben. Das Resultat ist das Release von Icinga 2 Version 2.0 vom 16. Juni 2014. Darin wurden die bekannten Konzepte in der Bedienung weitergeführt, aber auch einige sehr wichtige Neuerungen eingeführt.

Diese Neuerungen umfassen unter anderem:

eine Domain Specific Language (

DSL

) zur Konfigurationi,

den integrierten Cluster-Stack, zur Kommunikation von verschiedenen Icinga-Instanzen untereinander,

das Verteilen von Teilen der Konfiguration an beliebig viele andere Icinga 2 Instanzen,

besseres Ausnutzen der verfügbaren Ressourcen durch Multithreading,

der Einsatz als Agent,

die API, mit der u. a. zu überwachende Objekte zur Laufzeit hinzugefügt werden können.

Die neue regelbasierte Sprache erlaubt eine deutlich flexiblere Konfiguration. Viele Objekte, die früher einzeln definiert werden mussten, können nun automatisch durch Auswerten von Regeln und Funktionen angegeben werden. Das spart nicht nur sehr viel Tipparbeit, sondern schützt auch vor Fehlern, da einmal definierte Regeln natürlich auch für neue Objekte gelten.

Um Demilitarized Zones (DMZs) oder entfernte Netzwerke zu überwachen, wurden auch bei den Vorgängern von Icinga 2 schon mehrere Instanzen verwendet, die miteinander kommunizieren. Allerdings enthielten diese keinen nativen Weg, mehrere Instanzen miteinander zu verbinden, weshalb verschiedenste Lösungen dafür entwickelt wurden. Diese waren jedoch teilweise kompliziert zu konfigurieren und oft auch nicht performant genug, um die Zeit zwischen Auftreten einer Störung und der Alarmierung ausreichend kurz zu halten. Dieses Verbinden von Instanzen wurde auch genutzt, um die auftretende Last zwischen mehreren Hosts zu verteilen und in Verbindung mit Clustertools wie corosync3 und pacemaker4 Hochverfügbarkeit zu erreichen.

Durch die neue Clusterfunktionalität können nicht nur lastverteilte und hochverfügbare Cluster mit Icinga 2 Bordmitteln erreicht werden, auch untergeordnete Icinga 2 Instanzen in anderen Netzsegmenten können Ergebnisse von Checks, die sie ausführen, an zentrale Instanzen weiterschicken. Diese zeigen einen Gesamtüberblick an und alarmieren.

Über die Clusterverbindung kann auch von zentralen Systemen aus eine Konfiguration an untergeordnete Instanzen ausgebracht werden.

Die Vorgänger von Icinga 2 liefen als ein einziger Thread und konnten so auch nur einen CPU-Kern ausnutzen. Zwar waren die gestarteten Plugins immer schon eigene Threads, dennoch wurde dadurch einer Installation eine Obergrenze an zu überwachenden Systemen gesetzt. Icinga 2 ist nun multithreaded und kann die zur Verfügung stehenden Ressourcen tatsächlich ausnutzen.

Durch den geringen Ressourcenverbrauch des Icinga 2 Kerns, die Clusterverbindung und die Konfigurationsverteilung hat sich eine neue Anwendungsmöglichkeit als Agent ergeben. Dabei wird eine Icinga 2 Instanz auf einem zu überwachenden Host installiert, die nur eben diesen überwacht. Die Ergebnisse leitet sie über die Clusterverbindung an eine zentrale Instanz weiter, die die Checks aller angeschlossenen Icinga 2 Instanzen sammelt und eine Übersicht zur Verfügung stellt. Konfiguriert wird sie von der zentralen Instanz aus. Für einen Vergleich aus Anwendersicht bietet die Icinga 2 Onlinedokumentation5 einen umfassenden Überblick an.

1.1.3Namen und Versionen

Aktuell wird nur noch die Version 2.x weiterentwickelt. Dieses Buch behandelt ausschließlich den 2.x-Zweig der Entwicklung. Mit dem Versionssprung von 1.x auf 2.x geht aber auch eine Umbenennung einher, daher heißt das Tool nun tatsächlich »Icinga 2 Version 2.x«.

Gleiches gilt für das moderne Webinterface Icinga Web 2. Es ist übrigens zu beiden existierenden Icinga-Varianten kompatibel, weshalb man durchaus Icinga 2 2.8.1 wie auch Icinga 1.13.3 mit Icinga Web 2 2.5.1 betreiben kann.

Die hier genannten Versionen waren zum Zeitpunkt, als die zweite Auflage dieses Buchs entstand, die jeweils aktuellsten.

1.2Software-Komponenten

Ein Monitoring-System auf Basis von Icinga 2 besteht aus mehreren Teilkomponenten, so bildet der Core »Icinga 2« das Grundgerüst. Er regelt alle Abläufe, unter anderem z. B., wann was wie zu überwachen ist.

Die eigentliche Arbeit der Überwachung wird dann durch sogenannte Plugins erledigt, die vom Core aufgerufen werden und deren Ergebnisse dann verarbeitet werden. Plugins werden gesondert angeboten und nicht vom Icinga-Team betreut.

Die Komponente Icinga Web 2 ist ein in Hypertext Preprocessor (PHP) geschriebenes Framework zur Darstellung der ermittelten Ergebnisse der Überwachung mit Icinga 2. Als Schnittstelle zwischen Core und dem in einem Webserver laufenden Icinga Web 2 muss eine Datenbank verwendet werden. Unterstützt werden ausschließlich MariaDB respektive MySQL oder PostgreSQL. Das Beschicken dieser Datenbank ist über ein explizit einzuschaltendes Core-Feature zu aktivieren.

Icinga 2

Plugins, z. B. die Monitoring-Plugins

6

MariaDB-, MySQL- oder PostgreSQL-Datenbank

Icinga Web 2

Webserver mit

PHP

, standardmäßig Apache

Alle Komponenten werden in eigenen Projekten gepflegt und weiterentwickelt, somit wird auch jede unter einer eigenen Versionierung geführt. Darüber hinaus existieren viele weitere Komponenten, die über das bis hierher Erwähnte hinausgehen. So existiert mit dem Director eine Integration in Icinga Web 2 zur grafisch unterstützten Konfiguration oder diverse Projekte, die zeitliche Verläufe von Daten aus anderen Projekten wie Graphite oder InfluxDB einbinden.

1.3Grundlagen

Icinga 2 ist wie auch sein Vorgänger auf Verfügbarkeitsüberwachung ausgelegt. Hierbei wird primär mit aktiven Checks gearbeitet. Als ein Check wird der Test eines Hosts oder Services bezeichnet. Jedes Gerät mit einer IP-Adresse wird als Host-Objekt betrachtet. Ein Service ist immer einem Host zugeordnet, ist also z. B. ein auf einem Host laufender Dienst oder eine zu überwachende Hardwarekomponente. Die Logik, wie Tests zu erfolgen haben, ist in sogenannten Plugins implementiert. Plugins sind externe Programme, die für jeden aktiven Check aufgerufen werden und über ihren Returncode den ermittelten Status zurückgeben.

Plugins können somit auch durch den Benutzer zu Testzwecken aufgerufen werden. Zu beachten ist, dass dies durch den Benutzer erfolgen sollte, unter dem der Icinga 2 Prozess ausgeführt wird. Auf RedHat-Systemen ist das icinga, auf Debian hingegen historisch bedingt der Benutzer nagios.

$ sudo -u icinga /usr/lib64/nagios/plugins/check_procs

PROCS OK: 100 processes | procs=100;;;0;

So ermittelt z.B. das Plugin check_procs durch einen Aufruf ohne Parameter die momentan auf dem System lauffähigen Prozesse. Die Ausgabe informiert über den ermittelten Status und die Anzahl der Prozesse. Der Text nach dem senkrechten Strich (Pipe) enthält Metriken, die das Plugin ermittelt hat, die sogenannten Performance-Daten. Eine genaue Erläuterung erfolgt in Kapitel 20 ab Seite 470.

Plugins sollten auch immer eine Hilfsfunktion bieten, damit ein Anwender dessen Funktionsumfang kennenlernen kann.

$ cd /usr/lib64/nagios/plugins

$ sudo -u icinga ./check_procs --help

check_procs v2.1.4 (nagios-plugins 2.1.4)

Copyright (c) 1999 Ethan Galstad <[email protected]>

Copyright (c) 2000-2014 Nagios Plugin Development Team

<[email protected]>

Checks all processes and generates WARNING or CRITICAL

states if the specified metric is outside the required

threshold ranges. The metric defaults to number of

processes. Search filters can be applied to limit the

processes to check.

Usage:

check_procs -w <range> -c <range> [-m metric] [-s state]

[-p ppid] [-u user] [-r rss] [-z vsz] [-P %cpu]

[-a argument-array] [-C command] [-k] [-t timeout] [-v]

Options:

-h, --help

Print detailed help screen

-V, --version

Print version information

--extra-opts=[section][@file]

Read options from an ini file. See

https://www.nagios-plugins.org/doc/extra-opts.html

for usage and examples.

-w, --warning=RANGE

Generate warning state if metric is outside this range

-c, --critical=RANGE

Generate critical state if metric is outside this range

[...]

Plugins müssen vier Zustände zurückliefern können, OK, WARNING, CRITICAL und UNKNOWN. Diese werden als Returncode vom Plugin zurück gegeben. Kann ein Zustand nicht ermittelt werden, weil z. B. das Plugin nicht ausführbar ist oder eine gewisse Laufzeit überschreitet und damit in einen Timeout läuft, ist der Rückgabewert UNKNOWN. Wann die anderen drei Zustände eintreten, kann bei nahezu allen Plugins durch die Angabe von Schwellwerten7 beeinflusst werden.

Returncode

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-Returncodes, Service- und Hoststatus

Diese Schwellwerte beziehen sich immer auf die ermittelten Metriken, bei check_procs ist das z. B. die Anzahl der lauffähigen Prozesse. So liefert das folgende Beispiel ein WARNING, da der entsprechende Schwellwert auf 90 gesetzt wurde und der Schwellwert für ein CRITICAL erst bei 120 liegt. Liefen also 120 Prozesse oder mehr, meldete das Plugin den Status CRITICAL.

$ sudo -u icinga ./check_procs -w 90 -c 120

PROCS WARNING: 100 processes | procs=100;90;120;0;

Der Returncode des letzten gelaufenen Prozesses kann mit echo ausgegeben werden:

$ sudo -u icinga ./check_procs -w 80 -c 90

PROCS CRITICAL: 100 processes | procs=100;80;90;0;

$ echo $?

2

Ein Host kann drei unterschiedliche Zustände annehmen, ein Service hingegen vier. Das Plugin erkennt jedoch nicht, ob ein Host oder ein Service zu überwachen ist. Es liefert immer Zustände zwischen 0 und 3 zurück, also vier wie für Services. Handelt es sich aber um einen Host, interpretiert Icinga 2 die Werte entsprechend. Die Werte OK und WARNING bedeuten, dass sich der Host im Status UP befindet. Die Unterscheidung zwischen DOWN und UNREACHABLE muss berechnet werden und setzt voraus, dass zwischen Hosts Abhängigkeiten definiert sind. Wie dies zu realisieren ist, wird in Abschnitt 12.3 ab Seite 184 erläutert.

Ruft Icinga 2 ein Plugin auf, wird von aktiven Checks gesprochen. Dies geschieht regelmäßig in einem anzugebenden Intervall und ist von Icinga 2 fortwährend zeitlich einzuplanen. Definiert man in der Konfiguration den zu überwachenden Host oder Service als passiv, wartet Icinga 2 auf Informationen über den Status, der von einer externen Quelle geliefert werden muss. Mehr Informationen zu passiven Checks finden sich unter Kapitel 21.5 ab Seite 549.

Abbildung 1-1: Aktive und passive Checks

Eine weitere wichtige Aufgabe des Monitorings ist die Benachrichtigung über erkannte Probleme. Hierbei ist es womöglich wünschenswert, über unterschiedliche Probleme verschiedene Personenkreise zu informieren. Diese Benachrichtigungen können je nach Grad der Wichtigkeit auf unterschiedlichen Wegen erfolgen; üblich sind Mails, Instant Messenger, SMS oder Voicecalls. Mehr Informationen zu Benachrichtigungen und wie sie konfiguriert werden, zeigt Kapitel 12 ab Seite 177.

Auch möchte man solche Benachrichtigungen gegebenenfalls unterdrücken, weil sie zeitlich in eine Downtime fallen und es sich damit um einen geplanten Ausfall handelt. Downtimes können bei Icinga 2 auf zwei Weisen angegeben werden: als wiederkehrendes Ereignis mit Scheduled Downtime bezeichnet, die in der Konfiguration hinterlegt werden muss, oder als einmaliges. Letzteres wird zur Laufzeit vom Benutzer erzeugt und Downtime genannt.

Icinga 2 ist modular aufgebaut und rüstet alle Funktionalität über sogenannte Features nach. So kümmert sich z. B. notification um die Benachrichtigung oder checker um den Aufruf von Plugins und damit um die Planung, wann aktive Checks auszuführen sind. Alle Features werden ausführlich in Abschnitt 4.3 ab Seite 49 vorgestellt.

2Installation

Das Icinga-Projekt1 stellt auf seiner Website Installationspakete für Debian, SuSE, Red Hat und deren jeweilige Derivate zur Verfügung. Pakete bieten gegenüber einem selbst durchgeführten Übersetzen einige Vorteile:

Bei der Installation aus Paketen werden alle weiteren benötigten Pakete ebenfalls automatisch mit installiert.

Die Pflege, also das Einspielen neuer Versionen, wird erheblich erleichtert. Die Binärdateien werden aktualisiert, die Konfigurationsdateien bleiben jedoch aus der bisher laufenden Installation erhalten.

Auch auf starker Hardware benötigt das Übersetzen von Icinga 2 viel Zeit, die über das Kochen und den anschließenden Konsum von Kaffee weit hinaus geht.

Die einzelnen Komponenten, wie Core, die Anbindung einer Datenbank oder Icinga Web 2, sind aufeinander und auf die Besonderheiten der Betriebssysteme abgestimmt und so vorkonfiguriert, dass sie mit möglichst geringem Aufwand zusammenarbeiten.

Das Icinga-Team stellt neue Paketversionen immer zeitnah auf Servern zum Download zur Verfügung. Den aktuellen Entwicklungsstand kann man als »Nightly Snapshots« ebenfalls verfolgen, ohne auf die Vorteile einer paketbasierten Installation verzichten zu müssen.

Gegenüber den Repositories der Linux-Distributoren bieten die vom Icinga-Projekt angebotenen den Vorteil, dass hier andere Richtlinien zu Versionswechseln gelten können. Das verhindert, dass eine Installation auf einer bestimmten Version eingefroren wird, nur weil es der Richtlinie eines Distributors widerspricht, einen Versionswechsel zuzulassen. Bei einem sich so rasch entwickelnden Projekt wie Icinga 2 ist ein gelegentlicher Versionssprung durchaus sinnvoll.

»Tue es oder tue es nicht, es gibt kein versuchen.«

Meister Yoda, 1980

2.1Repositories

Um das Repository mit den Paketen der stabilen Releases einbinden zu können, importiert man zuerst den GPG-Schlüssel, der zur Überprüfung der Signaturen der Pakete dient. Danach werden die Repositories je nach Distribution eingebunden und die Indices neu aufgebaut. Eine Anleitung befindet sich zu jeder Distribution auf den Download-Sites2 des Icinga-Projekts.

RedHatFür RedHat basierte Systeme empfiehlt es sich, neben dem Icinga- auch gleich noch des EPEL3-Repository einzubinden, da sich z. B. nur dort die benötigten Monitoring-Plugins als Pakete befinden.

$ rpm --import https://packages.icinga.com/icinga.key

$ yum install -y https://packages.icinga.com \

/epel/icinga-rpm-release-7-latest.noarch.rpm

$ yum install -y https://dl.fedoraproject.org \

/pub/epel/epel-release-latest-7.noarch.rpm

$ yum makecache

DebianRepositories für Debian bieten in der Regel keine Pakete, um sich selbst einzubinden. Für das Icinga-Repository reicht jedoch ein Einzeiler an der richtigen Stelle. Sollen die Pakete via HTTPS bezogen werden, muss ein zusätzliches Paket apt-transport-https für den Paketmanager installiert sein.

$ apt-get install -y apt-transport-https

$ curl https://packages.icinga.com/icinga.key | apt-key add -

$ echo " \

deb https://packages.icinga.com/debian icinga-stretch main" \

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

$ apt-get update

2.2Sicherheits- und Zugriffskontrolle

Zur Erhöhung der Sicherheit setzen Linux-Systeme auf klassische Paketfilter und kernelnahe 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 auf Unix um Rollen, Domänen und Abstufungen bei Sensibilität dieser.

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. In allen anderen Fällen reicht ein reload.

RedHatInstallationen unter RedHat kommen meistens mit aktiviertem SELinux4, 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

$ systemctl restart icinga2.service

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 Online-Dokumentation zu icinga2-selinux5 und icingaweb2-selinux6 beschrieben.

Zusätzlich blockt ein Paketfilter hereinkommende Anfragen auf TCP-Port 80. Dieser muss entsprechend konfiguriert werden 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

Debianinstalliert auf einem Server 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-Projekten7. 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.

2.3Icinga 2 und Plugins

Die Paketquellen für Icinga 2 sind bei RedHat und Debian gleich, das Repository des Icinga-Projekts. Bei den »Standard«-Plugins verhält sich dies anders. Das EPEL-Repository stellt für RedHat-Systeme die von Nagios Enterprise8 gepflegten nagios-plugins zur Verfügung. Bei Debian setzt man auf die vom Community-Projekt9 bereitgestellten monitoring-plugins. Bis vor einigen Jahren existierten lediglich die von der Community betreuten nagios-plugins, durch Querelen kam es zu den jetzt zwei »unabhängigen« Projekten.

RedHatIm EPEL-Repository ist jedes Plugin einzeln paketiert zu finden. Über das Meta-Paket nagios-plugins-all lassen sich alle dem Projekt zugehörigen Plugins installieren. Die Plugins befinden sich danach im Verzeichnis /usr/lin64/nagios/plugins.

$ yum install icinga2 nagios-plugins-all

$ systemctl start icinga2.service

$ systemctl enable icinga2.service

Wie bei Red Hat üblich, wird der gerade installierte Dienst nicht automatisch gestartet, dies muss per Hand ausgeführt werden. Zusätzlich muss der Service auch für den automatischen Start beim Bootvorgang aktiviert werden. Ab RHEL 7 funktioniert beides mittels systemd. Die älteren System-V-Mechanismen können aber in der 7er-Version auch noch weiterhin verwendet werden. Icinga 2 wird als Benutzer icinga ausgeführt.

DebianAuch bei Debian sind die »Standard«-Plugins in unterschiedliche Pakete aufgeteilt, monitoring-plugins-basic und -standard. Wobei standard als Abhängigkeit basic mit installiert. Das Meta-Paket monitoring-plugins fasst dann nochmals beide zusammen. Alle werden im Dateisystem unter /usr/lib/nagios/plugins abgelegt.

$ apt-get install -y icinga2 monitoring-plugins

Aus Gründen der Kompatibilität existiert zusätzlich zu jedem Monitoring-Plugin-Paket auch noch ein Dummy-Paket mit entsprechender Benennung mit nagios. So installiert das Paket nagios-plugins dennoch monitoring-plugins.

Im Gegensatz zu RedHat wird der Service icinga2 nach erfolgter Installation gestartet und läuft somit auch schon zum jetzigen Zeitpunkt. Der Systembenutzer, unter dem Icinga 2 auf Debian läuft, ist wie schon erwähnt nagios. Da Icinga 2009 als Ableger von Nagios (Fork) gestartet ist, wird vom Debian-Projekt als Grund angeführt, dass auch alle Zusatzsoftware auf Nagios zugeschnitten ist und den User nagios verwendet. Damit es mit diesen nicht zu Problemen in der Zusammenarbeit mit Icinga kommt, wurde der Benutzer damals beibehalten.

Beispielkonfiguration

Icinga 2 kommt nach der Installation mit einer Beispielkonfiguration zur Überwachung des eigenen Hosts und einiger Services. Diese ist in /etc/icinga2/conf.d abgelegt und steht unter der Paketverwaltung der jeweiligen Distribution, das heißt, bei Änderungen an den mitgelieferten Dateien kann die eigene Konfiguration beschädigt werden, wenn sich dise im Verzeichnis conf.d befindet.

Da im Folgenden noch auf die Beispiele in conf.d eingegangen wird und diese abgeändert bzw. erweitert werden, dupliziert man am besten das Beispielverzeichnis.

$ cd /etc/icinga2

$ cp -rdp conf.d book.d

Nun muss das neue Verzeichnis noch von Icinga 2 berücksichtigt werden, gleichzeitig ist das alte aus der Konfiguration herauszuhalten, da sonst ja alle Definitionen doppelt vorhanden wären. Hierzu ist in der Datei /etc/icinga2/icinga2.conf in der letzten Zeile conf.d durch book.d zu ersetzen.

//include_recursive "conf.d"

include_recursive "book.d"

Codebeispiel 2.1: Icinga 2 Konfigurationsdatei /etc/icinga2/icinga2.conf

Nach durchgeführten Änderungen an der Konfiguration muss Icinga 2 diese neu laden:

$ systemctl reload icinga2

2.4Icinga Data Output

Voraussetzung für den Einsatz von Icinga Web 2 ist eine PostgreSQL- oder MySQL-Datenbank, die die von Icinga 2 und den Plugins ermittelten Werte mit Hilfe des Features ido in eine Datenbank schreibt. Icinga Web 2 liest dort die Informationen wieder aus, bereitet sie auf und zeigt sie an.

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. Je größer die zu überwachende Umgebung, desto wichtiger ist ein schnelles Plattensubsystem mit geringen Latenzen. Direct Attached Storage (DAS), also lokal angebundene Festplatten, ist hierfür nach wie vor am besten geeignet.

Abbildung 2-1: Icinga 2 IDO Anbindung

Icinga 2 als Monitoring-Anwendung verursacht im Datenbank-Backend erhebliche Schreiblast. Jeder mit einem Plugin ermittelte Wert muss in die Datenbank geschrieben werden. Dies zieht eine Vielzahl von SQL-Inserts und Updates nach sich, die IO-Last verursachen. Verkleinert man die Check-Intervalle, steigt die Last linear an.

Das angesprochene Feature befindet sich zum jetzigen Zeitpunkt noch nicht auf dem System, es muss durch die Installation eines weiteren Pakets hinzugefügt werden. Hierbei wird zwischen den unterschiedlichen Datenbanken unterschieden, das heißt, je nachdem, ob PostgreSQL oder MySQL zum Einsatz kommen soll, sind unterschiedliche Pakete zu installieren.

2.4.1MySQL/MariaDB

Weiter Verbreitung im Icinga-Umfeld erfreut sich MySQL bzw. MariaDB. Auch auf dem Community-Portal10 erhält man schneller und leichter Unterstützung für MySQL als für PostgreSQL.

RedHatDie Pakete für das DBMS MariaDB kommen bei RedHat aus den eigenen Repositories, das Feature ido-mysql für die kompatible MariaDB stellt das Icinga-Team über ihren Download im Paket icinga2-ido-mysql zur Verfügung. Nach erfolgter Installation muss MariaDB gestartet werden und auch per Hand dafür Sorge getragen werden, dass der Start automatisch bei einem Systemstart erfolgt.

$ yum install -y icinga2-ido-mysql mariadb-server

$ systemctl start mariadb.service

$ systemctl enable mariadb.service

Danach sind die Datenbank und ein Account mit Zugriff auf diese anzulegen sowie das Datenbank-Schema für die IDO einzuspielen.

$ mysql

MariaDB [(none)]> CREATE DATABASE icinga2;

Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> GRANT SELECT, INSERT, UPDATE, DELETE, \

DROP, CREATE VIEW, INDEX, EXECUTE ON icinga2.* TO \

’icinga2’@’localhost’ IDENTIFIED BY ’XXX’;

Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> exit

Bye

$ mysql icinga2 < /usr/share/icinga2-ido-mysql/schema/mysql.sql

Debianstellt ebenfalls über ihr Standard-Repository die Pakete für MariaDB bereit. Das Paket mit dem IDO-Feature kommt auch hier vom durch das Icinga-Team gehosteten Repository.

$ apt-get install -y icinga2-ido-mysql mariadb-server

Abbildung 2-2: Konfiguration der IDO-Datenbank mittels dbconfig auf Debian

Auf Debian-Systemen unterstützt dbconfig die Einrichtung des DBMS und der Datenbank für Icinga. Zusätzlich wird auch die Konfiguration des IDO-Features nach der Installation angeboten.

Bei den Pakten zur aktuellen Version 2.8 von Icinga 2 funktioniert die Aktivierung des Features jedoch nicht und muss nachträglich per Hand durchgeführt werden.

2.4.2PostgreSQL

Zu PostgreSQL müssen die Autoren gestehen, nicht ausreichend praktische Erfahrungen zu besitzen. Erfahrungen fehlen hier vor allem für größere Umgebungen mit mehr als 20.000 Services. Probleme bestehen durch massive Insert- und Update-Queries im Zusammenhang mit dem Vacuum-Prozess von PostgreSQL. Das Freiräumen von nicht mehr genutztem Platz, der damit wieder freizugeben ist, kann dem angesprochenen Aufkommen zu einem gewissen Zeitpunkt nicht mehr nachkommen. Dies soll jedoch niemanden abhalten, PostgreSQL als Backend zu verwenden, da bestimmt Möglichkeiten zum Performance-Tuning bestehen.

RedHatbietet Pakete zu PostgreSQL in seinem Basis-Repository an. Das Paket icinga2-ido-pgsql zum IDO-Feature kommt wieder aus dem Repository des Icinga-Projekts. Bevor PostgreSQL erst mal gestartet werden kann, muss das DBMS initialisiert werden.

$ yum install -y icinga2-ido-pgsql postgresql-server

$ /usr/bin/postgresql-setup initdb

$ systemctl start postgresql.service

$ systemctl enable postgresql.service

Für PostgreSQL ist noch etwas mehr zu tun. Zuerst wird ebenfalls eine Datenbank angelegt. Dies ist dem Benutzer »root« nicht gestattet, es muss als Datenbankadministrator »postgres« geschehen.

$ cd ˜postgres

$ sudo -u postgres psql -c \

"CREATE ROLE icinga2 WITH LOGIN PASSWORD ’XXX’"

$ sudo -u postgres createdb -O icinga2 -E UTF8 icinga2

Das Berechtigungskonzept verlangt jedoch zusätzlich noch die Autorisierung, von wo aus zugegriffen werden darf, und diese wird nicht in einer Datenbank des DBMS hinterlegt, sondern in der Konfigurationsdatei pg_hba.conf. Für den lokalen Zugriff sind die folgenden, die Datenbank icinga2 betreffenden drei Zeilen einzufügen und dies vor den vordefinierten anderen lokalen Zugriffen.

$ icinga

local icinga2 icinga2 md5

host icinga2 icinga2 127.0.0.1/32 md5

host icinga2 icinga2 ::1/128 md5

$ "local" is for Unix domain socket connections only

local all all ident

$ IPv4 local connections:

host all all 127.0.0.1/32 ident

$ IPv6 local connections:

host all all ::1/128 ident

Codebeispiel 2.2:/var/lib/pgsql/data/pg_hba.conf

Nach Änderungen an der pg_hba.conf muss PostgreSQL neu gestartet werden. Danach kann das Einspielen des Datenbankschemas für die IDO als Datenbankbenutzer icinga2 erfolgen:

$ systemctl restart postgresql.service

$ psql -U icinga2 -d icinga2 \

< /usr/share/icinga2-ido-pgsql/schema/pgsql.sql

DebianIm Gegensatz zu RedHat läuft hier PostgreSQL schon nach der Installation und muss nicht per Hand initialisiert werden. Auch mit Hilfe des dbconfig-Systems wird im Anschluss interaktiv die nahezu komplette Konfiguration durchgeführt.

Abbildung 2-3: Aktivieren des IDO-Features auf Debian

$ apt-get install -y icinga2-ido-pgsql postgresql

Neben der generellen Frage, ob das IDO-Feature konfiguriert werden soll, folgen weitere Fragen zum Anlegen der Datenbank, eines Benutzers und zum Einspielen des IDO-Schemas.

Ob das IDO-Feature im Icinga eingeschaltet werden soll, ist jedoch genauso wie für MySQL defekt. Damit ist mit folgendem Abschnitt fortzufahren, um dies manuell durchzuführen.

2.4.3Feature IDO aktivieren

Für das Schreiben in die Datenbank muss das entsprechende IDO-Feature eingeschaltet sein. Der momentane Zustand, welche Features aktiviert bzw. deaktiviert sind, wird mit icinga2 feature list ermittelt.

$ icinga2 feature list

Disabled features: api command compatlog debuglog gelf ...

Enabled features: checker ido-mysql mainlog notification

Ebenfalls mit icinga2 feature werden Features an- (enable) und abgeschaltet (disable). Die Distribution macht hierbei keinerlei Unterschied.

Die jeweiligen Konfigurationsdateien befinden sich im Verzeichnis /etc/icinga2/features-available. Mit der Aktivierung wird ein Link nach /etc/icinga2/features-enabled gesetzt. Die dortigen Konfigurationsdateien werden dann bei dem nötigen Neustart von Icinga 2 eingelesen.

MySQLerfordert das Feature ido-mysql. Die entsprechende Datei zur Konfiguration enthält die Zugangsdaten zur Datenbank und die Angabe, wo sich diese befindet.

Codebeispiel 2.3:/etc/icinga2/features-available/ido-mysql.conf

Nach gemachten Einstellungen kann das Feature wie folgt aktiviert werden. Auf RedHat sollte dies schon von der Paketinstallation erledigt worden sein. Bei Debian liegt hingegen oben beschriebener Bug vor, so dass hier der folgende Schritt auszuführen ist. Danach ist zwingend der Neustart von Icinga 2 erforderlich, auch bei RedHat.

$ icinga2 feature enable ido-mysql

Enabling feature ido-mysql. Make sure to restart Icinga 2 for...

$ systemctl reload icinga2

Ab sofort schreibt Icinga 2 zusätzlich zu Status- und Logdateien auch in die IDO-Datenbank. Verbindet man sich nun mit der Datenbank, kann durch SQL-Abfragen kontrolliert werden, ob die vorgenommene Konfiguration reibungslos funktioniert.

MariaDB [icinga2]> SELECT * FROM icinga_hosts\G

*************************** 1. row ***************************

host_id: 1

instance_id: 1

config_type: 1

host_object_id: 54

alias: fornax.icinga-book.local

display_name: fornax.icinga-book.local

address: 127.0.0.1

address6: ::1

[...]

1 row in set (0.00 sec)

So liegen in der Tabelle icinga_hosts die Informationen der konfigurierten Host-Objekte und in icinga_services die der Services.

MariaDB [icinga2]> SELECT count(*) FROM icinga_hosts;

+----------+

| count(*) |

+----------+

| 11 |

+----------+

1 row in set (0.00 sec)

Die Tabelle icinga_services enthält je nach Distribution bzw. mitkommender Beispielkonfiguration eine unterschiedliche Anzahl an Zeilen.

Neben diesen Tabellen gibt es noch eine Vielzahl weiterer Tabellen mit Informationen oder Relationen zwischen diesen. Das komplette Datenbankschema ist der Dokumentation11 zu entnehmen.

PostgresSQLbenötigt das Feature ido-pgsql. Die Datei für die Konfiguration, auf welche Datenbank mit welchem Benutzer und Passwort zugegriffen wird, befindet sich wie für Features üblich im Verzeichnis features-available im Icinga-Konfigurationsverzeichnis und heißt ido-pgsql.conf.

Codebeispiel 2.4:/etc/icinga2/features-available/ido-pgsql.conf

Nach gemachten Anpassungen ist das Feature einzuschalten. Auf Red-Hat ist dies schon durch die Paketinstallation erfolgt. Bei Debian besteht derselbe Bug wie für MySQL und das Feature muss noch per Hand aktiviert werden. Danach ist Icinga 2 neu zu starten.

$ icinga2 feature enable ido-pgsql

Enabling feature ido-pgsql. Make sure to restart Icinga 2 for...

$ systemctl reload icinga2.service

Ab diesem Zeitpunkt schreibt Icinga 2 in die PostgreSQL-Datenbank, sofern alles richtig konfiguriert ist. Überprüfen lässt sich dies durch einen Blick in die Datenbank. In der mitgelieferten Beispielkonfiguration wird zunächst nur der eigene Host überwacht. Die Anzahl der dortigen Services, in der Tabelle icinga_services, variiert je nach Distribution, muss aber größer als null sein. Das vollständige Datenbankschema ist der schon bei MySQL erwähnten Online-Dokumentation zu entnehmen.

$ cd ˜postgres

$ sudo -u postgres psql -U icinga2 -d icinga2 -c \

’select count(*) from icinga_services’

Password for user icinga2: XXX

count

-------

12

(1 row)

2.5API einrichten

Mit Icinga Web 2 hat der Benutzer die Möglichkeit, verschiedene Aktionen auszuführen, die Icinga 2 übergeben werden müssen. Dies betrifft das Setzen von Downtimes ebenso wie Acknowledgments, Comments oder auch das Senden von sofortig auszuführenden Checks. Icinga Web 2 kennt zwei Wege, dieses Icinga mitzuteilen.

Die bisherige Methode, die Informationen über einen Unix-Socket zu senden, ist mit der in Icinga Web 2 Version 2.4 veraltet. Icinga Web 2 sendet dann alle Kommandos an den API-Port von Icinga 2, standardmäßig ist dies der TCP-Port 5665. Um jedoch die API nutzen zu können, ist sie zu aktivieren und ein Zertifikat ist erforderlich.

$ icinga2 api setup

information/cli: Generating new CA.

...

Enabling feature api. Make sure to restart Icinga 2 for...

Done.

Now restart your Icinga 2 daemon to finish the installation!

Abbildung 2-4: Icinga 2 API Anbindung

Was außerdem getan werden muss, ist das Anlegen eines API-Accounts per Hand. Das oben stehende Kommando schreibt das Objekt root mit einem zufällig erzeugten Passwort nach book.d/api-users.conf ins Konfigurationsverzeichnis von Icinga 2. Dieser Benutzer unterliegt keinen Einschränkungen in Bezug auf Berechtigungen für den Zugang. Icinga Web 2 benötigt jedoch keinen Vollzugriff und deshalb sollte unbedingt ein eigener Benutzer icingaweb2 mit Einschränkungen angelegt werden.

Codebeispiel 2.5:/etc/icinga2/book.d/api-users.conf

Die Berechtigungen werden später im Kapitel 21 ab Seite 537 eingehend erklärt. Abschließend muss auf jeden Fall die Konfiguration neu eingelesen werden.

$ systemctl reload icinga2

2.6Icinga Web 2

Bei Icinga Web 2 handelt es sich um ein in PHP implementiertes Framework, in dem Monitoring ein Modul ist. Weitere mitgelieferte Module sind die Icinga Dokumentation und Translation, das den Übersetzern der Oberfläche bei der Arbeit hilft. Es handelt sich also bisher ausschließlich um Module aus dem Bereich Monitoring oder für die Arbeit mit Icinga Web 2 selbst. Mehr Module können bei Bedarf dazuinstalliert werden, wie später gezeigt wird. Die hier beschriebene Installation und Konfiguration beziehen sich auf die 2.5er Version von Icinga Web 2.

Abbildung 2-5: Icinga Web 2, Auswahl der installierbaren Module

Ab dieser Version setzen Pakete von Icinga Web 2 ein PHP in der Version 5.6 oder neuer voraus. Als zusätzliche Abhängigkeiten von Icinga Web 2 werden etliche PHP-Pakete installiert. Für PHP fordert Icinga Web 2 eine gesetzte Zeitzone, die in der php.ini unter der Sektion Date einzutragen ist.

Codebeispiel 2.6: Zeitzonen-Einstellung in PHP

RedHatUm auch andere Webserver als nur den Apache unterstützen zu können, hat das Icinga-Team entschieden, die Pakete für RedHat-basierte Plattformen auf die ausschließliche Unterstützung des PHP FastCGI Process Manager (FPM) auszurichten. Damit ist nun auch die einfache Benutzung z. B. eines Nginx als Webserver möglich. Entfallen ist damit jedoch die abhängige Installation vom Apache und der favorisierte Webserver muss selbst installiert werden.

Als Voraussetzung für die Installation von Icinga Web 2 muss neben dem EPEL-Repository auch noch zusätzlich das SCL-Repository (Software Collection for Linux) eingebunden werden, wo PHP in der aktuellen Version 7 und viele benötigte PHP-Pakete zu dieser Version zum Download angeboten werden.

Für ein aktuelles CentOS 7 befindet sich ein Paket im CentOS Extra Repository:

$ yum install -y centos-release-scl

Bei RHEL 7 wird das SCL-Repository ebenfalls als Paket über den Subscribtion-Manager aktiviert:

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

$ subscription-manager repos --enable rhel-server-rhscl-7-rpms

Für RHEL/CentOS 6 steht zurzeit nur PHP 7.0 zur Verfügung, detailliert wird hierfür das Vorgehen in der Online-Dokumentation12 zur Installation beschrieben.

Neben dem Paket icingaweb2 wird zur Konfiguration noch das Paket icingacli benötigt. Als Beispiel wird hier ein Apache-Webserver verwendet. Das FPM wird als Dienst unabhängig vom Webserver angeboten und muss ebenfalls wie dieser beim Systemstart gestartet werden.

$ yum install -y httpd icingaweb2 icingacli

$ systemctl enable httpd.service

$ systemctl enable rh-php71-php-fpm.service

Je nachdem, welches DBMS zur Anwendung kommt, ist entweder rh-php71-php-mysqlnd für MySQL-DBs oder rh-php71-php-pgsql bei PostgreSQL zusätzlich zu installieren. Die PHP-Konfiguration wird aus /etc/opt/rh/rh-php71/php.ini gelesen und muss mit der gewünschten Zeitzone wie in Beispiel 2.6 angepasst werden.

Debianbezieht alle erforderlichen Pakete aus seinem Standard-Repository wie auch aus dem vom Icinga-Projekt. Im Gegensatz zu RedHat basieren die Pakete bei Debian nach wie vor auf einer Abhängigkeit zum PHP-Modul des Apache-Webservers.

$ apt-get install -y icingaweb2 icingacli

Die Datei php.ini befindet sich für den Apache bei »jessie« (Debian 8) im Verzeichnis /etc/php5/apache2. Im aktuellen Release »stretch« (Debian 9) kommt PHP in der Version 7.0 zum Einsatz und liegt unterhalb von /etc/php/7.0/apache2.

2.6.1Konfiguration mit Hilfe des Assistenten

Bevor mit der Konfiguration fortgefahren werden kann, muss der Webserver gestartet bzw. neu gestartet werden.

Das ist immer erforderlich, wenn an der PHP-Konfiguration Änderungen erfolgt sind. Beim Einsatz von FPM auf RedHat muss bei Anpassungen an PHP entsprechend der Dienst hierzu neu gestartet werden. Nicht nur Anpassungen an der php.ini betrifft das, sondern auch wenn neue PHP-Module installiert wurden, die nun verwendet werden sollen.

Bei direkten Konfigurationsarbeiten am Webserver gilt die Erfordernis, diesen einem Neustart zu unterziehen, natürlich auch.

Abbildung 2-6: Anmeldemaske von Icinga Web 2 direkt nach der Installation

Wird nun der Webserver, auf dem Icinga Web 2 läuft, mit /icingaweb2 als URI aufgerufen, erhält man den Anmeldebildschirm aus Abbildung 2-6 mit dem Hinweis, die noch nötige Konfiguration wie in der Dokumentation beschrieben oder mit dem Assistenten durchzuführen. Hier folgt die Beschreibung, wie bei der Benutzung des Assistenten zu verfahren ist.

Da dieses Setup in der Regel ohne Authentifizierung für jeden erreichbar ist, muss als Erstes festgestellt werden, dass der Benutzer der Session autorisiert ist, eine Konfiguration vorzunehmen. Dies geschieht anhand eines einzugebenden Tokens.

Das erforderliche Token muss mit icingacli auf der Konsole des Webservers erzeugt werden:

$ icingacli setup token create;

The newly generated setup token is: 9a1df41ea92bcf9b

Abbildung 2-7: Icinga Web 2, Setup Authentifizierung mit Token

Weiter geht es mit der Auswahl der zu aktivierenden Module aus Abbildung 2-5 auf Seite 24. Nachdem zumindest Monitoring ausgewählt wurde, gelangt man zur Seite, auf der die Voraussetzungen für die Konfiguration geprüft werden, zu sehen in Abbildung 2-8 auf Seite 28.

Unbedingt erforderliche Voraussetzungen werden Rot angezeigt, optionale in Gelb und schon erfüllte in Grün. In Abbildung 2-8 fehlt entweder die zu setzende Zeitzone in der php.ini oder der nach deren Änderung notwendige Neustart des Webservers bzw. des PHP-FPM-Services wurde nicht ausgeführt.

Das fehlende PHP-Modul für die Kommunikation via Lightweight Directory Access Protocol (LDAP) ist hingegen nur optional und muss nur installiert werden, wenn in irgendeiner Form das LDAP-Protokoll verwendet werden soll, z. B. zur Authentifizierung gegen ein Microsoft Active Directory (AD).

Etwas anders verhält es sich mit den PHP-Modulen für MySQL und PostgreSQL, hier ist zur Konfiguration des Monitoring-Moduls von Icinga Web 2 eines von beiden erforderlich. Es wird hier jedoch nicht in Rot angezeigt, sondern bei Abwesenheit immer nur in Gelb. Das folgt daraus, dass die Konfiguration zweigeteilt verläuft. Zuerst wird das Framework Icinga Web 2 konfiguriert und im Anschluss das Modul Monitoring, bei dem die Datenbankanbindung erst endgültig relevant wird.

Abbildung 2-8: Icinga Web 2, Test auf erfüllte Voraussetzungen

Wird auf der darauffolgenden Seite jedoch »Datenbank« als Authentifizierungsquelle gewählt, ist auch schon für das Framework das entsprechende PHP-Modul Voraussetzung. Die externe Quelle bezeichnet z. B. die Authentifizierung über ein Apache-Auth-Modul.

Abbildung 2-9: Icinga Web 2, Konfiguration der Authentifizierung

Hat man sich für Datenbank entschieden, werden als Nächstes deren Zugangsdaten erfragt. Als Erstes ist ein Ressourcenname erforderlich, standardmäßig schlägt der Assistent icingaweb_db vor. Diese Bezeichnung ist lediglich zur internen Verwendung und dient später zur Identifizierung dieser Quelle und der dort enthaltenen Authentifizierungsdaten.

Welcher Datenbanktyp ausgewählt werden kann, richtet sich nach den schon oben erwähnten PHP-Modulen, die installiert sein müssen. Darauf folgen dann die üblichen Daten wie Host und Port, um eine Datenbank zu erreichen. Die Angabe eines Ports ist optional, wird keiner eingetragen, findet der jeweilige Standardport Verwendung.

Abbildung 2-10: Icinga Web 2, Authentifizierung mit Datenbank-Backend

Fehlen noch Datenbank-, Benutzername und Passwort, zusätzlich kann auch der Aufbau einer persistenten Verbindung zur Datenbank bestimmt werden. Dabei wird die Verbindung nach erfolgten Anfragen an die Webseite nicht wieder abgebaut, sondern bleibt für die nächsten Anfragen bestehen.

Wird kein Zeichensatz angegeben, wird der jeweilige Default-Wert des DBMS benutzt. Zu beachten ist, dass dies im Nachhinein nicht mehr ohne Weiteres geändert werden kann.

Da die gerade angegebene Datenbank noch nicht existiert, wird der Assistent versuchen, diese anzulegen. Hierbei unterscheidet sich das Verhalten des Assistenten nicht nur nach gewähltem Datenbanktyp und eingesetzter Linux-Distribution, sondern auch je nach Release.

MySQLerlaubt es, dass man sich als administrativer Benutzer root anmelden darf und damit die Berechtigung erhält, eine Datenbank zu erstellen. Ausnahme ist allerdings Debian 9 alias »stretch«. Hierfür muss die Datenbank per Hand angelegt werden. Gleiches gilt für den Fall, dass die Datenbank auf einem entfernten Server liegen soll.

MariaDB [(none)]> CREATE DATABASE icingaweb2;

Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> GRANT ALL ON icingaweb2.* \

TO ’icingaweb2’@’localhost’ IDENTIFIED BY ’XXX’;

Query OK, 0 rows affected (0.00 sec)

Ist die Datenbank bereits angelegt, wird die folgende Maske, die den Benutzernamen und das zugehörige Passwort für einen Admin-Account abfragt, übersprungen und damit nicht angezeigt. Wie bereits oben erwähnt, kann hier für RedHat und Debian »jessie« ein solcher Account erfolgreich benutzt werden.

Gerät man unter Debian 9 dennoch in diese Maske, gibt es zwei Möglichkeiten, nachdem dann die Datenbank angelegt wurde. Die einfache ist, über Back in den vorherigen Bildschirm zurückzuwechseln und von dort nochmals Next auszuwählen.

Alternativ kann auch ein beliebiger Username eingetragen werden. Nach fehlgeschlagenem Versuch, die Datenbank anzulegen, erscheint eine Checkbox Skip Validation, die aktiviert werden muss. Danach verifiziert der Assistent den angegebenen Benutzer nicht mehr und das DB-Schema für Icinga Web 2 wird als Benutzer icingaweb2 eingespielt.

Abbildung 2-11: Icinga Web 2, Konfiguration des administrativen Zugangs zum DBMS

Bei RedHat oder Debian 8 hingegen ist der lokale Zugriff als root erlaubt. Womöglich sogar ohne Passwort, wie es bei beiden der Standardinstallation entspricht.

PostgeSQLerlaubt generell keinen Admin-Zugriff, der nicht als Systembenutzer postgres ausgeführt wird. Hier müssen die Datenbank und der Account selbst von der Konsole aus angelegt werden. Soll der Zugriff nicht vom lokalen Server selbst erfolgen, muss darüberhinaus auch die Datei pg_hba.conf angepasst werden.

$ cd~postgres

$ sudo -u postgres psql -c \

"CREATE ROLE icingaweb2 WITH LOGIN PASSWORD ’XXX’"

$ sudo -u postgres createdb -O icingaweb2 -E UTF8 icingaweb2

Abbildung 2-12: Backendnamen für die Authentifizierung festlegen

Als Nächstes wird der zu vergebende Name des Backends abgefragt. Dieser wird wie schon der Name der Ressource intern verwendet. Es handelt sich hierbei um das Backend zur Authentifizierung des Benutzers und der Gruppenzugehörigkeit. Icinga Web 2 unterstützt mehrere Backends gleichzeitig, über diese Namen wird auf die unterschiedlichen Backends zugegriffen.

Abbildung 2-13: Icinga Web 2, Administrator Account anlegen

Bevor die abschließende Konfiguration vom Framework erfolgt, muss noch der Administrator-Zugang zum Icinga Web 2 erstellt werden. Dann sind Einstellungen bezüglich des Loggings zu treffen.

Logging erfolgt via Syslog, bei dem dann zusätzlich die Facility, das Prefix und das zu protokollierende Loglevel angegeben werden müssen. Alternativ kann in eine dedizierte Datei geschrieben werden. Interessant ist noch, wie Benutzerdaten gespeichert werden, die über die Authentifizierung via Namen und Passwort hinausgehen. Damit sind Eigenschaften wie z. B. Spracheinstellungen oder das Thema der Anzeigeoptik gemeint. Da in diesem Beispiel schon eine Datenbank für die Authentifizierungsdaten verwendet wird, bietet es sich an, auch hier Database auszuwählen, zumal in diesem Fall dieselbe DB benutzt wird.

Abbildung 2-14: Icinga Web 2, Logging und Anwenderdaten

Damit ist die Konfiguration des Frameworks abgeschlossen und auf der folgenden Seite sind nochmals alle gemachten Angaben aufgelistet. Nun startet mit der kommenden Seite die Konfiguration des Monitoring-Moduls. Zuerst bestimmt man den Namen des Backends, als Typ wird zurzeit nur IDO unterstützt.

Abbildung 2-15: Icinga Web 2, Auswahl des Backends

Als Zweites werden dann die Zugangsdaten zur IDO eingetragen, aus der Icinga Web 2 alle Informationen zum aktuellen Status der einzelnen Host- und Service-Checks bezieht sowie auch alle zusätzlichen historischen Daten wie z. B., wann Statuswechsel erfolgten. In Abbildung 2-16 wird als Beispiel eine MySQL-Datenbank auf dem lokalen Host als anzusprechen konfiguriert.

Abbildung 2-16: Icinga Web 2, Auswahl des Backends

Mit Anwahl des Buttons Validate Configuration können die vorgenommenen Angaben auf Korrektheit geprüft werden und somit, ob die Datenbank erreichbar ist.