Pandora: Documentation es: Intro Monitorizacion

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

1 Introducción a la monitorización

Toda la interacción del usuario con Pandora FMS se realiza a través de la consola web. La consola permite acceso a través de un navegador, sin necesidad de la instalación de aplicaciones pesadas, permitiendo la gestión desde cualquier equipo con un navegador.

La monitorización consiste en la ejecución de procesos sobre todo tipo de sistemas para recoger y almacenar información, realizar acciones y tomar decisiones en base a dichos datos.

Pandora FMS es un sistema de monitorización escalable que tiene multitud de funcionalidades para extender el alcance y volumen de información recogida, prácticamente sin limites.

2 Agentes en Pandora FMS

La monitorización realizada por Pandora FMS se clasifica en agentes. Un agente siempre pertenece a un grupo. Estos agentes van a equivaler a cada uno de los distintos equipos, dispositivos, webs o aplicaciones que estemos monitorizando.

Los agentes definidos en la consola de Pandora FMS pueden presentar información local recogida mediante un agente software, información remota recogida mediante chequeos de red, o ambas cosas. Por ello, cabe destacar la diferencia entre agentes como unidad organizativa en la consola de Pandora FMS, y agentes software como servicios de recolección de datos locales.




AgentHierarchy.png



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

Podríamos dividir la monitorización en dos grandes grupos, basándonos en la forma de recoger la información: monitorización basada en agentes software y monitorización remota.

La monitorización basada en agentes consiste en la instalación de un pequeño software que permanece corriendo en el sistema y obteniendo información de forma local, mediante la ejecución de comandos y scripts.

La monitorización remota consiste en el uso de la red para ejecutar chequeos remotos hacia los sistemas, sin necesidad de instalar ningún componente adicional en los equipos que se quieren monitorizar.

Como puede apreciarse, la monitorización basada en agentes obtendrá la información mediante chequeos locales, mientras que la monitorización remota obtendrá la información mediante chequeos de red desde el servidor de Pandora FMS.

Con Pandora FMS la monitorización puede ser de una u otra manera y también combinada, produciendo una monitorización mixta.

Ambos tipos de agente comparten la misma configuración general y visualización de los datos.

2.2 Configuración del agente en consola




Configuracion agente consola1.png






Configuracion agente consola2.png



  • Alias: Para un correcto funcionamiento de todas las funciones que realiza Pandora FMS con sus agentes/módulos, se recomienda no usar caracteres del tipo /,\,|,%,#,&,$ en el nombrado del agente. A la hora de tratar estos agentes pueden crear confusión con el uso de rutas del sistema o ejecución de otros comandos, provocando errores en el servidor.
  • Servidor: Servidor que va a ejecutar los chequeos configurados en la monitorización del agente, parámetro especial en caso de tener configurado HA en su instalación.
  • Grupos secundarios: Parámetro opcional para que un agente pueda pertenecer a más de un grupo.
  • Protección en cascada: Parámetro con el cual se puede evitar una avalancha de alertas. Se puede escoger un agente o un módulo de un agente. En el primer caso, cuando el agente escogido se encuentre en crítico, el agente no generará alertas. En el segundo caso, solo cuando el módulo especificado esté en crítico, el agente no generará alertas.
  • Definición de módulos: Se pueden seleccionar tres modos de trabajo.
    • Modo aprendizaje: Si llega un XML con nuevos módulos, se crearán automáticamente (por defecto).
    • Modo normal: Si llega un XML con nuevos módulos, no se crearán a no ser que ya estén declarados en la consola previamente.
    • Modo autodeshabilitado: Igual que el modo de aprendizaje, pero si todos los módulos pasan a desconocido, el agente se deshabilitará hasta que llegue nuevamente información.

2.3 Visualización del agente

En esta pantalla se puede observar una gran cantidad de información referente al agente, y se nos ofrece la posibilidad de poder forzar la ejecución de los chequeos remotos y refrescar los datos que lleguen.




Visualizacion agente consola1.png



En la parte superior podemos ver un resumen con los datos del agente:

  • Total de módulos y estado de los mismos.
  • Eventos en las últimas 24 horas.
  • Información del agente.
    • Nombre.
    • Versión.
    • Accesibilidad del agente.
    • Grupo.
    • ...




Visualizacion agente consola2.png



A continuación podemos observar la lista de módulos pertenecientes al agente, donde no se podrán observar aquellos módulos en estado no iniciado, y debajo las alertas generadas para dichos módulos.




Visualizacion agente consola3.png



Por último, veremos los eventos generados del agente.




Visualizacion agente consola4.png



3 Módulos

Los módulos son unidades de información almacenada dentro de un agente. Son los elementos de monitorización con los cuales se extrae la información del dispositivo o servidor al que apunta el agente. Cada módulo puede almacenar solo un tipo de métrica.

Dentro de un mismo agente no puede haber dos módulos con el mismo nombre. Todos los módulos tienen un estado asociado, que puede ser:

  • No iniciado: donde aún no se han recibido datos.
  • Normal: se están recibiendo datos con valores comprendidos fuera de los umbrales de advertencia o crítico.
  • Advertencia: se están recibiendo datos con valores comprendidos dentro del umbral de advertencia.
  • Crítico: se están recibiendo datos con valores comprendidos dentro del umbral de crítico.
  • Desconocido: el módulo ha estado funcionando y ha dejado de recibir información durante un determinado tiempo.

Los módulos tienen distintos tipos de datos, como son el booleano, el numérico o el alfanumérico. Dependiendo de la información recogida por el módulo, será de un tipo u otro.

3.1 Tipos de módulos

Existen varios tipos de módulo dentro de Pandora FMS.

  • Módulo de datos: se trata de un tipo de módulo de monitorización local con el cual se realizan chequeos sobre el sistema en el que se encuentra el agente, como por ejemplo el uso de CPU del dispositivo o la memoria libre del mismo. Para conocer más acerca de este tipo de módulo visite el siguiente enlace.
  • Módulo de red: se trata de un tipo de módulo de monitorización remota con el cual se hacen chequeos para comprobar la conexión con el dispositivo o servidor al que apunta el agente, como por ejemplo si está funcionando o si tiene un puerto en particular abierto. Para conocer más acerca de este tipo de módulo visite el siguiente enlace.
  • Módulo de plugin: se trata de un tipo de módulo de monitorización local o remota con el cual se pueden realizar chequeos personalizados a través de la creación de scripts. Con ellos se pueden realizar comprobaciones más avanzadas y extensas que las propuestas directamente mediante la consola de Pandora FMS. Para conocer más acerca de este tipo de módulo visite el siguiente enlace.
  • Módulo WMI: se trata de un tipo de módulo de monitorización local con el que se pueden realizar chequeos del sistema de Windows mediante el protocolo WMI, como por ejemplo obtener la lista de servicios instalados o la carga actual de la CPU. Para conocer más acerca de este tipo de módulo visite el siguiente enlace.
  • Módulo de predicción: se trata de un tipo de módulo de monitorización predictiva con el cual se realizan distintas operaciones aritméticas a través de la consulta de datos de otros módulos “base”, como por ejemplo la media de uso de CPU de los servidores monitorizados o la suma de latencia de conexión. Para conocer más acerca de este tipo de módulo visite el siguiente enlace.
  • Módulo de webserver: se trata de un tipo de monitorización web con el cual se realizan comprobaciones del estado de una web y se obtienen datos de ella, como por ejemplo ver si una web se encuentra caída o si contiene una palabra concreta. Para conocer más acerca de este tipo de módulo visite el siguiente enlace.
  • Módulo de análisis web: se trata de un tipo de monitorización web con el cual se realizan simulaciones de navegación web de un usuario, como la navegación a una web, introducción de credenciales o cumplimiento de formularios. Para conocer más acerca de este tipo de módulo visite el siguiente enlace.

3.2 Parámetros comunes

Dentro de la configuración de cada módulo existen parámetros comunes a todos ellos.





Parametros comunes modulos1.png



  • Utilizar módulo de librería: Pandora FMS posee un repertorio de módulos por defecto que pueden ser utilizados. Dependiendo del módulo seleccionado, se rellenarán automáticamente los parámetros necesarios para realizar la monitorización. Este token aparece en todos los tipos de módulos, salvo en los de predicción.
  • Intervalo de rango dinámico: token para la monitorización dinámica que se explicará en una sección posterior.
  • Umbral warning/crítico: token para la monitorización de estados que se explicará en una sección posterior.
  • Umbral Flip-Flop: Se conoce por FlipFlop (FF) a un fenómeno usual en monitorización: cuando un valor oscila de forma frecuente entre valores alternativos (MAL/BIEN) que dificulta su interpretación. Cuando esto ocurre se suele emplear un "umbral", de forma que para considerar que algo ha cambiado de estado tiene que "permanecer" más de X intervalos seguidos en un estado sin alterarse. A esto lo llamamos en terminología de Pandora FMS: 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 FMS 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).

    • Keep counters

Se trata de una opción avanzada del Flip Flop para el control de estado de un módulo. Mediante “keep counters” estableceremos unos valores de contador para pasar de un estado a otro, dependiendo, en lugar del valor, del estado del módulo con el valor recibido.

A continuación se verá con un ejemplo su funcionamiento:

Supongamos que existe un módulo con las siguientes características:

Intervalo: 5 min.
Umbrales:
  Critico: 90 - 100;
  Warning: 80 - 90;

Flip Flop:
   Normal: 0;
   Warning: 3;
   Critical: 2;

Estado actual: Normal;

Y se reciben los siguientes datos/estado:

Dato Estado
81 Warning
83 Warning
95 Crítico
89 Warning
98 Crítico
81 Warning
86 Warning

Como se puede ver en el ejemplo, los datos mostrados pertenecen a estados warning y crítico pero el estado actual es normal porque no se cumplen las condiciones de Flip Flop.

Mediante la configuración del parámetro de “keep counters” se mantendrá un contador de estados, dando como resultado el cambio de estado como podemos ver a continuación:

Dato Estado Dato Estado Módulo
81 Warning Normal
83 Warning Normal
95 Crítico Normal
89 Warning Warning
98 Crítico Warning
81 Warning Warning
86 Warning Warning

Veamos un caso más completo:

Supongamos un módulo con las siguientes características:

Intervalo: 5 min.
Umbrales:
  Crítico: 90 - 100;
  Warning: 80 - 90;

Flip Flop:
   Normal: 2;
   Warning: 3;
   Critical: 2;

Estado actual: Normal;

El contador de estados únicamente acumulará los estados de normal y crítico si estos llegan de manera consecutiva. En cambio, el estado warning podrá acumularse aunque no llegue de manera consecutiva.

El contador de estados se verá reiniciado en los siguientes casos: · Llega un valor cuyo estado coincide con el estado actual. · Se modifica el estado al cumplir con las condiciones del “keep counter”

Los contadores de normal y crítico tienen un comportamiento especial, por el cual se verán reiniciados únicamente estos contadores, si no son consecutivos.

En este caso se reciben los siguientes datos:

Dato Estado Dato Contador crítico Contador warning Contador normal Estado Módulo
81 Warning 0 1 0 Normal
83 Warning 0 2 0 Normal
95 Crítico 1 2 0 Normal
89 Warning 0 0 0 Warning
Al llegar a tres el contador warning, se modifica el estado a warning y se reinician todos los contadores
50 Normal 0 0 1 Warning
98 Crítico 1 0 0 Warning
El contador normal y el contador crítico deben ser consecutivos para seguir incrementando. Al recibir un valor crítico el contador normal pasa a ser 0
91 Crítico 0 0 0 Crítico
Al llegar a dos el contador crítico se modifica el estado a crítico y se reinician todos los contadores
30 Normal 0 0 1/td> Crítico
31 Normal 0 0 0/td> Normal
Al llegar a dos el contador normal se modifica el estado a normal y se reinician todos los contadores
81 Warning 0 1 0/td> Normal
83 Warning 0 2 0/td> Normal
12 Normal 0 0 0/td> Normal
Al recibir un dato en estado normal que es igual al estado actual, se reinician los contadores

Dentro de las opciones avanzadas de los módulos, se pueden observar los siguientes parámetros comunes.




Parametros comunes modulos2.png






Parametros comunes modulos3.png



  • Intervalo: Parámetro donde se define el periodo en que el módulo debería devolver datos. En caso de módulos remotos, se trata del periodo en el cual se realiza el chequeo remoto. En el caso de módulos de datos, se trata de un valor numérico el cual representa X veces el intervalo del agente definido, realizando el chequeo local en ese periodo. Si un módulo pasa más de dos intervalos sin recibir datos, entrará en estado desconocido.
  • Posprocesado: Parámetro por el cual se puede realizar una conversión del dato recibido por el módulo. Por defecto viene deshabilitado con el valor 0. Se pueden realizar las siguientes conversiones:
    • Segundos a meses
    • Segundos a semanas
    • Segundos a días
    • Segundos a minutos
    • Bytes a Gigabytes
    • Bytes a Megabytes
    • Bytes a Kilobytes
    • Timeticks a semanas
    • Timeticks a días
  • Intervalo FF: En caso de tener activado el Umbral de flip-flop y existir un cambio de estado, el intervalo del módulo se cambiará para la siguiente ejecución.
  • FF tiempo de espera: Parámetro que únicamente puede ser utilizado en módulos asíncronos. Para que un cambio de estado por flip-flop sea efectivo se tienen que recibir datos consecutivos iguales dentro del intervalo especificado.
  • Silencioso: Parámetro por el cual el módulo seguirá recibiendo información, pero no se generará ningún tipo de evento ni alerta.
  • Cascade Protection Services: Parámetro por el cual la generación de eventos y alertas pasaría al servicio al que pertenece en caso de estar habilitada esta funcionalidad.
  • Cron: Parámetro por el cual se puede especificar periodos de tiempo en los cuales se ejecutará el módulo con la nomenclatura: Minuto, Hora, Día del Mes, Mes, Día de la semana. Existen tres posibilidades distintas:
    • Cron desde(from): cualquier -> No existen restricciones de monitorización ( por defecto).
    • Cron desde: específico. Cron hasta: cualquiera -> Se ejecutará únicamente cuando coincida con el número estipulado. Ej: 15 20 * * *, se ejecutará todos los días a las 20:15
    • Cron desde: específico. Cron hasta: específico -> Se ejecutará durante el intervalo expuesto. Ej: 5-10 * * * *, se ejecutará cada hora entre los minutos 5 y 10.
  • Macros personalizadas: Se puede definir cualquier número de macros de módulo. El formato recomendado para los nombres de macros es el siguiente:
   _macroname_

Por ejemplo:

   _technology_
   _modulepriority_
   _contactperson_

Estas macros se pueden utilizar en las alertas de módulos. Si el módulo es de tipo análisis de módulo web:

Las macros dinámicas tendrán un formato especial que empieza por @ y tendrán estas posibles sustituciones:

   @DATE_FORMAT (fecha/hora actual con formato definido por el usuario)
   @DATE_FORMAT_nh (horas)
   @DATE_FORMAT_nm (minutos)
   @DATE_FORMAT_nd (días)
   @DATE_FORMAT_ns (segundos)
   @DATE_FORMAT_nM (mes)
   @DATE_FORMAT_nY (años)

