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.1 There 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_log System 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. 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_end Performance parameters The performance check modules are described below: Performance check block. Similar to the system checks as shown below: check_begin # Linea de comentario. 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 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 mysql_innodb check_end Number 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_end Total 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_end Module 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