Pandora: Documentation es: Optimizacion

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

Contents

1 Optimización y solución de problemas de Pandora FMS

1.1 Introducción

El servidor de Pandora FMS es capaz de monitorizar unos 2000 dispositivos, para ello es necesario afinar la configuración de la base de datos.

Además en este capítulo se explican algunas técnicas para detectar y solucionar problemas en la instalación de Pandora FMS,

1.2 Optimizando Pandora FMS

1.2.1 Optimización MySQL para enterprise grade systems

1.2.1.1 Consejos generales

Lo primero que se debe hacer si de verdad se desea tener un sistema ENORME con tablas mayores de 2GiB es seguir algunas pautas: MySQL recomienda usar un sistema de 64Bit. Además, se pueden sugerir estas recomendaciones generales: a más memoria RAM, y más CPU, mejor rendimiento. Acorde con nuestra experiencia, la memoria RAM es más importante que la CPU. Si está pensando usar 1GiB o una cantidad inferior de memoria para su sistema SQL, reconsidérelo. El mínimo para un sistema a nivel de empresa será 2GiB. Una buena opción para un gran sistema son 4GiB. Recuerde que más memoria RAM puede acelerar las actualizaciones clave mediante el mantenimiento de las páginas clave más usadas en la RAM.

Otro buen consejo, si no está usando tablas de transacción seguras o tiene discos duros grandes y quiere evitar largas comprobaciones de ficheros, sería usar un UPS. En ese caso, es buena idea ser capaz de retirar el sistema en caso de fallo. Para sistemas donde la base de datos está en un servidor específico, debería echar un vistazo a 1G Ethernet. La latencia es tan importante como el rendimiento.

La optimización del disco es muy importante para bases de datos muy grandes: habrá que partir las bases de datos y las tablas en diferentes discos. En MySQL se pueden usar enlaces simbólicos para ello. Utilice diferentes discos para el sistema y la base de datos, y muy importante: intente usar un disco duro de baja captura, ya que la aplicación se verá comprometida por la velocidad de captura del disco, que aumenta en N log N según obtenga más datos.

Bajo GNU/Linux use hdparm-m16 -d1 en los discos al arrancar para capacitar la lectura y escritura de múltiples sectores en un tiempo dado, así como DMA. Esto podrá aumentar el tiempo de respuesta en 5-50%. Otra buena idea es montar los discos con async (de forma predeterminada) y noatime, este conjunto no actualiza el tiempo de acceso a los ficheros en cada lectura/escritura. Para alguna aplicación específica, se querría tener un disco RAM para algunas tablas muy específicas, esto podría ser una buena opción pero algo arriesgada si se apaga sin guardarlo en un disco no volátil, téngalo en cuenta.

Use --skip-locking (activado de forma predeterminada en algunos sistemas) si es posible. Esto apagará el bloqueo externo y proporcionará un mejor rendimiento.

Si pone en marcha el cliente y el servidor MySQL en la misma máquina, use sockets en lugar de conexiones TCP/IP al conectar con MySQL (esto puede dar una mejora del 7.5%). Puede hacer esto sin especificar el nombre del anfitrión o el localhost al conectar al servidor MySQL. Deshabilite el inicio de sesión binario y la replicación si está lanzando sólo un servidor anfitrión MySQL.

Como aspecto general de cara a evaluar el rendimiento, tenga en cuenta que afecta mucho al rendimiento los siguientes puntos:

  • NO utilice logs binarios si no va a utilizar una configuracion de MySQL con replicación.
  • NO utilice logs de trazabilidad de queries o slowquery logs.
1.2.1.1.1 Versiones de MySQL

Diversas personas han utilizado una version modificada de MySQL (percona) [1] que ofrecen un mayor rendimiento.

Por otro lado, utilizar versiones recientes de MySQL (5.5) respecto a versiones más antiguas de MySQL (5.0.x) pueden ofrecer hasta una diferencia del 20% en rendimiento.

1.2.1.2 Herramientas automáticas de configuración

Existen bastantes herramientas para "optimizar" la configuración del servidor MySQL. Algunas son realmente útiles, por lo menos para echarle un vistazo rápido y ver que no se ha pasado nada por alto.

MySQL Tuning Primer, de Mattew Montgomery, es una herramienta de línea de comando para verificar la configuración de un servidor "en caliente" y ver su rendimiento y posibles mejoras, puede dar algunas pistas y sugerencias para mejorarlo. Está en https://bugs.launchpad.net/mysql-tuning-primer

1.2.1.3 Desactivar replicacion binaria

Por defecto viene habilitada en la mayoria de distros de Linux. Para desactivarla, editar el fichero my.cnf, habitualmente en /etc/my.cnf y comentar las siguientes lineas:

# log-bin=mysql-bin
# binlog_format=mixed

Hay que comentar las dos lineas, y luego reiniciar el servidor.


1.2.1.4 Rendimiento de acceso a disco

Junto con otros parámetros clave, hay dos que son especialmente relevantes en cuando a rendimiento de acceso a disco, que suele ser el cuello de botella respecto a MySQL.

innodb_log_file_size = 64M

Proponemos este valor, que puede ser mayor (incluso 512M) sin perjuicio, excepto para recuperación en caso de problema y por que ocupa más disco. El valor por defecto de MySQL es de 5M que es ridiculamente bajo para entornos de produccion con gran volumen de transacciones.

Para alterar este valor con un sistema ya en funcionamiento primero tenemos que hacer un DUMP completo y borrar los ficheros indices binarios de Innodb (generalmente en /var/lib/mysql/ib*). Cambiar el my.cnf reiniciar el MySQL y cargar el dump de SQL. Dado que el proceso es el mismo que hay que hacer para activar el token innodb_file_per_table (descrito un poco más abajo, recomendamos hacer todo el proceso simultáneamente): cambiar todo el my.cnf, reiniciar y restaurar la BBDD una sola vez.

innodb_io_capacity = xxx

Debemos conocer previamente los IOPS del disco del sistema. Se puede conocer exactamente buscando IOPS y el modelo exacto del disco duro (obtenido via smartctl) o mas o menos a ojo: 7500RPM -> 100 IOPS, 15000 RPM -> 190 IOPS, SSD -> 1500 IOPS

1.2.1.5 Evitando el Flush de disco en cada transaccion

MySQL por defecto establece autocommit = 1 para cada conexión. Lo cual no es tan malo para MyISAM, ya que lo que uno escribe no está garantizada en el disco, pero para InnoDB significa que cada insert / update / delete en una tabla InnoDB se traducirá en una escritura en el disco.

¿Qué tiene de malo que escriba en el disco? Nada en absoluto. Se aseguran de que ante cualquier compromiso se garantiza que el dato esté allí cuando se reinicie la base de datos después de un accidente. El problema es que el funcionamiento de la BBDD está limitado por la velocidad física del disco. Dado que el disco tiene que escribir los datos en un disco antes de la confirmación de la escritura, esto toma su tiempo.

Suponiendo incluso un tiempo medio de búsqueda de 9ms por la escritura en disco, estamos limitados a aproximadamente 67 commits/sec1, esto es muy lento. Y mientras el disco está ocupado tratando de que el sector sea escrito, no está haciendo lecturas. InnoDB puede evitar parte de esta limitación realizando algunas escrituras juntas, pero aún así, la limitación existe.

Podemos evitar que escriba al final de cada transacción, haciendo que ponga un sistema "automático" de escritura, que escribe aproximadamente cada segundo. En caso de fallo, puede que perdamos los datos del último segundo, algo más que asumible si se trata de ganar eficiencia. Para ello, usaremos el siguente token de configuración:


innodb_flush_log_at_trx_commit = 0


Referencia: http://tag1consulting.com/InnoDB_Performance_Tuning

1.2.1.6 Mayor tamaño del KeyBuffer

Dependiendo de la RAM total del sistema, es un parámetro global muy importante que acelera DELETES e INSERT.

key_buffer = 400M

1.2.1.7 Otros buffers importantes

Hay varios buffer que por defecto en algunas distribuciones vienen vacíos. Modificar estos parámetros puede dar un rendimiento muy superior al de por defecto. Es importante asegurarse de que existen estos tokens en el fichero de configuración de MySQL. Estos valores propuestos puede que no sean los óptimos, pero son mucho mejores que no tener nada:

