Startseite > Azure > Debugging Azure Role in lokaler Development Fabric; Diagnostics API

Debugging Azure Role in lokaler Development Fabric; Diagnostics API

DDC_2012_BannerSpeaker

Letzte Woche hatte ich auf der DDC 2012 am Expertentisch noch eine sehr interessante Diskussion zum Thema Windows Azure Diagnostics API. Wie versprochen hier eine kurze Einführung und Zusammenfassung des Themas. Sowie eine Empfehlung, wie das lokale Debuggen eines Azure Services erleichtert wird.

 

Problemstellung

Zur Überwachung und Abrechnung von Azure Cloud Services (WebRole / WorkerRole) liefert das Azure Diagnostics API Funktionen an die Hand, die das Leben sehr viel einfacher machen.

Sollte mal wieder keine Visual Studio Ultimate Edition zur Verfügung stehen und damit auch kein Intelli-Trace hilft das Diagnostics API auch evtl. Fehler nachvollziehbar zu machen. Gerade deshalb finden sich häufig Kommandos wie:

        protected void Page_Load(object sender, EventArgs e)
        {
            System.Diagnostics.Trace.TraceInformation(
                String.Format("Page_Load {0}",
                DateTime.Now.ToString()));
        }

im Source Code um an markanten Stellen den Programmablauf nachvollziehen zu können. Sobald man einen Service nun in der lokalen Development Fabric entwickelt, kann es sehr schnell zu dem Phänomen führen, dass die Trace Aufrufe nicht sofort ersichtlich sind und nicht im Storage Emulator erscheinen.

Allgemein arbeitet das Diagnostics API nach folgendem Verfahren:

Diagnostics_Overview

1: Cloud Service startet und konfiguriert DiagnosticMonitor

2: DiagnosticMonitor sammelt und verwaltet Trace Info vom Cloud Service und von Windows Datenquellen (IIS Logs, Failed Reqeust Logs, Perf. Counters, Event Logs)

3: Speichert Info im lokalen Filesystem der virtuellen Maschine welche den Cloud Service ausführt.

4: Transferiert in regelmäßigen Abständen oder auf Anforderung die Trace Informationen in einen gültigen Azure Storage Account.

Gerade der Punkt 4 stellt sich hier als Problem dar. Selbst in der lokalen Entwicklungsumgebung (Development Fabric) wird das Verhalten des Diagnostic Monitor simuliert. Dieser überträgt dementsprechend die Trace Informationen nur zeitverzögert in den lokalen Storage Emulator. Dadurch verlieren die Trace Informationen deutlich an Wert.

Lösungsansatz

Beim lokalen Entwickeln bzw. debuggen wird nicht der TraceListener der als Default beim Erstellen eines neuen Cloud Service in der web.config eingebunden wird verwendet sondern ein Listener, der die Trace Ausgaben direkt in den Development Storage schreibt.

<configuration>
  <system.diagnostics>
    <trace autoflush="true">
      <listeners>
        <!-- Default Trace Listener wird ersetzt -->
        <!--<add type="Microsoft.WindowsAzure.Diagnostics.
             DiagnosticMonitorTraceListener, 
             Microsoft.WindowsAzure.Diagnostics, 
             Version=1.0.0.0, Culture=neutral, 
             PublicKeyToken=31bf3856ad364e35" 
             name="AzureDiagnostics" />-->

        <!-- Trace Listener, welcher direkt in Storage schreibt -->
        <add name="azureLog" 
             type="AzureDiagnostics.TableStorageTraceListener, 
             AzureDiagnostics" />
      </listeners>
    </trace>
  </system.diagnostics>
</configuration>

Der TraceListener <<TableStorageTraceListener>> wird von Microsoft zur Verfügung gestellt und kann einfach geladen werden. Am Ende findet sich ein Link zu einer Beispielapplikation in welcher der Listener ebenfalls enthalten ist.

Als unschön stellt sich nun dar, dass die Web.config vor dem Deploy wieder manuell geändert werden muss um den vorherigen TraceListener zu aktivieren. Visual Studio stellt hier mit den „Visual Studio Configuration Transforms“ aber auch ein elegantes Mittel zum Lösen des Problems zur Verfügung. Einfach im “Configuration Manager” eine neue Build Konfiguration auf Basis der existierenden “Debug” Konfiguration erzeugen. Im Beispiel habe ich sie “Debug – DirectTrace” genannt.

Diagnostics_Configuration

Nun in Visual Studio in der Datei “Web.Debug – DirectTrace.config”

Diagnostics_SolutionNavigator

folgende Transformierung anlegen:

<configuration 
  xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.web>
  </system.web>

  <system.diagnostics>
    <trace autoflush="true">
      <listeners xdt:Transform="Replace">
        <add name="azureLog" 
             type="AzureDiagnostics.TableStorageTraceListener,
             AzureDiagnostics" />
      </listeners>
    </trace>
  </system.diagnostics>

</configuration>

Unter Verwendung der neuen Build Konfiguration kann nun lokal mit dem TraceListener, der sofort in den lokalen Storage Emulator schreibt, gearbeitet werden.

Leider findet sich  noch ein Bug im Azure SDK 1.6.0 der die Transformierung nicht korrekt durchführt. Um den Bug zu umgehen, muss manuell im Projektfile der Azure Solution der Eintrag:

<packagewebrole>true</packagewebrole>

unterhalb von

<Project ...="">
  <PropertyGroup>
    ...
    <packagewebrole>true</packagewebrole>

eingefügt werden.

Beim späteren Cloud Deploy muss nun nichts besonderes beachtet werden, da der neue TraceListener hier nicht zur Verwendung kommt.

Ich hoffe ich kann mit der obigen Beschreibung und der Beispielapplikation alle noch offenen Fragen von der DDC klären.

Kategorien:Azure Schlagwörter: , ,
  1. Es gibt noch keine Kommentare.
  1. No trackbacks yet.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: