Open Source Monitoring Conference 2017 – Stay tuned!

OSMC 2017 | The worldwide leading conference on open source monitoring solutions
November 21 to 24 | Nuremberg

In 10 parts of this series, we will give you some valuable information about the conference as well as some impressions of the last years.

What is the OSMC about?
The bilingual conference focuses on the latest trends and developments on open source monitoring solutions and offers a unique opportunity to meet the open source community
and to gain valuable expertise. The thematic focus is broadly diversified and equally suited for beginners and advanced users.

What makes the OSMC unique?
The conference offers Interesting talks with a real benefit for the attendees, as well as hands-on workshops to expand your knowledge and monitoring know- how.
Due to the great success in the past two years, we are again offering a hackathon, which is bookable as an add-on.

We’re very excited and would be happy to welcome you to Nuremberg in November!

And now, have a look at this high class talk of the Icinga Team!

 

Julia Hackbarth

Autor: Julia Hackbarth

Julia hat 2017 ihre Ausbildung zum Office Manager bei NETWAYS absolviert und währenddessen das Events&Marketing Team kennen und lieben gelernt. Besondere Freude bereiten ihr bei NETWAYS die tolle Teamarbeit und vielseitige Herausforderungen. Privat nutzt Julia ihre freie Zeit, um so oft wie möglich über's Handballfeld zu flitzen und sich auszutoben. In ihrer neuen Rolle als Marketing Managerin freut sie sich auf spannende Aufgaben und hofft, dass ihr die Ideen für kreative Texte nicht so schnell ausgehen.

Icinga 2 Best Practice Teil 6: Service-Checks auf Agenten schedulen

This entry is part 6 of 6 in the series Icinga 2 Best Practice

In Teil 1 dieser Blogserien beschäftigten wir uns mit Zonen, Agenten und wie man zentral angetriggert Plugins auf diesen Agenten ausführt. Nun im aktuellen Teil soll es darum gehen, das einplanen und ausführen dem Agenten selbst zu überlassen, damit werden auch während eines Verbindungsausfalls weiter Daten gesammelt und später, wenn die Verbindung wieder besteht, nachträglich übertragen.

In dem hier folgenden verdeutlichen wir, wie dies zu konfigurieren ist, mit einem Beispiel von einer Zone master, einer globalen Zone global-templates und einer Zone zu einem Beispiel Agenten agent.example.org.

Die Zonen- und Endpoint-Definitionen des Agenten auf Seite des Masters müssen in einer Datei in der Master-Zone oder in zones.conf hinterlegt werden. Leider ist es hier nicht möglich die jeweiligen Host-, Zonen- und Endpoint-Objekte in einer Datei zusammen zufassen, da wir das Host-Objekt agent.example.org zum Agenten selbst synchronisieren müssen und diese Definition in der Agenten-Zone abgelegt sein muss, z.B. in der Datei zones.d/agent.example.org/agent.conf:

object Host "agent.example.org“ {
 import "generic-host"

 address = "10.0.10.42"
 zone = get_object(Zone, name).parent

 vars.os = "Linux“
}

Durch die Ablage an genau diesem Ort, wird das Objekt zum Agenten synchronisiert. Mit setzen des Attributes zone auf die eigene Parent-Zone sorgen wir jedoch wieder dafür, dass das Host-CheckCommand sowie alle an diesen Host gebundenen Services auf einem Endpoint der Parent-Zone ausgeführt werden, hier die Zone master.

Damit wird der hostalive vom Master ausgeführt, was gewünscht ist, da sonst der Host seine Erreichbarkeit von sich selbst aus testen würde. D.h. alle Services, die auf den Agenten über das Netzwerk zugreifen sollen, bleiben wie sie sind und wir müssen keine Anpassungen vornehmen. Ganz im Gegensatz zu Services, die ein Plugin lokal auf dem Agenten ausführen sollen.

apply Service "load“ {
 import "generic-service“

 check_command = "load“
 if ( get_object(Zone, host.name) ) {
   zone = host.name
 }

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

Auch Objekte vom Typ Service besitzen das Attribut zone mit dem wir hier nun die umgekehrten Weg beschreiten, existiert zum Host eine Zone selben Namens, wird die Zone zur Ausführung des zugeordneten Plugins in die eigene Agenten-Zone verlegt.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Github Topics – Ein kleiner Blick in die Zukunft

Wir sind seit einiger Zeit damit beschäftigt, Icinga Exchange in neuem Licht erstrahlen zu lassen. Neben einem neuen Design wird es allerdings auch einige andere Änderungen und Neuerungen geben.

Eine dieser Neuerungen wird eine stärkere Github Integration sein. Wir werden unter anderem die bisher notwendige yaml Datei ablösen, indem wir Details über von Github synchronisierte Projekte über die API von Github abrufen. Dabei ist uns eine neue Funktion von Github ins Auge gefallen: Topics.

Diese ist seit Anfang des Jahres verfügbar und erlaubt es einem Repository bestimmte Begriffe zuzuordnen, ganz ähnlich den auf Icinga Exchange bekannten Tags. Mit der üblichen URL um Details zu einem Repository abzurufen wird man jedoch nicht fündig:

https://api.github.com/repos/<owner>/<repository>

Aktuell fand diese Funktion noch keinen Einzug in die offizielle API. Stattdessen muss man explizit angeben, eine bestimmte preview Version der API benutzen zu wollen, damit zugeordnete Topics in den Details ebenfalls erscheinen.

Dies erreicht man bei Github mit bestimmten media types im Accept header:

Accept:application/vnd.github[.version].param[+json]

(Alle preview Versionen gibt es hier)

Um also über die API auf die Topics zuzugreifen, wird folgender media type benötigt:

Accept:application/vnd.github.mercy-preview

