nagios automação em grande escala

Question

Gostaria de saber se você tem alguma experiência ou ideia sobre como configurar nagios em grande escala.

Anteriormente usamos nagios e nagiosql para configurações manuais, era bastante confortável para alguns servidores.

Recentemente, o número de servidores foi alterado e a configuração manual do nagiosql ficou desconfortável. Nós usamos o chef para iniciar novas instâncias, eu gostaria de saber se existem boas práticas para usar chef e nagios juntos. Como uma opção, podemos usar apenas nagios e reescrever arquivos de configuração de nagios (com base na função de servidor) toda vez que iniciarmos uma nova instância.

Por exemplo, o cenário poderia ser assim, tendo iniciado um novo servidor mysql, há uma receita dedicada para reescrever o arquivo de configuração do nagios. A receita pode obter todos os dados dos sacos de dados do chef sobre cada servidor e criar configurações com base nas funções do chef.

    

Answer 1

Eu implementei três soluções ligeiramente diferentes para o monitoramento do Nagios usando o Chef nos últimos 18 meses. Eles são todos baseados no recurso de modelo do Chef para gerar arquivos de configuração usando a sintaxe do ERB e esse bit funcionou muito bem. Você tem uma matriz Ruby ou um hash de hosts e serviços, e os arquivos de configuração do Nagios são gerados. É muito fácil testar e depurar.

1. Completamente configuração baseada em bolsa de dados . Nesse caso, há um pacote de dados nagios_hosts e nagios_services e cada host tem uma chave que informa quais verificações de serviço serão executadas, por exemplo, check_load , check_disk . Essa configuração é rápida e funciona razoavelmente bem, embora se os hosts forem excluídos ou os novos adicionados, alguém precise estar por perto para atualizar os pacotes de dados. Na prática, é fácil esquecer isso e as coisas podem ficar desatualizadas, o que pode causar problemas.
2. Configuração baseada no atributo do chef . Aqui, usei a API REST do Chef para consultar um ou mais servidores Chef para obter listas de nós e atribuir verificações de serviço a eles com base nas funções que foram designadas. Ter uma dependência do Chef significa que é difícil monitorar sistemas que não sejam do Chef, por exemplo, dispositivos, dispositivos de rede ou nós que não executam o Chef por qualquer motivo. O Chef acaba enviando uma quantidade enorme de dados JSON pela rede para um grande número de nós e processando todos esses dados coloca uma carga no (s) servidor (es) Chef, bem como no servidor Nagios quando gera arquivos de configuração.
3. aplicativo Rails gerando arquivos de configuração do Nagios . Acabei quebrando a dependência do Chef, armazenando as informações de configuração do Nagios em um banco de dados e tendo um aplicativo Rails gerando os arquivos de configuração. Cada servidor Nagios faz uma solicitação REST e baixa seus arquivos de configuração que são gerados usando o ERB e um banco de dados MySQL. É um pouco de trabalho para conseguir isso, mas até agora está funcionando bem para monitorar os nós Chef e não-Chef.

Então, depois de passar por tudo isso, eu provavelmente recomendaria usar algo como a opção nº 2 para pequenas (dezenas a centenas) de nós. Eu tentaria e manteria isso simples. Eu usei o sistema de atributos do Chef para definir e substituir limites para as verificações de serviço com base em funções e, enquanto ele funciona, é muito complicado e o livro de receitas acabou se tornando uma bagunça inamovível.

Boa sorte!