Ingeniería de Pandora FMS

Volver al Índice de Documentación Pandora FMS

En el siguiente apartado se explicarán algunos de los principios de diseño y particularidades de Pandora FMS.

Las primeras versiones de Pandora FMS, desde la 0.83 hasta la 1.1, estaban basadas en una idea muy sencilla: un dato, una inserción de la base de datos. Esto permitía al software realizar búsquedas fáciles, inserciones y otras operaciones rápidamente.

Aparte de todas las ventajas que suponía este desarrollo, había un inconveniente: la escalabilidad (crecimiento rápido sin afectar o afectar poco las operaciones y rutinas de trabajo). Este sistema tenía un límite definido en máximo número de módulos que pueda soportar, y con cierta cantidad de datos (más de 5 millones de elementos) el rendimiento se veía afectado.

Las soluciones basadas en clúster MySQL, por otro lado, no son fáciles: aunque permiten gestionar una mayor carga, añaden algunos problemas y dificultades extra, y tampoco ofrecen una solución a largo plazo al problema de rendimiento con gran cantidad de datos.

Actualmente, Pandora FMS implementa una compactación de datos en tiempo real para cada inserción, además de realizar una compresión de datos basada en interpolación. Por otro lado, la tarea de mantenimiento permite borrar automáticamente los datos que sobrepasen cierta antigüedad.

El sistema de procesamiento de Pandora FMS almacena solo datos «nuevos»: si entra un valor duplicado en el sistema, no se almacenará en la base de datos. Esto es muy útil para mantener la base de datos reducida, y funciona para todos los tipos de módulo de Pandora FMS (numérico, incremental, booleano y cadena de texto). Por ejemplo, en los datos de tipo booleano el índice de compactación es muy alto ya que son datos que difícilmente cambian. No obstante, se almacenan elementos «índice» cada 24 horas, de forma que exista una información mínima que sirva como referencia a la hora de compactar la información.

Este mecanismo resuelve parte del problema de escalabilidad, reduciendo considerablemente el uso de la base de datos (entre un 40 y un 70 por ciento), pero hay otras maneras de aumentar la escalabilidad.

Pandora FMS permite la disgregación total de componentes, de manera que se puede equilibrar la carga de procesado de ficheros de datos y ejecución de módulos de red en diferentes servidores. Es posible tener varios servidores de Pandora FMS (servidores de red, datos o SNMP), consolas Web de Pandora FMS, así como una base de datos o un clúster de alto rendimiento (con MySQL5), todo ello en servidores independientes.

Las modificaciones comportan grandes cambios a la hora de leer e interpretar los datos. En las últimas versiones de Pandora FMS, se ha rediseñado desde cero el motor gráfico para poder representar los datos rápidamente con el nuevo modelo de almacenamiento de datos.

Los mecanismos de compactación tienen ciertas implicaciones a la hora de leer e interpretar los datos gráficamente. Imagine que un agente no puede comunicarse con Pandora FMS, por lo que el servidor de Pandora FMS no recibe datos del mismo, y habrá un periodo de tiempo en el que el servidor no tenga información de los módulos de dicho agente. Si accede a la gráfica de uno de esos módulos, el intervalo sin datos se representará como si no hubiera cambios; una línea horizontal. Pandora FMS, si no recibe nuevos valores, asumirá que no los hay, y todo aparecerá tal y como estaba en la última notificación.

Para ver un ejemplo gráfico, esta imagen muestra los cambios para cada dato, recibidos cada 180 segundos.

Este sería el gráfico equivalente para el mismo dato, excepto por un fallo de la conexión, de 05:55 a 15:29 aproximadamente.

En Pandora FMS 1.3, se introdujo un nuevo gráfico general para el agente que muestra la conectividad del mismo, y que refleja la tasa de acceso desde los módulos al agente. Este gráfico complementa los otros que mostraban cuando el agente tenía actividad y estaba recibiendo datos.

