Icinga 2 – Monitoring automatisiert mit Puppet Teil 3: Plugins

This entry is part 3 of 5 in the series Icinga 2 Monitoring automatisiert mit Puppet

Heute gehen wir der Frage nach wann und wie Plugins installiert werden sollten, was besonders wichtig bei Systemen mit icinga Benutzern zum Gegensatz nagios zu beachten ist. Auf z.B. RedHat-Systemen besteht das Problem, dass der Prozess Icinga 2 unter dem Benutzer icinga läuft, aber unteranderem das Plugin check_icmp oder auch check_dhcp nur vom Benutzer root oder einem Mitglied der Gruppe nagios mittels suid-Bit ausgeführt werden können.

# ls -l /usr/lib64/nagios/plugins/check_icmp
-rwsr-x---. 1 root nagios ... /usr/lib64/nagios/plugins/check_icmp

Das Ändern der Gruppenzugehörigkeit mit Puppet ist wenig hilfreich, da leider bei einem Update des Paketes nagios-plugins die alten Berechtigungen wieder hergestellt werden. Man könnte nun natürlich den Benutzer icinga und das Paket nagios-plugins explizit vor der Klasse icinga2 managen, verliert dann jedoch die Paketkontrolle über die uid und muss das Home-Directory, Shell und weitere Eigenschaften per Hand in Puppet entscheiden. Klarer ist die Methode genau diese Sachen dem Paket zu überlassen und erst danach icinga in die Gruppe nagios aufzunehmen.

yumrepo { 'icinga-stable-release':
  ...
}
->
package { [ 'icinga2', 'nagios-plugins' ]:
  ensure => installed,
}
->
user { 'icinga':
  groups => [ 'nagios' ],
}
->
class { '::icinga2':
  manage_package => false,
}

Um dieses Vorhaben umzusetzen ist es erforderlich die benötigten Repositories zuerst einzubinden, hier mit yumrepo angedeutet, dann die Pakete zu installieren, den Benutzer anzupassen und erst dann die Klasse icinga2 zu deklarieren.

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.

Icinga, Nagios, Naemon, OMD, Check_MK, Op5 oder Shinken – Teil II

Einen Vergleich der oben genannten Tools hatte ich vor fast drei Jahren einmal gemacht. Seitdem ist viel passiert (SPOILER-ALARM: Nicht bei allen) und ich dachte es wäre mal wieder an der Zeit für ein heiteres Core-Bashing. Ich mache aber keinen Feature-Vergleich, um festzustellen, wer mehr Checks in der Minute ausführen kann. Es geht mir mehr um die Agilität und die strategische Ausrichtung des Projekts. Und in den nächsten Tagen folgt nochmal ein detaillierter Artikel zum Thema Metriken, also schon mal den Sekt kaltstellen.

Grundsätzlich versuche ich bei der Bewertung folgende Kriterien einzubeziehen:

  • Aktivität des Projekts aus Sicht der Code-Basis
  • Aktivität der Community
  • Aktuelle Roadmap und Features
  • Und last but not least, meine persönliche und rein subjektive Sicht

Da wir mit Op5 noch einen Neuen (nicht im Business, aber in der Vergleichsrunde) haben, starten wir gleich durch und fangen an mit… Shinken:

Shinken

Es mag an dem allgemeinen Trend zur veganen Ernährung liegen, aber um Shinken ist es in den letzten Monaten sehr ruhig geworden. Auf dem verlinkten GitHub-Repo ist seit Oktober letzten Jahres nichts mehr in den Master committed worden, was nicht wirklich einen guten Eindruck macht. Auch die Website ist vollkommen veraltet und das Forum scheint offline zu sein. Jetzt denkt man im ersten Moment, das Ding ist komplett tot, aber auf Shinken Enterprise hat man zumindest die Jahreszahl im Footer aktualisiert und es wird hier auch gearbeitet.

Eine Roadmap habe ich auch nach längerer Recherche nicht gefunden. Ich konnte lediglich entdecken, dass Jean Gabès an einem Discovery-Tool mit dem Namen Kunai arbeitet. Vor einigen Monaten ging es in der Community etwas rund und Shinken, eigentlich ja mal als Fork von Nagios gedacht, wurde selbst geforked. Das neue Projekt nennt sich Alignak und hat bereits den Preis für den kompliziertesten Namen einer Monitoring Software gewonnen.

