Pandora: Documentation es: Anexo Volumetría

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

1 Estudios volumétricos en Pandora FMS

1.1 Introducción

Pandora FMS es una aplicación distribuida bastante compleja que tiene diferentes elementos clave, susceptibles de representar un cuello de botella si no se dimensiona y configura correctamente, el propósito de este capítulo es ayudar a realizar un estudio propio de capacidad, para analizar la escalabilidad de Pandora FMS en función de una serie específica de parámetros. Este estudio nos ayudará conocer los requisitos que debería tener la instalación para poder soportar determinada capacidad.

Las pruebas de carga sirven también para observar la capacidad máxima por servidor. En el modelo de arquitectura actual (v3.0 o superior), con N servidores independientes y una Metaconsola, esta escalabilidad tiende a ser de orden lineal, mientras que la escalabilidad basada en modelos centralizados no lo es (sería del tipo mostrado en la siguiente gráfica)



Estudio vol0.png

1.1.1 Almacenamiento de datos y compactación

El hecho de que Pandora compacte datos en tiempo real, es muy relevante de cada a calcular el tamaño que van a ocupar. Se realizó un estudio inicial que relacionaba la forma de almacenar los datos un sistema clásico con la forma “asíncrona” de almacenar los datos de Pandora FMS. Esto se puede ver en el esquema que hay incluido en este capítulo.



Estudio vol01.png

En un sistema convencional

Para un chequeo, con una media de 20 chequeos al día, tenemos un total de 5MB al año en espacio ocupado. Para 50 chequeos por agente, esto es 250MB por año.

En un sistema no convencional, asíncrono o con compactación, como Pandora FMS

Para un chequeo, con una media de 0.1 variaciones al día, tenemos un total de 12,3KB al año en espacio ocupado. Para 50 chequeos por agente, esto es 615 KB por año.

1.1.2 Terminología específica

Se describe a continuación un glosario de términos específicos para este estudio, para mejor comprensión del lector.


  • Fragmentación de la información: La información que maneja Pandora FMS puede tener diferente comportamiento: cambiar constantemente (como p.e un medidor de porcentaje de CPU), o ser muy estática (como por ejemplo, determinar el estado de un servicio). Dado que Pandora FMS aprovecha esto para “compactar” la información en la BD, es un factor crítico para el rendimiento y el estudio de capacidad, ya que a más fragmentación, más tamaño en la BD y más capacidad de proceso será necesario emplear para procesar la misma información.
  • Módulo: Es la pieza básica de información recolectada para su monitorización. En algunos entornos se le conoce como Evento, en otros como monitor y en otros como métrica.
  • Intervalo: Es la cantidad de tiempo que transcurre entre recogidas de información de un módulo. Generalmente se expresa en minutos o segundos. El intermedio "medio" suele ser de 5 minutos.
  • Alerta: Se conoce así a la notificación que ejecuta Pandora FMS cuando un dato se sale de unos márgenes establecidos o cambia de estado a CRITICAL o WARNING.

1.2 Ejemplo de estudio de capacidad

1.2.1 Definición del alcance

El estudio se ha hecho pensando en una implantación dividida en tres fases principales:

  • Fase 1: Despliegue de 500 agentes.
  • Fase 2: Despliegue de 3000 agentes.
  • Fase 3: Despliegue de 6000 agentes.

Para determinar con exactitud los requisitos de Pandora FMS en implantaciones de este volumen de datos hay que conocer muy bien que tipo de monitorización se va a realizar, con la mayor exactitud posible. Para el siguiente estudio se ha tenido en cuenta de forma específica las características del entorno de un cliente ficticio llamado "QUASAR TECNOLOGIES" que se pueden resumir en los siguientes puntos:

  • Monitorización basada al 90% en agentes software.
  • Sistemas homogéneos con una serie de catacterizaciones agrupadas en tecnologías / políticas.
  • Intervalos muy variables entre los diferentes módulos / eventos a monitorizar.
  • Gran cantidad de información asíncrona (eventos, elementos en logs).
  • Mucha información de estado de procesos con muy poca probabilidad de cambio.
  • Poca información de rendimiento respecto del total.

