Seite wählen

NETWAYS Blog

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

Getting started Opennebula API

In wenigen Tagen starten die OpenNebula Techdays welche von Netways gesponsort werden. Da auf diesen einige interessante Dinge gezeigt werden gibt es hier jetzt eine kleine Einführung in die API.
Wenn man die API von OpenNebula benutzen möchte, gibt es zwei Möglichkeiten. Einmal „RPC XML“ und zweitens mit einem Ruby Binding. In meinem Beispiel werde ich mich auf das Ruby Binding beziehen.
Um mit der API rumspielen zu können benötigen wir erstmal eine passende OpenNebula Umgebung. Hierfür können wir uns ganz einfach eine vorinstallierte VM als VirtualBox image herunterladen.
Um nun auch auf die API zugreifen zu können, muss man noch eine Portweiterleitung für den Port „26330“ einrichten (Port 9869 ist optional, sollte man auch auf das Web-interface zugreifen wollen). Die Weiterleitung kann unter Setting > Network > Advanced > Port Forwarding eingerichtet werden.
Jetzt kann man anfangen sich gegen die API zu connecten. Als erstes fügt man die benötigten Ruby Gems hinzu. Dies wird mit

require 'opennebula'
include OpenNebula

gemacht.
Danach erstellt man Variablen für die login credentials und den Endpoint. Ich benutze dafür die default Username und Passwort Kombination.

CREDENTIALS = "oneadmin:opennebula"
ENDPOINT    = "http://<DeineVBoxIP>:26330/RPC2"

 
Nachdem dies erledigt ist, kann man eine Verbindung zur API festlegen. Hierfür legt man wieder eine Variable fest. (Bitte beachtet, das die credentials und endpoint variablen genauso heißen, wie oben festgelegt!)

client = Client.new(CREDENTIALS, ENDPOINT)

 
Als nächstes initialisiert man den Virtual Maschine Pool. Dafür wird die Variable vm_pool angelegt.

vm_pool = VirtualMaschinePool.new(client, -1)

 
Um mögliche Fehler abzufangen kann man eine kurze Fehlerabfrage einrichten. Diese gibt uns, im Falle eines Fehlers, gleich den richtigen Fehler Code zurück.

rc = vm_pool.info
if OpenNebula.is_error?(rc)
     puts rc.message
     exit -1
end

 
Damit jetzt jede Virtuelle Maschine gestoppt wird, richtet man eine kleine Schleife ein die uns pro VM, die sich im vm_pool befindet, eine Funktion ausführt.

vm_pool.each do |vm|
     rc = vm.shutdown
end

 
Mit der oben eingerichteten Fehlerabfrage kann man sich hier auch gleich noch den aktuellen Status bzw eine Success oder Fehlermeldung ausgeben lassen. Dafür fügt man ein paar Zeilen zu seiner Schleife hinzu.

vm_pool.each do |vm|
     rc = vm.shutdown
     if OpenNebula.is_error?(rc)
          puts "Virtual Machine #{vm.id}: #{rc.message}"
     else
          puts "Virtual Machine #{vm.id}: Shutting down"
     end
end

 
Das ganze noch mit einem sauberen

exit 0

abschließen und das erste Script ist fertig!
 
Um das Endprodukt testen zu können, muss man noch eine VM in OpenNebula erstellen. Hierfür kann man ein schon vorgefertigte Template nutzen.
OpenNebula API
Dieses einfach instantiieren und warten bis die VM hochgefahren ist. (Meist ca 10 Sekunden).
Wenn man jetzt das Ruby Script ausführt sollten man folgende Ausgabe erhalten:

Virtual Machine 1: Shutting down

 
Wie man an diesem Beispiel sehen kann, ist es sehr einfach eigene Scripte für Opennebula zu schreiben. Noch mehr spannende Dinge gibt es auf den diesjährigen TechDays!

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
Martin Krodel
Head of Sales

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.

Selbstentwickelte Anwendungen überwachen

Die Basis

Bei selbstentwickelten Anwendungen stellt sich häufig die Frage wie sich diese im Monitoringsystem überwachen lassen.
Häufig läuft es dann darauf hinaus das einzelne Komponenten der Anwendung überwacht werden. Der Webserver, die Datenbank, eventuell der Applicationserver oder die Messagequeue die von der Anwendung benötigt wird. Das alles ist ein Solides Grundgerüst auf dem sich aufbauen lässt.

Die Anwendung verrät Ihren Status

In einer agilen (Web-)Plattform ist es aber hilfreich wenn die Anwendung etwas über ihren Status verrät. Welches Softwarelease ist ausgerollt und passt die Version des Datenbank Schemas zu dieser Version? Erreicht der Server seine Failover Systeme und sind diese OK?
Die Software kann aber noch mehr über sich verraten. Wie ist der Gesamtstatus der Software? Dieser ist nur OK wenn alle einzelnen Prüfungen OK sind.
Wünschen sich Entwickler oder Admins bestimmte Infos auf einer Infoseite oder einer API, lassen sich diese häufig recht einfach implementieren.
Hier das Beispiel einer möglichen API Ausgabe:

{
  "health": {
    "status": "OK"
  },
  "checks": [
    {
      "version": "1.0.1"
    },
    {
      "commit": "338308edb94efb7e54e609d5a8ee3f5df78595d0"
    },
    {
      "nodeid": "node2"
    }
  ],
  "cluster": [
    {
      "node1": [
        {
          "status": "OK"
        },
        {
          "version": "1.0.2"
        },
        {
          "commit": "f28d07c9ec90a4f17b446de060c44cf6ff379de5"
        }
      ]
    },
    {
      "node2": [
        {
          "status": "MAINTENANCE"
        },
        {
          "version": "1.0.1"
        },
        {
          "commit": "338308edb94efb7e54e609d5a8ee3f5df78595d0"
        }
      ]
    },
    {
      "node3": [
        {
          "status": "OK"
        },
        {
          "version": "1.0.2"
        },
        {
          "commit": "f28d07c9ec90a4f17b446de060c44cf6ff379de5"
        }
      ]
    }
  ]
}

Die Informationen im Monitoring nutzen

Im Monitoring lassen sich einzelne Werte zum Beispiel mit check_http auswerten, indem man auf den zu erwartenden String prüft. Mit check_multi lassen sich diese Infos dann mit anderen Checks verknüpfen. Die Kollegen in der Rufbereitschaft freuen sich über weitere Anhaltspunkte, wo das Problem zu suchen ist.

Hilfe bei der Automatisierung

Diese Infos sind zum Beispiel bei Continuous Delivery Szenarien enorm hilfreich. Das CI System kann prüfen ob der Rollout der ersten Knotens erfolgreich war und diesen dann z.B. über einen API Call wieder als Live markieren, das Monitoring System beendet die Downtime und der Loadbalancer nimmt den Knoten wieder in die Verteilung.

AVTECH – Unsere Neuheit: Monitoring Hardware mit Wifi

Wir vom NETWAYS Online-Store freuen uns über Zuwachs in unserer Hersteller- Familie. Seit einigen Tagen bieten wir im Bereich Monitoring Hardware Produkte aus dem Hause AVTECH an. Der amerikanische Hersteller aus Rhode Island bietet eine Reihe von Lösungen zur Überwachung von Serverräumen bezüglich der Umwelteinflüsse an.
Unter dem Namen AVTECH Room Alert gibt es solche in verschiedenen Größenordnungen, sprich mit unterschiedlich vielen Anschlussmöglichkeiten für Sensoren. Heute stelle ich Euch die beiden AVTECH Room Alerts an, die wir in den Shop aufgenommen haben. Weitere Produkte aus der Reihe können wir natürlich auf Anfrage ebenfalls beschaffen.
 

AVTECH Room Alert 3 Wifi AVTECH Room Alert 3 Wifi

  • WLAN-Überwachungsmonitor für 3 Sensoren
  •  integrierter Webserver
  • 1 integrierter Temperatursensor
  • Anschluss von einem weiteren externen Sensor über RJ11
  • 1 potentialfreier Kontakt
  • keine SNMP Kompatibilität/kein RJ-45 Port
  • 1 Jahr kostenfreies Monitoring über www.GoToMyDevices.com (Option Personal)
  • sendet E-Mail Benachrichtigungen über die Software GoToMyDevices
  • kostenloser Download AVTECH Device ManageR

 
Das knallrote, 220 Gramm leichte Gerät kommt mit einem besonderen Feature daher: Es ist W-LAN– fähig und benötigt keine LAN-Verkabelung um über das Netzwerk eingebunden zu werden. Einfach das W-LAN des Gerätes ansprechen, verbinden und fertig.
Zusätzlich ist eine schnelle Inbetriebnahme durch den integrierten Temperatursensor gewährleistet.
Der Anschluss eines weiteren Sensors über einen RJ11-Anschluss und eines zusätzlichen Sensors über einen potentialfreien Kontakt runden dieses sehr gut durchdachte Produkt ab.
 

AVTECH Room Alert 3 PoE AVTECH Room Alert 3 PoE

  • LAN-Überwachungsmonitor für 3 Sensoren
  • integrierter Webserver
  • 1 integrierter Temperatursensor
  • Anschluss von einem weiteren externen Sensor über RJ11
  • potentialfreier Kontakt
  • Volle SNMP Kompatibilität
  • Jahr kostenfreies Monitoring über www.GoToMyDevices.com (Option Personal)
  • sendet E-Mail Benachrichtigungen über die Software GoToMyDevices
  • kostenloser Download AVTECH Device ManageR

 
Optisch identisch zu seinem Wifi-Bruder ist der AVTECH Room Alert 3 PoE mit einem LAN-Anschluss versehen und nicht W-Lan fähig. Dafür benötigt es kein Netzteil und ist voll SNMP-fähig. Ansonsten sind alle Funktionen und Sensoranschlüsse wie beim AVTECH Room Alert Wifi vorhanden.
Die Sensoren, die an sämtliche AVTECH Room Alerts anschließbar sind überwachen die Bereiche: Temperatur, Luftfeuchte, Wassereinbruch, Stromversorgung und vieles mehr.