query_cache_size = 64M
query_cache_limit = 2M 
join_buffer_size = 16M

1.2.1.8 Mejorando la concurrencia de innodb

Existe un parámetro que puede afectar bastante al rendimiento del servidor MySQL con Pandora. Este parámetro es innodb_thread_concurrency. Dicho parámetro sirve para especificar cuantos "hilos concurrentes" puede ejecutar MySQL. Una mala configuración de este parámetro puede hacer que vaya mas lento que por defecto, por lo que es especialmente importante prestar atención a varios parámetros.

  • Version de MySQL. En diferentes versiones de MySQL este parámetro se comporta MUY diferente.
  • Número de procesadores reales (fisicos).

Aqui se puede leer la documentacion oficial de MySQL [2].

El valor recomendado es el número de CPU (fisicas) multiplicado por 2 más el nº de discos donde se ubica InnoDB. En las últimas versiones de MySQL (> 5.0.21) el valor por defecto es 8. Un valor 0 significaría que "abra tantos hilos como le sea posible". Por lo tanto, si hay dudas, se puede usar:

innodb_thread_concurrency = 0

Diferentes personas [3] [4] han hecho pruebas, y han detectado problemas con el rendimiento en servidores con muchas CPU físicas cuando se usa un numero muy alto, con versiones de MySQL relativamente antiguas (hablamos de 2008).

1.2.1.9 Usar un espacio de tablas para cada tabla