Después de hacer un estudio exhaustivo de todas las tecnologías y determinar el alcance de la implentación (identificando los sistemas y sus perfiles de monitorización), hemos llegado a las siguientes conclusiones:

  • Existe una media de 40 módulos / eventos por máquina.
  • El intervalo medio de monitorización es de 1200 segundos (20 min).
  • Existiendo módulos que reportan información cada 5 minutos y módulos que reportan información una vez a la semana.
  • De todo el conjunto de módulos totales (240,000) se ha determinado que la probabilidad de cambio de cada evento para cada muestra, es del 25%.
  • Se ha determinado que la tasa de alertas por módulo es del 1,3 (es decir 1,3 alertas por módulo/evento).
  • Se estima (en este caso es una estimación basada en nuestra experiencia), que la probabilidad de disparo de una alerta, es del 1%.

Estas conclusiones sirven como base para preparar la estimación, y se codifican en la hoja excel utilizada para hacer el estudio:



Estudio vol1.png

Con estos datos de partida, y aplicando los cálculos necesarios podemos estimar tamaño en BBDD, nº de modulos por segundo que es necesario procesar y otros parámetros esenciales:



Estudio vol2.png


1.2.2 Medida de capacidad

Una vez conocidos los requisitos básicos para la implantación en cada fase (Tasa de modulos / segundo), nº de alertas totales, módulos por dia, y MB/mes, se va a realizar una prueba de stress real sobre un servidor relativamente similar a los sistemas de producción (no se ha podido hacer el test en una máquina similar a las de producción).

Éstas pruebas de stress, nos dirán que capacidad de proceso tiene Pandora FMS en un servidor y cual es su nivel de degradación con el tiempo. Esto nos tiene que servir para los siguientes objetivos:

  1. Por medio de una extrapolación, saber si el volumen final del proyecto será asumible con el hardware provisto a tal efecto.
  2. Saber cuales son los límites de almacenamiento “online” y cuales deben ser los puntos de corte a partir de los cuales se mueva la información a las bases de datos de histórico.
  3. Conocer los márgenes de respuesta ante picos de proceso, derivados de problemas que puedan surgir (parada de servicio, paradas planificadas) donde se acumule la información pendiente de procesar.
  4. Conocer el impacto en el rendimiento derivado de la diferente calidad (% de cambio) de la información de monitorización.
  5. Conocer el impacto del proceso de alertas en grandes volúmenes.

Las pruebas realizadas, han sido sobre un servidor DELL PowerEdge T100 con procesador Intel Core Duo 2,4Ghz y 2 GB de RAM. Este servidor, funcionando sobre un Ubuntu Server 8.04, ha proporcionado la base de nuestro estudio para las pruebas en entornos de Alta Capacidad. Las pruebas se han realizado sobre configuraciones de agente relativamente similares a las del proyecto de QUASAR TECNOLOGIES. La intención de las pruebas no es replicar exactamente el mismo volumen de información que va a tener QUASAR TECNOLOGIES, ya que no podemos disponer del mismo hardware, sino replicar un entorno de alta capacidad, similar al de QUASAR TECNOLOGIES para evaluar el impacto en el rendimiento a lo largo del tiempo y determinar otros problemas (principalmente de usabilidad) derivados de manejar grandes volúmenes de datos.



Estudio vol3.png

Los resultados obtenidos son muy positivos, ya que el sistema, aunque muy sobrecargado, era capaz de procesar un volumen de información muy considerable (180,000 modulos, 6000 agentes, 120,000 alertas). Las conclusiones derivadas de este estudio son las siguientes:

  1. Se debe mover la informacion de “tiempo real” a la base de datos de histórico en un plazo máximo de 15 dias, siendo lo óptimo hacerlo para datos de más de una semana. Esto garantiza una operación más rápida.
  2. El margen de maniobra en el caso óptimo es de casi de un 50% de capacidad de proceso, mas alto de lo esperado teniendo en cuenta este volumen de información.
  3. La tasa de fragmentación de la información es clave para determinar el rendimiento y la capacidad necesaria para el entorno donde queramos implantar el sistema.

1.3 Metodología detallada

Si bien el punto anterior representaba un estudio "rapido" basado unicamente en modulos de tipo "dataserver", en este capitulo se presenta una forma mas completa de hacer un analisis de la capacidad de Pandora FMS.