Si tiene picos (bajos) en este gráfico, podría tener problemas o conexiones lentas en la conectividad del agente de Pandora FMS con el servidor de Pandora FMS, o bien problemas de conectividad desde el servidor de red.

En la versión 5 de Pandora FMS, se introdujo la posibilidad de cruzar los datos de los eventos de tipo “módulo desconocido” con las gráficas, para mostrar en la gráfica el trozo de la serie de datos que está bajo condición de desconocido, complementando la gráfica para una mejor interpretación, por ejemplo:

Ya en la versión 7 NG 759 disponía de un menú de configuración gráfico el cual permite agregar percentiles, datos en tiempo real, cuándo se produjeron eventos y/o alertas, además de otras opciones.

A lo largo de las actualizaciones del software, se han ido implementando mejoras en el modelo relacional de la base de datos de Pandora FMS. Uno de los cambios introducidos ha sido la indexación de información en base a diferentes tipos de módulos. De esta forma, Pandora FMS puede acceder mucho más rápido a la información, ya que esta se reparte en diferentes tablas.

Es posible realizar un particionado de las tablas (por marcas de tiempo) para mejorar aún más el rendimiento del acceso a los históricos de datos.

Además, factores como la representación numérica de las marcas de tiempo (en _timestamp_ formato UNIX), acelera las búsquedas de rangos de fecha, comparaciones de las mismas, etc. Este trabajo ha permitido una mejora considerable en los tiempos de búsqueda y en las inserciones.

A continuación se muestra un diagrama ER y una descripción detallada de las principales tablas de la base de datos de Pandora FMS.

• taddress: Contiene direcciones adicionales de los Agentes.
• taddress_agent: Direcciones asociadas a un Agente (rel. taddress/tagente).
• tagente: Contiene la información de los Agentes de Pandora FMS.
  • id_agente: Identificador único del Agente.
  • nombre: Nombre del Agente (sensible a mayúsculas y minúsculas).
  • direccion: Dirección del Agente. Se pueden asignar direcciones adicionales a través de la tabla taddress.
  • comentarios: Texto libre.
  • id_grupo: Identificador del grupo al que pertenece el Agente (ref. tgrupo).
  • ultimo_contacto: Última fecha de contacto del Agente, ya sea a través de un Agente Software o de un Módulo remoto.
  • modo: Modo en que corre el Agente, 0 normal, 1 aprendizaje.
  • intervalo: Intervalo de ejecución del Agente. En función de este intervalo se marcará el Agente como fuera de límites.
  • id_os: Identificador del S.O. del Agente (ref. tconfig_os).
  • os_version: Versión del S.O. (texto libre).
  • agent_version: Versión del Agente (texto libre). Actualizada por los Agentes software.
  • ultimo_contacto_remoto: Última fecha de contacto recibida del Agente. En el caso de Agentes software y a diferencia de ultimo_contacto, la fecha la envía el propio Agente.
  • disabled: Estado del Agente, habilitado (0) o deshabilitado (1).
  • remote: Agentes con (1) o sin configuración remota (0).
  • id_parent: Identificador del padre del Agente (ref. tagente).
  • custom_id: Identificador personalizado del Agente. Útil para interactuar con otras herramientas.
  • server_name: Nombre del servidor al que está asignado el Agente.
  • cascade_protection: Protección en cascada. Deshabilitada a 0. Estando a 1 impide que se disparen las alertas asociadas al Agente si alguna alerta crítica del padre del Agente se ha disparado. Para más información consultar el capítulo de Alertas.
  • safe_mode_module: ID del Módulo (del mismo Agente) que usa el safe operation mode (todos los otros Módulos del Agente se deshabilitan si este Módulo está en estado crítico).
