PRTG MRS-Counter

Die Migration nach Exchange 2010 und neuer übernimmt in den meisten Fällen der "Mailbox Replication Service". Die Aufträge werden mittels New-MigrationBatch oder New-MoveRequest beauftragt und dann legt der MRS im Hintergrund los. Ich würde aber schon gerne wissen, wie viele Job aktuell welchen Status haben und welchen Durchsatz ich pro Server und insgesamt erreiche. Diese Sensoren beschreibe ich auf der Seite.

Zwei Sensoren, eine Quelle

Es gibt zwei Dinge, die ich gerne überwachen möchte und da es für beide komplett unterschiedliche Datenquellen gibt, habe ich zwei Sensoren gebaut.

  • MRSJobCounter
    Dieses Skript nutzt die Exchange PowerShell um über "Get-Moverequest" eine Liste der aktuellen Jobs samt Status zu erhalten und zu jedem Status die Anzahl der Jobs an PRTG zu melden.
  • MRSCounter
    Dieses Skript ermittelt die Performance Counter einer übergebenen Liste von Servern und berichtet den Durchsatz pro Server und in der Summe

Beiden Sensoren gemein ist aber, dass Sie nicht von PRTG zyklisch gestartet werden. Ich habe die Erfahrung gemacht, dass PRTG zwar gut ist, aber man mit wenigen Probe-Systemen nicht alle Server im LAN per PowerShell, WMI o.ä. überwachen kann. Mittlerweile gibt es mit den PRTG:HTTPPush-Sensoren aber eine elegante Möglichkeit die Ermittlung der Daten auf einem Server ausführen zu lassen und die Daten per HTTP an PRTG zu senden. Beide Sensoren arbeiten nach dem Prinzip und werden z.B. auf einem Server als "geplanter Task über den Windows Taskplaner gestartet. Sie belasten damit PRTG nur minimal.

MRSJobCounter

Wenn wir uns eine Grafik des Sensors MRSJobCounter anschauen, dann könnte folgendes Bild erscheinen. Hier scheinen fast 500 Jobs in dem Status "Autosuspended" zu stehen

Dann kommt unten kein kleiner Berg der bis zu 158 Jobs anzeigt, die hier gleichzeitig "in Progress" sind. Der MRS scheint die beauftragen Jobs sehr schnell anzugehen, so dass die Linie "Queued" gar keine Change hat höher zu werden. Nach etwas mehr als einer Stunde sind die Jobs in den Status "AutoSuspend" gewechselt. Die obere Linke ist entsprechend angestiegen. Gegen 10:15 abends kommt dann wieder Leben in die Migration. Hier dürfte ein "Autocomplete after" aktiv geworden sein. Es gibt noch einen kleinen Berg da einige Postfächer noch Änderungen haben. Aber sehr schnell werden die Jobs abgeschlossen und ca. 15 Min später hat die dunkelblaue "Completed" Linie ihr Niveau erreicht.

Manchmal sollte ein Admin dann natürlich diese "completed" Jobs wieder entfernen, dass die Skalierung nicht verzerrt wird.

MRSCounter

Daneben gibt es ein zweites Skript, welches von den MRS-Servern einer Liste ein paar Performancedaten ausliest. Diese Daten wurden zur gleichen Zeit ermittelt und zeigen daher gut den Einfluss der Migration auf die CPU-Last. Die durchgehend sichtbare dunkelgrüne Linie ist die der Mittelwert der CPU-Last alle Server.

Sie sehen etwas gegen 3:30 einen starken Anstieg der Durchsatzrate von "Total MRSTransmit" (Lesen von einem Quellserver) und das Schreiben mit "Total MRSWrite". All diese Werte sind die Summe der Einzelcounter aller Server. Hier ist also zu sehen, dass diese kleine Migration mit bis zu 20Megabyte/Sek die Postfächer verschoben hat. Aber selbst der Mittelwert, der bei 8-10Megabyte/Sek liegt, ist nicht zu verachten. Die Leistung könnte höher sein, wenn die Quell-Server denn liefern könnten. Wir haben auch schon Spitzenwerte (jeweils Momentaufnahmen im 5 Min Takt) von 80Megabyte/Sek erreicht. Nur gut zu wissen, dass der MRS sich selbst überwacht um die Quelle aber auch das Ziel nicht über Gebühr zu strapazieren. Wenn also der Content Index nicht mehr mitkommt, dann wird eben etwas langsamer migriert.

Download

Die beiden Skripte sind einfache Powershell-Dateien.

prtg-mrscounter.1.0.ps1.txt

prtg-mrsjobcounter.1.0.ps1.txt

Kopieren Sie diese nach dem Download auf einen Server und entfernen Sie das ".TXT" am Ende.

Einrichtung

Eine "Installation" der der klassischen Weise gibt es nicht.

  1. Ausführender Servet
    Sie suchen sich einen Server, auf dem die Exchange PowerShell vorhanden ist. Das kann der PRTG-Server sein, es kann aber auch jeder andere Server sein. Ich nutze gerne einen Exchange Server, da hier die Komponenten aktuell sind und die Zugriffe lokal erfolgen. zudem kann ich als Exchange Admin das Skripte jederzeit anpassen und muss nicht auf dem PRTG-Server arbeiten, zudem ich vielleicht gar keine Rechte habe
  2. Parameter
    MRSJobCounter benötigt die URL für eine Exchange PowerShell und MRSCounter benötigt eine Liste der Server, auf denen der MRS-Service ausgewertet werden soll. In der Regel werden Sie das Skript dazu editieren und in dem "Params"-Abschnitt die Werte anpassen. Auch die URL zum PRTG-Server und natürlich das TOKEN für die Identifizierung als HTTP-Push-Sensor muss editiert werden.
  3. Dienstkonto
    Das Skript muss unter einem Konto gestartet werden, welches natürlich die Rechte zum Zugriff auf die Informationen hat
  4. Taskplaner
    Dann fehlt nur noch die Einrichtung im Taskplaner, damit die Skripte mit der gewünschten Häufigkeit aufgerufen werden
  5. PRTG-Konfiguration
    Dann fehlt nur noch die Definition der HTTP Push Sensoren in PRTG, damit die gelieferten Daten auch aufgezeichnet und visualisiert werden. Leider gibt es in PRTG noch kein Automatismus, mit dem ein noch nicht bekannter HTTPPush-Sensor erkannt, gemeldet und mit einem Klick addiert wird, so wie es bei neuen Probes schon möglich ist.

Und dann brauchen Sie etwas Zeit, bis die ersten Messwerte eintrudeln. Sie können und sollten die Einstellungen natürlich noch um individuelle Warnschwellen erweitern. Allein ein Bild zu bekommen, auf welches ein Admin vielleicht einmal drauf schaut, ist nur die erste Hälfte. Mit der Definition von Grenzwerten für Kanäle können Sie entsprechende Warnungen verbinden und Betreiber umgehend informieren, wenn z.B. Jobs fehlgeschlagen.

Weitere Links