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.

NETWAYS Web Services: Icinga 2 Satellite

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

Icinga 2 ist bei vielen Unternehmen in allen Größenordnungen im Einsatz und ermöglicht die Überwachung von Servern, Anwendungen, Netzwerkhardware, Diensten, Webseiten uvm.. Allerdings stößt man beim Monitoring von externen Diensten auf ein Problem – es fehlt in den meisten Fällen der Blick von außen. So kann man zwar aus dem eigenen Netz alles überwachen, ob Ihr Kunde aber alles sehen und nutzen kann, lässt sich auf diese Weise nicht 100%-ig sicherstellen.

Praktischerweise verfügt Icinga 2 mit seinem Cluster- und Zonenkonzept über eine erprobte Möglichkeit, Icinga 2 Satelliten in seine eigene Monitoringumgebung einzubauen. Und wenn man externe Dienste überwachen will, muss diese Zone dann auch am besten außerhalb des eigenen Netzwerkes stehen.

Mit unseren NETWAYS Web Services können wir genau dies für Sie anbieten – einen komplett gemanagten Icinga 2 Satelliten.

Icinga 2 Satellite

Welche Checks bieten wir an?

  • Web service checks
    HTTP(S)
  • E-Mail service checks
    IMAP/POP3, SMTP
  • Availability checks
    Ping, ICMP, TCP/UDP
  • Icinga 2
    Icinga 2’s customized protocol

 

Welche Standorte stehen zur Verfügung?

  • US West
    North California
  • Europe
    Nuremberg
  • Asia/Pacific
    Tokyo

 

Mit einem extern bei NWS gehosteten Icinga 2 Satelliten können Sie sicherstellen, dass Ihre Dienste auch immer aus Kundensicht überwacht werden. Jetzt schnell anmelden und 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.

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.

Ja ist denn schon wieder Webinar Zeit?

Auch in diesem Jahr wollen wir natürlich wieder effektiv mit unseren Webinaren auf Neuheiten im Open Source Bereich, sei es Icinga 2, Ansible, uvm. oder auf Produktneuheiten in unserem Online-Store, wie bspw. die neue Braintower Firmware hinweisen.

Die folgenden Themen und Termine stehen Stand heute schon fest:

Titel Zeitraum Registrierung
Server-Überwachung mit Icinga 2 15. Februar 2017 – 10:30 Uhr Anmelden
Icinga Director: Neues vom Config Tool 02. März 2017 – 10:30 Uhr Anmelden
Braintower: Neuheiten in Firmware 3.5 16. März 2017 – 10:30 Uhr Anmelden
Icinga Web 2: Erstellen und verwalten von Business Prozessen 30. März 2017 – 10:30 Uhr Anmelden
AKCP SP2+: Die Neuheiten und Icinga 2 Integration 27. April 2017 – 10:30 Uhr Anmelden

Selbstverständlich werden die Webinare wieder aufgezeichnet und sind anschließend in unserem Webinar Archiv verfügbar.

Wir freuen uns über eine rege Teilnahme!

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Bald geht’s nach Berlin – Icinga Camp 2017

Am 07. März 2017 steigt das Icinga Camp in Berlin, wenn die Kalkscheue wieder zum Schauplatz der Monitoring-Verrückten wird. Jede Menge Icinga Talks und Diskussionen werden euch neben leckerem Essen und einem Icinga T-Shirt der neuesten Kollektion erwarten. Hier ein kleiner Vorgeschmack wer und was euch an diesem aufregenden Tag erwarten wird:

Nachdem Bernd den aktuellen Status von Icinga präsentiert, folgen Vorträge zu verschiedenen Icinga-Themen. Sven Nierlein von ConSol stellt mit Thrunk ein anderes Icinga Webfrontend vor, Eric Lippmann, Icinga CTO, gibt einen Einblick in Icinga Web 2. Werner Fischer von der Thomas.Krenn AG gibt Tipps, wie Hardware Monitoring besser gestaltet werden kann, wohingegen Mattis Haase von C-Store erläutert, was beim schreiben von Checks alles so zu beachten ist.

Außerdem werden Eduard Gueldner (Siemens AG) mit „Train IT Platform Monitoring“, Francesco Melchiori (Würth Phoenix) mit „Alynix – End user Experience Monitoring in Icinga“, sowie Thomas Gelf mit Infos zum Icinga Director und Micheal Friedrich („Integrations all the way“) mit von der Partie sein.

Noch kein Ticket? Buuuuh! Dann schnell hier hin klicken und noch eines der letzten Tickets ergattern. Wir sehen uns in Berlin! 🙂

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