In Frankreich ist Shinken noch immer eine Nummer, da es im Toolkatalog der Behörden als eine Art Standard für Monitoring definiert ist. Features, Roadmap und somit der verbunden Mehrwert sind nahezu nicht ersichtlich und die Website besteht eigentlich nur aus ganz viel heißer Luft.

Mein Fazit: Es tut mir leid, Jean, aber wie bei Austern die zu lange in der Sonne standen, würde ich die Finger von Shinken lassen.

Op5

Ehrlich gesagt habe ich die Kollegen in Schweden lange aus dem Auge verloren. Erst ein paar Gespräche auf der OSMC im letzten Jahr und die Info, dass Andreas Ericsson nicht mehr dort arbeitet, haben meine Aufmerksamkeit wieder mal auf die Freunde im Norden gelenkt. Auch wenn der verwendete Core Naemon, welcher als “unabhängiges” Projekt hier nochmal ein eigenes Kapitel spendiert bekommt, nicht im GitHub von Op5 zu finden ist, wird dort sonst viel gemacht. Sowohl bei Ninja (dem Webinterface) also auch bei Merlin (der Datenbank und HA-Komponente) wird viel fleißig gebohrt und geschraubt.

Der eigentlich verwendete Core spielt schon seit vielen Jahren für Op5 keine große Rolle, denn als Veredler geht es ihnen vielmehr um Integration und die Erweiterung mit eigenen Add-ons und Tools. Was Neuigkeiten angeht, wird man auch bei Op5 nicht richtig fündig. Das Tech-News-Archive hat seit einigen Monaten keine Neuerung mehr gesehen und eine richtige Roadmap findet man auch nicht.

Strategisch sehe ich Op5 heute da, wo wir vor 8 Jahren hin wollten. Alle möglichen System-Management-Disziplinen aus einem Guss zu kombinieren, sodass der User nichts mehr machen muss. Die Welt hat sich aber verändert und so würde man heute eher Graylog oder den ElasticStack favorisieren, bevor man den integrierten op5 Logger verwendet. Der Naemon-Core und alle anderen Add-ons sind in hoher Qualität miteinander verbunden und der User hat mit der eigentlichen Open-Source-Software nichts zu tun. Somit ist Op5 für mich auch kein Open-Source-Tool und will es vermutlich auch nicht wirklich sein. Die kostenlose Lizenz, die eine Verwendung von 20 Geräten erlaubt, ist in meinen Augen eher ein Marketinginstrument.

Mein Fazit: Op5 Monitor ist ein solides Produkt und wer alles aus einer Box haben möchte, fährt damit mit Sicherheit besser als mit NagiosXI. Der Vorteil der vollintegrierten Lösung ist an dieser Stelle aber auch der größte Nachteil des Werkzeugs. Gerade in den Bereichen Metriken und Loghandling wird es in den nächsten Jahren um seine Bedeutung kämpfen müssen.

Check_MK

Beginnen wir das ganze Thema sachlich: Files sind nicht die Lösung für jedes Problem, NEIN, NEIN, NEIN! Somit wäre das durch und mein strategischer Kampf für die Daseinsberechtigung einer Datenbank im Bereich Monitoring wäre erledigt. Im Bereich des Source-Codes waren die Kollegen aus München schon immer sehr aktiv und so geht es auf deren Git-Repo zu wie in der Münchner S-Bahn zur Rush-Hour. Trotzdem habe ich auch bei Check_MK vergeblich versucht, eine Roadmap zu finden und wurde lediglich im Bereich des Konferenz-Archivs in den vergangenen Jahren fündig. Sollte es eine Public-Roadmap geben, freue ich mich über einen Hinweis.

Nachdem ich mich ein bisschen auf dem Demo-System umgesehen haben, konnte ich dort keine wesentlichen Neuerungen finden. Bei der Durchsicht der letzten Commits wurde jedoch klar, dass sehr viel Energie in den Support der eigenen Check_MK-Checks geht. Die massive Anzahl der integrierten Checks sind für den User mit Sicherheit komfortabel, aber auch eine Bürde für die Entwickler. Wenn man die investierte Zeit hochrechnet, dürfte das mit Sicherheit zulasten von Investition gehen.

Mein Fazit: Vor drei Jahren hatte ich folgendes geschrieben “Ehrlich gesagt glaube ich aber auch, dass Check_mk in der Zwischenzeit eher mit geschlossenen Systemen Op5 Monitor oder OpsView zu vergleichen ist”. Ich würde sagen, die Annahme hat sich vollends bestätigt. Die Dokumentation auf der Website ist gut strukturiert und detailliert, aber ansonsten kann man über Strategie und Ausrichtung fast nichts finden. Persönlich war ich darüber hinaus nie ein Fan von Auto-Discovery, da es aus meiner Sicht alles das nicht ist, was “Infrastructure as Code” sein sollte. Das Check_mk trotzdem eine große Fangemeinde kann ich nachvollziehen, aber die ist einfach heute isolierter als in der Zeit des reinen Addon-ons.

OMD

Das eigentliche OMD-Projekt scheint es in der Form nicht mehr zu geben. Die Kollegen von Check_MK haben sich aus dem Projekt offensichtlich zurückgezogen und so idled die Website, deren Ownership bei Mathias liegt, eher vor sich hin. Tot ist das Thema jedoch nicht, da sich die Freunde von Consol dem Projekt angenommen haben. Die Weiterentwicklung erfolgt auf deren GitHub-Account und somit geht es mit dem Produkt ordentlich voran. Auf einer eigenen Seite wird der Unterschied zwischen OMD von Consol und dem Legacy-OMD – das sich aus meiner Sicht erledigt hat – detailliert erläutert.

Der eingeschlagene Weg von OMD gefällt mir. Wenn ich auch mit dem gebündelten Ansatz so meine Probleme habe, bietet es eine sehr einfache Möglichkeit ein Monitoringsystem hochzuziehen. Der User hat dann immer noch die Wahl zwischen Naemon und Icinga und es gibt reichlich Innovation hinsichtlich Metriksystemen wie Graphite und Prometheus. Auch LMD, was als schnelles Bindeglied zwischen unterschiedlichen Livestatus-Cores und dem Webinterface verstanden werden darf, ist bereits mit dabei.

Eine Roadmap im klassischen Sinn konnte ich auch hier nicht finden, aber Gerhard hat erst vor einigen Wochen einen kurzen Abriss über 6 Jahre OMD gegeben. Die 45 Minuten sind mit Sicherheit gut investiert.

Mein Fazit: Wer eine gebündelte Monitoringlösung sucht und auf Open Source wert legt, sollte sowohl von Check_MK als auch von Op5 die Finger lassen. Hier empfiehlt sich der Einsatz von OMD. Die Kollegen sind seit vielen Jahren im Bereich Monitoring aktiv, wissen worauf es ankommt und verweilen nicht auf dem Status Quo.

Naemon

Naemon ist letztendlich ja das Ergebnis eines frustrierten Andreas, der von den Nagios-Freunden kurz nachdem er Nagios 4 fertig gestellt hatte, aus dem Projekt gekegelt wurde. Warum genau Nagios Enterprises den Bruch mit Andreas vollzogen hat, habe ich erst von zwei Jahren auf der PuppetConf erfahren, hier wird es jedoch leider nicht landen.

Auf dem GitHub-Repo gibt es durchaus Aktivität und erst vor zwei Tagen ist mit Version 1.0.6 ein neues Release erschienen. Das Projekt wird in den letzten Jahren eigentlich ausschließlich von Sven Nierlein am Leben gehalten und ist laut meinem Kenntnisstand auch der bevorzugte Core in OMD. Laut Website gab es in den letzten Monaten keine großen Features sondern lediglich Bugfixes.

Für das Projekt wäre es mit Sicherheit schön, wenn es mehr Contributors hätte. Ich weiss wie anstrengend der “Betrieb” eines solchen Projekts ist und zolle hier Sven Respekt, dass er das Ding weiter in Bewegung hält. Um ehrlich zu sein, sieht es jedoch im Moment für mich nicht so aus, als ob da die Post abgeht.

