NETWAYS Web Services: Icinga 2 Master

This entry is part 2 of 3 in the series NETWAYS Web Services

Letzte Woche haben wir bei den NETWAYS Web Services den Icinga 2 Satellite vorgestellt, welcher sich schnell und einfach zur Überwachung von externen Diensten, Anwendungen und Webseiten über das Icinga 2 Clusterprotokoll in die eigene Icinga 2 Umgebung integrieren lässt. Wenn man aber nach einer Standalone-Lösung sucht, die alle Features und die passenden Addons von Icinga 2 gleich mitbringt, kann bei NWS zum Icinga 2 Master greifen.

Der Icinga 2 Master bietet alles, was man für eine eigenständige Icinga 2 Überwachungsumgebung braucht:

Icinga Director

Der Icinga Director vereinfacht die Konfiguration von Hosts und Services. Dazu stellen wir auch einen Satz an vorkonfigurierten Checks zur Verfügung, welche Ihnen die Arbeit mit Icinga 2 deutlich erleichtern.

Icinga Web 2

Mit Icinga Web 2 hat man den perfekten Blick auf die aktuellen Probleme, kann sich je nach Bedarf Dashboards bauen und alle neu im Monitoring aufgenommenen Systeme werden sofort angezeigt.

Graphite und Grafana

Mit den Performancedaten aus Icinga 2, welche über Graphite in Grafana dargestellt und gefiltert werden, können Probleme auf einfache Art und Weise visualisiert werden. Die Metriken werden für 12 Monate aufbewahrt.

Icinga 2 API
Natürlich ermöglichen wir den vollen Zugriff auf die Icinga 2 API, womit Sie mit dem Icinga 2 Master vollautomatisiert arbeiten können.

Externe Überwachung
Mit dem Icinga 2 Master kann man wie beim Icinga 2 Satellite externe Dienste, Anwendungen und Webseiten überwachen, mit dem verfügbaren Addons dann aber auch gleich konfigurieren, verwalten und ermittelten Werte live im Icinga Web 2 und Grafana betrachten. Somit kann man sich eine eigenständige Überwachungsumgebung aufbauen, wenn man z.B. für Kundenprojekte keinen Zugriff auf sein internes Monitoring gewähren und dies sauber trennen will oder man für ein bestimmtes Projekt eine eigene Lösung sucht.

Integration mit meiner eigenen Umgebung
Natürlich kann man mit dem Icinga 2 Master auch über das Icinga 2 Clusterprotokoll im Einsatz befindliche Icinga 2 Agents anbinden. Somit lässt sich der Icinga 2 Master zur kompletten Monitoringumgebung ausbauen, welche dann auch Überwachungen im (kunden-)eigenen Netz fahren kann. Wir bieten hierzu fertige Integrationsskripte für folgende Betriebssysteme:

  • Debian/Ubuntu
  • CentOS/Fedora
  • SuSe/OpenSuSe
  • Windows

Jetzt anmelden und für 30 Tage kostenfrei testen!

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Platz da LConf, der Director kommt!

Lange Zeit war das von NETWAYS entwickelte Tool LConf das Mittel der Wahl wenn ein grafisches Konfigurationsfrontend für Icinga gesucht wurde. Mit Icinga 2 und dem damit einhergehenden geänderten Konfigurationsformat litt jedoch die Kompatibilität, außerdem ist das ursprüngliche Konzept von LConf mit der Zuweisung von Services über Vererbungen eines OpenLDAP-Baumes spätestens mit den vielen Möglichkeiten der Apply Rules von Icinga 2 überholt.

Als eigenes Modul in Icinga Web 2 integriert, ist der Director das einzige Konfigurationstool das eine vollständige Unterstützung für Icinga 2 bietet. Die Kommunikation erfolgt dabei direkt mit der API des Icinga 2 Cores (seit Icinga 2.4). Daher stellt sich also die Frage: Wie lässt sich die Icinga Konfiguration von LConf am Besten auf den Director, respektive von Icinga 1.x auf Icinga 2.x migrieren?

Icinga Web 2 bietet bereits nativ eine Unterstützung für LDAP, diese steht auch den Modulen zur Verfügung. Um LConf nun als Import Source im Director zu verwenden, muss dafür in Web 2 noch eine entsprechende Resource eingerichtet werden.

Host in LConf

Bei der Import Source reicht es dann i.d.R. aus die Objektklasse auf lconfHost einzuschränken, denn mehr als nur Hosts zu importieren, macht in den wenigsten Fällen sind. Services sollten aufgrund von CheckCommands aus der Icinga Template Library (= ITL) sowieso neu gemacht und in dem Zuge auch gleich überdacht werden. Durch die Apply Rules liegt der Fokus auf Host Eigenschaften anhand deren später Services zugewiesen werden können. Neben Standardattributen stehen hier auch sog. Custom Attribute oder Custom Variablen (CustomVars) zur Verfügung, mit denen weitere individuelle Informationen wie beispielsweise Betriebssystem, Rolle oder Standort hinterlegt werden können.

