Community Comunidad Funcionalidades Tecnología

Mejorando el rendimiento de Pandora FMS

octubre 22, 2014

Mejorando el rendimiento de Pandora FMS

This post is also available in : Inglés

Introducción

El objetivo de este artículo es remarcar los principales cuellos de botella en la ejecución de un sistema tan exigente de recursos como Pandora FMS. Por orden de importancia podríamos destacar los siguientes:

  • CPU
  • Memoria
  • Acceso a disco
  • Rendimiento de BBDD
  • Configuración del servidor de Pandora FMS
  • Estado de la BBDD de Pandora FMS

Vamos a analizar las diferentes técnicas de análisis para detectar problemas en cada uno de estos puntos. La solución a cada problema excede el propósito de este artículo, que pretende únicamente mostrar la forma de identificar el problema, y dar algunas pistas sobre como afrontar su solución.

Procesador y acceso a disco

vmstat
Ejecutaremos el comando “vmstat 1 10”. Generalmente la primera línea debe ser ignorada ya que está afectada por el arranque del propio comando:

vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 10892 105036 404324 2540940 0 0 1 184 2 3 8 1 76 15 0
0 0 10892 104780 404324 2540936 0 0 0 32 557 641 5 2 92 1 0
1 0 10892 103788 404324 2540936 0 0 0 120 335 475 3 0 94 2 0
0 0 10892 103756 404324 2540936 0 0 0 36 361 489 5 0 94 1 0
1 0 10892 103384 404324 2540936 0 0 0 32 378 449 6 1 92 1 0
0 0 10892 103400 404324 2540936 0 0 0 0 465 664 1 0 99 0 0
1 0 10892 103860 404324 2540940 0 0 0 32 1439 1522 8 1 90 1 0
0 1 10892 106264 404324 2540948 0 0 0 112 9086 20506 9 1 87 2 0
0 0 10892 97052 404324 2540948 0 0 0 3704 9543 21045 13 2 77 9 0
0 0 10892 106956 404324 2540948 0 0 0 32 547 752 3 1 95 2 0

Las columnas más importantes son:

  • R: Número de hilos en la cola de ejecución. Son threads ejecutables, pero que no tienen CPU disponible para ejecutarlos.
  • B: Número de procesos bloqueados esperando acceso a E/S.
  • US: Uso de CPU en contexto de usuario (Aplicaciones).
  • SY: Uso de CPU en contexto del sistema (llamadas al sistema).
  • WA: Porcentaje de tiempo “sin uso” real del procesador, en espera forzosa por operaciones de Entrada/Salida.
  • CS: Context Switches, cambios de contexto de la CPU.
  • IN: Interrupciones.

El número en «R» no debe exceder 1-3 hilos por cada procesador. Es decir, un sistema con dos procesadores no debe exceder nunca un valor de 6, esto significaría que hay muchos hilos encolados para su ejecución, es decir, que hay demasiado trabajo pendiente.

Si el número en CS es superior al de IN, suele implicar un problema ya que el kernel tiene que ejecutar muchos cambios de contexto, gastando gran parte de tiempo en dicha operación. Suele ser un problema de sobrecarga del Scheduler del sistema. Esto suele tener como efecto secundario, un incremento en WA.

Utilización de CPU: El balance adecuado de uso de CPU debe ser 70% CPU Usuario, 25-30% CPU Sistema y 0-5% Idle.

mpstat
Este comando sirve para ver la distribución de carga entre las diferentes CPU del sistema. Ejecutaremos el comando “mpstat -P ALL 1”. Generalmente la primera línea debe ser ignorada, como en el caso anterior:

12:17:19 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
12:17:20 all 0,75 0,00 0,00 0,00 0,00 0,00 0,00 0,00 99,25
12:17:20 0 1,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 99,00
12:17:20 1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 100,00
12:17:20 2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 100,00
12:17:20 3 1,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 99,00