Mein Fazit: Wer mit dem Funktionsumfang von Nagios zufrieden ist, aber a) mit “denen” nichts zu tun haben will und b) auch Livestatus gleich fertig mit dabei haben will, ist mit Naemon gut bedient. Auch wenn nicht viele Features dazu kommen, wird das Projekt am Leben gehalten und das reicht für ein “eingefrorenes” Featureset vollkommen aus.

Nagios

Mein Fazit: Wem Nagios reicht, soll bitte Naemon nehmen.

Icinga

Zugegeben bin ich nicht der Richtige, um Icinga objektiv zu beurteilen, da ich mit der Software und vor allem den Personen einfach zu viel zu tun habe. Aber die Aktivität des Projekts ist sicher mit Abstand konkurrenzlos. Erst vor einigen Tagen ist das Projekt weg vom privaten Redmine zu GitHub gezogen. Das in der Regel vier bis fünf Personen in Vollzeit an Icinga arbeiten ist natürlich ein Grund für die starke Aktivität.

Mit Icinga 2 haben wir mit Sicherheit die Kruste von Nagios abgelegt und gerade die Konfiguration bietet eine Vielzahl an Möglichkeiten, die es sonst in dem Bereich nicht gibt. Eine große Herausforderung stellt noch das geerbte Datenbankschema da, das in großen Umgebungen immer mal wieder Schwierigkeiten bereiten kann. Eine alternative Lösung dafür zu schaffen, welche sowohl Livedaten sehr schnell, aber auch historischen Daten sehr lange zur Verfügung stellt, ist unsere Aufgabe für 2017. Dies wird sowohl im Core als auch bei Icinga Web 2 zu einer Vielzahl von Änderungen führen und somit den Großteil unserer Zeit in Anspruch nehmen.

Strategisch positioniert sich Icinga eher gegen eine gebündelte Lösung. Das Projekt kümmert sich um Core und Web und hat im letzten Jahr seine Anstrengungen in Richtung Integrationen intensiviert. Dies schließt beispielsweise die fertige Integration für Chef und Puppet aber auch Themen wie IcingaBeats mit ein. Auch der Icinga Director, der unterschiedlichste Quellen für die Konfiguration zusammenfassen kann, erfreut sich sehr starker Beliebtheit.

Mein Fazit: Icinga ist dann das richtige Werkzeug, wenn man die am Markt befindlichen Lösungen für Metriken, Logmanagement, Konfigurationsmanagement usw. nach dem best-of-breed Ansatz kombinieren will. Der Anwender muss hier definitiv ein bisschen mehr Hand anlegen, um die unterschiedlichen Lösungen zusammenbauen, profitiert dann aber auch von der Flexibilität, die er sich damit erarbeitet hat. 

Feedback willkommen

Wie bereits angedeutet handelt es sich hierbei um eine subjektive Betrachtung und sie erhebt nicht den Anspruch auf Vollständigkeit. Sollte ich jemanden zu Unrecht falsch beurteilen oder eine Aussage nicht korrekt sein, bitte ich um einen Hinweis und werde den Post entsprechend korrigieren. Habe ich jemanden zurecht schlecht beurteilt, so muss er damit leben.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

PNP4Nagios RRD Single/Multiple Storage

pnp4nagiosFür alle die das Nagios Plugin PNP4Nagios mit Icinga2 einsetzen, werden eventuell schon über folgende Fehlermeldung gestolpert sein,
oder noch stolpern:

/var/log/messages:
NPCD[65119]: ERROR: Executed command exits with return code '7'

/var/log/pnp4nagios/perfdata.log:
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Timeout after 15 secs. ***
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Deleting current file to avoid NPCD loops
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Please check your process_perfdata.cfg
Einstellung:
'/etc/pnp4nagios/process_perfdata.cfg'
Option
RRD_STORAGE_TYPE = SINGLE

Ab der PNP-Version 0.6 ist es möglich, die Performance-Daten nicht in einer einzelnen RRD-Datenbank (SINGLE), sondern in mehreren RRD Datenbanken (MULTIPLE) zu speichern.
Diese Einstellung in der Konfigurations-Datei sollte NICHT global verändert werden, da PNP4Nagios nach dieser Umstellung auf MULTIPLE sofort beginnt, neue RRD-Files anzulegen. Alte Daten gehen damit sofort verloren!

