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

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

Fiz algumas alterações de escala no trabalho do cron e no número de processos do cliente, reduzi o número de plugins em execução etc., mas decidi procurar uma alternativa que possua uma arquitetura mais escalável.

Quaisquer sugestões ou experiências serão bem-vindas. Estou basicamente interessado nas métricas de servidor que cabina devem ser usadas para o planejamento da capacidade e o diagnóstico do uso de recursos. (temos nagios para alertar)

Parece que você pode ter dois problemas

1. No servidor de monitoramento, o registro das métricas para muitos servidores requer uma E / S mais aleatória do que o armazenamento pode fornecer. Mesmo que todas as suas métricas estejam sendo gravadas em disco, o servidor pode estar sobrecarregado demais para gerar gráficos a partir delas.
2. Nos seus clientes sendo monitorados, os plug-ins que coletam as métricas consomem muita CPU e memória e não terminam de coletar dados no momento em que os clientes estão com carga pesada.

Eu usei Munin no passado, mas atualmente estou usando collectd . Os autores de collectd dedicaram muito pensamento e esforço para resolver esse problema. Eles possuem um sistema bem projetado para gravar os dados em arquivos RRD, garantindo 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, portanto, eles usam pouca memória ou tempo de CPU. Nos sistemas clientes, ele usa menos de 2 MB de RAM e cerca de um quarto de segundo do tempo da CPU a cada minuto. No meu servidor de monitoramento, ele usa 20 MB de RAM e dois terços de segundo da 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.

Embora sejam ótimas ferramentas, Munin e outras interfaces do RRDTool (como Cacti ou Ganglia) têm problemas de E / S e dificilmente escalam quando você monitora centenas de nós.

Existem algumas técnicas para lidar com esse gargalo de E / S. 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 administradores de sistema usam os sistemas de arquivos tmpfs para lidar com esse problema. O RRDCached também é uma opção recente e boa para lidar com isso, e eu recomendo que você dê uma olhada nesses slides .

Eu não estou tão familiarizado com Munin, mas o Cacti tem um plugin Boost . Este 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 de que Munin também tem algo assim.

Se você puder pagar, 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 . O Recconoiter é uma nova ferramenta de detecção de gráfico de falhas e gráficos / tendências. Diferentemente da maioria das ferramentas de tendências, o Reconnoiter não é baseado no RRDTool e tenta resolver esse problema específico. Não estou usando o Reconnoiter em produção, mas fiz alguns testes e, apesar de ainda ser um pouco "verde", parece realmente promissor, principalmente em relação à sua escalabilidade.

Espero que isto ajude!

Confira o Zabbix . É uma das melhores ferramentas de monitoramento de desempenho de código aberto disponíveis no mercado. Escala bem e tem sido usado em ambientes com milhares de computadores.

Marco Ramos dá alguns conselhos sólidos. Quero acrescentar 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 desistir. Este é o maior problema com munin.

Outras ferramentas baseadas em rrdtool, como o Ganglia, não estão bloqueadas nesta mesma janela de atualização de 5 minutos, porque não pesquisam todas as fontes de dados da mesma maneira sequencial que munin.

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

Estou substituindo Munin com Ganglia, Munin mata meu servidor, então vou tentar com Ganglia e ver como ele é dimensionado.