1 # Icinga 2 Features <a id="icinga2-features"></a>
3 ## Logging <a id="logging"></a>
5 Icinga 2 supports three different types of logging:
8 * Syslog (on Linux/UNIX)
9 * Console logging (`STDOUT` on tty)
11 You can enable additional loggers using the `icinga2 feature enable`
12 and `icinga2 feature disable` commands to configure loggers:
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)
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.
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.
28 ## DB IDO <a id="db-ido"></a>
30 The IDO (Icinga Data Output) feature for Icinga 2 takes care of exporting all
31 configuration and status information into a database. The IDO database is used
32 by Icinga Web 2 as data backend.
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
42 ### DB IDO Health <a id="db-ido-health"></a>
44 If the monitoring health indicator is critical in Icinga Web 2,
45 you can use the following queries to manually check whether Icinga 2
46 is actually updating the IDO database.
48 Icinga 2 writes its current status to the `icinga_programstatus` table
49 every 10 seconds. The query below checks 60 seconds into the past which is a reasonable
50 amount of time -- adjust it for your requirements. If the condition is not met,
51 the query returns an empty result.
55 > Use [check plugins](05-service-monitoring.md#service-monitoring-plugins) to monitor the backend.
57 Replace the `default` string with your instance name if different.
62 # mysql -u root -p icinga -e "SELECT status_update_time FROM icinga_programstatus ps
63 JOIN icinga_instances i ON ps.instance_id=i.instance_id
64 WHERE (UNIX_TIMESTAMP(ps.status_update_time) > UNIX_TIMESTAMP(NOW())-60)
65 AND i.instance_name='default';"
67 +---------------------+
68 | status_update_time |
69 +---------------------+
70 | 2014-05-29 14:29:56 |
71 +---------------------+
74 Example for PostgreSQL:
77 # export PGPASSWORD=icinga; psql -U icinga -d icinga -c "SELECT ps.status_update_time FROM icinga_programstatus AS ps
78 JOIN icinga_instances AS i ON ps.instance_id=i.instance_id
79 WHERE ((SELECT extract(epoch from status_update_time) FROM icinga_programstatus) > (SELECT extract(epoch from now())-60))
80 AND i.instance_name='default'";
83 ------------------------
84 2014-05-29 15:11:38+02
88 A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](24-appendix.md#schema-db-ido).
91 ### DB IDO Tuning <a id="db-ido-tuning"></a>
93 As with any application database, there are ways to optimize and tune the database performance.
95 General tips for performance tuning:
97 * [MariaDB KB](https://mariadb.com/kb/en/library/optimization-and-tuning/)
98 * [PostgreSQL Wiki](https://wiki.postgresql.org/wiki/Performance_Optimization)
100 Re-creation of indexes, changed column values, etc. will increase the database size. Ensure to
101 add health checks for this, and monitor the trend in your Grafana dashboards.
103 In order to optimize the tables, there are different approaches. Always keep in mind to have a
104 current backup and schedule maintenance downtime for these kind of tasks!
109 mariadb> OPTIMIZE TABLE icinga_statehistory;
114 > Tables might not support optimization at runtime. This can take a **long** time.
116 > `Table does not support optimize, doing recreate + analyze instead`.
118 If you want to optimize all tables in a specified database, there is a script called `mysqlcheck`.
119 This also allows to repair broken tables in the case of emergency.
122 mysqlcheck --optimize icinga
134 > Don't use `VACUUM FULL` as this has a severe impact on performance.
137 ## External Commands <a id="external-commands"></a>
141 > Please use the [REST API](12-icinga2-api.md#icinga2-api) as modern and secure alternative
142 > for external actions.
144 Icinga 2 provides an external command pipe for processing commands
145 triggering specific actions (for example rescheduling a service check
146 through the web interface).
148 In order to enable the `ExternalCommandListener` configuration use the
149 following command and restart Icinga 2 afterwards:
151 # icinga2 feature enable command
153 Icinga 2 creates the command pipe file as `/var/run/icinga2/cmd/icinga2.cmd`
154 using the default configuration.
156 Web interfaces and other Icinga addons are able to send commands to
157 Icinga 2 through the external command pipe, for example for rescheduling
158 a forced service check:
160 # /bin/echo "[`date +%s`] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;`date +%s`" >> /var/run/icinga2/cmd/icinga2.cmd
162 # tail -f /var/log/messages
164 Oct 17 15:01:25 icinga-server icinga2: Executing external command: [1382014885] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382014885
165 Oct 17 15:01:25 icinga-server icinga2: Rescheduling next check for service 'ping4'
167 A list of currently supported external commands can be found [here](24-appendix.md#external-commands-list-detail).
169 Detailed information on the commands and their required parameters can be found
170 on the [Icinga 1.x documentation](https://docs.icinga.com/latest/en/extcommands2.html).
172 ## Performance Data <a id="performance-data"></a>
174 When a host or service check is executed plugins should provide so-called
175 `performance data`. Next to that additional check performance data
176 can be fetched using Icinga 2 runtime macros such as the check latency
177 or the current service state (or additional custom attributes).
179 The performance data can be passed to external applications which aggregate and
180 store them in their backends. These tools usually generate graphs for historical
181 reporting and trending.
183 Well-known addons processing Icinga performance data are [PNP4Nagios](13-addons.md#addons-graphing-pnp),
184 [Graphite](13-addons.md#addons-graphing-graphite) or [OpenTSDB](14-features.md#opentsdb-writer).
186 ### Writing Performance Data Files <a id="writing-performance-data-files"></a>
188 PNP4Nagios and Graphios use performance data collector daemons to fetch
189 the current performance files for their backend updates.
191 Therefore the Icinga 2 [PerfdataWriter](09-object-types.md#objecttype-perfdatawriter)
192 feature allows you to define the output template format for host and services helped
193 with Icinga 2 runtime vars.
195 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$"
196 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$"
198 The default templates are already provided with the Icinga 2 feature configuration
199 which can be enabled using
201 # icinga2 feature enable perfdata
203 By default all performance data files are rotated in a 15 seconds interval into
204 the `/var/spool/icinga2/perfdata/` directory as `host-perfdata.<timestamp>` and
205 `service-perfdata.<timestamp>`.
206 External collectors need to parse the rotated performance data files and then
207 remove the processed files.
209 ### Graphite Carbon Cache Writer <a id="graphite-carbon-cache-writer"></a>
211 While there are some [Graphite](13-addons.md#addons-graphing-graphite)
212 collector scripts and daemons like Graphios available for Icinga 1.x it's more
213 reasonable to directly process the check and plugin performance
214 in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
215 write them to the defined Graphite Carbon daemon tcp socket.
217 You can enable the feature using
219 # icinga2 feature enable graphite
221 By default the [GraphiteWriter](09-object-types.md#objecttype-graphitewriter) feature
222 expects the Graphite Carbon Cache to listen at `127.0.0.1` on TCP port `2003`.
224 #### Current Graphite Schema <a id="graphite-carbon-cache-writer-schema"></a>
226 The current naming schema is defined as follows. The [Icinga Web 2 Graphite module](https://github.com/icinga/icingaweb2-module-graphite)
227 depends on this schema.
229 The default prefix for hosts and services is configured using
230 [runtime macros](03-monitoring-basics.md#runtime-macros)like this:
232 icinga2.$host.name$.host.$host.check_command$
233 icinga2.$host.name$.services.$service.name$.$service.check_command$
235 You can customize the prefix name by using the `host_name_template` and
236 `service_name_template` configuration attributes.
238 The additional levels will allow fine granular filters and also template
239 capabilities, e.g. by using the check command `disk` for specific
240 graph templates in web applications rendering the Graphite data.
242 The following characters are escaped in prefix labels:
244 Character | Escaped character
245 --------------|--------------------------
251 Metric values are stored like this:
253 <prefix>.perfdata.<perfdata-label>.value
255 The following characters are escaped in perfdata labels:
257 Character | Escaped character
258 --------------|--------------------------
264 Note that perfdata labels may contain dots (`.`) allowing to
265 add more subsequent levels inside the Graphite tree.
266 `::` adds support for [multi performance labels](http://my-plugin.de/wiki/projects/check_multi/configuration/performance)
267 and is therefore replaced by `.`.
269 By enabling `enable_send_thresholds` Icinga 2 automatically adds the following threshold metrics:
271 <prefix>.perfdata.<perfdata-label>.min
272 <prefix>.perfdata.<perfdata-label>.max
273 <prefix>.perfdata.<perfdata-label>.warn
274 <prefix>.perfdata.<perfdata-label>.crit
276 By enabling `enable_send_metadata` Icinga 2 automatically adds the following metadata metrics:
278 <prefix>.metadata.current_attempt
279 <prefix>.metadata.downtime_depth
280 <prefix>.metadata.acknowledgement
281 <prefix>.metadata.execution_time
282 <prefix>.metadata.latency
283 <prefix>.metadata.max_check_attempts
284 <prefix>.metadata.reachable
285 <prefix>.metadata.state
286 <prefix>.metadata.state_type
288 Metadata metric overview:
291 -------------------|------------------------------------------
292 current_attempt | current check attempt
293 max_check_attempts | maximum check attempts until the hard state is reached
294 reachable | checked object is reachable
295 downtime_depth | number of downtimes this object is in
296 acknowledgement | whether the object is acknowledged or not
297 execution_time | check execution time
298 latency | check latency
299 state | current state of the checked object
300 state_type | 0=SOFT, 1=HARD state
302 The following example illustrates how to configure the storage schemas for Graphite Carbon
306 # intervals like PNP4Nagios uses them per default
308 retentions = 1m:2d,5m:10d,30m:90d,360m:4y
311 ### InfluxDB Writer <a id="influxdb-writer"></a>
313 Once there are new metrics available, Icinga 2 will directly write them to the
314 defined InfluxDB HTTP API.
316 You can enable the feature using
318 # icinga2 feature enable influxdb
320 By default the [InfluxdbWriter](09-object-types.md#objecttype-influxdbwriter) feature
321 expects the InfluxDB daemon to listen at `127.0.0.1` on port `8086`.
323 Measurement names and tags are fully configurable by the end user. The InfluxdbWriter
324 object will automatically add a `metric` tag to each data point. This correlates to the
325 perfdata label. Fields (value, warn, crit, min, max, unit) are created from data if available
326 and the configuration allows it. If a value associated with a tag is not able to be
327 resolved, it will be dropped and not sent to the target host.
329 Backslashes are allowed in tag keys, tag values and field keys, however they are also
330 escape characters when followed by a space or comma, but cannot be escaped themselves.
331 As a result all trailling slashes in these fields are replaced with an underscore. This
332 predominantly affects Windows paths e.g. `C:\` becomes `C:_`.
334 The database is assumed to exist so this object will make no attempt to create it currently.
336 If [SELinux](22-selinux.md#selinux) is enabled, it will not allow access for Icinga 2 to InfluxDB until the [boolean](22-selinux.md#selinux-policy-booleans)
337 `icinga2_can_connect_all` is set to true as InfluxDB is not providing its own policy.
339 More configuration details can be found [here](09-object-types.md#objecttype-influxdbwriter).
341 #### Instance Tagging <a id="influxdb-writer-instance-tags"></a>
343 Consider the following service check:
346 apply Service "disk" for (disk => attributes in host.vars.disks) {
347 import "generic-service"
348 check_command = "disk"
349 display_name = "Disk " + disk
350 vars.disk_partitions = disk
351 assign where host.vars.disks
355 This is a typical pattern for checking individual disks, NICs, SSL certificates etc associated
356 with a host. What would be useful is to have the data points tagged with the specific instance
357 for that check. This would allow you to query time series data for a check on a host and for a
358 specific instance e.g. /dev/sda. To do this quite simply add the instance to the service variables:
361 apply Service "disk" for (disk => attributes in host.vars.disks) {
368 Then modify your writer configuration to add this tag to your data points if the instance variable
369 is associated with the service:
372 object InfluxdbWriter "influxdb" {
375 measurement = "$service.check_command$"
377 hostname = "$host.name$"
378 service = "$service.name$"
379 instance = "$service.vars.instance$"
386 ### Elastic Stack Integration <a id="elastic-stack-integration"></a>
388 [Icingabeat](https://github.com/icinga/icingabeat) is an Elastic Beat that fetches data
389 from the Icinga 2 API and sends it either directly to [Elasticsearch](https://www.elastic.co/products/elasticsearch)
390 or [Logstash](https://www.elastic.co/products/logstash).
394 * [Logstash output](https://github.com/Icinga/logstash-output-icinga) for the Icinga 2 API.
395 * [Logstash Grok Pattern](https://github.com/Icinga/logstash-grok-pattern) for Icinga 2 logs.
397 #### Elasticsearch Writer <a id="elasticsearch-writer"></a>
399 This feature forwards check results, state changes and notification events
400 to an [Elasticsearch](https://www.elastic.co/products/elasticsearch) installation over its HTTP API.
402 The check results include parsed performance data metrics if enabled.
406 > Elasticsearch 5.x or 6.x are required. This feature has been successfully tested with
407 > Elasticsearch 5.6.7 and 6.3.1.
411 Enable the feature and restart Icinga 2.
414 # icinga2 feature enable elasticsearch
417 The default configuration expects an Elasticsearch instance running on `localhost` on port `9200
418 and writes to an index called `icinga2`.
420 More configuration details can be found [here](09-object-types.md#objecttype-elasticsearchwriter).
422 #### Current Elasticsearch Schema <a id="elastic-writer-schema"></a>
424 The following event types are written to Elasticsearch:
426 * icinga2.event.checkresult
427 * icinga2.event.statechange
428 * icinga2.event.notification
430 Performance data metrics must be explicitly enabled with the `enable_send_perfdata`
433 Metric values are stored like this:
435 check_result.perfdata.<perfdata-label>.value
437 The following characters are escaped in perfdata labels:
439 Character | Escaped character
440 ------------|--------------------------
446 Note that perfdata labels may contain dots (`.`) allowing to
447 add more subsequent levels inside the tree.
448 `::` adds support for [multi performance labels](http://my-plugin.de/wiki/projects/check_multi/configuration/performance)
449 and is therefore replaced by `.`.
451 Icinga 2 automatically adds the following threshold metrics
454 check_result.perfdata.<perfdata-label>.min
455 check_result.perfdata.<perfdata-label>.max
456 check_result.perfdata.<perfdata-label>.warn
457 check_result.perfdata.<perfdata-label>.crit
459 ### Graylog Integration <a id="graylog-integration"></a>
461 #### GELF Writer <a id="gelfwriter"></a>
463 The `Graylog Extended Log Format` (short: [GELF](http://docs.graylog.org/en/latest/pages/gelf.html))
464 can be used to send application logs directly to a TCP socket.
466 While it has been specified by the [Graylog](https://www.graylog.org) project as their
467 [input resource standard](http://docs.graylog.org/en/latest/pages/sending_data.html), other tools such as
468 [Logstash](https://www.elastic.co/products/logstash) also support `GELF` as
469 [input type](https://www.elastic.co/guide/en/logstash/current/plugins-inputs-gelf.html).
471 You can enable the feature using
473 # icinga2 feature enable gelf
475 By default the `GelfWriter` object expects the GELF receiver to listen at `127.0.0.1` on TCP port `12201`.
476 The default `source` attribute is set to `icinga2`. You can customize that for your needs if required.
478 Currently these events are processed:
484 ### OpenTSDB Writer <a id="opentsdb-writer"></a>
486 While there are some OpenTSDB collector scripts and daemons like tcollector available for
487 Icinga 1.x it's more reasonable to directly process the check and plugin performance
488 in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
489 write them to the defined TSDB TCP socket.
491 You can enable the feature using
493 # icinga2 feature enable opentsdb
495 By default the `OpenTsdbWriter` object expects the TSD to listen at
496 `127.0.0.1` on port `4242`.
498 The current naming schema is
500 icinga.host.<metricname>
501 icinga.service.<servicename>.<metricname>
503 for host and service checks. The tag host is always applied.
505 To make sure Icinga 2 writes a valid metric into OpenTSDB some characters are replaced
506 with `_` in the target name:
510 The resulting name in OpenTSDB might look like:
512 www-01 / http-cert / response time
513 icinga.http_cert.response_time
515 In addition to the performance data retrieved from the check plugin, Icinga 2 sends
516 internal check statistic data to OpenTSDB:
519 -------------------|------------------------------------------
520 current_attempt | current check attempt
521 max_check_attempts | maximum check attempts until the hard state is reached
522 reachable | checked object is reachable
523 downtime_depth | number of downtimes this object is in
524 acknowledgement | whether the object is acknowledged or not
525 execution_time | check execution time
526 latency | check latency
527 state | current state of the checked object
528 state_type | 0=SOFT, 1=HARD state
530 While reachable, state and state_type are metrics for the host or service the
531 other metrics follow the current naming schema
533 icinga.check.<metricname>
535 with the following tags
538 --------|------------------------------------------
539 type | the check type, one of [host, service]
540 host | hostname, the check ran on
541 service | the service name (if type=service)
545 > You might want to set the tsd.core.auto_create_metrics setting to `true`
546 > in your opentsdb.conf configuration file.
549 ## Livestatus <a id="setting-up-livestatus"></a>
551 The [MK Livestatus](https://mathias-kettner.de/checkmk_livestatus.html) project
552 implements a query protocol that lets users query their Icinga instance for
553 status information. It can also be used to send commands.
555 The Livestatus component that is distributed as part of Icinga 2 is a
556 re-implementation of the Livestatus protocol which is compatible with MK
561 > Only install the Livestatus feature if your web interface or addon requires
563 > [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2) does not need
566 Details on the available tables and attributes with Icinga 2 can be found
567 in the [Livestatus Schema](24-appendix.md#schema-livestatus) section.
569 You can enable Livestatus using icinga2 feature enable:
571 # icinga2 feature enable livestatus
573 After that you will have to restart Icinga 2:
575 # systemctl restart icinga2
577 By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
579 In order for queries and commands to work you will need to add your query user
580 (e.g. your web server) to the `icingacmd` group:
582 # usermod -a -G icingacmd www-data
584 The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to
585 `nagios` if you're using Debian.
587 Change `www-data` to the user you're using to run queries.
589 In order to use the historical tables provided by the livestatus feature (for example, the
590 `log` table) you need to have the `CompatLogger` feature enabled. By default these logs
591 are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
592 `compat_log_path` configuration attribute.
594 # icinga2 feature enable compatlog
597 ### Livestatus Sockets <a id="livestatus-sockets"></a>
599 Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
601 * Unix socket (default)
604 Details on the configuration can be found in the [LivestatusListener](09-object-types.md#objecttype-livestatuslistener)
605 object configuration.
607 ### Livestatus GET Queries <a id="livestatus-get-queries"></a>
611 > All Livestatus queries require an additional empty line as query end identifier.
612 > The `nc` tool (`netcat`) provides the `-U` parameter to communicate using
615 There also is a Perl module available in CPAN for accessing the Livestatus socket
616 programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Monitoring-Livestatus-0.74/)
619 Example using the unix socket:
621 # echo -e "GET services\n" | /usr/bin/nc -U /var/run/icinga2/cmd/livestatus
623 Example using the tcp socket listening on port `6558`:
625 # echo -e 'GET services\n' | netcat 127.0.0.1 6558
627 # cat servicegroups <<EOF
632 (cat servicegroups; sleep 1) | netcat 127.0.0.1 6558
635 ### Livestatus COMMAND Queries <a id="livestatus-command-queries"></a>
637 A list of available external commands and their parameters can be found [here](24-appendix.md#external-commands-list-detail)
639 $ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
642 ### Livestatus Filters <a id="livestatus-filters"></a>
646 Operator | Negate | Description
647 ----------|----------|-------------
650 =~ | !=~ | Equality ignoring case
651 ~~ | !~~ | Regex ignoring case
654 <= | | Less than or equal
655 >= | | Greater than or equal
658 ### Livestatus Stats <a id="livestatus-stats"></a>
660 Schema: "Stats: aggregatefunction aggregateattribute"
662 Aggregate Function | Description
663 -------------------|--------------
668 std | standard deviation
669 suminv | sum (1 / value)
670 avginv | suminv / count
671 count | ordinary default for any stats query if not aggregate function defined
676 Filter: has_been_checked = 1
677 Filter: check_type = 0
678 Stats: sum execution_time
680 Stats: sum percent_state_change
681 Stats: min execution_time
683 Stats: min percent_state_change
684 Stats: max execution_time
686 Stats: max percent_state_change
688 ResponseHeader: fixed16
690 ### Livestatus Output <a id="livestatus-output"></a>
694 CSV output uses two levels of array separators: The members array separator
695 is a comma (1st level) while extra info and host|service relation separator
696 is a pipe (2nd level).
698 Separators can be set using ASCII codes like:
700 Separators: 10 59 44 124
706 ### Livestatus Error Codes <a id="livestatus-error-codes"></a>
709 ----------|--------------
711 404 | Table does not exist
712 452 | Exception on query
714 ### Livestatus Tables <a id="livestatus-tables"></a>
716 Table | Join |Description
717 --------------|-----------|----------------------------
718 hosts | | host config and status attributes, services counter
719 hostgroups | | hostgroup config, status attributes and host/service counters
720 services | hosts | service config and status attributes
721 servicegroups | | servicegroup config, status attributes and service counters
722 contacts | | contact config and status attributes
723 contactgroups | | contact config, members
724 commands | | command name and line
725 status | | programstatus, config and stats
726 comments | services | status attributes
727 downtimes | services | status attributes
728 timeperiods | | name and is inside flag
729 endpoints | | config and status attributes
730 log | services, hosts, contacts, commands | parses [compatlog](09-object-types.md#objecttype-compatlogger) and shows log attributes
731 statehist | hosts, services | parses [compatlog](09-object-types.md#objecttype-compatlogger) and aggregates state change attributes
732 hostsbygroup | hostgroups | host attributes grouped by hostgroup and its attributes
733 servicesbygroup | servicegroups | service attributes grouped by servicegroup and its attributes
734 servicesbyhostgroup | hostgroups | service attributes grouped by hostgroup and its attributes
736 The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects.
738 A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](24-appendix.md#schema-livestatus).
741 ## Status Data Files <a id="status-data"></a>
745 > This feature is DEPRECATED and will be removed in Icinga 2 v2.11.
747 Icinga 1.x writes object configuration data and status data in a cyclic
748 interval to its `objects.cache` and `status.dat` files. Icinga 2 provides
749 the `StatusDataWriter` object which dumps all configuration objects and
750 status updates in a regular interval.
752 # icinga2 feature enable statusdata
754 If you are not using any web interface or addon which uses these files,
755 you can safely disable this feature.
757 ## Compat Log Files <a id="compat-logging"></a>
761 > This feature is DEPRECATED and will be removed in Icinga 2 v2.11.
763 The Icinga 1.x log format is considered being the `Compat Log`
764 in Icinga 2 provided with the `CompatLogger` object.
766 These logs are used for informational representation in
767 external web interfaces parsing the logs, but also to generate
768 SLA reports and trends.
769 The [Livestatus](14-features.md#setting-up-livestatus) feature uses these logs
770 for answering queries to historical tables.
772 The `CompatLogger` object can be enabled with
774 # icinga2 feature enable compatlog
776 By default, the Icinga 1.x log file called `icinga.log` is located
777 in `/var/log/icinga2/compat`. Rotated log files are moved into
778 `var/log/icinga2/compat/archives`.
780 ## Check Result Files <a id="check-result-files"></a>
784 > This feature is DEPRECATED and will be removed in Icinga 2 v2.11.
786 Icinga 1.x writes its check result files to a temporary spool directory
787 where they are processed in a regular interval.
788 While this is extremely inefficient in performance regards it has been
789 rendered useful for passing passive check results directly into Icinga 1.x
790 skipping the external command pipe.
792 Several clustered/distributed environments and check-aggregation addons
793 use that method. In order to support step-by-step migration of these
794 environments, Icinga 2 supports the `CheckResultReader` object.
796 There is no feature configuration available, but it must be defined
797 on-demand in your Icinga 2 objects configuration.
799 object CheckResultReader "reader" {
800 spool_dir = "/data/check-results"