In der Antwort der API erscheint daraufhin ein neuer Eintrag:

{
  ...
  "topics": [
    "exchange",
    "icinga",
    "snmp"
  ],
  ...
}

Weil diese Funktion aber noch nicht Bestandteil der offiziellen API ist, werden wir vermutlich vorerst davon absehen diese in Icinga Exchange zu benutzen. Wir hoffen jedoch, dass sie bald Bestandteil der offiziellen wird oder absehbar ist, dass sie es sicher werden wird.

Ach, bevor Ihr fragt: Nein, wir haben noch keinen Release Zeitpunkt für die neue Version von Icinga Exchange. Aber vermutlich noch dieses Jahr. 😛

Johannes Meyer

Autor: Johannes Meyer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.

Was gibt’s Neues vom Director?

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

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"

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"

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.

Director Deployment History

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, Table

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 Choice in Action

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

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

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

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

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

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

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

Übersicht Custom-Variablen

Genutzte Varianten einer bestimmten Variable

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

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

Autor: Thomas Gelf

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.

Icinga Web 2 Modul fileshipper imports im Director

Es werden viele Importe im Icinga Web 2 Modul Director via Ldap / SQL-Ressource getätigt, aber viele übesehen eine einfache Möglichkeit bestehende Dateien mittels Icinga 2 Modul “fileshipper” in den Icinga Web 2 Director zu importieren. Wie man dieses umsetzt werde ich an einem einfachen Beispiel, einer CSV-Datei hier beschreiben.

Zuerst muss man sich das Fileshipper-Modul von Github per “git clone” oder .zip-Datei herunterladen und in dem Verzeichnis '/usr/share/icingaweb2/modules/' ablegen und anschießend das Verzeichnis in “fileshipper” umbennen, denn sonst erkennt es Icinga Web 2 als Modul nicht an.
# cd /usr/share/icingaweb2/modules/ && git clone https://github.com/Icinga/icingaweb2-module-fileshipper.git
oder
# cd /usr/share/icingaweb2/modules/ && unzip master.zip

Anschließend muss das neu installierte Modul noch aktiviert werden,  mit dem icingacli Kommando:
# icingacli module enable fileshipper
icingacli module list
MODULE VERSION STATE DESCRIPTION
director 1.3.1 enabled Director - Config tool for Icinga 2
doc 2.4.1 enabled Documentation module
fileshipper 1.0.0 enabled Fileshipper for Icinga Director
monitoring 2.4.1 enabled Icinga monitoring module

Es geht aber aber auch über die Icinga Web 2 –  Oberfläche siehe Screenshot:

Nachdem das Modul installiert und aktiviert ist kann es losgehen. Zuerst erstellt man das Verzeichnis “fileshipper” unter # mkdir /etc/icingaweb2/modules/fileshipper und erstellt eine import.ini Datei in der das Verzeichnis angeben wird, wo sich die zu importierenden Dateien (.csv) liegen.
[fileshipper files]
basedir = "/usr/local/share/"

Dann wird im Icinga Web 2 => Director => Automation => Add Import Source

ein Name des zukünftigen Imports z.B fileshipper-import-hosts vergeben und bei Source “Import from files (fileshipper) ausgewählt.

Jetzt muss die neue Import-Quelle noch modifiziert werden z.B. so:

Ich denke das Bild ist selbsterklärend und Bedarf keiner weiteren Erklärung.

Jetzt kann man einen Import run starten in dem man auf die Import-Source fileshipper-import-hosts und Trigger Import Run auswählt.

Nun sollte in der Voransicht (Preview) die importierten Hosts sichtbar werden.

Um jetzt aus diesen RAW-Daten Icinga 2 konforme Objekte werden zu lassen brauchen wir eine Sync-Rule die man z.B.so anlegt:


Hier wird in der Maske angeben, welcher Typ (Host-Objekt) daraus werden soll und ob bereits existierende Daten ersetzt (replace) oder zusammengeführt (merge) werden sollen.
Mit Purge können bereits existierende Daten gelöscht werde, JA oder NEIN.

Im Kartei-Reiter “Properties/Eigenschaften” werden die Felder vom Import (Source/Quelle) den Icinga 2 konformen Zielen (Destination) zugeordnet:

Danach kann der Sync-Run der erstellten Sync-Rule gestartet werden und bei erfolgreichen Lauf, werden Konfigurations-Dateien erstellt und sind bereit für den Director zu deployen.

Im Activity-Log kann der Vorgang nochmals überprüft werden, bevor man die Konfiguration per Director deploy übernehmen kann.

So jetzt sollten nach erfolgreichem Deployment die Hosts im Icinga Web 2 unter Hosts sichtbar sein.

 

Im Rahmen einer Icinga 2 Fundamentals Schulung, die wir anbieten, werden auch noch weitere Import-Quellen besprochen und praktisch vollzogen.

Unter anderem haben wir noch weitere Schulungen zu Open Source Themen im Portofolio, einen Überblick bekommen Sie hier bei NETWAYS-Schulungen.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Apply Service for im Icinga Director

Mit den Icinga 2 Apply Rules ist es spielend einfach möglich Services zu erstellen. Möchte man mehrere, gleiche Services erstellen (z. B. mehrere Port-Checks oder SNMP-Counteer) kommt Apply For zum Einsatz.

Im Zusammenhang mit dem Icinga Director erhalten wir ab und an Fragen zur Konfiguration von Apply For und sehr oft stellt sich dabei heraus das die Erklärung dieser Konfiguration per E-Mail oder Telefon sehr umständlich ist. Daher habe ich ein kleines Video für euch vorbereitet.

 

Schönes Wochenende! 🙂

Tobias Redel

Autor: Tobias Redel

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.