In servereye gibt es derzeit über 500 fertige Sensoren. Viele wurden zusammen mit Herstellern erarbeitet, viele in Eigenregie und mit eigener Analyse.
Doch welche Möglichkeiten hat man, wenn kein fertiger Sensor für mein Produkt / meine Hardware existiert? Viele! Sehr viele sogar und damit Sie einen Überblick erhalten, was genau möglich ist, zeige ich Ihnen einmal, welche Monitoring Schnittstellen in servereye existieren.
Bevor wir in die Details gehen, schauen wir uns die möglichen Schlagworte an. Hersteller, die folgende Schnittstellen bieten, können auch ohne fertigen Sensor in servereye integriert werden:
- SNMP
- WMI
- PowerShell
- Rest-API / API
- Logdateien
- Ereignisanzeige
- CLI (Command Line Interface)
Wenn Ihr Hersteller also solche Möglichkeiten bietet, ist die Chance sehr hoch, dass Sie recht einfach und schnell das Monitoring selbst aufsetzen können.
1. Vorbereitung / Vorgehensweise
Zuallererst sollten Sie bei uns einen Featurewunsch einreichen. Fordern Sie vom Hersteller noch notwendige Daten an, wenn diese fehlen. (Dokumentation zu APIs, SNMP MIBs, usw.). Egal, ob Ihr expliziter Wunsch aktuell umsetzbar ist oder nicht, lassen Sie uns davon wissen. Nur dann können wir die Wichtigkeit im Gesamten bewerten und im besten Fall profitieren am Ende alle davon. Derzeit sind 80 % unserer Sensoren genau durch diese Kundenwünsche entstanden. Sie haben also schon mehr als einmal von dieser Vorgehensweise profitiert. Wenn Sie bei den Schnittstellen keine Informationen finden, kontaktieren Sie den Hersteller direkt. servereye bietet darüber hinaus die Möglichkeit, dass Hersteller einen eigenen Sensorhub erstellen.
Szenario: Firewall Hersteller bietet keine nutzbaren Schnittstellen.
Lösung: Weisen Sie den Hersteller darauf hin, dass wir eine Sensorhub API haben die es ermöglicht, eigene Werte im OCC bereitzustellen. https://github.com/servereye/c-sensorhub-api
Somit kann direkt auf der Firewall ein Modul laufen und der Hersteller Gesundheitswerte an das OCC senden und speichern.
2. Auswertung der Schnittstellen
2.1 SNMP
SNMP finden Sie vor allem in Netzwerkgeräten, wie Switches oder Drucker, vor. Aber auch USV/Firewalls nutzen dies oft, um interessante Werte bereitzustellen. Diese Werte liefert der Hersteller oft in Form einer MIB Tabelle. Dort sind sogenannte OIDs enthalten. Das sind eindeutige IDs, die abgefragt werden können und hinter denen Werte stehen. Dies kann beispielsweise der Status eines Netzteils sein.
Im Falle eines Featurewunsches senden Sie uns wie folgt diese MIB Tabelle und einen SNMP Walk (Abruf aller SNMP Daten) zu.
https://servereye.freshdesk.com/a/solutions/articles/14000038937
Wie Sie selbst diese OIDs für eine eigene Überwachung in servereye nutzen können, finden Sie ausführlich beschrieben in unserem Blogartikel:
https://www.servereye.de/blog/schritt-fuer-schritt-snmp-fuer-individuelle-ueberwachungen-nutzen/
Dies scheint anfangs komplex und aufwendig zu sein. Sie werden aber schnell sehen, dass gar nicht so viel dahintersteckt und Sie schnell Erfolge erzielen können.
2.2 WMI
WMI (Windows Management Instrumentation) ist ein in Windows integriertes Werkzeug. Ziel ist es, wichtige Informationen abzurufen und zu verwalten. Viele Daten sind darüber abrufbar oder sogar veränderbar, wie zum Beispiel das Security Center, Windows Defender oder Festplatteninfos. Mittlerweile wird diese Schnittstelle aber immer mehr von der PowerShell abgelöst, auch wenn die PowerShell oftmals im Hintergrund noch WMI Aufrufe durchführt.
Die Abfragen gleichen dabei einem SQL Syntax, denn der Aufbau ähnelt einer Datenbankstruktur.
Ein Beispiel, wie Sie die Festplattenauslastung über die WMI messen können, finden Sie hier: https://www.servereye.de/blog/festplattenauslastung-messen/
2.3 PowerShell / Rest-API / API
Die PowerShell ist ein sehr mächtiges Interface. Es lassen sich nicht nur viele Windows Funktionen verwalten, sondern viele Hersteller bieten mittlerweile auch eigene Module wie beispielsweise VMware, Xen, Datacore oder Veeam, an. Durch einfache Befehle, wie Get-Process oder Set-Process, lassen sich Daten abrufen oder verändern. Richtig gewaltig wird das Ganze aber erst, wenn man Skripte erstellt. Also viele Abfragen in eine logische Struktur bringen.
Diese Skripte können Sie direkt in servereye integrieren und dadurch quasi eigene Sensoren bauen. Die Komplexität ist nur durch Ihren Zeitaufwand begrenzt. Eine Anleitung, wie Sie eigene Sensoren mit PowerShell in servereye erstellen, finden Sie hier:
Erweiterter PowerShell Sensor
https://servereye.freshdesk.com/a/solutions/articles/14000035882
Sie können über die PowerShell sogar Funktionen abbilden, die Sie vielleicht aktuell im OCC für sich vermissen oder abbilden wollen. Dank dem PowerShell Helper haben Sie Zugriff auf die API von servereye und können alle Daten aus dem OCC verarbeiten und aufbereiten. Viele Beispiele dazu finden Sie in unserem FAQ Bereich:
Aktueller Stand eines Click Zählers
https://servereye.freshdesk.com/a/solutions/articles/14000087119
Anleitung – Auflisten aller Sensorvorschläge der Sensorhubs (mit Export in Excel)
https://servereye.freshdesk.com/a/solutions/articles/14000092993
Rest-API oder andere API lassen sich ebenfalls über die PowerShell einfach nutzen und abbilden. Daher sind solche Schnittstellen bevorzugt darüber zu nutzen. Eine einfache Übersicht über REST und PowerShell findet sich wunderbar erklärt bei MSXFAQ. (https://www.msxfaq.de/code/rest.htm)
2.4 Logdateien
Viele Anwendungen haben „versteckte“ Schnittstellen. Dazu gehören auch Logdateien. Sie sind leider oftmals schwieriger zu analysieren, da Daten nicht immer in einem programmatisch erfassbaren Format gespeichert werden. Aber es gibt trotzdem Wege, wie Sie Schlüsselwörter und damit einige Szenarien, sehr einfach abbilden können. Beispielweise Backup Logs oder Datenbank Dumps. Mit unserem „Ultimativen Logsensor“ können Sie so ziemlich alle Szenarien rund um Logdateien abbilden und vielfältig einsetzen. Wie dies an einem Beispiel der Software ZD-Backup aussieht, finden Sie hier:
https://www.servereye.de/blog/zd-backup-ueber-ultimative-logueberpruefung-ueberwachen/
2.5 Ereignisanzeige
Genauso wie Logdateien bieten viele Produkte eine Protokollierung ihrer Fehler/Erfolge in der Windows Ereignisanzeige (Eventlog). Dies kann man sich mit Filtern nutzbar machen, die direkt in der Ereignisanzeige konfiguriert werden. Das ist sehr einfach und Ergebnisse sind direkt einsehbar. Diese Filterdefinition ist dann 1:1 in servereye nutzbar und überwachbar. Am Beispiel des Produktes Ahsay Backup zeigen wir dies in unserem Blog auf:
https://www.servereye.de/blog/ahsay-backup-ueber-ereignisanzeige-integrieren/
2.6 Command Line Interface
Eine gute CLI eines Herstellers ist Gold wert. Wenn diese dazu noch einen Export/Anzeige der Daten in einem programmatisch lesbaren Format darstellt, umso besser. Sie können natürlich auch hier wieder ein PowerShell Skript erstellen, welches verschiedene CLI Befehle ausführt und die Ergebnisse auswertet. Auch für uns ist es dann sehr gut möglich, am besten an Hand einer Dokumentation, einen Sensor zu erstellen. Manchmal liefern CLIs aber auch Exit Codes. Dies kann man sich über die geplanten Tasks zu nutzen machen. Führen Sie regelmäßig den Befehl über das CLI aus und überwachen Sie den Task in servereye mit unserem Sensor „Geplante Tasks“.
Sollten Sie also ein Feature in servereye vermissen, stehen Ihnen vielfältige Möglichkeiten zur Verfügung. Nutzen Sie die Option, Ihren Hersteller auf diese aufmerksam zu machen. Denn je besser die Schnittstelle in der Software oder dem Produkt ist, desto einfacher ist es für uns das Produkt zu integrieren.