PRTG - Exchange Tracking

Wenn Sie PRTG noch nicht können, dann sollten Sie sich das Programm auf jeden Fall anschauen. Selbst die Freeware mit 10 Sensoren und 60Sek Mindestabfrageinvervall ist für die folgende Aufgabenstellung super geeignet. Wer mag kann aber auch MRTG, RRDTool oder andere Werkzeuge nutzen. Da sich viele Administratoren aber mit eigenen Skripten schwer tun, ist PRTG als GUI-Lösung mit einem eigenen Skript sehr einfach produktiv zu bringen.

Aufgabestellung

Ich wüsste gerne, wie intensiv mein Exchange Server genutzt wird. Die Auswertung muss dabei nicht auf den einzelnen Benutzer herunter gebrochen werden, auch wenn auch dies durch eine einfache Erweiterung möglich wäre. Es reichen folgende Daten

  • Anzahl der ausgehenden Mails
  • Anzahl der eingehenden Mails
  • Kilobyte der ausgehenden Mails
  • Kilobyte der eingehenden Mails
  • Anzahl der Fail, PoisonQueue, BadMail-Messages

Die Zahlen können mit PRT maximal alle 60 Sekunden erhoben werden. Aber eine solche Genauigkeit ist gar nicht erforderlich. Mir reicht es auch, wenn z.B. alle 5 Minuten diese Daten ausgelesen und in eine Grafik übertragen werden.

Da es sich bei dem Sensor um ein Skript handelt, ist natürlich eine Weiterentwicklung möglich. Denkbar wäre die Filterung auf bestimmte Spezialpostfächer (Support, Vertrieb) oder die Trennung nach Systemmessages (PF Replikation), Trennung nach SameServer, SameSite, SameOrg, Internet oder andere Kennzeichen. Die Anwendungsfälle sind beinahe grenzenlos.

Messagetracking per PowerShell

Ich beschränke mich auf Exchange 2007 und neuer, da hier die PowerShell sehr einfache Werkzeuge zur Umsetzung bereit stellt. Folgender Einzeiler liefert alle Messages der letzten 5 Minuten.

get-transportserver | get-messagetrackinglog -start (get-date).addminutes(-5)

Damit kommen natürlich erst mal alle Messages mir und ich muss mir überlegen, ob ich über den Parameter "EventID" die Ergebnisse filtere und das Skript dann mehrfach aufrufe, oder ob ich mit einem Aufruf alle Einträge der letzten 5 Minuten sammle und in der For-Schleife beim Aufsummieren abhängig von der EventID einfach die richtigen Counter addieren. Ich habe mir für den zweiten Weg entschieden. Es ist zwar etwas "ungenauer" aber dafür muss ich nichts zwischenspeichern.

Es ist durchaus denkbar, dass es später mal eine Version 2 dieses Skripts gibt, welches die Mails seit dem letzten Aufruf ermittelt und dann vielleicht auch noch all die andere Übertragungsparameter getrennt erfasst, z.B. Anzahl der unzustellbaren Mails, Fehlerhaften Mails etc.. Exchange hat ja durchaus noch einige andere Kriterien (BadMail, Defer Deliver, DSN, Expand, Fail, PoisonMessage, Receive, Redirect, Resolve, Send, Submit und Transfer)

Ausgabe

Das Skript erstellt eine XML-Datei, die von PRTG ausgelesen werden kann. Hier ein Beispiel:

<prtg>
	<result>
		<channel>Sendcount</channel>
		<value>0</value>
		<showChart>1</showChart>
		<showTable>1</showTable>
		<unit>Count</unit>
		<customunit>Mails</customunit>
		<mode>Absolute</mode>
	</result>
	<result>
		<channel>Sendkbytes</channel>
		<value>0</value>
		<showChart>1</showChart>
		<showTable>1</showTable>
		<CustomUnit>kB</CustomUnit>
		<mode>Absolute</mode>
	</result>
	<result>
		<channel>Receivecount</channel>
		<value>0</value>
		<showChart>1</showChart>
		<showTable>1</showTable>
		<unit>Count</unit>
		<customunit>Mails</customunit>
		<mode>Absolute</mode>
	</result>
	<result>
		<channel>Receivekbytes</channel>
		<value>0</value>
		<showChart>1</showChart>
		<showTable>1</showTable>
		<CustomUnit>kB</CustomUnit>
		<mode>Absolute</mode>
	</result>
	<result>
		<channel>Totalkbytes</channel>
		<value>0</value>
		<showChart>1</showChart>
		<showTable>1</showTable>
		<CustomUnit>kB</CustomUnit>
		<mode>Absolute</mode>
	</result>
	<result>
		<channel>Totalcount</channel>
		<value>0</value>
		<showChart>1</showChart>
		<showTable>1</showTable>
		<unit>Count</unit>
		<customunit>Mails</customunit>
		<mode>Absolute</mode>
	</result>
	<text>Exchange Message Tracking Data Ver1.1 Errorcount:0</text>
</prtg>

Das Skript ersetzt natürlich die Werte und Auch den Error-Count..

Eine gewisse Ungenauigkeit bleibt natürlich bei dieser Verwendung. Da PRTG sicher nicht "sekundengenau" den Sensor startet und die Initialisierung der Exchange Module etwas braucht, können durchaus einige Message doppelt gezählt (zu früher aufruf) oder bei verspätetem Aufruf übersehen werden. Eine Sicherung dieser Funktion, indem sich das Skript den letzten Moment merkt, habe ich nicht eingebaut. Zudem dann die Anzahl sehr hoch werden würde, wenn der PRTG-Dienst mal einige Zeit (z.B. Windows Updates) nicht läuft.

Einrichtung

Ich habe ihnen den Beispielcode hier zum Download bereit gestellt

prtg-exchangemtrack.1.4.ps1
Nach dem Download die Extension ändern und im Explorer die Datei "unblocken"  (Da Download aus dem Internet)

Die Einrichtung ist schnell erzählt.

  1. Kopieren der PS1 nach C:\Program Files(x86)\prtg\custom sensors\exexml
    In diesem Verzeichnis sucht die Probe nach den Skripten. Beachten Sie, dass das Skript auf dem Server installiert werden muss, auf dem die Probe dieses Skript aufruft
  2. Anpassen des PS1 (Exchange WebService path)
    Wenn Sie die URL zum Exchange PowerShell Service nicht per Parameter angeben, sollten Sie diese im Skript codieren. Es ist kein Automatismus programmiert, der einen "passenden" CAS-Server sucht.
  3. Anlegen eines neuen Device
    Sensoren werden immer einem Device zugeordnet. Auf der Ebene des Device kann dann auch der Benutzername und das Kennwort angegeben werden, mit dem das Skript später gestartet wird. Ich lege daher in der Regel ein Device mit dem Namen des CAS-Servers oder CAS-Array an, gegen den am Ende auch das PowerShell-Skript arbeitet.
  4. Anlegen eines neuen Sensors (Exe/Script Advanced)
    Unter dem Device lege ich dann einen neuen Sensor vom Typ "Exe/Script Advanced" an, der die folgenden wesentlichen Werte hat.

    Wichtig ist hier die Auswahl des Skript aber auch die Angabe mit welchen Anmeldeinformationen das Skript gestartet wird und wie oft es ausgeführt werden soll. Als "LocalSystem" funktioniert das Skript nur, wenn die Probe direkt auf einem Exchange Server aktiv ist bzw. der Computer Mitglied der "Exchange Server" ist. Aufgrund der Laufzeit sollten Sie das Skript nicht jede Minute starten. Ich arbeite mit 5 Minuten und erwarte, das das Skript nach maximal 100 Sekunden zum Ende kommt.