• tagente_datos: Datos recibidos de cada Módulo. Si para un mismo Módulo el último dato recibido es igual al inmediatamente anterior no se inserta (pero se actualiza tagente_estado). Los datos de tipo incremental y cadena se guardan en tablas diferentes.
• tagente_datos_inc: Datos de tipo incremental.
• tagente_datos_string: Datos de tipo cadena.
• tagente_estado: Información del estado actual de cada Módulo.
  • id_agente_estado: Identificador.
  • id_agente_modulo: Identificador del Módulo (ref. tagente_modulo).
  • datos: Valor del último dato recibido.
  • timestamp: Fecha del último dato recibido (puede venir del Agente).
  • estado: Estado del Módulo: 0 NORMAL, 1 CRITICAL, 2 WARNING, 3 UNKNOWN.
  • id_agente: Identificador del Agente asociado al Módulo (ref. tagente).
  • last_try: Fecha de la última ejecución con éxito del Módulo.
  • utimestamp: Fecha de la última ejecución del Módulo en formato UNIX.
  • current_interval: Intervalo de ejecución del Módulo en segundos.
  • running_by: Nombre del servidor que ejecutó el Módulo.
  • last_execution_try: Fecha del último intento de ejecución del Módulo. La ejecución pudo fallar.
  • status_changes: Número de cambios de estado que se han producido. Se utiliza para evitar cambios continuos de estado. Para saber más, acuda a la sección Operación.
  • last_status: Estado anterior del Módulo.
• tagente_modulo: Configuración de Módulos.
  • id_agente_modulo: Identificador único del Módulo.
  • id_agente: Identificador del Agente asociado al Módulo (ref. tagente).
  • id_tipo_modulo: Tipo de Módulo (ref. ttipo_modulo).
  • descripcion: Texto libre.
  • nombre: Nombre del Módulo.
  • max: Valor máximo del Módulo. Datos mayores que este valor se considerarán inválidos.
  • min: Valor mínimo del Módulo. Datos menores que este valor se considerarán inválidos.
  • module_interval: Intervalo de ejecución del Módulo en segundos.
  • tcp_port: Puerto TCP destino en Módulos de red y plugin. Nombre de la columna a leer en Módulos WMI.
  • tcp_send: Datos a enviar en Módulos de red. Namespace en Módulos WMI.
  • tcp_rcv: Respuesta esperada en Módulos de red.
  • snmp_community: Comunidad SNMP en Módulos de red. Filtro en Módulos WMI.
  • snmp_oid: OID en Módulos de red. Query WQL en Módulos WMI.
  • ip_target: Dirección de destino en Módulos de red, plugin y WMI.
  • id_module_group: Identificador del grupo al que pertenece el Módulo (ref. tmodule_group).
  • flag: Indicador o bandera de ejecución forzada. Estando a 1 se ejecuta el Módulo aunque no le corresponda por intervalo.
  • id_modulo: Identificador para Módulos que no pueden reconocerse por su id_tipo_módulo. 6 para Módulos WMI, 7 para Módulos WEB.
  • disabled: Estado del Módulo, 0 habilitado, 1 deshabilitado.
  • id_export: Identificador del Export Server asociado al Módulo (ref. tserver).
  • plugin_user: Nombre de usuario en Módulos plugin y WMI, user-agent en Módulos Web.
  • plugin_pass: Contraseña en Módulos plugin y WMI, número de reintentos en Módulos Web.
  • plugin_parameter: Parámetros adicionales en Módulos plugin, configuración de la tarea de Goliat en Módulos Web.
  • id_plugin: Identificador del plugin asociado al Módulo en Módulos plugin (ref. tplugin).
  • post_process: Valor por el que se multiplicarán los datos del Módulo antes de ser guardados.
  • prediction_module: 1 si se trata de un Módulo de predicción, 2 si es de servicio, 3 si es sintético, 0 en cualquier otro caso.
  • max_timeout: Tiempo de espera segundos en Módulos plugin.
  • custom_id: Identificador personalizado del Módulo. Útil para interactuar con otras herramientas.
  • history_data: Si está a 0 no se guardan datos del Módulo en tagente_datos*, únicamente se actualiza tagente_estado.
  • min_warning: Valor mínimo que activa el estado WARNING.
  • max_warning: Valor máximo que activa el estado WARNING.
  • min_critical: Valor mínimo que activa el estado CRITICAL.
  • max_critical: Valor máximo que activa el estado CRITICAL.
  • min_ff_event: Número de veces que tiene que darse una condición de cambio de estado antes de que dicho cambio tenga lugar. Está relacionado con tagente_estado.status_changes.
  • delete_pending: Si está a 1 el Módulo será borrado por el guión de mantenimiento de la base de datos pandora_db.pl en la versión Community y pandora_db en la versión Enterprise.
  • custom_integer_1: Cuando predicion_module = 1 este campo tiene el id del Módulo del que se toman los datos para predecir. Cuando prediction_module = 2 este campo tendrá el id del servicio asignado al Módulo.
  • custom_integer_2: Utilizado por el Prediction Server.
  • custom_string_1: Utilizado por el Prediction Server.
  • custom_string_2: Utilizado por el Prediction Server.
  • custom_string_3: Utilizado por el Prediction Server.
