NETWAYS Blog

Monitoring: alles ist geregelt. Aber!

von Thomas Gelf | Sep 7, 2018 | Icinga

Es könnte so einfach sein. Auf der einen Seite eine Reihe von Import- und Sync-Definitionen welche aus den unterschiedlichsten Quellen unsere zu überwachenden CI’s importieren. Excel, CMDB, Datenbanken, AWS, JSON, YAML, LDAP, VMware, Active Directory – alles geht. Quellen werden kombiniert, Daten angereichert und wo nötig geradegebogen. Egal wie mies die Daten sind, der Director wird’s schon richten.
Auf der anderen Seite stehen mächtige Apply-Regeln. Diese weisen regelbasiert aus einem liebevoll vorbereiteten Service-Katalog das zu was passt. Ausnahmen von der Regel sind knifflig, nämlich dann wenn wöchentlich jemand wieder einen Schwellwert anders haben möchte. Genau dort wo wir’s nicht bedacht haben, dort wo Konstrukte mit vars am Host schnell hässlich werden.

Auch hier hilft der Director, mit den „Custom Variable Overrides“ fühlt es sich so an als würde man wirklich diesem einen Service auf dem einen Host einen anderen Schwellwert verpassen. Alles gut soweit. Die Regeln sitzen, für Schwellwerte sind die Overrides da.

Nun ist unsere Welt aber leider nicht perfekt. Und das ist auch gut so, sonst wäre sie furchtbar langweilig. Für unsere Regeln bedeutet das leider, dass sie im Laufe der Zeit immer umfangreicher und komplizierter werden. Bis wir erneut an dem Punkt angelangen, an dem wir wieder am liebsten alles selbst machen würden. Wir haben nämlich Angst, dass es kaputt wird wenn es ein Kollege anpackt.
Klar, der Director hat ein wunderbares Aktivitätslog, man kann hinterher mit dem Finger auf eben diesen Kollegen zeigen und es heroisch selbst wieder geradebiegen. Ein Klick auf „Restore“ hilft dabei. Aber wenn man sich dann allein dadurch besser fühlt, dann hat man charakterlich durchaus noch Möglichkeiten an sich selbst zu arbeiten.
Zudem gab es vorher unnötigen Stress. Über zwei Wochen ist niemandem aufgefallen, dass die Checks für einen wichtigen Job auf ein paar Servern verschwunden sind. Am Wochenende ist das Ding an die Wand gerannt, das Monitoring blieb stumm. Bemerkt hat’s der Kunde, und wir mussten uns mal wieder so doofe Sprüche wie „Ja habt ihr denn kein Monitoring?“ anhören. Und alles nur, weil jemand mal wieder eine simple doppelte Verneinung falsch verstanden hat.
Mit dem Director v1.5.0 sind die häufigsten Ausnahmen von der Regel jetzt ein Kinderspiel. Man muss die Apply-Regel gar nicht mehr anfassen, einfach auf besagtem Host die Services anzeigen lassen, einen wählen, Blacklist, fertig:

Im Hintergrund rendert der Director passende Ignore-Regeln und alles ist gut. Man kann wieder einen Task mehr an seine Kollegen delegieren und sich um Wichtigere Dinge kümmern. Also den Raspberry der den Wasserstand der Kaffeemaschine im Auge behält. Was in der v1.5.0 sonst noch alles neu ist steht im Release-Blogpost des Icinga-Blogs.

Thomas Gelf

Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Lies mehr von Thomas und triff unser Team

Die Extrawurst

von Thomas Gelf | Mai 11, 2018 | Security, Icinga, PHP

Icinga Web 2 bietet eine Reihe von Möglichkeiten, Gruppen-Mitgliedschaften zuzuweisen. Am häufigsten werden Gruppenmitgliedschaften entweder via Web angelegt oder aus einem LDAP-Verzeichnis gezogen. Der bekannteste Vertreter dabei ist Microsofts Active Directory.
Weniger bekannt ist, dass man in eigenen Modulen Benutzer- sowie Gruppenmitgliedschafts-Backends bereitstellen kann. Manchmal braucht man aber gar nicht ein volles Backend, sondern nur ein paar kleine Korrekturen. Aus einem solchen Grund entstand diese Woche in einem Kundenprojekt ein neues Icinga Web 2 Modul: Extragroups.

Zusätzliche Gruppen für jeden

