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!

Dica do Dia – Relatórios de desempenho do servidor com o Operations Manager

Imagine o cenário onde você recebe reclamações dos seus clientes em que determinado serviço, processo, aplicativo Web (Portais e Web Services) ou servidor estão apresentando desempenho abaixo do esperado. Como podemos identificar se esses pontos relatados tiveram incidentes de desempenho, e depois comparar com outros relatórios para identificar a cauza-raiz?

Para identificar essa incidentes, há diversas formas, uma delas é gerar um relatório do Operations Manager do Objeto que você deseja identificar o desempenho. Veja abaixo um exemplo:

Vá em Relatórios – Windows Server Operations System Reports

image

Selecione o objeto Computador que você deseja analisar e selecione o intervalo de datas.

image

image

image

Depois, avalie os relatórios para identificar se há pontos de afunilamento em Processador, Memória, Disco, entre outros. Caso haja, você poderá tirar um outro relatório mais detalhado para identificar qual o processo que está consumindo tais recursos e entender o motivo.

Simples assim.

Espero ter ajudado e até a próxima!

Alan Carlos

DEVOPS – Monitorando Aplicações com os Relatórios do System Center

Esse artigo tem como objetivo auxiliar o time de Desenvolvimento e Operações em análises de aplicações em ambientes de homologação e produção, e conseguir identificar itens como:

Tipos de Relatórios

– Consumo de recursos;

– Incidentes registrados ao longo do tempo (indisponibilidade de serviços, das aplicações Web, banco de dados);

– Identificar possíveis afunilamentos (banco de dados, link, memória, disco, processador) causando lentidão em sua aplicação;

– Boas práticas para manter o ambiente saudável, como os ultimos packs, atualizações do .NET inclusive que resolvem possiveis BUGS em sua aplicação ou falhas de comportamento, dicas de configuração de seu banco de dados.

Responda a perguntas

Meu aplicativo está com um comportamento inesperado devido a má configuração no ambiente?

Meu aplicativo está usando os recursos do ambiente de forma correta?

Qual o desempenho do meu aplicativo?

Meu aplicativo apresentou indisponibilidade em um determinado dia, houve alguma falha em um ativo como Banco de Dados, Link, Memória, Processador?

Meu aplicativo está apresentando lentidão no processamento?

Meu aplicativo está tendo intermitências de funcionamento?

Requisitos

Para realizar esse processo, você deve possuir:

– O System Center Operations Manager 2012 R2 da Microsoft;

– O agente do System Center nos servidores que possuem as aplicações e todos os ativos que compoem o ambiente, por exemplo, um agente instalado no servidor de banco de dados, um agente instalado no servidor Web e de aplicações (Serviços), etc.

– Os Management Packs do System Center para:

    SQL Server

    Windows Server

image

    Internet Information Services (está no catálogo online do System Center)

    – Microsoft Advisor;

Esse é simples, você deve apenas conectar seu SCOM no Advisor, lembrando que os servidores que serão monitorados, deverão ser no minimo Windows 2008 Server e deve estar instalado o .NET Framework 3.5 nos servidores que serão monitorados, para que o Advisor funcione.

Para instalar esses requisitos é muito simples, seguem artigos ajudando, inclusive lhe auxiliando como configurar um serviço ou aplicativo Web para ser monitorado.

ALM – DevOps – SCOM – Monitorar Aplicações Web, Desempenho, Disponibilidade e Executar Ações de Recuperação

ALM – DevOps – Monitorando Aplicações .NET com o System Center

Gerando os Relatórios

– Consumo de Recursos

Identifique se sua aplicação está em ambiente que possui recursos suficientes, e se os recursos estao sendo corretamente utilizados pela aplicação.

Para identificar gere os relatórios:

Reporting –> Windows Server Operation System Reports –> Performance by Utilization

image

image

image

Pergunte-se e obtenha as respostas com esse relatório.

Estou usando um dispositivo que atende a demanda de meu aplicativo?

