Introducción a la monitorización

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 web, sin necesidad de la instalación de aplicaciones pesadas, permitiendo la gestión desde cualquier equipo siempre y cuando dicho software sea compatible con HTML5.

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

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 límites.

Agentes Lógicos en Pandora FMS

La monitorización realizada por Pandora FMS se clasifica en Agentes Lógicos. Un Agente Lógico siempre pertenece a un Grupo. Estos Agentes Lógicos equivalen a cada uno de los distintos equipos, dispositivos, webs o aplicaciones que están sometidos a monitorización.

Los Agentes Lógicos definidos en la Consola de Pandora FMS pueden presentar datos locales recogidos mediante un Agente Software, datos remotos recogidos mediante chequeos de red, o ambos tipos de datos. Por ello, cabe destacar la diferencia entre Agentes Lógicos como unidad organizativa en la Consola de Pandora FMS, y Agentes Software como servicios de recolección de datos locales.

Comparación de la monitorización basada en Agentes Software y en Monitorización Remota

Pandora FMS divide de forma sencilla los métodos de monitorización, según la forma de recoger información, en dos grandes grupos:

  • La monitorización basada en agentes consiste en la instalación de un pequeño programa (Agente Software) que permanece en ejecución en el sistema, obteniendo datos de forma local, mediante la ejecución de comandos y/o guiones (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 requieren monitorizar.

Como se puede apreciar, la monitorización basada en Agentes Software 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.

Ambos tipos de agente comparten la misma configuración general y visualización de los datos; la monitorización puede ser de una u otra manera, o también las dos (monitorización mixta).

Configuración de un Agente Lógico en Consola

Interfaz de edición en vista normal

  • Alias: para un correcto funcionamiento de todas las funciones que realiza Pandora FMS con sus agentes y módulos, evite el uso de los siguientes caracteres /, \, |, %, #, & y $ para el nombrado del agente o módulo. Si estos agentes contienen dichos caracteres, pueden crear confusión con el uso de rutas del sistema o ejecución de otros comandos, provocando errores en el servidor.
  • Server: 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.

Interfaz de edición en vista avanzada

vista avanzada

  • Secondary groups: parámetro opcional para que un agente pueda pertenecer a más de un grupo (grupos secundarios).
  • Cascade protection services: para evitar una avalancha de alertas en cascada. 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.
  • Module definition: se pueden seleccionar tres modos de trabajo para la definición de módulos.
    • Learning mode: modo por defecto, si llega un XML con nuevos módulos, se crearán automáticamente; es un comportamiento de aprendizaje.
    • Normal mode: si llega un XML con nuevos módulos, solamente se crearán si están declarados en la Consola previamente.
    • Autodisable mode: es 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.

Visualización del agente

Esta pantalla ofrece gran cantidad de información referente al agente, con la posibilidad de forzar la ejecución de los chequeos remotos y refrescar datos.

En la parte superior muestra un resumen con varios 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.

Lista de módulos (Module name) iniciados pertenecientes al agente y sus respectivos estados (Status).

Por último, veremos los eventos generados del agente:

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: En espera de recepción de datos.
  • Normal: Recibiendo datos con valores comprendidos fuera de los umbrales de advertencia o crítico.
  • Advertencia: Datos comprendidos en ese umbral.
  • Crítico: Datos comprendidos en ese umbral.
  • Desconocido: El módulo ha estado funcionando y ha dejado de recibir información durante un tiempo determinado.

Los módulos tienen alguno de los varios tipos de datos: el booleano, el numérico o el alfanumérico, entre otros.

Tipos de módulos

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

  • Módulo de datos: Monitorización local con la cual se realizan chequeos sobre el sistema en el que se encuentra el Agente Software. Ejemplos: uso de CPU del dispositivo o la memoria libre del mismo.
  • 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.
  • 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.
  • 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 MS Windows® mediante el protocolo WMI, como por ejemplo obtener la lista de servicios instalados o la carga actual de la CPU.
  • 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.
  • 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 comprobar si una web se encuentra caída o si contiene una palabra concreta.
  • 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.

Monitorización de estados

Cuando monitorizamos obtenemos valores de un sistema, ya sea la memoria utilizada y libre, el porcentaje de uso de CPU, la temperatura de la placa madre, el número de usuarios conectados, la cantidad de pedidos en una WEB de comercio electrónico o cualquier otro valor, generalmente numérico. A veces solo nos interesa el dato como tal, el “valor absoluto”, sin embargo es más útil el “valor relativo”: asociar un ESTADO a esos valores de forma que al superar un “UMBRAL” cambie de estado para saber si algo está bien, está mal o va para 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 haya recogido. 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. y 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 todo valor mayor al límite inferior ocasionará el cambio de estado.
  • Critical status - Min. y Max.: igual al punto anterior, solo que para el estado critical.
  • 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. También funciona para módulos alfanuméricos (string); si las cadenas de texto no coinciden con lo especificado ya sea en Warning status- Str. o Critical status - Str., el módulo cambiará de estado; ver siguiente figura.

Warning threshold

  • 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 - Str.: igual al ítem anterior, solo que para el estado critical.

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

Umbrales numéricos - Caso práctico 1

Al crear un módulo los umbrales tiene por defecto valor cero, para monitorizar el porcentaje de uso de CPU necesitamos que pase a estado warning (color amarillo) cuando llegue al 70% de uso, y a estado critical (rojo) al alcanzar el 90%; pues será necesario establecer y fijar estos valores:

Al recibir la métrica de ese ordenador si el dato está por debajo de 70% será verde normal, entre 70% y 89,99% amarillo WARNING y de 90% o más, rojo CRITICAL. Debido al funcionamiento de los umbrales, en casos como este no es necesario establecer los límites superiores. Al establecer 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 solapan (intercambiamos 90 por 70), prevalecerá el umbral CRITICAL sobre WARNING.

Umbrales de texto - Caso práctico 2

Un Módulo puede devolver como dato recabado alguna de las siguientes cadenas de caracteres (string):

  • OK.
  • ERROR connection fail.
  • BUSY too many devices.

Usando expresiones regulares en los campos Str. de los parámetros Warning Status y Critical Status, como indica la figura, podremos definir umbrales de alerta.

Debe tener cuidado porque las expresiones regulares distinguen mayúsculas de minúsculas, son case sensitive.

Con esta configuración el módulo tendrá estado WARNING cuando el dato contenga “BUSY” y su estado será CRITICAL cuando el dato contenga “ERROR”.

Monitorización dinámica (Umbrales dinámicos)

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 a nivel de módulo.

Parámetros posibles

dynamic1.jpg

  • Dynamic Threshold Interval: intervalo de umbral dinámico o cantidad de tiempo que considerará para realizar el cálculo de umbrales. Si elegimos un mes, el sistema tomará todos los datos existentes en el último mes y construirá los umbrales en base a esos datos y se establecerán umbrales con valores por encima de la media.
  • Dynamic Threshold Max.: máximo valor del umbral dinámico crítico, si decidimos establecer un margen de tolerancia (en porcentaje) para ello; 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 Two Tailed: (desmarcado por defecto) son intervalos de umbrales dinámicos, si se activa esta opción el sistema de umbrales dinámicos también establecerá umbrales por debajo de la media.
    • Dynamic Threshold Min.: 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.
Caso práctico 1

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 2

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 queda 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 3

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

dynamic7.jpg

En esta situación es fundamental que la temperatura se mantenga estable dentro de un rango preciso, 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'0 , ya que es la temperatura aceptable en el ambiente ambiente a monitorizar. De necesitarlo, podríamos de nuevo utilizar los parámetros Dynamic Threshold Min. y Dynamic Threshold Max. para ajustar los umbrales.

Parámetros de configuración adicionales

Además en el fichero pandora_server.confse puede establecer:

  • dynamic_updates: este parámetro determina cuántas veces se recalculan los umbrales durante el periodo de tiempo establecido en Dynamic Threshold Interval, su valor por defecto es 5. Si configuramos 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 otra semana. Al modificar el parámetro dynamic_updates podríamos disminuir esta frecuencia, ej. 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).
  • dynamic_warning: diferencia, en porcentaje, entre los umbrales warning y critical, valor por defecto 25.
  • dynamic_constant: determina la desviación de la media que se utilizará para establecer los umbrales, valor por defecto 10. Valores mayores harán que los umbrales estén más alejados de los valores promedios.

Parámetros comunes

  • Using module component: al usar un componente de módulo se rellenarán automáticamente con valores de parámetros necesarios para realizar la monitorización, este token aparece en todos los tipos de módulos, salvo en los de predicción.
  • Dynamic Threshold Interval: este intervalo de rango dinámico es un token para la monitorización dinámica que se explicará en una sección posterior.
  • Warning status y Critical status: son 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 frecuentemente entre valores alternativos (MAL/BIEN). 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. FF Threshold se utiliza para “filtrar” los cambios continuos de estado en la generación de eventos/estados: así Pandora FMS “sabe” 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.

Parámetros comunes avanzados

  • Interval: periodo en que el módulo debería devolver datos. Si un módulo pasa más de dos intervalos sin recibir datos, entrará en estado desconocido.
    • Si son módulos remotos: periodo en el cual se realiza el chequeo remoto.
    • Si son módulos de datos: valor numérico que representa X veces el intervalo del agente definido, realizando el chequeo local en ese periodo.
  • Unit: elección de la unidad de los datos recibidos por el módulo, por defecto deshabilitado (none). Valores disponibles:
    • Timeticks.
    • Bytes.
    • Entries.
    • Files.
    • Hits.
    • Sessions.
    • Users.
    • ºC.
    • ºF.
  • Post process: por defecto deshabilitado (0), permite especificar el realizar un posprocesado una conversión del dato recibido por el módulo. Valores disponibles:
    • 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.
  • FF Interval: si está activado el Umbral FlipFlop y ocurre un cambio de estado, el intervalo del módulo se cambiará para la siguiente ejecución.
  • FlipFlop timeout: tiempo de espera solo utilizado en módulos asíncronos. Para que un cambio de estado por FF sea efectivo se tienen que recibir datos consecutivos iguales dentro del intervalo especificado.
  • Silent: el módulo seguirá recibiendo información, pero no se generará ningún tipo de evento ni alerta (modo “silencioso”).
  • 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 de eventos en cascada.

Se puede especificar periodos de tiempo en los cuales se ejecutará el módulo; tiene la nomenclatura: Minuto, Hora, Día del Mes, Mes, Día de la semana y existen tres posibilidades distintas:

  • Cron from tiene establecido por defecto en todos sus campos Any (_Cualquiera_), sin restricción alguna de tiempo para la monitorización.
  • Si Cron from → algún valor específico y Cron to todos en Any: se ejecutará únicamente cuando coincida con el número estipulado. Ej: 15 20 * * *, solo se ejecutará todos los días a las 20:15.
  • Cron from → algún valor específico y Cron to → → algún valor específico: se ejecutará durante el intervalo expuesto. Ej: 5 * * * * y 10 * * * *, se ejecutará cada hora entre los minutos 5 y 10 (esto es equivalente a 5-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_

Ej.

    _technology_
    _modulepriority_
    _contactperson_

Estas macros se pueden utilizar en las alertas de módulos y son especialmente útiles en Monitorización WUX y Monitorización de Usuario . 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 y FORMAT sigue el estándar de strftime de perl.

Tags

Las tags son etiquetas asociadas a cada módulo que luego se propagarán a los eventos que este módulo genere y se podrán usar en las alertas de eventos de este módulo. Son muy útiles ya que permiten usarlos como filtros en informes, vistas de eventos e incluso tienen vistas específicas para ellas. La información adicional de la tag (URL, email, teléfono) se puede emplear en las alertas, ya que están disponibles como macro.

Para poder crear o modificar un tag, hacemos clic sobre Module tags:

La tag permite definir un nombre, la descripción y opcionalmente una URL completa, email o teléfono asociados a esta tag. Cabe destacar que se puede asociar una o varias tags a cada módulo. Para ello, primero deben ser creadas como se describe anteriormente. Una vez creadas estarán disponibles para ser asignados a cada módulo.

Dentro de las opciones avanzadas de un módulo se mostrarán en la columna de la izquierda las tags disponibles y en la columna de la derecha las tags ya asociados al módulo:

Los tags se pueden utilizar, además, para otorgar permisos de acceso específicos a un módulo, de forma que un usuario pueda acceder únicamente a un módulo del agente, sin tener acceso al resto de módulos. Esto se ve en la sección de perfilado de usuarios.

Umbrales numéricos -Caso práctico keep counters

Se conoce por Flip/Flop, FlipFlop, Flip Flop o flip-flop (FF) a un fenómeno usual en monitorización: cuando un valor oscila de forma frecuente entre valores alternativas (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. Esto, en terminología de Pandora FMS, es llamado FF Threshold (Umbral Flip-Flop).

La protección flip flop de un Módulo indica el número de veces que se debe dar la condición de cambio de estado para que se produzca dicho cambio de estado. Esto permite proteger a un Módulo de falsos positivos/negativos. Por ejemplo, si se sabe que un Módulo devuelve falsos positivos pero nunca más de dos veces seguidas, se puede configurar la protección de flip flop a tres para evitar que los falsos positivos produzcan cambios de estado.

En las opciones avanzadas de un Módulo (Advanced options) es posible establecer la protección FF. Por defecto el valor es cambiar todos los estados (Change all statuses) en cero: con el primer valor que supere el umbral warning (advertencia) y/o critical (crítico) cambiará su estado.

Al seleccionar “Cambiar cada estado” (Change each status) permite colocar un valor específico para cada uno de los tres estados para que sea contado con cada intervalo transcurrido del Agente respectivo.

Keep counters – practical case

Transcurridos cuatro intervalos del Agente se reciben los siguientes valores: 50, 80, 95 y 89. Como en 95 se alcanza el estado critical el conteo para warning debería bajar a cero, pero como se especificó “recordar contadores” solo cambiará su estado a warning al alcanzar el valor 89. En la siguiente gráfica, que se obtiene la visitar el Módulo (seleccionando mostrar eventos y refrescando) se puede observar, en intervalos de 30 segundos, cómo se ejecuta el ejemplo en cada intervalo del Agente:

Mantener contadores “Keep counters”

En este ejemplo numérico, se establece un valor para el estado warning cuando supere 75, critical en 90 y además una protección flip-flop de cero para normal y dos para warning y dos para critical, manteniendo los contadores (Keep counters).

Librería de módulos

Disponible a partir de la versión 744. Para acceder a la librería de módulos desde el menú se necesitarán permisos de Agent Read (AR).

Se muestran las nueve categorías más importantes, al pulsar View all categories (“Ver todas las categorías”) encontrará el resto de ellas:

En cada categoría se mostrarán los módulos disponibles con una pequeña descripción que es ampliable al pulsar More details (“Más detalles”).

Nota: los enlaces de descarga de los módulos Enterprise de Pandora FMS solo serán visibles en estos casos:

  • El usuario y la contraseña que configuremos en el setup deben que coincidir con el de soporte de Integria IMS.
  • La versión de Pandora FMS es Enterprise.
  • El usuario de Pandora FMS tiene permiso AW.

Para más información sobre cómo acceder a la librería visite Configuracion de la consola

Volver al Índice de Documentación Pandora FMS