This may have been obvious to those who have managed to navigate the icinga2 documentation better than I, but apparently the IdoMySqlConnection object keeps the following information (and more) in the database forever by default:

  • every notification
  • every log message
  • every state change

See the full list in the IdoMySqlConnection section of the docs. Included amongst this data is the full host/service status at the time.

On paper, this is quite sensible, but when you have many thousands of checks being scheduled every minute this can rapidly balloon. Additionally, (although indexes have been added over time) this almost certainly hurts the performance of frontend tools such as icingaweb2.

Luckily, icinga2 does have built-in cleaning code which will tidy up data after it reaches a certain age; simply turn it on in your IdoMySqlConnection object definition. For example:

object IdoMysqlConnection "mysql-ido" {
  user = "icinga2"
  password = "icinga2password"
  database = "icinga2"

  cleanup = {
    downtimehistory_age = 48h
    contactnotifications_age = 31d
  }
}

Again, refer to the IdoMySqlConnection section in the docs for a full list of parameters that may be passed to clean.

Not so fast

There is a downside. If, like me, you’ve got to this point after months or years of running icinga2, you may have fairly large1 tables for some of these types, and icinga2 isn’t too intelligent about how it does its cleanup2. For example:

DELETE FROM icinga_logentries
  WHERE instance_id = 1
    AND logentry_time <= FROM_UNIXTIME(1456790400);

If you are in this position, and don’t value your historic data too highly, I would recommend truncating the relevant tables before enabling cleanup; it should be relatively obvious which table corresponds to which type of cleanup.

  1. My biggest tables were icinga_logentries and icinga_statehistory by an order of magnitude. YMMV. 

  2. In typical use, it doesn’t need to be—the cleaning code runs regularly and is expecting tens of rows, not millions.