Normalerweise ist es bei Hosts ausreichend cn, lconfAddress, lconfAlias und lconfHostCustomvar zu importieren. Da CustomVars in LConf mit Unterstrich vorm Bezeichner und einem Leerzeichen vor dem eigentlichen Wert angegeben werden müssen, sieht das in der Vorschau der Import Source beispielhaft so aus:

[

“_operatingsystem Linux”,

“_role Webserver”,

“_rack Rack01”

]

Diese Syntax kann vom Director nur schwer weiter verarbeitet werden, daher gibt es dort seit kurzem den Modifier “Transform LConf CustomVars to Hash“, mit dem das Ganze wie folgt transformiert wird:

{

operatingsystem: “Linux”,

rack: “Rack01”,

role: “Webserver”

}

Host im Director

Bei der darauf aufbauenden Sync Rule können dann alle CustomVars mit “All custom variables (vars)” automatisch umgesetzt werden, dabei spielt es keine Rolle ob die Hosts eine, keine oder mehrere Custom Attribute definiert haben.

Damit ist es sehr einfach die Hosts aus dem bestehenden LConf-Baum bereits im Produktivbetrieb schon auf die künftige Verwendung mit Icinga 2 vorzubereiten und sie dann mit dem Director einmalig oder regelmäßig zu importieren, sodass zumindest ein paar Andenken an den “geliebten” LConf bleiben…

Wer hier oder auch bei anderen Aufgaben mit Icinga und dem Director noch Unterstützung benötigt, kann aber natürlich auch gerne auf uns zukommen.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Timelion, eine Kibana Erweiterung

timelion logoIch habe mich in der Vergangenheit mit verschiedenen Tools beschäftigt die Performancedaten bzw. Metriken speichern und darstellen können. Aktuell beschäftige ich mich näher mit Timelion aus dem Hause Elastic und das hat zwei Gründe: Zum einen wurde mir die Kibana Erweiterung auf der ElasticON letzte Woche wieder schmackhaft gemacht, nachdem ich es eigentlich schon zur Seite gelegt hatte. Zum anderen erweist sich Timelion als sehr nützlich in Verbindung mit meinem Icingabeat. Ein Beat der Daten aus Icinga 2 zur weiteren Verarbeitung entweder an Logstash oder direkt an Elasticsearch schicken kann.

Timelion, übrigens Timeline ausgesprochen, ist eine Erweiterung für das bereits bekannte Kibana Webinterface. Es ist dazu gedacht Daten aus einem Elasticsearch Cluster visuell darzustellen. Anders als die bisherigen Visualisierugsmethoden von Kibana wird bei Timelion aber nichts zusammen geklickt und gefiltert. Stattdessen müssen die eingebauten Funktionen direkt aufgerufen und mit Parametern gefüllt werden. Klingt erst mal kompliziert, nach etwas Übung geht das aber schneller als alles mit der Maus zu bedienen.

Ein Beispiel: Um die Anzahl der Dokumente in Elasticsearch zu zählen, wird die Funktion es() verwendet. Sie erwartet als Parameter eine Query. Mit es(*) werden sämtliche Dokumente gezählt, die Query dabei ist *

timelion default query

Als Query kann alles eingegeben werden was das normale Kibana Interface auch versteht, also Apache Lucene Syntax. Zum Beispiel kann ich die Anzahl der Checkresults darstellen, die mein Icinga gerade ausführt: .es(type:icingabeat.event.checkresult)timelion icingabeat checkresults

Einfach Dokumente zu zählen reicht aber oft nicht aus, insbesondere im Hinblick auf Metriken. Wichtig an dieser Stelle ist der eigentliche Wert von einem Eintrag, nicht die Anzahl der Einträge. Die es() Funktion kann mit ihrem metric Parameter genau das tun. Man muss sich lediglich entscheiden mit welcher Methode man die Daten aggregieren möchte. Auch wenn die Daten nicht in einem definierten Zeitrahmen in Elasticsearch gespeichert werden, müssen sie spätestens bei der Darstellung irgendwie zusammengefasst werden um einen gleichmäßigen Graphen anzeigen zu können. Timelion versucht den Abstand in dem Daten aggregiert werden automatisch zu ermitteln, meistens ergibt das “Sekündlich”. Ob das der richtige Intervall ist, hängt davon ab wie schnell die Daten rein fließen. Wie viele MySQL Queries Icinga 2 innerhalb der letzten Minute ausgeführt hat, lässt sich zum Beispiel folgendermaßen ermitteln:

.es(metric=avg:perfdata.idomysqlconnection_ido-mysql_queries_1min.value).label("1 min").title("MySQL Queries").color(green)timelion icingabeat mysql

Hier sieht man auch das sich mehrere Funkionen aneinander ketten lassen. Zum Beispiel zum setzen von Titel oder Farbe. Timelion bringt eine ganze Fülle an Funktionen mit die die Darstellung der Daten beeinflussen. Ich will nicht alle aufzählen, weitere Beispiele aber sind:

  • bars(): Ein Barchart anstelle einer Linie
  • movingaverage(): Berechnet den gleitenden Durchschnitt
  • min(), max() und sum(): Erklärt sich von selbst

Es können auch mehrere Linien innerhalb eines Graphen angezeigt werden, dazu wird die Funktion einfach mehrfach aufgerufen. Hier ein vergleich der Ausführungszeiten von Icinga Plugins:

.es(metric=avg:status.avg_execution_time), .es(metric=avg:status.max_execution_time), .es(metric=avg:status.min_execution_time) timelion icingabeat execution time

Insgesamt ist das nur ein kleiner Teil dessen was Timelion kann. Auch wenn die Bedienung etwas gewöhnungsbedürftig ist, so kommt man nach etwas Übung schnell rein. Die Graphen die erstellt werden können entweder als eigenständige Dashboards abgespeichert werden oder als einzelne Visualisierungen. Werden die Graphen einzeln abgespeichert können Sie zu Kibana Dashboards hinzugefügt werden. Dadurch ergibt sich eine gute Ergänzung zu den normalen Visualisierungen.

Blerim Sheqa

Autor: Blerim Sheqa

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Icinga 2 – Multi-Zonen Notifications

Komplexe Monitoring Umgebungen mit Icinga 2 kennt man ja schon und auch was sich alles mit den Satelliten und zus. Zonen-Mastern anstellen lässt. Aber wisst ihr auch, dass sich gezielte Benachrichtigungen für einzelne Zonen definieren lassen? Die meisten nutzen wahrscheinlich schlicht nur die Haupt/Master Zone für Notifications; aber gehen wir doch von einem nicht unüblichen Beispiel aus : Der externen Überwachung des eigenen Monitorings.

Wir wollen, dass der externer Satellit uns autark kontaktiert sobald das Monitoring ausfällt und im Sinne des Directors, ebenso wenig eine manuell Konfiguration pflegen. Jetzt muss er die Benachrichtigung nur irgend wie zu uns bekommen. Das Wissen über die Objekte sollte bei solchen Setups vorhanden sein, daher werde ich keine Screens oder Config-Auszüge einfügen, sondern nur das Vorgehen beschreiben.

Wie einfach das Ganze mit Zonen-Verzeichnissen und einem Parameter realisiert werden kann, zeigt sich wie folgt. Wir generieren das entsprechende Notification-Command für den Satelliten und stellen sicher, das er es, sowie die betreffenden Kontakte, in seiner Zone finden kann. Anschließend folgt auch schon das Notification Objekt, welches a.) einfach mit in das Zonen-Verzeichnis des Satelliten geschoben, oder b.) global um den Parameter “zone” erweitert wird. Und schon kann es los gehen.

All das lässt sich übrigens auch wunderbar in einem NWS Satelliten abbilden. Probiert es einfach mal aus.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

Der Icinga Buildserver, Version 3

Letztes verbliebene Bild des alten Icinga Jenkins

Der Icinga-Buildserver, erreichbar unter https://build.icinga.com, läuft in dieser Form jetzt etwa ein Jahr. Doch gibt es noch immer ein paar Probleme die mit diesem Setup bestehen: So ist das Hinzufügen neuer Jobs noch etwas umständlich, das provisionieren dauert länger als uns lieb ist und besonders übersichtlich ist die Konfiguration auch nicht. Um diese Probleme anzugehen haben wir uns noch einmal mit Puppet und Jenkins auseinandergesetzt.

Wie vorher verwenden wir ein jenkins puppet-modul, nur diesmal haben wir es mit einem speziellen icinga-jenkins Modul erweitert. Dieses Modul erlaubt es uns spezielle pipeline-jobs mit geringem Konfigurationsaufwand zu erstellen. So ist das unterstehende Beispiel alles was zu konfigurieren ist um eine komplette Pipeline zu erstellen. Selbst der spezielle Umgang mir RPM und Deb ist zu großen Teilen vereinheitlicht und funktioniert für alle Projekte gleich.

