Pandora: Documentation es: IngenieríaPandora

From Pandora FMS Wiki
Jump to: navigation, search

Volver al ídice de documentación de Pandora FMS

1 Detalles sobre la ingeniería de Pandora FMS

En este anexo se van a explicar algunos de los principios de diseño y particularidades de Pandora FMS

1.1 Diseño de la base de datos de Pandora FMS

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

Esto tenía muchas ventajas y un gran inconveniente: la escalabilidad. Este sistema tiene un límite definido en máximo número de módulos que pueda soportar, sin tener que implementar costosos mecanismos de clusterización que permitan más carga, y aun así, con cierto número de datos el funcionamiento ya no era tan rápido (> 5 millones de elementos).

Las soluciones basadas en clúster MySQL no son fáciles y siempre añaden algunos problemas menores, además tampoco ofrecen siquiera una solución a largo plazo.

La versión de Pandora FMS (1.3 y superiores) implementan una compresión de datos en tiempo real para cada inserción. Además permite realizar una compresión de datos basada en interpolación. También implementa —como en versiones anteriores; un borrado automático de los datos a partir de una determinada antigüedad.

El nuevo sistema de procesado de datos almacena sólo datos «nuevos». Si entra un valor duplicado en el sistema, no se almacenará en la base de datos. Es muy útil para mantener la base de datos reducida. Esto funciona para todos los módulos de Pandora FMS: numérico, incremental, booleano y cadena. En los datos de tipo booleano el índice de compactación es altísimo 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.

Esto resuelve parte del problema de escalabilidad reduciendo considerablemente el uso de la base de datos, sobre un 40%-70%. También existe otra solución para problemas de escalabilidad: la disgregación total de componentes en Pandora FMS, que permite equilibrar la carga de procesado de ficheros de datos y ejecución de módulos de red en diferentes servidores. Ahora ya se pueden 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).

Las modificaciones comportan grandes cambios a la hora de leer e interpretar los datos. Se ha rediseñado e implementado desde cero el motor gráfico para poder representar los datos de forma rápida con el nuevo modelo de almacenamiento de datos. Con la nueva versión, si un agente no puede comunicarse con Pandora FMS, y el servidor de Pandora FMS no recibe datos del agente, entonces esta ausencia de datos no puede tener una representación gráfica, y en lo que a la gráfica del modulo se refiere, no habrá cambios.

Se obtendrá una gráfica con una perfecta línea horizontal. Pandora FMS, si no recibe nuevos valores, creerá que no los hay, y todo aparecerá tal y como estaba en la última notificación. Similar al comportamiento de MRTG, por ejemplo.

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



Module graph full.jpg



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



Module graph peak.jpg



En Pandora FMS 1.3 se introduce 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 gráficos que muestran cuando el agente tiene actividad y está recibiendo datos. Este es un ejemplo de un agente que se conecta regularmente al servidor:



Access graph full.jpg



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.

1.1.1 Mejoras en los índices y otros aspectos técnicos de BB.DD.

Se han implementado pequeñas mejoras en el modelo relacional de la base de datos de Pandora FMS. Uno de los cambios introducidos ha sido la indexación por tipos de módulos. De esta forma es más rápido acceder a la información, ya que el agente lógico de Pandora FMS, que sirve para «colgar» toda la información de monitorización, se reparte en diferentes pedazos de información que pueden provenir de fuentes muy diferentes. En la próxima versión de Pandora FMS se han planificado hasta cuatro tipos de servidores específicos nuevos que ofrecerán una oferta más amplia de tipos de información para procesar.

Module distribution.jpg

Además, factores como la representación numérica de las marcas de tiempo (en formato UNIX, o número de segundos desde el 1 de enero de 1970), 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.

1.1.2 Tablas principales de la base de datos

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. El resto de tablas también se comentan brevemente.



Pandora db eer.png



  • 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 (case sensitive).
    • direccion: Dirección del agente. Se pueden asignar direcciones adicionales a través de 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 SO del agente (ref. tconfig_os).
    • os_version: Versión del SO (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).
    • 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. http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_es:Alertas#Protecci.C3.B3n_en_cascada
  • 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. http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_es:Operacion#FF_Threshold
    • 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: Flag 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 servidor de exportación 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. http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_es:Operacion#FF_Threshold
    • delete_pending: Si está a 1 el módulo será borrado por el script de mantenimiento de la base de datos pandora_db.pl.
    • 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:
    • custom_string_1:
    • custom_string_2:
    • custom_string_3:
  • tagent_access: Se inserta una nueva entrada cada vez que legan 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 (eg. enviar mail).
  • talert_actions: Instancia de un comando asociada a una alerta (eg. enviar mail 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. http://www.openideas.info/wiki/index.php?title=Pandora_3.0:Documentation_es:Alertas#Plantilla_de_alerta
    • 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.
  • 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.
  • 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_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).

