Difference between revisions of "Pandora: Documentation es: IngenieríaPandora"

From Pandora FMS Wiki
Jump to: navigation, search
(Base de datos histórica)
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Pandora:Documentation|Volver al ídice de documentación de Pandora FMS]]
+
[[Pandora:Documentation|Volver al índice de documentación de Pandora FMS]]
 +
 
  
 
= Detalles sobre la ingeniería de Pandora FMS =
 
= 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. Solo es una introducción, ya que algunos aspectos técnicos, como el esquema de la Base de Datos de Pandora FMS requeriría mucha mas explicación.
+
En el siguiente apartado se explicarán algunos de los principios de diseño y particularidades de Pandora FMS.  
  
 
== Diseño de la base de datos de Pandora FMS ==
 
== 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.
+
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.
 +
 
 +
A parte de todas las ventajas que suponía este desarrollo, había un inconveniente: la escalabilidad. Este sistema tiene un límite definido en máximo número de módulos que pueda soportar, y con cierta cantidad de datos (> 5 millones de elementos) el rendimiento se veía afectado.
  
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, 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.
  
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.
+
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 [https://pandorafms.com/docs/index.php?title=Pandora:Documentation_es:Gestion_y_Administracion_Server#Mantenimiento_de_los_servidores_de_Pandora_FMS tarea de mantenimiento] permite borrar automáticamente los datos que sobrepasen cierta antigüedad.
  
La versión de Pandora FMS actual implementa 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 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 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.
  
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.  
+
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.
  
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).
+
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. 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.  
+
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.  
  
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.
+
Los mecanismos de compactación tienen ciertas implicaciones a la hora de leer e interpretar los datos gráficamente.
 +
Imaginemos 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 período de tiempo en el que el servidor no tenga información de los módulos de dicho agente. Si accedemos 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 que ver un ejemplo gráfico, esta imagen muestra los cambios para cada dato, recibidos cada 180 segundos.
 
Para que ver un ejemplo gráfico, esta imagen muestra los cambios para cada dato, recibidos cada 180 segundos.
  
<br>
 
<br>
 
 
<center>
 
<center>
 
[[Image:Module_graph_full.jpg]]
 
[[Image:Module_graph_full.jpg]]
 
</center>
 
</center>
<br>
 
<br>
 
  
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.
+
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.
  
 
<br>
 
<br>
Line 41: Line 41:
 
<br>
 
<br>
  
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:
+
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.  
  
 
<br>
 
<br>
Line 47: Line 47:
 
[[Image:Access_graph_full.jpg]]
 
[[Image:Access_graph_full.jpg]]
 
</center>
 
</center>
 +
<center>''Ejemplo de un agente que se conecta regularmente al servidor''</center>
 
<br>
 
<br>
  
 
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.  
 
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.  
  
A partir de la versión 5 de Pandora, 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:
+
A partir de 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:
 
 
<br>
 
 
<center>
 
<center>
 
[[Image:Grafica-dsconocido.jpg]]
 
[[Image:Grafica-dsconocido.jpg]]
 
</center>
 
</center>
<br>
 
  
 
=== Otros aspectos técnicos de BBDD ===
 
=== Otros aspectos técnicos de BBDD ===
  
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 de información en base a diferentes 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.
+
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.
 
 
<center>[[Image:Module_distribution.jpg]]</center>
 
  
En versiones posteriores, se recomienda un particionado de las tablas (por marcas de tiempo) para mejorar aun más el rendimiento del acceso a los históricos de datos.
+
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 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.
+
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.
  
 
=== Tablas principales de la base de datos ===
 
=== 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.
+
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.  
  
 
<br>
 
<br>
Line 87: Line 83:
 
** ''id_agente'': Identificador único del agente.
 
** ''id_agente'': Identificador único del agente.
 
** ''nombre'': Nombre del agente (case sensitive).
 
