Você já olhou para o Ganglia ?
Eu duvido strongmente que Munin escalaria ao seu tamanho. Mas o Ganglia é projetado desde o início para grandes grupos de servidores.
Estamos usando o Cacti com RRDTool para monitorar e representar graficamente cerca de 100.000 contadores espalhados em cerca de 1.000 nós baseados no Linux. No entanto, nossa configuração atual geralmente nos fornece gráficos de 5 minutos (com alguns dados sendo baseados em minutos); Geralmente, fazemos alterações em que ver comentários em "quase tempo real" seria valioso. Eu gostaria de aproximadamente uma semana de dados de 5 ou 10 segundos, um ano de dados de 1 minuto e 5 anos de dados de 10 minutos. Tenho discos SSD e um servidor dual-hexa-core de sobra.
Eu tentei configurar um servidor Graphite / carbon / whisper, e tinha cerca de 15 nós pipe, mas ele só tem "média" para a função de retenção ao promover para buckets mais antigos. Isso é quase inútil - eu gostaria de min, max, média, desvio padrão, e talvez "total sum" e "number of samples" ou talvez "95th percentile" disponível. O desenvolvedor alega que há um novo back-end "in beta" que permite que você escreva sua própria função, mas isso ainda só faz a retenção 1: 1 (ao salvar dados antigos, você realmente quer as estatísticas calculadas em muitos fluxos de um única entrada. Além disso, "in beta" parece um pouco arriscado para esta instalação. Se eu estiver errado sobre essa suposição, ficarei feliz em receber meu erro!
Eu ouvi o Zabbix recomendado, mas ele coloca dados no MySQL ou em algum outro banco de dados SQL. 100.000 contadores em um intervalo de 5 segundos significam 20.000 tps e, embora eu tenha um SSD, não tenho um RAID-6 de 8 vias com cache de backup de bateria, o que eu acho que precisaria para que isso funcionasse :-) Novamente, se isso é realmente algo que não é um problema, eu ficaria feliz em receber o erro dos meus caminhos. Além disso, o Zabbix pode fazer o fluxo de dados único - > promover com coisa de estatísticas?
Finalmente, Munin afirma ter um novo 2.0 saindo "em beta" agora, e possui planos de retenção personalizados. No entanto, mais uma vez, é essa parte "em beta" - alguém já usou isso de verdade e em escala? Como foi o desempenho, se sim?
Estou quase pensando em usar um frontend gráfico (como o Graphite) e criar meu próprio back-end de retenção com uma camada simples em cima de mmap () e algumas estatísticas. Isso não seria particularmente difícil, e provavelmente funcionaria muito bem, deixando o kernel descobrir o equilíbrio entre a frequência de liberação para o disco e as operações de processo.
Alguma outra sugestão que eu deva investigar? Nota: ele deve ter se mostrado capaz de sustentar os tipos de cargas de dados que estou sugerindo acima; Se você pode apontar para a implementação específica que você está referenciando, tanto melhor!
Você já olhou para o Ganglia ?
Eu duvido strongmente que Munin escalaria ao seu tamanho. Mas o Ganglia é projetado desde o início para grandes grupos de servidores.
O Zabbix é conhecido por ter um bom desempenho em mais de 1000 ambientes de hosts, sua atualização de 5 segundos é um pouco inédita (talvez você precise que a periodicidade para a maioria deles e algo como 30seg para alguns deles seja OK para você).
Proxies Zabbix (pense neles como mini-Zabbix Servers) são defendidos em grandes instalações para reduzir a carga sobre o Zabbix Server. link
Do próprio Alexei:
"Ele coletará dados de desempenho e disponibilidade e também executará a descoberta automática no nome do ZABBIX Server:
Confira Graphite, link . Eles têm isto a dizer sobre alta capacidade:
Graphite was internally developed by Orbitz.com where it is used to visualize a variety of operations-critical data including application metrics, database metrics, sales, etc. At the time of this writing, the production system at Orbitz can handle approximately 160,000 distinct metrics per minute running on two niagra-2 Sun servers on a very fast SAN.
Estou com as outras pessoas que comentaram perguntando por que você precisa monitorar tantos itens em uma frequência tão curta. O maior problema com isso é que seu sistema de monitoramento começará a causar falsos positivos em relação à carga e você estará reduzindo o tempo de CPU disponível para outro processamento. Mover o intervalo de monitoramento de 5 para 15 segundos causará uma queda de 80% na sobrecarga de monitoramento e ainda fornecerá pelo menos o dobro da visibilidade mínima normal, que geralmente é em torno de 30 segundos. Além disso, quando você olha mais de perto, pode determinar que alguns itens não precisem ser monitorados a cada 15 ou 30 segundos. Um exemplo é o disco, você pode manipular uma vez a cada 30 ou 60 segundos. Por exemplo, se você escrever somente 1.7MB / s, você só conseguirá empurrar 100MB em um minuto. Se o seu sistema de monitoramento estiver configurado para alarme em 1 GB, por exemplo, agora você tem cerca de 100 minutos antes de sair do disco (usando este exemplo de disco lento). CPU, por que você precisa saber o que está fazendo com uma resolução de menos de 30 segundos? Ele é carregado em 100% em uma nuvem, ótimo, ele está fazendo algum trabalho como um nó de cluster deve estar fazendo. Mas se estiver com 100% de carga quando a fila de trabalho for 0, você tem um problema.
Além disso, o monitoramento em uma frequência tão restrita aumenta sua busca por falsos positivos devido a artefatos induzidos em seu conjunto de dados. Por exemplo, se o seu sistema de monitoramento está causando uma carga de base de 20% e 100KB / s de monitorar tudo em um intervalo de 5 segundos, você realmente está obtendo uma imagem precisa do que seu host está fazendo? Quanto aos falsos positivos, considere o acionamento na carga de rede de 500KB / s, somente seu sistema de monitoramento coloca você a 20% do caminho até lá.
Além disso, você não sugeriu nada do acima, o que me faz pensar que o Zabbix não pode lidar com o que você quer fazer. Dê uma chance, estaremos esperando na comunidade do Zabbix para ajudá-lo quando necessário.