Um dir einen reflektierten und ehrlichen Einblick in meine Entscheidungsgrundlage zu geben, gehe ich so vor, als würde ich im Consulting einen Kunden beraten und mit ihm zu einem für ihn passenden Lösungsansatz kommen. Bevor ich die jeweiligen Vor- und Nachteile von Konfigurationsdateien und der grafischen Oberfläche, dem Icinga Director, beleuchte, möchte ich als Einstieg allerdings erst über die Icinga DSL reden. Dies soll dazu dienen, dass Du meine Argumente besser verstehst und nachvollziehen kannst. Nach dem Pro und Kontra werde ich dann mein persönliches Fazit ziehen und Dir verraten, wie ich mich entscheiden würde. Das muss aber nicht der Schluss sein, zu dem Du kommst. Hier darf gerne jede:r mit seiner eigenen Gewichtung zu einem persönlichen Ergebnis kommen. Und eigentlich handelt es sich hierbei nur um ein Zwischenfazit. Denn im Anschluss möchte ich noch auf die Möglichkeiten für eine Automatisierung der Konfiguration eingehen. Und falls Du Automatisierung in Betracht ziehst, wird auch das Deine endgültige Entscheidung maßgeblich beeinflussen. Also, schauen wir uns die Möglichkeiten einmal genauer an!

Icinga DSL

Nun hab ich die Abkürzung DSL bereits zweimal verwendet ohne sie auszuschreiben! Was ich meinen Auszubildenden angekreidet hätte, will ich aber bewusst als Stilmittel verwenden. Denn tatsächlich verwendet Icinga 2 zur Konfiguration nicht eine einfache Konfigurationssprache sondern eine Domain-Specific-Language (DSL). Das Gegenstück wäre eine General-Purpose-Language (GPL) wie beispielsweise YAML. Mit einer solchen ließen sich bestimmt auch alle Monitoring-Objekte abbilden, aber die Icinga DSL erlaubt noch mehr. Dank DSL lassen sich Verzweigungen und Funktionen umsetzen und damit die Konfiguration vereinfachen, was auch die Wartung vereinfacht.

Ein Beispiel für eine Host-Definition:

object Host "localhost" {
  imports "Default Host"
  address = "127.0.0.1"
  vars.os = "Linux"
}

Was aber für mich viel wichtiger ist, ist der Ansatz dahinter. War mit Icinga 1 die Konfiguration noch sehr objekt-basierend, so dass mehr oder weniger jedes Objekt einzeln angelegt und gepflegt werden musste, ist nun die DSL für eine regel-basierte Konfiguration gedacht. Das ermöglicht es, sich Regeln für Überwachung und Benachrichtigung zu überlegen und dann die Host-Objekte mit den passenden Eigenschaften auszustatten, damit die Regeln greifen.

Ein Beispiel für eine solche Regel zur Service-Definition:

apply Service "SSH" {
  import "Default Service"
  check_command = "ssh"

  assign where host.vars.os == "Linux"
}

Auch wenn Du Dich bisher nicht eingehender mit der Icinga DSL befasst hast, kannst Du vermutlich dieses einfache Beispiel nachvollziehen und erkennen, dass für jedes System inklusive unserem „localhost“ mit dem Betriebssystem Linux nun ein Service zur Überwachung des SSH-Diensts erzeugt wird. Natürlich kann es auch durchaus komplexer werden, aber auch das wollen wir vielleicht konfigurieren. Auch für einen komplexeren Befehl möchte ich Dir ein Beispiel geben.

Zeitabhängige Schwellwerte für die Überwachung der Auslastung als Beispiel für komplexere Konfiguration:

apply Service "Load" {
  import "Agent Service"
  check_command = "load"

  vars.load_wload1 = {{
    if (get_time_period("backup").is_inside) {
      return 20
    } else {
      return 5
    }
  }}
  vars.load_cload1 = {{
    if (get_time_period("backup").is_inside) {
      return 40
    } else {
      return 10
    }
  }}

  assign where host.vars.os == "Linux"
}

In diesem Beispiel werden die Schwellwerte für die Auslastung des Systems während der für das Backup definierten Timeperiod hoch gesetzt. Dadurch werden fehlerhaft-positive Alarme vermieden, ohne die Überwachung oder Alarmierung komplett abzuschalten.

Ich hoffe diese kleine Einleitung macht deutlich, was und wie wir aufgrund der Eigenschaften der Icinga DSL konfigurieren müssen. Egal ob in Konfigurationsdateien oder mit Hilfe der grafischen Oberfläche, dem Icinga Director.

