granicus.if.org Git - icinga2/blob - doc/14-features.md

   1 # Icinga 2 Features <a id="icinga2-features"></a>
   2
   3 ## Logging <a id="logging"></a>
   4
   5 Icinga 2 supports three different types of logging:
   6
   7 * File logging
   8 * Syslog (on Linux/UNIX)
   9 * Console logging (`STDOUT` on tty)
  10
  11 You can enable additional loggers using the `icinga2 feature enable`
  12 and `icinga2 feature disable` commands to configure loggers:
  13
  14 Feature  | Description
  15 ---------|------------
  16 debuglog | Debug log (path: `/var/log/icinga2/debug.log`, severity: `debug` or higher)
  17 mainlog  | Main log (path: `/var/log/icinga2/icinga2.log`, severity: `information` or higher)
  18 syslog   | Syslog (severity: `warning` or higher)
  19
  20 By default file the `mainlog` feature is enabled. When running Icinga 2
  21 on a terminal log messages with severity `information` or higher are
  22 written to the console.
  23
  24 Packages will install a configuration file for logrotate on supported
  25 platforms. This configuration ensures that the `icinga2.log`, `error.log` and
  26 `debug.log` files are rotated on a daily basis.
  27
  28 ## DB IDO <a id="db-ido"></a>
  29
  30 The IDO (Icinga Data Output) modules for Icinga 2 take care of exporting all
  31 configuration and status information into a database. The IDO database is used
  32 by Icinga Web 2.
  33
  34 Details on the installation can be found in the [Configuring DB IDO](02-getting-started.md#configuring-db-ido-mysql)
  35 chapter. Details on the configuration can be found in the
  36 [IdoMysqlConnection](09-object-types.md#objecttype-idomysqlconnection) and
  37 [IdoPgsqlConnection](09-object-types.md#objecttype-idopgsqlconnection)
  38 object configuration documentation.
  39 The DB IDO feature supports [High Availability](06-distributed-monitoring.md#distributed-monitoring-high-availability-db-ido) in
  40 the Icinga 2 cluster.
  41
  42 The following example query checks the health of the current Icinga 2 instance
  43 writing its current status to the DB IDO backend table `icinga_programstatus`
  44 every 10 seconds. By default it checks 60 seconds into the past which is a reasonable
  45 amount of time -- adjust it for your requirements. If the condition is not met,
  46 the query returns an empty result.
  47
  48 > **Tip**
  49 >
  50 > Use [check plugins](05-service-monitoring.md#service-monitoring-plugins) to monitor the backend.
  51
  52 Replace the `default` string with your instance name if different.
  53
  54 Example for MySQL:
  55
  56     # mysql -u root -p icinga -e "SELECT status_update_time FROM icinga_programstatus ps
  57       JOIN icinga_instances i ON ps.instance_id=i.instance_id
  58       WHERE (UNIX_TIMESTAMP(ps.status_update_time) > UNIX_TIMESTAMP(NOW())-60)
  59       AND i.instance_name='default';"
  60
  61     +---------------------+
  62     | status_update_time  |
  63     +---------------------+
  64     | 2014-05-29 14:29:56 |
  65     +---------------------+
  66
  67
  68 Example for PostgreSQL:
  69
  70     # export PGPASSWORD=icinga; psql -U icinga -d icinga -c "SELECT ps.status_update_time FROM icinga_programstatus AS ps
  71       JOIN icinga_instances AS i ON ps.instance_id=i.instance_id
  72       WHERE ((SELECT extract(epoch from status_update_time) FROM icinga_programstatus) > (SELECT extract(epoch from now())-60))
  73       AND i.instance_name='default'";
  74
  75     status_update_time
  76     ------------------------
  77      2014-05-29 15:11:38+02
  78     (1 Zeile)
  79
  80
  81 A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](23-appendix.md#schema-db-ido).
  82
  83
  84 ## External Commands <a id="external-commands"></a>
  85
  86 Icinga 2 provides an external command pipe for processing commands
  87 triggering specific actions (for example rescheduling a service check
  88 through the web interface).
  89
  90 In order to enable the `ExternalCommandListener` configuration use the
  91 following command and restart Icinga 2 afterwards:
  92
  93     # icinga2 feature enable command
  94
  95 Icinga 2 creates the command pipe file as `/var/run/icinga2/cmd/icinga2.cmd`
  96 using the default configuration.
  97
  98 Web interfaces and other Icinga addons are able to send commands to
  99 Icinga 2 through the external command pipe, for example for rescheduling
 100 a forced service check:
 101
 102     # /bin/echo "[`date +%s`] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;`date +%s`" >> /var/run/icinga2/cmd/icinga2.cmd
 103
 104     # tail -f /var/log/messages
 105
 106     Oct 17 15:01:25 icinga-server icinga2: Executing external command: [1382014885] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382014885
 107     Oct 17 15:01:25 icinga-server icinga2: Rescheduling next check for service 'ping4'
 108
 109 A list of currently supported external commands can be found [here](23-appendix.md#external-commands-list-detail).
 110
 111 Detailed information on the commands and their required parameters can be found
 112 on the [Icinga 1.x documentation](https://docs.icinga.com/latest/en/extcommands2.html).
 113
 114 ## Performance Data <a id="performance-data"></a>
 115
 116 When a host or service check is executed plugins should provide so-called
 117 `performance data`. Next to that additional check performance data
 118 can be fetched using Icinga 2 runtime macros such as the check latency
 119 or the current service state (or additional custom attributes).
 120
 121 The performance data can be passed to external applications which aggregate and
 122 store them in their backends. These tools usually generate graphs for historical
 123 reporting and trending.
 124
 125 Well-known addons processing Icinga performance data are [PNP4Nagios](13-addons.md#addons-graphing-pnp),
 126 [Graphite](13-addons.md#addons-graphing-graphite) or [OpenTSDB](14-features.md#opentsdb-writer).
 127
 128 ### Writing Performance Data Files <a id="writing-performance-data-files"></a>
 129
 130 PNP4Nagios and Graphios use performance data collector daemons to fetch
 131 the current performance files for their backend updates.
 132
 133 Therefore the Icinga 2 [PerfdataWriter](09-object-types.md#objecttype-perfdatawriter)
 134 feature allows you to define the output template format for host and services helped
 135 with Icinga 2 runtime vars.
 136
 137     host_format_template = "DATATYPE::HOSTPERFDATA\tTIMET::$icinga.timet$\tHOSTNAME::$host.name$\tHOSTPERFDATA::$host.perfdata$\tHOSTCHECKCOMMAND::$host.check_command$\tHOSTSTATE::$host.state$\tHOSTSTATETYPE::$host.state_type$"
 138     service_format_template = "DATATYPE::SERVICEPERFDATA\tTIMET::$icinga.timet$\tHOSTNAME::$host.name$\tSERVICEDESC::$service.name$\tSERVICEPERFDATA::$service.perfdata$\tSERVICECHECKCOMMAND::$service.check_command$\tHOSTSTATE::$host.state$\tHOSTSTATETYPE::$host.state_type$\tSERVICESTATE::$service.state$\tSERVICESTATETYPE::$service.state_type$"
 139
 140 The default templates are already provided with the Icinga 2 feature configuration
 141 which can be enabled using
 142
 143     # icinga2 feature enable perfdata
 144
 145 By default all performance data files are rotated in a 15 seconds interval into
 146 the `/var/spool/icinga2/perfdata/` directory as `host-perfdata.<timestamp>` and
 147 `service-perfdata.<timestamp>`.
 148 External collectors need to parse the rotated performance data files and then
 149 remove the processed files.
 150
 151 ### Graphite Carbon Cache Writer <a id="graphite-carbon-cache-writer"></a>
 152
 153 While there are some [Graphite](13-addons.md#addons-graphing-graphite)
 154 collector scripts and daemons like Graphios available for Icinga 1.x it's more
 155 reasonable to directly process the check and plugin performance
 156 in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
 157 write them to the defined Graphite Carbon daemon tcp socket.
 158
 159 You can enable the feature using
 160
 161     # icinga2 feature enable graphite
 162
 163 By default the [GraphiteWriter](09-object-types.md#objecttype-graphitewriter) feature
 164 expects the Graphite Carbon Cache to listen at `127.0.0.1` on TCP port `2003`.
 165
 166 #### Current Graphite Schema <a id="graphite-carbon-cache-writer-schema"></a>
 167
 168 The current naming schema is defined as follows. The [Icinga Web 2 Graphite module](https://github.com/icinga/icingaweb2-module-graphite)
 169 depends on this schema.
 170
 171 The default prefix for hosts and services is configured using
 172 [runtime macros](03-monitoring-basics.md#runtime-macros)like this:
 173
 174     icinga2.$host.name$.host.$host.check_command$
 175     icinga2.$host.name$.services.$service.name$.$service.check_command$
 176
 177 You can customize the prefix name by using the `host_name_template` and
 178 `service_name_template` configuration attributes.
 179
 180 The additional levels will allow fine granular filters and also template
 181 capabilities, e.g. by using the check command `disk` for specific
 182 graph templates in web applications rendering the Graphite data.
 183
 184 The following characters are escaped in prefix labels:
 185
 186   Character     | Escaped character
 187   --------------|--------------------------
 188   whitespace    | _
 189   .             | _
 190   \             | _
 191   /             | _
 192
 193 Metric values are stored like this:
 194
 195     <prefix>.perfdata.<perfdata-label>.value
 196
 197 The following characters are escaped in perfdata labels:
 198
 199   Character     | Escaped character
 200   --------------|--------------------------
 201   whitespace    | _
 202   \             | _
 203   /             | _
 204   ::            | .
 205
 206 Note that perfdata labels may contain dots (`.`) allowing to
 207 add more subsequent levels inside the Graphite tree.
 208 `::` adds support for [multi performance labels](http://my-plugin.de/wiki/projects/check_multi/configuration/performance)
 209 and is therefore replaced by `.`.
 210
 211 By enabling `enable_send_thresholds` Icinga 2 automatically adds the following threshold metrics:
 212
 213     <prefix>.perfdata.<perfdata-label>.min
 214     <prefix>.perfdata.<perfdata-label>.max
 215     <prefix>.perfdata.<perfdata-label>.warn
 216     <prefix>.perfdata.<perfdata-label>.crit
 217
 218 By enabling `enable_send_metadata` Icinga 2 automatically adds the following metadata metrics:
 219
 220     <prefix>.metadata.current_attempt
 221     <prefix>.metadata.downtime_depth
 222     <prefix>.metadata.acknowledgement
 223     <prefix>.metadata.execution_time
 224     <prefix>.metadata.latency
 225     <prefix>.metadata.max_check_attempts
 226     <prefix>.metadata.reachable
 227     <prefix>.metadata.state
 228     <prefix>.metadata.state_type
 229
 230 Metadata metric overview:
 231
 232   metric             | description
 233   -------------------|------------------------------------------
 234   current_attempt    | current check attempt
 235   max_check_attempts | maximum check attempts until the hard state is reached
 236   reachable          | checked object is reachable
 237   downtime_depth     | number of downtimes this object is in
 238   acknowledgement    | whether the object is acknowledged or not
 239   execution_time     | check execution time
 240   latency            | check latency
 241   state              | current state of the checked object
 242   state_type         | 0=SOFT, 1=HARD state
 243
 244 The following example illustrates how to configure the storage schemas for Graphite Carbon
 245 Cache.
 246
 247     [icinga2_default]
 248     # intervals like PNP4Nagios uses them per default
 249     pattern = ^icinga2\.
 250     retentions = 1m:2d,5m:10d,30m:90d,360m:4y
 251
 252
 253 ### InfluxDB Writer <a id="influxdb-writer"></a>
 254
 255 Once there are new metrics available, Icinga 2 will directly write them to the
 256 defined InfluxDB HTTP API.
 257
 258 You can enable the feature using
 259
 260     # icinga2 feature enable influxdb
 261
 262 By default the [InfluxdbWriter](09-object-types.md#objecttype-influxdbwriter) feature
 263 expects the InfluxDB daemon to listen at `127.0.0.1` on port `8086`.
 264
 265 More configuration details can be found [here](09-object-types.md#objecttype-influxdbwriter).
 266
 267 ### Elastic Stack Integration <a id="elastic-stack-integration"></a>
 268
 269 [Icingabeat](https://github.com/icinga/icingabeat) is an Elastic Beat that fetches data
 270 from the Icinga 2 API and sends it either directly to [Elasticsearch](https://www.elastic.co/products/elasticsearch)
 271 or [Logstash](https://www.elastic.co/products/logstash).
 272
 273 More integrations:
 274
 275 * [Logstash output](https://github.com/Icinga/logstash-output-icinga) for the Icinga 2 API.
 276 * [Logstash Grok Pattern](https://github.com/Icinga/logstash-grok-pattern) for Icinga 2 logs.
 277
 278 #### Elastic Writer <a id="elastic-writer"></a>
 279
 280 This feature forwards check results, state changes and notification events
 281 to an [Elasticsearch](https://www.elastic.co/products/elasticsearch) installation over its HTTP API.
 282
 283 The check results include parsed performance data metrics if enabled.
 284
 285 > **Note**
 286 >
 287 > Elasticsearch 5.x+ is required.
 288
 289 Enable the feature and restart Icinga 2.
 290
 291 ```
 292 # icinga2 feature enable elastic
 293 ```
 294
 295 The default configuration expects an Elasticsearch instance running on `localhost` on port `9200
 296  and writes to an index called `icinga2`.
 297
 298 More configuration details can be found [here](09-object-types.md#objecttype-elasticwriter).
 299
 300 #### Current Elasticsearch Schema <a id="elastic-writer-schema"></a>
 301
 302 The following event types are written to Elasticsearch:
 303
 304 * icinga2.event.checkresult
 305 * icinga2.event.statechange
 306 * icinga2.event.notification
 307
 308 Performance data metrics must be explicitly enabled with the `enable_send_perfdata`
 309 attribute.
 310
 311 Metric values are stored like this:
 312
 313     check_result.perfdata.<perfdata-label>.value
 314
 315 The following characters are escaped in perfdata labels:
 316
 317   Character     | Escaped character
 318   --------------|--------------------------
 319   whitespace    | _
 320   \             | _
 321   /             | _
 322   ::            | .
 323
 324 Note that perfdata labels may contain dots (`.`) allowing to
 325 add more subsequent levels inside the tree.
 326 `::` adds support for [multi performance labels](http://my-plugin.de/wiki/projects/check_multi/configuration/performance)
 327 and is therefore replaced by `.`.
 328
 329 Icinga 2 automatically adds the following threshold metrics
 330 if existing:
 331
 332     check_result.perfdata.<perfdata-label>.min
 333     check_result.perfdata.<perfdata-label>.max
 334     check_result.perfdata.<perfdata-label>.warn
 335     check_result.perfdata.<perfdata-label>.crit
 336
 337 ### Graylog Integration <a id="graylog-integration"></a>
 338
 339 #### GELF Writer <a id="gelfwriter"></a>
 340
 341 The `Graylog Extended Log Format` (short: [GELF](http://docs.graylog.org/en/latest/pages/gelf.html))
 342 can be used to send application logs directly to a TCP socket.
 343
 344 While it has been specified by the [Graylog](https://www.graylog.org) project as their
 345 [input resource standard](http://docs.graylog.org/en/latest/pages/sending_data.html), other tools such as
 346 [Logstash](https://www.elastic.co/products/logstash) also support `GELF` as
 347 [input type](https://www.elastic.co/guide/en/logstash/current/plugins-inputs-gelf.html).
 348
 349 You can enable the feature using
 350
 351     # icinga2 feature enable gelf
 352
 353 By default the `GelfWriter` object expects the GELF receiver to listen at `127.0.0.1` on TCP port `12201`.
 354 The default `source`  attribute is set to `icinga2`. You can customize that for your needs if required.
 355
 356 Currently these events are processed:
 357 * Check results
 358 * State changes
 359 * Notifications
 360
 361
 362 ### OpenTSDB Writer <a id="opentsdb-writer"></a>
 363
 364 While there are some OpenTSDB collector scripts and daemons like tcollector available for
 365 Icinga 1.x it's more reasonable to directly process the check and plugin performance
 366 in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
 367 write them to the defined TSDB TCP socket.
 368
 369 You can enable the feature using
 370
 371     # icinga2 feature enable opentsdb
 372
 373 By default the `OpenTsdbWriter` object expects the TSD to listen at
 374 `127.0.0.1` on port `4242`.
 375
 376 The current naming schema is
 377
 378     icinga.host.<metricname>
 379     icinga.service.<servicename>.<metricname>
 380
 381 for host and service checks. The tag host is always applied.
 382
 383 To make sure Icinga 2 writes a valid metric into OpenTSDB some characters are replaced
 384 with `_` in the target name:
 385
 386     \  (and space)
 387
 388 The resulting name in OpenTSDB might look like:
 389
 390     www-01 / http-cert / response time
 391     icinga.http_cert.response_time
 392
 393 In addition to the performance data retrieved from the check plugin, Icinga 2 sends
 394 internal check statistic data to OpenTSDB:
 395
 396   metric             | description
 397   -------------------|------------------------------------------
 398   current_attempt    | current check attempt
 399   max_check_attempts | maximum check attempts until the hard state is reached
 400   reachable          | checked object is reachable
 401   downtime_depth     | number of downtimes this object is in
 402   acknowledgement    | whether the object is acknowledged or not
 403   execution_time     | check execution time
 404   latency            | check latency
 405   state              | current state of the checked object
 406   state_type         | 0=SOFT, 1=HARD state
 407
 408 While reachable, state and state_type are metrics for the host or service the
 409 other metrics follow the current naming schema
 410
 411     icinga.check.<metricname>
 412
 413 with the following tags
 414
 415   tag     | description
 416   --------|------------------------------------------
 417   type    | the check type, one of [host, service]
 418   host    | hostname, the check ran on
 419   service | the service name (if type=service)
 420
 421 > **Note**
 422 >
 423 > You might want to set the tsd.core.auto_create_metrics setting to `true`
 424 > in your opentsdb.conf configuration file.
 425
 426
 427 ## Livestatus <a id="setting-up-livestatus"></a>
 428
 429 The [MK Livestatus](https://mathias-kettner.de/checkmk_livestatus.html) project
 430 implements a query protocol that lets users query their Icinga instance for
 431 status information. It can also be used to send commands.
 432
 433 > **Tip**
 434 >
 435 > Only install the Livestatus feature if your web interface or addon requires
 436 > you to do so (for example, [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2)).
 437 > Icinga Classic UI 1.x and Icinga Web 1.x do not use Livestatus as backend.
 438
 439 The Livestatus component that is distributed as part of Icinga 2 is a
 440 re-implementation of the Livestatus protocol which is compatible with MK
 441 Livestatus.
 442
 443 Details on the available tables and attributes with Icinga 2 can be found
 444 in the [Livestatus Schema](23-appendix.md#schema-livestatus) section.
 445
 446 You can enable Livestatus using icinga2 feature enable:
 447
 448     # icinga2 feature enable livestatus
 449
 450 After that you will have to restart Icinga 2:
 451
 452 RHEL/CentOS 7/Fedora, SLES 12, Debian Jessie/Stretch, Ubuntu Xenial:
 453
 454     # systemctl restart icinga2
 455
 456 Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
 457
 458     # service icinga2 restart
 459
 460 By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
 461
 462 In order for queries and commands to work you will need to add your query user
 463 (e.g. your web server) to the `icingacmd` group:
 464
 465     # usermod -a -G icingacmd www-data
 466
 467 The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to
 468 `nagios` if you're using Debian.
 469
 470 Change `www-data` to the user you're using to run queries.
 471
 472 In order to use the historical tables provided by the livestatus feature (for example, the
 473 `log` table) you need to have the `CompatLogger` feature enabled. By default these logs
 474 are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
 475 `compat_log_path` configuration attribute.
 476
 477     # icinga2 feature enable compatlog
 478
 479
 480 ### Livestatus Sockets <a id="livestatus-sockets"></a>
 481
 482 Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
 483
 484 * Unix socket (default)
 485 * TCP socket
 486
 487 Details on the configuration can be found in the [LivestatusListener](09-object-types.md#objecttype-livestatuslistener)
 488 object configuration.
 489
 490 ### Livestatus GET Queries <a id="livestatus-get-queries"></a>
 491
 492 > **Note**
 493 >
 494 > All Livestatus queries require an additional empty line as query end identifier.
 495 > The `nc` tool (`netcat`) provides the `-U` parameter to communicate using
 496 > a unix socket.
 497
 498 There also is a Perl module available in CPAN for accessing the Livestatus socket
 499 programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Monitoring-Livestatus-0.74/)
 500
 501
 502 Example using the unix socket:
 503
 504     # echo -e "GET services\n" | /usr/bin/nc -U /var/run/icinga2/cmd/livestatus
 505
 506 Example using the tcp socket listening on port `6558`:
 507
 508     # echo -e 'GET services\n' | netcat 127.0.0.1 6558
 509
 510     # cat servicegroups <<EOF
 511     GET servicegroups
 512
 513     EOF
 514
 515     (cat servicegroups; sleep 1) | netcat 127.0.0.1 6558
 516
 517
 518 ### Livestatus COMMAND Queries <a id="livestatus-command-queries"></a>
 519
 520 A list of available external commands and their parameters can be found [here](23-appendix.md#external-commands-list-detail)
 521
 522     $ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
 523
 524
 525 ### Livestatus Filters <a id="livestatus-filters"></a>
 526
 527 and, or, negate
 528
 529   Operator  | Negate   | Description
 530   ----------|------------------------
 531    =        | !=       | Equality
 532    ~        | !~       | Regex match
 533    =~       | !=~      | Equality ignoring case
 534    ~~       | !~~      | Regex ignoring case
 535    <        |          | Less than
 536    >        |          | Greater than
 537    <=       |          | Less than or equal
 538    >=       |          | Greater than or equal
 539
 540
 541 ### Livestatus Stats <a id="livestatus-stats"></a>
 542
 543 Schema: "Stats: aggregatefunction aggregateattribute"
 544
 545   Aggregate Function | Description
 546   -------------------|--------------
 547   sum                | &nbsp;
 548   min                | &nbsp;
 549   max                | &nbsp;
 550   avg                | sum / count
 551   std                | standard deviation
 552   suminv             | sum (1 / value)
 553   avginv             | suminv / count
 554   count              | ordinary default for any stats query if not aggregate function defined
 555
 556 Example:
 557
 558     GET hosts
 559     Filter: has_been_checked = 1
 560     Filter: check_type = 0
 561     Stats: sum execution_time
 562     Stats: sum latency
 563     Stats: sum percent_state_change
 564     Stats: min execution_time
 565     Stats: min latency
 566     Stats: min percent_state_change
 567     Stats: max execution_time
 568     Stats: max latency
 569     Stats: max percent_state_change
 570     OutputFormat: json
 571     ResponseHeader: fixed16
 572
 573 ### Livestatus Output <a id="livestatus-output"></a>
 574
 575 * CSV
 576
 577 CSV output uses two levels of array separators: The members array separator
 578 is a comma (1st level) while extra info and host|service relation separator
 579 is a pipe (2nd level).
 580
 581 Separators can be set using ASCII codes like:
 582
 583     Separators: 10 59 44 124
 584
 585 * JSON
 586
 587 Default separators.
 588
 589 ### Livestatus Error Codes <a id="livestatus-error-codes"></a>
 590
 591   Code      | Description
 592   ----------|--------------
 593   200       | OK
 594   404       | Table does not exist
 595   452       | Exception on query
 596
 597 ### Livestatus Tables <a id="livestatus-tables"></a>
 598
 599   Table         | Join      |Description
 600   --------------|-----------|----------------------------
 601   hosts         | &nbsp;    | host config and status attributes, services counter
 602   hostgroups    | &nbsp;    | hostgroup config, status attributes and host/service counters
 603   services      | hosts     | service config and status attributes
 604   servicegroups | &nbsp;    | servicegroup config, status attributes and service counters
 605   contacts      | &nbsp;    | contact config and status attributes
 606   contactgroups | &nbsp;    | contact config, members
 607   commands      | &nbsp;    | command name and line
 608   status        | &nbsp;    | programstatus, config and stats
 609   comments      | services  | status attributes
 610   downtimes     | services  | status attributes
 611   timeperiods   | &nbsp;    | name and is inside flag
 612   endpoints     | &nbsp;    | config and status attributes
 613   log           | services, hosts, contacts, commands | parses [compatlog](09-object-types.md#objecttype-compatlogger) and shows log attributes
 614   statehist     | hosts, services | parses [compatlog](09-object-types.md#objecttype-compatlogger) and aggregates state change attributes
 615   hostsbygroup  | hostgroups | host attributes grouped by hostgroup and its attributes
 616   servicesbygroup | servicegroups | service attributes grouped by servicegroup and its attributes
 617   servicesbyhostgroup  | hostgroups | service attributes grouped by hostgroup and its attributes
 618
 619 The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects.
 620
 621 A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](23-appendix.md#schema-livestatus).
 622
 623
 624 ## Status Data Files <a id="status-data"></a>
 625
 626 Icinga 1.x writes object configuration data and status data in a cyclic
 627 interval to its `objects.cache` and `status.dat` files. Icinga 2 provides
 628 the `StatusDataWriter` object which dumps all configuration objects and
 629 status updates in a regular interval.
 630
 631     # icinga2 feature enable statusdata
 632
 633 Icinga 1.x Classic UI requires this data set as part of its backend.
 634
 635 > **Note**
 636 >
 637 > If you are not using any web interface or addon which uses these files,
 638 > you can safely disable this feature.
 639
 640
 641 ## Compat Log Files <a id="compat-logging"></a>
 642
 643 The Icinga 1.x log format is considered being the `Compat Log`
 644 in Icinga 2 provided with the `CompatLogger` object.
 645
 646 These logs are not only used for informational representation in
 647 external web interfaces parsing the logs, but also to generate
 648 SLA reports and trends in Icinga 1.x Classic UI. Furthermore the
 649 [Livestatus](14-features.md#setting-up-livestatus) feature uses these logs for answering queries to
 650 historical tables.
 651
 652 The `CompatLogger` object can be enabled with
 653
 654     # icinga2 feature enable compatlog
 655
 656 By default, the Icinga 1.x log file called `icinga.log` is located
 657 in `/var/log/icinga2/compat`. Rotated log files are moved into
 658 `var/log/icinga2/compat/archives`.
 659
 660 The format cannot be changed without breaking compatibility to
 661 existing log parsers.
 662
 663     # tail -f /var/log/icinga2/compat/icinga.log
 664
 665     [1382115688] LOG ROTATION: HOURLY
 666     [1382115688] LOG VERSION: 2.0
 667     [1382115688] HOST STATE: CURRENT;localhost;UP;HARD;1;
 668     [1382115688] SERVICE STATE: CURRENT;localhost;disk;WARNING;HARD;1;
 669     [1382115688] SERVICE STATE: CURRENT;localhost;http;OK;HARD;1;
 670     [1382115688] SERVICE STATE: CURRENT;localhost;load;OK;HARD;1;
 671     [1382115688] SERVICE STATE: CURRENT;localhost;ping4;OK;HARD;1;
 672     [1382115688] SERVICE STATE: CURRENT;localhost;ping6;OK;HARD;1;
 673     [1382115688] SERVICE STATE: CURRENT;localhost;processes;WARNING;HARD;1;
 674     [1382115688] SERVICE STATE: CURRENT;localhost;ssh;OK;HARD;1;
 675     [1382115688] SERVICE STATE: CURRENT;localhost;users;OK;HARD;1;
 676     [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;disk;1382115705
 677     [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;http;1382115705
 678     [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;load;1382115705
 679     [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382115705
 680     [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping6;1382115705
 681     [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;processes;1382115705
 682     [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ssh;1382115705
 683     [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;users;1382115705
 684     [1382115731] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;localhost;ping6;2;critical test|
 685     [1382115731] SERVICE ALERT: localhost;ping6;CRITICAL;SOFT;2;critical test
 686
 687
 688 ## Check Result Files <a id="check-result-files"></a>
 689
 690 Icinga 1.x writes its check result files to a temporary spool directory
 691 where they are processed in a regular interval.
 692 While this is extremely inefficient in performance regards it has been
 693 rendered useful for passing passive check results directly into Icinga 1.x
 694 skipping the external command pipe.
 695
 696 Several clustered/distributed environments and check-aggregation addons
 697 use that method. In order to support step-by-step migration of these
 698 environments, Icinga 2 supports the `CheckResultReader` object.
 699
 700 There is no feature configuration available, but it must be defined
 701 on-demand in your Icinga 2 objects configuration.
 702
 703     object CheckResultReader "reader" {
 704       spool_dir = "/data/check-results"
 705     }
 706