Ende zu Ende Module

Überwachung von Exchange ist ein wichtiges Thema und es gibt eine ganze Menge von Überwachungsprogrammen, die eine lückenlose Kontrolle ihrer Server versprechend. Die meisten Programme nutzen dazu drei Kriterien:

Damit können die meisten Fehlersituationen sogar erkannt werden. Allerdings gibt es sehr oft Situationen, in denen Server und die gesamte Infrastruktur keinen Fehler anzeigen und es trotzdem zu Problemen kommt.

Denn eine Überwachung der Server und selbst der Netzwerke ist keine lückenlose Überwachung der Gesamtfunktion. Hierzu ist es nämlich erforderlich, eine "Ende zu Ende" Überwachung einzurichten und quasi dem Benutzer direkt über die Schulter zu schauen und seine "gefühlten Antwortzeiten" zu ermitteln.

Das Problem hierbei ist, dass die meisten Anwendungsentwickler sich dazu noch nie wirklich Gedanken gemacht haben. Es wäre ihre Aufgabe auf dem Client entsprechende Prüfpunkte zu implementieren.

Aber ich habe bislang auch noch nicht gesehen, dass ein Outlook, welches die berühmte bzw. berüchtigtes Meldungsbox "Daten werden abgerufen…" anzeigt, dies auch irgendwo im Eventlog niederschreibt. Erst Outlook 2007 hat ein Eventlog auf dem Client, welches zumindest grobe Fehler enthält.

Client Eventlog

Das gleiche gilt natürlich auch für Webbrowser oder auch einfach nur der Windows Explorer beim Zugriff auf ein Netzwerklaufwerk. Kaum ein Programm zeichnet auf dem Client selbst entsprechende Kennzahlen auf und stellt diese bereit. Entsprechend kann eine Überwachungssoftware diese auch nicht auswerten.

Etwas Anderes ist es z.B. mit Anwendungen die terminalbasiert laufen. Wenn nur die Bildschirme und Eingaben übertragen werden (z.B.: SAP-Gui) dann läuft die eigentliche Software auf zentralen Servern und hier kann ein Entwickler natürlich "Zeitmarken" im Code verwenden um Hinweise auf die Performance und Laufzeit zu erhalten. Engpässe bei der Übertragung zum Client, die sich in Verzögerungen beim Bildaufbau oder der Annahme von Tasten zeigen, können so aber auch nicht erkannt werden.

Da diese Situation für mich ziemlich unbefriedigend ist, habe ich angefangen, eigene Tools für die aktive Überwachung zu schreiben. Diese Skripte werden nun nicht regelmäßig mit einigem Abstand von einer Überwachungssoftware gestartet, sondern laufen auf dem fraglichen Server bzw. einer Probenstation permanent und legen eine gewisse Grundlast auf das System oder werden Counter aus, die nicht per Eventlog oder Perfmon zu erhalten sind. Treten hier Abweichungen auf, werden diese im Eventlog gemeldet, so dass die nachgeschaltete Überwachungssoftware dann darauf reagieren kann. Aktuell sind folgende Skripte realisiert:

  • End2End-file
    Überwachung von lokalen Festplatten und Netzwerklaufwerken durch eine permanente geringe Grundlast
  • End2End-msxlatency
    Überwachung von Exchange 2003, indem die "Latency-Zeiten", die Outlook 2003 an Exchange melden, ausgelesen und bei großen Abweichungen gemeldet werden
  • End2End-msxprobe
    Überwachung von Exchange durch eine permanente MAPI-Verbindung mit häufigen aber geringen zugriffen auf ein Postfach

All diese Skripte sind nicht frei verfügbar, da Sie keine "Plug and Play" Skripte sind, sondern für die jeweilige Umgebung angepasst werden müssen. "Ende 2 Ende"-Monitoring ist keine Software, die man einfach installiert, sondern ein Prozess, der implementiert wird.

Unterstützung durch Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach an.

End2End-Ping

Ein PING ist nicht wirklich eine sinnvoll messbare Größe, das die ICMP-Pakete sehr klein sind und man eine aktive Gegenstelle braucht. Man kann aber anhand der Laufzeit schon erkennen, ob es "Aussetzer" gibt, d.h. Pakete verloren gehen oder Engpässe einer WAN-Leitung ein Problem darstellen können. End2End-ping hat mir auch bei Clustern schon öfter geholfen, wenn ich damit z.B. einen Ping zwischen den Heartbeat-Karten aktiviert habe, um hier speziell bei Clusterknoten mit etwas "Entfernung" Aussagen über die Zuverlässigkeit machen zu können.

  • End2End-Ping
    Einfaches Tool um per ICMP eine Permanentüberwachung zu erlauben

End2End-AD

Auch eine Überwachung der Active Directory Replikation ist ein wichtiges Hilfsmittel die "Gesundheit" zu überprüfen. Dazu kann ein Skript z.B. ein Objekt ändern und schauen, ab wann diese Änderung dann auch auf den anderen DCs erscheint. Ein erster Schritt ist natürlich ein Skript, welches so ein Objekt verändert. Das kann "lokal" auf dem DC erfolgen oder von einem zentralen Punkt auf den einzelnen DCs.

  • End2End-AD
    Dies ist ein VBScript, welches auf jedem DC per Taskplaner als "LocalSystem" gestartet werden kann und in das Feld "telephoneNumber" des eigenen Computerobjekts einen Zeitstempel addiert.