• tagent_access: Se inserta una nueva entrada cada vez que llegan datos de un Agente a cualquiera de los servidores, pero nunca más de una por minuto para evitar cargar la base de datos en exceso. Se puede desactivar con poniendo agentaccess a 0 en el fichero de configuración pandora_server.conf.
• talert_snmp: Configuración de alertas SNMP.
• talert_commands: Comandos que se podrán ejecutar desde acciones asociadas a una alerta (ej. enviar correo electrónico).
• talert_actions: Instancia de un comando asociada a una alerta (ej. enviar correo electrónico al administrador).
• talert_templates: Plantillas de alertas.
  • id: Identificador único de la plantilla.
  • name: Nombre de la plantilla.
  • description: Descripción.
  • id_alert_action: Identificador de la acción por defecto asociada a la plantilla.
  • field1: Campo personalizado 1 (texto libre).
  • field2: Campo personalizado 2 (texto libre).
  • field3: Campo personalizado 3 (texto libre).
  • type: Tipo de alerta en función de la condición de disparo ('regex', 'max_min', 'max', 'min', 'equal', 'not_equal', 'warning', 'critical').
  • value: Valor para alertas tipo regex (texto libre).
  • matches_value: A 1 invierte la lógica de la condición de disparo.
  • max_value: Valor máximo para alertas max_min y max.
  • min_value: Valor mínimo para alertas max_min y min.
  • time_threshold: Intervalo de la alerta.
  • max_alerts: Número máximo de veces que se disparará una alerta durante un intervalo.
  • min_alerts: Número mínimo de veces que debe darse la condición de disparo durante un intervalo para que la alerta se dispare.
  • time_from: Tiempo a partir del cual la alerta está activa.
  • time_to: Tiempo hasta el cual la alerta está activa.
  • monday: A 1 la alerta está activa los lunes.
  • tuesday: A 1 la alerta está activa los martes.
  • wednesday: A 1 la alerta está activa los miércoles.
  • thursday: A 1 la alerta está activa los jueves.
  • friday: A 1 la alerta está activa los viernes.
  • saturday: A 1 la alerta está activa los sábados.
  • sunday: A 1 la alerta está activa los domingos.
  • recovery_notify: A 1 habilita la recuperación de alertas.
  • field2_recovery: Campo personalizado 2 para la recuperación de alerta (texto libre).
  • field3_recovery: Campo personalizado 3 para la recuperación de alerta (texto libre).
  • priority: Criticidad de la alerta: 0 Maintenance, 1 Informational, 2 Normal, 3 Warning, 4 Critical.
  • id_group: Identificador del grupo al que pertenece la plantilla (ref. tgrupo).
