Icinga: Installer, Diagnostics, Support Collector

Beim letzten Mal habe ich über Troubleshooting, Debugging und Performance innerhalb von Icinga for Windows geredet und heute wird das Ganze mal etwas Allgemeiner für Icinga und zwar ein paar Projekte, die dem ein oder anderen gar nicht bekannt sind, beziehungsweise deren Nützlichkeit in Hinsicht auf Informationsbeschaffung und Testen, was fürs Troubleshooting und Debugging auch nicht gerade unwichtig ist.

Icinga Installer

Zum einen wäre da der Icinga Installer, welcher eine exzellente Möglichkeit darstellt, schnell und einfach eine Icinga-Instanz zum Laufen zu bringen. Entsprechend einfach ist es auch, sich schnell mit ein oder zwei virtuellen Maschinen eine Icinga-Testumgebung zu zaubern, ohne viel Zeit in Konfigurationsdateien zu verbringen.

Hierbei bietet der Icinga-Installer unterschiedliche Installations-Szenarien an. Respektive ‘server-ido-mysql’ & ‘server-ido-pgsql’ für Icinga-Master; ‘worker’ für Icinga-Satelliten; und ‘agent’ für Icinga-Agenten.

Die Installation des Icinga-Installers ist ebenso denkbar simpel, da dieser im NETWAYS Packages Repository enthalten ist. Einfach das entsprechende Repository hinzufügen und daraufhin mit dem Paketmanager der Wahl installieren. Mehr dazu ist auch hier zu finden: https://github.com/NETWAYS/icinga-installer

Darüber hinaus kann der Installer auch im produktiven Betrieb zum Konfigurationsmanagement eingesetzt werden.

Icinga 2 diagnostics

Bei Icinga 2 diagnostics handelt es sich, um ein Bash-Script, das Daten der Umgebung sammelt und gegebenenfalls Anomalien entdeckt. Eigentlich ist das Skript zwar dafür gedacht, dass Daten gesammelt werden können, um diese mit entsprechenden Kanälen zu teilen, aber im Zweifelsfall kann es durchaus auch aufschlussreich sein, um einen simplen Fehler zu finden. Und das Skript findet ihr hier: https://github.com/Icinga/icinga2-diagnostics

Aber Vorsicht beim Teilen der Umgebungsinformationen in der Community. Immerhin enthält dieser mitunter auch Passwörter.

Support Collector

Wenn man schon Icinga 2 diagnostics erwähnt, dann kann man da genauso gut auch noch den Support Collector, welcher im eigenen NETWAYS Supports Anwendung findet, erwähnen. Dieses Projekt ist hier Zuhause: https://github.com/NETWAYS/support-collector

Genauso wie Icinga2 diagnostics ist auch der Support Collector eine gute Wahl um Konfiguration zu prüfen und erinnert vor allem den Laien daran, welche Datei dieser noch vergessen hat. Auch hier ist wieder Vorsicht geboten, die gesammelten Daten zu teilen, immerhin sind auch hier Passwörter enthalten.

Was noch?

An der Stelle ist final noch anzumerken, wie hilfreich es ist, sich Backups von Konfigurationen der Umgebung zu machen. Hierzu sollte man natürlich manuell und kontrolliert Backups anfertigen und weder Icinga2 diagnostics noch den Support Collector als Alternative betrachten, aber gelegentlich einen Abzug der Umgebung zu haben durch eines der beiden Tools ist schon praktisch. Auch der Installer kann zur Sicherung der Konfiguration und deren Wiederherstellung genutzt werden.

Es ist nicht selten der Fall, dass man glaubt, man hätte gar nichts geändert und ein diff zwischen der aktuellen zones.conf und der aus dem Support-Collector vor drei Wochen behauptet das Gegenteil.

Und eine entsprechende Testumgebung, die mit dem Icinga-Installer binnen 10 Minuten stehen könnte, gibt einen die Möglichkeit neue Konfiguration vorher an anderer Stelle als der Produktivumgebung zu testen, beziehungsweise die Möglichkeit Fehler nachzustellen und somit fehlerhafte Konfiguration zu identifizieren. Oder um es anders auszudrücken, ein Fehler ist einfacher zu beheben, wenn man klar weiß, wie er entstanden ist.

Und wenn dann der Fehler noch immer nicht gefunden ist, dann bleibt einem noch die Community oder NETWAYS Support, um dem Problem auf die Spur zu kommen.

Alexander Stoll

Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Lies mehr von Alexander und triff unser Team

Liebes Icinga 2, sag "Aaaaaah"