** ''nombre'': Nombre del agente (case sensitive).
** ''direccion'': Dirección del agente. Se pueden asignar direcciones adicionales a través de taddress.
+
** ''direccion'': Dirección del agente. Se pueden asignar direcciones adicionales a través de la tabla taddress.
 
** ''comentarios'': Texto libre.
 
** ''comentarios'': Texto libre.
 
** ''id_grupo'': Identificador del grupo al que pertenece el agente (ref. tgrupo).
 
** ''id_grupo'': Identificador del grupo al que pertenece el agente (ref. tgrupo).
Line 96: Line 92:
 
** ''os_version'': Versión del SO (texto libre).
 
** ''os_version'': Versión del SO (texto libre).
 
** ''agent_version'': Versión del agente (texto libre). Actualizada por los agentes software.
 
** ''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.
+
** ''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).
 
** ''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).
 
** ''id_parent'': Identificador del padre del agente (ref. tagente).
 
** ''custom_id'': Identificador personalizado del agente. Útil para interactuar con otras herramientas.
 
** ''custom_id'': Identificador personalizado del agente. Útil para interactuar con otras herramientas.
 
** ''server_name'': Nombre del servidor al que está asignado el agente.
 
** ''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 [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:Alertas| Alertas].
+
** ''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 [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:Alertas 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''': 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_inc''': Datos de tipo incremental.
Line 111: Line 109:
 
* '''tagente_estado''': Información del estado actual de cada módulo.
 
* '''tagente_estado''': Información del estado actual de cada módulo.
 
** ''id_agente_estado'': Identificador.
 
** ''id_agente_estado'': Identificador.
** ''id_agente_modulo'': Identificador del módulo (ref. tagente_modulo).
+
** ''id_agente_modulo'': Identificador del módulo (''ref. tagente_modulo'').
 
** ''datos'': Valor del último dato recibido.
 
** ''datos'': Valor del último dato recibido.
 
** ''timestamp'': Fecha del último dato recibido (puede venir del agente).
 
** ''timestamp'': Fecha del último dato recibido (puede venir del agente).
 
** ''estado'': Estado del módulo: 0 NORMAL, 1 CRITICAL, 2 WARNING, 3 UNKNOWN.
 
** ''estado'': Estado del módulo: 0 NORMAL, 1 CRITICAL, 2 WARNING, 3 UNKNOWN.
** ''id_agente'': Identificador del agente asociado al módulo (ref. tagente).
+
** ''id_agente'': Identificador del agente asociado al módulo (''ref. tagente'').
 
** ''last_try'': Fecha de la última ejecución con éxito del módulo.
 
** ''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.
 
** ''utimestamp'': Fecha de la última ejecución del módulo en formato UNIX.
Line 121: Line 119:
 
** ''running_by'': Nombre del servidor que ejecutó el módulo.
 
** ''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.
 
** ''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 [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:Operacion| Operación].
+
** ''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 [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:Operacion Operación].
 
** ''last_status'': Estado anterior del módulo.
 
** ''last_status'': Estado anterior del módulo.
  
 
* '''tagente_modulo''': Configuración de módulos.
 
* '''tagente_modulo''': Configuración de módulos.
 
 
** ''id_agente_modulo'': Identificador único del módulo.
 
** ''id_agente_modulo'': Identificador único del módulo.
 
** ''id_agente'': Identificador del agente asociado al módulo (ref. tagente).
 
** ''id_agente'': Identificador del agente asociado al módulo (ref. tagente).
** ''id_tipo_modulo'': Tipo de módulo (ref. ttipo_modulo).
+
** ''id_tipo_modulo'': Tipo de módulo (''ref. ttipo_modulo'').
 
** ''descripcion'': Texto libre.
 
** ''descripcion'': Texto libre.
 
** ''nombre'': Nombre del módulo.
 
** ''nombre'': Nombre del módulo.
Line 140: Line 137:
 
** ''snmp_oid'': OID en módulos de red. Query WQL 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.
 
** ''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).
+
** ''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.
 
