End2End MSXLatenz

Auf der Seite Ende zu Ende Monitoring habe ich beschrieben, dass ein einfaches Überwachen von Performance Countern  und des Eventlogs nicht alles ist, um die Leistung eines Servers zu überwachen. für eine komplette Überwachung und Bewertung der Leistung müssen auch Teste her, die die Antwortzeit beim Client entweder selbst müssen oder Messwerte des Clients einsammeln.

Outlook 2003 ist nun der erste Client, welcher mit jeder Anfrage an den Server die benötigte Zeit der vorherigen Anfrage wieder an den Server zurückmeldet und Exchange 2003 stellt eben diese Zahl in einem WMI-Counter bereit. Es war also nur eine Frage der Zeit, bi sich ein passenden VBScript erstellt habe, welches sich auf diesen WMI-Counter registriert und jede Meldung des Servers erhält, gegen Grenzwerte prüft und bei Bedarf eben auch alarmiert.

Dieses Skript funktioniert nur mit Exchange 2003 und Outlook 2003, da die erforderliche Schnittstelle erst mit Exchange 2003 per WMI erreichbar und in Exchange 2007 nicht mehr vorhanden ist.

Exchange 2007 stellt das PowerShell-Kommando "Test-MapiConnectivity" bereit, welches die Antwortzeit des Servers auf eine MAPI-Verbindung ermittelt.

Seit Exchange 2010 SP1 gibt es ein ähnliches Commandlet
Get-StoreUsageStatistics
http://technet.microsoft.com/en-us/library/dd876852.aspx

Die Anzeige im System-Manager

Dieses Skript macht sich die Eigenschaft zunutze, dass Exchange 2003 von Outlook 2003 die Laufzeit des vorletzen Befehls mit dem Folgepaket übermittelt bekommt. So kann mit einem Paket Verzögerung die vom Benutzer erlebte Antwortzeit ermittelt werden. Exchange 2003 stellt diese Daten allerdings nur per WMI bereit, so dass klassische Überwachungsprogramme per SNMP oder PERFMON darauf erst einmal keinen Zugriff haben. Selbst wenn ein Programm WMI verwendet, so nutzt es meist die Aufzählung, welche kein aktuelle Bild ergibt und das System unnötig belastet.

Der Exchange System Manager erlaubt z.B.: die Anzeige dieser Daten:

Wartezeit im ESM 

Die entsprechenden Spalten können Sie einfach über die Ansicht einblenden lassen. Das ist natürlich nur eine Momentaufnahme und jeder Druck auf "Aktualisieren" belastet den Server und wirbelt die Sortierung wieder durcheinander.

Der Abruf per Skript

Sicher kann man diese Lösung auch mit C++ oder C# schreiben und als EXE oder sogar Dienst kompilieren. Aber so arg viel langsamer ist ein VBScript auch nicht und es ist auf jeden Server schnell mit Notepad angepasst. Der Schlüssel des Skripts sind folgende Zeilen. Die erste bindet sich ganz normal an WMI an, während die zweite Zeile einen Notification-Event auf die "Exchange_Logon"-Tabelle legt.

Set objSWbemServices = GetObject("winmgmts:{impersonationLevel=impersonate}!"&_
                               "\\srv01\root\MicrosoftExchangeV2")
Set objEventSource = objSWbemServices.ExecNotificationQuery( &_
              "SELECT * FROM __InstanceOperationEvent       "&_
              "WITHIN 10 WHERE TargetInstance ISA 'Exchange_Logon' ")
Set objEventObject = objEventSource.NextEvent()
intlatency = objEventObject.targetinstance.Latency 

An der dritten Zeile bleibt das Skript dann ohne weitere CPU-Last stehen, bis eben so ein Event auftritt, welcher in der Folge auszuwerten ist. Mich interessiert nur due Latency, welche ich mit aus dem Event entsprechend hole. Nun will ich ja nicht jeden Messwert der Clients melden und muss aber auch Rücksicht auf unterschiedliche Clients nehmen. Einige sind ja im gleichen LAN und andere könnten ja per VPN von unterwegs arbeiten. Statische Grenzwerte (z.B. bei Überschreitung von 200ms) wären also fehl am Platz.

Aus dem Grund pflegt das Skript ein Dictionary, in dem für jede Kombination aus IP-Adresse, username, MailboxDN eben ein Mittelwert der letzten Latenzzeiten mitgeführt werden. Nur wenn dann ein Messwert eben aus der Reihe ist, dann wird dieser Vorgang im Eventlog protokolliert.

Zur Sicherheit beendet sich das Skript nach der Verarbeitung von 500 Events von alleine. So kann man sicher sein, dass das Skript nicht permanent läuft und Sie können die Einflüsse auf die Performance erst mal sehen. Diese Abbruchlogik hatte ich mal bei der Anwendung über eine langsame VPN-Verbindung per RDP gebraucht, wo ich ein Skript per CTRL-C nicht abbrechen konnte, da die Aktualisierung des Bildschirms schon die Bandbreite aufgebraucht hat. Diese Logik kann man natürlich einfach außer Kraft setzen.

 

Das Skript hingegen nutzt WMI um über eine "__InstanceOperationEvent"-Verbindung immer dann fortgeführt zu werden, wenn sich etwas geändert hat. Nur dann wird das Skript aktiv und kann mit wenig CPU-Zyklen die Daten auswerten und bei Bedarf alarmieren.

end2end MSX

Das Skript merkt sich pro aktiver Verbindung die Latenzzeit und bildet einen Mittelwert über die letzten 10 Werte. Weicht der letzte Wert zu stark Mittelwert dieser Verbindung ab und ist über eine konfigurierbaren Grenze, dann wird auch hier ein Eventlog für eine weiterer Auswertung geschrieben.

Eventlogmeldung

Der Code ist ähnlich von "ExStore2LOG", welcher die gleichen Daten aufnimmt und in eine CSV-Datei zur weiteren Auswertung protokolliert.

Download und Anwendung

Das Skript erfordert, dass Sie es mit einem Benutzer starten, welcher sich per WMI mit dem Server verbinden kann. Ich habe es selbst immer als lokaler Administrator auf dem Exchange Server selbst ausgeführt und nicht remote über das LAN.

Kein öffentlicher Download
Das Skript ist in der aktuellen Form nicht "Endkundentauglich", sondern muss noch weitere Tests und Anpassungen erhalten, ehe es zum Download bereitgestellt wird. Es hilft mir aktuell bei Exchange 2003 Servern mit diffusem Performancebild eine FehlerMöglichkeit auszuschließen. Es kann aber nur als Teil einer Gesamtbetrachtung gesehen werden.
Informationen, warum diese Skripte nicht öffentlich sind, finden Sie auf nicht public.

Exchange 2007 erlaubt nicht mehr die Abfrage per WMI. Allerdings gibt es weiterhin Performance Counter und auch einige PowerShell-Befehle erlauben das Auslesen dieser Kennzahlen. Auch in System Center Essentials und Operation Manager sind entsprechende Funktionen enthalten

Dieses Skript ist mittlerweile nicht mehr nutzbar, da Exchange 2003 schon zu alt ist und neuere Exchange Versionen leider keine WMI-Counter in der Art mehr anlegen.

Weitere Links