1.1.3 Compresión de datos en tiempo real

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 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.



Data compression 01.png



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 dados un intervalo y una fecha inicial, hay que seguir los siguientes pasos:

  • Buscar el dato anterior fuera del intervalo y fecha dados. Si existe hay que traerlo al inicio del intervalo. Si no existe anteriormente no había datos.
  • Buscar el siguiente dato fuera del intervalo y fecha dados hasta un máximo igual al intervalo del módulo. Si existe hay que traerlo al final del intervalo. Si no hay 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.


1.1.4 Compactación de datos

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/mediano (250-500 agentes, < 100.000 módulos) que desean tener un histórico de información extenso pero "perdiendo" resolución.

El mantenimiento de la base de datos de Pandora FMS,el cual se ejecuta cada día, hace un escaneo de los datos antigüos sometidos a ser compactados.La compactación se realiza usando una interpolación simple y lineal,lo que significa que si tenemos 10.000 puntos de información en un día tendremos el resultado del proceso que reemplazará esos 10.000 puntos por 1000 puntos.

Esto,obviamente,al ser una interpolación hace que se "pierda" información PERO igualmente guarda el almacenamiento de los datos y en gráficos con largos periodos de tiempo (mensual,anual) seran exactamente iguales.En bases de datos de gran tamaño este comportamiento puede ser bastante "costoso" en lo que se refiere al rendimiento de la base de datos y tendría que ser desactivado.En su lugar habría que optar por utilizar el modelo de base de datos histórica.

Ejemplo gráfica de datos sin compactar

Compact1.png

Ejemplo de gráfica de datos sin compactados

Compact2.png

1.1.5 Base de datos histórica

La base de datos histórica se trata de una funcionalidad Enterprise y es usada para almacenar información desde un punto en una hora dada, por ejemplo,los datos con una antigüedad de más de un mes en otra base de datos. Esta base de datos debe estar en un servidor físico distinto (no virtualizar). Automáticamente cuando queremos que nos muestre una gráfica de datos de un año, Pandora FMS mirará los primeros XX días en la base de datos "normal" y el resto en la base de datos histórica. De esta manera se puede evitar el tener problemas de rendimiento cuando acumulamos una cantidad grande de información en nuestro 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),y permisos de instalación para permitir el acceso a ella desde el servidor de Pandora FMS principal.

Ir a Setup > Setup > History database y configurar ahí los parámetros para acceder a la base de datos histórica.



Bbddhist.png



Algunos de los parámetros que tienen que ser explicados:

Días: Máximo de días que la información se almacena en la base de datos principal.Después de esa fecha,los datos serán movidos a la base de datos histórica. 30 días sería un buen margen.

Paso: Actúa como un buffer,el script de mantenimiento de la base de datos tomara XX registros de la Base de Datos,los insertará en la base de datos histórica y los borrará de la base de datos principal.Esto conlleva un consumo de tiempo y el tamaño depende de tu configuración.1000 sería un buen valor por defecto.

Retraso: Después de un bloque de una serie de módulos,el script esperará los segundos que se especifique en el retraso. Útil si el rendimiento de la base de datos es pobre,para evitar bloqueos. Los valores deben estar entre 1-5.

La configuración por defecto de pandora NO transfiere datos tipo string a la base de datos de histórico, no obstante si hemos modificado esta configuración y nuestra base de datos de histórico sí está recibiendo este tipo de información es imprescindible que configuremos su purgado ya que de otro modo terminará ocupando demasiado pudiendo ocasionar grandes problemas, además de tener un impacto negativo en el rendimiento.

Para configurar este parámetro debemos ejecutar directamente una consulta en la base de datos para determinar los días tras los cuales se purgará esta información. La tabla que nos interesa es tconfig y el campo string_purge. Si quisiésemos por ejemplo establecer 30 días para el purgado de este tipo de información, ejecutaríamos la siguiente query directamente sobre la base de datos de histórico:

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

Una buena manera de comprobar manualmente que el mantenimiento de la base de datos se ejecuta correctamente es correr 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.

1.2 Estados de los módulos en Pandora FMS

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

1.2.1 ¿Cuándo se establece cada estado?