** ''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.
 
** ''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.
 
** ''disabled'': Estado del módulo, 0 habilitado, 1 deshabilitado.
** ''id_export'': Identificador del servidor de exportación asociado al módulo (ref. tserver).
+
** ''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_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_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.
 
** ''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).
+
** ''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.
 
** ''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.
 
** ''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.
 
** ''max_timeout'': Tiempo de espera segundos en módulos plugin.
 
** ''custom_id'': Identificador personalizado del módulo. Útil para interactuar con otras herramientas.
 
** ''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.
+
** ''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.
 
** ''min_warning'': Valor mínimo que activa el estado WARNING.
 
** ''max_warning'': Valor máximo 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.
 
** ''min_critical'': Valor mínimo que activa el estado CRITICAL.
 
** ''max_critical'': Valor máximo 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.  
+
** ''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 script de mantenimiento de la base de datos pandora_db.pl.
+
** ''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_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_integer_2'':
 
** ''custom_string_1'':
 
** ''custom_string_1'':
Line 166: Line 163:
 
** ''custom_string_3'':
 
** ''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.
+
* '''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_snmp''': Configuración de alertas SNMP.
  
*'''talert_commands''': Comandos que se podrán ejecutar desde acciones asociadas a una alerta (eg. enviar mail).
+
*'''talert_commands''': Comandos que se podrán ejecutar desde acciones asociadas a una alerta (ej. enviar mail).
  
*'''talert_actions''': Instancia de un comando asociada a una alerta (eg. enviar mail al administrador).
+
*'''talert_actions''': Instancia de un comando asociada a una alerta (ej. enviar mail al administrador).
  
 
*'''talert_templates''': Plantillas de alertas.
 
*'''talert_templates''': Plantillas de alertas.
 
 
** ''id'': Identificador único de la plantilla.
 
** ''id'': Identificador único de la plantilla.
 
** ''name'': Nombre de la plantilla.
 
** ''name'': Nombre de la plantilla.
Line 186: Line 182:
 
** ''value'': Valor para alertas tipo regex (texto libre).
 
** ''value'': Valor para alertas tipo regex (texto libre).
 
** ''matches_value'': A 1 invierte la lógica de la condición de disparo.
 
** ''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.
+
** ''max_value'': Valor máximo para alertas ''max_min'' y ''max''.
** ''min_value'': Valor mínimo para alertas max_min y min.
+
** ''min_value'': Valor mínimo para alertas ''max_min'' y ''min''.
 
** ''time_threshold'': Intervalo de la alerta.
 
** ''time_threshold'': Intervalo de la alerta.
 
** ''max_alerts'': Número máximo de veces que se disparará una alerta durante un intervalo.
 
** ''max_alerts'': Número máximo de veces que se disparará una alerta durante un intervalo.
Line 200: Line 196:
 
** ''saturday'': A 1 la alerta está activa los sábados.
 
** ''saturday'': A 1 la alerta está activa los sábados.
 
** ''sunday'': A 1 la alerta está activa los domingos.
 
** ''sunday'': A 1 la alerta está activa los domingos.
** ''recovery_notify'': A 1 habilita la [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:Alertas#Plantilla_de_alerta| recuperación de alertas].
+
** ''recovery_notify'': A 1 habilita la [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:Alertas#Plantilla_de_alerta recuperación de alertas].
 
** ''field2_recovery'': Campo personalizado 2 para la recuperación de alerta (texto libre).
 
** ''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).
 
** ''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.
 
** ''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).
+
** ''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.
 
* '''talert_template_modules''': Instancia de una plantilla de alerta asociada a un módulo.
 
 
** ''id'': Identificador único de la alerta.
 
** ''id'': Identificador único de la alerta.
** ''id_agent_module'': Identificador del módulo asociado a la alerta (ref. tagente_modulo).
+
** ''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).
+
** ''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.
 
** ''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_fired'': Última vez que se disparó la alerta (tiempo UNIX).
 
