Plugin parametrization
The plugin is used after having previously configured the configuration external file.
NOTE: It is extremely important to consider that the configuration files that are though for the plugin in UNIX should be edited and stored with carriage return kind “UNIX” and that carriage return kind “WINDOWS” are used, then the plugin will be not work correctly.
There are three functional blocks in the configuration file:
MySQL Access Configuration and General data
In order for the plugin to monitor the database, you have to provide it with the access credentials and some general data that will be used later in the checks:
MySQL user, password and host.
The access credentials will be completed as follows:
conf_mysql_user mysql
conf_mysql_pass 1234
conf_mysql_host 127.0.0.1There is a possibility that we have a blank password for the mysql user. In this case
the line ( # conf_mysql_pass) should be commented out.
General data
Here you will specify the MySQL home directory (usually /var/lib/mysql), the log file, a directory for temporary files and the complete path to the
log file, a directory for temporary files and the complete path to the log parsing plugin of
Pandora log parsing plugin:
conf_mysql_homedir /var/lib/mysql
conf_mysql_basedir /var/lib/mysql
conf_mysql_logfile /var/log/mysql.log
conf_temp /tmp
conf_logparser /etc/pandora/plugins/grep_logSystem parameters
The following describes the system-specific test modules that are configured by default in the attached mysql.conf.
configured by default in the attached mysql.conf:
System check block
A system check block in the configuration file is as shown below:
check_begin
# Linea de comentario.
<token de chequeo de sistema>
check_end
The following is a description of the plugin checks:
Database connectivity check.
This check will verify if the database has connectivity with other software elements.
software. If this check is not satisfactory, the monitoring will be aborted:
check_begin
check_mysql_service
check_end
Check if the mysql process is active
This check verifies that the MySQL process is active on the system:
check_begin
check_mysql_service
check_end
Server memory check (process)
This check checks the memory usage of the MySQL server.
check_begin
check_mysql_memory
check_end
Number of TIME_WAIT connections in the system
Displays the number of connections in TIME_WAIT state in the system:
check_begin
check_system_timewait
check_end
Server disk space check
Checks the disk space (in KB) on the database side. It will check the size of the
MySQL homedir directory specified in the General data section will be checked:
check_begin
check_system_diskusage
check_end
ibdata1 file size
Checks the size (in KB) of the ibdata1 file located in the MySQL homedir directory:
check_begin
check_mysql_ibdata1
check_end
Search for errors in the database error logs.
It will search for the string "ERROR" in the log file indicated in the General Data section. This module will always return the async_string data type and in case the check returns data the associated command will be executed (explained in the section Executing commands under condition):
check_begin
check_mysql_logs
check_endPerformance parameters
The performance check modules are described below:
Performance check block.
Similar to the system checks as shown below:
check_begin
# Linea de comentario.
<token de chequeo de rendimiento>
check_end
The performance check blocks are shown below:
Number of active MySQL connections.
Returns the number of active connections to the database:
check_begin
mysql_status Full processlist
check_end
Number of connections aborted because the client did not correctly close the connection.
check_begin
mysql_status Aborted_connects
check_end
Number of bytes received by clients
check_begin
mysql_status Bytes_received
check_end
Number of bytes sent by clients
check_begin
mysql_status Bytes_sent
check_end
Server status information (SHOW GLOBAL STATUS or SHOW STATUS)
These queries are based on the MySQL SHOW GLOBAL STATUS command. Within the data
returned by this command you can search for a token and its associated value:
check_begin
mysql_status <token to search>
check_end
InnoDB Status Information (SHOW INNODB STATUS)
These queries are based on the MySQL SHOW INNODB STATUS command. Within the data
returned by this command you can search for a token and its associated value:
check_begin
mysql_status Com_insert
check_end
Number of insertions in the database
Number of INSERT transactions made in the database:
check_begin
check_name <check_name>
mysql_innodb <token to search in innodb status>
check_endNumber of locks on tables in the database when performing a transaction
check_begin
mysql_status Com_lock_tables
check_end
Active locks on tables and records for each active session
check_begin
# Number of locks over DB tables
mysql_status Table_locks_waited
check_end
check_begin
# Number of row locks
mysql_status Innodb_row_lock_waits
check_end
Pending I/0 requests
check_begin
mysql_status Pending_io
check_endTotal data size in GB
check_begin
mysql_status Total_size
check_end
Monitoring via SQL
One of the most powerful features of the plugin is the possibility to specify your own SQL command to get the value.
SQL to get the value. Let's see an example:
check_begin
check_name num_tables
check_schema information_schema
check_sql SELECT COUNT(*) FROM tables
check_end
Check_name El nombre de la comprbación que se verá en la interfaz de Pandora. .
Check_sql La query que deberá devolver un dato simple (ya sea número o cadena)..
Check_schema El esquema de MySQL al que se conectará el plugin para realizar la query
Execution of commands under condition
In all modules it is possible to specify the execution of a command if a condition is met.
Such conditions can be:
- == (equal to a value)
- != (different from a value)
- < (less than a given value)
- > (Greater than a given value).
If the condition is satisfied then the configured command will be executed using the post_execution token. In the case of the check_mysql_logs check the command will be executed if any data is returned by this check.
An example of this configuration is as follows:
check_begin
check_mysql_cpu
post_condition > 95
post_execution snmptrap -v 1 -c public x.x.x.x 1.2.4.4.65.6.4.3 6 128
check_end
Parameterization of the command associated to a check
As mentioned above, in each check a command can be configured to be executed if the condition is met. In addition, a token can be used in the command so that if it is executed then it is replaced by the value of the check. For example, by means of the macro _DATA_ in this example the content of the check is saved in the file /tmp/mysql_cpu_result:
check_begin
check_mysql_cpu
post_condition > 95
post_execution echo _DATA_ >> /tmp/mysql_cpu_result
check_endModule status
Complementarily, modules will return a status if indicated with the configuration token:
post_status WARNING
Or:
post_status CRITICAL
Data type
By default all monitors will return generic_data, unless the following configuration token is specified.
module_type generic_data_inc
module_type async_string
(or any other valid one)
The only exception is the monitor check_mysql_service automatically a module of type generic_proc.
* In modules where we use check_name, check_type can be used to choose the data type of the module.
Data processing in performance type checks
In performance type checks and SQL queries can be configured to return the absolute value as it is returned.
the absolute value as returned by MySQL (data_absolute) or the difference between the current and previous data (data_delta). In the first execution of the check configured with data_delta no data will be returned. From the second run the increment will be returned. If the difference between the current and previous data is negative, the value of the check is reset and the check will not return any data.
By default the performance type checks will be set to data_absolute.
For example this check will return the increment of active MySQL sessions:
check_begin
mysql_status Full processlist
data_delta
check_end