Eine zentrale Lösung habe ich in Planung. Sie ist so angelegt, dass Sie per PowerShell eine Lister aller DCs einsammelt und sich dann zu jedem DC verbindet und an dessen Computerobjekt einen Zeitstempel hinterlässt und umgekehrt über die GCs dann schaut, welche Zeitstempel sie von den anderen Domänencontroller können.

End2End-UDP

Interessant wird dieses Netzwerkthema mit VoIP. Hier werden ja speziell UDP-Pakete mit Audio/Video-Daten gesendet, die bitte schön möglichst kontinuierlich und ohne Ausfälle übertragen werden sollen. Das klassische Monitoring mit MRTG/PRTG und anderen Mitteln hilft hier bei der Überwachung nicht, da sie zu große Messabstände (meist 5 oder 10 min) haben und damit z.B. eine Unterbrechung von weniger als 1 Sek gar nicht erkennen können. Hier hilft nur eine aktive Probe, bei der UDP-Pakete mit der richtigen Größe, Anzahl und Abstand versendet und der Empfang überprüft wird. Am besten natürlich noch in beide Richtungen.

Dieses Skript ist noch nicht veröffentlicht

End2End-File

Der Auslöser zu diesem Skript war ein älterer Supportfall, bei der ein Kunde sich über "Sanduhren" beim Explorer und beim Speichern von Dateien auf einem Server beschwert hat. Die klassische Kontrolle des Dateiservers mittels Perfmon und anderen Lokalen Test (DT Performance Messung etc.) hat insofern nicht geholfen, da die kritischen Kennzahlen alle in Ordnung waren.

Also war eine aktive Langzeitmessung gefragt. Das Skript beschreibt permanent eine 10 Kilobyte Datei und misst die hierfür benötigte Zeit. Um den Server nicht zu überlasten, wird dann eine kurze Pause (100ms) eingelegt, so dass dieses Skript eine Dauerlast von ca. 100kByte/Sek = 1 Megabit produziert. Dies sollte einen aktuellen Server nicht beeinträchtigen. Die benötigte Zeit wird gespeichert und gemittelt, so dass ein "Durchschnitt" vorhanden ist. Weicht ein Zugriff nun sehr stark davon ab, wird die erkannt und eine Meldung hinterlassen.

Die Funktion des Skripts ist eigentlich ganz einfach. Um jedoch den Netzwerkzugriff zu testen, muss es auf einem Client oder anderen Server gestartet werden. Soll dies nicht interaktiv erfolgen, muss das Skript mit SRVANY, dem Windows Taskplaner oder anderen Tools als "Dienst" implementiert werden.

End2End-CPU

Ich wollte es ja nicht glauben aber ein Einsatz bei einem Kunden, bei dem Gäste auf einer Virtualisierungsplattform gefühlt einfach träge waren, hat mich dazu gebracht, ein einfaches CPU-Testprogramm zu schreiben, was versucht, wie schnell ein einzelner Kern eine PowerShell-Schleife abarbeiten kann. Auf der Seite End2End-CPU habe ich einen Vorfall bei einem Kunden beschrieben, in dem dieses kleine Skript quasi bewiesen hat, dass der Gast nicht die versprochene CPU Leistung bekommen hat. Das ist am Anfang aufgefallen. Aber wer stellt sicher, dass die versprochene Leistung auch während der gesamten Betriebszeit verfügbar ist ?

End2End-msxlatency

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.

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.

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

End2End-msxprobe

Diese Skript ist analog zu End2End-file eine Lösung um eine permanente Aktivität auf einem Postfach zu simulieren. Dieses Skript nutzt eine CDO-Verbindung, um sich mit einem Postfach zu verbinden und immer wieder eine Mail zu lesen. (Ohne Cachedmode). Es misst den Zeitbedarf dafür und meldet größere Abweichungen von Mittelwert. Auch hier ist es problemlos möglich, quasi im Sekundentakt die Mail zu lesen und Probleme sehr schnell zu erkennen und diese im Eventlog zu melden. Damit hat eine nachgeschaltete Überwachungssoftware dann in der Regel keine Probleme mehr einen Alarm auszulösen.

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

End2End-Tracking

Eine weitere gute Testquelle ist das Message-Tracking. Damit kann nicht nur geprüft werden, welche Mails wann übertragen wurden, sondern man kann damit auch wunderbar das Eintreffen einer Mail und das Zustellen oder Verlassen auf dem Server überwachen und daraus Messzahlen für die Durchlaufzeit ermitteln.

Wer dazu sich noch die Mühe macht, die Werte von mehreren Servern einzusammeln und so die Zeit zwischen dem ersten Auftreten der Mail in der Organisation und der Zustellung oder Weiterleitung ermittelt, kann sogar die Gesamtdurchlaufzeit müssen und bewerten.

Exchange 2007 stellt das PowerShell-Kommando "TEST-Mailflow" bereit, welches eine Mail an das Systempostfach senden und die Laufzeit bis zum eintreffen misst.
Allerdings nicht anhand des Messagetrackings sondern eher in der Art wie End2End-SMTPflow

Weitere Links