** ''last_reference'': Comienzo del intervalo actual (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).
+
** ''times_fired'': Número de veces que se disparó la alerta (puede ser distinto a ''internal_counter'').
 
** ''disabled'': A 1 la alerta está deshabilitada.
 
** ''disabled'': A 1 la alerta está deshabilitada.
 
** ''priority'': Criticidad de la alerta: 0 Maintenance, 1 Informational, 2 Normal, 3 Warning, 4 Critical.
 
** ''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.
 
** ''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_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''': 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_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).
+
* '''talert_compound_actions''': Acciones asociadas a una alerta compuesta (''ref. talert_compound'').
  
 
* '''tattachment''': Adjuntos asociados a una incidencia.
 
* '''tattachment''': Adjuntos asociados a una incidencia.
Line 243: Line 238:
 
* '''tlink''': Enlaces mostrados en la parte inferior del menú de la consola.
 
* '''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''': 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_component_group''': Grupos para clasificar los componentes de red.
Line 249: Line 244:
 
* '''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''': 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).
+
* '''tnetwork_profile_component''': Componentes de red asociados a un perfil de red (''rel. tnetwork_component/tnetwork_profile'').
  
 
* '''tnota''': Notas asociadas a una incidencia.
 
* '''tnota''': Notas asociadas a una incidencia.
Line 257: Line 252:
 
* '''tperfil''': Perfiles de usuarios definidos en la consola.
 
* '''tperfil''': Perfiles de usuarios definidos en la consola.
  
* '''trecon_task''': Tareas de reconocimiento del [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:ReconServer| Recon Server].
+
* '''trecon_task''': Tareas de reconocimiento del [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:ReconServer Recon Server].
  
 
* '''tserver''': Servidores registrados.
 
* '''tserver''': Servidores registrados.
Line 269: Line 264:
 
* '''tusuario''': Usuarios registrados en la consola.
 
* '''tusuario''': Usuarios registrados en la consola.
  
* '''tusuario_perfil''': Perfiles asociados a un usuario (rel. tusuario/tperfil).
+
* '''tusuario_perfil''': Perfiles asociados a un usuario (''rel. tusuario/tperfil'').
  
 
* '''tnews''': Noticias mostradas en la consola.
 
* '''tnews''': Noticias mostradas en la consola.
Line 275: Line 270:
 
* '''tgraph''': Gráficas personalizadas creadas en la consola.
 
* '''tgraph''': Gráficas personalizadas creadas en la consola.
  
* '''tgraph_source''': Módulos asociados a una gráfica (rel. tgraph/tagente_modulo).
+
* '''tgraph_source''': Módulos asociados a una gráfica (''rel. tgraph/tagente_modulo'').
  
 
* '''treport''': Informes personalizados creados en la consola.
 
* '''treport''': Informes personalizados creados en la consola.
Line 293: Line 288:
 
* '''tmodule''': Tipos de módulos (Network, Plugin, WMI...).
 
* '''tmodule''': Tipos de módulos (Network, Plugin, WMI...).
  
* '''tserver_export''': Destinos configurados para el [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:ExportServer| Export Server].
+
* '''tserver_export''': Destinos configurados para el [https://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:ExportServer Export Server].
  
 
* '''tserver_export_data''': Datos a exportar, asociados a un destino.
 
* '''tserver_export_data''': Datos a exportar, asociados a un destino.
Line 299: Line 294:
 
* '''tplanned_downtime''': Paradas programadas.
 
* '''tplanned_downtime''': Paradas programadas.
  
* '''tplanned_downtime_agents''': Agentes asociados a una parada programada (rel. tplanned_downtime/tagente).
+
* '''tplanned_downtime_agents''': Agentes asociados a una parada programada (''rel. tplanned_downtime/tagente'').
  
 
=== Compresión de datos en tiempo real ===
 
=== Compresión de datos en tiempo real ===
  
Tal como se ha comentado antes, 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.
+
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 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.
 
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.
Line 309: Line 304:
 
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 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.
  
<br>
 
<br>
 
 
<center>
 
<center>
 
[[File:Data_compression_01.png‎]]
 
[[File:Data_compression_01.png‎]]
 
</center>
 
</center>
<br>
 
<br>
 
  
 
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.
 
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:
+
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 existe hay que traerlo al inicio del intervalo. Si no existe anteriormente no había datos.
+
* 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 existe hay que traerlo al final del intervalo. Si no hay que prolongar el último valor disponible hasta el final del intervalo.
+
* 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.
 
* Se recorren todos los datos, teniendo en cuenta que un dato es válido hasta que se reciba un dato distinto.
Line 329: Line 320:
 
=== Compactación de datos ===
 
=== 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.
+
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 antiguos 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.
+
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 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) serán 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.  
+
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.
  
