Seite wählen

NETWAYS Blog

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 Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

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!

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
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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.