Einmal installiert, lassen sich in der config.ini des Moduls flexible Regeln definieren.
[Jeder ist ein Mimimi] add_groups = "Mimimi"
Das allein hat erst mal keinen Effekt, also hinterlegen wir in der /etc/icingaweb2/roles.ini eine Rolle, welche unseren Usern eine entsprechende Einschränkung verpasst:
[Mimimi Demo] groups = "Mimimi" monitoring/filter/objects = "host_name=*mi*"
Sobald wir uns neu anmelden sind wir Mitglied der Gruppe „Mimimi“ und sehen nur noch Hosts welche „mi“ enthalten. Dabei ist nebensächlich, ob eine Benutzergruppe namens „Mimimi“ existiert oder nicht.

Mustervergleich mit Benutzernamen

Lasst uns das Ganze ein wenig einschränken:
[Alle Heuler sollen Mimimis werden] user_filter = "username=*heul*" add_groups = "Mimimi"
Was hier passiert dürfte klar sein, wir machen nur noch unsere Heuler zu Mimimis.

Regeln basierend auf Umgebungsvariablen

Ihr möchtet alle Benutzer mit ein paar Ausnahmen in eine spezielle Gruppe geben, aber nur wenn diese remote arbeiten? Erstellt einfache eine auf deren IP-Range basierende Regel:
[Einschränkung wenn via VPN verbunden] env_filter = "REMOTE_ADDR=192.0.2.*" user_filter = "username!=tom&username!=admin" add_groups = "Via VPN verbunden"
Ähnlich wie REMOTE_ADDR in diesem Beispiel können alle vom Web-Server bereitgestellten Umgebungsvariablen benutzt werden. Im nächsten Beispiel zeigen wir Netzwerk-Admins welche via Nagstamon angemeldet sind lediglich wirklich wichtige Hosts und Services:
[Filter für Nagstamon] env_filter = "HTTP_USER_AGENT=Nagstamon*" user_filter = "group=Network Admin" add_groups = "VIP objects filter"
VORSICHT: Der User-Agent kann einfachst gefälscht werden. Dieses Beispiel dient dem Komfort unserer Benutzer: sie wollen in Nagstamon nicht mit allen Problemen belästigt werden. Für sicherheitskritische Regeln taugt der User-Agent nicht.

Mehrere Gruppen zuweisen

Manchmal will man mehrere Gruppen auf einmal zuweisen, ohne die ganze Regel zu klonen. Das lässt sich einfach bewerkstelligen, denn add_groups akzeptiert eine Komma-getrennte Liste:
[VPN-Benutzer einschränken] ; .. add_groups = "Eingeschränkte Benutzer, Spezielle Dashboards, Business-Prozesse"
Soll die Gruppenliste noch dynamischer sein? Vorausgesetzt dass ein Webserver-Modul oder dessen Konfiguration diese Information bereitstellt, lässt sich jede Umgebungsvariable via {VARIABLE_NAME} nutzen:
[Gruppen des SSO-Moduls zuweisen] add_groups = "{HTTP_AUTHZ_GROUPS}"
Auch in Strings die aus Umgebungsvariablen kommen funktioniert das Komma (,) als Trennzeichen. Und man kann natürlich Variablen-Platzhalter mit statischen Werten kombinieren:
[Eine Reihe von Gruppen] add_groups = "Spezial-Gruppe, {REMOTE_GROUPS}, {HTTP_AUTHZ_GROUPS}"

Auf Gruppenmitgliedschaften basierende Regeln

