-
Problema con las alertas en la v.5.0
Hola, buenas tardes,
Recientemente he configurado un nuevo servidor de Pandora FMS con la versión 5.0. Dado que yo tenía la versión 3.2.1, prefería partir de cero y añadir los agentes manualmente para no tener sorpresas. Todo ha ido muy bien y ya tengo los agentes en el nuevo Pandora FMS, el problema es que al configurar las alertas como las tenía antes, no están funcionando como yo deseo.
En la versión 3.2.1 tenía configurado en la plantilla de Host Alive, que se dispare cuando el módulo se encuentre en estado crítico, con un determinado horario y que se envíe una sola alerta. La alerta se enviaría en el momento de pérdida de contacto con el módulo, y no volvería a saltar hasta que pasase 1 mes si no se volvía a tener contacto con el módulo.
Esto mismo lo tengo configurado en el nuevo servidor de Pandora, pero a pesar que indico que el periodo de tiempo es 1 mes, recibo alertas de módulos “caídos” constantemente.
¿Ha habido algún cambio en el funcionamiento de las alertas en esta nueva versión o han de configurarse de algún otro modo? Por lo que he podido ver es casi igual a la versión 3.2.1…
Gracias de antemano.
Un cordial saludo,
David. -
22 Replies
-
-
Hola Mario,
Gracias por la ayuda. Te dejo las capturas de todo el proceso (configuración del agente, configuración del módulo y la configuración de la alerta del módulo). Si necesitas algo más, quedo a tu disposición.
Un cordial saludo!
David.Configuración de la alerta, fase 1 de la plantilla:
Configuración de la alerta, fase 2 de la plantilla:
Configuración de la alerta, fase 3 de la plantilla:
Configuración del agente:
Configuración del módulo Host Alive:
-
Pues revisando la configuración todo parece correcto.
Lo único que se me ocurre es que lo que le esté sucediendo es que al tener el intervalo cada 10 segundos, se recupere la alerta en algún momento y el contador vuelva a estar a 0. Recuerda que el contador que lleva el time threshold se vuelve a poner a 0 cuando se recupera la alerta. Si ves que siempre aparece el valor del módulo a 0, entonces no es eso claro…
-
Hola Mario,
Gracias por la información, pero no creo que suceda eso ya que el dispositivo monitorizado siempre esta caído puesto que tengo el dispositivo sin conectar a la red… ¿Puede ser un bug en la versión de Pandora 5? ¿sabéis de algún otro caso en el que pase lo mismo? Me sería de gran ayuda saber si creando el mismo entorno en otro sistema, sucede lo mismo. ¿Sería alguien tan amable de simular el caso en su entorno?
Gracias, un saludo.
David. -
-
En la 5.0 hay un nuevo umbral general de alerta que te puede ayudar con este problema, esta en la configuracion de la accion. Prueba a poner ahi 3600. Eso deberia hacer que esa accion no se disparara más de una vez cada hora.
Otra cosa a verificar es que los datos de origen de la alerta y el sistema esten sincronizados. Si el dato origen de la alerta se dispara “una hora con retraso” por asi decir, respecto al tiempo del sistema, esto lo puede volver impredecible.
Por otro lado me falta un detalle en la configuracion de las alertas, el minimo para disparar la alerta pone que es 0, y el maximo no lo veo, deberia ser 1.
Prueba a jugar con todo lo que he dicho y me cuentas que tal.
-
Hola Sancho,
Gracias por la ayuda y disculpa la demora de mi respuesta. Sí, el número de alertas máximas es 1 y he configurado el tiempo en la acción (2592000 segundos – 1 mes) con igual resultado. Sigue sin funcionar. He revisado también las horas y coinciden.
¿Es esto un bug? Ya no se que puede ser, estoy revisando la configuración del servidor antiguo que funcionaba correctamente (versión 3.2.1) y todo coincide… Para colmo me llevaría mucho tiempo volver a migrar los agentes a dicho servidor, aparte que quería utilizar este nuevo Pandora, pero me está ocasionando muchos problemas en mi puesto de trabajo.
Si a alguien se le ocurre algo, le sucede lo mismo o simula el entorno y da con la solución ruego me avise! Estaría enormemente agradecido!
Gracias, un saludo.
David. -
Por indagar un poco mas:
a) Puedes ponernos por aqui la lista de datos de ese modulo (deberia haber un “0” cada 24hr mas o menos).
b) Puedes ponernos por aqui los eventos generados por ese modulo ?, y alguna captura con los “detalles” de uno de esos eventos (los validados y los sin validar, ojo con eso). -
Hola de nuevo Sancho,
Después del anterior post, he estado mirando justo esto que me indicas y me ha resultado extraño puesto que sólo tengo 1 evento en el agente y me indica que se originó hace 23 minutos, cuando lleva ya más de dos semanas caido. También he visto que muchos agentes me aparecen en estado desconocido de vez en cuando. Tengo configurado que se realice un “ping” cada 10 segundos con un flip-flop de 10.
Esto lo tenía así configurado en la anterior versión de Pandora y no tuve problemas nunca. Los módulos no pasaban a estado desconocido a no ser que fuese información enviada por el agente instalado y cuyo proceso se hubiese detenido. No obstante, vuelven solos al estado de “normalidad” a los pocos segundos o minutos.
Si esto sucede con los agentes que están caidos, al cambiar el estado a desconocido, ¿generan una nueva alarma al volver al estado crítico verdad?
Ahora el problema viene en detectar por que me cambian de estado los agentes durante un breve periodo de tiempo.
Tengo 146 agentes con 537 modulos configurados (por ahora) y me faltarían añadir unos 20 más. Acabo de ejecutar el script de pandora_db (aunque lo tengo en el cron.daily) y sigue sucediendo lo mismo.
La configuración más relevante del servidor es la siguiente:
network_timeout 5
server_keepalive 45
server_threshold 5
network_threads 20
icmp_checks 1
tcp_checks 1
tcp_timeout 30
snmp_checks 1
snmp_timeout 5
snmp_proc_deadresponse 1
plugin_threads 2
plugin_timeout 15
wmi_timeout 10
wmi_threads 2
recon_threads 1
dataserver_threads 15
max_log_size 65536
max_queue_files 2500Por si sirve de algo. Gracias por todo, parece que ya vamos acercándonos al problema.
Un saludo.
David. -
Efectivamente, este es el problema.
En la 5.0 el estado “desconocido” se gestionan como un estado más, a diferencia de versiones anteirores que era una especie de “estado de no-estoy-en-otro-estado”. Como consecuencia de ello generan eventos, alertas, y en tu caso, debido a esa combinacion de factores, ocurre eso.
Puedes irte a la configuracion de los modulos y desactivar la casilla de “Generar eventos desconocidos”, aunque yo te recomendaría que revisaras los umbrales de polling para evitar entrar en estados desconocidos (incrementarlo a 30 seg).
Para optimizar el server, te recomiendaria algunos cambios:
network_timeout 4
snmp_timeout 3
dataserver_threads 2
network_threads 15
server_threshold 3A no ser que tengas un tremendo maquinon, al meter mas threads empeoras el rendimiento. Con esos cambios no te deberia reportar mas unknown.
Piensa que la version enterprise de pandora, con un solo server puede gestionar unos 80,000 modulos SNMP/ICMP, eso es una tasa de algo más de 250modulos/sec. La version Open está algo mas limitada, pero supera sin dificultad los 50modulos/sec (solo de red, los procesados por el data server dependen de otros factores).
Suerte y a ver si empezamos bien el año 🙂
-
Hola Sancho,
Acabo de realizar los cambios que me has indicado, a ver si conseguimos que se solucione! muchísimas gracias y te mantengo informado de los resultados. Lo haré el Jueves seguramente ya que hoy quiero dar cierto margen a la recogida de datos y los próximos dos días no estaré en el trabajo.
Os deseo a ti y al equipo de administradores, moderadores y demás usuarios que ayudan con sus conocimientos y experiencia al foro una muy feliz entrada de año y que lo mejor de este año sea lo peor del próximo! Enhorabuena y gracias por vuestra dedicación.
Un cordial saludo.
David. -
Hola, buenos días,
He dejado el sistema de monitorización estos días con la configuración que me recomendaste y sigue sucediendo lo mismo. A pesar de que cambié los parámetros de configuración del servidor por lo que me indicaste y que desactive el envío de eventos desconocidos en los agentes, Pandora me reporta los agentes caídos cada pocos minutos y además me envía la alerta correspondiente ya que interpreta que se cae el mismo agente cada minuto.
Me están llegando cientos de correos del mismo agente. Tengo las alertas configuradas como muestro en las imágenes e incluso configuré en la acción de la alerta, un umbral de 1 mes (en segundos). No sé qué mas quedaría por probar, pero debería ser capaz de “recordar” que el agente está caído. ¿Podría ser un problema en la configuración de los eventos?
No se si ha variado esto respecto a la versión 3.2.1, pero comparando la configuración de ambos servidores, no he visto que varíe nada exceptuando las nuevas opciones y los parámetros que me aconsejaste cambiar.
Saludos.
-
Tras días probando y modificando parámetros de configuración en las alertas y en el propio servidor no he conseguido resolver el envío de alertas masivo. Esta misma noche me han llegado 120 correos de un mismo agente cuyo módulo Host Alive llevaba caído desde ayer por la mañana sin posibilidad de recuperación. No entiendo por qué sucede esto si por lo que me comentabais y basándome en las capturas que os envié, está todo bien configurado.
Yo ya desisto… quería subir de versión para mejorar nuestro centro de monitorización y solo he conseguido estropearlo…
-
El problema que esta sucediendo parece ser por culpa de los estados Unknown, y da igual el umbral que tengas que como comentaba Sancho coge el estado y parece que recupera la alerta…
Habría que centrarse en disminuir el lag del servidor de red para evitar estos estados Unknown. Aumentaría el intervalo de estos módulos para que disminuya el número de chequeos y una vez que este estable el servidor de red, este problema se debería solucionar.
Un saludo
-
Hola, buenos días,
Sí, parece que es un problema de los estados UNKNOWN del servidor, pero aún así no se como solucionarlo… Si lanzo ping desde el servidor a distintas IP públicas monitorizadas, o locales o a través de túneles IPSec, no pierdo paquetes y es constante, no obstante tengo muchísimos agentes en estado desconocido y el retraso del servidor de datos va en aumento.
Entiendo que los módulos podrían estar en estado desconocido si no recibo datos de los agentes instalados en las máquinas monitorizadas después de haber superado el intervalo especificado, pero lo que sigo sin entender es por qué los módulos de red (Host Alive, Host Latency, Check Port, etc…) cambian a estado desconocido.
He cambiado el modo de verbosity a 10 y veo nada extraño salvo que cuando procesa los módulos de red, no me indica el nombre del agente, sino que me dice: “Processing module ‘Host Alive’ for agent ID XXX” Donde las X son números. No se si tendrá algo que ver…
La configuración del servidor es la que me indicasteis en este mismo thread. Por otro lado, he comprobado los recursos de la máquina y sobra de todo…
Tiene 4 cores y está usando un 5%, 4 GB de ram y usa sólo 1 y 50 GB de disco y usa 4.3 por lo que tampoco creo que sean recursos…
¿Alguna idea?
Muchas gracias por vuestro tiempo y dedicación.
Un saludo.
Editado: Parece que el servidor de datos ha vuelto a la normalidad, pero el servidor de red es el que varía. En ocasiones presenta un retraso de 7 segundos o más, lo cual no es normal y seguramente cause que los módulos cambien su estado a desconocido. Sin embargo la red va bien siempre puesto que el ping se mantiene constante…
He aumentado el número de network_threads de 15 a 20 para ver si hay alguna mejoría, pero parece que no la hay…
-
Pues en principio según se muestra en la imagen, el que de verdad tiene retraso es el data server, el de red no tiene excesivo retraso, bien es verdad que tiene 39 módulos encolados pero no debería ser crítico.
Si tienes el sistema bien de recursos, una opción es subirle el número de hilos al network_server. A ver si empiezan a funcionar mejor estos módulos.
El retraso de 44 minutos del data server, seguramente se deba a algún agente que tengas que ha dejado de reportar, no parece que tengas encolamiento de XML en el directorio /var/spool/pandora/data_inUn saludo
-
Hola Mario,
El retraso del data server se debe a los reinicios que he efectuado sobre el servicio pandora_server para que adopte los cambios en la configuración. Si te fijas en la última imagen que he posteado el retraso era de 1 minuto, pero ahora no hay ningún tipo de retraso. El que me preocupa es el network server ya que siempre tiene unos 40 módulos en cola y ni aumentando el número de hilos se reduce significativamente la cola.
Como he indicado antes, aumente el número de network threads a 20 (lo tenía en 15) pero al ver que no hubo mejoría, lo dejé como estaba. Me pides que añada hilos al network server, supongo que te refieres a aumentar los network threads, ¿no?
Gracias por la ayuda.
Te dejo otra captura del estado actual de los servidores:
-
-
Hola Mario, buenos días,
Esta es la configuración del servidor:
incomingdir /var/spool/pandora/data_in
log_file /var/log/pandora/pandora_server.log
snmp_logfile /var/log/pandora/pandora_snmptrap.log
errorlog_file /var/log/pandora/pandora_server.error
dbengine mysql[Omito los datos de la base de datos]
verbosity 1
master 1
snmpconsole 1
snmp_ignore_authfailure 1
snmp_pdu_address 0
networkserver 1
dataserver 1
reconserver 1
pluginserver 1
plugin_exec /usr/bin/timeout
predictionserver 0
wmiserver 1
network_timeout 4
server_keepalive 45
server_threshold 3
network_threads 30 [Este valor lo tenía en 15, lo incrementé a 20 y ayer lo dejé en 30 para observar el rendimiento de Pandora]
icmp_checks 1
tcp_checks 1
tcp_timeout 30
snmp_checks 1
snmp_timeout 3
snmp_proc_deadresponse 1
plugin_threads 2
plugin_timeout 15
wmi_timeout 10
wmi_threads 2
recon_threads 1
dataserver_threads 15
xprobe2 /usr/bin/xprobe2
nmap /usr/bin/nmap
snmpget /usr/bin/snmpget
autocreate_group 2
autocreate 1
max_log_size 65536
max_queue_files 2500
activate_gis 1
self_monitoring 1
openstreetmaps_description 1
eventserver 0
dataserver_lifo 0
event_auto_validation 1
event_expiry_time 0Muchas gracias de nuevo por la ayuda!
Un saludo.
-
Buenas
Pienso que son excesivos los hilos del network_server. Probaría con reducir los hilos a 10 y eliminar todos los servidores que no estes utilizando:
reconserver 0
pluginserver 0
wmiserver 0Así podemos usar todos los “hilos” que estos servidores tienen configurados para otro.
Es posible tambien que el cuello de botella no este en el servidor, y se produzca en la base de datos. En nuestra wiki tenemos un apartado de optimización de la base de datos en la que puedes observar algunos cambios para que la base de datos vaya de forma más fluida. Chequealo a ver si conseguimos mejorar el rendimiento del sistema.
Un saludo