(Tomado del manual de MySQL en http://dev.mysql.com/doc/refman/5.0/es/multiple-tablespaces.html)

En MySQL 5.0, se puede almacenar cada tabla InnoDB y sus índices en su propio fichero. Esta característica se llama “multiple tablespaces” (espacios de tablas múltiples) porque, en efecto, cada tabla tiene su propio espacio de tablas.

El uso de múltiples espacios de tablas puede ser beneficioso para usuarios que desean mover tablas específicas a discos físicos separados o quienes deseen restaurar respaldos de tablas sin interrumpir el uso de las demás tablas InnoDB.

Se pueden habilitar múltiples espacios de tablas agregando esta línea a la sección [mysqld] de my.cnf:

[mysqld]
innodb_file_per_table

Después de reiniciar el servidor, InnoDB almacenará cada nueva tabla creada en su propio fichero nombre_tabla.ibd en el directorio de la base de datos a la que pertenece la tabla. Esto es similar a lo que hace el motor de almacenamiento MyISAM, pero MyISAM divide la tabla en un fichero de datos tbl_name.MYD y el fichero de índice tbl_name.MYI. Para InnoDB, los datos y los índices se almacenan juntos en el fichero .ibd. El fichero tbl_name.frm se sigue creando como es usual.

Si se quita la línea innodb_file_per_table de my.cnf y se reinicia el servidor, InnoDB creará nuevamente las tablas dentro de los ficheros del espacio de tablas compartido.

innodb_file_per_table afecta solamente la creación de tablas. Si se inicia el servidor con esta opción, las tablas nuevas se crearán empleando ficheros .ibd, pero aún se puede acceder a las tablas existentes en el espacio de tablas compartido. Si se remueve la opción, las nuevas tablas se crearán en el espacio compartido, pero aún se podrá acceder a las tablas creadas en espacios de tablas múltiples.

1.2.1.10 Fragmentación MySQL

Al igual que los filesystems, las bases de datos tambien se fragmentan, haciendo que todo el sistema pierda rendimiento. En un sistema de alto rendimiento, como Pandora FMS es vital que la salud de la BBDD no afecte al funcionamiento del sistema. En sistemas sobrecargados, al final la BBDD puede "rendirse" y bloquearse, resultando una caída de todo el sistema. Una buena configuración de MySQL podría hacer que Pandora FMS trabajase 100 veces mas rápido. Si tienes problemas de rendimiento probablemente será porque no tienes MySQL correctamente configurado o por algún problema relacionado con la base de datos.

1.2.1.10.1 Comprobación del fichero my.ini/cnf

Empezaremos con el fichero my.cnf y su configuración básica para MySQL. La configuracón de su my.cnf debería ser similar a esta(4GB RAM y usando un hardware con una configuración media). Comprueba que tienes todos estos parámetros correctamente introducidos en la sección [mysqld]:

 [mysqld]
 datadir=/var/lib/mysql
 socket=/var/lib/mysql/mysql.sock
 user=mysql
 character-set-server=utf8
 skip-character-set-client-handshake

 key_buffer_Size    = 4M
 max_allowed_packet = 100M
 thread_stack       = 64K
 thread_cache_size  = 8
 max_connections    = 100
 skip-locking

 innodb_file_per_table
 innodb_flush_log_at_trx_commit  = 0
 innodb_flush_method             = O_DIRECT
 innodb_thread_concurrency       = 16
 innodb_buffer_pool_size         = 500M
 innodb_additional_mem_pool_size = 32M
 innodb_log_file_size            = 64M
 innodb_log_buffer_size          = 16M
 innodb_lock_wait_timeout        = 90
 # IO: 100 for 7500RPM disk, 180 for 15K RPM disk, 1500 for SSD disks
 innodb_io_capacity              = 100

 key_buffer_size      = 32M
 read_buffer_size     = 128K
 read_rnd_buffer_size = 128K
 sort_buffer_size     = 128K
 join_buffer_size     = 64M


 # Enable query cache
 query_cache_type        = 1
 query_cache_size        = 8M
 query_cache_limit       = 16M


Cualquier cambio que realices en el fichero my.cnf necesitará reiniciar MySQL. Comprueba al final del fichero /var/log/mysqld.log para ver si ha ocurrido algún error.


1.2.1.10.2 Reconstruir bases de datos

Uno de los "problemas" mas conocidos cuando modificamos el fichero my.cnf es configurar los nuevos valores para los registros de transacciones. Por lo que, si le aparece este error:

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 67108864 bytes!

Restaure la configuración previa, construya un backup de su base de datos y siga los siguientes pasos:

1. Una vez creado el backup, detenga el servicio MySQL

systemctl stop mysql

2. Vaya a la carpeta previa donde se encuentran los ficheros de datos de MySQL (datadir) (por defecto /var/lib/mysql)

cd /var/lib/

3. Mueva la carpeta a otra ubicación (/var/lib/mysql -> /var/lib/mysql_backup)

mv mysql mysql_old

4. Cree una nueva carpeta (/var/lib/mysql)

mkdir mysql

5. Asigne el propietario de la carpeta

chown -R mysql. mysql

6. Inicialice la carpeta con los datos de MySQL

mysql_install_db --datadir=/var/lib/mysql

7. Inicie el servicio

systemctl start mysql

8. Lance el configurador y siga el asistente

mysql_secure_installation

9. Reconstruya sus bases de datos

mysql> create database pandora;

10. Asigne los permisos a los usuarios correctos

mysql> grant all privileges on pandora.* to pandora@'localhost' identified by 'pandora';
mysql> grant all privileges on pandora.* to pandora@'127.0.0.1' identified by 'pandora';

11. Carge los backups

mysql> source /path/to/your/backup.sql


Template warning.png

Muchas veces los sistemas con MySQL/Percona no cargan correctamente los parámetros de configuración del fichero my.cnf (normalmente porque estos valores han sido metidos fuera de la sección de [mysqld]

 



Después de haber configurado el fichero my.cnf y reiniciado, deberá comprobar que estos cambios han sido correctamente aplicados. Para hacer esto usaremos el comando SHOW VARIABLES:

mysql> show variables like 'innodb%';
+-----------------------------------------+------------------------+
| Variable_name                           | Value                  |
+-----------------------------------------+------------------------+
| innodb_adaptive_hash_index              | ON                     |
| innodb_additional_mem_pool_size         | 1048576                |
| innodb_autoextend_increment             | 8                      |
| innodb_autoinc_lock_mode                | 1                      |
| innodb_buffer_pool_size                 | 8388608                |
| innodb_checksums                        | ON                     |
| innodb_commit_concurrency               | 0                      |
| innodb_concurrency_tickets              | 500                    |
| innodb_data_file_path                   | ibdata1:10M:autoextend |
| innodb_data_home_dir                    |                        |
| innodb_doublewrite                      | ON                     |
| innodb_fast_shutdown                    | 1                      |
| innodb_file_io_threads                  | 4                      |
| innodb_file_per_table                   | OFF                    |
| innodb_flush_log_at_trx_commit          | 1                      |
| innodb_flush_method                     |                        |
| innodb_force_recovery                   | 0                      |
| innodb_lock_wait_timeout                | 50                     |
| innodb_locks_unsafe_for_binlog          | OFF                    |
| innodb_log_buffer_size                  | 1048576                |
| innodb_log_file_size                    | 5242880                |
| innodb_log_files_in_group               | 2                      |
| innodb_log_group_home_dir               | ./                     |
| innodb_max_dirty_pages_pct              | 90                     |
| innodb_max_purge_lag                    | 0                      |
| innodb_mirrored_log_groups              | 1                      |
| innodb_open_files                       | 300                    |
| innodb_rollback_on_timeout              | OFF                    |
| innodb_stats_method                     | nulls_equal            |
| innodb_stats_on_metadata                | ON                     |
| innodb_support_xa                       | ON                     |
| innodb_sync_spin_loops                  | 20                     |
| innodb_table_locks                      | ON                     |
| innodb_thread_concurrency               | 8                      |
| innodb_thread_sleep_delay               | 10000                  |
| innodb_use_legacy_cardinality_algorithm | ON                     |
+-----------------------------------------+------------------------+
1.2.1.10.3 Comprobación de que los ficheros de datos aislados para cada tabla están ACTIVADOS
ls -lah /var/lib/mysql/pandora/*.ibd | wc -l

Debería tener mas de 100 ficheros (dependiendo de la versión de Pandora FMS). Cada ".ibd" será el fichero de datos para cada tabla, cuando tiene activado el parámetro "innodb_file_per_table" en el fichero my.cnf. Si no tuviese ninguno de estos ficheros ".ibd" significará que utiliza un único archivo para almacenar toda la información. Esto significará que la fragmentación de las tablas es común al resto de tablas, lo que podría indicar, que el rendimiento será peor cada semana que pase.

Si tiene su base de datos corriendo bajo una única base de datos, necesitará en primer lugar re-crear la base de datos después de haber configurado correctamente el fichero my.cnf y reiniciar MySQL.

1.2.1.10.4 Comprobación de la fragmentación tabla por tabla

Usando el CLI de MySQL, deberá ejecutar esta consulta:

Select ENGINE, TABLE_NAME,Round( DATA_LENGTH/1024/1024) as data_length , round(INDEX_LENGTH/1024/1024)
 as index_length, round(DATA_FREE/ 1024/1024) as data_free, (data_free/(index_length+data_length)) 
 as frag_ratio from information_schema.tables  where  DATA_FREE > 0 order by frag_ratio desc;

Debería ver solamente las tablas con algún indice de fragmentación, por ejemplo:

+--------+-------------------------+-------------+--------------+-----------+------------+
| ENGINE | TABLE_NAME              | data_length | index_length | data_free | frag_ratio |
+--------+-------------------------+-------------+--------------+-----------+------------+
| InnoDB | tserver_export_data     |           0 |            0 |         5 |   320.0000 |
| InnoDB | tagent_module_inventory |           0 |            0 |         6 |    25.6000 |
| InnoDB | tagente_datos_inventory |           4 |            0 |        40 |     9.8842 |
| InnoDB | tsesion_extended        |           1 |            0 |         4 |     3.3684 |
| InnoDB | tagent_access           |           2 |            7 |        27 |     2.9845 |
| InnoDB | tpending_mail           |           2 |            0 |         4 |     2.6392 |
| InnoDB | tagente_modulo          |           2 |            0 |         4 |     2.1333 |
| InnoDB | tgis_data_history       |          24 |           11 |        67 |     1.9075 |
| InnoDB | tsesion                 |           2 |            0 |         4 |     1.7778 |
| InnoDB | tupdate                 |           3 |            0 |         3 |     1.1852 |
| InnoDB | tagente_datos           |         186 |          194 |       399 |     1.0525 |
| InnoDB | tagente_datos_string    |          15 |            9 |        24 |     0.9981 |
| InnoDB | tevento                 |         149 |           62 |        46 |     0.2183 |
| InnoDB | tagente_datos           |        2810 |         2509 |        65 |     0.0122 |
| InnoDB | tagente_datos_string    |         317 |          122 |         5 |     0.0114 |
+--------+-------------------------+-------------+--------------+-----------+------------+

Esta consulta funcionará solamente en las tablas que posean mas de un 10% de fragmentación.

Template warning.png

Las tablas demasiado grandes (como tagente_datos) podrían tardar demasiado tiempo en optimizarse si están muy fragmentadas. Esto podría causar algún tipo de impacto en los sistemas de producción. Por lo que recomendamos no opmitizar este tipo de tablas tan grandes, ya que podría causar un bloqueo del sistema (el proceso de optimización "bloquea" la tabla para reescribirla)

 


Para optimizar la tabla "tagent_module_inventory":

optimize table  tagent_module_inventory;

Aparecerá un mensaje diciéndonos:

"Table does not support optimize, doing recreate + analyze instead".

Ahora, si comprueba de nuevo la fragmentación de las tablas, puede ver que la fragmentación ha desaparecido:

+--------+-------------------------+-------------+--------------+-----------+------------+
| ENGINE | TABLE_NAME              | data_length | index_length | data_free | frag_ratio |
+--------+-------------------------+-------------+--------------+-----------+------------+
| InnoDB | tserver_export_data     |           0 |            0 |         5 |   320.0000 |
| InnoDB | tagente_datos_inventory |           4 |            0 |        40 |     9.8842 |
| InnoDB | tsesion_extended        |           1 |            0 |         4 |     3.3684 |
| InnoDB | tagent_access           |           2 |            7 |        27 |     2.9845 |
| InnoDB | tpending_mail           |           2 |            0 |         4 |     2.6392 |
| InnoDB | tagente_modulo          |           2 |            0 |         4 |     2.1333 |
| InnoDB | tgis_data_history       |          24 |           11 |        67 |     1.9075 |
| InnoDB | tsesion                 |           2 |            0 |         4 |     1.7778 |
| InnoDB | tupdate                 |           3 |            0 |         3 |     1.1852 |
| InnoDB | tagente_datos           |         186 |          194 |       399 |     1.0525 |
| InnoDB | tagente_datos_string    |          15 |            9 |        24 |     0.9981 |
| InnoDB | tevento                 |         149 |           62 |        46 |     0.2183 |
| InnoDB | tagente_datos           |        2810 |         2509 |        65 |     0.0122 |
| InnoDB | tagente_datos_string    |         317 |          122 |         5 |     0.0114 |
+--------+-------------------------+-------------+--------------+-----------+------------+
1.2.1.10.5 Carga del sistema

Ésto es de ámbito general, pero deberemos estar seguros de que el sistema de E/S no es un cuello de botella (discos). Necesitaremos ejecutar el comando "vmstat" para recoger información del sistema:

vmstat 1 10

Ahora, nos fijaremos en las últimas columnas (CPU WA), un valor por encima de 10 significará que tu disco de E/S tiene un problema que deberá ser arreglado. Tener unos valores de CPU US es normal, pero CPU SY no deberá ser mayor de 10-15. En condiciones normales debería tener SWAP si/so a 0, si no, significaría que su sistema esta usando memoria SWAP, considerado como un destructor de rendimiento. Necesitarás incrementar la memoria RAM o decrementar la memoria RAM usada en sus aplicaciones (hilos de Pandora FMS, buffers de MySQL, etc).

Le mostramos la salida de ejemplo de un sistema "normal":

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  46248  78664 154644 576800    0    0     2   147    0    9  7 10 83  0  0	
 0  0  46248  78656 154644 576808    0    0     0     0   49   37  0  0 100  0  0	
 2  0  46248  78904 154648 576740    0    0     0   184  728 2484 63  6 31  0  0	
 0  0  46248  79028 154648 576736    0    0    16   616  363  979 21  0 79  0  0	
 1  0  46248  79028 154648 576736    0    0     0    20   35   37  0  1 98  1  0	
 0  0  46248  79028 154648 576736    0    0     0     0   28   22  0  0 100  0  0	
 1  0  46248  79028 154648 576736    0    0     0  3852  141  303  0  0 98  2  0	
 2  0  46248  78904 154660 576660    0    0     0   188  642 2354 56  4 40  0  0	
 1  0  46248  78904 154660 576680    0    0     0    88  190  634 13  0 86  1  0	
 1  0  46248  78904 154660 576680    0    0     0    16   35   40  0  0 100  0  0	
 1  0  46248  78904 154660 576680    0    0     0     0   26   21  0  0 100  0  0	
 0  0  46248  78904 154660 576680    0    0     0     0   27   27  0  0 100  0  0	
 1  0  46248  78904 154724 576616    0    0   112   192  608 2214 52  4 44  0  0	
 0  0  46248  78904 154724 576616    0    0     0    76  236  771 16  0 84  0  0	
 0  0  46248  78904 154724 576616    0    0     0    20   38   38  0  0 100  0  0	
 0  0  46248  78904 154724 576616    0    0     0     0   31   21  0  0 100  0  0	
 0  0  46248  78904 154740 576608    0    0     0  3192  187  322  1  0 96  3  0	
 1  0  46248  79028 154756 576544    0    0    16   192  632 2087 53  5 42  0  0	
 0  0  46248  79028 154760 576568    0    0     0    56  255  927 19  2 79  0  0	
 0  0  46248  79028 154768 576564    0    0     0    20   33   44  0  0 100  0  0

1.2.1.11 Particionado de tablas MySQL

Para usar Particionado de tablas MySQL, debería usar también el sistema de "multiples tablespaces" descrito arriba (innodb_file_per_table).


MySQL 5.1 soporta particionado de tablas, lo que permite distribuir tablas muy grandes en trozos más pequeños, como subdivisiones lógicas. (Puede consultar el manual de MySQL para más detalles: http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html)

Si tiene grandes cantidades de datos en la base de datos de su Pandora FMS y cree que muchas operaciones de la consola que se refieren a esos datos (por ejemplo drawing graph) son bastante lentas, mejorará su rendimiento utilizando particionado de tablas.

Comprobar en un primer momento que el directorio /var/lib/mysql/pandora_history/*.ibd tiene muchos ficheros (uno por tabla), si no, necesitará hacer un dump de la base de datos, cambiar la configuración del fichero my.cnf, reiniciar MySQL, borrar la base de datos actual y re-crearla desde el dump.

Una vez que te hayas asegurado que innodb_file_per_table está activado, separaremos las dos bases de datos principales en diferentes particiones. Éste es un ejemplo para hacer la partición de todo el 2015 hasta ahora y para futuros meses.

Esta operación necesitará espacio suficiente en el disco para se completada. Habrá que comprobar como es de grande "tagente_datos.ibd". Si por ejemplo ocupa 10gb, necesitarás 15gb de espacio libre para empezar la operación.

Esta operación puede llevarle mucho tiempo, dependiendo del tamaño de la tabla. Por ejemplo, llevaría una hora y media partir una tabla con aproximadamente 7500 modules data para 100 dias (más de 50,000,000 filas).

Para comenzar el procesó deberá ejecutar la siguiente consulta en el CLI de MySQL:


ALTER TABLE tagente_datos PARTITION BY RANGE (utimestamp) (
PARTITION Ene15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-01-01 00:00:00')),
PARTITION Feb15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-02-01 00:00:00')),
PARTITION Mar15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-03-01 00:00:00')),
PARTITION Apr15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-04-01 00:00:00')),
PARTITION May15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-05-01 00:00:00')),
PARTITION Jun15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-06-01 00:00:00')),
PARTITION Jul15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-07-01 00:00:00')),
PARTITION Ago15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-08-01 00:00:00')),
PARTITION Sep15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-09-01 00:00:00')),
PARTITION Oct15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-10-01 00:00:00')),
PARTITION Nov15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-11-01 00:00:00')),
PARTITION Dec15 VALUES LESS THAN (UNIX_TIMESTAMP('2015-12-01 00:00:00')),
PARTITION pActual VALUES LESS THAN (MAXVALUE)
);

Luego habría que ejecutar cada mes la siguiente consulta para reorganizar el particionamiento:

ALTER TABLE tagente_datos REORGANIZE PARTITION pActual INTO (
PARTITION Feb16 VALUES LESS THAN (UNIX_TIMESTAMP('2016-02-01 00:00:00')),
PARTITION pActual VALUES LESS THAN MAXVALUE);

Cambiando "Feb16" por el mes en el que se encuentre.

Recuerde que esta operación podría tardar horas, dependiendo como de grande sea la tabla "tagente_datos". Puede ir comprobando el proceso viendo el tamaño de los archivos de particionamiento ejecutando:

[root@firefly pandora_history]# ls -lah | grep "#sql"
 
 -rw-rw----  1 mysql mysql 424M dic 23 05:58 #sql-76b4_3f7c#P#Ago15.ibd
 -rw-rw----  1 mysql mysql 420M dic 23 05:51 #sql-76b4_3f7c#P#Apr15.ibd
 -rw-rw----  1 mysql mysql 128K dic 23 05:40 #sql-76b4_3f7c#P#Dec15.ibd
 -rw-rw----  1 mysql mysql 840M dic 23 05:44 #sql-76b4_3f7c#P#Ene15.ibd
 -rw-rw----  1 mysql mysql 440M dic 23 05:47 #sql-76b4_3f7c#P#Feb15.ibd
 -rw-rw----  1 mysql mysql  10M dic 23 05:42 #sql-76b4_3f7c#P#Jan16.ibd
 -rw-rw----  1 mysql mysql 404M dic 23 05:56 #sql-76b4_3f7c#P#Jul15.ibd
 -rw-rw----  1 mysql mysql 436M dic 23 05:54 #sql-76b4_3f7c#P#Jun15.ibd
 -rw-rw----  1 mysql mysql 400M dic 23 05:49 #sql-76b4_3f7c#P#Mar15.ibd
 -rw-rw----  1 mysql mysql 408M dic 23 05:52 #sql-76b4_3f7c#P#May15.ibd
 -rw-rw----  1 mysql mysql  72M dic 23 06:03 #sql-76b4_3f7c#P#Nov15.ibd
 -rw-rw----  1 mysql mysql 404M dic 23 06:03 #sql-76b4_3f7c#P#Oct15.ibd
 -rw-rw----  1 mysql mysql 416M dic 23 06:00 #sql-76b4_3f7c#P#Sep15.ibd

1.2.1.12 Reconstruccion de la BBDD

1.2.1.12.1 Reconstruccion parcial

El sistema de gestión de base de datos de MySQL, al igual que otros motores SQL, como Oracle (tm), se degrada con el tiempo por causas como la fragmentación de datos producida por el borrado y la inserción continuada en grandes tablas. En grandes entornos con mucho volumen de tráfico existe una forma muy sencilla de mejorar el rendimiento e impedir que el rendimiento se degrade: reconstruir la BBDD de forma periódica.

Para ello hay que programar una parada de servicio, que puede durar aprox. 1 hr.

En esta parada de servicio, lo que hay que hacer es parar la consola WEB de Pandora FMS, y el servidor (ojo, dejar el servidor tentacle para que siga recibiendo datos, y esos se procesarán tan pronto como el servidor esté operativo de nuevo).

Una vez parados, hacemos un volcado de la BBDD (Export)

mysqldump -u root -p pandora3 > /tmp/pandora3.sql
Enter password:

Borramos la BBDD:

> mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3279346
Server version: 5.0.67-Max SUSE MySQL RPM
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> drop database pandora3;
Query OK, 87 rows affected (1 min 34.37 sec)

Creamos la BBDD y hacemos un import del export anterior:

mysql> create database pandora3;
Query OK, 1 row affected (0.01 sec)
mysql> use pandora3;
mysql> source /tmp/pandora3.sql

Esto puede tardar unos 10-30 minutos en total, algo más si el sistema es grande y el hardware no demasiado portente, para un sistema con 1500 agentes y aproximadamente 100.000 modulos. Se puede automatizar este proceso, pero por su naturaleza delicada, es mejor hacerlo manualmente cada mes o mes y medio.

1.2.1.12.2 Reconstruccion total

Este capítulo solo afecta a bases de datos Innodb. Pandora FMS está construido sobre bases de datos Innodb.

Desgraciadamente MySQL se degrada _mucho_ con el tiempo, cosa que afecta a todo el rendimiento del sistema. No existe otra solucion que no pase por reconstruir todos los esquemas de base de datos desde 0, reconstruyendo el fichero binario de datos que MySQL usa para almacenar toda la informacion y los ficheros usados para reconstruir las transacciones.

Si se mira el directorio /var/lib/mysql se puede ver que hay tres ficheros, que siempre se llaman igual y son, en funcion de lo grave del caso, gigantes. En mi caso de ejemplo:

-rw-rw----  1 mysql mysql 4.8G 2012-01-12 14:00 ibdata1
-rw-rw----  1 mysql mysql 5.0M 2012-01-12 14:00 ib_logfile0
-rw-rw----  1 mysql mysql 5.0M 2012-01-12 14:00 ib_logfile1

El fichero ibdata1 es el que alberga todos los datos Innodb del sistema. En un sistema muy fragmentado, que lleva mucho tiempo sin "rehacer" o sin "reinstalar" este sistema será grande y poco eficiente. El parametro innodb_file_per_table del que hablamos [Pandora_3.0:Documentation_es:Anexo_AjusteMySQL] antes, regula parte de este comportamiento.

Asi mismo, cada base de datos tiene dentro del directorio /var/lib/mysql un directorio para definir su estructura. Deberá borrarlos tambien.

El procedimiento es simple:

  1. Volcar (via mysqldump) todos los esquemas a disco:
 mysqldump -u root -p -A > all.sql
  1. Parar MySQL.
  2. Borrar ibdata1, ib_logfile0, ib_logfile1 y los directorios de bases de datos InnoDB
  3. Levantar MySQL.
  4. Crear la base de datos de pandora de nuevo (create database pandora;)
  5. Importar el fichero de backup (all.sql)
mysql -u root -p
mysql> source all.sql;


El sistema deberia ir ostensiblemente más rapido ahora.

1.2.1.13 Indices opcionales

En algunas situaciones es posible optimizar el funcionamiento de MySQL a costa de recursos del sistema.

Este índice, sirve para optimizar la velocidad de obtención de gráficas a costa de un mayor uso de disco y un ligero descenso en el rendimiento de borrados / inserciones en las tablas de datos:

ALTER TABLE `pandora`.`tagente_datos`  ADD  INDEX  `id_agente_modulo_utimestamp`  (  `id_agente_modulo`  , `utimestamp`  );

1.2.1.14 Queries lentas

En algunos sistemas, en funcion del tipo de informacion que tengamos, podemos encontrarnos con algunas "queries lentas" que hacen que el sistema vaya peor de lo normal. Podemos activar el log de este tipo de consultas durante un periodo CORTO de tiempo (ya que perjudica al rendimiento del sistema) a fin de estudiar las consultas a intentar optimizar las tablas con índices. Para activar este sistema hay que hacer lo siguiente:

Editar my.cnf y añadir las siguientes lineas:

slow_query_log=1
long_query_time=2
slow_query_log_file=/var/log/mysql_slow.log


En la version open:


touch /var/log/mysql_slow.log
chmod 777 /var/log/mysql_slow.log

Reiniciar mysql.

1.2.1.15 Optimización de tablas específicas

Otra solución menos "radical" para paliar el problema de la fragmentación es el uso de la herramienta OPTIMIZE de MYSQL para optimizar ciertas tablas de pandora. Para ello directamente desde MySQL, ejecutar:

OPTIMIZE table tagente_datos;
OPTIMIZE table tagente;
OPTIMIZE table tagente_datos_string;
OPTIMIZE table tagent_access;
OPTIMIZE table tagente_modulo;
OPTIMIZE table tagente_estado;

Eso mejora el rendimiento y no debería ser necesario lanzarlo mas que una vez a la semana, pudiendo hacerse "EN CALIENTE" mientras el sistema trabaja. En sistemas muy grandes el OPTIMIZE puede quedarse "bloqueado" y no ser una alternativa, para eso es mejor reconstruir la BBDD.

Después de hacer estas operaciones, conviene ejecutar:

FLUSH TABLES;

Del manual de MySQL:

For InnoDB tables, OPTIMIZE TABLE is mapped to ALTER TABLE, which rebuilds the table to update index statistics and free unused space in the clustered index.

1.2.1.16 Tokens especiales de MySQL

Existen algunos tokens muy "especiales" de mySQL, que pueden ayudar o empeorar el rendimiento:

# Set to 0 in mysql 5.1.12 or higher
innodb_thread_concurrency            = 20

Este parametro (innodb_thread_concurrency) en version 5.1.12 o superiores, si vale 0 significa que no haya limite a la concurrencia, en versiones inferiores a la señalada, si vale 20 o mas, implica lo mismo: sin limite a la concurrencia.

innodb_flush_method = O_DIRECT

Este parámetro afecta a como se escribe en disco. Pruébelo, en la mayoría de los casos ayuda.

innodb_thread_sleep_delay = 1000
innodb_concurrency_tickets = 250

Afecta a procesos con mucha carga, para "agilizar" como se gestionan las colas y los bloqueos.

innodb_lock_wait_timeout = 180

Evita que ante un atasco ocasional el MySQL "se rinda" (MySQL has gone away) y se pare. Si pasa de 180 segundos, es que es un gran problema.

1.2.1.17 Ejemplo de Configuración

Este ejemplo de configuración utiliza un sistema de ejemplo con 4GB RAM

# Sample configuration for a MySQL with ~3GB RAM dedicated to MySQL Process
# Pandora FMS Recommended setup for a 4GB Server running Database, Server & Console
# Put this in [mysqld] section

bind-address		= 0.0.0.0 
key_buffer		= 500M
max_allowed_packet	= 64M
thread_stack		= 192K
max_connections        = 500
query_cache_size = 128M
query_cache_limit = 2M 
join_buffer_size = 16M
sort_buffer_size  = 16M
join_buffer_size = 32M
read_rnd_buffer_size = 64M

innodb_buffer_pool_size        = 1G
innodb_lock_wait_timeout = 30
innodb_stats_on_metadata = 0
innodb_old_blocks_time = 1000
innodb_file_per_table

# Beware, you cannot change this two following parameters
# in an already running system or the database will be corrupted!
innodb_log_file_size=64M
innodb_log_buffer_size=16M
innodb_io_capacity = 100 # 100 for 7500RPM disk, 180 for 15K RPM disk, 1500 for SSD disks
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT

max_connections                      = 500
back_log                             = 100
log_warnings

# End of recommended configuration

1.2.1.18 Referencias

Referencias:

1.2.2 MySQL Percona XTraDB

Percona es una version "mejorada" de MySQL, sobre todo respecto a la escalabilidad. Aprovecha mucho mejor los sistemas de múltiples CPU's y acelera mucho el acceso a disco.

Para configurar su MySQL percona, utilice este excelente wizard online, que generará su fichero /etc/my.cnf: Percona Wizard Configurator

1.2.3 Dimensionamiento Pandora FMS para alta capacidad

Esta sección describe diferentes métodos para configurar Pandora FMS en un entorno de alta capacidad. Así mismo describe diferentes herramientas para hacer pruebas de carga, útiles para ajustar el entorno a la mayor capacidad de proceso posible.

Se ha configurado Pandora FMS para soportar una carga de alrededor de 2500 agentes en sistemas donde base de datos, consola y servidor están en la misma máquina. La cifra recomendada está en torno a 2500 agentes por sistema, pero esta cifra varía enormemente en funcion de si son agentes XML, modulos remotos, con intervalos altos o bajos, o con sistemas de mucha capacidad o poca memoria, todos factores alteran enormemente el nº de agentes que un sistema puede gestionar eficientemente. En pruebas de laboratorio se han logrado ejecutar 8000 agentes en un solo servidor de gama baja, pero fuertemente optimizado.

1.2.4 Uso de discos RAM (tmpfs) para directorio incoming

En algunos entornos de alta capacidad para el procesado de XML provinientes de agentes, el directorio /var/spool/pandora/data_in tiene un alto tráfico y disponer de este file system en un almacenamiento en memoria puede aumentar el rendimiento de procesado de XML en un 25%.

Para crear una particion en /var/spool/pandora/data_in_RAM, bastaria con el comando:

mount -t tmpfs -o size=100M,nr_inodes=10k,mode=770 tmpfs /var/spool/pandora/data_in_RAM

Se puede programar en /etc/inittab para que esta particion se cree en el arranque. El directorio destino debe existir y estar vacío.

tmpfs /var/spool/pandora/data_in_RAM tmpfs size=100M,nr_inodes=10k,mode=770 0 0

Por supuesto, al estar limitado a 100MB, si se llena el sistema dejará de funcionar propiamente. Si se está trabajando con políticas o configuraciones remotas los directorios que cuelgan generalmente de /data_in (file collections, md5, conf y otros) deberian ubicarse como enlaces a sus rutas reales en disco, suponiendo una estructura basada en los siguientes comandos:

mv /var/spool/pandora/data_in /var/spool/pandora/data_in_old
ln -s /var/spool/pandora/data_in /var/spool/pandora/data_in_RAM
ln -s /var/spool/pandora/data_in_old/md5 /var/spool/pandora/data_in_RAM/md5
ln -s /var/spool/pandora/data_in_old/conf /var/spool/pandora/data_in_RAM/conf
ln -s /var/spool/pandora/data_in_old/collections /var/spool/pandora/data_in_RAM/collections

1.2.5 Múltiples instancias en el mismo sistema

Un caso especial para implementar mayor poder de procesamiento en servidores con multiples procesadores (de dos o más núcleos físicos) consiste en implementar varias instancias de servidores específicos de Pandora en la misma máquina, algo que no tiene que ver con incrementar el nº de hilos del servidor, ya que por diseño del kernel Linux y de la máquina virtual de Perl, se aprovechan mejor los núcleos con multiples procesos que con más hilos dentro del mismo proceso.

Esta técnica se puede emplear cuando Pandora FMS no puede procesar toda la información sin retrasarse demasiado. Esta opción pasa por instalar otro servidor de Pandora FMS con otro directorio de entrada incoming, por supuesto con su propio pandora_server.conf y un nombre de servidor diferente. Habría que hacer modificaciones en el script lanzador del servidor y otras personalizaciones menores al sistema.

1.2.6 Ejemplo de configuracion de servidores de alta capacidad

Suponiendo una maquina CentOS con 16GB de RAM y 8 CPUs que quisieramos optimizar para la máxima capacidad de procesamiento del data server (XML).

1.2.6.1 my.cnf

(Solo se muestran los parámetros más significativos)

# Mysql optimizations for Pandora FMS Example server 12GB RAM
# Please check the documentation in http://pandorafms.com for better results

max_allowed_packet = 64M
innodb_buffer_pool_size = 5G
innodb_lock_wait_timeout = 90
innodb_file_per_table
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_log_file_size = 64M
innodb_log_buffer_size = 16M
innodb_io_capacity = 100
thread_cache_size = 8
thread_stack    = 128K
max_connections = 200

key_buffer_size=4M
read_buffer_size=128K
read_rnd_buffer_size=128K
sort_buffer_size=128K
join_buffer_size=4M

query_cache_type = 1
query_cache_size = 16M
query_cache_limit = 32M

sql_mode=""

1.2.6.2 pandora_server.conf

(Se muestran solo los parámetros relevantes)

verbose 1
server_threshold 15
dataserver_threads 5
max_queue_files 1000

Cosas a tener en cuente:

  • El nº de hilos muy alto (+5) solo beneficia a procesos con largas esperas de E/S, como el network o el plugin server, en el caso del dataserver que es todo tiempo de proceso, pueed incluso penalizar el rendimiento, por eso usamos 5 aqui. En sistemas con una BD lenta, usariamos incluso menos hilos), pruebe diferentes combinaciones entre 1 y 10. En el caso de optimizar el sistema para el newworkserver, el nº seria mucho mas alto, entre 10 y 30.
  • El server threshold alto (15) hace que la BD se resienta menos, mientras que el incremento en el max numero de ficheros procesados hace que cada vez que el servidor "busque ficheros" llene los buffers. Estos dos elementos de la configuracion están intimamente ligados. En el caso de optimizar el network server seria recomendable bajar el server threshold a 5 o a 10.
  • Algunos parámetros de la configuracion pueden afectar mucho al rendimiento de Pandora FMS, como el parametro agent_access (configurable desde la consola).

1.2.7 Herramientas de análisis de capacidad (Capacity)

Pandora FMS dispone de varias herramientas que le ayudarán a dimensionar adecuadamente su hardware y software para el volumen de datos que espera obtener. Una de ellas sirve para "atacar" directamente la base de datos con datos ficticios (dbstress) y la otra genera ficheros XML ficticios (xml_stress)


1.2.7.1 Pandora FMS XML Stress

Este es un pequeño script que genera ficheros de datos XML como los enviados por los agentes de Pandora FMS. Está en /usr/share/pandora_server/util/pandora_xml_stress.pl

Los scripts leen los nombres de los agentes desde un fichero de texto y generan ficheros de datos XML para cada agente acorde con fichero de configuración, donde los módulos están definidos como plantillas.

Los módulos se rellenan con datos al azar. Se pueden especificar el valor inicial y la probabilidad de cambio de los datos de un módulo.

Ejecuta el script de este modo:


./pandora_xml_stress.pl <configuration file>

Ejemplo de configuración de un fichero:

# Maximum number of threads, by default 10.
max_threads 10

# File containing a list of agent names (one per line).
agent_file agent_names.txt

# Directory where XML data files will be placed, by default /tmp.
temporal /var/spool/pandora/data_in

# Pandora FMS XML Stress log file, logs to stdout by default.
log_file pandora_xml_stress.log

# XML version, by default 1.0.
xml_version 1.0

# XML encoding, by default ISO-8859-1.
encoding ISO-8859-1

# Operating system (shared by all agents), by default Linux.
os_name Linux

# Operating system version (shared by all agents), by default 2.6.
os_version 2.6

# Agent interval, by default 300.
agent_interval 300

# Data file generation start date, by default now.
time_from 2009-06-01 00:00:00

# Data file generation end date, by default now.
time_to 2009-06-05 00:00:00

# Delay after generating the first data file for each agent to avoid
# race conditions when auto-creating the agent, by default 2.
startup_delay 2

# Address of the Tentacle server where XML files will be sent (optional).
# server_ip 192.168.50.1

# Port of the Tentacle server, by default 41121.
# server_port 41121

# Module definitions. Similar to pandora_agent.conf.

module_begin
module_name Module 1 
module_type generic_data
module_description A long description.
module_max 100
module_min 10
module_exec type=RANDOM;variation=60;min=20;max=80
module_end

module_begin
module_name Module 2
module_type generic_data
module_description A long description.
module_max 80
module_min 20
module_exec type=SCATTER;prob=1;avg=40;min=0;max=80
module_end


module_begin
module_name Module 3
module_type generic_data
module_description A long description.
module_max 80
module_min 20
module_exec type=CURVE;min=20;max=80;time_wave_length=3600;time_offset=0
module_end

module_begin
module_name Module 4
module_type generic_data_string
module_description A long description.
module_max 100
module_min 10
module_exec type=RANDOM;variation=60;min=20;max=80
module_end

module_begin
module_name Module_5
module_type generic_proc
module_descripcion Module 3 description.
# Initial data.
module_data 1
module_end
1.2.7.1.1 Enviar y recibir la configuración local del agente

Activando en su "pandora_xml_stress.conf" el valor de configuración "get_and_send_agent_conf" a 1 puede hacer que los agentes de prueba de carga se comporten como agentes normales, ya que envían su fichero de configuración y el md5. Y desde Pandora Console Enterprise puede modificar la configuración remota para que en sucesivas ejecuciones del pandora_xml_stress use la configuración personalizada desde Pandora Console Enterprise en vez de a través de la definición de "pandora_xml_stress.conf".

A parte de eso puedes configurar donde guardar de forma local los conf de tus agentes de prueba con el token de configuración "directory_confs" en el fichero "pandora_xml_stress.conf".

1.2.7.1.2 Fichero de configuración
  • max_threads Numero de threads en la que se ejecutara el script, esto mejora la E/S.
  • agent_file Ruta del fichero de lista de nombres, separados por nueva linea.
  • temporal Ruta del directorio donde se generaran los ficheros de datos XML ficticios.
  • log_file Ruta del fichero de log donde informara el script de su ejecución.
  • xml_version Versión del ficheros de datos XML (por defecto 1.0).
  • encoding Codificación de los ficheros de datos XML (por defecto ISO-8859-1).
  • os_name Nombre del sistema operativo de los agentes ficticios (por defecto Linux).
  • os_version Versión del sistema operativo de los agentes ficticios (por defecto 2.6).
  • agent_interval Intervalo de los agentes ficticios en segundos (por defecto 300).
  • time_from Fecha de comienzo a generar los ficheros de datos XML ficticios, en formato "AÑO-MES-DIA HORA:MIN:SEC"
  • time_to Fecha de fin a generar los ficheros de datos XML ficticios, en formato "AÑO-MES-DIA HORA:MIN:SEC"
  • get_and_send_agent_conf Valor booleano 0 o 1, cuando esta activo los agentes ficticios intentaran descargar por configuración remota una versión mas actual del fichero configuración estandar de un agente. Y desde la consola Pandora FMS enterprise puedes editarlos.
  • startup_delay Valor numérico de tiempo en segundos antes de comience cada agente a generar los ficheros, se usa para evitar condiciones de carrera.
  • timezone_offset Valor numérico del offset de time zone.
  • timezone_offset_range Valor numérico que sirve para generar dentro de este rango los timezone de forma aleatoria.
  • latitude_base Valor numérico, es la latitud donde apareceran los agentes ficticios.
  • longitude_base Valor numérico, es la longitud donde apareceran los agentes ficticios.
  • altitude_base Valor numérico, es la altitud donde apareceran los agentes ficticios.
  • position_radius Valor numerico, es el rango alrededor la circunferencia con este radio que aparece el agente ficticio de forma aleatoria.
1.2.7.1.3 Definición de los módulos

La definición de un modulo dentro del fichero de configuración script y si tienes activada la configuración remota también sera igual es:

module_begin
module_name <nombre_del_módulo>
module_type <tipo_de_dato_módulo>
module_description <descripción>
module_exec type=<tipo_generación_xml_stress>;<otras_opciones_separadas_por_punto_y_coma>
module_unit <unidades>
module_min_critical <value>
module_max_critical <value>
module_min_warning <value>
module_max_warning <value>
module_end

Y cada uno lo puedes configurar como:

  • tipo_generación_xml_stress: puede tomar los valores RANDOM , SCATTER, CURVE.
  • module_attenuation <value>: El valor generado se multiplica por el valor dado, normalmente entre 0.1 y 0.9.
  • module_attenuation_wdays <value> <value> ... <value>: El valor del módulo se atenúa únicamente los días dados, que van de domingo (0) a sábado (6). Por ejemplo, el siguiente módulo simula una disminución del 50% en el tráfico de red los sábados y domingos:
module_begin
module_name Network Traffic
module_type generic_data
module_description Incoming network traffic (Kbit/s)
module_exec type=RANDOM;variation=50;min=0;max=1000000
module_unit Kbit/s
module_min_critical 900000
module_attenuation 0.5
module_attenuation_wdays 0 6
module_end
  • module_incremental <value>: Si se configura a uno, el valor previo del módulo se suma siempre a un nuevo valor, lo que da lugar a una función creciente.
  • otras ver más abajo que opciones tiene, en función del tipo de generación del modulo.

Note que los tokens de configuracion min/max_critical y min/max_warning están solo disponibles en la version 5.0 o superior.

1.2.7.1.3.1 Aleatorios (RANDOM)

Los cuales tienen las siguientes opciones:

  • variation probabilidad en % de que varie con respecto al valor anterior.
  • min valor mínimo que puede tener el valor.
  • max valor máximo que puede tener el valor.

Numéricos

Generada valores numericos aleatorios entre el rango valor min y el valor max.


Boleanos

Generada valores entre 0 y 1.


Cadena

Generada una cadena de longitud entre valor min y el valor max, los caracteres son aleatorios entre A y Z incluidas mayusculas y minusculas y cifras numéricas.

1.2.7.1.3.2 Fuente externa de datos (SOURCE)

Permite escoger un archivo de texto plano como fuente de datos. Opciones:

  • src: archivo fuente para los datos.

El archivo contiene un dato por línea, no hay límite de líneas. Por ejemplo:

4
5
6
10

Adminte todo tipo de valores (númericos y cadenas de texto). Este tipo de módulos usará cada unos de los datos del archivo para generar los datos de los módulos en Pandora, los datos se cogen de forma secuencial. Por ejemplo los datos del módulo anterior se verían en Pandora así:

4 5 6 10 4 5 6 10 4 5 6 10 4 5 6 10 4 5 6 10 4 5 6 10
1.2.7.1.3.3 Dispersión (SCATTER)

Solo vale para datos numéricos, y la gráficas generadas son parecidas a las de un latido de corazón, es decir un valor normal y de vez en cuando un "latido".

Y tiene las siguientes opciones:

  • min valor mínimo que puede tener el valor.
  • max valor máximo que puede tener el valor.
  • prob probabilidad en % de que genere un "latido".
  • avg valor medio que debe mostrar por defecto si no hay ningún "latido".
1.2.7.1.3.4 Curva (CURVE)

Genera datos de módulo siguiendo una curva trigonométrica. Los cuales tienen las siguientes opciones:

  • min valor mínimo que puede tener el valor.
  • max valor máximo que puede tener el valor.
  • time_wave_length valor numérico en segundos de la duración de la "cresta" de la onda.
  • time_offset valor numérico en segundos de comienzo de la onda desde el tiempo cero con valor cero del módulo (similar a la gráfica de seno).
Curve module xml stress.v2.png
1.2.7.1.4 Notas de interes
  • Ten encuenta que la cantidad de ficheros generados es la relación entre la fecha de comienzo (time_from) y fecha de final (time_to) y el intervalo seteado en el agente (agent_interval), por lo que a grandes tramos de tiempo o pequeño intervalo el script te va generar muchos ficheros de datos XML.

1.2.7.2 Como medir la capacidad de proceso del dataserver

Existe un pequeño script llamado "pandora_count.sh" que está en el directorio /util en el directorio del servidor de Pandora FMS. Este script se usa para medir la tasa de procesamiento de ficheros XML por el data server, y utiliza como referencia el total de ficheros pendientes de procesar en /var/spool/pandora/data_in de forma que para poder usarlo se necesita tener pendiente de procesar varios miles de paquetes (o generarlos con la herramienta anteriormente mencionada). Este script simplemente cuenta los paquetes existentes ahora y los resta de los paquetes que habia hace 10 segundos, luego divide el resultado por 10 y esos son los fiheros que se han procesado en los ultimos 10 segundos, mostrando la tasa por segundo. Es una medida algo burda pero sirve para ajustar la configuracion del servidor.

1.2.7.3 Pandora FMS DB Stress

Esta es una pequeña herramienta para probar el rendimiento de su base de datos. También se puede usar para «pregenerar» datos periódicos o aleatorios (usando funciones trigonométricas) y rellenar módulos ficticios.

Se debe crear un agente y asignarle módulos para inyección de datos automática con esta herramienta. Los nombres se deben llamar con la notación siguiente:

  • random: para generar datos aleatorios.
  • curve: para generar una curva de coincidencias usando funciones trigonométricas. Útil para ver el trabajo de interpolación con diferentes intervalos, etc.
  • boolean: generar datos booleanos aleatorios.

De tal forma que se podría usar cualquier nombre que contenga las palabras «random», «curve» y/o «boolean», por ejemplo:

  • random_1
  • curve_other

Sólo se podrá elegir el tipo de módulo «data_server».

1.2.7.3.1 Ajuste fino de la herramienta Pandora FMS DB Stress

Esta herramienta está preconfigurada para buscar, en todos los agentes, los módulos de nombre «random», «curve» o «boolean», y que usen un intervalo entre 300 segundos y 30 días.

Si se quiere modificar este comportamiento, se debe editar el script pandora_dbstress y modificar algunas variables al inicio del fichero:

# Configure here target (AGENT_ID for Stress)
my $target_module = -1; # -1 for all modules of that agent
my $target_agent = -1;
my $target_interval = 300;
my $target_days = 30;

La primera línea de variable correspondiente con target_module, se debe establecer para un módulo fijo o -1 para procesar todos los objetivos que coincidan. La segunda línea de variable corresponde con target_agent, para un agente específico. La tercera línea corresponde con target_interval, definida en segundos y que representa el intervalo de periodicidad predeterminada del módulo. La cuarta línea es target_days y representa el número de días en el pasado desde la fecha, en timestamp, actual.

1.3 Solución de problemas y herramientas de Diagnóstico en Pandora FMS

A veces, el usuario tiene problemas y los desarrolladores de Pandora no le pueden ayudar sin tener más información acerca de sus sistemas. En la version 3.0, hemos desarrollado algunas herramientas con el fin de ayudarle a resolver algunos problemas:

1.3.1 pandora_diag.php

Esta es una herramienta de diagnóstico web. Necesita tener una sesión activa para usar este recurso. El recurso proporciona información acerca del uso de la base de datos de Pandora FMS y también sobre los valores de configuración y versión. Esta herramienta es accesible desde su consola usando la siguiente URL:

http://localhost/pandora_console/extras/pandora_diag.php

Si tiene su consola de Pandora FMS en otra URL sólo necesita añadir /extras/pandora_diag.php en su URL home.


Ejemplo de output

Pandora FMS Build	PC090512
Pandora FMS Version	v3.0-dev
Homedir	/var/www/pandora_console
HomeUrl	/pandora_console
tagente	2385
tagent_access	20049
tagente_datos	4342323
tusuario	19
Update Key	PANDORA-FREE
Updating code path	/var/www/pandora_console
Keygen path	/usr/share/pandora/util/keygen
Current Update #	0


Esta herramienta puede lanzarse también desde la línea de comandos, y necesitará pasar la ruta completa a su consola homedir de Pandora FMS, por ejemplo:

php /var/www/pandora_console/extras/pandora_diag.php /var/www/pandora_console

Y la salida de este script será registrada en la salida de la consola estandar.

1.3.2 pandora_diagnostic.sh

Es una herramienta localizada en /usr/share/pandora_server/util y proporciona mucha información acerca del sistema:

  • Información de la CPU
  • Uptime y avgload de la CPU
  • Información sobre la memoria
  • Información sobre Kernel/liberación
  • Un fichero dump de configuración mysql
  • Un fichero dump (filtrando contraseñas) de configuración del servidor de Pandora FMS
  • Los logs de información de Pandora FMS (pero no el log completo!)
  • Información del disco
  • Información sobre procesos de Pandora FMS
  • Una información completa del log del kernel(dmesg).

Toda la información se genera en un fichero .txt, con lo que los usuarios pueden enviar esta información a cualquiera que quiera ayudarles, por ejemplo, en el foro de usuarios de Pandora FMS o en las listas de correo públicas de Pandora FMS. Esta información no deberá contener ningún tipo de información confidencial. Tenga en cuenta que posiblemente usted quiera correr con privilegios de root si quiere obtener los ficherospandora_server.conf ymy.cnf parseados

Este es un ejemplo de ejecución:

$ ./pandora_diagnostic.sh 
 
Pandora FMS Diagnostic Script v1.0 (c) ArticaST 2009
http://pandorafms.org. This script is licensed under GPL2 terms
 
Please wait while this script is collecting data
  
Output file with all information is in '/tmp/pandora_diag.20090601_164511.data'

Y estas son algunas partes de la salida del fichero

Information gathered at 20090601_164511
Linux raz0r 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:27:06 UTC 2009 i686 GNU/Linux
=========================================================================
-----------------------------------------------------------------
CPUINFO
-----------------------------------------------------------------
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
.
.
-----------------------------------------------------------------
Other System Parameters
-----------------------------------------------------------------
Uptime:  16:45:11 up  5:27,  2 users,  load average: 0.11, 0.12, 0.09
-----------------------------------------------------------------
PROC INFO (Pandora)
-----------------------------------------------------------------
slerena  11875  0.9  2.1 114436 44336 pts/0    Sl   13:14   1:56 gedit pandora_diagnostic.sh
slerena  24357  0.0  0.0   4452  1524 pts/0    S+   16:45   0:00 /bin/bash ./pandora_diagnostic.sh
-----------------------------------------------------------------
MySQL Configuration file
-----------------------------------------------------------------
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
.
.
.
-----------------------------------------------------------------
Pandora FMS Logfiles information
-----------------------------------------------------------------
total 3032
drwxr-xrwx  2 root    root       4096 2009-04-30 20:00 .
drwxr-xr-x 17 root    root       4096 2009-06-01 11:24 ..
-rw-r-----  1 root    sys      377322 2009-04-06 00:12 pandora_agent.log
-rw-r--r--  1 root    root          0 2009-04-06 00:15 pandora_agent.log.err
-rw-r--r--  1 root    root      13945 2009-04-02 21:47 pandora_alert.log
-rw-r--r--  1 slerena slerena 2595426 2009-04-30 20:02 pandora_server.error
-rw-rw-rw-  1 root    root       9898 2009-04-30 20:02 pandora_server.log
-rw-rw-rw-  1 root    root      65542 2009-04-30 20:00 pandora_server.log.old
-rw-r--r--  1 root    root         94 2009-04-06 00:19 pandora_snmptrap.log
-rw-rw-rw-  1 root    root          4 2009-04-03 14:16 pandora_snmptrap.log.index
-----------------------------------------------------------------
System disk
-----------------------------------------------------------------
S.ficheros            Tamaño Usado  Disp Uso% Montado en
/dev/sda6              91G   49G   37G  58% /
tmpfs                1003M     0 1003M   0% /lib/init/rw
varrun               1003M  260K 1002M   1% /var/run
varlock              1003M     0 1003M   0% /var/lock
udev                 1003M  184K 1002M   1% /dev
tmpfs                1003M  480K 1002M   1% /dev/shm
lrm                  1003M  2,4M 1000M   1% /lib/modules/2.6.28-12-generic/volatile
-----------------------------------------------------------------
Vmstat (5 execs)
-----------------------------------------------------------------
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  0      0 684840 119888 619624    0    0    15    10  258  474  3  1 95  0
 0  0      0 684768 119888 619640    0    0     0     0  265  391  0  0 100  0
 0  0      0 684768 119892 619636    0    0     0    56  249  325  1  1 99  0
 0  0      0 684768 119892 619640    0    0     0     0  329  580  0  0 100  0
 0  0      0 684776 119892 619640    0    0     0     0  385 1382  1  0 99  0
-----------------------------------------------------------------
System dmesg
-----------------------------------------------------------------
[    0.000000] BIOS EBDA/lowmem at: 0009f000/0009f000
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.28-12-generic (buildd@rothera) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) )   #43-Ubuntu SMP Fri May 1 
19:27:06 UTC 2009 (Ubuntu 2.6.28-12.43-generic)
.
.
-----------------------------------------------------------------
END OF FILE
-----------------------------------------------------------------
560e8fa02818916d4abb59bb50d91f6a  /tmp/pandora_diag.20090601_164511.data

1.3.3 snmptrap_gen.sh

Es una herramienta para generar traps y enviarlos a una IP determinada, puede proveer IP's aleatorias o especificar una IP de origen fija. Genera OID's aleatorios a partir de la base MIB enterprise. Es útil para testear alertas de traps y poner a prueba la capacidad del servidor y la red. Se encuentra en /usr/share/pandora_server/util y está presente a partir de la version 5.1 SP1 de Pandora FMS.


Volver a Indice de Documentacion Pandora FMS