Auf Grund der Performance ist es nicht sinnvoll, global mit RRD_STORAGE_TYPE = MULTIPLE zu arbeiten, da die Anzahl der RRD-Datenbanken und somit auch der Disk-I/O während der Updates sich vervielfachen würde. Deshalb sollte man überlegen, welche Nagios Checks mit dieser Einstellung gefahren werden.
Bestehende RRD-Datenbanken können über einen Konverter (Perl-Skript) '/usr/libexec/pnp4nagios/rrd_convert.pl' konvertiert werden.

Folgende Ausgabe bekommt man bei Ausführung des Perl-Skriptes:

Usage: /usr/libexec/pnp4nagios/rrd_convert.pl --check_command=
--cfg_dir= [ --list_commands ]
[ --dry-run ]
[ --tmp_dir= ]
[ --no_structure_check ]

Schaut dann so in etwa aus:

rrd-convert

# sudo -su icinga /usr/libexec/pnp4nagios/rrd_convert.pl --cfg_dir=/etc/pnp4nagios/ --check_command=disk --dry-run

Search pattern disk
XML Files analyzed 129
XML Files found 7
XML Files without RRD 0
Old XML Files ignored 0
Number of unique check_commands 15
Dry run? [YES]
Temp Directory /tmp/rrd_convert

This is only a 'dry run'. The new RRD Files are stored in '/tmp/rrd_convert'

Start Converter [n|y]?:y
File 1/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk__.dump
Manipulating /tmp/rrd_convert/icinga2-disk__.dump
............ done 47999 lines
Restoring File
/tmp/rrd_convert/icinga2/disk____.rrd
... done
File 2/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk.dump
Manipulating /tmp/rrd_convert/icinga2-disk.dump
............ done 48424 lines
Restoring File
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_manifests-a11d1078b1b1f2e3bdea27312f6ba513.rrd
/tmp/rrd_convert/icinga2/disk__vagrant.rrd
/tmp/rrd_convert/icinga2/disk__.rrd
/tmp/rrd_convert/icinga2/disk__boot.rrd
/tmp/rrd_convert/icinga2/disk__home.rrd
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_modules-41d422e93c9413f221fcbaa64a7964b7.rrd
... done
DONE

Schauen Sie doch einfach mal auf unserer Webseite vorbei, wir biete Schulungen zu vielen interessanten OpenSource-Themen an.

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

Braintower Gateways erben iSMS Features

braintower_logo Seit vielen Jahren setzen wir im Bereich SMS Alarmierung für Icinga sehr erfolgreich auf das MultiTech iSMS.
Neben der sehr simplen Einrichtung, der Netzwerkanbindungsmöglichkeit und dem Versenden von SMS über die Weboberfläche, bietet das Gerät eine HTTP-Schnittstelle für den Versand von SMS. Dadurch wird eine Integration in Monitoring Lösungen um ein vielfaches einfacher. Als weitere Option bietet das Gerät die Möglichkeit eingehende SMS an einen Webserver weiterzuleiten, was es in unserem Fall erlaubt, Alarmmeldungen von Icinga 2 mit einer simplen Antwort SMS zu Acknowledgen.

Für die Braintower Gateways gibt es seit letzter Woche die neue Firmware Version 3.3.0, welche das Gateway um einige interessante Funktionen erweitert. Eines dieser Features ist das SMS Routing, mit welchem SMS Nachrichten per Mail, SMS oder per Web-Call weitergereicht werden können.

Darüber hinaus wurde die API-Funktion des Gateways erweitert und ist nun vollständig kompatibel zu der MultiTech iSMS API. Wer bisher also ein iSMS sein eigen nennt, kann ohne Probleme auf ein Braintower Gateway umsteigen. Eine Erweiterung der Basis-Funktion (welche die API-Kompatibilität bereits inkludiert), ist über eine Vielzahl von Zusatz-Features möglich. Sofern das Gateway identisch eingerichtet wird (Benutzer, IP, etc.), kann eine nahtlose Alarmierung erfolgen – ohne Anpassungen an Skripten oder Software durchführen zu müssen.

Darüber hinaus ist unser iSMS Notification Plugin mit dem SMS Routing Feature zu 100% kompatibel mit Braintower. Somit ist nun neben einer Alarmierung auch ein Acknowledgen von Alarmmeldungen in Icinga möglich.

