Não tenho certeza se você está perguntando sobre limites de configuração ou limites de tempo de execução. Ou ambos.
Se você está perguntando se há um limite no número de objetos (hosts / serviços / comandos / contatos / o que for) que o analisador manipulará, parece que a resposta é "não" (olhando para a fonte para o parser). A menos que você fique sem memória durante a análise.
À medida que você entra em dezenas de milhares de objetos (e mais) em território, o tempo necessário para analisar a configuração pode aumentar drasticamente. Isso é mais um problema com a v3 do que com a v4. Consulte a página de documentos em Opções de inicialização rápida para obter mais informações.
Se você está perguntando sobre limitações de tempo de execução, novamente não há um limite superior pré-configurado ou codificado. A única coisa que realmente importa é o checks / second , e se o seu hardware pode ou não lidar com isso. 10k hosts (ou serviços) com um intervalo de verificação de 5 minutos é o mesmo que 2k hosts / serviços com um intervalo de 1 minuto, a esse respeito.
Assistir (e tender) as latências médias de verificação e os tempos de execução de nagiostats é uma boa maneira de avaliar os problemas de capacidade do Nagios.
Existem alguns ajustes simples que podem fazer grandes diferenças, como ter spool de resultados de verificação em um ramdisk e usar check_icmp em vez de check_ping . Há boas sugestões na página Tuning Nagios para máximo desempenho . (Mas essa página também sugere o uso de discos UltraSCSI em vez do IDE, para dar uma ideia de como ela é atual ...)
O motivo pelo qual você está tendo tanto trabalho para encontrar informações definitivas sobre o dimensionamento do Nagios é que não há duas instalações iguais, e há muitas variáveis para poder dizer "você pode fazer X checks por segundo por núcleo" ou qualquer coisa semelhante.