Konfigurationsdateien

Der Vorteil von Konfigurationsdateien ist oftmals der „Haben wir schon immer so gemacht“-Faktor. Zwar muss man für den Einstieg die Icinga DSL lernen, aber man kann mit gewohnten Werkzeugen, Strukturen und Arbeitsweisen an die Konfiguration von Icinga herangehen. Auch eine Versionskontrolle mittels Git oder eine Automatisierung mit Ansible oder Puppet ist einfach möglich.

Eine Zusammenarbeit an den Dateien wird schon etwas komplizierter, denn alle müssen das gleiche Verständnis der Struktur mitbringen. Sollen dabei auch noch verschiedene Rollen eingenommen werden, müssen entsprechend feine Dateirechte her oder es braucht zumindest wirklich eine Versionskontrolle und damit verbundene Reviews.

Syntax-Highlighting ist für die wichtigsten Editoren vorhanden, aber trotzdem dürfte das Hauptproblem die Fehleranfälligkeit des Menschen sein. Sowohl syntaktische als auch logische Fehler fallen erst bei der Validierung durch Icinga auf und sind gerade wenn mehrere Personen parallel Änderungen vorgenommen haben auch nicht immer leicht zu finden.

Der größte Vorteil steht dem direkt entgegen, denn ohne eine weitere Abstraktion habe ich direkten und vollen Zugriff auf alle Möglichkeiten der Icinga DSL. Somit sind zahlreiche Anpassungen möglich wie die oben gezeigten zeitabhängigen Schwellwerte, aber noch vieles mehr wie das Erzeugen von Objekten per Schleife auch über komplexe Datenstrukturen oder das Auswerten und Zusammenfassen von bestehenden Checks zu einem Gesamtergebnis. Aber auch ohne die komplexen Beispiele kann eine einfache Ergänzung, wie etwa eine Fallunterscheidung, schon Arbeitserleichterung bringen und doppelte Pflege vermeiden!

Icinga Director

Der Icinga Director als grafisches Frontend zur Konfiguration stellt eine Abstraktion der Icinga DSL dar, denn es müssen natürlich für alle Objekte mit allen Attributen Eingabemasken existieren. Um das noch etwas klarer zu machen, gebe ich Dir einen kurzen Einblick in die Funktionsweise des Icinga Directors. Der Director importiert von einer Icinga-Instanz grundlegende Objekte wie Check-Kommandos, Endpunkte und Zonen. Nach diesem Kickstart musst Du für die allermeisten Objekte zunächst Templates anlegen, wobei direkt Felder für zusätzliche Eigenschaften zu erstellen und anzuhängen sind. Sobald Du auch konkrete Objekte angelegt hast, kannst Du die Konfiguration für Icinga rendern und über den entsprechenden API-Endpunkt produktiv nehmen.

Das heißt auch beim Director können Fehler erst durch die Validierung durch Icinga sichtbar werden. Aber die Eingabemasken reduzieren das Fehlerpotential stark, da Syntax-Fehler weitestgehend ausgeschlossen werden. Bei der Erstellung von Templates, Feldern und Regelwerk kannst Du durch sprechende Namen, Beschreibungen, Filter die nur passende Kombinationen erlauben sowie weitere ähnliche Maßnahmen das Risiko für logische Fehler weiter senken.

Auf der Trennung von Templates und Objekten baut auch das Rechtesystem des Directors auf, denn der Zwang zur Erstellung von Templates bereitet auch eine entsprechende Rollentrennung vor. So soll gewährleistet werden, dass ein Monitoring-Administrator ganz leicht Vorgaben machen kann und beispielsweise der Linux-Administrator anschließend einfach seine Hosts einpflegen braucht. Wer darauf geachtet hat, dem ist hier mein zögerliches Zugestehen aufgefallen. Denn ein Nachteil, den ich nicht verschweigen möchte, ist leider die Dokumentation des Directors. Alles Grundsätzliche ist in der Dokumentation durchaus enthalten. Manche Details jedoch werden erst durch Ausprobieren klar und Best Practices kristallisieren sich erst mit einiger Erfahrung heraus.

