Pandora: Documentation es: Modulos parametros comunes
Volver a Indice de Documentacion Pandora FMS
Contents
1 Parámetros comunes de los módulos
1.1 Datos históricos
Por defecto, Pandora FMS guarda cada valor recogido de cada modulo. Esto, en un sistema con muchos agentes tiene un impacto muy considerable en la BBDD del sistema. Por eso, el sistema le permite escoger que datos necesita almacenar en un histórico y cuales no. Si solo necesita conocer el último valor y le es suficiente con tener un histórico de alertas y/o eventos, desactive el almacenamiento de histórico para los módulos donde no lo necesita, su sistema tendrá mejor rendimiento.
1.2 No generar eventos desconocidos
De forma similar al punto anterior (histórico), los módulos de pandora generan eventos de tipo "desconocido" cuando dejan de recibir datos en un período de tiempo. Para aliviar la carga del servidor, evite que se generen este tipo de eventos si realmente no necesita esa funcionalidad.
1.3 Post procesado
El sistema automáticamente multiplicará por este número el valor obtenido en la monitorización. Es util para normalizar datos, convertirla de unidades u otros usos. Algunas conversiones, por ejemplo:
- Convierte timeticks (SNMP) a días: 0.000000115740741
- Convierte bytes en Metabytes: 0.00000095367432
- Convierte bytes en GigaBytes: 0.00000000093132
- Convierte megabits en megabytes: 0.125
Dispone de algunos valores predefinidos, para un uso más sencillo, como puede ver en la captura anterior. También puede añadir y modificar algunos de los valores por defecto, en la opción de setup visual de la consola.
1.4 Valor Max / Min
A diferencia de los valores de max/min de umbrales, estos, limitan el valor máximo y mínimo posibles "aceptables" para este módulo. Actúan como filtro para evitar introducir datos que pudieran desvirtuar la monitorización. El caso mas sencillo de entender es un supuesto valor porcentual, que debería tener valores mínimos de 0 y máximos de 100. Cualquier otro valor fuera de esos márgenes no tendría sentido.
1.5 Umbral Flip Flop
Un módulo remoto (ya sea un módulo de red, un módulo de plug-in etc.) puede devolver datos poco fiables for diferentes motivos. Por ejemplo, un módulo de ping puede devolver 0 aunque un host esté arriba por problemas de congestión de la red.
Dependiendo de cómo esté configurado Pandora FMS, esto puede desencadenar una serie de eventos no deseados (cambios de estados, disparos de alertas, envío de emails...).
Para solucionar esta situación Pandora FMS dispone de umbrales de FF personalizados para cada módulo. El umbral de FF es el número de veces adicionales que un módulo se ejecutará antes de cambiar su estado (un valor de 0 quiere decir que esta característica está deshabilitada). Sólo si la condición que provoca el cambio de estado se mantiene en todos los reintentos se cambia el estado del módulo.
El intervalo de estas ejecuciones adicionales se puede especificar con el intervalo de FF.
Todo esto se ve mejor con un ejemplo: Supongamos que tenemos un módulo WMI que devuelve la cantidad de espacio en disco libre en megabytes. Configuramos este módulo para que se ponga en estado crítico cuando este valor sea menor que 100. A continuación creamos una alerta que envía un email al administrador de sistemas cuando el módulo está crítico para que éste pueda liberar algo de espacio. Pero, por un bug de software, cada cierto tiempo el valor devuelto es mucho menor que el valor actual. Para solucionar este problema configuramos el umbral de FF del módulo a uno y el intervalo de FF a 30 segundos. Esto quiere decir que la primera vez que el módulo reciba un dato menor que 100, el módulo se volverá a ejecutar pasados 30 segundos, y sólo si sigue siendo menor que 100 se pondrá en estado crítico. De otro modo el módulo continúa su ejecución normal.
Esto funciona bien para módulos síncronos, pero los módulos asíncronos necesitan un parámetro de configuración adicional. Como no envían datos en intervalos regulares, comprobar valores consecutivos puede no resultar muy útil si están muy separados en el tiempo. En este caso, hay que especificar un timeout de FF. Lo que implica que los valores consecutivos deben ocurrir dentro del intervalo de tiempo especificado.
Desde la versión 5.1, se pueden definir umbrales de FF individuales para cada estado, de modo que un módulo puede necesitar dos valores consecutivos para cambiar a estado crítico, pero sólo uno para volver a estado normal.
1.5.1 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: Critico: 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 de 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 | |||||
1.6 Unidad
Sirve para asignar una unidad a los datos del módulo. Es un dato puramente informativo y se mostrará en varias vistas de datos así como gráficas del módulo en cuestión.
1.7 Quiet (Mudo)
Los datos del módulo se siguen almacenando, pero se para la generación de eventos y las alertas. Esto es especialmente relevante cuando a través de las paradas planificadas, dejamos "mudo" un módulo durante un tiempo determinado.
La diferencia del modo "quiet" al modo "desactivado" es que este último no procesa datos y el quiet si, de forma que con quiet seguiremos almacenando datos, pero ignorando su información de estado, y con el modo desactivado (disabled) ignoraremos los datos del todo.
1.8 Critical, Warning y Unknown instructions
Se mostrarán instrucciones cuando el estado del módulo sea crítico. Esto se puede ver en la información extendida del evento.
Además, esta información se puede emplear como parte de una alerta, mediante las macros siguientes (ver en detalle en el capítulo de alertas [1]):
- _alert_critical_instructions_: Instrucciones contenidas en el módulo para un estado CRITICAL.
- _alert_warning_instructions_: Instrucciones contenidas en el módulo para un estado WARNING.
- _alert_unknown_instructions_: Instrucciones contenidas en el módulo para un estado UNKNOWN.
1.9 Grupos de módulos
Los grupos de módulos son agrupaciones de módulos. Permiten hacer filtros y se utilizan en algunas vistas específicas. No deja de ser una manera de agrupar los módulos, útil cuando tenemos un gran volumen de módulos en un mismo agente. Se pueden definir nuevos o modificar los existentes en el menú "Resources -> Module groups" de la configuración.
1.10 Tags
Los 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. Los tags son útiles ya que permiten usarlos como filtros en informes, vistas de eventos e incluso tienen vistas específicas para ellos. La información adicional del 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 click sobre Module tags:
El tag permite definir un nombre, la descripción y una opcionalmente una URL completa (http://somewebpage.com), email o teléfono asociados a este tag. Cabe destacar que se puede asociar uno o varios tags a cada módulo. Para ello primero deben ser creados como se describe anteriormente. Una vez creados 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 los tags disponibles y en la columna de la derecha los tags ya asociados al módulo:
Los tags se pueden utilizar además para otorgar permisos de acceso específicos a un modulo, de forma que un usuario pueda acceder únicamente a un modulo del agente, sin tener acceso al resto de módulos. Esto se ve en la sección de perfilado de usuarios [2]
