2011-09-29 4 views
5

Ho un ruolo web in azzurro. Funziona bene localmente nel fabric delle app di sviluppo, ma fallisce silenziosamente quando viene distribuito in Azure (semplicemente nessuna risposta per nessuna richiesta).Come rintracciare gli errori all'avvio del ruolo Web di Azure?

Presumo che ci sia qualche problema con il web.config, ma ciò sta accadendo così presto che si verifica già prima che io possa impostare il materiale diagnostico nell'asax globale. Come detto, funziona a livello locale, ma non c'è semplicemente alcuna risposta dal sistema azzurro.

Come posso scoprire che cosa è specificamente sbagliato essere in grado di risolverlo come ottenere il testo dell'eccezione, la traccia dello stack, il registro degli errori del sistema applicativo di IIS o qualcosa che potrebbe suggerire il vero problema?

risposta

4

La prima cosa assoluta che viene eseguita in un ruolo Web non è l'applicazione ma il metodo OnStart() in WebRole.cs nel progetto di Azure. Questo è il posto dove aggiungere codice per monitorare il tuo sito Web.

La tecnica standard consiste nel copiare i registri di traccia delle applicazioni ei registri degli eventi di Windows nell'archivio della tabella di Azure, insieme (se necessario) con la strumentazione per l'utilizzo della CPU, le statistiche IIS e what-have-you.

Una buona introduzione a questo è qui: http://blog.bareweb.eu/2011/01/beginning-azure-diagnostics/

e un buon follow con i dettagli sulle specifiche di cui ha bisogno nella vostra applicazione è qui: http://blog.bareweb.eu/2011/03/implementing-azure-diagnostics-with-sdk-v1-4/

che resta applicabile per l'Azure SDK 1.5.

Dopo aver acquisito la diagnostica, è possibile utilizzare Visual Studio per visualizzarli direttamente oppure è possibile utilizzare uno strumento come Cerebrata Azure Diagnostics Manager per rappresentare graficamente e filtrarli automaticamente. Questo strumento è un po 'approssimativo attorno ai bordi (specialmente per i sistemi più grandi con più istanze: i grafici non sono molto utili) ma è buono come al momento.


Un approccio alternativo è quello di utilizzare Desktop remoto per connettersi all'istanza remota e fare qualche speleologia nei registri eventi di Windows e simili. È inoltre possibile utilizzare il browser Internet Explorer presente nell'istanza remota per collegarsi direttamente all'applicazione e vedere eventuali errori, ecc. Che potrebbero altrimenti essere nascosti.

Personalmente lo farei solo se il meccanismo di archiviazione diagnostica non funziona: i server di produzione dovrebbero in realtà avere l'accesso remoto al desktop completamente disattivato per ridurre l'area di superficie possibile per un attacco esterno.

+0

Con il desktop remoto ho potuto rintracciare l'errore. Il problema era che all'avvio dell'applicazione un riferimento all'assembly era sbagliato (versione errata dell'assembly). Dal momento che ciò accadeva prima che qualsiasi altro codice potesse essere eseguito, era un po 'complicato, ma l'ho trovato dai registri di sys. –

+0

Buona cattura, bello - Ho avuto un problema simile a un certo punto con un assemblaggio di 32 bit canaglia che si intrufolava sotto il radar. –