Neu im Shop: RackMonitoring Kits von TinkerForge

Ab heute können sich unsere Kunden über einen neuen Hersteller bei uns im Shop freuen: Zur Überwachung von Serverräumen bieten wir nun zwei RackMonitoring Kits aus dem Hause TinkerForge an.

TinkerForge ist ein mittelständisches Unternehmen aus Ostwestfalen-Lippe, das Mikrocontrollerbausteine herstellt, die sogenannten Bricks. Die Idee zu diesen Bricks hatten die beiden Gründer Bastian Nordmeyer und Olaf Lüke, nachdem sie – auf der Suche nach Mikrocontrollermodulen für autonome Fußballroboter – keine offenen, mit verschiedenen Programmiersprachen ansteuerbaren Bauteile gefunden haben. Was 2011 noch mit einer kleinen Produktlinie begann, ist nun ein extensiver Katalog an Controllern und Modulen, die sich in zahlreichen Programmiersprachen ansteuern lassen, und sich durch ihre modulare Bauweise schier endlos verknüpfen lassen.

 

 

In enger Zusammenarbeit wurden nun zwei RackMonitoring Kits erstellt, die vor allem Kunden mit individuellen Ansprüchen gerecht werden. Aufgrund der hohen Modularität der einzelnen Komponenten lassen sich TinkerForge Produkte immer wieder neu zusammensetzen. Des Weiteren zeichnet sich TinkerForge durch offene Schnittstellen für Programmierer aus und fällt damit klar in die Kategorie Open Source. Zu den Kits gibt es natürlich auch ein entsprechendes Monitoring Plugin auf exchange.icinga.com.

Folgende Features erwarten Sie bei unseren RackMonitoring Kits PTC4 und PTC8:

  • Modulare Low-Cost Serverraum-Überwachung
  • Lieferumfang:
    • vormontiertes 1HE-Gehäuse passend für 19″ Racks
    • jeweils ein integrierter Sensor für Temperatur, Luftfeuchtigkeit und Umgebungslicht
    • ein pt100 Temperaturfühler mit 1 m Länge
    • Anschlüsse für 7 weitere pt100 Temperaturfühler (nicht enthalten)
    • Anschlüsse und Adapter für Monitor und Keyboard
    • USB-Netzteil
  • Variante PTC4 erlaubt den Anschluss von bis zu 4 pt100 Temperaturfühlern, Variante PTC8 bis zu 8 pt100 Temperaturfühler
  • Erweiterbar: Weitere Sensoren und Ein-/Ausgabe Module können einfach hinzugesteckt werden
  • Stromversorgung per Ethernet (PoE) oder USB
  • Open Source Soft- und Hardware mit Icinga und Nagios Unterstützung
  • APIs für diverse Programmiersprachen verfügbar:
    • C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Wie in der Feature-Liste breits erwähnt wurde, können die RackMonitoring Kits individuell erweitert werden. Für unsere Kunden heißt das, dass hier bzgl. Bricks, Bricklets und anderen Modulen aus dem Vollen geschöpft werden kann – egal, ob es sich um Sensoren, Netzwerk, Funk, Schalter oder Displays handelt. Gerade im Bereich Sensoren sind TinkerForge hier vorbildlich aufgestellt – von Luftqualität (Staub, CO2), räumliche Wahrnehmung (Distanz, Bewegung), Akustik (Schalldruck), Licht (Helligkeit, UV-Einstrahlung) und mehr.

Bei Fragen zum Produkt oder bzgl. Erweiterungs- oder Umbaumöglichkeiten können Sie sich wie gewohnt per Mail an uns wenden – wir helfen gerne weiter! Und wer gerne noch ein bisschen weiterlesen möchte zum Thema TinkerForge, dem sei unser erster Blogpost dazu empfohlen, in dem es um die Inbetriebnahme einer Wetterstation geht:

TinkerForge-Basteln Teil 1: Auspacken und Einrichten!

Linux Netzwerkschnittstellen mit check_nwc_health überwachen

Quelle: 9gag.com


