Carga alta em um servidor nagios - Quantas verificações de serviço para um servidor nagios são demais?


9

Eu tenho um servidor nagios executando o Ubuntu com um processador Intel de 2,0 GHz, uma matriz RAID10 e 400 MB de RAM. Ele monitora um total de 42 serviços em 8 hosts, a maioria dos quais é verificada usando o plug-in check_http por até 5 minutos, alguns a cada minuto. Recentemente, a carga no servidor nagios ficou acima de 4, geralmente tão alta quanto 6. O servidor também executa cactos, reunindo estatísticas a cada minuto para 6 hosts.

Pergunto-me, quantos serviços um hardware como esse poderia suportar? A carga é tão alta porque estou pressionando os limites do hardware ou esse hardware deve poder lidar com 42 verificações de serviço mais cactos? Se o hardware for inadequado, devo adicionar mais RAM, mais núcleos ou núcleos mais rápidos? Quais verificações de hardware / serviço estão sendo executadas por outras pessoas?


Como é o uso de memória RAM agora no servidor? Também como é o uso da CPU? Se isso é alto, quais processos estão atrelando?
3dinfluence

Você resolveu o problema ? Estamos enfrentando o mesmo problema. A média de carga é 12 .. #
John

Respostas:


7

Você precisa descobrir onde está o seu gargalo ...

Eu corro um monitor nagios que verifica mais de 400 hosts com http, ping e ssh. (junto com muitas outras verificações passivas e nscd)

Este é um servidor 2xQuadCore com 4 discos SAS no RAID10.

Eu suspeito que você esteja tendo contenção de entrada / saída, pois escrever para muitos rrds é muito ineficiente.

Você precisa descobrir qual processo está consumindo seus recursos. (cactos, nagios ou outra coisa)

Para verificação de IO, eu gosto do iotop. Instale o iotop (o pacote 9.04 funciona no 8.04)

Mas, caso contrário, o top também deve ajudá-lo a encontrar o seu porco.

Cactos uma vez por minuto é bastante agressivo. (Eu corro o meu em intervalos de 5m)

Uma abordagem que ouvi sobre a contenção de gravação rrd é colocar seus repositórios rrd em um ramdisk / tmpfs. (certifique-se de sincronizar isso de vez em quando para armazenamento persistente)

Boa sorte.


Obrigado. Eu vou dar uma olhada. Provavelmente são cactos gerando a carga, e vou ver se existe uma maneira de mover os rrds para tmpfs. Ou apenas adicione mais RAM para que o servidor possa armazenar em buffer os rrds. Temo que se eu correr cactos cada 5 minutos poderia haver picos de carga que duram apenas 1 ou 2 minutos, que eu iria perder completamente ...
Josh

6

A menos que os cactos gerem a maior parte da carga, você poderá executar muito mais verificações do que no seu hardware.

Estou executando o nagios em uma máquina virtual FreeBSD em execução no Microsoft Virtual Server em um PC antigo lento (Pentium 3 1GHz com um disco PATA lento). A máquina virtual possui apenas 128 MB de RAM e o desempenho é péssimo.

No entanto, a média de carga é de cerca de 0,2, executando 158 verificações em 42 hosts.


Obrigado. Eu gostaria de poder aceitar as duas respostas! Você foi muito útil, indica para mim que os cactos são provavelmente os culpados.
28410 Josh

2

Em um PIII antigo com 256 MB de RAM, monitorei ativamente cerca de 230 serviços diferentes. A mesma máquina também está executando o MRTG e o HylaFAX para todos os nossos faxes recebidos e está fazendo isso com bastante facilidade.


Informação muito útil. Isso indica para mim que os cactos provavelmente são os culpados, não os nagios. Obrigado!
Josh

1

Você deve poder executar uma carga de verificações do nagios com esse hardware. Executamos uma configuração semelhante com cerca de 70 verificações e Nagiosgraph - a principal diferença é a RAM adicionada (é barato, então eu aumentaria a caixa para 2Gb).

Tente rodar top ou ps -aux para ver se a CPU está sobrecarregada, mas duvido. Você também pode verificar os documentos de paralelização do nagios para ver se sua instalação está tentando executar muitas verificações ao mesmo tempo, em vez de serializá-las.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.