Icinga 2 Best Practice Teil 3: Services überwachen

Nun in Teil 3 dieser Serie werden wir uns näher damit beschäftigen wie in Icinga 2 Services überwacht werden bzw. wie es zu konfigurieren ist, dass bestimmte Services nur auf bestimmten Hosts überwacht werden. Hier bietet Icinga 2 als Neuerung eine regelbasierte Zuweisung an Host-Objekte die definierten Eigenschaften genügen.

apply Service "ping4" {
  import "generic-service"

  check_command = "ping"

  assign where host.address || host.address6
}

So wird hier ein Service ping4 an alle Hosts “gebunden”, die das Attribut address oder address6 definiert haben. Nach diesem recht einfachem Beispiel wenden wir uns auch gleich etwas komplizierterem zu, der Überwachung von Dateisystemen auf einem Linux-System.

apply Service for (filesystem => config in host.vars.disks) {
  import "generic-service"

  check_command = "disk"
  command_endpoint = host.name

  vars += config

  assign where host.vars.os == "Linux"
  ignore where typeof(config) != Dictionary
}

Da hier über das CheckCommand disk, das Plugin check_disk zur Anwendung gelangt, das lokal auf dem zu überwachenden System laufen muss, wird es via command_endpoint auf genau diesem Endpoint angetriggert (siehe hierzu Teil 1 dieser Serie). Ein Host kann mehrere unterschiedlich Dateisysteme beherbergen, deshalb sind diese im Host-Objekt mit dem Custom-Attribute vars.disks zu definieren. Ausserdem muss zusätzlich, wie in dem assign-Statement gefordert, vars.os auf Linux gesetzt sein.

object Host "host.example.org" {
  ...
  vars.os = "Linux"

  vars.disks["disk /"] = {
    disk_partition = "/"
  }
  vars.disks|"disk /tmp"] = {
    disk_partition = "/tmp"
  }
}

Bekanntlich handelt es sich bei vars um ein Dictionary und vars.disks ist eine Darstellungsform eines Keys in diesem Dictionary. Eine andere Form einen Schlüssel anzusprechen ist der Index mit []-Klammern, wie in vars.disks[“disk /”]. Das heißt wir haben hier ein Dictionary in einem Dictionary. Und um es noch auf die Spitze zu treiben weisen wir den einzelnen Keys als Wert wieder jeweils ein Dictionary zu, Perl lässt grüßen. Wozu nun das Ganze? Mit apply Service for wird der Inhalt von vars.disks durchlaufen. Da es sich hierbei um ein Dictionary handelt, wird hier ein for-each verwendet, zu sehen an filesystem => config. Beides sind hier unsere Laufvariablen für die Schleife. Der Variablen filesystem wird jeweils der Key zu gewiesen, also beim ersten Durchlauf “disk /” und beim Zweiten “disk /tmp”, in config dann demnach der zugehörige Wert. Diesen Wert, selbst ein Dictionary, kann als Konfigurations-Dictionary bezeichnet werden, der den jeweiligen Pluginaufruf von disk parametrisiert. Die möglichen Parameter für disk sind sehr gut der Online-Dokumentation zu entnehmen. Wie dies funktioniert und warum die Zeile vars += config hierzu eine zentrale Rolle spielt, wird in Teil 4 erklärt werden. Der Name des Services entspricht standardmäßig dem Inhalt von filesystem.
Selbstverständlich besitzt jedes Linux-System ein Root-Dateisystem und sagen wir, bei uns auch ein eigenes für /tmp. Natürlich möchte man nun nicht für alle seine Hosts immer diese obigen 7 Zeilen angeben müssen, deshalb definieren wir mit diesen ein Host-Template mit der Bezeichnung linux-host. Nun haben Regeln die dumme Eigenheit ihre Ausnahmen zu haben, z.B. hat der Host host.example.org im Gegensatz zu allen anderen Hosts eben kein Dateisystem /tmp. Was dann?

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

  vars.disks["disk /tmp"] = false
}

Hier wird nun für /tmp die Definition aus dem Template nachträglich überschrieben. Das ignore-Statement in unserer Service-Definition sorgt dafür, dass alle Dateisysteme, denen kein Konfiguration-Dictionary zugewiesen ist, auch nicht als Service in unserer Icinga-Konfiguration landen. Bei typeof handelt es sich um eine Funktion, die die Typesierung einer Variablen ermittelt.

Bis zum nächsten Mal, ihr müsst unbedingt schauen wie es weiter geht. In Teil 4 folgt die etwas theoretische Erklärung wie solche Services jeweils einzeln unterschiedlich parametrisiert werden.

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.