Monitoring eines S2D Clusters mit Grafana, InfluxDB und PowerShell (Teil 2) | Hyper-V Server Blog

Monitoring eines S2D Clusters mit Grafana, InfluxDB und PowerShell (Teil 2)

Hallo, Jan hier mal wieder. Ich komme endlich mal dazu, den Artikel zum Monitoring von S2D mittels Grafana und InfluxDB weiter zu schreiben. Im ersten Teil ging es um die grundsätzliche Einrichtung von Datenbank, Grafana und der Erstellung des ersten Dashboards.
Im diesem zweiten Teil werden wir uns mal anschauen, wie wir relevante Daten einsammeln und mittels Grafana visualisieren.

Update von Grafana

Der letzte Beitrag ist ein bisschen her, daher gibt es auch schon wieder Updates für die von mir genutzte Installation. Das Debian als Basis ist bereits aktuell, allerdings gibt es eine neue Version Grafana. Diese bekommen wir immer von der Hauptseite, dort ist beschrieben wie man das aktuelle Paket zur Installation bekommt: https://grafana.com/grafana/download

Das eigentliche Update gestaltet sich recht einfach, hier zu müssen wir nur das Paket herunterladen und mittels dpkg installieren:

Klappt nach dem Update von ein Aufruf der Hauptseite und eine Anmeldung, scheint das Update geklappt zu haben. In diesem Fall können wir fortfahren mit der Einrichtung.

Einsammeln der Daten mittels Telegram Agent

Im ersten Teil hatten wir uns angeschaut, wie man mittels Influx-Modul per Windows PowerShell einen oder mehrere Werte ausliest und diese dann in die Influx-Datenbank schreibt. Diese Art von Daten sammeln ist nicht gerade ressourcenschonend, daher werden wir uns nun eine andere Möglichkeit anschauen: Telegraf.
Telegraf ist ein Agent, der von den Machern von InfluxDB (der genutzten Datenbank) zur Verfügung gestellt wird. Die Installation und die Nutzung ist ebenfalls kostenlos, nach einem Download und einem entpacken kann direkt losgelegt werden.

Download: https://portal.influxdata.com/downloads/

Zum aktuellen Zeitpunkt ist Version 1.13.3 die aktuelle Stabil-Version. Achtet bei dem Download darauf, vorne den Telegraf-Agent herunterzuladen und nicht eines der anderen Produkte.

Download und Einrichtung

Nach dem Download kann das Zip-Archiv entpackt werden. Damit konstant Daten abgerufen und in der Datenbank gespeichert werden, empfiehlt sich die Einrichtung als Dienst.

Laut der Installationsanleitung empfiehlt es sich, die Daten unter C:\Program Files\ in einem Ordner mit dem Namen Telegraf abzulegen. Das habe ich, wie man in dem Screenshot erkennen kann, gemacht. Nun kann der Dienst registriert werden:

C:\Program Files\Telegraf\telegraf.exe --service install --config "C:\Program Files\Telegraf\telegraf.conf"

Hat die Registrierung geklappt, kann der Dienst entweder per services.msc, per cmd oder per PowerShell gestartet werden.

Die Anpassung der Konfiguration

Die Datei telegraf.conf enthält die Steuerung für den Agenten. Schauen wir uns die Datei mal genauer an. Wichtig hierfür ist ein ordentlicher Editor wie Visual Studio Code oder auch notepad++, ein normales Notepad zerreißt ggf. die gesamte Formatierung und ist nicht zu brauchen.

Globale Einstellungen

Im oberen Teil der Konfiguration können wir im agent-Bereich diverse Optionen angeben, z.B. das Intervall. Damit legen wir fest, in welchem Abstand wir die Daten einsammeln und in die Datenbank schicken möchten. Hier sollten wir einen guten Abstand zwischen "zu selten" und "zu oft" auswählen. Sammeln wir zu selten Werte (z.B. nur alle 60 oder 90 Sekunden), können wir mögliche Ausschläge schlechter erkennen und die gemittelten Werte sind nicht realistisch. Fragen wir hingegen zu häufig Werte ab, erhöht dies die Belastung auf dem System und wir erzeugen künstlich Last.

