Uno dei vantaggi di Windows Azure è costituito dal totale disinteresse che si deve prestare sul server dove l'applicazione risiede, sulla gestione delle tematiche hardware, dei dischi, dei backup ecc. Questo perché non si dispone di un accesso fisico al server, ma solo di un pannello amministrativo per i deployment.

La realtà però insegna che errori, bug e malfunzionamenti sono all'ordine del giorno ed attività come il logging ed il tracing sono fondamentali per una diagnostica. Fortunatamente già le API di Windows Azure includono un sistema di diagnostica, governato dalla classe DiagnosticMonitor del namespace Microsoft.WindowsAzure.Diagnostics, che si occupa di collezionare attività di IIS, dell'insfrastruttura, Windows Event, performance counter, crush dump e logging personalizzato. Quest'ultimo è ottenibile mediante l'infrastruttura classica del .NET Framework e in particolare dell'oggetto Trace del namespace System.Diagnostics.

Per effettuare il logging è quindi necessario usare, laddove lo si ritiene, i metodi statici della classe Trace per tracciare errori o marcare delle informazioni. Essendo una classe del .NET Framework è possibile usarla liberamente su tutti gli strati, senza accoppiarsi necessariamente a Windows Azure, come nell'esempio seguente:

Trace.TraceError("Errore xxx");

Occorre poi aggiungere il tracing nel file app/web.config del ruolo, tramite l'apposita sezione system.diagnostics/trace/listeners, la quale permette di specificare listener personalizzati che mandino email o che scrivano su db. In questo caso si aggiunge un listener che si aggancia a Windows Azure.

<configuration>
  <system.diagnostics>
    <trace autoflush="true">
      <listeners>
        <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
           name="AzureDiagnostics">
          <filter type="" />
        </add>
      </listeners>
    </trace>
  </system.diagnostics>
</configuration>

Come anticipato la diagnostica su Windows Azure fa capo alla classe DiagnosticMonitor, la cui particolarità è di permettere di persistere i dati raccolti sullo storage di Windows Azure: in table o blob a seconda del tipo di log. Depositare queste informazioni su tali servizi è la via più comoda per un ruolo, mentre la consultazione e la manipolazione remota è la più immediata per l'amministratore. Per questo motivo sull'OnStart del ruolo è necessario chiamare la seguente riga di codice.

DiagnosticMonitor.Start("DataConnectionString");

Il parametro DataConnectionString indica il nome della stringa di connessione che specifica gli endpoint e le credenziali d'accesso verso lo storage. Il template di Visual Studio 2010 prevede già questa istruzione, così come la configurazione del listener, perciò normalmente si è già pronti per la diagnostica.

Tuttavia questo non è sufficiente, perché occorre configurare le modalità con cui effettuare il logging. Poiché si accede ai servizi di storage tramite HTTP, le loro prestazioni non sono particolarmente indicate per attività di logging, le quali possono essere intense e rallentare l'intera applicazione. E' quindi necessario ottenere la configurazione predefinita e modificare le policy, come nel seguente codice.

DiagnosticMonitorConfiguration diagConfig = DiagnosticMonitor.GetDefaultInitialConfiguration();
diagConfig.Logs.ScheduledTransferLogLevelFilter = LogLevel.Error;
diagConfig.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);

// Attivo la diagnostica specificando la configurazione
DiagnosticMonitor.Start("DataConnectionString", diagConfig);

Tra i tanti parametri è possibile indicare che genere di filtro adottare (nell'esempio solo gli errori) e specificare ogni quanti minuti trasferire il buffer di informazioni. In pratica quest'ultime vengono collezionate in memoria e a intervalli regolari scritte sullo storage. Va evidenziato che poiché ogni operazione sul database è considerata come una transazione ai fini della fatturazione, è necessario misurare attentamente la quantità e la frequenza del logging.