Und dann heißt es warten bis die ersten Zahlen "kommen". In der Übersicht sollten Sie als erstes sehen, wann der Sensor das letzte mal gelaufen ist und welche Werte beim letzten Lauf ermittelt wurden:

Warten Sie einfach ein paar Tage und so langsam "bilden" sich die Diagramme mit echten Werten. Diese Ansicht wurde mit der "History"-Funktion erstellt.

Aufgrund der Besonderheit von PRTG alle Werte zu mitteln, muss man bei der hier dargestellten 5-Tages-Ansicht natürlich noch mal in der Tabelle genau schauen, wie viele Einzelmessungen zusammengefasst wurden und entsprechend die Zahlen multiplizieren. Hier sieht man Rechts den Ende eines Donnerstag und ein "normaler Freitag". Dann sind Sa/So kaum Mails unterwegs und der Montag ist fast vorbei.

Einschränkungen

Dass die Wurzeln von PRTG im Bereich der Netzwerke sind, in denen "Mittelwerte" weit häufiger gebraucht werden, ist leider für ein paar Einschränkungen verantwortlich.

  • Mittelwerte statt Summen
    Auch wenn das PowerShell-Skript die Zahlen korrekt ermittelt und Sie damit z.B.: die Anzahl der Mails/5Min erhalten, so sehen Sie diese Daten in der Live-Ansicht aber nicht mehr in den Zusammenfassungen für 2 Tage/30 Tage/365/Tage. PRTG hat die Eigenschaft, die Werte für die Intervalle als "AVERAGE" auszugeben. Alle Werte eines Intervalls werden also aufaddiert und dann durch die Länge des Intervalls geteilt.
    Wer also vier Messungen mit vielleicht 10,40,30,20 Mails ermittelt hat, sieht in der größeren Übersicht dann eben nur 25 Mails/Zeit und nicht 100 Mail. Sie können sich behelfen, indem Sie die Werte bei der Stundenauflösung eben mit 12 (60Min/5Min) multiplizieren.
    Mir wäre es persönlich lieber, wenn die Einzelwerte einfach aufaddiert werden (Total).
    Wenn man den Sensor auf "Difference" statt "Absolute" stellt, dann ändert PRTG zwar die Ausgabe und zeigt neben Mittelwerten auch Summen an, aber dann müsste das Skript die Eingabedaten anders aufbereiten.
  • Kein "Maximum"
    Durch die Mittelwerte "verschwinden" natürlich auch die Spitzen. Ich würde mir wünschen, dass in einer Grafik neben den aufsummierten Werten optional auch das Maximum einer Einzelmessung in der zusammengefassten Periode sichtbar wird. Ein 365Tage Bild wird wenig aussagen, wenn alle Werte einfach durch Mittelwerte "glattgebügelt" werden.
  • 5Min sind nicht 5 Min, kein Accounting
    Weiter oben habe ich schon geschrieben, dass die 5Min Intervalle nicht genau eingehalten werden. Schon das initialisieren der PowerShell zu Exchange dauert unterschiedlich lange. Insofern können Mails übersehen oder doppelt gezählt werden. Erwarten Sie also nicht, dass die Summen auch mit ihrer Internetbandbreite genau übereinstimmen.
    Eventuell ändere ich das Skript später einmal, um den Zeitpunkt der letzten Messung zu speichern und beim nächsten Aufruf dort wieder aufzusetzen. Das hätte auch den Vorteil, dass das Volumen etwa stimmt, wenn das Skript einige Stunden nicht läuft.

Mit diesen Einschränkungen kann ich aber noch ganz gut leben, da die durchschnittliche Verwendung von Exchange so immer noch gut ersichtlich ist.

Geplante Erweiterungen

Wie schon an anderer Stelle geschrieben, habe ich vor, bei Gelegenheit z.B. die Replikationsmeldungen von öffentlichen Ordnern separat auszuweisen. Ebenso wären alle unzustellbaren Mails ein interessanter Kanal.

Weitere Links