Der user_filter erlaubt auch Regeln basierend auf bereits zugewiesene Gruppen. In unserem umfangreicheren letzten Beispiel erhalten alle Benutzer zusätzliche Gruppenmitgliedschaften via HTTP_AUTHZ_GROUPS. Na gut, jeder außer der guest und der admin-Benutzer.
Wenn sie Nagstamon nutzen während sie via VPN verbunden sind, sollen sie zusätzlich in die Gruppe Nagstamon Remote kommen.
Wird Nagstamon ohne VPN benutzt, sollen Mitglieder der Gruppen „Linux Benutzer“ und/oder „Unix Benutzer“ in die Gruppe „Nagstamon Lokal“ kommen. Alle außer dem admin:
[Gruppen des SSO-Moduls zuweisen] add_groups = "{HTTP_AUTHZ_GROUPS}" user_filter = "user_name!=guest&username!=admin"
[Nagstamon via VPN] env_filter = "REMOTE_ADDR=192.0.2.*&HTTP_USER_AGENT=Nagstamon*" add_groups = "Nagstamon Remote"
[Nagstamon ohne VPN] env_filter = "REMOTE_ADDR!=192.0.2.*&HTTP_USER_AGENT=Nagstamon*" user_filter = "username!=admin&(group=Linux Benutzer|group=Unix Benutzer)" add_groups = "Nagstamon Local"
Dabei gilt es zu beachten, dass der Filter basierend auf die group-Eigenschaft nur Gruppen sieht, welche von vorhergehenden Regeln zugewiesen wurden. Von anderen Backends bereitgestellte Gruppenmitgliedschaften sind nicht zugänglich.
Das war’s auch schon, viel Spaß!

Thomas Gelf

Principal Consultant

Lies mehr von Thomas und triff unser Team

Der kleine Ping erkundet die Welt

von Thomas Gelf | Nov 17, 2017 | Icinga, Team, Network

Als der kleine Ping vor bald 34 Jahren geboren wurde, war die Welt noch übersichtlich und in Ordnung. Jeder kannte jeden und man lernte schnell neue Freunde kennen. Diese Freunde bleiben einem dann häufig auch lange treu. Ein offenherziger Kerl wie der kleine Ping lernte damals sehr schnell sehr viele Freunde kennen.
Gut erzogen und treu wie er war, besuchte er die meisten davon immer wieder und wieder. War jemand krank, dann war Ping schon mal länger unterwegs oder kam gar nicht mehr zurück. Aber langsam von vorn.
Seinen Namen bekam der kleine Ping vermutlich, weil sein Vater Mike zu viele Kriegsfilme im Fernsehen schaute. Oder weil seine Arbeit bei der US Army ihn so faszinierte. Ping, so hört sich nämlich der Sonar ein einem U-Boot an. Wie ein Klopfen. Irgendwie fanden seine Eltern das wohl sehr spannend. Also die Tatsache dass da Schallsignale gesendet und wieder zurück reflektiert wurden.
Das wäre doch auch ein schöner Job für unseren Ping, dachten sie. Also wurde der kleine Ping schon sehr früh losgeschickt, um unsere Welt zu erkunden. Da war er noch ganz klein, gerade mal 1000 Zeilen hoch. Dennoch fühlte er sich wie ein ganz Großer. Ständig auf Reisen kannte er sehr bald jede Straße, jede Autobahn und jeden Weg wie seine Westentasche. Das fand er unglaublich spannend.
Sein Vater war aber sehr streng. Jedesmal wenn Ping das Haus verließ notierte er auf die Millisekunde genau, wie spät es war. Und als der Ping dann wieder zurückkam, wurde auch das notiert. Aus Start- und Endzeit errechnete sein Vater dann, wie lange der kleine Ping unterwegs war.
Als der kleine Ping älter wurde, machte er sein Hobby zum Beruf. Wenn jemand wissen wollte, wie lang man auf einer Strecke unterwegs war, dann ging er zum kleinen Ping. Wollte ein LKW-Fahrer wissen, ob sein fetter Brummi unter einer Brücke Platz hätte – unser Ping konnte das klären.
Manchmal war es freilich ein wenig langweilig. Als Berufspendler war er hauptsächlich auf immer denselben Strecken unterwegs. Zu den Stoßzeiten im Stau zu sein war auch kein Vergnügen. Ping nahm sich dann ab und an andere Texte zum Lesen mit, das sorgte für gute Unterhaltung. Sein Vater prüfte übrigens immer, ob er auch wirklich mit denselben Texten wieder nach Hause kam. Fehlten Buchstaben oder waren falsche dabei, dann ließ er ihn unter Umständen gar nicht mehr ins Haus. Ping musste dann auf der Straße übernachten.
Ab und an erlaubte Ping sich einen Spaß. Da packte er ein Vielfaches an Ladung drauf um zu sehen, ob auch wirklich alle Tunnel-Decken und Brücken hoch genug waren. Er war halt so ein richtig nerviger Besserwisser. Und ab und an krachte es dabei natürlich ganz heftig. Ping bekam dann aber nicht etwa Stress. Das lief dann einfach als „Prüfung des Maximalen Tunnel Umfangs“, kurz MTU-Test. Ping hatte seinen Spaß – und die Polizei war froh, dass sie von jemandem auf Verletzungen der Bauvorschriften hingewiesen wurden.
Die richtig wichtigen Jobs bekamen andere. Einige seiner Brüder arbeiteten bei der Polizei, das hätte dem kleinen Ping gefallen. Bei welcher Einheit wäre ihm egal gewesen, zur Not auch bei den lahmen Kerlen von der „Ruhigen Inneren Polizei“, dem RIP. Das sind die Verkehrspolizisten in den kleinen Käffern auf dem Land.
Im Grunde machten die nicht viel mehr als die Leute nach links und rechts zu dirigieren. Aber dennoch. Betrachtete man das Geschehen vom Kirchturm aus, dann sah das schon beeindruckend aus. Alles floss schön links und rechts an den Polizisten vorbei – genau wie die sich das gerade so vorstellten. Ganz großes Kino!
Die richtig coolen Jungs hingegen arbeiteten bei der „Beindruckend Großen Polizei“, dem BGP. Das ist die Autobahnpolizei, irre was bei denen abging. Schon bei der Aufnahmeprüfung musste jeder von denen ein paar hunderttausend Routen im Kopf haben. Das klang irre anspruchsvoll und stressig. So weit wollte der kleine Ping dann doch nicht hinaus. Aber ab und an davon zu träumen, das war schon schön.
Der kleine Ping war zufrieden mit seinem Job. Er war es, der dieses Berufsbild erfunden und geformt hatte. Tausende hatten es ihm im Laufe der Jahre nachgemacht. Und heute ist er nicht zuletzt wichtiger Bestandteil einer jeden Monitoring-Umgebung. Auch wir haben kaum irgendwo eine Icinga-Umgebung am Laufen, in welchem er nicht zuverlässig seinen Dienst verrichten würden. Darum sei ihm an dieser Stelle mal ein Lob ausgesprochen: er macht seinen Job ausgezeichnet, ist zuverlässig und unauffällig.
Weiter so, lieber kleiner Ping!

