ASP.NET

Solucionando problemas de aplicativos com logs do IIS

Eduardo Sanabria

Alguma vez você já tentou solucionar problemas ou depurar um aplicativo sem nunca ter visto o código? Você já teve um aplicativo com defeito, e nem o navegador nem o aplicativo forneceu um código de erro é útil?

Já me deparei com essas duas situações muitas vezes, e é uma boa ideia estar preparado para essa eventualidade. As técnicas que descreverei neste artigo ajudarão você a solucionar problemas de qualquer aplicativo ou sistema que esteja sendo executado no IIS, seja qual for a plataforma de codificação. Essas técnicas têm me ajudado a solucionar problemas de aplicativos e sites em uma variedade de situações, especialmente em dispositivos diferentes de PCs – cenário que está se tornando a norma nos dias de hoje. Em um caso recente, essas técnicas me ajudaram a descobrir por que os vídeos não eram exibidos em dispositivos Apple embora fossem reproduzidos perfeitamente em dispositivos baseados no Windows.

Algumas considerações

Há muitas técnicas válidas para depurar ASP.NET e outros aplicativos Web em execução no IIS. O próprio navegador muitas vezes gera um erro específico ou conjunto de erros que é suficiente para resolver os problemas.

Mas vamos supor que essa informação não seja suficiente? É aí que vale a pena saber algumas técnicas extras. A mais simples delas é também uma dos mais rápidas e mais conhecida — executar o aplicativo diretamente no servidor. Às vezes, os servidores não estão configurados para essa opção, mas se você puder fazer isso, o servidor geralmente fornecerá informações de depuração mais úteis do que um computador externo. Esse comportamento é obviamente criado pela Microsoft para fins de segurança. Para obter ainda mais dados sobre o navegador do servidor, desative a opção "Mostrar mensagens de erro HTTP amigáveis", que você encontrará no Internet Explorer, em Opções da Internet | Avançado.

Às vezes, você precisará de mais informações, e é aí que o log se torna essencial. A Microsoft criou poderosos recursos de log em seus servidores, o que ajudará imensamente em qualquer busca de solução de problemas, supondo que você saiba o que procurar e onde.

Ativação do Log do IIS

A primeira etapa é ativar o log do Windows no servidor. Existem várias formas de se fazer isso. As etapas reais podem variar (às vezes muito) dependendo da versão do Windows Server em que são executadas.

Detalhar essas etapas ou descrever as vantagens e desvantagens de cada uma vai além do escopo deste artigo. Aqui, direi simplesmente que para usar corretamente o log para depurar seus aplicativos, você deve ativá-lo antes que ocorram os erros reais. Você encontrará muitas informações úteis nestes dois artigos do MSDN sobre o Windows Server 2003 e 2012: “Como configurar o log de sites no Windows Server 2003” (bit.ly/cbS3xZ) e “Configurar log no IIS” (bit.ly/18vvSgT). Se eles não atenderem às suas necessidades, há muitos outros artigos online relevantes para ativar o log no IIS para outras versões do Windows Server.

Determine o número da ID adequada

Uma vez ativado o log, é preciso descobrir o número de identificação no IIS do site cujos problemas você está solucionando. Isso é crucial, pois os servidores normalmente hospedam mais de um site, e tentar encontrar a pasta de log manualmente pode ser assustador. (Tentei isso em um servidor executando 45 sites e foi quase impossível.)

Abra o Gerenciador do IIS para exibir todos os sites hospedados. Neste exemplo, vamos supor que eu esteja tentando descobrir por que WebSite2 de repente parou de funcionar ou está funcionando apenas em alguns momentos.

Como você pode ver na Figura 1, a ID do WebSite2 é “3”. A próxima etapa é abrir a pasta log correspondente, que é normalmente (mas nem sempre) encontrada na pasta Inetpub. O Windows geralmente cria essa pasta na raiz (C:) do servidor, mas no meu caso, a pasta Inetpub está na unidade D:. As práticas recomendadas do setor aconselham manter o código e as unidades de SO separadas para facilitar a troca em caso de falha.

Finding the Web Site ID Number
Figura 1 Localizando o número de identificação do site

O Windows nomeia todas as pastas de log como W3SVC#, onde # é a ID do site em questão. Como a ID do site que está sendo depurado neste caso é 3, os arquivos de log estão localizados em uma pasta chamada W3SVC3, como ilustrado na Figura 2.

Opening the Log-File Folder
Figura 2 Abrindo a pasta Log-File

Procure os arquivos