• talert_template_modules: Instancia de una plantilla de alerta asociada a un Módulo.
  • id: Identificador único de la alerta.
  • id_agent_module: Identificador del Módulo asociado a la alerta (ref. tagente_modulo).
  • id_alert_template: Identificador de la plantilla asociada a la alerta (ref. talert_templates).
  • internal_counter: Número de veces que se ha dado la condición de disparo de la alerta.
  • last_fired: Última vez que se disparó la alerta (tiempo UNIX).
  • last_reference: Comienzo del intervalo actual (tiempo UNIX).
  • times_fired: Número de veces que se disparó la alerta (puede ser distinto a internal_counter).
  • disabled: A 1 la alerta está deshabilitada.
  • priority: Criticidad de la alerta: 0 Maintenance, 1 Informational, 2 Normal, 3 Warning, 4 Critical.
  • force_execution: A 1 se ejecutará la acción de la alerta aunque no haya sido disparada. Se utiliza para la ejecución manual de alertas.
• talert_template_module_actions: Instancia de una acción asociada a una alerta (ref. talert_template_modules).
• talert_compound: Alertas compuestas, las columnas son similares a las de talert_templates.
• talert_compound_elements: Alertas simples asociadas a una alerta compuesta, cada una con su correspondiente operación lógica (ref. talert_template_modules).
• talert_compound_actions: Acciones asociadas a una alerta compuesta (ref. talert_compound).
• tattachment: Adjuntos asociados a una incidencia.
• tconfig: Configuración de la Consola.
• tconfig_os: Sistemas operativos reconocidos en Pandora FMS.
• tevento: Entradas de eventos. Los valores de criticidad son los mismos que para las alertas.
• tgrupo: Grupos definidos en Pandora FMS.
• tincidencia: Entradas de incidencias.
• tlanguage: Idiomas reconocidos en Pandora FMS.
• tlink: Enlaces mostrados en la parte inferior del menú de la consola.
• tnetwork_component: Componentes de red. Son Módulos asociados a un perfil de red utilizada por el Recon Server. Posteriormente darán lugar a una entrada en tagente_modulo, de modo que las columnas de ambas tablas son similares.
• tnetwork_component_group: Grupos para clasificar los componentes de red.
• tnetwork_profile: Perfil de red. Agrupación de componentes de red que se asignarán a tareas de reconocimiento del Recon Server. Los componentes de red asociados al perfil darán lugar a Módulos en los Agentes creados.
• tnetwork_profile_component: Componentes de red asociados a un perfil de red (rel. tnetwork_component/tnetwork_profile).
• tnota: Notas asociadas a una incidencia.
• torigen: Orígenes posibles de una incidencia.
• tperfil: Perfiles de usuarios definidos en la consola.
• trecon_task: Tareas de reconocimiento del Recon Server.
• tserver: Servidores registrados.
• tsesion: Información sobre las acciones llevadas a cabo durante la sesión de un usuario para los logs de administración y estadísticas.
• ttipo_modulo: Tipos de Módulo según su origen y tipo de dato.
• ttrap: Traps SNMP recibidos por la Consola SNMP.
• tusuario: Usuarios registrados en la Consola.
• tusuario_perfil: Perfiles asociados a un usuario (rel. tusuario/tperfil).
• tnews: Noticias mostradas en la Consola.
• tgraph: Gráficas personalizadas creadas en la Consola.
• tgraph_source: Módulos asociados a una gráfica (rel. tgraph/tagente_modulo).
• treport: Informes personalizados creados en la Consola.
• treport_content: Elementos asociados a un informe.
• treport_content_sla_combined: Componentes de un elemento SLA asociado a un informe.
• tlayout: Mapas personalizados creados en la Consola.
• tlayout_data: Elementos asociados a un mapa.
• tplugin: Definiciones de plugins para el Plugin Server.
• tmodule: Tipos de Módulos (Network, Plugin, WMI…).
• tserver_export: Destinos configurados para el Export Server.
• tserver_export_data: Datos a exportar, asociados a un destino.
• tplanned_downtime: Paradas programadas.
• tplanned_downtime_agents: Agentes asociados a una parada programada (rel. tplanned_downtime/tagente).