Übrigens: Wer bereits ein Braintower-Gateway mit dem SMS-Weiterleitungs-Feature erworben hat, kann ein Upgrade für das SMS Routing direkt nachkaufen.

Da wir auch immer wieder einmal diverse Kunden-Anfragen zum Thema GFI FaxMaker erhalten, ob wir passende Gateways anbieten können, ist die Antwort simpel: Ja!

Offiziell supportet wird seitens des Herstellers das MultiTech iSMS. Mit dem neuen Firmware-Update werden nun auch Braintower Gateways unterstützt.

Anbei noch ein kurzer Überblick zu den Änderungen zu Version 3.3.0:

Verbesserungen
[SMSGW-546] – Es ist möglich, die Scripts sendsms.pl und smsack.cgi aus dem NETWAYS iSMS Nagios / Icinga Plugin zu verwenden.
[SMSGW-606] – Es wurde eine Dokumentation zum Ersetzen von Geräten anderer Hersteller durch das Braintower SMS Gateway hinzugefügt.
[SMSGW-618] – Das Gateway ist zusätzlich auf Port 81 erreichbar.
[SMSGW-597] – Das Nachrichten-Routing kann nun Nachrichten auch an Ziele per HTTP weiterleiten.
[SMSGW-608] – HTTP-Ziele beim Nachrichten-Routing sind nun editierbar.
[SMSGW-612] – Es ist möglich, mehr als ein HTTP-Ziel pro Regel beim Nachrichten-Routing zu konfigurieren.
[SMSGW-624] – HTTP-Ziele sind bei Nachrichten-Routing auch auf eingehende Emails anwendbar.
[SMSGW-627] – Im Nachrichten-Routing wird nun ein Hinweis angezeigt, wenn kein SMTP Server konfiguriert wurde.
[SMSGW-634] – Das Feature Nachrichten-Routing kann nun kostenpflichtig lizenziert werden.
[SMSGW-607] – Das Feature SMS Weiterleitung ist nun Bestandteil des Nachrichten-Routings, jedoch mit verringerter Funktionalität. Kunden, die das Feature SMS Weiterleitung lizenziert haben, können eine Upgrade-Lizenz zur Nutzung des Nachrichten-Routings erwerben.
[SMSGW-619] – Die Gestaltung der Weboberfläche wurde verbessert.
[SMSGW-675] – Es wurden zahlreiche Übersetzungen verbessert.
[SMSGW-623] – Die Regeln zur Überprüfung gültiger Rufnummern bei der HTTP API wurden erweitert.
[SMSGW-641] – Es wurden neuen FAQ Artikel hinzugefügt (Syslog, API per HTTPS, SIM Karten Formfaktor, Einbindung in Centreon, Icinga 2 und WhatsUp Gold, Import und Export des Adressbuchs, Technische Daten).

Fehlerbehebungen
[SMSGW-604] – Beim Nachrichten-Routing wird die konfigurierte Absenderadresse nun korrekt gesetzt.
[SMSGW-614] – Die Whitelist der E-Mail-to-SMS Funktionalität wurde korrigiert.
[SMSGW-616] – Der Suchen und Ersetzen Bereich beim Nachrichten-Routing wird nicht mehr doppelt angezeigt.
[SMSGW-617] – Die E-Mail-Gruppen-Benachrichtigung beim Nachrichten-Routing wurde korrigiert.
[SMSGW-622] – Bei E-Mail-zu-SMS wurde die fehlende Online-Hilfe ergänzt.
[SMSGW-615] – Die Produktbezeichnung in Benachrichtigungs-Emails wurde korrigiert.
[SMSGW-628] – Nachrichten wurden teilweise sowohl über Email-zu-SMS als auch über das Nachrichten-Routing versendet.

Sie haben Interesse an unseren angebotenen Produkten oder wünschen eine Beratung? Nehmen Sie einfach direkt Kontakt mit uns auf oder besuchen Sie unseren Online-Shop für weitere Informationen. Wir stehen Ihnen gerne zur Verfügung!

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".

Umstieg auf Icinga 2 gesucht?