Quando você abre a pasta correta, pode ver muitos arquivos. O IIS geralmente mantém muitos arquivos diferentes, dependendo de como você configurou o histórico do servidor ou de quanto tempo o log está ativado. Para encontrar o arquivo necessário, uma aposta quase certa é rolar até o final da lista e abrir o último arquivo, mas se você souber a hora exata em que ocorreu o erro, poderá localizar o arquivo usando a data e a hora no nome do arquivo. De qualquer forma, abra o arquivo usando um editor de arquivos, como Notepad.exe.

Você provavelmente verá muitos dados no arquivo. À primeira vista, as informações podem parecer enigmáticas e inúteis, mas com um pouco de estudo, você pode encontrar muitas joias enterradas nesses dados. Vou descrever alguns dos elementos de dados mais úteis gravados pelo processo de log.

O IIS e o Windows registram em log uma linha individual para cada solicitação HTTP. Uma linha comum é semelhante a esta:

2013-08-28 00:01:12 128.128.128.20 GET /default.asp - 443 - 200.200.200.17 Mozilla/4.0+(compatible; +MSIE+8.0; +Windows+NT+6.1; +WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727; +.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+InfoPath.3;+MS-RTC+LM+8; +.NET4.0C;+.NET4.0E; +.NET+CLR+1.1.4322) 200 0 0 15

Esta é uma linha de um log real do IIS. Os dados mostrados aqui estão em um dos formatos "padrão". No entanto, como esta opção é altamente configurável, não há garantia de que seus arquivos terão exatamente a mesma aparência da minha amostra. Em vez de vagar por todos os dados, vou focar aqui nos elementos que são de maior interesse para depurar um aplicativo.

O primeiro elemento em negrito na amostra é a data da solicitação. Tenha em mente que esta é a data do servidor. Como muitos aplicativos Web são executados no mundo todo por muitos servidores implantados em diferentes fusos horários, essa data pode ser ilusória. Certifique-se de que a data reflita com precisão a hora real em que os erros ocorreram. Muitos servidores usam a hora GMT, mas você deve validar o formato.

Em seguida, você verá o endereço IP que foi acessado, o tipo de operação HTTP (GET) e o arquivo real solicitado ou acessado. Na seguinte linha da amostra, o código está chamando o arquivo default.asp:

128.128.128.20 GET /default.asp

Essa informação é valiosa, pois já deve haver erros ocorrendo nessa fase do processo. Por exemplo, você pode estar esperando um outro arquivo ser executado neste momento.

A próxima parte da linha mostra o endereço IP de origem da solicitação, bem como a porta de recepção:

443 - 200.200.200.17

Essa informação também é importante, pois às vezes é necessário verificar se a solicitação que você está solucionando veio realmente de uma fonte conhecida.

Como você pode ver, a porta real usada também é referenciada. Essa informação aparentemente sem importância é vital na busca por problemas. Por exemplo, o firewall pode não estar configurado corretamente. Esses dados são seguidos de muitas informações, principalmente relacionadas a versões:

+MSIE+8.0; +Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2; +.NET+CLR+2.0.50727; +.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729; +InfoPath.3;+MS-RTC+LM+8; +.NET4.0C

Por exemplo, você pode ver se o navegador está sendo executado 32 ou 64 bits, as versões CLR (para quem quiser investigar isso a fundo no universo .NET), bem como a versão atual do .NET instalado no servidor (neste caso, .NET 4 C).

Vá direto ao ponto da questão 

Até este ponto, mostrei as partes relativamente óbvias da entrada do arquivo de log. O mais importante é que você pode ver qual navegador está respondendo à solicitação HTTP. Às vezes, isso será suficiente, pois navegadores diferentes podem gerar resultados diferentes. Aqui estão algumas sequências parciais mostram como o Firefox e o Chrome podem parecer no arquivo:

;+rv:17.0)+Gecko/20100101+Firefox/17.0 404 0 2 109
+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/­28.0.1500.95+Safari/537.36 200 0 0 125

Pode ser difícil detectar qual das várias solicitações HTTP está sendo depurada, pois todas parecem iguais. É aqui que a mudança do navegador se mostra realmente útil. Adicionar uma entrada de um navegador diferente (e inesperado), como Safari ou Opera, pode facilitar a localização e, consequentemente, a solução do problema da entrada em questão.

Finalmente, dê uma olhada nos últimos quatro itens da linha:

200 0 0 15

O último número, 15, é o tempo de resposta (em milissegundos) da solicitação HTTP. Essa é uma informação muito útil. Saber quanto tempo uma solicitação demorou para ser processada pode ajudar a decidir se determinado trecho de código, serviço Web ou processo está consumindo o tempo "normal" ou desejado.