Por un lado, cada módulo tiene en su configuración unos umbrales de Advertencia y Crítico. 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.

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.

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.

1.2.2 Propagación y prioridad

En la organización de Pandora, 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.

Esta 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.

1.2.2.1 ¿Qué estado tendrá un agente?

Un agente tendrá el peor de los estados de sus módulos. Recursivamente, 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, con ver un grupo con estado crítico, por ejemplo, sabremos que al menos uno de sus agentes tiene ese mismo estado. Al localizarlo, podremos bajar otro nivel para llegar al módulo o módulos causantes de propagar el estado crítico hasta el nivel más alto.

1.2.2.2 ¿Cuál es la prioridad de los estados?

Cuando hablamos de que se propaga el peor de los estados, debemos tener claro qué 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

Vemos que 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.

1.2.3 Código de colores

Cada uno de los estados comentados tiene asignado un color, para poder ver en los mapas de red, a simple vista, cuando algo no funciona correctamente.

Orange status.png Estado de Alertas disparadas
Red status.png Estado Crítico
Yellow status.png Estado de Advertencia
Grey status.png Estado Desconocido
Green status.png Estado Normal


1.3 Gráficas de Pandora FMS

Las gráficas son unas de las implementaciones más complejas de Pandora FMS, ya que extraen datos en tiempo real desde la BBDD y no se utiliza ningun sistema externo (tipo 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 BBDD son todas las muestras reales del dato -no hay compactación. Produce gráficas mucho mas "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, es decir.
  • Módulos de datos numericos. La mayoria de los modulos reportan este tipo de datos.
  • Módulos de datos booleanos. Corresponden a datos numericos en monitores *PROC: por ejemplo, chequeos Ping, esado de interfaces, etc. Valor 0 es algo malo y 1 es el estado "Normal". Levantan eventos cuando cambian de estado automáticamente.

1.3.1 Compresión

La compresión afecta a como se pintan las gráficas. Cuando recibimos dos datos del mismo valor, pandora no guarda el ultimo dato, sino que interpreta que el ultimo valor conocido se puede usar para el momento actual si no tengo otro valor. Si cuando pintamos una gráfica no tengo un valor de referencia justo al inicio de pintar la gráfica, pandora busca hasta 48hr atrás en el tiempo para encontrar el último valor conocido, que toma como referencia. Si no encuentra alguna, empieza desde 0.

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

1.3.2 Interpolación

Al componer una gráfica se toman 50xN muestras. Siendo N el factor de resolución de las gráficas (un parámetro que se puede configurar en el setup). Un monitor que devuelva datos cada 300 segundos (5 minutos) generará 12 muestras por hora, y 12x24=288 muestras en un dia. Asi que si pedimos una gráfica de un día, realmente no estamos "imprimiendo" los 288 puntos, sino que debemos "comprimir" o interpolar la gráfica usando unicamente 50x3=150 muestras (por defecto la resolucion de graficas en pandora es 3).

Esto significa que "perdemos" algo de resolucion, y cuantas mas muestras tengamos, por ejemplo, las 2016 muestras de una semana o las 8400 muestras de un mes, debemos meterlas en las 150 muestras de una gráfica. Por ello a veces perdemos detalle y no vemos ciertos detalles, para eso la gráfica se puede pedir con diferentes intervalos y hacer zoom.


Graph-explain.png


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

En las gráficas booleanas, si en una muestra tenemos varios datos (sólo podemos tener 0 y 1), nos ponemos siempre en el caso peor, y mostramos el 0. Esto ayuda visualmente a ver un caso de fallo en un intervalo, primando el problema sobre la situacion corriente.

En ambos casos, si en una muestra no tenemos un dato (porque está comprimido o porque falta), utilizamos el ultimo valor conocido del intervalo anterior para mostrar el dato, como ocurre en el intervalo E del ejemplo de arriba.

1.3.3 Avg/Max/Min

Grafica avg max min.png

Las gráficas por defecto muestran el valor medio, máximo y mínimo. Dado que en una muestra (ver interpolación), puede haber varios datos, podemos hablar de mostrar datos para valor promedio (avg), máximo o mínimo. Cuanto más haya que interpolar una gráfica (cuanto mayor sea el período que visualicemos y más datos tengamos), mayor será el grado de interpolación y por tanto habrá probablemente más diferentes entre los valores max, min y avg. Cuanto menor sea el rango de la gráfica (p,e: gráficas de una hora), no habrá interpolación o será muy ligera, de forma que veremos los datos con su resolucion "real" y las tres series seran idénticas.


Volver al ídice de documentación de Pandora FMS