Exchange Server Dashboards mit ELK (ElasticSearch, Logstash, Kibana) Teil 1

Leider bietet Exchange Server keine Build-In Möglichkeit um den Status der Umgebung oder bestimmte Leistungsparameter übersichtlich auf einem Dashboard darzustellen. Auch viele Monitoring Tools kommen hier schnell an ihre Grenzen, wenn es darum geht, beispielsweise die Anzahl empfangener oder gesendeter E-Mails übersichtlich darzustellen.

In dieser Artikelserie möchte ich daher einmal ELK, bzw. den Elastic Stack als mögliche Option für Dashboards in Verbindung mit Exchange Server vorstellen.

Vielleicht kann ja jemand damit ebenfalls etwas anfangen, oder über seine Erfahrungen berichten.

Einleitung

Vor Kurzem hatte ich schon einen Artikel zu Dashboards und Exchange Server veröffentlicht. Dank einer Artikelserie von Jan Kappen bin ich auf das Thema Grafana und InfluxDB aufmerksam geworden und habe es entsprechend für Exchange Server adaptiert. In meiner kleinen Home-Umgebung läuft dies auch absolut zuverlässig mit ein paar kleinen PowerShell Scripts, welche die Daten in der InfluxDB speichern. Die Scripts werten die beispielsweise die Message Tracking Logs aus und senden entsprechende Werte an die InfluxDB.

In einer größeren Umgebung funktioniert das Durchsuchen der Exchange Message Tracking Logs und das Speichern der Daten in InfluxDB allerdings eher suboptimal. Eine der Ursachen: Das Durchsuchen der Message Tracking Logs via PowerShell (get-messagetrackinglog) und die Aufbereitung ist einfach viel zu langsam. Dazu kommt, dass entsprechende Scripte in Intervallen laufen müssen und dadurch auch immer eine gewisse “Unschärfe” aufgrund der Laufzeit mit sich bringen (Überlappung der Laufzeit oder “blinde Flecken”).

Ich habe daher nach einer Möglichkeit gesucht, um die folgenden Probleme in den Griff zu bekommen:

• Get-MessagetrackingLog ist sehr langsam bei großen Datenmengen (beispielsweise großer Zeitraum und großes Mailaufkommen)
• Gewisse Unschärfe in den Daten aufgrund langer Scriptlaufzeit und erhöhte Systemlast

Trotzdem wollte ich natürlich schicke Dashboards zum aktuellen Status der Exchange Server.

Ich bin dann irgendwie beim ELK-Stack (Elastic Stack) hängengeblieben, da ich hier noch weitere Möglichkeiten und Anwendungsfälle ausgemacht hatte. Dazu gleich mehr.

Was ist ELK?

ELK, beziehungsweise der Elastic-Stack besteht im wesentlichen aus vier Komponenten:

• Elasticsearch: Eine “Suchmaschine” welche große Datenmengen, beispielsweise Logs, durchsuchbar macht
• Logstash: Empfängt Logs und Daten, bereitet die Daten auf und speichert diese in Elasticsearch
• Kibana: Das grafische FrontEnd zu Elasticsearch

Der neue Name von ELK ist eigentlich Elastic Stack, denn zu den schon genannten drei Komponenten ist mittlerweile eine vierte hinzugekommen:

• Beats: Sammelt Daten auf Quellsystemen und übergibt diese an Elasticsearch

BELK oder KELB hört sich irgendwie nicht so schön an, daher heißt es nun einfach Elastic-Stack.

Hier gibt es dazu weitere Informationen dazu:

• What is the ELK Stack?

Meine Anwendungsfälle

Meine Motivation für diese Artikelserie ist folgende:

• Ich möchte ein System haben, welches es ermöglicht die Exchange Message Tracking Logs, möglichst schnell zu durchsuchen. Wer einmal in einer größeren Umgebung die Message Tracking Logs in einem längeren Zeitraum auswerten musste, weiß was ich meine.
• Ich möchte unterschiedliche Dashboards für unterschiedliche Benutzergruppen erstellen. Als Admin ist es wichtig, den aktuellen Status im Blick zu haben um frühzeitig Probleme erkennen zu können, während sich andere Anwender für ganz andere Metriken interessieren. Beispielweise wie viele Mails an eine Support Adresse geschickt wurden.
• Am liebsten möchte die Daten von allen Mailgateways in einer Oberfläche haben, so muss nicht erst auf den verschiedenen Gateways geprüft werden, ob die Mail eingegangen ist und was mit der Mail passiert ist.

Dies ist im wesentlichen erst einmal dass, was ich erreichen möchte. Leistungsdaten der Server oder Ereignisprotokolle stehen hier erst einmal nicht im Fokus. Man könnte es also als kleine Insellösung für das Message Tracking sehen.

Hinweise zu dieser Artikelserie

Die Systemanforderungen an den Elastic Stack sind deutlich höher als an eine Grafana / InfluxDB Installation. Während sich InfluxDB und Grafana mit recht wenig Ressourcen betreiben lassen, sieht es beim Elastic Stack schon ganz anders aus.

Ich würde an dieser Stelle allerdings Äpfel mit Zitronen vergleichen. zwar können mit Grafana und Kibana moderne Dashboards erzeugt werden, die Funktionsweise und der Ansatz ist aber verschieden. Bezogen auf das Endprodukt “Dashboard” können Grafana und Kibana zwar ähnliche Ergebnisse liefern, jedoch kann Elastic Stack und “Grafana mit InfluxDB” hier kaum miteinander verglichen werden. Es handelt sich hierbei einfach um zwei komplett verschiedene Produkte, ich denke in den folgenden Artikel wird dies etwas klarer werden. Der Hinweis soll einfach nur nur Abgrenzung dienen, da ich eingangs Grafana erwähnt hatte. Welchen Weg man wählt, bleibt jedem selbst überlassen. Dies ist ja auch nur einer von vielen.

Die spannenden Teile folgen, wenn sie fertig sind…