icinga_build::pipeline:
  icinga2-snapshot:
    control_repo: https://github.com/Icinga/icinga-packaging.git
    control_branch: snapshot
    matrix_deb:
      'debian-jessie': {}

Die Pipeline erstellt dabei nicht nur einen, sondern gleich vier Jobs: “source”, “binary”, “test” und “publish”. Diese verarbeiten die specfiles, bauen das Paket, testen es und veröffentlichen es auf https://packages.icinga.com

In Produktion ist unser Modul noch nicht, aber um den testen und konfigurieren zu können haben wir Vagrant Boxen gebaut. Mit Hilfe derer bauen wir zur Zeit das icinga-jenkins Modul weiter aus um den bestehenden Buildserver komplett mit den neuen Pipelinejobs abbilden zu können. Wir hoffen unseren Buildprozess damit noch einfacher für Entwickler zu machen und dank der neuen Testsphase für Pakete Problemen in Zukunft besser vorzubeugen zu können

Jean-Marcel Flach

Autor: Jean-Marcel Flach

Auch wenn man Anderes vermuten möchte: Jean ist nicht unser französischer Austauschazubi, sondern waschechter Bamberger. Die Uni war ihm zu langweilig, deshalb knöpft er sich nun in seiner Ausbildung im Development gleich die kniffligsten Aufgaben vor.

AB HEUTE LIVE: NWS – NETWAYS Web Services

Im kleinen Kreis haben wir unsere neue Plattform bereits auf der OSMC gezeigt, ab heute sind wir aber für alle am Start und dürfen mit großen Stolz verkünden: NWS ist live!

Die NETWAYS Web Services (NWS) sind ein SaaS Angebot, welches komplett auf die Bereitstellung von Open Source Anwendungen setzt.

Die Anmeldung und der Start der ersten Anwendung ist in wenigen Minuten erledigt und alle Tools können in den ersten 30 Tagen kostenfrei getestet werden. Mit NWS können Sie sich voll auf Ihr Business konzentrieren – wir übernehmen den kompletten Betrieb der jeweiligen Anwendung.

Hier finden Sie die aktuell verfügbaren Apps:

Icinga 2 Satellite

Ihr persönlicher Icinga 2 Satellite an drei Wunschstandorten: Europa (Nürnberg), USA (Kalifornien) und Asien (Tokyo). Überwachen Sie Ihre Dienste aus Kundensicht und integrieren Sie den Satelliten ganz einfach und sicher in Ihr Icinga 2 Monitoring.

Einsatzzweck: Überwachung von externen Diensten (Webseiten, Shops, SMTP, DNS etc.) und einfache Integration in eine bestehende Icinga 2 Installation über das Icinga 2 Clusterprotokoll.

Icinga 2 Master

Der komplette Icinga 2 Stack als eigenständiges System in drei verschiedenen Größen für jeden Einsatzzweck.

Einsatzzweck: Überwachung von externen Diensten (Webseiten, Shops, SMTP, DNS etc.) als Standalone-System mit Icinga Web 2, Icinga Director und Grafana. Natürlich ist Icinga 2 API voll nutzbar.

 

Rocket.Chat

Rocket.Chat ist die Open Source Lösung für den Chat (intern und extern), Video-Chat und Screensharing, File-Sharing und als Helpdesk Chat-Lösung für jede Unternehmensgröße.

Einsatzzweck: Unternehmensinterne Kommunikation für agile Teams und als Channel für den einfachen Dialog mit Ihren Kunden.

Nextcloud

Nextcloud ist die Filesync und -share-Lösung für Unternehmen.

Einsatzzweck: Sicheres Filesharing in Ihrem Unternehmen und mit Ihren Kunden und Nutzung einer webbasierten Office Lösung, welche die Bearbeitung von Dokumenten im Team ermöglicht.

More to come

Wir bauen NWS kontinuierlich aus und werden in den nächsten Monaten noch viele spannende Open Source Tools aufnehmen.

Hier die Projekte der nächsten Monate:

 

Sie vermissen eine Anwendung? Wir freuen uns über Ihre Kontaktaufnahme.

Webinar

Sie wollen noch mehr zu den NETWAYS Web Services erfahren? Mein Kollege Christian Stein stellt die Plattform in einem Webinar am 15. März um 10:30h vor.

Jetzt schnell kostenlos anmelden!

Was steckt dahinter?

Wir haben die komplette Umgebung natürlich nur mit Open Source Mitteln gebaut. Wer mehr wissen will, meldet sich umgehend zur OSDC 2017 in Berlin an und lauscht Sebastians Vortrag.

Vielen Dank an dieser Stelle an unser NWS-Team für den tollen Einsatz und wir freuen uns auf Fragen und Feedback rund um unser neues Angebot.

Martin Krodel

Autor: Martin Krodel

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.