Was erklärt Dir die Dokumentation gut? Komfortfunktionen wie die, dass Du über ein Attribut den Host zu einem Icinga Agenten erklären kannst, finden sich relativ einfach. Die Erklärung, dass es uns Arbeit abnimmt, nochmal separat Endpoint- und Zonen-Objekte für jeden Host zu definieren, findet sich auch. Ebenso ein Hinweis auf die Installations- und Konfigurationshilfe, die sich hinter einem neuen Tab verbirgt. Anderes ist meines Erachtens weniger optimal dokumentiert. Wie ich Checks auf einem anderen Agenten ausführe und was es für das Feature bedeutet, ist dann außer für den erfahrenen Benutzer schwer ersichtlich. Ähnlich geht es mir auch mit anderen Features wie Choices oder Datenfeldkategorien. Diese sind sicher alle optional, dienen jedoch die Benutzerführung zu verbessern und wie bereits angemerkt Fehleranfälligkeiten zu reduzieren.

Auch wenn es nicht ganz offensichtlich ist und die Möglichkeit erst einmal einschränkend wirkt, können mit dem Icinga Director sogar bei Argumenten von Check-Kommandos komplexere Konstrukte mit der Icinga DSL eingebaut werden. Das bedeutet, dass auch das Beispiel mit zeitgesteuerten Schwellwerten möglich ist. Nur muss es halt etwas anders gelöst werden.

Erwähnt werden wollen noch die integrierte CLI und API. Solche Schnittstellen sehe ich immer als Plus. Sie ermöglichen hilfreiche zusätzliche Arbeitsweisen. Die ein oder andere schnelle Schleife über die CLI hat mir schon einiges an Klick-Arbeit gespart.

Zwischenfazit

Für meine eigene kleine Instanz wären wohl Konfigurationsdateien meine erste Wahl, denn ich bin ziemlich schnell im VIM unterwegs, kenne die Icinga DSL doch ganz gut und vor allem bin dann auch nur ich auf dem System unterwegs.

Ansonsten möchte ich Dir aber den Icinga Director ans Herz legen! Mit entsprechender Vorbereitung durch einen erfahrenen Admin oder wenn Du selbst Dir die Zeit nehmen kannst, Dich einzuarbeiten, kannst Du aus dem Director einiges rausholen. Ein großer Vorteil: Du kannst im Director die Arbeit leicht auf mehrere Personen verteilen, ohne dass alle ganz tief in die Materie einsteigen müssen. Das erlaubt es euch, leicht im Team zusammenzuarbeiten und die Abhängigkeit von einzelnen Personen zu reduzieren. Auch die Qualität des Monitorings wird in der Regel besser, wenn Administratoren das Monitoring eigenverantwortlich für ihre Systeme und Dienste pflegen können. Dazu tragen auch die erwähnten Komfortfunktionen und Möglichkeiten zum Aufhübschen bei, denn zumindest ein Umdenken erfordert der Director: Weg von der einfachen Konfiguration, die das primäre Ziel verfolgt,möglichst schnell etwas zu konfigurieren, hin zu einer möglichst übersichtlichen Konfiguration, die leicht zu verstehen und damit auch zu pflegen ist!

Nun fragt sich der eine oder die andere vielleicht, ob er oder sie mit einer Mischung aus beidem nicht die Vorteile beider Welten bekommen kann. Davon möchte ich jedoch abraten! Es ist zwar theoretisch und auch praktisch möglich, erfordert aber definitiv ein sehr tiefes Verständnis. Spätestens bei der Fehlersuche kann dies zum Verhängnis werden. Zudem schränkt es die Möglichkeiten des Directors ein, Objekte aus den Konfigurationsdateien zu verwalten. Du hast beispielsweise nicht mehr die Möglichkeit, wenn Du einen Check-Command importierst, alle Eigenschaften zu pflegen. Gerne behalte die Option im Hinterkopf und denke daran, wenn Du zum Beispiel Check-Kommandos als Konfigurationsdatei beim Plugin mitgeliefert bekommst. Aber bitte plane nicht damit! Daher auch hier meine übliche Empfehlung, dass Du Dich direkt zu Beginn für einen der beiden Wege entscheidest. So ersparst Du Dir später eine Migration und damit einhergehendes Umdenken.

Möglichkeiten der Automatisierung

Für mich ist schlussendlich meistens nicht entscheidend, wie einzelne Objekte konfiguriert werden können, da ich im Idealfall das Monitoring gar nicht manuell pflegen möchte. Und hier kommt eine der größten Stärken des Directors zum tragen: Der Director bietet die Möglichkeit, Daten aus einer Datenquelle zu importieren und aus diesen Daten dann Monitoring-Objekte zu erzeugen. Dabei können sogar noch Modifikatoren genutzt werden, um die Daten für den Verwendungszweck anzupassen.

