Server-Monitoring via Pushover/Pushalot

„Wo nur bleibt die Mail, die ich mir vor 10 Minuten habe weiterleiten lassen? SPAM-Folder? Nein. Bei genauerem Hinsehen entdecke ich einen Fehler im Mail-Client, der beim Synchronisieren mit dem privaten Mailserver aufgetreten sei. Man möge es später nochmals versuchen oder sich an seinen Admin wenden orakeln die üblichen Beschwichtigungsversuche. Mist – ausgerechnet heute! Eine erste Prüfung ergibt wenig. DynDNS ist okay, Maschine lebt aber mehr ist von unterwegs vorerst nicht festzustellen. Am Abend dann die Gewissheit: Auf dem Mailserver ist die Platte voll. Mailbox-Database und Log-Files haben ihr Übriges dazu beigetragen – hätte man doch aber eigentlich rechtzeitig mitbekommen können…“

So oder ähnlich kommt man gelegentlich zu der Erkenntnis, dass auch die IT in den eigenen vier Wänden nicht gänzlich wartungsfrei vor sich hin säuselt. Sei es ein Dienst, der sich gerne mal verabschiedet, eine Netzwerk-Komponente die einen kleinen Tritt braucht oder gar der knapp gewordene Speicherplatz.

An denkbaren Lösungen mangelt es heute nicht mehr. So könnte man überlegen, ob ein Nagios, MOM, OpenNMS, WhatsUp, Zabbix, etc. die Mühe wert wäre. Im Funktionsumfang und auch in der Erweiterbarkeit ähneln sich die bekanntesten Vertreter des Server-/Netzwerk-Monitoring schon seit Jahren sehr. Bleibt noch die Qual der Wahl. Und natürlich müsste auch noch eine Datenbank her, eine brauchbare Erstkonfiguration und vielleicht ein Backup aber daran würde es sicher nicht scheitern.
Dennoch bin ich mir sicher, dass zumindest für meinen Hausgebrauch dieser Ansatz völlig am Ziel vorbeigehen würde. Ein Wort trifft es ganz gut: überdimensioniert. So möchte ich doch nur wissen, dass der Speicher nicht voll läuft, hier und dort ein paar für mich spannende Dienste laufen und zwei/drei Webinterfaces erreichbar sind. Theoretisch genügt es auch völlig im Falle eines Fehlers eine kurze Info zu erhalten – ich muss nicht ganz genau wissen seit wann das Problem besteht und Dashboards brauche ich auch nicht.

Die Anforderungen:

  • Keine Middleware: Clients und Server sollen direkt Bescheid sagen, wenn etwas nicht mehr so ist, wie erwartet
  • Kein Aufwand: Einfach und schnell zu konfigurieren
  • Kein SPAM: Statt auf Mails auf Push-Dienste setzen
  • Kein Overhead: „Small memory/resource footprint“

Die Idee zum „PushMonitoring“

Ein simples Kommandozeilen-Tool mit XML-Konfigurationsdatei, welches bei jeder Ausführung die per Konfiguration definierten Prüfungen einmalig ausführt, deren Ergebnisse zusammenfasst und bei Abweichungen vom SOLL per Pushalot oder Pushover informiert. Als Prüf-Typen sollten anfangs Ping, freier Speicher und HTTP-Requests genügen – später vielleicht noch Dienste, TCP, Up-time. Durch den minimalistischen Ansatz bleibt das Tool universell einsetzbar und flexibel. Per geplantem Task genügt beispielsweise eine stündliche oder je nach Aufgabe auch tägliche Ausführung.

Konfiguration

Neben den primären Konfigurationsbereichen wie <sendInterfaces> und <checksToRun> kann zusätzlich per <sendWithoutError> ein Zeitraum festgelegt werden, nachdem man auch ohne Fehlermeldung mal wieder ein Lebenszeichen vom System erhalten möchte. Diese Funktion kann jedoch nur verwendet werden, wenn die Anwendung irgendwo das Logfile (definiert in <logFile>) speichern kann.

Fertig ist das Monitoring für Puristen

Das Projekt

Die Quellen finden sich auf Github unter roschinsky/PushMonitoring. Wer sich berufen fühlt – das Portieren auf Mono- bzw. CLR Core steht noch aus… 😉

Für alle die gerade kein Visual Studio am Start haben oder nur die Binaries brauchen gibt es natürlich noch die Pre-Build Version, die ich im One-Drive hinterlegt habe:

„PushMonitoring.zip“

QUELLE: OneDrive