<center>
+
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.
<i>Ejemplo gráfica de datos sin compactar</i>
+
 
<br><br>
+
<br>
[[Image:Compact1.png|350px]]
 
<br><br>
 
</center>
 
<center>
 
<i>Ejemplo de gráfica de datos sin compactados</i>
 
<br><br>
 
[[Image:Compact2.png|350px]]
 
<br><br>
 
</center>
 
  
 
=== Base de datos histórica ===
 
=== Base de datos histórica ===
  
La base de datos histórica se trata de una funcionalidad Enterprise y es usada para almacenar información antigua, que no se usa en vistas "del dia a dia", como por ejemplo los datos con una antigüedad de más de un mes. Esos datos, se mueven de forma transparente a una base de datos diferente. Esta base de datos '''debe''' estar en un servidor físico distinto (no virtualizar) con un almacenamiento (disco) diferente al de la base de datos principal. Automáticamente cuando queremos que nos muestre una gráfica o un informe con datos del último 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.
+
La base de datos histórica es una funcionalidad Enterprise, utilizada para almacenar toda la información pasada, que no se usa en vistas "del día a día", 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 físico distinto (no virtual) 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),y permisos de instalación para permitir el acceso a ella desde el servidor de Pandora FMS principal.
+
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.
  
 
Ir a ''Setup > Setup > History database'' y configurar ahí los parámetros para acceder a la base de datos histórica.
 
Ir a ''Setup > Setup > History database'' y configurar ahí los parámetros para acceder a la base de datos histórica.
Line 364: Line 348:
 
<br>
 
<br>
  
Algunos de los parámetros que tienen que ser explicados:
+
Algunos de los parámetros a tener en cuenta son los siguientes:  
  
*'''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.
+
*'''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.
+
*'''Paso:''' Actúa como un buffer, el script de mantenimiento de la base de datos tomará X registros de la base de datos principal, los insertará en la base de datos histórica y los borrará de la principal. Esto conlleva tiempo y el tamaño dependerá de la configuración de la consola. Un valor correcto por defecto sería 1000.  
  
*'''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.  
+
*'''Retraso:''' Después de un bloque de una serie de módulos, el script esperará los segundos que se especifique en el ''retraso''. Es útil si el rendimiento de la base de datos es pobre porque evita bloqueos. Los valores deben estar entre 1-5.  
  
La configuración por defecto de Pandora FMS 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 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.
+
La configuración por defecto de Pandora FMS no transfiere datos tipo ''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 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''':
+
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''. Si se quisiera, por ejemplo, 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";
 
  UPDATE tconfig SET value = 30 WHERE token = "string_purge";
Line 390: Line 374:
 
=== ¿Cuándo se establece cada estado? ===  
 
=== ¿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.  
+
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.
+
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.
+
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''.
  
 
=== Propagación y prioridad ===
 
=== 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.
+
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.
  
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.  
+
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.  
  
 
==== ¿Qué estado tendrá un agente? ====
 
==== ¿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.
+
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, 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.
+
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.
  
 
==== ¿Cuál es la prioridad de los estados? ====
 
