Übersicht über Diagnosemöglichkeiten bei Windows Azure 1.4
Veröffentlichung des Originalartikels: 24.08.2011
Mir ist bekannt, dass im Internet eine Vielzahl von Beiträgen und Artikeln zur Diagnose in Windows Azure kursiert. Dies war im Wesentlichen ein Teil des Problems, als ich die Details dazu herausfinden wollte, welche Dokumentation zur Verfügung steht. Ich fand viele verschiedene Artikel, die jedoch zu vielen verschiedenen Versionen von Azure gehörten, weshalb es recht zeitaufwändig war herauszufinden, welche Angaben für das neueste Azure SDK (1.4) gelten. Ziel dieses Beitrags ist es, die wichtigsten Punkte für die Verwendung der Azure-Diagnose mit Version 1.4 des SDK zusammenzutragen.
Wie viele von Ihnen bestimmt bereits wissen, bietet Azure einen integrierten Ablaufverfolgungslistener, der Ihre Trace.* -Befehle (wie Trace.Write, Trace.WriteLine, Trace.TraceInformation usw.) ausführt und diese im Arbeitsspeicher speichert. Sie müssen jedoch einen weiteren Schritt ausführen, um sie aus dem Arbeitsspeicher in den dauerhaften Speicher zu übertragen. Dies kann das Auslösen einer manuellen Übertragung der Daten oder Konfigurieren eines Zeitplans für die zu erfolgenden Übertragungen sein. Darüber hinaus können Sie auch Informationen aus Ereignisprotokollen, IIS-Protokollen und benutzerdefinierten Protokollen übertragen und Leistungsindikatoren erfassen.
Zusätzlich zu allen typischen Protokollierungs- und Debuggingtools wie den zuvor erwähnten können Sie Ihre Bereitstellung auch so konfigurieren, dass eine RDP-Verbindung mit dem Azure-Server hergestellt wird, der als Host Ihrer Anwendung dient. Außerdem können Sie IntelliTrace für eine begrenzte Fehlerbehebung und Problembehandlung in einer Anwendung aktivieren, die bereitgestellt wurde. Diese verschiedenen Komponenten möchte ich Ihnen nun vorstellen.
Am einfachsten erfolgt die Konfiguration der verschiedenen Diagnosekomponenten, z. B. Häufigkeit, mit der Daten dauerhaft gespeichert werden, Größe des zuzuordnenden Speichers, zu erfassende Leistungsindikatoren usw. durch Schreiben von Code in die Datei WebRole.cs, die zum Standardfunktionsumfang einer Azure-Anwendung vom Typ Webrolle gehört (und ich meine, dass die meisten Azure-Features außer der VM-Rolle über etwas Analoges zu einer WebRole-Klasse verfügen, z. B. die Datei WorkerRole.cs in einem Arbeitsrollenprojekt). Bevor wir uns den Code näher anschauen, müssen Sie in Ihrem Azure-Rollenprojekt auf der Registerkarte Konfiguration das Kontrollkästchen Geben Sie die Anmeldeinformationen des Speicherkontos für die Diagnoseergebnisse an: aktivieren. Wählen Sie mithilfe der Auswahlschaltfläche ein Speicherkonto aus, über das Sie in Azure verfügen. Wählen Sie nicht die lokale Entwicklung aus. Dadurch wird im Projekt Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString eine neue Verbindungszeichenfolge gespeichert.
Wir wollen uns nun den gesamten Code in der Webrollenklasse ansehen, den ich anschließend im Detail behandeln werde:
public override bool OnStart()
{
// Informationen zum Durchführen von Konfigurationsänderungen
// finden Sie im MSDN-Thema unter "https://go.microsoft.com/fwlink/?LinkId=166357".
try
{
//das Einstellungsframework initialisieren
Microsoft.WindowsAzure.CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
{
configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
});
//das Speicherkonto mithilfe der standardmäßigen Verbindungszeichenfolge für die Diagnose abrufen
CloudStorageAccount cs =
CloudStorageAccount.FromConfigurationSetting(
"Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString");
//den Diagnose-Manager abrufen
RoleInstanceDiagnosticManager dm = cs.CreateRoleInstanceDiagnosticManager(
RoleEnvironment.DeploymentId,
RoleEnvironment.CurrentRoleInstance.Role.Name,
RoleEnvironment.CurrentRoleInstance.Id);
//die aktuelle Konfiguration abrufen
DiagnosticMonitorConfiguration dc = dm.GetCurrentConfiguration();
//falls nicht möglich, die Werte aus der Konfigurationsdatei abrufen
if (dc == null)
dc = DiagnosticMonitor.GetDefaultInitialConfiguration();
//Windows Azure-Protokolle
dc.Logs.BufferQuotaInMB = 10;
dc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
dc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(5);
//Windows-Ereignisprotokolle
dc.WindowsEventLog.BufferQuotaInMB = 10;
dc.WindowsEventLog.DataSources.Add("System!*");
dc.WindowsEventLog.DataSources.Add("Application!*");
dc.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(15);
//Leistungsindikatoren
dc.PerformanceCounters.BufferQuotaInMB = 10;
PerformanceCounterConfiguration perfConfig =
new PerformanceCounterConfiguration();
perfConfig.CounterSpecifier = @"Processor(_Total)% Processor Time";
perfConfig.SampleRate = System.TimeSpan.FromSeconds(60);
dc.PerformanceCounters.DataSources.Add(perfConfig);
dc.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);
//Protokolle zu fehlerhaften Anforderungen
dc.Directories.BufferQuotaInMB = 10;
dc.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(30);
//Infrastrukturprotokolle
dc.DiagnosticInfrastructureLogs.BufferQuotaInMB = 10;
dc.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter =
LogLevel.Verbose;
dc.DiagnosticInfrastructureLogs.ScheduledTransferPeriod =
TimeSpan.FromMinutes(60);
//Absturzabbilder
CrashDumps.EnableCollection(true);
//Gesamtkontingent, das größer sein muss als die Summe aller Elemente
dc.OverallQuotaInMB = 5000;
//die Konfiguration speichern
dm.SetCurrentConfiguration(dc);
}
catch (Exception ex)
{
System.Diagnostics.Trace.Write(ex.Message);
}
return base.OnStart();
}
Sehen wir uns nun den Code etwas genauer an. Ich beginne mit dem Abrufen des Werts der für die Diagnose verwendeten Verbindungszeichenfolge, um eine Verbindung mit dem verwendeten Speicherkonto herzustellen. Das Speicherkonto dient anschließend dazu, um zur Konfigurationsklasse der Diagnoseüberwachung zu gelangen. Sobald ich dort angelangt bin, kann ich anfangen, die verschiedenen Protokollierungskomponenten zu konfigurieren.
In den Windows Azure-Protokollen werden alle Aufrufe von Trace.* gespeichert. Bei meiner Konfiguration werden 10 MB Daten in der verwendeten Tabelle gespeichert und Schreibvorgänge in die Tabelle mit mindestens der Einstellung Verbose alle fünf Minuten dauerhaft gespeichert. Eine Liste der verschiedenen Tabellen und Wartschlangen, die Windows Azure zum Speichern dieser Protokollierungsdaten verwendet, finden Sie hier: https://msdn.microsoft.com/en-us/library/hh180875.aspx und hier: https://msdn.microsoft.com/en-us/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx. Infrastruktur- und Diagnoseprotokolle sind praktisch identisch.
Für Einträge in der Ereignisanzeige muss ich jedes zu erfassende Protokoll der Liste DataSources für die WindowsEventLog-Klasse hinzufügen. Die Werte, die ich angeben kann, heißen Application!* , System!* oder UserData!* . Die anderen entsprechen denen, die für Windows Azure-Protokolle beschrieben wurden.
Bei Leistungsindikatoren des Systemmonitors müssen Sie angeben, welche Indikatoren mit welcher Häufigkeit erfasst werden sollen. Im Beispiel oben habe ich einen Leistungsindikator für die CPU hinzugefügt, der alle 60 Sekunden Daten erfasst.
Zu den letzten Konfigurationseinstellungen zählten das Aktivieren der Erfassung von Absturzabbildern und das Ändern des Gesamtkontingents für alle Protokollierungsdaten in ca. 5 GB. Abschließend wurden alle Daten gespeichert. Es ist überaus wichtig, das Gesamtkontingent zu erhöhen, da andernfalls eine Ausnahme ausgelöst wird, die besagt, dass für die Durchführung der oben beschriebenen Änderungen nicht genügend Speicherplatz vorhanden ist. 5 GB eignen sich als sicherer Standardwert, doch Ihre Anforderungen können ggf. abweichend sein.
Nach Abschluss der Konfiguration kann die Anwendung veröffentlicht werden. Bei Veröffentlichung der Anwendung aus Visual Studio müssen verschiedene Dinge beachtet werden:
Im Dialogfeld Veröffentlichungseinstellungen müssen Sie das Kontrollkästchen IntelliTrace aktivieren aktivieren (weitere Informationen hierzu weiter unten). Darüber hinaus empfehle ich, auf den Link zum Konfigurieren von Remotedesktopverbindungen zu klicken, denn mitunter war dies die einzige Möglichkeit, ein Problem zu beheben. Da die Dokumentation zu Remotedesktop nicht mehr ganz aktuell zu sein scheint, schlage ich vor, dass Sie dieses Dialogfeld verwenden, anstatt Konfigurationsdateien manuell zu bearbeiten. Das eingeblendete Dialogfeld sieht ungefähr so aus:
Die folgenden wichtigen Punkte müssen beachtet werden:
- Sie können anscheinend jedes beliebige Zertifikat verwenden, für das Sie eine PFX-Datei haben. Vor dem Veröffentlichen der Anwendung muss dieses Zertifikat in Ihren gehosteten Dienst hochgeladen werden.
- In das Feld Benutzername können Sie einen beliebigen Namen eingeben. Ein lokales Konto mit diesem Benutzernamen und dem angegebenen Kennwort wird erstellt.
Nun müssen Sie beide Dialogfelder ausfüllen und Ihre Anwendung veröffentlichen. Starten Sie Ihre Anwendung, und prüfen Sie, ob der Webrollencode ausgeführt wird. Anschließend können Sie die Diagnoseeinstellungen für die Anwendung untersuchen und Ihre implementierten Anpassungen überprüfen (siehe die folgende Abbildung. HINWEIS: Ich verwalte Azure mit den kostenlosen CodePlex-Tools, die an dieser Adresse heruntergeladen werden können: https://wapmmc.codeplex.com/).
Nachdem Code von mir ausgeführt wurde und ich den nächsten geplanten Übertragungszeitraum für die Windows Azure-Protokolle abgewartet habe, werden meine Aufrufe von Trace.* in der Tabelle WADLogsTable angezeigt (siehe die folgende Abbildung):
Da ich außerdem in meiner Anwendung Unterstützung für RDP konfiguriert habe, wird beim Klicken auf die Webrolle die Option zum Herstellen einer RDP-Verbindung mit der Anwendung auf der Symbolleiste im Azure-Entwicklerportal aktiviert:
Nun stehen mir also alle Protokolle und Ablaufverfolgungen meiner Anwendung zur Verfügung, und ich kann mich über RDP mit den Servern verbinden, sollten weitere Untersuchungen nötig sein. Das andere sehr nützliche Feature, das ich aktiviert habe, ist IntelliSense. Ein umfassende Beschreibung von IntelliSense ist in diesem Beitrag nicht vorgesehen, doch auf folgenden Websites finden Sie weiterführende Informationen: https://blogs.msdn.com/b/jnak/archive/2010/06/07/using-intellitrace-to-debug-windows-azure-cloud-services.aspx und https://blogs.msdn.com/b/ianhu/archive/2010/03/16/intellitrace-what-we-collect.aspx. Wenn IntelliTrace aktiviert ist, wird dies in Visual Studio Server Explorer so für meinen gehosteten Dienst angezeigt:
Anschließend kann ich mit der rechten Maustaste auf eine Instanz in meiner Anwendung klicken und den Menüpunkt IntelliTrace-Protokolle anzeigen auswählen. Dies dient zum Herunterladen der IntelliTrace-Protokolle aus Azure und deren Öffnung in Visual Studio (siehe die folgende Abbildung):
Wie die Abbildung zeigt, wird Folgendes angezeigt: die verwendeten Threads, ggf. ausgelöste Ausnahmen, Systeminformationen, die geladenen Module usw. Ich simulierte eine Ausnahme für Testzwecke, für die ich den gesamten für Diagnoseinformationen verfügbaren Speicher auf 5 MB festlegte. Sie werden sich erinnern, dass ich zuvor erwähnt habe, dass mindestens 5 GB erforderlich sind. Ich nahm die Änderung vor und veröffentlichte meine Anwendung. Ein paar Minuten später lud ich die IntelliTrace-Protokolle herunter. Auf der zweite Seite der Protokolle fand ich den Fehler hervorgehoben vor:
Das war sie also, meine brauchbare Übersicht über die Diagnosemöglichkeiten für Windows Azure 1.4. Wir können Ablaufverfolgungsereignisse, Ereignisprotokolle, Leistungsindikatoren, IIS-Protokolle, Absturzabbilder und beliebige benutzerdefinierte Diagnoseprotokolldateien erfassen. Ich kann über RDP eine Verbindung mit dem Server herstellen, sollte eine weitere Problembehandlung nötig sein. Ich kann IntelliTrace-Protokolle aus meiner Anwendung herunterladen und verfüge in meiner lokalen Instanz von Visual Studio 2010 über eine eingeschränkte Debuggingumgebung.
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Windows Azure 1.4 Diagnostics All Up Overview