Oi Muito curioso.
Parece que até a quantidade de serviços que voce tem parce com a minha... Esa latência que voce observa e sempre assim ? Eu já observei que os tempos que obtenho pioram bastante quando tem muitos alarmes ao mesmo tempo. Por exemplo, quando cai um link WAN até uma filial e alarma tudo daquela filial em específico... Voce tem alguma situação parecida ? E o Linux ? Como vai ? no Top, qual é a indicação de performance que voce vê, com relação à quantidade de processos na fila ? Em 09/08/07, Rejaine Monteiro <[EMAIL PROTECTED]> escreveu: > > > Ola Jose Oliveira, > > Pois é.. > Eu também estou trabalhando com os mesmos valores que você e veja o que > diz o meu Performance_Info: > > Check Execution Time: < 1 sec 9 sec 0.469 sec > Check Latency:1111 sec 1629 sec 1389.919 sec > Percent State Change: 0.00% 0.00 %0.00% > > Active Checks: > <= 1 minute: 0 (0.0%) > <= 5 minutes: 57 (8.8%) > <= 15 minutes: 231 (35.5%) > <= 1 hour: 595 (91.4%) > Since program start: 635 (97.5%) > > Passive Checks: > <= 1 minute: 0 (0.0%) > <= 5 minutes: 0 (0.0%) > <= 15 minutes: 0 (0.0%) > <= 1 hour: 10 (7.1%) > Since program start: 14 (9.9%) > Percent State Change: 0.00% 0.00% 0.00% > > > Já reavaliei todos as checagens, aumentei o tempo de checagem em alguns > processos menos importantes , etc.. > Sendo que o intervalo da grande maioria é de 5 minutos (com > retry_check_interval=1, e max_check_attempts variando muito dependendo > do tipo de serviço) > Talvez eu faça o contrario, ou seja, aumente o retry_check_interval e > vou redimensionando o max_check_attempts, para ver o que vai dar (mas > imagino que no fundo deve dar a mesma coisa) > > > > Jose Oliveira escreveu: > > Olá Rejaine > > > > Eu ainda rodo a versão 1.0... > > > > Eu tive este problema no passado e tentei bastante coisa. O problema, > que > > deduzimos, é derivado da teoria das filas. Se um processo começa a > demorar e > > o concurrent_checks está ativado, voce sempre tem uma chance do seu > delay > > ficar muuuuuuuito grande. > > > > Eu coloquei o max_concurrent_checks=0. O inter_check_delay_method e o > > service_interleave_factor estão = s. > > > > Monitorei muito a performance da máquina, principalmente na quantidade > de > > processos em execução. > > O nosso servidor nem é muito bom e dá conta direitinho. > > > > Temos um Pentium III 800 com 512Mb de RAM e discos SCSI de 7.200 RPM. > > > > Temos 205 hosts, 645 checks ativos e 72 passivos. A maioria dos ativos > > possui tempo herdado do template de 120 segundos. > > > > > > > > > > Em 08/08/07, Rejaine Monteiro <[EMAIL PROTECTED]> escreveu: > > > >> Ola lista, > >> > >> De algum tempo para cá, provavelmente devido ao aumento no número de > >> hosts e serviços a serem checados, notei que meu Nagios está começando > a > >> ter problemas de performance. Vários serviços estão ficando na fila > >> (scheduling queue) durante muito tempo, ultrapassando o horário > previsto > >> da próxima checagem. > >> > >> Li algumas informações sobre "performance tunning" na documentação > >> oficial, porém ainda não encontrei valores de configurações que me > >> atendam, por isso venho a vocês para quem saber resolver o meu > problema. > >> > >> Estou usando o nagios-1.1 - eu sei, está bem desatualizado... mas > vou > >> providenciar atualização breve ;o) > >> A maquina que roda o nagios fica praticamente exclusiva para esse fim e > >> não apresenta problema de sobrecarga de cpu , nem comprometimento de > >> performance de disco e afins.. > >> > >> Seguem algumas informações sobre a performance atual: > >> > >> Program-Wide Performance Information > >> Active Checks: > >> > >> Time Frame Checks Completed > >> <= 1 minute: 12 (1.8%) > >> <= 5 minutes: 78 (11.9%) > >> <= 15 minutes: 258 (39.2%) > >> <= 1 hour: 281 (42.7%) > >> Since program start: 281 (42.7%) > >> > >> Metric Min. Max. Average > >> Check Execution Time: < 1 sec 11 sec 0.198 sec > >> Check Latency: < 1 sec 616 sec 138.872 sec > >> Percent State Change: 0.00% 0.00% 0.00% > >> Passive Checks: > >> > >> Time Frame Checks Completed > >> <= 1 minute: 0 (0.0%) > >> <= 5 minutes: 0 (0.0%) > >> <= 15 minutes: 0 (0.0%) > >> <= 1 hour: 0 (0.0%) > >> Since program start: 0 (0.0%) > >> > >> Metric Min. Max. Average > >> Percent State Change: 0.00% 0.00% 0.00% > >> > >> > >> O nagios -s /etc/nagios/nagios.cfg me retornou os seguintes valores: > >> > >> > >> SERVICE SCHEDULING INFORMATION > >> ------------------------------- > >> Total services: 793 > >> Total hosts: 68 > >> > >> Command check interval: -1 sec > >> Check reaper interval: 5 sec > >> > >> Inter-check delay method: SMART > >> Average check interval: 715.309 sec > >> Inter-check delay: 0.902 sec > >> > >> Interleave factor method: SMART > >> Average services per host: 11.662 > >> Service interleave factor: 12 > >> > >> Initial service check scheduling info: > >> -------------------------------------- > >> First scheduled check: 1186596717 -> Wed Aug 8 15:11:57 > 2007 > >> Last scheduled check: 1186597441 -> Wed Aug 8 15:24:01 > 2007 > >> > >> Rough guidelines for max_concurrent_checks value: > >> ------------------------------------------------- > >> Absolute minimum value: 6 > >> Recommend value: 18 > >> > >> > >> Meu nagios.cfg atualmente tem os seguinte valores (estou enviado > somente > >> os valores relevantes) : > >> > >> service_reaper_frequency=5 > >> max_concurrent_checks=6 > >> command_check_interval=-1 > >> > >> Ja tentei aumentar o service_reaper_frequency para 10, 15 e 25.. Só > >> piorou a situação.. > >> Já tentei aumentar o max_concurrent_checks para 18 (como recomendado > >> acima), mantendo service_reaper_frequency=5, mas tambem não surtiu > >> efeito... > >> > >> E de resto a maioria das opções é a default .. > >> > >> Alguma dica?? > >> > >> > ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Splunk Inc. > >> Still grepping through log files to find problems? Stop. > >> Now Search log events and configuration files using AJAX and a browser. > >> Download your FREE copy of Splunk now >> http://get.splunk.com/ > >> -- > >> [email protected] mailing list > >> https://lists.sourceforge.net/lists/listinfo/nagios-users-br > >> Wiki: http://nagios-br.sf.net/wiki > >> > >> > > > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > -- > [email protected] mailing list > https://lists.sourceforge.net/lists/listinfo/nagios-users-br > Wiki: http://nagios-br.sf.net/wiki > -- Abraços JGeraldo ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- [email protected] mailing list https://lists.sourceforge.net/lists/listinfo/nagios-users-br Wiki: http://nagios-br.sf.net/wiki