12:17:20 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
12:17:21 all 6,00 0,00 0,50 0,00 0,00 0,00 0,00 0,00 93,50
12:17:21 0 7,00 0,00 1,00 0,00 0,00 0,00 0,00 0,00 92,00
12:17:21 1 9,90 0,00 0,99 0,00 0,00 0,00 0,00 0,00 89,11
12:17:21 2 8,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 92,00
12:17:21 3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 100,00

12:17:21 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
12:17:22 all 7,48 0,00 0,25 4,49 0,00 0,00 0,00 0,00 87,78
12:17:22 0 7,07 0,00 1,01 15,15 0,00 0,00 0,00 0,00 76,77
12:17:22 1 5,94 0,00 0,00 0,00 0,00 0,00 0,00 0,00 94,06
12:17:22 2 12,87 0,00 0,99 2,97 0,00 0,00 0,00 0,00 83,17
12:17:22 3 4,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 96,00

12:17:22 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
12:17:23 all 14,50 0,00 1,25 0,75 0,00 0,00 0,00 0,00 83,50
12:17:23 0 23,00 0,00 2,00 3,00 0,00 0,00 0,00 0,00 72,00
12:17:23 1 15,84 0,00 1,98 0,00 0,00 0,00 0,00 0,00 82,18
12:17:23 2 2,97 0,00 0,00 0,00 0,00 0,00 0,00 0,00 97,03
12:17:23 3 16,00 0,00 1,00 0,00 0,00 0,00 0,00 0,00 83,00

Lo normal es que la carga esté balanceada entre los diferentes procesadores. Si no fuera así, tenemos algún tipo de problema relativo a la falta de multiproceso.

El disco es importante analizarlo desde dos puntos de vista, datos del fabricante (para conocer IOPS y tasa de velocidad de escritura real).

Para obtener la información del dispositivo, lo haremos con el comando smartctl:

smartctl –a /dev/sda

Eso nos dará datos del fabricante y modelo. Con estos datos en Google obtendremos una aproximación de los IOPS del modelo y su tasa media de escritura (teórica).

La tasa de velocidad real:

dd if=/dev/urandom of=testfileR bs=8k count=10000; sync;

Optimo serán valores entre 50MB/Sec y 100, valores entre 20-30MB/sec son de dispositivos relativamente modernos. Por debajo de 10MB/Sec es un sistema lento, y por debajo de 5MB/Sec no recomendamos seguir adelante, ya que el rendimiento es muy pobre.

La tasa de escritura no tiene porqué tener una correlación con los IOPS, que tienen mas que ver con la eficiencia a la hora de escribir que con la tasa de escritura, pero suele haber una correlación, discos rápidos en escritura no secuencial suelen tener IOPS altos.

Memoria

vmstat
De nuevo utilizaremos vmstat para obtener algunos datos de memoria del sistema, relativos al uso de Swap y al intercambio de páginas de memoria:

vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 10948 904160 404324 2536700 0 0 1 184 2 3 8 1 76 15 0
0 0 10948 896568 404324 2536696 0 0 0 32 2620 3553 18 6 75 1 0
0 0 10948 898332 404324 2536700 0 0 0 36 329 461 2 0 97 1 0
1 0 10948 898332 404324 2536700 0 0 0 20 440 547 4 0 96 0 0
0 0 10948 898396 404324 2536736 0 0 0 0 270 301 4 0 96 0 0
1 0 10948 898372 404324 2536736 0 0 96 88 844 1495 6 0 93 2 0
0 0 10948 898492 404324 2536736 0 0 80 3644 499 781 6 0 84 10 0
0 0 10948 902860 404324 2536736 0 0 0 24 315 405 2 0 98 0 0
0 1 10948 902724 404324 2536736 0 0 48 52 1651 2942 16 1 81 2 0
0 0 10948 902700 404324 2536736 0 0 0 20 128 172 1 0 99 1 0