==== ¿Cuál es la prioridad de los estados? ====
Line 421: Line 405:
  
 
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.
 
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.
 
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.
  
 
=== Código de colores ===
 
=== 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.
+
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.  
  
 
<div style='margin-left: 200px; text-align: left;'>
 
<div style='margin-left: 200px; text-align: left;'>
Line 438: Line 423:
 
== Gráficas de Pandora FMS ==
 
== 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).
+
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 (tipo ''rrdtool'' o similar).
  
 
Existen varios comportamientos de las gráficas en función del tipo de datos origen:
 
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 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, es decir.
+
* '''Módulos de tipo cadena de texto'''. Muestran gráficas con la tasa de datos a lo largo del tiempo.
* '''Módulos de datos numericos'''. La mayoria de los modulos reportan este tipo de datos.  
+
* '''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 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.  
+
* '''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".
  
 
=== Compresión ===
 
=== 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.
+
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 comporta de forma similar.
+
En los asíncronos, aunque no hay compresión, el mecanismo de búsqueda hacia atrás se comportaría de forma similar.  
  
 
=== Interpolación ===
 
=== 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).
+
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 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.
+
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.
  
 
<center><br>
 
<center><br>
Line 463: Line 448:
 
</center>
 
</center>
  
 +
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 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 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 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.
+
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.
  
 
=== Avg/Max/Min ===
 
=== Avg/Max/Min ===
Line 476: Line 460:
 
</center>
 
</center>
  
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.
+
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 período 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.
  
  
[[Pandora:Documentation|Volver al ídice de documentación de Pandora FMS]]
+
[[Pandora:Documentation|Volver al índice de documentación de Pandora FMS]]
  
 
[[Category: Pandora FMS]]
 
[[Category: Pandora FMS]]

Latest revision as of 11:43, 11 February 2020

Volver al índice de documentación de Pandora FMS


1 Detalles sobre la ingeniería de Pandora FMS

En el siguiente apartado se explicarán 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 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.

A parte de todas las ventajas que suponía este desarrollo, había un inconveniente: la escalabilidad. Este sistema tiene un límite definido en máximo número de módulos que pueda soportar, y con cierta cantidad de datos (> 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 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.

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. Imaginemos 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 período de tiempo en el que el servidor no tenga información de los módulos de dicho agente. Si accedemos 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 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 por un fallo de la conexión, de 05:55 a 15:29 aproximadamente.


Module graph peak.jpg


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.


Access graph full.jpg

Ejemplo de un agente que se conecta regularmente al servidor


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.

A partir de 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:

Grafica-dsconocido.jpg

1.1.1 Otros aspectos técnicos de BBDD

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.

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.


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 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 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).
    • 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: 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.
    • 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 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 mail).
  • talert_actions: Instancia de un comando asociada a una alerta (ej. 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.
    • 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

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

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

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.


1.1.5 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 "del día a día", 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 físico distinto (no virtual) 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.

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 a tener en cuenta son los siguientes:

  • 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 tomará X registros de la base de datos principal, los insertará en la base de datos histórica y los borrará de la principal. Esto conlleva tiempo y el tamaño dependerá de la configuración de la consola. Un valor correcto por defecto sería 1000.
  • Retraso: Después de un bloque de una serie de módulos, el script esperará los segundos que se especifique en el retraso. Es útil si el rendimiento de la base de datos es pobre porque evita bloqueos. Los valores deben estar entre 1-5.

La configuración por defecto de Pandora FMS no transfiere datos tipo 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. Si se quisiera, por ejemplo, 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";

Una buena manera de comprobar 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

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.

1.2.2.1 ¿Qué estado tendrá un agente?

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.

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 de un solo vistazo cuándo un elemento no funciona en los mapas de red.

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, extraen datos en tiempo real desde la base de datos y no se utiliza ningún 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 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".

1.3.1 Compresión

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.

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


Graph-explain.png

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.

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 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 período 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