Thomas Gelf

Principal Consultant

Lies mehr von Thomas und triff unser Team

Was gibt's Neues vom Director?

von Thomas Gelf | Jul 28, 2017 | Icinga

Gleich zwei neue Releases stehen an, und während die v1.3.2 bereits vor einer Woche inoffiziell getagged wurde, werden bei der v1.4.0 gerade noch die letzten Kanten rund geschliffen. Wenn nichts dazwischen kommt werden dann Anfang nächster Woche beide gemeinsam offiziell angekündigt werden.

Director v1.4.0 Dashboard

Warum aber gleich zwei Releases auf einmal?

Director v1.4.0 versucht zwar, optisch möglichst nah an seinem Vorgänger zu bleiben, ist aber unter der Haube in großen Teilen komplett neu. In diesem Zuge haben wir die System-Anforderungen minimal erhöht, PHP 5.4 anstelle von PHP 5.3 ist jetzt vonnöten. Wer beste Performance und minimalen Ressourcenverbrauch schätzt, sollte auf 7.x wechseln.

Property Modifier „Combine“

PHP 5.4 sollte in allen aktiv von uns unterstützten Linux-Distributionen verfügbar sein, lediglich Nutzer von RHEL/CentOS 6.x müssten deren Konfiguration auf die in den offiziellen SCLs (Software Collections) vorhandenen Pakete umstellen. Das Standardverhalten beim Packaging von Icinga Web 2 werden wir vermutlich heuer noch entsprechend umbauen.

Property Modifier „Array Filter“

Für all jene, die jetzt auf die Schnelle nicht umstellen können/wollen ist die neue Version 1.3.2 gedacht. Diese enthält eine ganze Menge kleinerer und größerer Bugfixes, welche seit der 1.3.1 entstanden sind. Zudem haben wir ein paar neue nützliche Import Property Modifier einfließen lassen. Da sie am bestehenden Verhalten nichts ändern, durften sie gemeinsam mit ein paar neuen CLI-Befehlen mit in dieses Patch-Release:

Einfachere Suche, flexiblere Tabellen