SI,SO: Swap In/Out. Cualquier valor diferente de 0 significa que el sistema está tirando de swap. En sistemas estables de producción no debería tirar nunca de SWAP. Si tiene valores diferentes de 0, hay poca memoria en el sistema, por lo que debemos ajustar la configuración de MySQL, Pandora FMS u otros elementos que puedan interferir.

Rendimiento de base de datos

/etc/my.cnf
Existen algunos parámetros que son claves para el rendimiento óptimo de MySQL. Vamos a centrarnos en los más relevantes, para más información, acuda a la documentación de Pandora FMS sobre optimización de MySQL. Vamos a fijarnos especialmente en estos tres:

innodb_io_capacity 75
innodb_flush_log_at_trx_commit 0
innodb_flush_method O_DIRECT

Estos tres parámetros son claves y deben tener valores como los reflejados ahí arriba. El Valor de IO_Capacity debe ser uno u otro en función de su tipo de almacenamiento:

  • Discos 5000 RPM o inferior ~ innodb_io_capacity 75
  • Discos 7200 RPM ~ innodb_io_capacity 100
  • Discos 15000 RPM ~ innodb_io_capacity 180
  • Discos SSD última generacion ~ innodb_io_capacity 240

pandoradb_stress
Esta es una herramienta de diagnóstico que se utiliza para verificar la capacidad de inserción de datos de un Pandora FMS, utilizando los mecanismos de la librería de Pandora FMS (API) para acceder a los datos. Para ello debe realizar varios pasos:

1. Crear un agente vacío.
2. Crear un módulo de tipo ICMP Latency y apuntarlo a 127.0.0.1
3. Esperar a que tenga datos.
4. Apuntar el ID del agente, este ID se obtiene en la URL, en la vista principal del agente, p.e: http://firefly.artica.es/pandora_demo/index.php?sec=estado&sec2=operation/agentes/ver_agente&id_agente=52663
El ID de este agente es el 52663
5.  Editamos el fichero /usr/share/pandora_server/util/pandoradb_stress.pl y donde pone:

$target_agent = -1;

Reemplazaremos el -1 con el ID de nuestro agente.

Ejecutaremos, a continuación el comando:

/usr/share/pandora_server/util/pandora_dbstress.pl /etc/pandora/pandora_server.conf

Pandora DB Stress tool 5.1dev Build 140602 Copyright (c) 2004-2014 ArticaST
This program is OpenSource, licensed under the terms of GPL License version 2.
You can download latest versions and documentation at http://www.pandorafms.org
[*] Working for agent ID 52610
[*] Generating data of 90 days ago
[*] Interval for this workload is 300
[*] Processing module Host Latency
[D] ID_AgenteModulo 341281 Interval 300 ModuleName Host Latency Days 90 Agent 198.27.73.105
-> Current rate: 0.12 modules/sec
-> Current rate: 358.95 modules/sec
-> Current rate: 387.78 modules/sec
-> Current rate: 411.94 modules/sec
-> Current rate: 426.88 modules/sec
-> Current rate: 359.93 modules/sec

Para mayor exactitud de los datos, es recomendable crear un módulo nuevo y borrar el anterior en dicho agente. La herramienta empezará a insertar datos en el módulo de ese agente, simulando datos que posteriormente pueden ser usados para informes o gráficas. Por defecto, la herramienta inserta datos de un mes en todos los módulos de todos los agentes de su instalación, al modificar el parámetro de agente, hacemos que lo haga en el agente que hemos especificado.

El valor medio de un servidor de Pandora FMS, debería estar por encima de los 300 mod/segundo. Esta herramienta se puede utilizar para comprobar la optimización del sistema.

Configuración de Pandora_server

