Windows – Análises de Incidentes de Aplicativos – Monitor de Confiabilidade e Eventos do Sistema
Introdução
Esse artigo tem como objetivo auxiliar em análises de incidentes de aplicativos que compremetem o sistema operacional, demonstrado como identificar o que está ocorrendo.
Entendimentos
Normalmente, aplicativos de empresas confiáveis dificilmente tornam o sistema operacional instável de uma hora para a outra, isso ocorre devido a diversas proteções e arquitetura que o próprio sistema operacional possui para evitar que ocorra esse tipo de incidente, como a arquitetura de anéis, onde as aplicações e usuários estão no anel 1 e o Kernel (Executivo) do sistema operacional está no anel 0, garantindo assim uma estabilidade maior, pois as requisições passam a ser feitas por API do proprio sistema operacional, e caso haja violação, ela é bem controlada pelo sistema.
Claro que pode ocorrer exceções de violação de memória (endereçamento), ocasionando um “congelamento” ou uma Blue-Screen, mas normalmente são ocasionadas por DRIVERS e DISPOSITIVOS que trabalham em conjunto com o KERNEL no ANEL 0.
Em grande maioria, uma aplicação pode tornar um servidor instável ao ponto de “travá-lo” quando ocorre-se um consumo excessivo de recursos no decorrer do tempo que, dependendo do servidor, pode ser de dias, caso sejam recursos que envolvam espaço em disco, ou memória RAM.
Os recursos comumente “tomados” de forma incorreta por aplicações que ocasionam a indisponibilidade de um servidor são os seguintes:
- Handles (Ponteiros) – Recurso por aplicações para “conversar” e solicitar recursos ao sistema operacional;
Um numero ideal é no máximo 100.000 (isso já é alto), mas o comportamento fácil de indentificar é acompanhar o processo e validar se apenas aumenta e não diminui ou aumenta 10 e diminui 01, por exemplo. Para identificar tais erros, utilize o Gerenciador de Tarefas do Windows. Veja aqui o que significa cada coluna: http://windows.microsoft.com/pt-br/windows/what-task-manager-memory-columns-mean#1TC=windows-7
http://qualidadeeti.files.wordpress.com/2014/11/image_thumb10.png?w=244&h=110
- Memória (Vazamento de memória) – A aplicação apresentar problemas em gerenciamento de memória, ocasionando consumo excessivo até a total “parada” do servidor;
**- Conexões (TCP e UDP) – **Toda a comunicação, seja interna ou externa, é feita via TCP/UDP, e uma aplicação pode apresentar certa instabilidade ao gerenciar tais recursos, ocasionando um consumo excessivo de portas até a total indisponibilidade de um servidor;
Normalmente nesse caso haverá um processo com diversas conexões em estados como TIME_WAI, FIN, ACK, que são estados intermediários entre LISTENING e ESTABILISHED, e que não deveriam estar nesse estado por um tempo elevado. Para acompanhar o comportamento, utilize no servidor que apresenta tal instabilidade, a ferramenta TCP View.
http://qualidadeeti.files.wordpress.com/2014/11/image_thumb11.png?w=244&h=129
Mas é importante entender também se uma instabilidade não está sendo causada por recursos ou incompatibilidade de aplicações, como por exemplo um problema de consumo excessivo de leitura e escrita de disco, está na verdade associado a uma falha de funcionamento do próprio disco, então é importante que nas análises, sejam usadas ferramentas como o Visualizador de Eventos do Windows e oMonitor de Confiabilidade.
Ferramentas de Apoio
Para identificar possíveis falhas nesses cenário pode se usar as ferramentas abaixo:
- Monitor de Confiabilidade (Identificar Correlação de Travamento com outros Aplicativos)
Para exibir o monitor de confiabilidade digite no executar perfmon /rel
http://qualidadeeti.files.wordpress.com/2014/11/image_thumb12.png?w=244&h=145
Verifique na tela que as coletas demonstram incidentes de alguns aplicativos, como o próprio Internet Explorer, possivelmente causado por um plugin de terceiro instalado. Use esse monitor para correlacionar os incidentes de “travamento” do servidor identificar se houve uma falha em conjunto com esse travamento.
http://qualidadeeti.files.wordpress.com/2014/11/image_thumb13.png?w=244&h=106
Caso o monitor de confiabilidade não esteja ativo, você pode ativar e acompanhar. Para ativar a coleta do monitor de confiabilidade, abra o Agendador de Tarefas:
http://qualidadeeti.files.wordpress.com/2014/11/image_thumb14.png?w=244&h=132
Vá na tarefa oculta RAC e configure para executar conforme seus critérios, por exemplo uma vez ao dia, de 12 e 12 horas, quando o sistema iniciar ou a partir de um evento.
http://qualidadeeti.files.wordpress.com/2014/11/image_thumb15.png?w=244&h=227
Exemplos:
http://qualidadeeti.files.wordpress.com/2014/11/image_thumb16.png?w=244&h=94
Clique aqui para maiores informações: http://technet.microsoft.com/pt-br/library/cc766393(v=ws.10).aspx
- Utilizando o Visualizador de Eventos (Identificar Falhas de Componentes ou Dispositivos)
Você pode usar o visualizador de eventos para avaliar se antes da falha no servidor houve algum evento como por exemplo, falha de disco, processador, memória, quando há uma Blue Screen o ID do erro é gravado no evento e com esse ID é possível identificar a raiz do incidente, como uma violação de memória ou falha de equipamento, por exemplo.
http://qualidadeeti.files.wordpress.com/2014/11/image_thumb17.png?w=244&h=129
http://qualidadeeti.files.wordpress.com/2014/11/image_thumb18.png?w=244&h=116
Avalie em Sistema falhas de disco, processador, sistema operacional, gravação de erro de congelamento, ou em **Aplicativo **falhas de componentes, de plugins, do próprio aplicativo em questão.