DevOps – 02 Passos para Diagnosticar Incidente em um Servidor de Aplicativo em 05 Minutos

1. Introdução

Esse artigo tem como finalidade explicar como analisar um servidor de aplicação ou banco de dados e identificar possíveis falhas através de um rápido diagnóstico. O objetivo é que em 05 minutos você tenha descartado ou confirmado se a falha no aplicativo está associada à infraestrutura e qual o ativo.

Ou seja, o objetivo é através de contadores básicos, identificarmos se há um afunilamento de recursos no Servidor que hospeda a aplicação e caso sim, quem é o responsável por esse afuniliamento.

2. Estratégia

Antes de iniciar, tenha sempre alguns conceitos bem firmados em mente para que sua análise seja rápida e objetiva! Tenha em mente esses 04 conceitos abaixo:

Conceito 1: 90% dos incidentes são coisas simples de se diagnosticar.

Não queria ser um Físico Quântico que é parecido com um cego num quarto escuro à procura de um gato preto que não está lá.

image

Tenha em mente que você precisará analisar todos os servidores que compõem a estrutura de sua aplicação.

Conceito 2: Nenhum erro é igual ao outro, por mais que os sintomas sejam parecidos, sempre inicie sua análise do marco zero novamente.

estacazero

Conceito 3: Lembre-se que a maioria dos incidentes são efeito dominó.

domino2

Ou seja, algo falhou por outro que falhou, que outro que falhou, e assim sucessivamente.

efeito-domino

Por exemplo, lock em banco de dados normalmente é ocasionado por má execução de querys ou store procedures e concorrências ocasionadas pela aplicação, ou pouco recurso no servidor mesmo.

Consumo excessivo de memória pode estar sendo ocasionado por um vazamento (memory leak), ou bug na aplicação, bem como falta mesmo de recurso de memória no servidor.

Conceito 04: Entender a aplicação e o que analisar

Saiba como a aplicação funciona, o que acessa o que, onde os dados são armazenados, quais as melhores práticas de configuração, onde os logs de operação estão armazenados e como interpretar eles, como a aplicação é constituída, por exemplo: Web Services, Windows Services, armazenamento em disco e armazenamento em banco de dados, etc. Quais os aplicativos de terceiros e recursos do sistema operacional que sua aplicação utiliza, por exemplo .NET Framework, Java, Internet Information Services, SNMP, etc.

Assim você poderá estender sua análise corretamente inclusive entender “o que afeta o que”.

3. Passos

Primeiro Passo: Diagnóstico  e Desempenho do Servidor (Tempo de Identificação: 180 segundos)

Abra o Monitor de Desempenho digitando “perfmon” no executar do Windows.

SNAGHTML73414a7

Em seguida vá Desempenho – Sistema e Inicie o Contador “System Diagnostics”

SNAGHTML77c61cf

Inicie e espere a coleta, leva em média 60 segundos, e o tempo máximo é de 10 minutos (tolerância).

image

Em seguida abra o Relatório Diagnóstico gerado para interpretação.

image

Diagnóstico de Saúde

Observe o Relatório abaixo e veja que a parte de Diagnóstico teve um alerta, referente a o UAC estar desativado e o Servidor não possuir nenhum antivirus instalado. Os demais itens estão OK.

image

Caso algum componente apresente uma falha, o Diagnóstico irá informar e detalhar, com por exemplo problemas de bit sujo no disco indicando corrupção.

Diagnóstico de Desempenho

Dentro ainda do mesmo relatório, vamos avaliar agora se temos problemas relacionados à Desempenho.

image

Os itens que devemos sempre observar são: Processador, Memória, Disco e Rede. Se há algum afunilamento neles e caso haja, quem está causando o mesmo (Processo).

Nesse relatório, caso algum dos itens esteja com afunilamento, ele ficará com um STATUS em vermelho. No nosso caso, todos os itens estão OK, sendo que todos estão ociosos e a memória está com status normal. Vamos ver no detalhe a memória. Para isso, no mesmo relatório, clique em Memória.

image

Podemos observar no detalhe, quais os processos estao consumindo mais memória e identificar se um processo de nossa aplicação está consumindo memória de forma anormal, ou se algum processo de um aplicativo de terceiro que nossa aplicação dependa está tendo um consumo anormal, ou se é apenas falta de memória no servidor mesmo.

image

Inclusive é possivel identificar os contadores separados, mas isso é para uma análise mais complexa. Nosso objetivo aqui é uma análise em 05 minutos para identificar possíveis afunilamentos de recursos e os responsáveis pelo mesmo.

Lembre-se de executar esse procedimento em cada servidor que faz parte da aplicação. Caso não possua acesso, solicite ao time responsável a geração do relatório e encaminhamento do mesmo a você. De preferência executar a análise no momento do incidente. Outro ponto importante, ative essas coletas remotamente ao mesmo tempo, conectando no servidor e ativando.

image

Segundo Passo: Diagnóstico de Eventos (Tempo de Identificação: 120 segundos)

Outro diagnóstico importante de ser feito e fácil de identificar são os eventos gerados pelo Sistema Operacional e Aplicativo. Neles é possivel identificar falhas relacionadas ao ambiente e aplicativo e comparar com o diagnóstico feito no primeiro passo e com logs gerados pela aplicação.

Para isso, abra o Visualizador de Eventos no Servidor digitando o comando eventvwr no executar do seu servidor.

SNAGHTML814d815

Em seguida a parte mais simples. Comparar os horários que ocorrem as falhas com possíveis eventos, momentos antes ou depois do incidente.

image

Comparar:

Evento de Aplicativos, inclusive se há eventos por exemplo relacionandos ao Internet Information Services, .NET Framework, JAVA Runtime, Banco de Dados.

Eventos de Sistema, se há erros relacionados a leitura no disco, falha de processamento, parada inesperada de um serviço.

Comparar esses eventos a coleta feita pelo Perfmon mais os logs da sua aplicação.

Lembrando novamente que o objetivo é apenas identificar a falha, para depois entender o motivo que ocasiona ela. Descobrindo a falha, você poderá tomar ações rápidas para contornar o incidente até sua soluçao final. Por exemplo:

– Reinício do Internet Information Services

– Reinício de um serviço da aplicação

Entre outras ações de rapido resultado.

4. Conclusão

Esses templates estao disponíveis nativamente no Windows Server 2008 e Windows Server 2012, bem como nos Windows Clientes (Windows 8 e Windows 10).

O objetivo é uma análise rapida em cima de um ambiente e aplicação para entender o que está impactando o funcionamento. Caso os passos não resolvam, iremos para uma análise mais profunda que envolve:

– Processos

– Contadores Específicos

– Ferramentas Adicionais (Sysinternals, Management Studio do SQL, etc.) mas ficará para um próximo artigo!

Caso queira saber um pouco mais, leia também esse artigo por enquanto: Testes: Medindo o Desempenho de Sua Aplicação

Até a próxima!

Um comentário sobre “DevOps – 02 Passos para Diagnosticar Incidente em um Servidor de Aplicativo em 05 Minutos

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s