Según lo comentado anteriormente, para evitar sobrecargar la base de datos, el servidor realiza una sencilla compresión en tiempo de inserción. Un dato no se guarda en la base de datos a menos que sea distinto del anterior o haya una diferencia de más de 24 horas entre ambos.

Por ejemplo, suponiendo un intervalo aproximado de 1 hora, la secuencia 0,1,0,0,0,0,0,0,1,1,0,0 se almacena en la base de datos como 0,1,0,1,0. No se guardará otro 0 consecutivo a menos que hayan pasado 24 horas.

La gráfica que se muestra a continuación se ha dibujado a partir de los datos del ejemplo anterior. Únicamente se han insertado en la base de datos los datos marcados en rojo.

La compresión afecta en gran medida a los algoritmos de procesado de datos, tanto a las métricas como a las gráficas, y es importante tener en cuenta que hay que rellenar los huecos provocados por la compresión.

Teniendo en cuenta todo lo anterior, para realizar cálculos con los datos de un módulo dado un intervalo y una fecha inicial, hay que seguir los siguientes pasos:

• Buscar el dato anterior, fuera del intervalo y fecha dados. Si existiera, hay que traerlo al inicio del intervalo. Si no existiera anteriormente no habría datos.

• Buscar el siguiente dato, fuera del intervalo y fecha dados hasta un máximo igual al intervalo del módulo. Si existiera hay que traerlo al final del intervalo. Si no existiera, habría que prolongar el último valor disponible hasta el final del intervalo.

• Se recorren todos los datos, teniendo en cuenta que un dato es válido hasta que se reciba un dato distinto.

Pandora FMS ha incluido un sistema para compactar la información de la base de datos. Este sistema está orientado a escenarios de tamaño pequeño y mediano ( de 250 a 500 agentes y con menos de 100.000 módulos) que desean tener un histórico de información extenso pero perdiendo detalles.

El mantenimiento de la base de datos de Pandora FMS que se ejecuta cada hora, y entre otras tareas de limpieza permite realizar una compactación de datos antiguos. Esta compactación usa una interpolación simple y lineal, lo que significa que si, por ejemplo se tienen 10.000 datos en un día, el proceso reducirá esos 10.000 puntos a 1000 puntos.

Al ser una interpolación, esto hace que se pierda detalle en esta información, pero seguirá siendo suficientemente informativa para la generación de informes y gráficas mensuales, anuales, etcétera.

En bases de datos de gran tamaño, este comportamiento puede ser bastante costoso en términos de rendimiento y tendría que ser desactivado; en su lugar, se recomienda optar por el modelo de base de datos histórica.

La base de datos histórica es una funcionalidad Enterprise, utilizada para almacenar toda la información pasada, que no se usa en vistas de días recientes, como por ejemplo los datos con una antigüedad de más de un mes. Esos datos se migran, de manera automática, a una base de datos diferente, que debe estar en un servidor distinto con un almacenamiento (disco) diferente al de la base de datos principal.

Cuando se muestre una gráfica o un informe con datos antiguos, Pandora FMS buscará los primeros días en la base de datos principal, y al llegar al punto en el que se migran a la base de datos histórica, pasará a buscar en ella. Gracias a ello el rendimiento se maximiza incluso al acumular un gran cantidad de información en el sistema.

Para configurar esto, hay que instalar manualmente en otro servidor una base de datos histórica (importando el esquema de Pandora FMS en él, sin datos), además de permisos de instalación para permitir el acceso a ella desde el servidor de Pandora FMS principal.

Luego vaya a Setup → Setup → Historical database y configure los parámetros para acceder a la base de datos histórica.