O disco suporta as taxas de transferência que minha aplicação exige?

O fabricante oferece um equipamento mais robusto?

Minha aplicação foi desenhada para atender o mercado e ambientes dos clientes de médio porte, usando dispositivos com desempenho inferior?

Incidentes registrados ao longo do tempo (indisponibilidade de serviços, das aplicações Web, banco de dados)

Depois de ter configurado os serviços, conforme os artigos acima citados, gere relatórios de acompanhamento, de seu Web Site (que hospeda sua aplicação), seu serviço Windows ou banco de dados e avalie o comportamento de sua aplicação ao longo do tempo, inclusive avaliando possiveis incidentes, falhas de funcionamento, que não são reportadas. Por exemplo, disponibilidade de seu pool de aplicação Web:

Monitoring –> Microsoft Windows Internet Information Services –> Application Pool State (Selecione o Pool) –> Task Pane –> Report Task –> Availability

image

image

image

image

image

Ou alertas de um serviço:

Monitoring –> Windows Service And Process Monitoring –> Windows Service State (Selecione o Serviço)  –> Task Pane –> Report Task –> Availability

image

image

image

Relatórios de alertas de monitoramento de aplicações Web:

image

E diversos outros.

Boas práticas para manter o ambiente saudável, como os ultimos packs, alterações nas configurações, atualizações do .NET inclusive que resolvem possiveis BUGS em sua aplicação ou falhas de comportamento, dicas de configuração de seu banco de dados.

Acompanhe alertas de manutenções, boas práticas de configuração, além de monitorar desempenho de suas aplicações em homologação e produção no cliente.

– Banco de Dados

Monitoring –> Microsoft SQL Server –> Dashboard for SQL Server

image

– Alteração de Configurações

Reporting –> Microsoft Generic Report Library –> Configuration Changes

image

– Dicas de Service Packs, Hotfix, Boas Práticas de Configuração, a serem usadas em seu ambiente

image

image

image

image

image

Há diversos outros relatórios que podem ser usados combinando suas necessidades, explore os mesmos conforme seu objetivo.

Alan Carlos
Technet Wiki Ninja

ALM e Operações – Criando Coletores Para Análise de Aplicações – 2/3

O Objetivo desse artigo é auxiliar o analista e criar coletores do Performance Monitor para auxiliar na coleta de informações de desempenho e uso de recursos pelas aplicações e também do seu servidor.

O que pode ser avaliado com esses contadores:

– Consumo excessivo de processamento

– Consumo excessivo de disco

– Vazamento de memórias (Memory Leak)

Responda a perguntas como:

Você consegue diagnosticar se sua aplicação está usando recursos dos servidores corretamente?

A forma de escrita em disco, alocação de memória, consumo de processador está dentro dos padrões de mercado ou o cliente/usuário necessita de uma estrutura “parruda” e consequentemente cara para hospedar sua aplicação?

Sua aplicação está preparada para trabalhar em ambientes compartilhados e publicos com limitações geográficas e de equipamentos?

Veja aqui a parte 01: ALM e Operações – Analisando o Desempenho do Servidor

Parte 02/03: Analisando Processos

– Ativando Análise de Processos

image

image

image

image

Ao adicionar os contadores de Processos, selecione o contador depois o processo específico, você pode escolher alguns específicos, muito usados para identificar possíveis incidentes ou consumo de recursos, como por exemplo:

Handles (Identificadores): São ponteiros abertos pelas aplicações para comunicação com o sistema operacional solicitando a alocação de recursos. Normalmente se estiver acima de 10.000 possivelmente há vazamento de identificadores. Que podem estar associados a um BUG da aplicação ou um BUG dos componentes Runtime usados como .NET, JAVA, C++, etc.

image

Private Bytes (Bytes Privados): Ajuda a identificar o consumo de memória do processo. Se houver um consumo anormal e com aumento gradativo sem gerenciamento, pode-se estar associado a vazamento de memória da aplicação (memory leak).