Olá!
Heute möchte ich euch zeigen wie ihr lokale Netzwerk Schnittstellen unter Linux ganz einfach mit dem Plugin check_nwc_health überwachen könnt. Für die Demonstration verwende ich eine VirtualBox Maschine mit CentOS Linux 7.5.1804 (Core) und Icinga 2.9.1.
Anmerkung: Zusätzliche Icinga 2 Plugins werden im besten Fall unter /usr/lib64/nagios/plugins/contrib installiert. Hierfür muss die Konstante PluginContribDir (/etc/icinga2/constants.conf) angepasst werden da diese per se auf /usr/lib64/nagios/plugins zeigt.
 

[root@centos7 ~]# mkdir -pv /var/lib64/nagios/plugins/contrib
[root@centos7 ~]# vi /etc/icinga2/constants.conf
- const PluginContribDir = "/usr/lib64/nagios/plugins"
+ const PluginContribDir = "/usr/lib64/nagios/plugins/contrib"

Dann kann es auch schon los gehen! Zunächst müssen fehlende Pakete installieren sowie das Plugin heruntergeladen und kompilieren werden:

[root@centos7 ~]# yum install -y perl-Net-SNMP perl-Data-Dumper perl-Module-Load
[root@centos7 ~]# cd /tmp
[root@centos7 tmp]# wget https://labs.consol.de/assets/downloads/nagios/check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# tar -xvzf check_nwc_health-7.2.tar.gz
[root@centos7 tmp]# cd check_nwc_health-7.2
[root@centos7 check_nwc_health-7.2]# ./configure \
  --libexecdir=/usr/lib64/nagios/plugins/contrib \
  --with-statesfiles-dir=/var/cache/icinga2 \
  --with-nagios-user=icinga \
  --with-nagios-group=icinga
[root@centos7 check_nwc_health-7.2]# make
[root@centos7 check_nwc_health-7.2]# make install

Nun sollte man das Plugin im Verzeichnis /usr/lib64/nagios/plugins/contrib vorfinden. Im Endeffekt waren das jetzt auch schon alle Schritte. Nun können wir folgende Befehle einfach ausführen:

[root@centos7 check_nwc_health-7.2]# cd /usr/lib64/nagios/plugins/contrib
[root@centos7 contrib]# sudo -u icinga ./check_nwc_health --hostname localhost --servertype linuxlocal --mode interface-health

Ausgabe

Schnittstelle eth0

OK - eth0 is up/up, interface eth0 usage is in:0.00% (0.06bit/s) out:0.00% (0.00bit/s), interface eth0 errors in:0.00/s out:0.00/s , interface eth0 discards in:0.00/s out:0.00/s , interface eth0 broadcast in:0.00% out:0.00%

Schnittstelle eth1

eth1 is up/up, interface eth1 usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface eth1 errors in:0.00/s out:0.00/s , interface eth1 discards in:0.00/s out:0.00/s , interface eth1 broadcast in:0.00% out:0.00%

Schnittstelle lo

lo is up/up, interface lo usage is in:0.00% (0.00bit/s) out:0.00% (0.00bit/s), interface lo errors in:0.00/s out:0.00/s , interface lo discards in:0.00/s out:0.00/s , interface lo broadcast in:0.00% out:0.00%

Performancedaten

'eth0_usage_in'=0%;80;90;0;100 'eth0_usage_out'=0%;80;90;0;100 'eth0_traffic_in'=0.06;0;0;0;0 'eth0_traffic_out'=0.00;0;0;0;0 'eth0_errors_in'=0;1;10;; 'eth0_errors_out'=0;1;10;; 'eth0_discards_in'=0;1;10;; 'eth0_discards_out'=0;1;10;; 'eth0_broadcast_in'=0%;10;20;0;100 'eth0_broadcast_out'=0%;10;20;0;100 'eth1_usage_in'=0%;80;90;0;100 'eth1_usage_out'=0%;80;90;0;100 'eth1_traffic_in'=0.00;0;0;0;0 'eth1_traffic_out'=0.00;0;0;0;0 'eth1_errors_in'=0;1;10;; 'eth1_errors_out'=0;1;10;; 'eth1_discards_in'=0;1;10;; 'eth1_discards_out'=0;1;10;; 'eth1_broadcast_in'=0%;10;20;0;100 'eth1_broadcast_out'=0%;10;20;0;100 'lo_usage_in'=0%;80;90;0;100 'lo_usage_out'=0%;80;90;0;100 'lo_traffic_in'=0.00;0;0;0;0 'lo_traffic_out'=0.00;0;0;0;0 'lo_errors_in'=0;1;10;; 'lo_errors_out'=0;1;10;; 'lo_discards_in'=0;1;10;; 'lo_discards_out'=0;1;10;; 'lo_broadcast_in'=0%;10;20;0;100 'lo_broadcast_out'=0%;10;20;0;100