Sämtliche Tabellen unterstützen intern zwar weiterhin unsere mächtigen Filter-Funktionen, stellen in der GUI aber vorerst nur noch ein einfaches Suchfeld bereit. Einfach testen, mehrere Wörter kombinieren, auch wenn diese in unterschiedlichen Spalten stecken – es sollte ziemlich intuitiv sein.
Beim Umbau der Tabellen sind neue generische Features entstanden. So konnten wir ohne großen Aufwand an mehreren Stellen historische Darstellungen säuberlich nach Tagen getrennt übersichtlicher gestalten.

Historie der Deployment

Template Choices

Der Director trennt strikt zwischen Objekten und Templates und erlaubt bestimmte Optionen nur an Templates. Das hat einen einfachen Grund: Templates sollen von Icinga-Admins betreut werden, „normale“ Objekte (also Hosts und Services) sollen aber durchaus Systembetreuer nutzen dürfen, die sich nicht täglich um’s Monitoring kümmern. Alles was potentiell „gefährlich“ sein kann wird aus dem Grund dort nicht angeboten.

Host Template Choices: Dashboard, Tabelle

Nun ist es aber nicht gerade intuitiv, bei jedem zweiten Host zusätzlich ein Template namens „Schnelle Checks“ einzubinden. Also erstellt man sich jetzt sogenannte Choices, gibt denen einen schönen Namen – und bietet sie auf diese Weise elegant im Formular an.

Template Choices in Aktion

Schnelleres Arbeiten mit einzelnen Services

Die letzten Director-Releases kamen mit so einigen neuen Tricks. Gerade die „Variable Overrides“ werden gern genutzt. Sie erlauben das Ändern von Schwellwerten für einzelne Hosts auch dann, wenn der zugehörige Service eigentlich via Apply-Rule erstellt wird.

Mehrere Services auswählen

Die Version 1.4.0 legt jetzt den Fokus auf schnelleres Arbeiten mit einzelnen Services. Neu ist eine Übersicht aller Einzel-Services auf allen Hosts. Von hier kann man mit SHIFT/STRG-Klick mehrere Services auswählen und gemeinsam anpassen. Oder löschen. Selbiges geht auch in die andere Richtung bei den Hosts: mehrere auswählen, Service oder Service Set hinzufügen, wählen, speichern:

Mehrere Services auf einmal bearbeiten

Autocompletion

Neu an Board ist endlich ein Mechanismus zur Autovervollständigung. Dieser hat bereits so einige Dropdownfelder abgelöst und wird in Zukunft noch intensiv für weitere Aufgaben genutzt werden.

Autovervollständigung

Gerade Formulare welche potentiell viele Objekte verknüpfen müssen, können wir damit jetzt schonend für den Browser umsetzen. Dependencies, Ein Punkt der schon lange auf der Wunschliste steht, kommen damit jetzt in Reichweite!

Neue Dashboards und Dashlets

Wie schon der Screenshot eingangs gezeigt hat: das Dashboard wurde umgestaltet und aufgeräumt. Die Tabs passen zu den Dashlets, wenn man umschaltet wird optisch hervorgehoben, wo man sich befindet. Aber nicht nur das, es kamen viele neue Unter-Dashboards hinzu. Und, neu in Kombination mit den Tabs: im Zweispalten-Modus macht ein Doppelklick auf den Tab-Titel jetzt die aktuelle Spalte „groß“.

Mobiles Director Dashboard

Das Layout wurde übrigens für breitere Bildschirme auf ein 50/50 Spaltenverhältnis umgestellt, statt wie bisher 33/66. Sehr viele Verbesserungen gab es auch beim mobilen Layout. Dashboards sind dort jetzt angenehmer und auch die Formulare wurden für mobile Nutzung optimiert:

Formulare – mobile

Vererbung ist alles

Bugs im Template-Baum wurden gefixt, und ganz neu ist eine Übersicht welche die Nutzung von Templates anzeigt:

Template-Baum

Zudem werden Apply-Regeln für Hostgruppen jetzt voll aufgelöst und Gruppenmitglieder sowie der Typ der Mitgliedschaft (direkt oder via Apply) werden angezeigt.

Benutzung von Templates

Berechtigungen

Damit wären wir auch schon beim nächsten Thema. Das Auflösen von Vererbung und Apply-Regeln erlaubt uns jetzt endlich, entsprechende Restrictions freizugeben. Begonnen haben wir mit dem was einige unserer Kunden am dringendsten benötigt hatten. Hostgruppen, unterschiedliche Prefix-basierte Filter, sogar einzelne Einträge in Data Lists können jetzt nur für bestimmte Rollen freigegeben werden.