Thread Count (Contagem de Threads): Mede o número total de threads ativos em um processo no momento. Pode haver um vazamento de threads se esse número for superior a 500, entre os números mínimo e máximo de threads.

image

Importante: Além dos coletores de Handles, Threads e Memória, também pode-se analisar uso de recursos como disco, processamento, entre outros, conforme abaixo.

image

Local de armazenamento dos logs.

image

Definição da conta a ser usada para a execução da coleta dos contadores.

image

Depois clique em Iniciar (Start) para começar a coleta dos dados.

image

Obs.: Por questões de segurança, você pode setar algumas condições para o coletor para e evitar consumo excessivo de recursos do servidor, como por exemplo espaço em disco. Para isso pare o coletor, clique com o botão direito, vá em propriedades e procure a aba “Stop Condition”. Defina os valores para que ele pare automaticamente. Por exemplo, Maximum Size, em megabytes.

image

Você também pode criar uma agenda dos horários de execução, para coletar nos momentos mais críticos.

image

– Gerando Relatórios (Análise dos Contadores)

Depois de concluindo a captura (caso seje ativado na mão, pare a mesma). Vá em Relatórios e visualize os dados coletados.

image

Observe os contadores nos relatórios, primeiramente eles aparentam um constante no uso dos recursos. Normalmente varia para cima e para baixo, conforme o uso ao dia.

Os indicadores Average (Média) estão abaixos dos usados nesse intervalo. Cuidado ao observar os contadores, pois calcular a escala. Por exemplo:

image

A média é de 639,636, em escala de 0,1 equivale a 639 Handles.

Observe que depois, o Last (Ultimo) é menor que o Maximum (Máximo), ou seja, um comportamento saudável, pois o processo liberou o uso dos ponteiros.

Caso algum ponteiro esteja fora do esperado, você poderá ativar alertas para te comunicar em tempo real os incidentes e também executar um DEBUG ou ativação de TRACE mais apurado da própria aplicação para identificar o que está ocorrendo, usando por exemplo, o System Center Operation Manager.

Você também pode acompanhar o processo em tempo real, em conjunto com a aplicação Process Explorer para realizar identificações adicionais como por exemplo:

– Monitorar trafego de dados do processo com o banco de dados

– Locais de acesso

– Componentes alocados

image

image

image

Referências:

Ask The Core Team Blog – Windows Performance Monitor Disk Counters Explained

Top Six FAQs on Windows 2000 Disk Performance

Technet Magazine – Avaliando o desempenho do seu servidor

ALM e Operações – Criando Coletores Para Análise de Aplicações – 1/3

O Objetivo desse artigo é auxiliar o analista e criar coletores do Performance Monitor para auxiliar na coleta de informações de desempenho e uso de recursos pelas aplicações e também do seu servidor.

O que pode ser avaliado com esses contadores:

– Consumo excessivo de processamento

– Consumo excessivo de disco

– Vazamento de memórias (Memory Leak)

Responda a perguntas como:

Você consegue diagnosticar se sua aplicação está usando recursos dos servidores corretamente?

A forma de escrita em disco, alocação de memória, consumo de processador está dentro dos padrões de mercado ou o cliente/usuário necessita de uma estrutura “parruda” e consequentemente cara para hospedar sua aplicação?

Sua aplicação está preparada para trabalhar em ambientes compartilhados e publicos com limitações geográficas e de equipamentos?

Parte 01/03: Analisando o Desempenho do Servidor

– Ativando o Contador

Para analisar o desempenho no contexto do servidor, será necessário realizar uma análise de três indicadores:

– Processador

– Memória

– Disco

Para isso siga os passos abaixo:

image

image

image

image

image

Insira 03 contadores inicialmente:

Tempo de Processador (quanto tempo de uso e quantidade ficou ocupada, em sua totalidade, pressupoe que sua análise é baseada em desempenho de forma geral não de um Core de Processador ou análise específica de uma aplicação), Mais de 75% precisa avaliar quais processos consomem mais ou a substituição do processador.