Como punto de partida, en todos los casos utilizaremos siempre la filosofía de "el peor de los casos" siempre que se pueda escoger. Se asume que si no se puede escoger, será la filosofia "el caso habitual". Nunca se estimará nada en el "mejor de los casos" ya que no es válida.

A continuación veremos como calcular la capacidad del sistema, por tipo de monitorización o en base al origen de la información.

1.3.1 Servidor de datos

En base a unos objetivos, calculados tal como vimos en el punto anterior, supondremos que el objetivo estimado, es ver como se comporta con una carga de 100,000 modulos, repartido entre un total de 3000 agentes, esto es una media de 33 modulos por agente.

Se creará una tarea (ejecutada mediante cron o script manual) de pandora_xmlstress que contenga 33 modulos, repartidos con una configuración similar a esta:

  • 1 modulos de tipo cadena.
  • 17 modulos de tipo generic_proc.
  • 15 modulos de tipo generic_data.

Configuraremos los umbrales de los 17 modulos de tipo generic_proc de esta manera:

module_begin
module_name Process Status X
module_type generic_proc
module_description Status of my super-important daemon / service / process
module_exec type=RANDOM;variation=1;min=0;max=100
module_end

En los 15 modulos de tipo generic_data deberemos establecer umbrales. El procedimiento a seguir será el siguiente:

Configuraremos los umbrales de los 15 modulos de tipo generic_data de forma que genere datos de tipo:

module_exec type=SCATTER;prob=20;avg=10;min=0;max=100

Configuraremos los umbrales para esos 15 modulos, de forma que tengan este patrón:

0-50 normal
50-74 warning
75- critical

Añadiremos al fichero de configuracion de nuestro pandora_xml_stress unos tokens nuevos, para poder definir los umbrales ya desde la generacion del XML. OJO; porque Pandora FMS solo "adopta" la definicion de umbrales en la creacion del modulo, pero no en la actualización con datos nuevos.

module_min_critical 75
module_min_warning 50

Ejecutaremos el pandora xml stress.

Debemos dejarlo corriendo al menos 48 horas sin ningun tipo de interrupcion y debemos monitorizar (con un agente de pandora) los siguientes parámetros:

nº de paquetes encolados:

 find /var/spool/pandora/data_in | wc -l

CPU de pandora_server

 ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $3}'

Memoria total de pandora_server

  ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $4}'

CPU de mysqld (revisar sintaxis de la ejecucion, depende de la distro de mysql)

 ps aux | grep "sbin/mysqld" | grep -v grep | awk '{print $3}'

Tiempo medio de respuesta de la BBDD de pandora:

 /usr/share/pandora_server/util/pandora_database_check.pl /etc/pandora/pandora_server.conf
Nº de monitores en unknown

 echo "select SUM(unknown_count) FROM tagente;" | mysql -u pandora -pxxxxxx -D pandora | tail -1

(poner donde pone xxx la password de la bbdd "pandora" para usarla con el usuario "pandora")

Las primeras ejecuciones tienen que servirnos para "tunear" el servidor y la configuracion de MySQL.

Utilizaremos el script /usr/share/pandora_server/util/pandora_count.sh para contar (cuando haya xml pendientes de procesar) la tasa de procesamiento de paquetes. El objetivo es lograr que se puedan "procesar" todos los paquetes generados (3000) en un intervalo inferior al 80% del tiempo limite (5 minutos). Esto implica que se tienen que procesar 3000 paquetes en 4 minutos, luego:

3000 / (4x60) = 12,5

Tenemos que lograr una tasa de procesamiento de 12,5 paquetes como minimo para estar razonablemente seguros de que pandora puede procesar esa información.

Recordatorio de cosas a tocar: nº de hilos, nº maximo de elementos en cola intermedia (max_queue_files), y por supuesto todos los parámetros pertinentes de MySQL (importantísimo).

Solo un comentario acerca de la importancia de esto: un Pandora con un servidor Linux instalado "por defecto" en una maquina potente, puede no pasar de 5-6 paquetes por segundo, en una máquina potente bien "optimizada" y "tuneada" puede llegar perfectamente a 30-40 paquetes por segundo. Tambien depende mucho de la cantidad de modulos que haya en cada agente.

