-
Monitores no refrescan
Hola a todos:
Felicidades por el programa. Antes de empezar a usarlo hicimos una comparativa entre los más conocidos y Pandora nos resultó como el más adecuado y versátil.
Nuestro problema es que algunos monitores (ej: el ping) no se actualizan.
Tenemos instalada la máquina virtual vmware del Pandora 1.3.1 y tras un par de meses en producción, revisando unas cosas decidimos quitar los servidores “pandora-131_*” (Gestion de Servidores -> Aspa a su derecha) porque habíamos cambiado el nombre a la máquina y aparecían en verde los servidores “MONITOR_*” y en rojo los de pandora.
Al poco de hacer esto, todos los monitores de “ICMP Proc”, “SNMP Proc” y “Alive” (los que hacen consultar a switches, pings…, los que revisan agentes de servidores funcionan bien) dejaron de actualizarse y en la columna Fecha/Hora del enlace “Ver Agentes -> Detalle de monitores” aparecen valores de varios días. En “Ver Agentes -> Vista táctica” aparece el “Monitor Health” a 0.
Desde que vimos el problema hemos probado lo siguiente:
- Reiniciar la máquina y los servicios de Pandora.
- Poner el verbosity a 10 y revisar logs.
- En un agente, pulsar el círculo a la izquierda del “host alive” (aparecen flechas) y pulsarlo otra vez (para volver al círculo).
- Importar la BDD a una nueva máquina virtual.
He reiniciado todos los servicios y me he asegurado que están vivos. Ninguno me ha dado error y el pandora los pone todos en verde.
La única línea de error que he visto es:
MONITOR_Recon [V10] Loop in Recon Module Subsystem
He estado buscando y sólo he encontrado un tema que lo solucionaron bajando el número de threads, pero no es mi caso porque lo tengo todo por defecto de la máquina virtual y son valores bastante bajos.
Aparte de ese error, no aparece nada. Es como si Pandora no supiese que tiene que hacer pings.
Al hacer esto, una vez se ponen las flechas no hay forma de que, pulsando, vuelva a aparecer el círculo. Es como si estuviese bloqueado.
Tras todo lo anterior decidimos montar la máquina virtual de cero. Como no hay un “exportar-importar configuración de agentes”, decidimos mover la configuración mediante un mysqldump.
Sin embargo, tras la grata sorpresa de que todo sigue igual descubrimos que el error también seguía igual, lo que implicaría que el problema viene de algún valor en la base de datos.¿Alguien sabe a qué puede ser debido este error en la actualización de monitores o cómo evitar rehacer toda la configuración a mano en una máquina virtual nueva?
Muchas gracias por vuestra ayuda
Un saludo -
4 Replies
-
Finalmente lo he logrado solucionar a base de modificar la tabla tserver de la base de datos. Tiene pinta de ser un bug:
Según parece, el problema era debido a que al arrancar por primera vez se graban datos refiriéndose a los servidores por el índice incremental “1”, “2”, “3” o “4”. Sin embargo al cambiar el nombre a la máquina se crean nuevos servidores con otros índices y orden que, al eliminar los índices anteriores no se actualizan en las tablas y genera el error.
Subo el script sql para retocar la tabla tserver y que ha logrado que todo vuelva a funcionar.
Gracias y un saludo
-
-
Creo que el problema tenia una facil solucion. Al borrar el servidor que tenias asignado al agente y crear una nuevo, ese agente tiene asignado un servidor que ya no está en uso. Al forzar el refresco sobre un servidor que ya no existe, se queda esperando a ese servidor.
Es una circustancia que no se nos habia ocurrido, le daremos una pensada a ver como lo podemos solucionar, pero es algo que no deberia ocurrir frecuentemente.
Lo correcto hubiera sido borrar el servidor, crear el nuevo (arrancando este), y cambiar del agente el servidor de red asignado. En cualquier caso vamos a darle una vuelta a esto que has comentado.
Gracias por la informacion.
-
El caso se dió al cambiar el nombre de la máquina a “monitor”. Los servidores se crean automáticamente con el nuevo hostname, pero no se pueden borrar los antíguos pese a aparecer como deshabilitados.
Otra cosa que he visto en la máquina vmware de Pandora es que, pese a tener un script en el cron para ejecutar el pandora_db, éste está mal escrito y falla al ejecutarlo. Se soluciona poniendo “#!/bin/sh” en la primera línea de /etc/cron.daily/pandora_purge_db.
Me alegro de haber servido de ayuda 🙂