Icinga Kaum hat man sein Nagios-System aufgebaut um Linux, Windows, ESXi und diverse Hardware-Komponenten wie Router und Switche zu überwachen, meint die Community im Jahr 2009 einen Fork mit dem Namen Icinga ins Leben zu rufen. Aufgrund vieler Bugfixes und Optimierungen ging es dann bei einer Vielzahl von Kunden in Richtung Migration auf Icinga – mit Erfolg. Als Dienstleister traten wir hier oft unterstützend und beratend zur Seite, bis der Kunde sein neues Monitoring in Betrieb nehmen konnte.

3 Jahre später kamen die Icinga Jungs dann auf die Idee Icinga 2 zu veröffentlichen, mit vielen neuen Features wie einem eingebauten Cluster, einer eigenen API, einem schnellen und dynamischen Webfrontend, einem fancy Web-Konfigurations Tool und vielem, vielem mehr.

Um allen einen einfachen Umstieg von sowohl Nagios als auch Icinga (oder natürlichem jedem anderen Monitoring-Tool) zu ermöglichen, bieten wir unsere Icinga 2 Starterpakete an. Innerhalb von 4 Tagen Dienstleistung bei Ihnen vor Ort bauen unsere Consultants gemeinsam mit Ihnen eine Icinga 2 Umgebung auf und fügen die ersten Services in das Monitoring hinzu. Selbstverständlich gehen wir auf die Unterschiede zu den Vorgänger-Versionen ein und zeigen auf, wie das neue Monitoring-Tool bedient werden kann.

Auf Wunsch installieren wir verschiedene Web-Module wie bspw. das Business-Process Addon, den Icinga Director oder ganz klassisch PNP4Nagios.

Unsere Starterpakete richten sich dabei nicht nur an Nagios / Icinga Benutzer, sondern natürlich auch an neue Kunden welche mit den Open Source Lösungen bisher noch keine Berührungspunkte hatten.

Warum sich ein Umstieg auf Icinga 2 lohnt? Hierzu kann man jetzt viele Vorteile schreiben. Am besten ist es aber man probiert das System selbst einmal über die bereitgestellten Vagrant-Boxen aus oder man schaut sich eines unserer Webinare zu Icinga 2 und Icinga Web 2 an, um einen besseren Eindruck zu bekommen.

Wer noch nicht überzeugt ist oder ein Angebot für ein Icinga 2 Starterpaket wünscht, kann gerne mit uns Kontakt aufnehmen. Wir freuen uns über jede Anfrage!

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".

Braintower SMS Gateways – Neue Firmware 3.1.1

Braintower SMS Gateway Desktop EditionBraintower hat für das Braintower SMS Gateway Desktop Edition und das Braintower SMS Gateway Rack Edition die Firmware-Version 3.1.1 entwickelt, welche viele Verbesserungen enthält.

Die Braintower Gateways können SMS über eine API versenden und fügen sich hervorragend in Monitoringumgebungen mit Icinga 2 ein. Über zahlreiche Erweiterungen lassen sich die Geräte auch für viele weitere Einsatzbereiche im SMS-Versand nutzen.
Verbesserungen

  • [SMSGW-326] – Die Lokalisierung des Webinterfaces wurde an zahlreichen Stellen verbessert.
  • [SMSGW-200] – Die Dokumentation wurde erweitert.
  • [SMSGW-300] – Es wurden Updates des Linux-Basis-OS installiert.
  • [SMSGW-330] – Der maximal konfigurierbare Timeout für Monitoring-Checks wurde angepasst, um mögliche Beeinträchtigungen zu vermeiden.
  • [SMSGW-438] – Die Statistik-Seite wurde überarbeitet.

Fehlerbehebungen

  • [SMSGW-321] – Es wurde ein Fehler beim Überprüfen der Berechtigungen behoben, der das Anlegen und Löschen von Monitoring-Checks verhindert hat.
  • [SMSGW-437] – SMS, die über das Feature E-Mail-zu-SMS versendet wurden, wurden nicht in der Statistik angezeigt.
  • [SMSGW-450] – Durch das Monitoring-Feature wurden keine Recovery-Benachrichtigungen versendet.

Der Download der aktuellen Version erfolgt nach Eingabe der Seriennummer des Geräts unter support.braintower.de.

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.