Genutzte Custom Variablen

Eher an Admins richtet sich ein neues Feature, das eine Übersicht aller benutzten Custom Variablen und deren Varianten anzeigen kann:

Übersicht Custom-Variablen

Genutzte Varianten einer bestimmten Variable

An dieser Stelle möchten wir in Zukunft noch die Möglichkeit anbieten, gleich an Ort und Stelle umfangreiche Massen-Changes und Aufräumarbeiten vornehmen zu können.
Stark überarbeitet wurde übrigens auch die Inspect-Funktionalität. Wer tiefer in den Core blicken möchte findet dort jetzt detaillierte Informationen zu den verfügbaren Eigenschaften und Methoden der unterschiedlichen Objekt-Typen. Auch der aktuelle Status der einzelnen Komponenten lässt sich abrufen, wenn auch noch nicht sehr schön formatiert.

VMware vSphere/ESXi Import

Diese Funktionalität wurde im Kundenauftrag als dediziertes Icinga Web 2 Modul entwickelt. Vorerst stellt es „nur“ eine Import-Quelle für den Icinga-Director bereit. Wir haben damit aber noch so einiges vor. So möchten wir das Modul so aufbohren, dass es in einem kleinen eigenen DB-Schema ein Subset der in vSphere verfügbaren Informationen vorhält und ständig aktuell hält.

VMware vSphere Import

Festhalten wollen wir vor allem:

Welche VM mit welchen Eigenschaften seit wann wo läuft
Eine Historie der Migrationen
Ein paar wenige aggregierte aktuell Kennzahlen/Performancewerte

Diese Informationen möchten wir dann gleich mehrfach nutzen:

Für schnellere und schonendere Check-Plugins, da diese darauf verzichten können bei jedem Aufruf mit teuren API-Abfragen die benötigten Komponenten zu suchen
Für ein kleines Visualisierungsmodul
Um Zusatz-Informationen via Hook anderen Modulen in Icinga Web 2 bereitzustellen, in erste Linie natürlich dem zentralen Monitoring-Modul.

Bei der Entwicklung wurde auf sämtliche SDKs von VMware verzichtet. Mit selbigen hatten wir bisher keine guten Erfahrungen gesammelt. Probleme beim Upgrade, Inkompatibilitäten anderen Bibliotheken und/oder je nach Sprache auch einfach vollständiger Entwicklungsstillstand machten das Leben schwer.
Bei diesem Modul sind wir jetzt einen anderen Weg gegangen und nutzen zu 100% eigenem Code. Der deckt natürlich nicht die volle API ab – aber all das was wir brauchen. Damit fällt einiges an Overhead weg, und wir haben bei Bedarf die Möglichkeit viel flexibler auf Inkonsistenzen bei neuen Releases reagieren zu können. Wir sprechen direkt mit der SOAP-Schnittstelle und schaffen es damit, einen ziemlich breiten Bereich von vSphere- und ESXi-Versionen abdecken zu können. Für Nutzer des Moduls heißt das: runterladen, aktivieren, loslegen.
Es wird jedenfalls nicht langweilig. Und in diesem Sinne wünsche ich schon mal ein schönes Wochenende!

Thomas Gelf

Principal Consultant

Lies mehr von Thomas und triff unser Team

Icinga Director 1.2.0 veröffentlicht

von Thomas Gelf | Nov 4, 2016 | Icinga

Gerade mal 4 Monate sind seit eploer 1.1.0 vergangen, und wenig mehr als 7 Monate seit unserer ersten stabilen Release. Der Icinga Director reifte schnell, und aus einem kleinen Icinga Web 2 Modul ist mittlerweile ein ziemlich großes Projekt erwachsen. Gestern haben wir die Version 1.2.0 freigegeben, vollgestopft mit neuen Features, Bugfixes und Usability-Verbesserungen.

Berechtigungen

