NSCA pasivo obsoleto -> ¿múltiples procesos nrpe colgantes?

NSCA pasivo obsoleto -> ¿múltiples procesos nrpe colgantes?
  • encogido 2.0.3
  • nrp 2.15

Estamos usandonscapara realizar controles pasivos.

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
}

Aunque freshness_thresholdson 10 minutos, hay un caso en el que las comprobaciones pasivas están obsoletas:

6 de octubre 09:52:36 x shinken: [martes 6 de octubre 09:52:35 2015] Advertencia: los resultados del servicio 'syncthing_procs-2' en el host 'x' están obsoletos en 0d 0h 10m 16s (umbral = 16714d 9h 42m 35). Estoy obligando a una verificación inmediata del servicio.

Oh, ¿ threshold=16714d 9h 42m 35sde dónde viene mientras lo configuro en 10 minutos en el archivo de configuración? Claro, la hora del sistema en la máquina virtual Shinken y el host 'x' es la misma.

Hay muchos servicios así de obsoletos. Como puede ver, después de que una verificación pasiva queda obsoleta, utilizamos check_nrpepara realizar una verificación activa. Y el problema es que ahora tenemos tantos procesos nrpe que parecen colgarse:

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

Solo pego algunos. En realidad, hay > 200 procesos.

Entonces, además del umbral incorrecto, también tengo otra pregunta: ¿por qué hay tantos procesos nrpe después de eso? Sé que se bifurcará un nuevo proceso al realizar una verificación activa. Pero debería desaparecer una vez realizada la comprobación, ¿verdad?


Ah, sé la respuesta a la primera pregunta.

Oh, ¿de dónde viene el umbral = 16714d 9h 42m 35s mientras lo configuro en 10 minutos en el archivo de configuración?

Parece que hay una ligera diferencia entre Shinken y Nagios. Es la época de la época en días/horas/minutos/segundos.

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

Respuesta1

No es posible saber qué salió mal exactamente en su caso. Así que he aquí algunas reflexiones:

Estamos utilizando nsca para realizar comprobaciones pasivas. ¿Por qué hay tantos procesos nrpe después de eso? Sé que se bifurcará un nuevo proceso al realizar una verificación activa. Pero debería desaparecer una vez realizada la verificación, ¿verdad?

Parece que nsca no funciona correctamente, entonces se realizaron comprobaciones activas. Asegúrese de que nsca funcione.

Aunque el umbral de frescura es de 10 minutos, hay un caso en el que las comprobaciones pasivas están obsoletas.

o nsca no está configurado para enviar resultados pasivos a shinken

Sé que se bifurcará un nuevo proceso al realizar una verificación activa. Pero debería desaparecer una vez realizada la verificación, ¿verdad?

Quizás las comprobaciones no se han realizado y las conexiones se mantienen en el otro lado (shinken)

información relacionada