Icinga Web 2

check_nwc_health hält noch viele andere Möglichkeiten bereit die vom Umfang her, aber den Rahmen dieses Blogposts sprengen würden. Daher würde ich euch gerne auf die Dokumentation verweisen. In diesen Sinne verabschiede ich mich auch schon wieder und wünsche euch viel Spaß beim implementieren und basteln 🙂

Max Deparade
Max Deparade
Consultant

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn...

Wie überwache ich eine Cluster-Applikation in Icinga 2?

Vor dieser Frage stand ich neulich bei einem Kunden. Und dank dem Rat netter Kollegen kam sogar eine ansehnliche Lösung hervor. Wer kennt das nicht – Applikationen, die in einem Linux-HA Cluster laufen worauf über eine Cluster-Virtual-IP zugegriffen wird. An diese VIP-Ressource sind der Applikationsprozess und womöglich eingehängter Speicher als weitere Cluster-Ressource angeknüpft. Somit sprechen wir von zwei Cluster-Ressourcen, die mit einer Cluster-Ressource der VIP verknüpft sind. Diese Abhängigkeit definiert, dass die Anwendung immer nur auf einem aktiven Cluster-Node im zugewiesener VIP laufen kann. Dies ergibt einen Active und einen Passive Node (in unserem Fallbeispiel!)
 

Was bedeutet das genau?

Die Cluster-VIP kann von Active zum Passive Host anhand von Fehler-Kriterien geschwenkt werden. Somit schwenkt der gesamte Betrieb der Applikation vom aktiven Host auf den passiven Host. Dort wird der Applikationsprozess gestartet und die Disk eingehängt. Würden wir jetzt einfach auf beiden Servern neben den System-Standards noch die Applikation gezielt überwachen, würden wir auf einem der beiden Nodes für den fehlenden Prozess und die fehlende Disk immer den Status “Critical”  bzw. den Status “Unknown” beim Ausführen des Disk-Checks zurückbekommen.
 

Lösung!

Um eine Überwachung über die Cluster-VIP zu realisieren, verwenden wir ein eigenes Plugin welches als Wrapper fungiert. Der Check verwendet die Cluster-VIP als Parameter und überprüft ob diese an einem lokalen Interface konfiguriert ist. Wird an einem Interface die Cluster-VIP-Ressource zugewiesen, führt das Plugin den eigentlichen Check aus. Dieser wird als zweiter Parameter übergeben und entspricht dem Namen des Checks, z.B. “check_disk”. Durch den Aufruf des Kommandos mit dem Argument “$@” werden alle Parameter des Wrapper-Scripts an das Plugin übergeben.
 

Plugin-Skript

