Nagios carrega pico a cada 7 horas

Question

Eu tenho um servidor NagiosXi monitorando 631 serviços em 63 hosts. A cada sete horas, a carga no servidor aumenta para 20 e, em seguida, cai gradualmente para quase 0.

Não há tarefas do cron executando a cada 7 horas.

O servidor tem 8 núcleos e 2 GB de RAM. A RAM não é um problema, ela ainda fica 1GB livre durante os picos, e aumentar para 4GB não faz diferença. O servidor também foi migrado para um novo host uma semana atrás, sem alterações.

Também temos um tempo de inatividade programado em 17 dos hosts sendo monitorados para que eles sejam monitorados apenas entre 6h e 18h de segunda a sexta, o que parece não fazer diferença para os picos de carga.

A maioria das verificações é feita em servidores Windows, usando check_wmi_plus.

Durante picos de carga, eu costumo ver 5-8 instâncias de check_wmi_plus.pl usando 2-3% cpu, e um punhado de processos httpd usando o mesmo, mas nada se destaca como usar um monte de cpu. Esses processos também passam muito rápido, para que não fiquem suspensos ou tenham um longo período incomum de tempo. O tempo de execução de verificação de serviço no NagiosXi Performance Monitor tende a atingir um pico de ~ 5,5s com uma média de 1s.

Alguém pode sugerir uma possível causa, ou como posso resolver isso ainda mais?

    

Answer 1

Uma carga alta NÃO significa necessariamente que você esteja utilizando somente altos níveis de CPU; ela apenas fornece o número de processos em um instantâneo que está pronto para ser executado e recebe tempo de CPU, mas não quanto dele.

O Nagios desdobra muitos processos rapidamente, dependendo de como você configurou seus cronogramas de monitoramento e, às vezes, causará um pico, já que ele inicia muitos processos em execução o mais rápido possível, mas eles podem não exigir muita CPU ou ir imediatamente para um estado de espera / espera.

BTW, se você desativar NOTIFICATIONS no Nagios, isso não impede que ele continue monitorando um determinado host ou serviço.

    

Answer 2

Reduza as configurações prefork do padrão rhel / centos no padrão /etc/httpd/conf/httpd.conf para algo mais realista.

Use ferramentas como apachebuddy.pl & apachetuner.sh para fazer a matemática na memória por bifurcação de processo. permitir mais memória para outro processo no sistema (mysql / postgresql / php) e reduzir o MaxClient e MaxRequestChild.

Eu experimentei isso após a atualização para 2014R1.1 de 2012R2.9. Não tenho certeza se a versão mais recente do XI2014 requer mais recursos para a interface web.

Esta manhã, depois de diminuir minhas configurações, notei que os picos de carga são menores e navegar pela interface não me dá uma tela cinza infeliz usando os botões avançar e voltar no navegador. essa estranheza na interface parece semelhante?

Um último item, estou olhando agora, é o que os módulos rhel neste arquivo httpd.conf padrão são necessários. Não vejo sentido em carregar módulos padrão, se não for necessário. Este servidor é um servidor corporativo PROD no meu local de trabalho com milhares de verificações, portanto, ele precisa ser sólido.

ATUALIZAÇÃO:

executar

\# service mysqld stop
\# sh /usr/local/nagiosxi/scripts/repair_databases.sh 
\# service mysqld start

ou otimizar tabelas enquanto estiver on-line via

\# mysql -u root -p
mysql> use nagios;

liste suas tabelas

mysql> show tables;

então

mysql> optimize table $TABLENAME;
mysql> optimize table $TABLENAME;
mysql> optimize table $TABLENAME;
...
mysql> use nagiosql;

**list your tables**

mysql> show tables;

então

mysql> optimize table $TABLENAME;
mysql> optimize table $TABLENAME;
mysql> optimize table $TABLENAME;
...

faça isso para todas as tabelas.

Se você puder parar o serviço por alguns minutos, faça-o via script nagiosxi. se você não puder até mais tarde ... faça isso online, mas espere que a interface fique um pouco lenta até que as consultas sejam executadas novamente. Talvez também seja benéfico liberar o cache de consultas

mysql> FLUSH QUERY CACHE;

link