Auch wenn Anwendungen in der Cloud betrieben werden, müssen sie korrekt verwaltet werden. Im Rahmen des Application Lifecycle fallen zudem Aufgaben wie Installation, Überwachung, Fehlererkennung und -behebung usw. an. Die Durchführung der erforderlichen Arbeitsschritte ist jedoch von den besonderen Gegebenheiten der Cloud geprägt. Zu diesen zählen beispielsweise eine entfernte Umgebung mit eingeschränktem Zugriff oder eine dynamische Instanzenkonfiguration. Dieser Artikel zeigt, wie Azure-basierte Cloud-Anwendungen vor diesem Hintergrund überwacht werden können und was das für Wartung und Fehlerbehebung bedeutet.
Überblick
Der Betrieb einer Software auf einer Cloud-Plattform unterscheidet sich in einigen Aspekten grundlegend vom Betrieb auf einer Umgebung, die vollständig unter Kontrolle des Anwenders steht: Die Umgebung ist hochdynamisch, das heißt, die Zahl der Instanzen eines Cloud-Services kann sich zur Laufzeit ändern. Beispielsweise kann der der Ausführungsort wechseln, weil aufgrund eines Hardwareausfalls ein Service auf eine lauffähige Umgebung verschoben wird und der Zugriff auf die Umgebung nur über bestimmte Serviceschnittstellen möglich ist, wohingegen ein direkter Zugriff auf die Infrastruktur nicht funktioniert.
Da unter diesen Voraussetzungen auch das Debugging einer Anwendung zur Testzwecken unmöglich ist, gibt es bei Windows Azure für Entwickler eine sogenannte Development Fabric. Diese kann Windows Azure auf einem lokalen Entwicklungsrechner simulieren und dort das Debugging ermöglichen. Zur Entwicklungszeit ist die Überwachung eines Cloud-Services in der lokalen Umgebung möglich.
Für die Überwachung zur Laufzeit, das heißt in der Cloud-Umgebung, werden andere Mechanismen benötigt. Diese müssen Zugriff auf Zustandsinformationen und das Laufzeitverhalten einer Cloud-Anwendung erlauben. Windows Azure stellt hierzu die sogenannte Diagnostics zur Verfügung. Diese gestattet indirekten Zugriff auf sämtliche Diagnosedaten, die auch ein Windows-Server-Betriebssystem, der Internet-Information-Server oder die Anwendung selbst in Form von Logging- und Tracing-Ausgaben zur Verfügung stellt. Darüber stehen verschiedene Werkzeuge bereit, die Zugriff auf diese Daten gestatten und bei der Auswertung helfen.
Erzeugung von Diagnosedaten
Diagnosedaten fallen auf Windows Azure aus verschiedenen Quellen an. Für deren Sammlung, Zugriff und Auswertung kann der Mechanismus der Azure Diagnostics verwendet werden.
Ein für Azure entwickelter Cloud-Service muss zunächst einen sogenannten Diagnostics-Monitor instanziieren. Dieser koordiniert und steuert die Sammlung von Diagnosedaten. Hierbei besteht Zugriff auf alle Daten des unter Windows Azure liegenden Windows-Server-Betriebssystems. Die erzeugten Daten werden zunächst im lokalen Dateisystem der Serviceinstanz gespeichert.
Natürlich ist es ebenso möglich, eigene Analysedaten des Cloud-Services selbst zu erzeugen. Dies kann beispielsweise über Tracelogs erfolgen. Auch diese Daten werden zunächst im lokalen Dateisystem gespeichert. Von außen kann auf dieses Dateisystem nicht direkt zugegriffen werden.
Sollen die Diagnosedaten ausgelesen werden, können sie mithilfe des Diagnostic-Monitors in Windows Azure Storage (Blob- oder Table-Storage) übertragen werden. Diese Übertragung kann entweder in regelmäßigen Intervallen oder auf Anforderung erfolgen. Der Windows Azure Storage kann dann über Webservice-Schnittstellen angesprochen werden, und hierüber lassen sich die Daten auslesen.
Windows Azure Diagnostics
Für Diagnose- und Überwachungszwecke steht mit Windows Azure Diagnostics ein Windows-Azure-Subsystem zur Verfügung, das indirekten Zugriff auf verschiedene Diagnosedaten einer Azure-basierten Cloud-Anwendung ermöglicht. Die Interaktion mit Windows Azure Diagnostics erfolgt in drei Schritten:
1. Initialisierung des Diagnosesystems mithilfe eines Diagnostics Monitors;
2. Übertragung von Diagnosedaten an Windows Azure Storage (in regelmäßigen Intervallen oder auf Anforderung);
3. Auslesen der Diagnosedaten aus Windows Azure Storage mit anschließender Auswertung.
Das Windows Azure Software Development Kit (SDK) stellt Entwicklern eine Reihe von Klassen zur Verfügung, mit deren Hilfe Initialisierung und Übertragung ausgelöst werden können.
Arten von Diagnosedaten
Windows Azure Diagnostics stellt grundsätzlich alle Diagnosedaten bereit, die auch auf einem Windows-Server-Betriebssystem anfallen.
Je nach Datenquelle erfolgt der Transfer der Daten entweder in Windows Azure Table Storage oder in Windows Azure Blob Storage. Die folgende Tabelle zeigt, welche Datentypen zur Verfügung stehen und in welchen Windows Azure Storage sie beim Auslesen übertragen werden.
|
Datenquelle |
Voreinstellung |
Unterstützte Rollen |
Windows Azure Storage |
|
Windows Azure Logs |
gesammelt; erfordert einen entsprechenden Trace Listener in der Datei web.config oder app.config |
Web / Worker |
Table |
|
IIS 7.0 Logs |
gesammelt |
Web |
Blob |
|
Windows Diagnostic Infrastructure Logs |
gesammelt |
Web / Worker |
Table |
|
Failed Request Logs |
nicht gesammelt |
Web |
Blob |
|
Windows Event Logs |
nicht gesammelt |
Web / Worker |
Table |
|
Performance Counter |
nicht gesammelt |
Web / Worker |
Table |
|
Crash Dumps |
nicht gesammelt |
Web / Worker |
Blob |
|
Eigene Error Logs |
nicht gesammelt |
Web / Worker |
Blob |
Vorbereitung einer Cloud-Anwendung
Cloud-Anwendungen müssen mithilfe ein paar weniger Code-Zeilen auf das Sammeln und Auslesen von Diagnosedaten vorbereitet werden. Zunächst muss in einer zu überwachenden Rolle innerhalb der OnStart()-Methode eine neue Instanz eines Diagnostics Monitors erzeugt werden. Diese ist dann für die Steuerung von Datensammlung und -transfer verantwortlich.
Listing 1
using Microsoft.WindowsAzure.Diagnostics;
// Aktivierung der Windows Azure Diagnostics in der OnStart()-Methode einer Rolle
public override bool OnStart()
{
// Start des Diagnostic Monitors. Der Parameter referenziert einen Connection String,
// der in der Servicekonfiguration spezifiziert ist. Dort ist unter anderem hinterlegt
// in welchen Storage Account die Diagnosedaten später übertragen werden sollen.
// Wenn der Wert hier "UseDevelopmentStorage=true" lautet, werden die Diagnosedaten in
// den Development Storage übertragen.
DiagnosticMonitor.Start("DiagnosticsConnectionString");
Die Initialisierung des Diagnostics Monitors wie im Listing oben beschrieben bewirkt, dass Diagnosedaten entsprechend der generellen Voreinstellung erzeugt werden, das heißt, es werden nur solche Daten gesammelt, die in der zuvor erwähnten Tabelle entsprechend gekennzeichnet sind. Das folgende Listing zeigt, wie davon abweichend zusätzliche Daten gesammelt werden können.
Listing 2
public override bool OnStart()
{
// Ermittle die voreingestellte Konfiguration
var config = DiagnosticMonitor.GetDefaultInitialConfiguration();
// Füge einen Performance Counter zur Konfiguration hinzu
config.PerformanceCounters.DataSources.Add(
new PerformanceCounterConfiguration()
{
CounterSpecifier = @"\Processor(_Total)\% Processor Time",
SampleRate = TimeSpan.FromSeconds(5)
});
// Füge der Konfiguration auch noch Einträge aus dem Windows Event Log hinzu
config.WindowsEventLog.DataSources.Add("System!*");
// Veranlasse einen regelmäßigen Datentransfer in Windows Azure Storage
config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Error;
config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = TimeSpan.FromMinutes(5);
// Starte den Diagnostic Monitor mit der angepassten Konfiguration.
DiagnosticMonitor.Start("DiagnosticsConnectionString", config);
return base.OnStart();
}
In diesem Beispiel wird konfiguriert, dass neben den Standardinformationen auch noch alle fünf Sekunden die Prozessorauslastung (der Performance Counter "\Processor(_Total)\% Processor Time") sowie die das System betreffenden Einträge aus den Windows Event Logs gespeichert werden. Für die Diagnostic Infrastructure Logs wird darüber hinaus festgelegt, dass die enthaltenen Fehlermeldungen alle fünf Minuten in Windows Azure Storage übertragen werden.
Konfiguration der Datenquellen
Je nach Datenquelle müssen diese noch auf die Interaktion mit Windows Azure Diagnostics vorbereitet werden. Um beispielsweise eigene Logging-Ausgaben mit Diagnostics auslesen zu lassen, sind in der web.config beziehungsweise app.config der betreffenden Rolle Trace Listener zu konfigurieren. Dies bewirkt, dass Tracing-Ausgaben, die im Programmcode gemacht werden, vom Diagnosesystem erfasst und unterstützt werden.
Listing 3
<system.diagnostics>
<trace>
<listeners>
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener,
Microsoft.WindowsAzure.Diagnostics,
Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=xxxxxx"
name="AzureDiagnostics">
<filter type="" />
</add>
</listeners>
</trace>
</system.diagnostics>
Während IIS 7.0 Logs und Windows Azure Diagnostics Logs ohne Zutun automatisch erfasst werden, ist für Failed Request Logs ebenfalls eine Konfiguration erforderlich. Diese befindet sich im Abschnitt <system.webServer> der web.config-Datei der betreffenden Rolle.
Listing 4
<tracing>
<traceFailedRequests>
<add path="Default.aspx">
<traceAreas>
<add provider="ASP" verbosity="Verbose" />
<add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices"
verbosity="Verbose" />
<add provider="ISAPI Extension" verbosity="Verbose" />
<add provider="WWW Server"
areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,
RequestNotifications,Module"
verbosity="Verbose" />
</traceAreas>
<failureDefinitions statusCodes="400-599" />
</add>
</traceFailedRequests>
</tracing>
Wird nun eine derart konfigurierte Cloud-Anwendung auf Windows Azure ausgeführt, sorgt der Diagnostic-Monitor dafür, dass die konfigurierten Diagnosedaten gesammelt und in festgelegten Intervallen in Windows Azure Storage übertragen werden.
Zugriff auf Diagnosedaten
Aus dem Windows Azure Storage können die Diagnosedaten dann über Standardschnittstellen (REST-basierte Webservices) ausgelesen werden. Grundsätzlich kann dies also über beliebige Werkzeuge bewerkstelligt werden, die diese Schnittstellen unterstützen
Der Datentransfer nach Windows Azure Storage kann üblicherweise automatisiert in regelmäßigen Intervallen oder auf Anforderung erfolgen. Die Konfiguration des kontinuierlichen Datentransfers ist bereits in Listing 2 zu sehen. Dort wurde für Fehlermeldungen aus der Diagnostics-Infrastruktur ein Datentransfer in Abständen von fünf Minuten eingestellt. Selbstverständlich sind hier auch kleinere Intervalle möglich, um eine möglichst durchgehende Statusaktualisierung einsehen zu können.
Ein Datentransfer kann zudem auf Anforderung erfolgen. Diese kann von innerhalb einer Cloud Anwendung oder von außerhalb kommen. Das Codefragment in Listing 5 zeigt, wie der Datentransfer für eine bestimmte Anwendungsinstanz initiiert werden kann.
Listing 5
// Erstelle für eine bestimmte Cloud-Anwendung einen neuen Diagnostic Manager
var diagManager = new DeploymentDiagnosticManager(storageAccount, deploymentID);
// Leite aus diesem auf der Anwendungsebene definierten Diagnostic Manager den
// Diagnostic Manager der gewünschten Rolle und Instanz ab.
var roleInstDiagMgr = diagManager.GetRoleInstanceDiagnosticManager(roleName,
roleInstanceName);
// Alle verzeichnisbasierten Logs sollen übertragen werden.
DataBufferName dataBuffersToTransfer = DataBufferName.Directories;
// Es sollen alle Daten, das heißt von Beginn der Aufzeichnungen bis zum gegenwärtigen
// Zeitpunkt, übertragen werden.
OnDemandTransferOptions transferOptions = new OnDemandTransferOptions();
transferOptions.From = DateTime.MinValue;
transferOptions.To = DateTime.UtcNow;
// Initiiere den Datentransfer.
Guid requestID = roleInstDiagMgr.BeginOnDemandTransfer(dataBuffersToTransfer,
transferOptions);
Mit Abschluss des regelmäßigen oder angeforderten Datentransfers liegen die betreffenden Diagnosedaten in den in Tabelle 1 aufgelisteten Windows-Azure-Storage-Bereichen. Von dort aus können sie über verschiedene Werkzeuge ausgelesen und ausgewertet werden.
Werkzeuge für den Zugriff
Für Zugriff und Auswertung von Diagnosedaten Azure-basierter Cloud-Anwendungen gibt es verschiedene Alternativen auf dem Markt.
Die einfachste Möglichkeit, die Daten auszulesen, ist die über den direkten Zugriff auf den Windows Azure Storage. Dieser stellt REST-basierte Webservice-Schnittstellen zur Verfügung, über die die Inhalte von Table- und Blob-Storage ganz leicht ausgelesen und angezeigt werden können. Diese Schnittstellen machen sich zudem zwei Werkzeuge zunutze, die die Daten nach dem Auslesen zusätzlich grafisch aufbereiten.
Für Microsoft System Center Operations Manager steht mit dem Windows Azure Management Pack eine Erweiterung zur Verfügung, die Zugriff und Auswertung von Windows-Azure-Diagnosedaten ermöglicht. Die vom Operations Manager zu überwachenden Cloud-Anwendungen müssen wie oben beschrieben konfiguriert werden. Der Operations Manager kann dann die Diagnosedaten aus dem Windows Azure Storage auslesen und auswerten.
Ein weiteres Werkzeug zur Auswertung von Azure-Diagnosedaten ist der Azure Diagnostics Manager der Firma Cerebrate Software. Auch dieses erfordert, dass die überwachten Anwendungen entsprechend konfiguriert werden. Das Azure Management Studio kann dann auf die in den Azure Storage übertragenen Daten zugreifen und sie grafisch aufbereiten.
Fazit
Windows Azure stellt Mittel bereit, mit denen sich auch in einer dynamischen Cloud-Umgebung Diagnosedaten ermitteln lassen.
Diese werden regelmäßig oder auf Anforderung in Windows Azure Storage übertragen, von wo aus sie über verschiedene Werkzeuge ausgelesen und ausgewertet werden. Die Brücke vom lokalen Softwarebetrieb zum Betrieb in der Cloud wird hierdurch enger gespannt. (mje)