☰

NSCA passivo obsoleto -> vários processos nrpe suspensos?

tag-icon • tag-icon nagios nrpe
NSCA passivo obsoleto -> vários processos nrpe suspensos?
  • Shinken 2.0.3
  • nrpe 2.15

Nós estamos usandonscapara realizar verificações passivas.

define service {
    name salt-service
    register 0

    active_checks_enabled 0
    passive_checks_enabled 1
    check_freshness 1
    freshness_threshold 600
    max_check_attempts 2
    check_interval 5
    retry_interval 3
}

define service {
    use salt-service
    service_description syncthing_procs-2
    host_name x
    check_command check_nrpe!syncthing_procs!10
    display_name Syncthing Procs
}

Embora freshness_thresholddemore 10 minutos, há um caso em que as verificações passivas ficam obsoletas:

6 de outubro 09:52:36 x shinken: [Terça, 6 de outubro 09:52:35 2015] Aviso: os resultados do serviço 'syncthing_procs-2' no host 'x' estão obsoletos em 0d 0h 10m 16s (limite = 16714d 9h 42m 35s). Estou forçando uma verificação imediata do serviço.

Ah, de onde vem threshold=16714d 9h 42m 35senquanto eu configuro para 10 minutos no arquivo de configuração? Claro, a hora do sistema na VM Shinken e no host 'x' é a mesma.

Há muitos serviços obsoletos assim. Como você pode ver, depois que uma verificação passiva fica obsoleta, usamos check_nrpepara realizar uma verificação ativa. E o problema é que agora temos tantos processos nrpe que parecem travados:

nagios   31404     1  0 Sep18 ?        00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
nagios   31727     1  0 Oct01 ?        00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
nagios   31732     1  0 Oct01 ?        00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
nagios   32148     1  0 Sep30 ?        00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
nagios   32157     1  0 Sep30 ?        00:00:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d

Acabei de colar alguns. Na verdade, existem mais de 200 processos.

Então, além do limite errado, também tenho outra pergunta: por que existem tantos processos nrpe depois disso? Eu sei que um novo processo será bifurcado ao realizar uma verificação ativa. Mas deve desaparecer após a verificação, certo?

Ah, eu sei a resposta para a primeira pergunta.

Ah, de onde vem o limite = 16714d 9h 42m 35s enquanto eu o configuro para 10 minutos no arquivo de configuração?

Parece que há uma pequena diferença entre Shinken e Nagios. É o tempo da Época em dias/horas/minutos/segundos.

expr $(date +%s) / 3600 / 24
16714

Responder1

não é possível dizer exatamente o que deu errado no seu caso. Então aqui está um pensamento:

Estamos usando o nsca para realizar verificações passivas. por que existem tantos processos nrpe depois disso? Eu sei que um novo processo será bifurcado ao realizar uma verificação ativa. Mas deve desaparecer depois que a verificação for feita, certo

Parece que o nsca não funciona corretamente, então foram realizadas verificações ativas. Certifique-se de que o nsca funcione.

Embora o frescor_threshold seja de 10 minutos, há um caso em que as verificações passivas estão obsoletas

ou nsca não está configurado para enviar resultado passivo para shinken

Eu sei que um novo processo será bifurcado ao realizar uma verificação ativa. Mas deve desaparecer depois que a verificação for feita, certo

Talvez as verificações não tenham sido feitas e as conexões sejam mantidas do outro lado (shinken)

informação relacionada