Se configura el sistema para que el script de mantenimiento de bbdd en /usr/share/pandora_server/util/pandora_db.pl se ejecute cada hora en vez de cada dia:

mv /etc/cron.daily/pandora_db /etc/cron.hourly

Se deja funcionando el sistema, con el generador de paquetes un minimo de 48 horas. Una vez pasado ese tiempo se evaluan los siguientes puntos:

  1. ¿ Está el sistema estable ?, ¿se ha caído?. Si hay problemas, mirar logs y gráficas de las metricas que hemos obtenido (principalmente memoria).
  2. Evaluar la tendencia de tiempo de la métrica "nº de monitores en unknown". No tiene que haber tendencias ni picos importantes. Deberian ser la excepcion. Si se suceden con una regularidad de una hora, es porque hay problemas con la concurrencia del proceso de gestion de bbdd.
  3. Evaluar la métrica "Tiempo medio de respuesta de la BBDD de pandora". No deberia crecer con el tiempo sino mantenerse constante.
  4. Evaluar la métrica "CPU de pandora_server", deberia tener frecuentes picos, pero con una tendencia constante, no creciente.
  5. Evaluar la métrica "CPU del servidor MYSQL", debería permanecer constante con frecuentes picos, pero con una tendencia constante, no creciente.

1.3.1.1 Evaluación del impacto de alertas

Si todo ha ido bien, ahora debemos evaluar el impacto del rendimiento de la ejecucion de alertas. Aplicaremos una alerta a cinco módulos específicos de cada agente (de tipo generic_data), para la condicion CRITICAL. Algo que sea relativamente ligero, como crear un evento o escribir a syslog (pare despreciar el impacto que pudiera tener algo con alta latencia como enviar un mail).

Opcionalmente, podemos crear una alerta de correlacion de eventos, para generar una alerta para cualquier condicion critical de cualquier agente con uno de esos cinco modulos.

Dejamos el sistema 12 horas operando bajo esos criterios y evaluamos el impacto, siguiendo el criterio anterior.

1.3.1.2 Evaluación del purgado / traslado de datos.

Suponiendo que la política de almacenamiento de datos fuera:

  • Borrado de eventos de más de 72 horas.
  • Mover datos a historico de más de 7 dias.

Deberíamos dejar el sistema funcionando "solo" durante al menos 10 dias para evaluar el rendimiento a largo plazo. Puede que vieramos un "pico" sustacial al cabo de 7 dias debido al movimiento de datos a la bbdd de historico. Esa degradación es IMPORTANTE tenerla en cuenta. Si no se puede disponer de tanto tiempo, se puede reproducir (con menos "realismo") cambiando el intervalo de purgado a 2 dias en eventos y 2 dias para mover datos a historico, para evaluar ese impacto.

1.3.2 Servidor de ICMP (Enterprise)

Aqui hablaremos específicamente del servidor de red ICMP. En caso de realizar las pruebas para el servidor de red open, vea el punto correspondiente al servidor de red (genérico).

Suponemos que ya tiene el servidor funcionando y configurado. Pasaremos a explicar algunos parámetros clave para su funcionamiento:

block_size X

Define el numero de "pings" que hará el sistema por cada ejecución. Si la mayoría de pings van a tardar lo mismo, puede subir el numero a un numero considerablemente alto, p.e: 50 o 70.

Si por el contrario el parque te modulos de ping es heterogéneo y están en redes muy diferentes, con tiempos de latencia muy diferentes, no le interesa poner un número alto pues la prueba tardará lo que tarde el más lento, así que puede utilizar un numero relativamente bajo, como 15 o 20.

icmp_threads X 

Evidentemente, cuantos mas hilos tenga, más chequeos podrá ejecutar. Si suma todos los hilos que ejecuta Pandora no deberían llegar a 30-40. No debería usar más de 10 hilos aquí, aunque depende mucho del tipo de hardware y version de Linux que esté usando.

Ahora, debe "crear" un número ficticio de modulos de tipo ping para probar. Asumimos que va a probar un total de 3000 modulos de tipo ping. Para ello, lo mejor es coger un sistema en la red que sea capaz de aguantar todos los pings (un servidor Linux cualquiera valdría).