La configuración por defecto de Pandora FMS no transfiere datos tipo cadena de texto string a la base de datos de histórico, no obstante si se ha modificado esta configuración y la base de datos de histórico está recibiendo este tipo de información es imprescindible que se configure su purgado, ya que de otro modo terminará ocupando demasiado, ocasionando grandes problemas y obteniendo un impacto negativo en el rendimiento.

Para configurar este parámetro se deberá ejecutar directamente una consulta en la base de datos para determinar los días tras los cuales se purgará esta información. La tabla en cuestión es tconfig y el campo string_purge. Para establecer 30 días para el purgado de este tipo de información, se ejecutaría la siguiente query directamente sobre la base de datos de histórico:

UPDATE tconfig SET value = 30 WHERE token = "string_purge";

La base de datos es mantenida por un script llamado pandora_db.pl:

Para comprobar que el mantenimiento de la base de datos se ejecuta correctamente corra el script de mantenimiento manualmente:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf

No debería reportar ningún error. Si otra instancia está utilizando la base de datos, bien puede utilizar la opción -f que fuerza la ejecución; con el parámetro -p no realiza un compactado de los datos. Esto es especialmente útil en entornos de Alta disponibilidad (HA) con base de datos histórica, ya que el script se asegura de realizar en un orden y modo correcto los pasos necesarios para dichos componentes.

En Pandora FMS los módulos pueden tener diferentes estados: Desconocido, Normal, Advertencia, Crítico o con Alertas disparadas.

• Por un lado, cada módulo tiene en su configuración unos umbrales de Advertencia (WARNING) y Crítico (CRITICAL).
  • Estos umbrales definen los valores de sus datos para los que se activarán dichos estados.
  • Si el módulo proporciona datos fuera de estos umbrales, se considera que está en estado Normal (NORMAL).

• Cada módulo tiene, además, un intervalo de tiempo que establecerá la frecuencia con la que obtendrá los datos.
  • Ese intervalo será tenido en cuenta por la consola para recoger los datos.
  • Si el módulo lleva el doble de su intervalo sin recoger datos, se considera que ese módulo está en estado Desconocido (UNKNOWN).

• Por último, si el módulo tiene alertas configuradas y alguna de ellas ha sido disparada y no se ha validado, el módulo tendrá el correspondiente estado de Alerta disparada.

Dentro de la organización de Pandora FMS, ciertos elementos dependen de otros, como es el caso de los módulos de un agente o los agentes de un grupo. También se puede aplicar esto al caso de las políticas de Pandora FMS Enterprise, las cuales tienen asociados ciertos agentes y ciertos módulos que se consideran asociados a cada agente.

Dicha estructura es especialmente útil para evaluar los estados de los módulos a simple vista. Esto se consigue propagando hacia arriba en esta organización los estados, otorgándole así estado a los agentes, grupos y políticas.

Un agente se mostrará con el peor de los estados de sus módulos. A su vez, un grupo tendrá el peor de los estados de los agentes que a él pertenezcan, y lo mismo para las políticas, que tendrán el peor estado de sus agentes asignados.

De este modo, al ver un grupo con estado crítico, por ejemplo, se sabrá que al menos uno de sus agentes tiene ese mismo estado. Para localizarlo, se deberá bajar otro nivel, al de los agentes, para estrechar el cerco y encontrar el módulo o módulos causantes de propagar ese estado crítico.

Cuando se establece de que se propaga el peor de los estados, debe tener claro cuáles estados son prioritarios frente a los demás. Por ello existe una lista de prioridades, siendo el primer estado que figura en ella el que más prioridad tiene sobre los demás y el último el que menos, apareciendo éste solamente cuando todos los elementos lo tienen.

1. Alertas disparadas.
2. Estado crítico.
3. Estado de advertencia.
4. Estado desconocido.
5. Estado normal.

Cuando un módulo tiene alertas disparadas, su estado tiene prioridad sobre todos lo demás y el agente al que pertenece tendrá ese estado y el grupo al que pertenezca ese agente, a su vez, también.