Você pode se surpreender ao descobrir que etapas relativamente simples em um processo estão consumindo um tempo de processamento inesperado. Em um caso recente, um aplicativo às vezes conectava, às vezes, não, sem gerar um erro detectável no navegador – nenhum outro tipo de erro. Ele simplesmente falhava. Depois de analisar os tempos de resposta no log, os desenvolvedores descobriram esta propriedade no arquivo web.config:

<add name="CacheProfile1" duration="30" />

O valor deste parâmetro, aparente e inofensivamente definido para 30 segundos, era simplesmente muito grande. Uma vez reduzido, o aplicativo funcionou conforme o esperado.

Agora (repetindo a linha aqui para maior clareza) vou zerar em um dos parâmetros mais importantes do conjunto que estou revisando. O primeiro item, 200, é a resposta HTTP real do IIS:

200 0 0 15

 

Esse código de resposta HTTP, 200, é sinônimo de sucesso. Muitas vezes, você encontrará um tipo conhecido de erro, como 404 (não encontrado) ou 500 (erro interno do servidor), e isso pode lhe dar informações suficientes para solucionar um problema. Para uma lista oficial de códigos de status HTTP, visite bit.ly/17sGpwE.

Agora vou relatar mais um caso do mundo real – o que realmente me levou a compartilhar este artigo. Eu tinha um site que funcionava e executava perfeitamente em PCs, mas assim que os usuários acessavam o site em seus iPads, a transmissão de vídeo simplesmente não funcionava. Para piorar as coisas, não havia código de erro, o vídeo apenas se recusava a funcionar.

E foi aí que a solução de problemas com os logs provou-se inestimável. Ao verificar os logs e que a solicitação HTTP estava sendo feita pelo Safari (para isolar a solicitar), descobri que o servidor relatou um erro 404. A mensagem de erro era confusa e o próprio erro parecia improvável, já que a versão para PC do site funcionava perfeitamente.

Embora os logs estivessem relatando que o objeto não estava sendo encontrado, eu sabia muito bem que os arquivos existiam. Isso me levou a rever as diferentes maneiras com que o iOS e o Windows tratavam e armazenavam arquivos. Enquanto eu explorava o código-fonte que carregava o vídeo, descobri que o caminho real para os arquivos de vídeo foram codificados na fonte, e que o caminho não existia em dispositivos iPad iOS. Esse era o motivo do 404.

É importante observar aqui que todos os sintomas apontavam para outra direção. Por exemplo, um problema desse tipo é normalmente resolvido verificando a existência de tipos de mídia sem suporte (ou MIMEs – Multipurpose Internet Mail Extensions) no IIS. No entanto, se o problema fosse um tipo MIME ausente, o código de erro teria sido HTTP 415 (tipo de mídia sem suporte) ou um erro semelhante, e os logs não relataram isso. A depuração usando os logs do IIS provaram ser eficientes na localização do problema. Poupei uma quantidade significativa de tempo ao ver o código de erro real e investigá-lo, em vez de perseguir o que inicialmente parecia mais provável. Mais uma vez, saber ler os logs salvou a pátria.

Conclusão

Os arquivos de log podem ser uma ferramenta poderosa para depurar e solucionar problemas de aplicativos, mesmo em situações "cegas", desde que você saiba onde encontrá-los e o que os dados significam. Investigar os dados nos logs é um dos mais simples – porém mais sofisticados e completos – métodos que você encontrará para resolver problemas.

É preciso um pouco de prática e, certamente, disciplina, mas quando você estiver confortável com essas técnicas, será capaz de depurar e resolver mais problemas de aplicativos e do IIS. Eu fiz bons usos dessas técnicas, você também fará.

Eduardo Sanabria é um consultor de fornecimento de serviços IV para a HP Enterprise Services em El Paso, Texas. Lá, ele entrega resultados de qualidade que fazem a diferença, atuando como especialista em .NET em seu projeto atual. Sanabria contribui com a Hewlett-Packard Co. há mais de 25 anos com sua experiência em desenvolvimento de aplicativos de ciclo completo. As especialidades dele são .NET, aplicativos de banco de dados, processamento de dados e desenvolvimento para a Web. É possível contatar Sanabria pelo email EdSanabria@Yahoo.com.

AGRADECEMOS ao seguinte especialista técnico pela revisão deste artigo: Roger Hawkins (Hewlett-Packard)
Roger Hawkins é tecnólogo-chefe para todas as Américas na Hewlett-Packard, e um tecnólogo diferenciado e grande colaborador para a empresa. "