Als erstes einfaches Beispiel möchte ich skizzieren, wie ein Import von Benutzern aussehen könnte. Die gleiche LDAP-Ressource, die für die Authentifizierung hergenommen wird, kann im Director als Importquelle verwendet werden. Ich gehe üblicherweise her und erstelle eine erste Import-Regel, die Gruppen importiert, und da hier meist keine Anpassungen nötig sind, kann ich sie direkt zu Usergroups für Icinga synchronisieren.Als zweites erstelle ich eine Import-Regel, die Benutzer importiert, dabei die Gruppenmitgliedschaften filtert und in ein passendes Format bringt, bevor über die Synchronisation daraus User-Objekte werden. Und schon muss ich für Benachrichtigungen nur noch benötigte Templates und die eigentlichen Benachrichtigungen pflegen. Das Management der hierfür benötigten Benutzer und ihrer Gruppen übernimmt das Active Directory, egal ob neue Kolleg:innen, Namensänderungen, Team-Wechsel oder was auch immer anstehen.

Das zweite Beispiel ist in der Praxis oftmals komplizierter. Denn um das Management der Hosts zu automatisieren, braucht es eine geeignete Quelle. Gibt es eine gut gepflegte CMDB (Configuration Management Database) oder Asset Management (oder wie auch immer es im jeweiligen Unternehmen genannt wird)? Perfekt! Eventuell stellst Du fest, dass die Datenqualität nicht so hoch ist, wie Du dies gerne hättest. Und auch hier kommen Modifikatoren zum Einsatz und schaffen Abhilfe. So können etwa alle Hostnamen zum FQDN ergänzt, die Schreibweise beispielsweise des Betriebssystems vereinheitlicht, die fehlende IP-Adresse durch DNS-Abfragen herausgefunden werden oder was sonst noch nötig ist.

Falls Daten fehlen, kannst Du sie aus einer anderen Quelle beziehen, denn viele weitere Module liefern Import-Quellen für den Director. Du kannst Dir etwa Systeminformationen aus dem Konfigurationsmanagement mit Hilfe der PuppetDB oder aus der zugrunde liegenden Plattform wie VMware vSphere oder AWS holen. Und der Vorteil ist: die Daten sind garantiert richtig! Sollten immer noch Daten fehlen, kannst Du diese mit einer eigenen Quelle anreichern. Vielleicht ist die Information schon in einem Excel-Dokument gepflegt oder Du kannst Dir schnell eine CSV-Datei bauen, denn beide Möglichkeiten bringt der Fileshipper. Letzteres nutze ich so regelmäßig, um Standortinformationen anzureichern, dass diese Option sogar als Beispiel in die Schulung Icinga 2 Advanced eingeflossen ist.

Je nachdem wie sehr man dem Automatismus dann vertraut, lässt der Director sich noch weiter automatisieren, so dass Import, Synchronisation und sogar das anschließende Deployment vollautomatisch passiert. Wer im Fehlerfall nicht nachts raus geklingelt werden möchte, kann auch gerne einstellen, dass dies nur während der Arbeitszeit passiert! 😉

Fazit

Mein Zwischenfazit hat ja bereits gezeigt, dass ich zum Director tendiere, selbst wenn es nur um manuelle Konfiguration geht. Aber auch wenn Importe natürlich individuell sind und man sich Konfigurationsdateien anders auch automatisch erstellen kann: hier trumpft der Director wirklich auf! Nicht nur der Workflow ist gut gedacht und vorbereitet, sondern durch die Möglichkeit mit weiteren spezialisierten Modulen, die Zahl der Importquellen und Modifikatoren zu erweitern. Das ist bei Bedarf sogar selbst in wenigen Zeilen zu erreichen. Damit wird der Icinga Director zum ganz klaren Sieger!

Falls Du Dir nun Hilfe bei der Einrichtung des Directors wünscht oder Unterstützung bei der Automatisierung suchst, aber auch wenn Du trotz meiner Ausführungen noch nicht entscheiden kannst, was für Dich der richtige Ansatz ist, melde Dich gerne! Ich oder ein:e Kolleg:in führen gerne eine individuelle Betrachtung zu Deiner IT-Umgebung und ihren Anforderungen durch. Im Rahmen eines solchen Consultingtermins erstellen wir Dir zunächst ein Konzept und können gerne auch direkt mit der Umsetzung beginnen.

Dirk Götz

Principal Consultant

---

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Lies mehr von Dirk und triff unser Team