Ende zu Ende Monitoring

Auf verschiedenen Seiten beschreibe ich die üblichen Methoden, um Systeme zu überwachen, sei es über das Auslesen von Betriebsdaten per Performance Counter und SNMP, das Einsammeln von Meldungen (Eventlog, Syslog) und aktive Tests. All diese Messungen sind wichtig und nützlich aber nicht immer hinreichend. Diverse Funktionen lassen sich nicht durch die Summe der Einzeltests sicherstellen, sondern nur durch synthetische Transaktionen, die genau das tun, was ein Anwender auch tut. Idealerweise auch nicht nur einmal alle 5 Minuten sondern quasi dauern.

Bei VoIP ist es am einfachsten zu erklären: Wer nur alle 5 Minuten die Netzwerkauslastung misst, wird nie kurze Überlastsituationen bemerken, die jedes Telefonat unterbrechen. Der klassische "Datenverkehr" kann in der Regel problemlos damit leben, wenn die Pakete mal ein paar Sekunde "stocken". VoIP nicht. Aus dem Grund habe ich mir Tools gebaut, die ich in Projekten als "Dauerlast"-Geber und Sensor verwende.

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

Zu fast jedem Sensor habe ich auf der Seite auch das Beispiel angeführt, bei welcher konkreten Situation das Tool mir geholfen hat.

  • 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-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 und entsprechend auf anderen DCs ausgewertet werden kann um Replikationsverzögerungen zu erkennen.
  • 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 Abstände der Messung (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
  • End2End-File
    Dateisysteme sind bei heutigen Servern der langsamste Prozess und oft sogar noch im SAN auf einem Shared Medium über vielen Stationen angebunden. Wie stellen Sie sicher, dass das Dateisystem kontinuierlich die erwartete Leistung bringt?. Performance Counter über Latenzzeit und Queue-Length sind nicht immer ausreichend, wie ich auf dieser Seite beschreibe
  • 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 -MSXLatenz
    Warum sollte man Exchange 2003 mit eigenen Tests überwachen, wenn viele reguläre Clients auf den Server zugreifen und selbst die Latenzzeit müssen und an den Server melden. Dieses Skript liest per WMI vom Server eben diese Daten aus und melden Abweichungen.
  • End2End Mailbox
    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.
  • End2End Tracking
    Analog wie die Latenz liefert auch das Messagetracking ausführliche Daten. Wenn ein Skript die Zeiten zwischen Eintreffen und Zustellung einer Mail ermittelt, ist die ein Zeichen für die Performance. Bei Exchange 2010 wird die Latenz sogar schon in jedem Eintrag addiert und muss nur noch ausgelesen werden
  • End2End-SMTPflow
    Das Skript sendet mit jedem Aufruf eine Mail und prüft im Posteingang, wann die vorherigen Mails von einem SMTP-Echo-Server zurückgegeben wurden. Damit kann die komplette Kette der Stationen zu diesem einen Ziel gemessen werden.
  • End2End-Ldap
    Bei einem Kunden kam es zu vereinzelten Abbrüchen bei LDAP-Zugriffen. Zur Fehlersuche wurde mit End2End-LDAP ein Skript entwickekt, welches einfach immer LDAP-Verbindungen prüft.
  • End2End Service
    Entwurf eines Programms zum permanenten Monitoring von Latenzzeiten bei Netzwerk und Storage
  • End2End-FRS
    Wenn Verzeichnisse über den "File Replication Service" synchronisiert werden, dann kann ein Skript eine Datei auf einer Seite ändern und kontrollieren, ab wann diese auf der anderen Seite ankommt.

Weitere Links