Donde “n” puede ser un número sin signo (positivo) o negativo.

3.3 Monitorización de estados

Cuando monitorizamos obtenemos valores de un sistema, sea la memoria, CPU, temperatura del chasis, número de usuarios conectados, de pedidos en una WEB de comercio electrónico o cualquier otro valor numérico. A veces solo nos interesa el dato, pero generalmente querremos asociar un ESTADO a esos valores, de forma que al superar un "UMBRAL" cambie de estado, para saber si algo está bien o está mal. Por eso, cuando hablamos de monitorización, tenemos que introducir el concepto de ESTADO.

Pandora FMS permite definir umbrales para definir el estado que un chequeo tendrá basándose en los datos que muestre. Los tres estados posibles son: NORMAL, WARNING y CRITICAL. Un umbral es un valor a partir del cual pasamos de un estado a otro. El estado que adquirirán los módulos dependerá de estos umbrales, que se especifican mediante los siguientes parámetros presentes en la configuración de cada módulo:

  • Warning status - Min. Max.: límites inferior y superior para el estado warning. Si el valor numérico del módulo se encuentra entre este rango, el módulo pasará a estado warning. Si no se especifica límite superior este será infinito (todo valor superior al límite inferior).
  • Warning status - Str.: expresión regular para módulos de tipo alfanumérico (string). Si se encuentran coincidencias el módulo pasará a estado warning.
  • Critical status - Min. Max.: límites inferior y superior para el estado crítico. Si el valor numérico del módulo se encuentra entre este rango, el módulo pasará a estado critical. Si no se especifica límite superior este será infinito (todo valor superior al límite inferior).
  • Critical status - Str.: expresión regular para módulos tipo alfanumérico (string). Si se encuentran coincidencias el módulo pasará a estado crítico.
  • Inverse interval: presente tanto para el umbral warning como critical. Si se encuentra activado, el módulo cambiará de estado cuando sus valores estén fuera del intervalo especificado en los umbrales. También funciona para módulos alfanuméricos (string); si las cadenas de texto NO coinciden con lo especificado en Warning/Critical Str., el módulo cambiará de estado.


Threshold1.JPG



Threshold2.JPG


Info.png

En caso de que los umbrales warning y critical coincidan en algún rango, siempre prevalecerá el umbral critical.

 


3.3.1 Umbrales numéricos - Caso práctico 1

Tenemos un módulo de porcentaje de uso de CPU que 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 pase a estado warning (color amarillo) cuando llegue al 70% de su uso, y a estado crítico (rojo) cuando llegue al 90%, deberemos configurar los umbrales de la siguiente forma:

  • Warning status Min.: 70
  • Critical status Min.: 90


Threshold3.JPG


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

Debido al funcionamiento de los umbrales, en casos como este no es necesario establecer los límites superiores. Esto es debido a que, si únicamente se establece el umbral inferior, el superior se tendrá en cuenta como "sin límite", por lo que todo valor por encima del umbral inferior será tenido en cuenta como dentro del umbral. Además, si los umbrales se cruzan, prevalecerá el umbral crítico sobre el warning, dando como resultado la gráfica de umbrales que mostrábamos en la captura anterior.

3.3.2 Umbrales de texto - Caso práctico 2

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. En este caso tenemos un módulo que nos puede devolver como dato: OK, ERROR connection fail o bien BUSY too many 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.*


Threshold4.JPG


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. Debe tener cuidado porque las expresiones regulares son case sensitive.

3.3.3 Monitorización dinámica (Umbrales automáticos)

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 son utilizadas 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 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


3.3.3.1 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 latencia 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


3.3.3.2 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 esta manera se considerarán normales todos los valores que se encuentren entre 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. Volver a Indice de Documentacion Pandora FMS