GRÖßE: 0,02 MByte

DATUM: 30.06.2015

Advertisements

Home Access Center

Mittlerweile beherbergt man, nicht mal mehr nur in „nerdigen“ Behausungen, eine Vielzahl von Geräten, die am Netz hängen. Viele davon ebenfalls mit einer irgend gearteten Web-Oberfläche: NAS, Router, Fernseher, Notebook, Netzwerk-Player, Drucker, WLAN-Lampe, usw. – unter IT-Volk gerne auch Server bzw. VMs für Basteleien.

In den seltensten Fällen passt alles perfekt zusammen und eine zentrale Anlaufstelle, die einen flotten Überblick über die Netzwelt in den eigenen vier Wänden erlaubt, sucht man vergebens. Unter den Media Center Lösungen dieser Welt wird gerne versucht dies mit Hilfe von UPnP zusammenzutragen aber auch hier hört es oft dort auf, wo keine Multimedia-Daten mehr zum Abspielen gefunden werden…

Natürlich könnte man sich in einem Intranet mit wenigen Handgriffen eine solche „Zentrale“ zusammenklicken. Ein Intranet für zu Hause – egal ob als Entwicklungsumgebung oder tatsächlich um seine Daten zu organisieren keine außergewöhnliche Idee mehr. Aber nur dafür ein Intranet aufsetzen? Eigentlich Quatsch, wenn man nicht zufälligerweise bereits eins zur Hand hat.

Diese Gedanken und eine leere IIS-Willkommensseite, die mir omnipräsent auf all meinen VMs begegnete, trieben mich vor ein/zwei Jahren dazu, ein kleine, flexible und für sich allein stehende Seite zu basteln, die nichts weiter tut, als genau diesen Zweck zu erfüllen. Das „Home Access Center“ war geboren…

Home Access Control - Intern

Meine damals wichtigsten Anforderungen:

  • Klein/flexibel mit wenig Overhead (keine Datenbank, keine dickes Backend, so „plain“ wie möglich)
  • Konfigurierbar
  • Sowohl von extern als auch von intern (bei mir DMZ und LAN) zu erreichen
  • Anzeige von Menü-Einträgen in Abhängigkeit der Quelle des Zugriffs
  • Differenzierung der Ziel-Links von Menü-Einträgen in Abhängigkeit der Quelle des Zugriffs
  • Anzeige der Erreichbarkeit (Host up / Host down via Ping)
  • Einigermaßen ansprechend sowie sowohl für mobile und stationäre Endgeräte brauchbar

Wie schon oben angedeutet, ergab sich eine Frage zum Hosting der Seite nicht, da in meinem Fall 24/7 ein IIS läuft. Grundsätzlich wäre ein RasPi mit Mono ebenfalls ein geeigneter Host für die Seite. Es handelt sich insgesamt lediglich um eine aspx-Seite nebst Code-Behind, CSS-Dateien/Webfonts, ein paar Bilder für den Hintergrund sowie die XML-Konfiguration.

Die fast wichtigste Funktion ist die Unterscheidung zwischen den Zugriffszonen und die davon abhängig ausgegebenen Ziel-Links. So ist es relativ einfach, intern die Geräte direkt anzusprechen und für den externen Zugriff beispielsweise auf ein Port-Mapping zurückzugreifen.

Home Access Control - Zugriffsschema

Natürlich möchte man nicht auf einer externen Seite den Online-Status seiner sensibelsten Technik offenbaren, selbst wenn die Hyperlinks darauf nicht funktionieren würden, wenn dies nicht entsprechend konfiguriert ist. Mit Hilfe der Unterscheidung zwischen verschiedenen Ziel-Pfaden ist es ebenfalls möglich, ausgewählte Geräte nicht in allen Zugriffszonen zur Verfügung zu stehen, so dass sich externen Gäste oder Besuchern in der DMZ unter gleicher URL ein ähnliches aber doch anderes Bild bietet:

Home Access Control - Extern

Die Konfiguration erfolgt derzeit denkbar einfach über eine XML-Datei, in welcher die einzelnen Endgeräte mit Anzeigenamen bzw. Kürzel, Beschreibung, Host (für den Ping) und den Zugriffspfaden aufgelistet werden.

HAC_Config

Ich freue mich, falls ich hier oder dort jemanden auf eine Idee gebracht habe. Den Code dazu plane ich auf einer der gängigen Open Source Plattformen zu veröffentlichen; falls jemand unmittelbar damit starten möchte, sprecht mich bitte an.