Dies ist die erste Release mit offizieller Unterstützung für Berechtigungen. Die Aufgabe eines Icinga-Administrator ist es, Commands, Service- und Host-Vorlagen zu definieren und eventuell alle Schritte von Import/Sync bis zum Deployment der Konfiguration zu automatisieren. Hier setzt der Director an, er ist zuallererst ein mächtiges Automatisierungstool.
Viele wenn nicht gar die meisten Umgebungen haben aber dennoch immer noch so einige Aufgaben die sich schwer automatisieren lassen. Wer kennt nicht den Mitarbeiter der sich zweimal am Tag umentscheidet, ob den nun der Schwellwert für seine seit Monaten volle Platte bei 99,9 oder doch besser bei 99,8% liegen soll. Stehen gerade 3000 neue Router an, die (nachdem jeweils ein Ticket erstellt wurde) im Laufe der nächsten Monate überwacht werden sollen? Diese Aufgaben sind prädestiniert dafür, an andere delegiert zu werden!

Konfigurationsvorschau, Core API inspection oder das Auditlog können sensible Informationen beinhalten. Solcherlei Berechtigungen gibt man also besser nur denen, die sie wirklich brauchen. Soll ein Auditor alle Änderungen sehen aber keinen administrativen Zugang erhalten? Auch das ist jetzt möglich. Alle Aktivitäten lassen sich jetzt außerdem zusätzlich ins Syslog schreiben, für den Fall dass man es anderweitig archivieren möchte.

Performance

Das Rendern der Konfiguration wurde enorm beschleunigt. In großen Live-Umgebungen benötigt das Deployment nur noch ein Fünftel der ursprünglichen Zeit. Eine mir bekannte Umgebung konnte heute übrigens ihr tausendstes (automatisiertes) Director-basiertes Deployment feiern. Das Ganze bei mehr als einer halben Million Einzeländerungen im Aktivitätslog.

Konfigurationsmöglichkeiten

Es ist jetzt möglich tief verschachtelte Assign-Regeln zu definieren, basierend auf allen Host- und/oder Service-Eigenschaften. Wer das „apply for“ Feature von Icinga 2 vermisst hat darf sich jetzt auch freuen. Ein Team von Internap hat einen Großteils des Codes dafür beigetragen. Bei dieser Gelegenheit herzlichen Dank für die gute Arbeit!
Die Unterstützung für Icinga 2 DSL in Command-Definitionen wurde verbessert. Ein Blick auf die Screenshots im Support-Ticket #12928 gibt einen kleinen Eindruck von den schrägen Möglichkeiten, die sich dadurch ergeben. Ein paar versteckte Features wie die implizite Unterstützung von skip_key fanden ebenfalls ihren Weg in die neue Version.

Wolltest Du immer schon eine bestimmte Eigenschaft eines von einem Host-Template geerbten Services für nur einen Host überschreiben? Dies und ähnliche Features sind jetzt verfügbar!

Automatisierung

Beim Arbeiten mit der Import/Sync-Funktionalität lassen sich viele kleine Verbesserungen entdecken. Es gibt neue „Property-Modifier“, und deren Ergebnis lässt sich jetzt auch dafür verwenden neue virtuelle Eigenschaften zu erstellen. Wer mit Datenfeldern arbeitet wird neben Usability-Verbesserungen die Möglichkeit entdecken, andere Objekte in einer Dropdown-Liste bereitzustellen und als String oder Array in Custom-Variablen zu nutzen.

Testing

Immer mehr Entwickler tragen Quellcode zum Icinga Director bei. Um den Einstieg zu erleichtern haben wir das Bootstrapping unserer Unit-Tests vereinfacht und entsprechende Dokumentation bereitgestellt.

GUI und Usability

Die Fehlerbehandlung in den Formularen wurde stark verbessert, eventuelle Exceptions werden an vielen Stellen gefangen und auf lesbare Weise dargestellt. Der Deployment-Button ist jetzt nicht mehr so versteckt, die Konfigurationsvorschau wurde verbessert und erlaubt jetzt vollständige Konfigurations-Diffs auch vor dem Ausrollen einer neuen Konfiguration.

Loops bei der Vererbung werden jetzt freundlich dargestellt und lassen sich direkt im Frontend beheben. Ein verstecktes Juwel ist die „Multi-Edit“-Funktionalität. Mit SHIFT/ALT+Klick lassen sich mehrere Hosts auswählen. Deren Imports, Custom-Variablen und andere Eigenschaften lassen sich an dieser Stelle für alle ausgewählten Objekte auf einmal ändern. Fehler oder Warnungen in allen historischen Startup-Logs verlinken jetzt direkt zur entsprechenden Konfigurationsdatei und springen an die richtige Zeile.