Die meisten, die schon mal ein Support Ticket aufgemacht haben, kennen das:
„Hallo, ich hab‘ ein Problem, weil blah blubb.“
„Hi, das ist schade. Ich hab‘ hier ein paar Seiten Doku über Euer Setup. Ist das noch aktuell?“
Und erst dann geht’s los mit der eigentlichen Fehlersuche. Das hat vor allem den Hintergrund, dass viele unserer Kunden sehr unterschiedliche Ansätze haben, wie sie ihr Setup betreuen und mit uns zusammenarbeiten. Manche kontaktieren uns nur im Notfall, andere nehmen nur grössere Umbauten mit uns gemeinsam vor und pflegen alles andere selbst und wieder andere lassen alles von uns machen. Deshalb kommt auch immer erst die Frage, ob sich nicht vielleicht was geändert hat, was natürlich völlig ok ist, nur wissen muss man es für den Support.
Oder man stellt eine Frage im Monitoringportal. Dann kommt da auch gern mal: „Sag erstmal, was für ein Setup Du hast.“
Und genau für diese Fälle gibt’s jetzt (oder eher demnächst) das „Icinga 2 Diagnostics Script“. Das Script soll zwei Anwendungsfälle haben:

Einen ersten Überblick über die Eckdaten einer Installation
Eine umfassende Datensammlung um alle Feinheiten abzuklopfen

Dabei liegt der Fokus klar auf der ersten Anwendung. Icinga und die damit verbundenen Tools haben eine unglaubliche Flexibilität und können auf so viele unterschiedliche Arten verwendet und konfiguriert werden, dass es oft ziemlich aufwändig sein kann, einen ersten Überblick zu erhalten. Deshalb soll das Script einen nicht gleich mit Unmengen an Information überwältigen, sondern sie sinnvoll und übersichtlich aufbereiten. Dazu probiert es meist verschiedene Befehle durch, die einem Betriebssystem Informationen entlocken können und listet die Ausgabe dann entsprechend aufbereitet auf.
Der andere Modus sammelt so viele Informationen wie er nur kann, inklusive Logfiles, Konfiguration, Datenbankdumps, etc. Weil diese Daten manchmal Informationen enthalten, die man nicht rausgeben darf oder will, ist das nicht der Default Modus.
Egal, welchen Modus man verwendet, das Script sammelt die Daten und legt sie auf dem Host ab, der sie eingesammelt hat. Es gibt also keinen versteckten „Phone-Home“ Mechanismus oder eine „praktische“ Verschlüsselung, die nur verschlüsselte Daten zurücklässt, sodass der User nicht sieht, was er da verschickt. Auch ein Ändern der Daten ist vor dem Versand natürlich möglich, um z.B. Passwörter zu entfernen.
Ein Wunschtraum für die Zukunft wäre, dass das Script im Überblicksmodus auch auf ungewöhnliche Dinge prüft und nur meldet, wenn es etwas Erwähnenswertes gefunden hat. Also z.B. wenn eine Datenbank nicht dem Schema entspricht, das mitgeliefert wird – entspricht es, gibt’s aber keinen „Ok“ Eintrag, um die Übersicht nicht zu beeinträchtigen.
Das Script ist aktuell noch auf dem Stand eines schnellen Hacks, der nach einem Dokumentationstermin bei einem Kunden entstanden ist. Ich habe damals versucht, die relevantesten Eckdaten des Setups zu dokumentieren und mir notiert, welche Befehle ich benutzt habe. Das wurde noch etwas erweitert (Danke Dirk, für die vielen guten Ideen) und einige davon in ein Script gegossen. Wie wahrscheinlich die meisten, die selber Projekte laufen haben, bin ich noch höchst unzufrieden mit dem Funktionsumfang, dem Errorhandling, dem Scripting-Stil, usw. Da ich aber nicht wieder ewig warten will, bis ich doch mal Zeit finde, daran weiter zu schrauben, folge ich der Empfehlung meiner Kollegen und mache ein offizielles Icinga-Projekt daraus. Das motiviert mich erstens sicherlich dazu, eher weiter zu arbeiten und andererseits, wird so wohl eher auch mal jemand den ein oder anderen Pull-Request schicken. Bitte habt aber Verständnis dafür, dass der Fokus darauf bleibt, den Output übersichtlich zu halten.
Inzwischen befindet sich das Script schon in einem GitHub Repo im Icinga Bereich. Wer es testen möchte, Ideen dafür hat oder auch mitarbeiten möchte, findet dort alles Nötige.

Thomas Widhalm

Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Lies mehr von Thomas und triff unser Team