Utilizando el importador CSV de Pandora (disponible en la version Enteprise), cree una fichero con el siguiente formato:

(Nombre agente, IP,os_id,Interval,Group_id)

Puede usarse este shellscript para generar ese fichero (cambiando la IP de destino y el ID de grupo)

A=3000
while [ $A -gt 0 ]
do 
	echo "AGENT_$A,192.168.50.1,1,300,10" 
	A=`expr $A - 1`
done

Antes de hacer nada, deberemos tener el pandora monitorizado, midiendo las metricas que vimos en el punto anterior: consumo de CPU (pandora y mysql), nº de modulos en unknown y otros monitores interesantes.

Importaremos el CSV para crear 3000 agentes (tardará unos minutos). Luego iremos al primer agente (AGENT_3000) y le crearemos un modulo de tipo PING.

Luego iremos a la herramienta de operaciones masivas y copiaremos ese modulo a los otros 2999 agentes.

Pandora debería empezar a procesar esos modulos. Mediremos con las mismas métricas que el caso anterior y veremos como evoluciona. El objetivo es dejar un sistema operable para el numero de modulos de tipo ICMP requerido sin que ninguno de ellos llegue a estado unknown.

1.3.3 Servidor de SNMP (Enterprise)

Aqui hablaremos específicamente del servidor de red SNMP Enterprise. En caso de realizar las pruebas para el servidor de red open, vea el punto correspondiente al servidor de red (genérico).

Suponemos que ya tiene el servidor funcionando y configurado. Pasaremos a explicar algunos parámetros clave para su funcionamiento:

block_size X

Define el numero de peticiones SNMP que hará el sistema por cada ejecución. Hay que tener en cuenta que el servidor los agrupa por IP de destino, de forma que ese bloque es orientativo. Conviene que no sea muy grande (30-40 maximo). Cuando un elemento del bloque falla, un contador interno hace que lo reintente el servidor enterprise, y si tras X intentos no funciona, se lo pasará al servidor open.

snmp_threads X 

Evidentemente, cuantos mas hilos tenga, más chequeos podrá ejecutar. Si suma todos los hilos que ejecuta Pandora no deberían llegar a 30-40. No debería usar más de 10 hilos aquí, aunque depende mucho del tipo de hardware y version de Linux que esté usando.

El servidor de SNMP Enterprise no soporta versión 3. Esos modulos (v3) serán ejecutuados por la version open.

La forma más rapida de probar es mediante un dispositivo SNMP, aplicando a todos los interfaces, todos los modulos de monitorización "básicos" de serie. Esto se hace mediante la aplicación del SNMP Explorer (Agente -> Modo de administracion -> SNMP Explorer). Identifique las interfaces, y aplica todas las metricas a cada interfaz. En un switch de 24 puertos, esto genera unos 650 modulos.

Si genera otro agente con otro nombre, peor la misma IP; tendrá otros 650 modulos. Otra opción puede ser copiar todos los modulos a una serie de agentes que tengan todos la misma IP de forma que los modulos copiados funcionen atacando al mismo switch.

Otra opción es utilizar un emulador de SNMP, como el Jalasoft SNMP Device Simulator.

El objetivo de este punto es ser capaz de monitorizar de forma constante, un pool de modulos SNMP durante al menos 48 horas, monitorizando la infraestructura, para asegurarse de que el ratio de monitorizacion de mod/seg es constante, y no existen periodos de tiempo donde el servidor produce módulos en estado desconocido. Esta situación se podría dar por:

  • Escasez de recursos (mem, CPU). Se podría ver una tendencia de estas métricas en incremento contínuo, lo cual es una mala señal.
  • Problemas puntuales: reinicio del servidor diario (para rotado de logs), ejecución del mantenimiento programado de base de datos, u otros scripts que se ejecuten en el servidor o el servidor de BBBDD.
  • Problemas de red, derivados de procesos no relacionados (p.e: backup de un servidor en la red) que afecten a la velocidad/disponibilidad de la red.

1.3.4 Servidor de Plugins, Red (open) y HTTP