Wir können mit den Werten jederzeit spielen und testen, das Intervall kann einfach durch diese eine Zeile angepasst werden. Starten wir erst einmal mit 2 Sekunden. Ich gehe nicht auf alle Möglichkeiten ein, nahezu alle Einstellungen sind beschrieben und erklärt. Primär gehe ich auf die Werte und Dinge ein, die ich gegenüber der Haupt-Konfiguration ändere.

OUTPUT PLUGINS

In diesem Bereich müssen wir einstellen, wie wir uns mit der Datenbank verbinden können. Hier tragen wir den Namen bzw. die IP vom Influx-Server ein, den Namen der Datenbank, die Zugangsdaten und auf Wunsch auch noch SSL/HTTPS-Einstellungen.
Mehr ist es dann auch erstmal nicht, damit eine eine grundsätzliche Verbindung zur Datenbank aufbauen können. Kommen wir nun zum spannendsten Teil, die Auswahl der Mess-Counter.

INPUT PLUGINS

Im unteren Teil der Konfigurationsdatei sind standardmäßig bereits einige Performance-Counter vorhanden, z.B. die Auslastung von CPU, RAM usw.

Wenn wir nun die Datei speichern und den Telegraf-Agenten starten (und wir uns nicht vertan haben bei Servername und den Zugangsdaten), sollten die ersten Daten in die Datenbank eingetragen werden. Dies können wir unter anderem probieren, indem wir in einem Dashboard eine neue Abfrage erstellen. Direkt nach der Erstellung einer neuen Query müssten wir unter FROM mehrere Einträge sehen, z.B. win_cpu.

Sind diese Daten vorhanden, funktioniert die Einspielung der Daten vom lokalen Knoten in die Influx-Datenbank. Nun können wir damit fortfahren, die benötigten Daten und Werte zusammenzubringen, die relevant sind bei dem Betrieb von einem S2D Cluster.

Die korrekten Werte

Bei einem Hyper-V Host, einem Failover Cluster Knoten und/oder einem S2D Cluster gibt es mehrere Werte, die interessant sind für die Betrachtung der Performance.
Zum einen wäre da die Auslastung der CPUs in den Hosts. Hier ist wichtig zu wissen, dass ein Hyper-V Host möglicherweise nicht korrekt anzeigt, wie seine wirkliche Auslastung ist. Dies liegt daran, dass das Management OS auf dem System nur "seinen" CPU-Wert anzeigt und nicht den Wert, der auf dem gesamten Host anliegt. Hier ein Beispiel mit konkreten Werten:

Wir sehen in diesem Screenshot sehr gut, wie sich der Wert "Hyper-V Hypervisor Logical Processor" vom Wert "Processor Information" unterscheidet. Der erste Wert ist auf die gesamte Hardware bezogen und spiegelt die Auslastung über alle VMs hinweg wieder, der zweite Wert ist "nur" die CPU vom Management OS. Hier sind die Werte nicht allzu weit voneinander entfernt und auch mehr als unkritisch, teilweise habe ich aber schon Systeme gesehen bei denen die Auslastung bei 80% oder mehr liegt und bei denen dies nicht wahrgenommen wurde, weil schlicht der falsche Werte überwacht wurde.

Ein weiterer Wert, der sinnvollerweise abgebildet werden sollte, ist die Auslastung des RAMs. Hier ist es deutlich einfacher, der Wert kann relativ einfach ausgelesen und angezeigt werden. Da nicht nur der frei RAM, sondern auch der belegte sowie der maximal verfügbare abgefragt werden kann, können hier auch recht einfach "gestackte" Anzeigen gebaut werden, d.h. freier RAM und belegter RAM können in Grafana übereinander gelegt werden, damit dann in Summe der maximal verfügbare Arbeitsspeicher eingesehen werden kann.

