From cf79724eb90682d96f95dd207253e859d096d931 Mon Sep 17 00:00:00 2001 From: Michael Friedrich Date: Thu, 18 Jan 2018 17:50:39 +0100 Subject: [PATCH] Docs: Add IDO DB tuning tips fixes #5622 refs #6014 --- doc/14-features.md | 101 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 77 insertions(+), 24 deletions(-) diff --git a/doc/14-features.md b/doc/14-features.md index 9f4db6a78..b4e66931a 100644 --- a/doc/14-features.md +++ b/doc/14-features.md @@ -27,9 +27,9 @@ platforms. This configuration ensures that the `icinga2.log`, `error.log` and ## DB IDO -The IDO (Icinga Data Output) modules for Icinga 2 take care of exporting all +The IDO (Icinga Data Output) feature for Icinga 2 takes care of exporting all configuration and status information into a database. The IDO database is used -by Icinga Web 2. +by Icinga Web 2 as data backend. Details on the installation can be found in the [Configuring DB IDO](02-getting-started.md#configuring-db-ido-mysql) chapter. Details on the configuration can be found in the @@ -39,9 +39,14 @@ object configuration documentation. The DB IDO feature supports [High Availability](06-distributed-monitoring.md#distributed-monitoring-high-availability-db-ido) in the Icinga 2 cluster. -The following example query checks the health of the current Icinga 2 instance -writing its current status to the DB IDO backend table `icinga_programstatus` -every 10 seconds. By default it checks 60 seconds into the past which is a reasonable +### DB IDO Health + +If the monitoring health indicator is critical in Icinga Web 2, +you can use the following queries to manually check whether Icinga 2 +is actually updating the IDO database. + +Icinga 2 writes its current status to the `icinga_programstatus` table +every 10 seconds. The query below checks 60 seconds into the past which is a reasonable amount of time -- adjust it for your requirements. If the condition is not met, the query returns an empty result. @@ -53,34 +58,82 @@ Replace the `default` string with your instance name if different. Example for MySQL: - # mysql -u root -p icinga -e "SELECT status_update_time FROM icinga_programstatus ps - JOIN icinga_instances i ON ps.instance_id=i.instance_id - WHERE (UNIX_TIMESTAMP(ps.status_update_time) > UNIX_TIMESTAMP(NOW())-60) - AND i.instance_name='default';" - - +---------------------+ - | status_update_time | - +---------------------+ - | 2014-05-29 14:29:56 | - +---------------------+ +``` +# mysql -u root -p icinga -e "SELECT status_update_time FROM icinga_programstatus ps + JOIN icinga_instances i ON ps.instance_id=i.instance_id + WHERE (UNIX_TIMESTAMP(ps.status_update_time) > UNIX_TIMESTAMP(NOW())-60) + AND i.instance_name='default';" ++---------------------+ +| status_update_time | ++---------------------+ +| 2014-05-29 14:29:56 | ++---------------------+ +``` Example for PostgreSQL: - # export PGPASSWORD=icinga; psql -U icinga -d icinga -c "SELECT ps.status_update_time FROM icinga_programstatus AS ps - JOIN icinga_instances AS i ON ps.instance_id=i.instance_id - WHERE ((SELECT extract(epoch from status_update_time) FROM icinga_programstatus) > (SELECT extract(epoch from now())-60)) - AND i.instance_name='default'"; - - status_update_time - ------------------------ - 2014-05-29 15:11:38+02 - (1 Zeile) +``` +# export PGPASSWORD=icinga; psql -U icinga -d icinga -c "SELECT ps.status_update_time FROM icinga_programstatus AS ps + JOIN icinga_instances AS i ON ps.instance_id=i.instance_id + WHERE ((SELECT extract(epoch from status_update_time) FROM icinga_programstatus) > (SELECT extract(epoch from now())-60)) + AND i.instance_name='default'"; +status_update_time +------------------------ + 2014-05-29 15:11:38+02 +(1 Zeile) +``` A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](24-appendix.md#schema-db-ido). +### DB IDO Tuning + +As with any application database, there are ways to optimize and tune the database performance. + +General tips for performance tuning: + +* [MariaDB KB](https://mariadb.com/kb/en/library/optimization-and-tuning/) +* [PostgreSQL Wiki](https://wiki.postgresql.org/wiki/Performance_Optimization) + +Re-creation of indexes, changed column values, etc. will increase the database size. Ensure to +add health checks for this, and monitor the trend in your Grafana dashboards. + +In order to optimize the tables, there are different approaches. Always keep in mind to have a +current backup and schedule maintenance downtime for these kind of tasks! + +MySQL: + +``` +mariadb> OPTIMIZE TABLE icinga_statehistory; +``` + +> **Important** +> +> Tables might not support optimization at runtime. This can take a **long** time. +> +> `Table does not support optimize, doing recreate + analyze instead`. + +If you want to optimize all tables in a specified database, there is a script called `mysqlcheck`. +This also allows to repair broken tables in the case of emergency. + +``` +mysqlcheck --optimize icinga +``` + +PostgreSQL: + +``` +icinga=# vacuum; +VACUUM +``` + +> **Note** +> +> Don't use `VACUUM FULL` as this has a severe impact on performance. + + ## External Commands > **Note**