O que verificar durante uma verificação periódica do sistema

Question

Recebi a tarefa de preparar uma lista de verificações para fazer como parte de uma rotina semanal de verificação de integridade do sistema que minha equipe deveria fazer. O problema é que nem eu nem nenhum dos meus colegas já fomos administradores de sistemas profissionais, e o melhor que conseguimos é risível.

O sistema executa o Siemens SIMATIC IT e o LIMS, mas estou interessado em algumas verificações / testes genéricos para sistemas operacionais e servidores de banco de dados. Alguém cuidará de testes específicos para os aplicativos que estão sendo executados.

A configuração é a seguinte:

Todos os servidores são virtuais, sendo executados no ambiente do vSphere5.

• Servidor Web - MS Windows Server 2003 R2
• 2 servidores que executam os componentes do SIMATIC IT, um para o Historiador e um para o Modelador de Produção e outros componentes - MS Windows Server 2003 R2
• Servidor de banco de dados - MS Windows Server 2003 R2 + MS SQL Server 2005
• Banco de dados + servidor LIMS - MS Windows Server 2008 R2 + Banco de dados Oracle 11g

Provavelmente não teremos acesso ao console do vCenter, então a idéia é conectar uma área de trabalho remota a esses servidores, fazer algumas verificações / testes construtivos e preparar um relatório.

Como eu já escrevi, não há muito além de procurar por um espaço livre em disco, que eu possa inventar. Eu também posso pensar em verificar o nível de fragmentação de um sistema de arquivos e erros do sistema de arquivos com ChkDsk, olhando para o visualizador de eventos do Windows para alguns erros importantes e avisos, verificando o nível de fragmentação do índice em bancos de dados e talvez coletando algumas estatísticas de tempos de resposta e tempos de execução de algumas consultas importantes.

Eu apreciarei muito qualquer ajuda. Além de informações sobre o que deve ser verificado, dicas para o que não fazer em um sistema que está sob carga 24/5 também será muito útil. Por exemplo, executar um desfragmentador mesmo para análise em um servidor de banco de dados sob carga pode ser uma ideia muito ruim, mas ainda não sei.

Obrigado.

    

Answer 1

Você está sendo solicitado a fazer isso errado.

Você não deve fazer login nos sistemas de produção e fazer verificações manuais periódicas.
Isso garante que você (a) perderá algo que acontece entre as verificações e desestimula sua empresa, e (b) acabará se atrapalhando ao fazer as verificações e derrubar o negócio.

Em vez disso, você deve implementar um sistema de monitoramento que faz verificações periódicas contínuas (a cada 5-10 minutos) e relata anomalias para você. Consulte a tag monitoring para mais informações e ideias sobre o que verificar.

Espaço em disco, utilização de troca e carga da CPU (profundidade de RunQ) são coisas típicas para monitorar. Você também pode querer executar (e marcar / marcar a saída de) consultas de teste padrão em servidores de banco de dados (essas consultas são algo que você precisa criar com base em seu ambiente).

    

Answer 2

Para servidores em execução no sistema operacional Windows, verificações importantes podem ser:

• Utilização da CPU.
• Utilização da RAM.
• Espaço disponível no disco rígido.
• Serviço do servidor Web (IIS) em execução ou não.

Da perspectiva de rede:

• DNS bem configurado
• IP do DHCP

Isso pode ser útil ...

    

Answer 3

Eu adicionaria outra coisa à lista, porque é um servidor da Web.

• configure uma tarefa agendada para COUNT o número de respostas "200", "500", "401" e "503" nos registros do IIS - você pode usar o LOGPARSER para fazer isso. A ideia é que o script contaria o número de ocorrências de cada um e depois dividiria o número de 500 e 503 respostas pelo número de 200 respostas. Isso proporcionará a integridade geral do desempenho da resposta do servidor da Web, como uma proporção de falha (500) / sucesso (200).

  • 500 - Erro - a chamada da web falhou
  • 503 - Tempo limite - o proxy da web nunca recebeu uma resposta do servidor da web upstream
  • 401 - Não autorizado - a chamada da Web não autenticou
  • 200 - Sucesso - a chamada da web foi processada sem erros

Em seguida, o script deve carregar os resultados (incluindo os dados brutos) em um sistema central de relatórios, para que você possa examiná-los sem precisar fazer login localmente.

Se você precisar de um exame mais aprofundado dos logs (digamos, o que o pool de aplicativos está fazendo mal se for o caso), há muitas outras coisas que você pode usar no LOGPARSER para descobrir essas coisas.