Die Auslastung sowie die Belastung der CSV-Datenträger sollte auch im Auge behalten werden, dies ist häufig die Ursache für Probleme oder Performance-Engpässe. Spontan interessante und aussagekräftige Werte ist der gesamte Speicherplatz, der freie bzw. belegte Speicherplatz und die Latenz beim Zugriff auf den Speicher. Eine Monitoring von Netzwerk-Komponenten wie den SMB-Karten, der vSwitch und den Karten allgemein kommt ebenfalls noch hinzu und sollten nicht vergessen werden.

Nachdem wir nun über einen Teil der interessanten Werte gesprochen haben stellt sich jetzt bestimmt die Frage: Wie bekomme ich diese Werte und was muss ich dazu anstellen?

Damit die Werte abgefragt und gespeichert werden können, müssen sie in der Konfigurationsdatei vom Telegraf-Agenten eingetragen werden. Da der Agent auf den Perfmon im Hintergrund zugreift, können die benötigten Werte (mehr oder weniger einfach) über den Perfmon bzw. die Windows PowerShell abgefragt werden.

Schauen wir uns mal einen kleinen Block an, der den Gesundheitszustand der VMs auf dem Host abfragt:

[[inputs.win_perf_counters.object]]
ObjectName = "Hyper-V Virtual Machine Health Summary"
Instances = ["------"]
Measurement = "hyperv.vm.health"
Counters = ["Health Ok", "Health Critical"]

Wir sehen hier in der ersten Zeile unter Objectname das Objekt, welches abgefragt wird. Der Name deckt sich mit dem Namen, der auch im Perfmon abgefragt und eingesehen werden kann. Wenn man nicht genau weiß, wie und was man überwachen soll, kann man hier sehr gut den Perfmon zur Hilfe nehmen und die Namen und Einträge einfach abpinnen.

Der Eintrag Instances fragt ab, welche Instanzen überwacht werden. Habe ich z.B. vier Netzwerkkarten in meinem Server verbaut, könnte ich mit einem "*" alle verfügbaren Karten abfragen. Sollen diverse NICs ausgelassen werden, z.B. die Isatap-Adapter usw., kann ich diese hier aktiv ausschließen. Die Nutzung von 6x "-" führt dazu, dass das Instanz-Bit entfernt wird.

Im oberen Beispiel führt dies z.B. dazu, dass nicht für jede einzelne VM ein Status in die Datenbank eingetragen wird, sondern das die Summe der VMs eingetragen wird. Gebe ich diesen Wert später im Grafana aus, sehe ich immer die Gesamtzahl aller gesunden VMs sowie die Gesamtzahl aller kritischen VMs. Ich könnte diese Summierung natürlich auch später im Grafana machen, da wäre es dann aber mehr Aufwand. Man muss bzw. kann immer pro Abfrage entscheiden, ob man die einzelnen Werte in die Datenbank schreibt oder die Gesamtsumme.

Unter Measurement kann ich angeben, unter welchem Namen die Daten abgespeichert werden. Später in meiner Abfrage (Query) im Grafana sehe ich diesen Namen wieder. Je deutlicher dieser Name gewählt wird, desto einfacher komme ich später bei dem Aufbau der Dashboards zurecht. Der aktuell gewählte Name "hyperv.vm.health" sagt eigentlich schon sehr deutlich aus, was genau hier abgefragt wird.

Zu guter Letzt muss mit Counters ausgewählt werden, welche Daten abgefragt und gespeichert werden. Diese Informationen kann ich ebenfalls sehr gut über den Perfmon abfragen und einsehen, man sieht in dem Screenshot weiter oben die hier angegebenen Counter "Health OK" und "Health Critical".

Wird dieser Block in die Config-Datei eingearbeitet, gespeichert und der Dienst wird kurz durchgestartet, sollten kurz darauf die ersten neuen Einträge in der Datenbank sichtbar sein und über Grafana visualisiert werden können.

Ganz einfach zusammengesetzt kann dies dann z.B. so aussehen:

Bei der Gestaltung der Kacheln sind mehr oder weniger keine Grenzen gesetzt, eine sehr schicke Möglichkeit zur besseren Darstellung ist die Möglichkeit, dass bei "VMs Critical" alle Zahlen größer als 0 direkt Rot angezeigt werden. Wer möchte schon kritische VMs haben ;)

Und welche Werte brauche ich jetzt WIRKLICH?

Microsoft hat in den Docs ein sehr gutes Dokument veröffentlicht, welches einige relevante Werte bei dem Betrieb von Hyper-V aufführt: https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/hyper-v-server/detecting-virtualized-environment-bottlenecks

Hier sind einige gute Werte sowie Grenzwerte aufgeführt, die in einer Umgebung sinnvollerweise nicht überschritten werden sollten. Welche Werte die richtigen für genau euren Bedarf sind kann ich hier nicht generell sagen, das kommt immer auf die Umgebung an. Bei 15 Systemen werden vermutlich 16 unterschiedliche Konfigurationen herauskommen :)

Sehr gut. Und wie bekomme ich die Namen alle raus?

Um die Namen der einzelnen Werte nicht abtippen zu müssen , kann man sich die PowerShell zur Hilfe nehmen. Wenn ich nun z.B. herausgefunden habe, dass ich gerne einzelne Werte aus dem Satz "Cluster CSVFS" haben möchte, kann ich mir diese anzeigen lassen mit

(Get-Counter -ListSet "Cluster CSVFS").Paths

Diese Ausgabe kann ich nun benutzen, um in meiner telegraf-Konfiguration einen neuen Block einzufügen, der die gewünschten Werte abfragt. Da ich immer alle CSV-Datenträger einlesen möchte, wird bei Instances der Wert "*" eingetragen. ObjectName und Measurement kann ich frei wählen, unter Counters werden dann die gewünschten Counter eingetragen.

[[inputs.win_perf_counters.object]]
  ObjectName = "Cluster CSVFS"
  Counters = ["Write Bytes/sec", "Read Bytes/sec", "Writes/sec", "Reads/sec", "Current Write Queue Length", "Current Read Queue Length"]
  Instances = ["*"]
  Measurement = "cluster.storage.csvfs"

So füllt sich dann nach und nach die Konfigurationsdatei und die Werte werden in dem von uns definierten Intervall abgezogen und in die Datenbank geschrieben.

Dateien und Dashboards

Die Datei, die ich während dem Schreiben von diesem Artikel zusammengetragen habe, sieht wie folgt aus:

Das erstellte Grafana-Dashboard sieht wie folgt aus:

Falls jemand das fertige Dashboard als JSON-Datei haben möchte:

Download: Grafana-JSON-File

Wenn ihr für euch ebenfalls ein Dashboard baut und Werte abfragt, könnt ihr diese gerne hier teilen und anderen Lesern die Arbeit ein bisschen leichter machen. Einfach einen kurzen Kommentar dalassen und auf eure Konfig-Datei verweisen. Wenn Fragen sind könnt ihr diese natürlich ebenfalls gern hier in den Kommentaren schreiben, ich lese hier immer noch mit :)

Jan Kappen
 

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitete bis August 2018 bei der Rachfahl IT-Solutions GmbH & Co. KG. Seit September 2018 arbeitet er als Senior Netzwerk- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland. Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure. Seit 2015 wird Jan Kappen im Bereich "File System Storage" bzw. "Cloud & Datacenter Management" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

  • HeissF sagt:

    Hi! Toller Post, der eine geniale Idee erklärt! Allerdings möchte ich eines anmerken, das mir gerade aufgefallen ist beim nachbauen – beim Erstellen von user und db in influx – im ersten Teil – ist was durcheinander gekommen, statt:

    influx
    CREATE USER “username” WITH PASSWORD ‘password’ WITH ALL PRIVILEGES
    CREATE DATABASE “Datenbankname”
    exit

    muss es:

    influx
    CREATE DATABASE “Datenbankname”
    use Datenbankname
    CREATE USER “username” WITH PASSWORD ‘password’ WITH ALL PRIVILEGES
    CREATE DATABASE “Datenbankname”
    exit

    heißen.

  • >