Eu tenho uma configuração de Icinga distribuída configurada da seguinte forma:
CENTRAL
Receives passive check results only
DISTRIBUTED A
227 hosts
835 services
DISTRIBUTED B
67 hosts
243 services
O servidor CENTRAL fica abaixo da latência média de verificação de 1 segundo em todos os momentos. DISTRIBUÍDO B atualmente está em torno de ~ 10 segundos na latência de verificação média, mas mesmo isso está aumentando à medida que adicionamos mais verificações.
DISTRIBUÍDO A tem alguns problemas sérios de latência de verificação (até 700 segundos, às vezes, menos após um recarregamento, mas ele volta a ser feito) que não consigo definir. Aqui está uma saída atual do icingastats:
Icinga Stats 1.10.3
Copyright (c) 2009 Nagios Core Development Team and Community Contributors
Copyright (c) 1999-2009 Ethan Galstad
Last Modified: 02-11-2014
License: GPL
CURRENT STATUS DATA
------------------------------------------------------
Status File: /var/lib/icinga/status.dat
Status File Age: 0d 0h 0m 3s
Status File Version: 1.10.3
Program Running Time: 1d 17h 30m 44s
Icinga PID: 1160
Used/High/Total Command Buffers: 0 / 11 / 4096
Total Services: 839
Services Checked: 839
Services Scheduled: 839
Services Actively Checked: 839
Services Passively Checked: 0
Total Service State Change: 0.000 / 6.250 / 0.007 %
Active Service Latency: 644.742 / 776.293 / 729.813 sec
Active Service Execution Time: 0.010 / 20.163 / 0.720 sec
Active Service State Change: 0.000 / 6.250 / 0.007 %
Active Services Last 1/5/15/60 min: 18 / 274 / 717 / 839
Passive Service Latency: 0.000 / 0.000 / 0.000 sec
Passive Service State Change: 0.000 / 0.000 / 0.000 %
Passive Services Last 1/5/15/60 min: 0 / 0 / 0 / 0
Services Ok/Warn/Unk/Crit: 835 / 2 / 1 / 1
Services Flapping: 0
Services In Downtime: 0
Total Hosts: 227
Hosts Checked: 227
Hosts Scheduled: 227
Hosts Actively Checked: 227
Host Passively Checked: 0
Total Host State Change: 0.000 / 0.000 / 0.000 %
Active Host Latency: 0.000 / 772.310 / 726.904 sec
Active Host Execution Time: 0.006 / 0.338 / 0.030 sec
Active Host State Change: 0.000 / 0.000 / 0.000 %
Active Hosts Last 1/5/15/60 min: 14 / 22 / 196 / 227
Passive Host Latency: 0.000 / 0.000 / 0.000 sec
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 227 / 0 / 0
Hosts Flapping: 0
Hosts In Downtime: 0
Active Host Checks Last 1/5/15 min: 14 / 28 / 192
Scheduled: 14 / 26 / 188
On-demand: 0 / 2 / 4
Parallel: 14 / 27 / 190
Serial: 0 / 0 / 0
Cached: 0 / 1 / 2
Passive Host Checks Last 1/5/15 min: 0 / 0 / 0
Active Service Checks Last 1/5/15 min: 31 / 276 / 702
Scheduled: 31 / 276 / 702
On-demand: 0 / 0 / 0
Cached: 0 / 0 / 0
Passive Service Checks Last 1/5/15 min: 0 / 0 / 0
External Commands Last 1/5/15 min: 0 / 0 / 0
Isso não parece ser um problema de buffer de verificação externa, pois é sempre 0. Eu toquei com as configurações do reaper e tentei combinações variadas de tempo de verificação do reaper max (5,10,30) e frequência do reaper (1 , 5,10) e nada parece diminuir o tempo.
Verificando status.dat, não é como se algumas verificações estivessem elevando a média. Todas as verificações de serviço e cheques de host estão mostrando uma latência em torno da média (mais de 700 segundos). Verifique os tempos de execução na placa são baixos. A grande maioria é de > 1 segundo. De lá, existem 143 cheques que levam mais de 1 segundo, mas menos de 2 segundos. Existem 50 verificações que demoram mais de 4 segundos. 4 cheques estão acima deste ponto, levando 8, 10, 17 e 20 segundos, respectivamente. Esses números não parecem indicar um problema de tempo de verificação real para mim.
O servidor em si não está lutando contra recursos, tanto a CPU quanto a memória estão bem. Também vale a pena notar que os servidores CENTRAL e DISTRIBUTED A estão na mesma infraestrutura física, embora diferentes VMs.