Eu preciso substituir munin com algo mais escalável [fechado]

Question

Eu tenho usado o munin em vários servidores por muitos anos com grande sucesso, porém com mais de 100 nós munin e quando há carga nos clientes, o processamento está expirando.

Eu fiz algumas alterações de escala para o cron job, e número de processos do cliente, e reduzi o número de plugins rodando etc. mas decidi procurar uma alternativa que tenha uma arquitetura mais escalável.

Qualquer sugestão ou experiência seria bem vinda. Estou basicamente interessado em métricas de servidor que podem ser usadas para planejamento de capacidade e diagnóstico de uso de recursos. (nós temos nagios para alertar)

    

Answer 1

Parece que você pode ter dois problemas

1. No seu servidor de monitoramento, a gravação das métricas para vários servidores requer mais i / o aleatório do que o seu armazenamento pode fornecer. Mesmo que todas as suas métricas estejam sendo gravadas no disco, o servidor pode estar muito sobrecarregado para gerar gráficos a partir delas.
2. Em seus clientes que estão sendo monitorados, os plug-ins que coletam as métricas são muito intensivos em CPU e memória e não concluem a coleta de dados no momento em que os clientes estão com carga pesada.

Eu usei Munin no passado, mas atualmente estou usando collectd . Os autores do collectd colocaram muita reflexão e esforço na solução desses problemas. Eles têm um sistema bem projetado para gravar os dados nos arquivos RRD , o que garante que você não perca dados e possa gerar gráficos atualizados. Também há suporte para RRDCacheD . O daemon e os plugins oficiais são escritos em C, então eles usam pouca memória ou tempo de CPU. Nos meus sistemas clientes, ele usa menos de 2MB de RAM e cerca de um quarto de segundo de tempo de CPU a cada minuto. No meu servidor de monitoramento está usando 20MB de RAM e dois terços de um segundo de tempo de CPU a cada minuto. Lembre-se de que todas as minhas métricas estão sendo reunidas e enviadas ao meu servidor de monitoramento a cada dez segundos, em vez de em intervalos de minutos como munin.

    

Answer 2

Apesar de serem ótimas ferramentas, Munin e outros frontends do RRDTool (como Cacti ou Ganglia) têm problemas de i / o e são difíceis de escalar quando você monitora hundreads de nós.

Existem algumas técnicas para lidar com esse gargalo de i / o. Uma dessas técnicas é espalhar gravações em um grande número de discos para reduzir a E / S em cada disco. Por outro lado, muitos sysadmins usam sistemas de arquivos tmpfs para lidar com este problema. RRDCached também é uma opção recente e boa para lidar com isso e eu recomendo que você dê uma olhada nestes slides .

Eu não sou tão familiarizado com Munin, mas o Cacti tem um plugin Boost . Esse plug-in armazena em cache os dados na memória e executa atualizações em massa e sob demanda no disco, em vez de gravações individuais, reduzindo assim a E / S. Tenho certeza que Munin também tem algo assim.

Se você puder comprá-los, os discos SSD também são boas opções.

Por último, mas não menos importante, você também pode dar uma olhada no Reconnoiter . Recconoiter é uma nova ferramenta de detecção de falhas e gráficos / tendências. Ao contrário da maioria das ferramentas de tendências, o Reconnoiter não é baseado em RRDTool e tenta resolver este problema específico. Eu não estou usando o Reconnoiter em produção, mas eu fiz alguns testes, e apesar de ainda ser um pouco "verde", parece realmente promissor, especialmente em relação à sua escalabilidade.

Espero que isso ajude!

    

Answer 3

Confira o Zabbix . É uma das melhores ferramentas de monitoramento de desempenho de código aberto existente no mercado. Ele escala bem e foi usado em ambientes com milhares de computadores.

    

Answer 4

Marco Ramos dá alguns conselhos sólidos. Eu quero adicionar alguns esclarecimentos, no entanto: o grande problema com munin é o cronograma fixo de coleta de 5 minutos. Se todos os nós não retornarem resultados dentro da janela de 5 minutos, você começará a obter desistências. Este é o maior problema com munin.

Outras ferramentas baseadas em rrdtool, como o Ganglia, não são bloqueadas nesta mesma janela de atualização de 5 minutos porque elas não fazem poll de todas as fontes de dados da mesma forma sequencial que o munin faz.

Eu recomendaria que você olhasse para o Ganglia porque ele geralmente parece ser bem dimensionado (embora você precise desativar a coleta de dados multicast para uma grande instalação de gânglios). Eu suspeito que você pode percorrer um longo caminho com os gânglios antes de começar a se preocupar com o fato de o rrdtool ser o ponto de estrangulamento. Nesse ponto, você pode fazer o tipo de coisas que Marco sugere, como usar unidades SSD.

    

Answer 5

Eu estou substituindo o Munin w / Ganglia, o Munin mata o meu servidor, então vou experimentar o Ganglia e ver como ele é escalável.