/etc/pandora/pandora_server.conf
La correcta configuración del servidor de Pandora FMS puede incrementar hasta en un 500% el rendimiento del mismo, vamos a realizar algunas sencillas comprobaciones para verificar su correcta parametrización:

  • verbosity 1: Valores más altos se emplean como diagnóstico de problemas, pero un valor mayor de 1 impactará en el rendimiento del sistema.
  • network_timeout X: Siendo el valor por defecto 3, es recomendable bajarlo si se trabaja con redes locales. Un valor alto (p.e: 10) puede provocar fácilmente la aparición de muchos módulos en unknown dado que el servidor tiene que esperar 10 segundos por cada chequeo que falle.
  • server_threshold x: Siendo el valor por defecto 5, en casos de sobrecarga puede ser recomendable subirlo a 10 o 20, pero nunca bajarlo de 3-4 (para casos de servidores con muy poca carga y chequeos con intervalos muy pequeños.
  • server_keepalive 45: Este parámetro se utiliza en entornos con varios servidores de Pandora FMS, para detectar cuando se ha caído un servidor. No debería modificarse.
  • xxxx_checks X: En nº de chequeos que hace el servidor de red (icmp, snmp. Tcp). Por defecto vale 1, en entornos con muchos falsos positivos puede ser necesario incrementarlo a 2 o máximo 3, pero esto puede perjudicar el rendimiento del servidor de red.
  • xxxx_timeout: Similar al caso de network_timeout, incrementar los valores por defecto suele traer como consecuencia una disminución del rendimiento en algunos casos. Bajarlo, puede producir falsos positivos o pérdidas de monitorización.
  • xxxx_threads: El nº total de threads de todas las opciones, sumados, no debería exceder un numero entre 30-40.
  • dataserver_threads: Debe tener valores entre 1 y 5.
  • max_queue_files 500: Su valor no debe modificarse.

/var/log/pandora
Un simple vistazo a ese directorio puede ayudar a detectar problemas. Los logs que contiene no deberían tener tamaños grandes:

[[email protected] pandora]# ls -lah /var/log/pandora/
total 356K
drwxr-xr-x. 2 pandora root 4,0K jul 21 03:17 .
drwxr-xr-x. 13 root root 4,0K jul 20 03:33 ..
-rw-r–r–. 1 root root 983 oct 22 2013 pandora_agent.log
-rw-rw-rw-. 1 root root 32K jul 23 19:33 pandora_server.error
-rw-rw-rw- 1 root root 2,1K jul 21 03:17 pandora_server.error-20140721.gz
-rw-rw-rw- 1 root root 44K jul 23 19:27 pandora_server.log
-rw-rw-rw- 1 root root 65K jun 14 18:17 pandora_server.log.old
-rw-rw-rw- 1 root root 176K jul 23 19:33 pandora_snmptrap.log
-rw-rw-rw- 1 root root 10 jul 23 19:34 pandora_snmptrap.log.index

Un log con un tamaño de mas de 50 MB debería ser rotado o borrado.

BBDD de Pandora FMS

Para ello vamos a ejecutar la herramienta de diagnóstico del sistema de Pandora FMS:

Setup->Diagnostic Info

Debemos fijarnos en los siguientes valores:

    • Table tagent_access. No debería exceder los 250,000 registros.
    • Table tagente_datos. No debería superar los 5-10 millones de registros.
    • Table tagente_datos_string. No debería superar los 2-4 millones.
    • Table tagente_estado. No debería exceder los 100,000 registros.
    • Table tevento. No debería tener más de 250,000 registros.
    • Table tsesion. No debería tener más de 50.000 registros.
    • PandoraDB Last run: Debería ser una fecha no más de 24hr respecto a la actual.

Valores fuera de los umbrales especificados, pueden ser indicativo de un problema, una sobredimensión o un desequilibrio en la configuración del sistema.

icon_contact_us download_it-08
¿Quiere saber más sobre como
optimizar Pandora FMS?
¿Quiere obtener Pandora FMS?

Written by:



Leave a comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.