O que é um processo sólido para projetar um sistema de monitoramento?

Question

A versão curta: Eu tenho um ambiente heterogêneo de ~ 400 hosts usando Groundwork / Nagios para monitoramento. As verificações atuais, grupos de hosts e grupos de serviços foram reunidos de maneira orgânica e ad hoc. Estou encarregado essencialmente de reconstruir a configuração de monitoramento.

Meu show anterior envolveu menos de 20 máquinas sem requisitos rigorosos de tempo de atividade, monitoradas com Munin - isso está além da minha experiência. Eu estou, na base, procurando por um processo pelo qual essa tarefa possa ser resolvida.

Eu tenho uma vaga noção de designar verificações completas de ponta a ponta para serviços de usuário final - como um scraper tentando fazer login em um de nossos sites - e então ter um conjunto de verificações padrão mais específicas configuradas como verificações dependentes - coisas como verificar se o httpd está em execução, o host está disponível na rede, e ter apenas as verificações de nível inferior executadas quando as verificações de alto nível falham como forma de fornecer visibilidade da causa raiz minimizando a tensão do sistema. Eu também estou pensando geralmente em dividir hosts pelo ambiente, de modo que a equipe só receba páginas de caixas de produção depois do expediente, esse tipo de coisa.

Isso é sensato? Existe uma abordagem de melhores práticas para projetar um sistema de monitoramento? Estou confiante em minha capacidade de migrar de nossa configuração atual menos ideal para algo melhor projetado, mas gostaria de algumas orientações mais experientes sobre como projetar uma configuração ideal em primeiro lugar.

    

Answer 1

Para expandir o meu comentário e, esperamos, dar-lhe um pouco de orientação, o que você provavelmente vai querer tirar do Kyle's postagem no blog ( e esta também , ambas na minha lista de leitura obrigatória referências para pessoas que projetam sistemas de monitoramento) é que uma falha geralmente não é quando uma coisa dá errado - é quando 10 coisas dão errado. O trabalho de um sistema de monitoramento decente é pegar essas 10 coisas antes que elas realmente derrubem seus serviços e impactem as coisas voltadas para o cliente.

O que segue abaixo não é de forma alguma exaustivo ou completo, mas é bastante semelhante ao meu método de lidar com a configuração de monitoramento & você deve ir na direção certa:

1. Para descobrir o que você deseja monitorar, primeiro é necessário pensar no que pode fazer com que as coisas falhem.

   1. Algumas dessas coisas são comuns
      Muitos deles podem ser removidos da postagem de Kyle, por isso não os listarei, mas você deseja ser notificado sobre as condições PRÉ-FALHA - por exemplo, Falha na unidade ONE em um RAID5 - substitua-a agora e evite o tempo de inatividade mais tarde.
   2. Outros variam de acordo com sua infraestrutura / design & incluir dependências em outros serviços
      Se você estiver executando um site com suporte de banco de dados e o banco de dados estiver desativado, seu site não funcionará
      

2. Veja as dependências e construa uma árvore de dependências.
   (Em um datacenter, você pode ir tão longe quanto quiser: no meu último trabalho, fomos uma empresa de hospedagem e nosso sistema de monitoramento conversou com nossos sistemas UPS, Generator e Cooling para nos manter atualizados sobre seu status)

3. Armado com todas essas informações, você pode decidir o que pode ser monitorado proativamente e o que só pode ser reativamente respondido ao (ex. "Network cable (s) yanked out") derrubará qualquer servidor, mas vale a pena monitorar o status da porta do switch, ou você quer que seja uma situação "Está em baixo, tenho que ir olhar para ela"?) .

Isso deixa apenas a tarefa de selecionar software de monitoramento para implementar sua visão. Essa seleção deve se basear em qual pacote permite que você monitore todos (ou a maioria) de qual é a sua lista ideal, e realisticamente levará em consideração as diferenças de preço entre os pacotes.