Passos para monitorar e solucionar problemas em aplicações no Windows Azure

O primeiro ponto é conseguir isolar onde ocorre o problema e para isso é necessário ter instrumentação na aplicação para ser possível um diagnóstico. Para isso você precisa coletar dados de diagnóstico pela importação do módulo Diagnostics dentro do modelo do serviço e pela configuração das fontes de dados para o dados possam ser coletados.

O Windows Azure possui um conjunto de serviços de diagnósticos que pode ser utilizado na aplicação. Você pode começar configurando e gerenciando o diagnóstico e como sugestão seguir os seguintes passos:

• Fazer o setup do diagnóstico inicializando o Windows Azure Diagnostics Monitor e configurar as fontes de dados.
• Adicionar instrumentação de tracing e debugging na sua aplicação.
• Criar e usar contadores de performance (performance counters).
• Transferir os dados de diagnóstico para um storage para preservar e usar os dados.
• (opcional) Gerenciar a configuração do diagnóstico por uma aplicação fora do Windows Azure.

O artigo “Getting Started with Windows Azure Diagnostics” traz uma visão detalhada dos passos acima.

Além dos passos sugeridos acima, o novo portal do Windows Azure traz uma série de novidades sobre o assunto, recomendo a leitura do artigo “How to Monitor Cloud Services”.

Outro ponto muito importante é entender o que monitorar, seguem alguns exemplos:

• Gargalos na aplicação
  • Loops excessivos e Locks. Monitorar Contention Rate / sec e Queue Length Peak (dentro de .NET CLR LocksAndThreads)
  • Excesso de exceções e try-catchs (pode gerar gargalos). Monitorar # of Excepts Thrown / sec (dentro de .NET CLR Exceptions) 
• Gargalos de IO / latência de rede
  • Windows Azure SQL Database
    • Excesso de conexões (que acabam sendo enfileiradas -> throttling). Monitorar HardConnectsPerSecond, SoftConnectsPerSecond, (dentro de .NET Data Provider for SqlServer) e SqlClient: Peak # pooled connections (dentro de .NET CLR Data).
    • Desempenho de queries. Usar as DMVs (https://msdn.microsoft.com/en-us/library/windowsazure/ff394114.aspx).
    • Latência de rede: Ligar tracing to ADO.NET / Entity Framework (https://msdn.microsoft.com/en-us/magazine/gg309181.aspx, https://blogs.msdn.com/b/sqlazure/archive/2010/05/27/10016392.aspx). 
  • Web Services de terceiros
    • Lentidão na resposta: Ligar tracings e/ou fazer teste de carga nesses webservices. 
  • Windows Azure Storage
    • Latência de rede e demora do serviço. Ligar tracing de E2E Latency e Server Latency   (https://blogs.msdn.com/b/windowsazurestorage/archive/2011/08/03/windows-azure-storage-logging-using-logs-to-track-storage-requests.aspx). 
  • Azure Caching
    • Cotas de conexões por hora, volume de dados por hora (se acontecer isso ele gera exceções: https://msdn.microsoft.com/en-us/library/windowsazure/gg185683.aspx).
    • Uma alternativa pode ser o cache dedicado do Windows Azure SDK 1.7 https://www.windowsazure.com/en-us/develop/net/how-to-guides/cache/

Mais sobre a parte de instrumentação, o Visual Studio em conjunto com o Windows Azure tem uma funcionalidade de profiling onde é possível ligar a instrumentação do código. Este artigo traz mais conteúdo sobre o assunto: Profiling a Windows Azure Application.”

Para complementar o post, seguem outras referencias sobre o assunto. São vídeos, artigos e laboratórios:

• Academia: Módulo 4:  Monitorando e gerenciando o Windows Azure (MVA Entendo o Windows Azure).
• Vídeo: Monitoring and troubleshooting Windows Azure apps.
• Treinamento: Azure, High Performance Computing and Identity Training Courses.
• Laboratório: Monitoring Applications in Windows Azure.
• Laboratório: Debugging Applications in Windows Azure (Training Kit do Windows Azure).

Até o próximo post!