Aqui aplica el mismo concepto que arriba, pero de forma mas simplificada. Habra que controlar:

  • Nº de hilos.
  • Timeouts (para calcular la incidencia en el peor de los casos).
  • Tiempo medio de chequeo.

Dimensionar con esos datos un conjunto de prueba, y verificar que la capacidad del servidor es constante a lo largo del tiempo.

1.3.5 Recepción de traps

Aqui el supuesto es más sencillo: Partimos que el sistema no va a recibir traps de forma constante, sino que más bien se trata de evaluar la respuesta ante una avalancha de traps, de los cuales, algunos generarán alertas.

Para ello simplemente hay que hacer un script sencillo que genere traps de forma controlada a gran velocidad:

#!/bin/bash
TARGET=192.168.1.1
while [ 1 ]
do
   snmptrap -v 1 -c public $TARGET .1.3.6.1.4.1.2789.2005 192.168.5.2 6 666 1233433 .1.3.6.1.4.1.2789.2005.1 s "$RANDOM"
done

NOTA: Cortarlo con CTRL-C a los pocos segundos, pues generará cientos de traps en pocos segundos.

Una vez montado el entorno hay que validar los siguientes supuestos:

  1. Inyección de traps a una tasa constante (basta con meter un sleep 1 al script anterior dentro del bucle while, para generar 1 trap/seg. Se deja el sistema operando 48hr y se evalúa el impacto en el servidor.
  2. Tormenta de traps. Evaluar el antes, el durante, y la recuperación ante una tormenta de traps.
  3. Efectos del sistema sobre una tabla de traps muy grande (>50,000). Esto incluye el efecto de pasar el mantenimiento de la bbdd.

1.3.6 Eventos

De forma similar a los SNMP, evaluaremos el sistema en dos supuestos:

1. Tasa normal de recepción de eventos. Esto ya se ha probado en el servidor de datos, pues en cada cambia de estado, se genera un evento. 2. Tormenta de generación de eventos. Para ello, forzaremos la generación de eventos via CLI. Utilizando el comando siguiente:

/usr/share/pandora_server/util/pandora_manage.pl /etc/pandora/pandora_server.conf --create_event "Prueba de evento" system Pruebas

Nota: Suponemos que existe un grupo llamado "Pruebas".

Ese comando, usado en un bucle como el usado para generar traps se puede usar para generar decenas de eventos por segundo. Se puede paralelizar en un script con varias instancias para provocar un nº mas alto de inserciones. Esto serviría para simular el comportamiento del sistema ante una tormenta de eventos. De esta forma podríamos probar el sistema, antes, durante y después de una tormenta de eventos.

1.3.7 Concurrencia de usuarios

Para ello usaremos otro servidor independiente de Pandora, utilizando la funcionalidad de monitorización WEB. Realizaremos una sesión de usuario donde realizaremos las siguientes tareas en este orden, y mediremos lo que tardan.

  1. Login en la consola.
  2. Ver eventos.
  3. Ir a la vista de grupo.
  4. Ir a la vista de detalle de agente
  5. Visualizar un informe (en HTML). Dicho informe debería contener un par de gráficas y un par de modulos con informes de tipo SUMA o MEDIA. El intervalo de cada elemento debería ser de una semana o cinco días.
  6. Visualización de una gráfica combinada (24hr).
  7. Generación de informe en PDF (otro informe diferente).

Se realiza esta prueba con al menos tres usuarios diferentes. Se puede paralelizar esa tarea para ejecutarla cada minuto, de forma que si hay 5 tareas (cada uno con su usuario), estaríamos simulando la navegación de cinco usuarios simultáneos. Una vez establecido el entorno, tendremos en cuenta:

  1. . La velocidad media de cada modulo es relevante de cara a identificar "cuellos de botella" relacionados con otras actividades paralelas, como la ejecución de script de mantenimiento, etc.
  2. . Se medirá el impacto de CPU/Memoria en el servidor para cada sesión concurrent.
  3. . Se medirá el impacto de cada sesión de usuario simulada respecto al tiempo medio del resto de sesiones. Es decir, se debería estimar cuantos segundos de demora añade cada sesión extra simultánea.

Volver a Indice de Documentación Pandora FMS