SystemDataRecorder

Herausforderung

SystemDataRecorder ist vielleicht das vollständigste und einfachste Paket für professionelle Leistungsüberwachung, Leistungsanalyse, Systemdimensionierung und Kapazitätsplanung in anspruchsvollen Geschäftsumgebungen. Es bietet eine konsistente Datenaufzeichnung über Systeme und Geräte hinweg, erlaubt den Zugriff auf Rohdaten und ist für Zeitreihenanalysen ausgelegt. Für Nicht-Software-Experten mag das nicht so aussehen, aber es ist tatsächlich eine sehr leistungsfähige und lang erwartete Lösung für ein seit langem bestehendes Problem.

Obwohl es Computer schon seit mehr als 25 Jahren gibt, gibt es immer noch keine einheitliche Leistungsüberwachung zwischen verschiedenen Betriebssystemen, da jede Umgebung ihre eigene Art von Überwachungs- und Datenerfassungstools einsetzt. Eine konsistente Datenaufzeichnung über verschiedene Betriebssysteme hinweg ist nur sehr schwer möglich, ohne für jede Umgebung eine eigene Software zu kaufen oder Lösungen von Drittanbietern zu installieren. Selbst das für die Datenaufzeichnung verwendete Format ist von System zu System unterschiedlich, was die Datenerfassung und -analyse zu einem logistischen Alptraum macht.

Schaut man sich die einzelnen Betriebssysteme genauer an, stellt man schnell fest, dass die Methoden zur Erfassung von Leistungsdaten eigentlich ähnlich sind, aber je nach Hersteller und Implementierungsart unterschiedliche Schnittstellen mit unterschiedlicher Terminologie verwendet werden. Die Idee hinter dem SystemDataRecorder ist es, mehrere Standarddatenerfassungsagenten zu haben, um Metriken von den Systemschnittstellen zu erhalten und diese Informationen auf eine einheitliche Weise zu exportieren. Für die exportierten Daten kann eine einfache Textdatei verwendet werden, wobei auf spezielle Dateiformate verzichtet wird, um diese Datei für jedes verfügbare Analysetool nutzbar zu machen. Auf diese Weise kann ein einfaches Datenaufzeichnungsmodul für die Fehlersuche im System, die Leistungsanalyse, die Analyse von Systemabstürzen usw. verwendet werden, und es lässt sich leicht über eine große Anzahl von Hosts in einem Rechenzentrum aktivieren, wobei das verwendete Betriebssystem keine Rolle mehr spielt.

Der SystemDataRecorder war bereits verfügbar und erwies sich als das Licht am Ende des Tunnels für Linux- und Solaris-Systeme, als Redwerk kontaktiert wurde, um ihn auch für Windows 2003- und 2008-Server-Umgebungen zu adaptieren. Ziel war es, dass diese Server mit ähnlichen Metriken arbeiten wie der SystemDataRecorder für Linux oder Solaris. Die Lösung sollte so wenig Systemressourcen wie möglich verbrauchen, klein und robust genug sein, um keinen System-Overhead zu erzeugen. Die Rekorder mussten als Windows-Dienste implementiert werden, d. h. als native Anwendungen für 32- und 64-Bit-Systeme. Alle Daten mussten in einer einfachen Textdatei gespeichert werden.

Eine zusätzliche Herausforderung bestand darin, die Fähigkeit zur Überwachung der Ausgabe der Rohdaten-Dateien auf Windows zu portieren. Für jede Änderung in einer Datei musste ein HTTP/HTTPS POST an ein Backend-System gesendet werden, um später analysiert zu werden. Die Software musste als Softwarepaket vertrieben werden, das sich für die automatische Installation unter Windows eignet, ohne dass eine Benutzerinteraktion erforderlich ist.

Lösung

Unsere Untersuchungen haben gezeigt, dass ein in C/C++ geschriebener Dienst, der Dutzende von Parametern empfängt und Daten in eine Datei schreibt, etwa 2 MB RAM und nur geringe CPU-Ressourcen benötigt. Derselbe Dienst in C# benötigt mindestens 6 MB, und obwohl er einfacher zu entwickeln ist, erfordert er auch mindestens .NET 2.0. Nach einer Analyse der Vor- und Nachteile wurde der Code in C entwickelt. Auf diese Weise gelang es uns, die Abstraktion zu minimieren und einfache Routinen für den Zugriff auf Windows-Kernel-Metriken zu verwenden, ohne den Overhead, den die Verwendung einer objektorientierten Sprache mit sich gebracht hätte. Alle Daten für den Dienst wurden von der WMI-API bezogen.

Für jeden einzelnen Rekorder ist der wichtigste Parameter die Anzahl der Sekunden zwischen den einzelnen Messungen. Der Standardwert war 60 Sekunden. Wir haben auch eine Lösung für das Starten mit einem bestimmten Parameter unter Windows gefunden. Die Rekorder starten und schreiben die Daten in ihre eigenen, individuellen Dateien. Nach diesem ersten Schritt werden die Dateien gedreht und komprimiert. Unter Linux oder Solaris wird dies mit cron realisiert, aber für Windows mussten wir eine eigene Lösung finden.

Der Entwicklungsprozess war sehr solide und basierte auf logischen Schritten der Forschung, des Testens und der Bereitstellung. Bei den Tests traten einige sehr interessante Probleme auf. Wir mussten sicherstellen, dass die Rekorder mindestens 48 Stunden lang ohne Speicherlecks oder andere Abweichungen liefen. Wir ließen sie sogar über das Wochenende laufen, um sie ordnungsgemäß überwachen zu können und geeignete Akzeptanztests durchzuführen.

Damit der Prozess und die Lösung solide und gründlich sind, müssen auch Notfallsituationen wie Stromausfälle oder ungeplante Systemneustarts berücksichtigt werden. Um solche Szenarien zu bewältigen, müssen die Dienste beim Systemstart automatisch neu gestartet werden und weiterhin Daten aufzeichnen und in den Ausgabedateien speichern.