Tempo de Fila em Disco Físico (em sua totalidade ou disco, caso seja apenas um disco especifico);

Uso de Memória RAM (em sua totalidade, independente do processo que consome, pois a análise é sobre o servidor). Mais de 80%, precisa avaliar quais processos consomem mais a alocação de mais memória.

image

image 

Defina a conta que irá executar o processo, como uma conta administrativa.

image

Depois de finalizado, inicie o coletor e deixe o mesmo rodando por um período de uso constante dos recursos do servidor, para posterior análise.

image

Obs.: Por questões de segurança, você pode setar algumas condições para o coletor para e evitar consumo excessivo de recursos do servidor, como por exemplo espaço em disco. Para isso pare o coletor, clique com o botão direito, vá em propriedades e procure a aba “Stop Condition”. Defina os valores para que ele pare automaticamente. Por exemplo, Maximum Size, em megabytes.

image

– Gerando Relatórios (Analisando os Contadores)

Depois do tempo que você usou o contador, pare o mesmo e gere os relatórios dos contadores.

image

image

Observe os gráficos e escalas.

image

Interpretando eles temos:

Processador: Em uma duração de 07 minutos, média (average) de 9,97% de uso, muito abaixo dos 75%.

image

Memória: Em uma duração de 07 minutos, média (average) de 37,83% de uso, muito abaixo dos 80%.

image 

Disco Físico (com o uso de virtualizações, devemos estar sempre monitorando esse contador): Em uma duração de 07 minutos, média (average) de 0,2 de uso, muito abaixo dos picos de 100 (se tiver essa constante de 100, há afunilamentos que precisam ser analisados.

image

Importante salientar que caso necessário, você poderá ativar outros contadores para ajudar nessa análise. Clique nos links das referências para maiores informações, e demais contadores.

Referências:

Ask The Core Team Blog – Windows Performance Monitor Disk Counters Explained

Top Six FAQs on Windows 2000 Disk Performance

Technet Magazine – Avaliando o desempenho do seu servidor

Windows Server – Dicas – Melhorar Desempenho de Volume Compartilhado (CSV)

INTRODUÇÃO

Volumes Compartilhados do cluster (CSVs) em um cluster de failover do Windows Server 2012 permitem vários nós do cluster ao mesmo tempo ter acesso de leitura-gravação para o mesmo LUN (disco) que é configurado como um volume NTFS. Com CSVs, funções de clusterizadas podem falhar mais rapidamente de um nó para outro nó sem exigir uma mudança de propriedade de unidade, ou desmontagem e remontagem de um volume. CSVs também ajudam a simplificar o gerenciamento de um número potencialmente grande de LUNs em um cluster de failover.

CENÁRIO

Você possui diversos arquivos VHDX armazenados no disco (DISK1) de compartilhamento CSV. Você percebe que quando ocorre acesso I/O o desempenho se degrada significamente.

SOLUÇÃO

No Windows Powershell execute os seguintes comandos:

(Get-Cluster).SharedVolumeBlockCacheSizeInMB = 512.

Explicação: Esta é uma propriedade comum de cluster que permite definir a quantidade de memória (em megabytes) para reservar para o cache CSV em cada nó no cluster. Por exemplo, se for definido um valor de 512, 512 MB de memória do sistema está reservada em cada nó. (Em muitos clusters, 512 MB é um valor recomendado). A configuração padrão é 0 (para deficientes).

Get-ClusterSharedVolume “Disk1” | Set- ClusterParameter CsvEnableBlockCache 1.

Explicação: Esta é uma propriedade privada do recurso de disco físico de cluster. Ele permite que você ativar cache de CSV em um disco individual que é adicionado ao cluster CSVs. A configuração padrão é 0 (para deficientes). Para habilitar o cache de CSV em um disco, configure um valor de 1.

Depois reinicie cada nó do Cluster.