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.

Monitorización dinámica

La monitorización dinámica consiste en el ajuste dinámico y de forma automática de los umbrales de estados de los módulos de una forma inteligente y predictiva. El modo de funcionar es recoger los valores de un periodo determinado y calcular una media y una desviación estándar, que es utilizada para establecer los umbrales correspondientes.

La configuración se realiza a nivel de módulo, y los parámetros posibles son:

  • Dynamic Threshold Interval: intervalo de tiempo que se considerará para realizar el cálculo de umbrales. Si elegimos 1 mes, el sistema tomará todos los datos existentes en el último mes y construirá los umbrales en base a esos datos.
  • Dynamic Threshold Two Tailed: si se activa, el sistema de umbrales dinámicos establecerá también umbrales por debajo de la media. Si se encuentra desmarcado (por defecto) solo se establecerán umbrales con valores por encima de la media.
  • Dynamic Threshold Max.: permite aumentar el límite superior en el porcentaje que indiquemos. Ej: si los valores promedio se encuentran alrededor del 60 y el umbral crítico ha sido establecido a partir del valor 80, si establecemos el valor Dynamic Threshold Max: 10, aumentaremos un 10% este umbral crítico, por lo que quedaría en un 88.
  • Dynamic Threshold Min.: solo aplica si tenemos activo el parámetro Dynamic Threshold Two Tailed. Permite reducir el límite inferior en el porcentaje que indiquemos. Ej: si los valores promedio se encuentran alrededor del 60 y el umbral crítico inferior ha sido establecido en un valor 40, si establecemos el valor Dynamic Threshold Min: 10, reduciremos un 10% este umbral crítico, por lo que quedaría en un 36.

Además existen varios parámetros de configuración adicionales en el fichero pandora_server.conf.

  • dynamic_updates: este parámetro determina cuántas veces se recalculan los umbrales durante el periodo de tiempo establecido en Dynamic Threshold Interval. Si configurásemos Dynamic Threshold Interval con un valor de 1 semana, por defecto se hace recogen los datos de una semana hacia atrás y se hace el cálculo una única vez, repitiéndose el proceso nuevamente una vez transcurrida una semana. Si modificásemos el parámetro dynamic_updates podríamos incrementar esta frecuencia. Por ejemplo configurar el parámetro con un valor de 3 hará que se recalculen los umbrales hasta tres veces durante el periodo de una semana (o el periodo que tengamos configurado en Dynamic Threshold Interval. Su valor por defecto es 5.
  • dynamic_warning: diferencia entre los umbrales warning y critical, en porcentaje. Su valor por defecto es 25.
  • dynamic_constant: determina la desviación de la media que se utilizará para establecer los umbrales, valores mayores harán que los umbrales estén más alejados de los valores promedios. Su valor por defecto es 10.


En el siguiente ejemplo el valor promedio calculado se encuentra a la altura de la línea roja (aprox. 30):


Thresh1.JPG


Al activar los umbrales dinámicos, se ha establecido de este modo el umbral superior (aprox. 45 y superiores):


Thresh2.JPG


Hemos activado el parámetro Dynamic Threshold Two Tailed, de modo que también se ha establecido un umbral crítico por debajo de los valores promedios (aprox. 15 e inferiores):


Thresh3.JPG


Ahora hemos establecido los parámetros Dynamic Threshold Min. y Dynamic Threshold Max. a 20 y 30 respectivamente, por lo que los umbrales se han abierto, siendo ligeramente más permisivos:


Thresh4.JPG


Caso práctico 1

Partimos de un módulo de latencia web. La configuración básica que hemos empleado toma en cuenta un intervalo de una semana:


Dynamic1.JPG


Al guardar cambios, tras ejecutarse pandora_db los umbrales se han establecido de este modo:


Dynamic2.JPG


El módulo por tanto cambiará a estado warning cuando la altencia sea superior a 0'33 segundos, y a critical cuando sea superior a 0'37 segundos. En la gráfica se muestra del siguiente modo:


Dynamic3.JPG


Se ha considerado que el umbral es algo permisivo, por lo que se decide hacer uso del parámetro Dynamic Threshold Min. para reducir los umbrales mínimos. Como en este caso el umbral no tiene valores máximos porque se considerará incorrecto todo lo que sea superior a un determinado valor, no vamos a utilizar Dynamic Threshold Max.. La modificación hecha es así:


Dynamic4.JPG


Tras aplicar cambios y ejecutarse el pandora_db, los umbrales quedan establecidos del siguiente modo:


Dynamic5.JPG


Y la gráfica tendrá este aspecto:


Dynamic6.JPG


Caso práctico 2

En este ejemplo estamos monitorizando la temperatura de una sala de control o un CPD, la gráfica que muestra presenta unos valores con poca variación:


Dynamic7.JPG


En esta situación es fundamental que la temperatura se mantenga estable y no alcance valores muy superiores pero tampoco muy inferiores, por lo que utilizaremos el parámetro Dynamic Threshold Two Tailed para delimitar umbrales tanto por encima como por debajo. La configuración es la siguiente:


Dynamic8.JPG


Los umbrales que se han generado automáticamente han sido estos:


Dynamic9.JPG


La gráfica los muestra de este modo:


Dynamic10.JPG


De este modo se considerará normal todos los valores que se encuentre en tre 23'10 y 26, ya que es la temperatura aceptable en nuestro CPD o sala de control. De necesitarlo podríamos de nuevo utilizar los parámetros Dynamic Threshold Min. y Dynamic Threshold Max. para ajustar los umbrales si fuese necesario.

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