Por otro lado, para que un grupo, por ejemplo, tenga estado normal, todos sus agentes deben tener dicho estado; lo que significa que a su vez todos los módulos de dichos grupos tendrán estado normal.

Cada uno de los estados comentados tiene asignado un color para poder ver de un solo vistazo cuándo un elemento no funciona en los mapas de red.

Estado de Alertas disparadas

Estado Crítico

Estado de Advertencia

Estado Desconocido

Estado Normal

Las gráficas son unas de las implementaciones más complejas de Pandora FMS, extraen datos en tiempo real desde la base de datos y no se utiliza ningún sistema externo (RRDtool o similar).

Existen varios comportamientos de las gráficas en función del tipo de datos origen:

• Módulos asíncronos. Se asume que no hay compactación de datos. Los datos que hay en la base de datos son todas las muestras reales del dato, no hay compactación. Produce gráficas mucho más “exactas” y sin posible malinterpretación.
• Módulos de tipo cadena de texto. Muestran gráficas con la tasa de datos a lo largo del tiempo.
• Módulos de datos numéricos. La mayoría de los módulos reportan este tipo de datos.
• Módulos de datos booleanos. Corresponden a datos numéricos en monitores *PROC: por ejemplo, chequeos Ping, estado de interfaces, etc. El valor 0 se corresponde con el estado Crítico, y el valor 1 con el estado “Normal”.

La compresión afecta a cómo se pintan las gráficas. Cuando se reciben dos datos del mismo valor, Pandora FMS no guarda el último. Además, en el caso de que al pintar una gráfica no tenga un valor de referencia, Pandora FMS buscará hasta 48 horas atrás en el tiempo para encontrar el último valor conocido, el cual tomará de referencia. Si no encontrara ningún dato, la gráfica empezaría desde 0.

En los asíncronos, aunque no hay compresión, el mecanismo de búsqueda hacia atrás se comportaría de forma similar.

Al componer una gráfica se toman 50xN muestras, siendo N el factor de resolución de las gráficas (este parámetro se puede configurar en el setup, y por defecto es 3). Por ejemplo, un monitor que devuelva datos cada 300 segundos (5 minutos) generará 12 muestras por hora, 288 (12*24) en un día. En el caso de una gráfica de un día, realmente no se estarían “imprimiendo” los 288 puntos, sino que se “comprimen” usando únicamente 150 (50*3) muestras.

Esto implica que se “pierde” algo de resolución, y cuantas más muestras tengamos, más se perderá, pero esto puede evitarse creando la gráfica con un intervalo o zoom diferente.

En las gráficas normales, la interpolación se implementa de forma sencilla: si en un intervalo hay dos muestras (p.e: en el intervalo B del ejemplo), se realizará la media y se pintará su valor.

En las gráficas booleanas, si en una muestra se dispone de varios datos (en este caso, solo se podrá tener 0 y 1), se mostrará el 0. Esto ayuda visualmente a ver un caso de fallo en un intervalo, primando el problema sobre la situación corriente.

En ambos casos, si en una muestra no se tiene un dato (porque está comprimido o porque falta), se utilizará el último valor conocido del intervalo anterior para mostrarlo, como ocurre en el intervalo E del ejemplo de arriba.

Las gráficas por defecto muestran el valor medio, máximo y mínimo. Dado que en una muestra puede haber varios datos, se mostrarán los datos para un valor promedio (avg), máximo o mínimo. Cuanto más haya que interpolar una gráfica (cuanto mayor sea el periodo de visualización y más datos haya) mayor será el grado de interpolación y por tanto habrá más diferencias entre los valores max, min y avg.

Cuanto menor sea el rango de la gráfica (ej. gráficas de una hora), no habrá interpolación o será muy ligera, de forma que se verán los datos con su resolución “real” y las tres series serán idénticas.

Volver al índice de documentación de Pandora FMS