Pandora:Documentation es:Intro Monitorizacion

From Pandora FMS Wiki

Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

Introducción a la monitorización

Monitorización con Pandora FMS

Toda la interacción del usuario con Pandora FMS se realiza a través de la consola WEB. La consola de Pandora FMS es una consola WEB que sigue los últimos estándares y tecnologías WEB, por lo que requiere un navegador avanzado y el uso opcional de Flash. Se recomienda Firefox 2.x o superior. También puede usarse Internet Explorer 8 o superior, aunque este provee una experiencia de usuario más incómoda por su manera particular de gestionar algunos controles WEB.

De una forma genérica, la monitorización consiste en la ejecución de procesos (a través de módulos) sobre cualquier tipo de sistemas para posteriormente enviar sus datos resultantes al servidor. Este los procesará y se mostrarán al usuario mediante el front-end (la consola WEB).

Pandora FMS es un sistema de monitorización escalable. Con un solo servidor se podrían monitorizar en torno a 1200/1500 agentes aunque con la arquitectura correcta (metaconsola) el número de procesos de monitorización puede aumentar sin restricciones.

Monitorización basada en agentes software vs. monitorización remota

Existen dos principales procedimientos de monitorización con Pandora FMS: la monitorización basada en agentes software (local) y la remota.

La basada en agentes software incorpora en el sistema monitorizado una pieza de software (módulo), por ejemplo la medición del consumo de CPU en tanto por ciento en determinado sistema. Mientras que la monitorización remota se realizará mediante pruebas de red sin la utilización de módulos, por ejemplo detectar si un host está activo.

La principal diferencia entre estos dos tipos es que mientras la que está basada en agentes software se ejecuta desde el sistema monitorizado, la monitorización de red se ejecuta desde el servidor de Pandora FMS contra el sistema deseado.

Agentes en Pandora FMS

Toda la monitorización que realiza Pandora FMS se organiza a través de una entidad genérica llamada "agente", que está dentro de un bloque más genérico, llamado grupo. Un agente sólo puede pertenecer a un grupo.

La información se ordena de forma lógica mediante una jerarquía basada en grupos, agentes, grupos de módulos y módulos. Existen agentes basados unicamente en la información proporcionada por un agente software e instalados en el Sistema, y agentes con información exclusiva de red, información que no procede de un agente software, donde no hay necesidad de instalar ningún software, y que ejecuta las tareas de monitorización de red desde los servidores de red de Pandora FMS.



AgentHierarchy.png



De igual manera, existen agentes que tienen tanto información de red, como información obtenida mediante agentes software.

La información se recoge en módulos que están asignados (de forma lógica) a agentes de Pandora FMS en la consola. Es importante distinguir el concepto de agente (de donde cuelgan los módulos, que contienen la información recolectada) de los agentes software que se ejecutan en sistemas remotos.

Monitorización de estados

Desde Pandora FMS 3.0 se incorpora una importante funcionalidad que cambia la forma en la que Pandora FMS estaba trabajando hasta ahora. Pandora FMS permite que el usuario establezca baremos para definir cualquier dato en tres estados posibles: NORMAL, WARNING y CRITICAL.

De forma automática, todos los módulos de tipo *proc se catalogan como NORMAL si tienen un valor de 1 o mayor de 1, y como CRITICAL si tienen un valor menor que uno (0 o un valor negativo).

Pero, ¿Qué ocurre con un valor de uso de CPU?, ¿Cómo puede saber el sistema si es un valor NORMAL, CRITICAL o WARNING?. Por defecto no lo sabe, sólo obtiene un valor numérico y si no se le dice nada, para el están todos los valores "bien", es decir, en estado NORMAL.

Existen dos campos de estado en la configuración del agente que no se han mencionado antes, estos son los campos:

  • Estado advertencia ─ Warning status
  • Estado crítico ─ Critical status

Estos dos campos hasta ahora disponían de dos valores cada uno: mínimo y máximo. Adicionalmente y a partir de Pandora 4.0, se dispone de un tercer valor para asociar un estado de advertencia o crítico a cadenas de texto, en el caso de los módulos de tipo string. Configurándolos correctamente se conseguirá que ciertos valores marquen un módulo como estado en advertencia, y otros como crítico:

PandoraStatus.jpeg



Para entender mejor estas opciones es mejor ver un ejemplo. El módulo de CPU siempre va a estar verde en el estado de los agentes, ya que simplemente informa de un valor entre 0% y 100%. Si queremos que el módulo de uso de CPU se marque en amarillo (advertencia) cuando llegue al 70% de su uso, y en rojo cuando llegue al 90%, deberemos configurar:

  • Estado advertencia: 70
  • Estado crítico: 90

Con ello, cuando se llegue al valor 90 el módulo aparecerá en rojo (CRITICAL), mientras que entre 70 y 89.99 estará en amarillo (WARNING), y por debajo de 70 en verde (NORMAL).

Si tenemos un módulo de tipo string podemos configurar los estados usando expresiones regulares en los campos Str de los parámetros Warning Status y Critical Status. Por ejemplo: tenemos un módulo que nos devolverá como dato OK, ERROR connection fail o BUSY to much devices, dependiendo del resultado de la consulta.

Para configurar los estados de WARNING y CRITICAL del módulo de texto usaremos las siguientes expresiones regulares:

Warning Status: .*BUSY.*
Crirical Status: .*ERROR.*

Debe tener cuidado porque las expresiones regulares son case sensitive. Con esta configuración el módulo tendrá estado WARNING cuando el dato contenga el string BUSY y su estado será CRITICAL cuando el dato contenga el string ERROR.

Si por algún casual se configuran ambos estados con los mismos valores, el valor crítico tiene preferencia, es decir, nunca se alcanzará el estado de advertencia puesto que el crítico es más importante.

Éste es un ejemplo de módulos en cada uno de los estados:

Colorin.jpg


Es evidente que estos campos no tienen sentido para módulos que sólo devuelven valores booleanos (1 ó 0).

Estos valores se muestran en la pantalla principal de la vista de los monitores, pudiendo saber de un vistazo cuántas comprobaciones están en estado correcto, en estado advertencia y en estado crítico.

Otros parámetros de Monitorización comunes

Histórico



Historicaldata.png


Pandora FMS permite almacenar (opcionalmente) el histórico de cada dato, de forma individual. Por defecto todos los módulos guardan histórico (lo que les permite pintar gráficas, incluirlos en informes de tipo histórico/evolutivo, etc). Sin embargo en una implantación muy grande que necesite monitorizar muchos datos, puede que pueda prescindir de mantener el histórico de algunos de los datos, permitiendo así utilizar menos recursos.

Esta opción permite desactivar el histórico de aquellos módulos donde no necesite guardar un histórico. Aunque desactive el histórico, las alertas continuarán funcionando exactamente igual, lo mismo que la generación de eventos y la visualización del estado actual de ese monitor.

FF Threshold



Fft.png


El parámetro FF Threshold (FF = FlipFlop) se utiliza para "filtrar" los cambios continuos de estado en la generación de eventos/estados, de forma que se le pueda decir a Pandora FMS que hasta que un elemento no esté al menos X veces en el mismo estado después de cambiar desde un estado original, no lo considere como que ha cambiado. Pongamos un ejemplo clásico: Un ping a un host donde hay pérdida de paquetes. En un entorno de este tipo, podría darnos resultados como:

1
1
0
1
1
0
1
1
1

Sin embargo el host está vivo en todos los casos. Lo que queremos realmente decirle a Pandora es que hasta que el host no diga que está al menos tres veces caído, no lo marque como tal, de forma que en el caso anterior nunca estaría como caído, y solo en este caso lo estaría:

1
1
0
1
0
0
0

A partir de este punto ya lo marcaría como caído, pero no antes.

Por tanto la protección anti Flip-Flop sirve para evitar estas molestas fluctuaciones, Todos los módulos lo implementan y su uso es para evitar el cambio de estado (delimitado por sus limites definidos o limites automáticos, como es el caso de los módulos *proc).

Volver a Indice de Documentacion Pandora FMS