#!/bin/bash
#
# License: GPLv2, Copyright: info@netways.de NETWAYS GmbH
#
#
plugin_dir=${0%/*}
VIP="$1"
vip_exists=`ip a|grep " inet ${VIP}/"`
echo $vip_exists
shift
command="$1"
shift
if [ ! "$vip_exists" ]; then
  echo "YES! VIP down & I'm STANDBY" && exit $OK
fi
exec ${plugin_dir}/${command} "$@"

Sollte auf einem Cluster-Node die Cluster-VIP nicht zugewiesen sein, gibt der Check den Status “OK” und den Plugin-Output “YES! VIP down & I’m STANDBY” zurück.
 

Einrichten des Check-Commands

Nun können wir dieses Plugin im PluginDir-Pfad auf dem zu überwachenden Host ablegen. Zusätzlich benötigen wir noch ein CheckCommand, welches das Wrapper-Script aufruft und dann die Parameter von “disk” erwartet. Dies kann man so lösen, dass mittels “import” das bestehende “disk” CheckCommand importiert wird und lediglich das auszuführende “command” mit dem Wrapper-Script überschrieben wird. Die Einbindung des CheckCommands sollte am Icinga-2-Master erfolgen, statisch in “commands.conf” oder im Director.
Im  folgenden sind die Beispiele für eine Disk, Prozess und Logfile-Check aufgeführt. Dieses Set könnte einer typischen Cluster-Applikation entsprechen. Wir definieren einen Service-Prozess und einen Filesystem-Mount/Disk die als Cluster-Ressource an die Cluster-VIP gebunden sind. Diese Applikation schreibt auch Log-Dateien, die möglicherweise zu überwachen sind.

object CheckCommand "vip-disk" {
  import "plugin-check-command"
  import "disk"
  command = [ PluginDir + "/check_vip_app", "$app_vip$", "check_disk" ]
}
object CheckCommand "vip-procs" {
  import "plugin-check-command"
  import "procs"
  command = [
   PluginDir + "/check_vip_app",
   "$app_vip$",
   "check_procs"
  ]
}
object CheckCommand "vip-logfiles" {
  import "plugin-check-command"
  import "check_logfiles"
  command = [
    PluginDir + "/check_vip_app",
    "$app_vip$",
    "check_logfiles"
  ]
  timeout = 1m
}

Die zugehörigen Service-Definitionen könnten so definiert werden:

apply Service "vip-disk" {
  check_command = "vip-disk"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
apply Service "vip-procs" {
  check_command = "vip-procs"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
apply Service "vip-logfiles" {
  check_command = "vip-logfiles"
  vars.app_vip = host.vars.app_vip
  command_endpoint = "..."
  assign where host.vars.app_vip
}
Und hier ein Auszug zur Darstellung im icingaweb2:

Service-List Icingaweb2


Service – Plugin Output Icingaweb2



Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das Netways Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner...

Neuigkeiten rund um die AKCP sensorProbe 2+

AKCP-SP2plusDer Online-Store hat schon immer Umweltmonitore von AKCP im Angebot. Die Qualität der Ware ist unbestritten und unsere Kunden und wir profitieren von der gut durchdachten Hardware. Bei unseren Kunden ist die Ware sehr beliebt und gehört zu unseren Topsellern.
Im vergangenen Jahr wurde nun die AKCP sensorProbe2 komplett überarbeitet und nennt sich nun sensorProbe2+. Alle bekannten Features blieben erhalten und auch die Kompatibilität mit allen Sensoren der sensorProbe-Reihe bleibt gegeben.
Ab der neuen Baureihe ist es endlich auch möglich, ein GSM-Modem zu integrieren, wobei dies bei der Erstbestellung der AKCP sensorProbe2+ zwingend mitbestellt werden muss. Außerdem sind bei allen Geräten der AKCP sensorProbe2+– Reihe die VPN Funktion und ein Upgrade auf SNMPv3 optional bestellbar. Neuheit: Bei der E-Mail-Alarmierung wird nun auf TLS-Verschlüsselung gesetzt, die es bislang nur bei den securityProbes gab.
Bei der AKCP SP2+ können neben den bekannten RJ45-Sensoren, von denen vier angeschlossen werden können, auch bis zu 20 potentialfreie Kontakte genutzt werden. Für den Anschluss der potentialfreien Kontakte ist sowohl der Kauf des Sensors: Inputs für potentialfreie Kontakte (5 potentialfreie Kontakte) und eine Lizenz, die jeweils für 5 potentialfreie Kontakte gilt, erforderlich.
Technische Daten AKCP sensorProbe2+

  • Anschlüsse: 4 RJ45 Ports, für sämtliche AKCP-Sensoren der sensorProbe-Reihe, bis zu 20 potentialfreie Kontakte (über speziellen Sensor + Lizenz)
  • Maße/Gewicht: (ca. BxHxT in cm) 11,5 x 6,35 x 3,2/ 0,3 kg
  • GSM-Modem: optional, inklusive externer Antenne
  • sensorProbe2+ Expansion: mit Expansion Unit für bis zu 100 Sensoren
  • Stromversorgung: 12 VDC, 1 Amp; inkl Modem: 12 VDC, 2 Amp
  • Arbeitsumgebung: Temperatur: -35 bis +80 C / Luftfeuchte: 20 bis 80 % (ohne Kondensation)

Intelligente Erweiterung: AKCP sensorProbe2+ Expansion
4 Sensoren reichen Ihnen nicht? Prima, dann können Sie die AKCP sensorProbe2+ Expansion nutzen. Einer der 4 RJ45 Ports kann dort dazu genutzt werden, die von der AKCP securityProbe Reihe bekannten Expansion Units anzuschließen. Hier kann auf die Erweiterung um 8 Ports und/oder die Erweiterung um 16 potentialfreie Kontakte zurückgegriffen werden. Im Daisy Chain Verfahren können somit bis zu 100 Sensoren angeschlossen werden. Ausnahme: Die o.g. VPN Funktion wurde zusätzlich eThermal Map Sensoringekauft. Damit verringert sich die Anzahl der Sensoren auf 50.
Thermal Mapping: Noch genauere Überwachung Ihrer Serverschränke möglich
Die genauere Auswertung und Erfassung thermischer Bedingungen eines Serverracks wird nun durch den neuen Thermal Map Sensor ermöglicht. Dabei wird der Sensor wie im Schaubild rechts zu sehen, an unterschiedlichen Stellen des Racks positioniert. So können “Hot-Spots” leicht lokalisiert werden, was ein gezieltes Eingreifen schneller ermöglicht. Hier kann durch effizientes Kühlen an den besonders warmen und kühlen Stellen, bares Geld gespart werden. Der Thermal Map Sensor kann separat gekauft werden, es gibt aber auch ein Bundle in Form der AKCP sensorProbe2+ inkl. Thermal Map Sensor (Temperatur + Luftfeuchte).
Neues Icinga 2 check-Plugin für AKCP sensorProbe 2+ verfügbar!
Ab sofort steht das neue Plugin für die AKCP sensorProbe 2+ im Github bereit. Unser Entwicklungsteam hat sich das bereits bestehende, seit Jahren funktionierende check_AKCP -Plugin zur Vorlage genommen und ein neues Plugin kreiert. Hier war es notwendig die erweiterte Funktionalität des Gerätes zu berücksichtigen. Hier mal eine Ansicht dazu:

Webinar AKCP SP2+: Die Neuheiten und Icinga 2 Integration
Wer sich die Funktionalität und die Integration in Icinga 2 einmal anschauen möchte, sei herzlich zu unserem Webinar zum AKCP sensorProbe 2+ am 27.04.2017 um 10:30 Uhr eingeladen. Im Anschluss an die Präsentation und die Livedemo gibt es auch die Möglichkeit per Chat Fragen zu stellen. Wir freuen uns auf Sie!

Isabel Salampasidis
Isabel Salampasidis
Account Manager

Isabel ist seit Februar zurück bei NETWAYS. Bis 2009 war sie unsere Office Managerin und verstärkt nun ab sofort das Sales Team. Hier ist sie für alle Belange des Online Stores verantwortlich. Der Ein- und Verkauf der Monitoring Hardware sowie die Weiterentwicklung des Shops und seines Portfolios wird sie mit ihrem bekannten Tatendrang gehörig vorantreiben. Privat verbringt die halbgriechische Ruhrpott-Fränkin sehr gerne so viel Zeit wie möglich mit ihren bald 4-jährigen Patensöhnen oder schreit sich...

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
Christian Stein
Lead Senior Account Manager

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 Gateway – Icinga Plugin verfügbar!

icinga_logo_200x69Trotz Weihnachten und dem bevorstehenden Jahreswechsel sind wir natürlich nicht untätig und stehts dabei unser Portfolio an Plugins weiter auszubauen. Heute möchte ich die Gelegenheit nutzen, um zum Jahresende ein nützliches Plugin für die Überwachung unserer Braintower Geräte mit Icinga vorzustellen.
Das kleine Python-Plugin bedient sich dabei der Statusseite des Gateways und liefert unter anderem Informationen über die Failed-Queue, die Signalstärke sowie die Uptime.
Will man das Gateways überwachen, ruft man das Plugin einfach mit folgenden Parametern auf:

./check_braintower -H 192.168.1.1 --signal-warning -85 --signal-critical -90

Die Werte der Parameter muss natürlich jeder auf seine Bedürfnisse anpassen 🙂
Als Ergebnis erhält man dann beispielsweise folgende Ausgabe:

BRAINTOWER OK - que: 0 failed: 0 signal: -83db total: 0 state: Idle load: 0;0.03;0.05 time: 1451320254 disk free: 647569408 uptime: 9 min, 0 users

Selbstverständlich kann man nicht nur die Signalstärke überwachen, sondern eine Vielzahl von Parametern. Mit –help erhält man hier eine schöne Erklärung über die Möglichkeiten:

usage: check_braintower [-h] -H HOSTNAME [-T TIMEOUT] [-Q QUEUE] [-F FAIL] [--signal-warning SIGNAL_WARNING] [--signal-critical SIGNAL_CRITICAL]

optional arguments:

-h, –help show this help message and exit
-H HOSTNAME, –hostname HOSTNAME The host address of the SMS Gateway
-T TIMEOUT, –timeout TIMEOUT Seconds before connection times out (default 10)
-Q QUEUE, –queue QUEUE The warning threshold for the amount of queued SMS (default 1)
-F FAIL, –fail FAIL The critical threshold for failed SMS (default 1)
–signal-warning SIGNAL_WARNING The warning threshold for the minimum signal strength (in db, default 0)
–signal-critical SIGNAL_CRITICAL The critical threshold for the minimum signal strength (in db, default 0)

 
Wer das Plugin ausprobieren möchte, kann dies natürlich gerne tun – wir freuen uns über Feedback! Verfügbar ist es auf Icinga Exchange und in unserem NETWAYS Git.

Christian Stein
Christian Stein
Lead Senior Account Manager

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

check_disk_btrfs reloaded

While BTRFS is still considered experimental in some environments, it gets even more popular with Docker and CoreOS setups.
I did write a check plugin for a customer nearly 3 years ago called check_disk_btrfs which parses the output of “btrfs filesystem df /” and checks against given thresholds.
Over the years, the shell output of the the btrfs cli tool changed and so the plugin was broken. Code quality wasn’t good enough either in a retrospective and so additional feature requests were not added.
opensuse_icingaweb2_disk_btrfsOn Monday Blerim approached me with a question on monitoring the BTRFS filesystem and also told that the plugin was broken. Instead of fixing the old Perl code, I decided to just go for a new implementation in Python, our current language standard for development projects. It also makes usage of “sudo” optional, and parses the raw bytes output returned from the btrfs cli tool. An example for adding it to Icinga 2 is included as well.
You can download the current 2.0.0 release from Icinga Exchange, and of course sponsor or contribute a feature even. Tested on current OpenSUSE 13.2.

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

OSMC 2015: Der Countdown läuft – nur noch 91 Tage

Alexander Wirt stimmt uns, mit seinem Talk “Plugin Entwicklung für Einsteiger”, auf die heraneilende OSMC ein.

OSMC? Was soll das denn sein und wer sind die netten Menschen in diesen Videos? Die Open Source Monitoring Conference (kurz: OSMC) ist die internationale Plattform für alle an Open Source Monitoring Lösungen Interessierten, speziell Nagios und Icinga. Jedes Jahr gibt es hier die Möglichkeit sein Wissen über freie Monitoringsysteme zu erweitern und sich mit anderen Anwendern auszutauschen. Die Konferenz richtet sich besonders an IT-Verantwortliche aus den Bereichen System- und Netzwerkadministration, Entwicklung und IT-Management. Und die netten Menschen, die Ihr in unseren Videos zur OSMC seht, gehören dazu. 2015 wird die OSMC zum 10. Mal in Nürnberg stattfinden.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

check_cache (is back)

check_cache_workflowEs gibt Dinge im Leben die einfach nicht tot zu kriegen sind. Deswegen haben wir, frei nach dem Motto “Totgesagte leben länger”, unser gutes altes check_cache etwas aufpoliert.
Für alle die sich nicht mehr an den ersten Blogpost erinnern können, check_cache ist Jahrgang 2009 (Südhang, spätlese) und funktioniert grob gesagt wie ein intelligentes check_by_ssh das beim Ausführen mehrere Checks gebündelt verarbeitet. Somit spart man sich in größeren Umgebungen ziemlich viele SSH-Sessions, was einem irgendwann von den Netzwerkern gedankt wird.
In der nun aktuellen Version 1.2.2 sind viele Bugfixes enthalten. In den Bereichen “XML Escaping” und “Exit Codes” wurde etwas mehr korrigiert.
check_cache steht auf exchange.icinga.org zum Download bereit.

Tobias Redel
Tobias Redel
Head of Professional Services

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.

Nicht noch ein S.M.A.R.T. Check …

… es gibt doch schon so viele davon! JA das dachte sich mein Kollege der Achim Ledermüller auch und bat mich doch vor ca. Zwei Wochen, ich solle Ihm einen Check für SSD Platten (für sein Ceph-Projekt) in Unser Monitoring einbauen. Was grundsätzlich mit Checks von der monitoringexchange.org Platform abgedeckt wird hat meinen Kollegen nicht zufriedenstellen können, seine Anforderungen lauteten wie folgt:

S.M.A.R.T. Werte der SSDs zuverlässig überprüfen.
– Mindestens MWI.
– Recherchieren welche Werte sonst aussagekräftig sind!

Die Freunde von Thomas-Krenn haben sich wohl das Gleiche gedacht und auch so ein Plugin gebaut. Da wir aber nur hier bei Uns ziemlich pingelig sind was den Umfang so wie Portabilität an Software (seien es auch nur Plugins) angeht, habe ich mich kurzerhand dazu entschieden ein neues Plugin auf Basis des schon Vorhanden zu schreiben.
Lange rede kurzer Sinn, “check_smartvalues” wurde geboren und deckt eigentlich alles ab, was man sich bei anderen S.M.A.R.T. -Checks so Wünscht und noch viel mehr ( mehr möchte Ich allerdings noch nicht verraten 🙂 ).
Da ich derzeit einen großen namhaften Kunden in Bezug auf das am Ende des Jahres kommende Icinga2 & Icingaweb2 betreue, wollte ich auch Euch die Ansicht der neuen Web-UI nicht vorenthalten. Hier mal ein Bild …

lx-ssd-smart-icingaweb2-longoutput

Der Longoutput der Plugins im neuen Icingaweb2, mit hübschen Kuchen Diagrammen.

Im derzeit noch vielerorts Installiertem “inGraph” für Icingaweb1, sieht die ganze Sache natürlich auch sehr schön aus

mwi

Der “Media Wearout Indicator” hier im “inGraph-Icingaweb1” über eine Zeitschiene von einem Monat mit einem Scalefactor bei 90% ( sonst würde man halt nix Sehen ).


und weil ich Persönlich ein großer Fan des neuen Icingaweb2 bin, und diese HTML5 Kuchendiagramme einfach liebe, hier nochmal eine Nah-Ansicht des “Media Wearout Indicator” …
mwi-icinga2

hier der “Media Wearout Indicator” in Groß, man sieht auch sehr schön, das die Platte (eine Intel 530 SSD hinter dem MegaRaid LSI mit DeviceID 22 ), nach eben nur 4 Wochen Lifetime doch schon sehr geschruppt wurde.


Das Plugin ist derzeit noch im Testing, bei Uns hier im Monitoring allerdings schon mal Live da mein Kollege eben auch sehr für Graphen zu begeistern ist. Es bezieht seine Daten sowie auch die Konfiguration für Schwellewerte aus einer JSON-Datenbank, das ganze sieht dann in etwa so aus …
lx-ssd-database
Sobald den die Letzten Tests abgeschlossen sind werden ich den Check auf der neuen Icinga Exchange Plattform zum Download anbieten.
Im übrigen, das Plugin ist in seiner Grundfunktion schon als Multicheck ausgelegt, so viel möchte ich an dieser Stelle nun doch schon mal verraten. 😉
Macht euch auf was gefasst …