Debugging Azure Role in lokaler Development Fabric; Diagnostics API

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:

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.

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

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.

dotnet Cologne 2012–Identitätskontrolle

Am 04. Mai war es wieder soweit: Die dotnet Cologne hatte zum vierten mal seine Pforten für die .NET Community geöffnet.

In meinem Talk zum Aufbau von Single Sign-On Lösungen (“Identitätskontrolle”) habe ich im Live-Coding Teil eine Beispielapplikation erstellt welche den Windows Azure Access Control Service verwendet. Auf vielfachen Wunsch findet sich hier der Source Code der erstellten C# Solution.

Die zugehörige Konfiguration des Windows Azure Access Control Service steht ebenfalls online zur Verfügung. Es sollte also keine Probleme beim Nachvollziehen des Beispiels geben.

Wer sich selbst ein Bild von der dotnet Cologne machen möchte kann einen Blick auf das Video vom Konferenztag werfen.

Windows Azure Access Control Service

Im Rahmen der MSDN WebCast Serie „Dienste der Windows Azure Platform“ habe ich einen WebCast zum Thema Windows Azure Access Control Service erstellt.

Alle die sich einen Überblick über die Verwendung von Claims, Active Directory Federation Service (ADFS) und Windows Identity Foundation (WIF) in Verbindung mit dem Windows Azure Access Control Service verschaffen wollen können den WebCast hier herunterladen.

Viel Spaß damit.