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).
90 ### DB IDO Cleanup <a id="db-ido-cleanup"></a>
92 Objects get deactivated when they are deleted from the configuration.
93 This is visible with the `is_active` column in the `icinga_objects` table.
94 Therefore all queries need to join this table and add `WHERE is_active=1` as
95 condition. Deleted objects preserve their history table entries for later SLA
98 Historical data isn't purged by default. You can enable the least
99 kept data age inside the `cleanup` configuration attribute for the
100 IDO features [IdoMysqlConnection](09-object-types.md#objecttype-idomysqlconnection)
101 and [IdoPgsqlConnection](09-object-types.md#objecttype-idopgsqlconnection).
103 Example if you prefer to keep notification history for 30 days:
107 notifications_age = 30d
108 contactnotifications_age = 30d
112 The historical tables are populated depending on the data `categories` specified.
113 Some tables are empty by default.
115 ### DB IDO Tuning <a id="db-ido-tuning"></a>
117 As with any application database, there are ways to optimize and tune the database performance.
119 General tips for performance tuning:
121 * [MariaDB KB](https://mariadb.com/kb/en/library/optimization-and-tuning/)
122 * [PostgreSQL Wiki](https://wiki.postgresql.org/wiki/Performance_Optimization)
124 Re-creation of indexes, changed column values, etc. will increase the database size. Ensure to
125 add health checks for this, and monitor the trend in your Grafana dashboards.
127 In order to optimize the tables, there are different approaches. Always keep in mind to have a
128 current backup and schedule maintenance downtime for these kind of tasks!
133 mariadb> OPTIMIZE TABLE icinga_statehistory;
138 > Tables might not support optimization at runtime. This can take a **long** time.
140 > `Table does not support optimize, doing recreate + analyze instead`.
142 If you want to optimize all tables in a specified database, there is a script called `mysqlcheck`.
143 This also allows to repair broken tables in the case of emergency.
146 mysqlcheck --optimize icinga
158 > Don't use `VACUUM FULL` as this has a severe impact on performance.
161 ## External Commands <a id="external-commands"></a>
165 > Please use the [REST API](12-icinga2-api.md#icinga2-api) as modern and secure alternative
166 > for external actions.
168 Icinga 2 provides an external command pipe for processing commands
169 triggering specific actions (for example rescheduling a service check
170 through the web interface).
172 In order to enable the `ExternalCommandListener` configuration use the
173 following command and restart Icinga 2 afterwards:
176 # icinga2 feature enable command
179 Icinga 2 creates the command pipe file as `/var/run/icinga2/cmd/icinga2.cmd`
180 using the default configuration.
182 Web interfaces and other Icinga addons are able to send commands to
183 Icinga 2 through the external command pipe, for example for rescheduling
184 a forced service check:
187 # /bin/echo "[`date +%s`] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;`date +%s`" >> /var/run/icinga2/cmd/icinga2.cmd
189 # tail -f /var/log/messages
191 Oct 17 15:01:25 icinga-server icinga2: Executing external command: [1382014885] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382014885
192 Oct 17 15:01:25 icinga-server icinga2: Rescheduling next check for service 'ping4'
195 A list of currently supported external commands can be found [here](24-appendix.md#external-commands-list-detail).
197 Detailed information on the commands and their required parameters can be found
198 on the [Icinga 1.x documentation](https://docs.icinga.com/latest/en/extcommands2.html).
200 ## Performance Data <a id="performance-data"></a>
202 When a host or service check is executed plugins should provide so-called
203 `performance data`. Next to that additional check performance data
204 can be fetched using Icinga 2 runtime macros such as the check latency
205 or the current service state (or additional custom attributes).
207 The performance data can be passed to external applications which aggregate and
208 store them in their backends. These tools usually generate graphs for historical
209 reporting and trending.
211 Well-known addons processing Icinga performance data are [PNP4Nagios](13-addons.md#addons-graphing-pnp),
212 [Graphite](13-addons.md#addons-graphing-graphite) or [OpenTSDB](14-features.md#opentsdb-writer).
214 ### Writing Performance Data Files <a id="writing-performance-data-files"></a>
216 PNP4Nagios and Graphios use performance data collector daemons to fetch
217 the current performance files for their backend updates.
219 Therefore the Icinga 2 [PerfdataWriter](09-object-types.md#objecttype-perfdatawriter)
220 feature allows you to define the output template format for host and services helped
221 with Icinga 2 runtime vars.
224 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$"
225 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$"
228 The default templates are already provided with the Icinga 2 feature configuration
229 which can be enabled using
232 # icinga2 feature enable perfdata
235 By default all performance data files are rotated in a 15 seconds interval into
236 the `/var/spool/icinga2/perfdata/` directory as `host-perfdata.<timestamp>` and
237 `service-perfdata.<timestamp>`.
238 External collectors need to parse the rotated performance data files and then
239 remove the processed files.
241 ### Graphite Carbon Cache Writer <a id="graphite-carbon-cache-writer"></a>
243 While there are some [Graphite](13-addons.md#addons-graphing-graphite)
244 collector scripts and daemons like Graphios available for Icinga 1.x it's more
245 reasonable to directly process the check and plugin performance
246 in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
247 write them to the defined Graphite Carbon daemon tcp socket.
249 You can enable the feature using
252 # icinga2 feature enable graphite
255 By default the [GraphiteWriter](09-object-types.md#objecttype-graphitewriter) feature
256 expects the Graphite Carbon Cache to listen at `127.0.0.1` on TCP port `2003`.
258 #### Current Graphite Schema <a id="graphite-carbon-cache-writer-schema"></a>
260 The current naming schema is defined as follows. The [Icinga Web 2 Graphite module](https://github.com/icinga/icingaweb2-module-graphite)
261 depends on this schema.
263 The default prefix for hosts and services is configured using
264 [runtime macros](03-monitoring-basics.md#runtime-macros)like this:
267 icinga2.$host.name$.host.$host.check_command$
268 icinga2.$host.name$.services.$service.name$.$service.check_command$
271 You can customize the prefix name by using the `host_name_template` and
272 `service_name_template` configuration attributes.
274 The additional levels will allow fine granular filters and also template
275 capabilities, e.g. by using the check command `disk` for specific
276 graph templates in web applications rendering the Graphite data.
278 The following characters are escaped in prefix labels:
280 Character | Escaped character
281 --------------|--------------------------
287 Metric values are stored like this:
290 <prefix>.perfdata.<perfdata-label>.value
293 The following characters are escaped in perfdata labels:
295 Character | Escaped character
296 --------------|--------------------------
302 Note that perfdata labels may contain dots (`.`) allowing to
303 add more subsequent levels inside the Graphite tree.
304 `::` adds support for [multi performance labels](http://my-plugin.de/wiki/projects/check_multi/configuration/performance)
305 and is therefore replaced by `.`.
307 By enabling `enable_send_thresholds` Icinga 2 automatically adds the following threshold metrics:
310 <prefix>.perfdata.<perfdata-label>.min
311 <prefix>.perfdata.<perfdata-label>.max
312 <prefix>.perfdata.<perfdata-label>.warn
313 <prefix>.perfdata.<perfdata-label>.crit
316 By enabling `enable_send_metadata` Icinga 2 automatically adds the following metadata metrics:
319 <prefix>.metadata.current_attempt
320 <prefix>.metadata.downtime_depth
321 <prefix>.metadata.acknowledgement
322 <prefix>.metadata.execution_time
323 <prefix>.metadata.latency
324 <prefix>.metadata.max_check_attempts
325 <prefix>.metadata.reachable
326 <prefix>.metadata.state
327 <prefix>.metadata.state_type
330 Metadata metric overview:
333 -------------------|------------------------------------------
334 current_attempt | current check attempt
335 max_check_attempts | maximum check attempts until the hard state is reached
336 reachable | checked object is reachable
337 downtime_depth | number of downtimes this object is in
338 acknowledgement | whether the object is acknowledged or not
339 execution_time | check execution time
340 latency | check latency
341 state | current state of the checked object
342 state_type | 0=SOFT, 1=HARD state
344 The following example illustrates how to configure the storage schemas for Graphite Carbon
349 # intervals like PNP4Nagios uses them per default
351 retentions = 1m:2d,5m:10d,30m:90d,360m:4y
355 ### InfluxDB Writer <a id="influxdb-writer"></a>
357 Once there are new metrics available, Icinga 2 will directly write them to the
358 defined InfluxDB HTTP API.
360 You can enable the feature using
363 # icinga2 feature enable influxdb
366 By default the [InfluxdbWriter](09-object-types.md#objecttype-influxdbwriter) feature
367 expects the InfluxDB daemon to listen at `127.0.0.1` on port `8086`.
369 Measurement names and tags are fully configurable by the end user. The InfluxdbWriter
370 object will automatically add a `metric` tag to each data point. This correlates to the
371 perfdata label. Fields (value, warn, crit, min, max, unit) are created from data if available
372 and the configuration allows it. If a value associated with a tag is not able to be
373 resolved, it will be dropped and not sent to the target host.
375 Backslashes are allowed in tag keys, tag values and field keys, however they are also
376 escape characters when followed by a space or comma, but cannot be escaped themselves.
377 As a result all trailling slashes in these fields are replaced with an underscore. This
378 predominantly affects Windows paths e.g. `C:\` becomes `C:_`.
380 The database is assumed to exist so this object will make no attempt to create it currently.
382 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)
383 `icinga2_can_connect_all` is set to true as InfluxDB is not providing its own policy.
385 More configuration details can be found [here](09-object-types.md#objecttype-influxdbwriter).
387 #### Instance Tagging <a id="influxdb-writer-instance-tags"></a>
389 Consider the following service check:
392 apply Service "disk" for (disk => attributes in host.vars.disks) {
393 import "generic-service"
394 check_command = "disk"
395 display_name = "Disk " + disk
396 vars.disk_partitions = disk
397 assign where host.vars.disks
401 This is a typical pattern for checking individual disks, NICs, SSL certificates etc associated
402 with a host. What would be useful is to have the data points tagged with the specific instance
403 for that check. This would allow you to query time series data for a check on a host and for a
404 specific instance e.g. /dev/sda. To do this quite simply add the instance to the service variables:
407 apply Service "disk" for (disk => attributes in host.vars.disks) {
414 Then modify your writer configuration to add this tag to your data points if the instance variable
415 is associated with the service:
418 object InfluxdbWriter "influxdb" {
421 measurement = "$service.check_command$"
423 hostname = "$host.name$"
424 service = "$service.name$"
425 instance = "$service.vars.instance$"
432 ### Elastic Stack Integration <a id="elastic-stack-integration"></a>
434 [Icingabeat](https://github.com/icinga/icingabeat) is an Elastic Beat that fetches data
435 from the Icinga 2 API and sends it either directly to [Elasticsearch](https://www.elastic.co/products/elasticsearch)
436 or [Logstash](https://www.elastic.co/products/logstash).
440 * [Logstash output](https://github.com/Icinga/logstash-output-icinga) for the Icinga 2 API.
441 * [Logstash Grok Pattern](https://github.com/Icinga/logstash-grok-pattern) for Icinga 2 logs.
443 #### Elasticsearch Writer <a id="elasticsearch-writer"></a>
445 This feature forwards check results, state changes and notification events
446 to an [Elasticsearch](https://www.elastic.co/products/elasticsearch) installation over its HTTP API.
448 The check results include parsed performance data metrics if enabled.
452 > Elasticsearch 5.x or 6.x are required. This feature has been successfully tested with
453 > Elasticsearch 5.6.7 and 6.3.1.
457 Enable the feature and restart Icinga 2.
460 # icinga2 feature enable elasticsearch
463 The default configuration expects an Elasticsearch instance running on `localhost` on port `9200
464 and writes to an index called `icinga2`.
466 More configuration details can be found [here](09-object-types.md#objecttype-elasticsearchwriter).
468 #### Current Elasticsearch Schema <a id="elastic-writer-schema"></a>
470 The following event types are written to Elasticsearch:
472 * icinga2.event.checkresult
473 * icinga2.event.statechange
474 * icinga2.event.notification
476 Performance data metrics must be explicitly enabled with the `enable_send_perfdata`
479 Metric values are stored like this:
482 check_result.perfdata.<perfdata-label>.value
485 The following characters are escaped in perfdata labels:
487 Character | Escaped character
488 ------------|--------------------------
494 Note that perfdata labels may contain dots (`.`) allowing to
495 add more subsequent levels inside the tree.
496 `::` adds support for [multi performance labels](http://my-plugin.de/wiki/projects/check_multi/configuration/performance)
497 and is therefore replaced by `.`.
499 Icinga 2 automatically adds the following threshold metrics
503 check_result.perfdata.<perfdata-label>.min
504 check_result.perfdata.<perfdata-label>.max
505 check_result.perfdata.<perfdata-label>.warn
506 check_result.perfdata.<perfdata-label>.crit
509 ### Graylog Integration <a id="graylog-integration"></a>
511 #### GELF Writer <a id="gelfwriter"></a>
513 The `Graylog Extended Log Format` (short: [GELF](http://docs.graylog.org/en/latest/pages/gelf.html))
514 can be used to send application logs directly to a TCP socket.
516 While it has been specified by the [Graylog](https://www.graylog.org) project as their
517 [input resource standard](http://docs.graylog.org/en/latest/pages/sending_data.html), other tools such as
518 [Logstash](https://www.elastic.co/products/logstash) also support `GELF` as
519 [input type](https://www.elastic.co/guide/en/logstash/current/plugins-inputs-gelf.html).
521 You can enable the feature using
524 # icinga2 feature enable gelf
527 By default the `GelfWriter` object expects the GELF receiver to listen at `127.0.0.1` on TCP port `12201`.
528 The default `source` attribute is set to `icinga2`. You can customize that for your needs if required.
530 Currently these events are processed:
536 ### OpenTSDB Writer <a id="opentsdb-writer"></a>
538 While there are some OpenTSDB collector scripts and daemons like tcollector available for
539 Icinga 1.x it's more reasonable to directly process the check and plugin performance
540 in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
541 write them to the defined TSDB TCP socket.
543 You can enable the feature using
546 # icinga2 feature enable opentsdb
549 By default the `OpenTsdbWriter` object expects the TSD to listen at
550 `127.0.0.1` on port `4242`.
552 The current naming schema is
555 icinga.host.<metricname>
556 icinga.service.<servicename>.<metricname>
559 for host and service checks. The tag host is always applied.
561 To make sure Icinga 2 writes a valid metric into OpenTSDB some characters are replaced
562 with `_` in the target name:
568 The resulting name in OpenTSDB might look like:
571 www-01 / http-cert / response time
572 icinga.http_cert.response_time
575 In addition to the performance data retrieved from the check plugin, Icinga 2 sends
576 internal check statistic data to OpenTSDB:
579 -------------------|------------------------------------------
580 current_attempt | current check attempt
581 max_check_attempts | maximum check attempts until the hard state is reached
582 reachable | checked object is reachable
583 downtime_depth | number of downtimes this object is in
584 acknowledgement | whether the object is acknowledged or not
585 execution_time | check execution time
586 latency | check latency
587 state | current state of the checked object
588 state_type | 0=SOFT, 1=HARD state
590 While reachable, state and state_type are metrics for the host or service the
591 other metrics follow the current naming schema
594 icinga.check.<metricname>
597 with the following tags
600 --------|------------------------------------------
601 type | the check type, one of [host, service]
602 host | hostname, the check ran on
603 service | the service name (if type=service)
607 > You might want to set the tsd.core.auto_create_metrics setting to `true`
608 > in your opentsdb.conf configuration file.
611 ## Livestatus <a id="setting-up-livestatus"></a>
613 The [MK Livestatus](https://mathias-kettner.de/checkmk_livestatus.html) project
614 implements a query protocol that lets users query their Icinga instance for
615 status information. It can also be used to send commands.
617 The Livestatus component that is distributed as part of Icinga 2 is a
618 re-implementation of the Livestatus protocol which is compatible with MK
623 > Only install the Livestatus feature if your web interface or addon requires
625 > [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2) does not need
628 Details on the available tables and attributes with Icinga 2 can be found
629 in the [Livestatus Schema](24-appendix.md#schema-livestatus) section.
631 You can enable Livestatus using icinga2 feature enable:
634 # icinga2 feature enable livestatus
637 After that you will have to restart Icinga 2:
640 # systemctl restart icinga2
643 By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
645 In order for queries and commands to work you will need to add your query user
646 (e.g. your web server) to the `icingacmd` group:
649 # usermod -a -G icingacmd www-data
652 The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to
653 `nagios` if you're using Debian.
655 Change `www-data` to the user you're using to run queries.
657 In order to use the historical tables provided by the livestatus feature (for example, the
658 `log` table) you need to have the `CompatLogger` feature enabled. By default these logs
659 are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
660 `compat_log_path` configuration attribute.
663 # icinga2 feature enable compatlog
666 ### Livestatus Sockets <a id="livestatus-sockets"></a>
668 Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
670 * Unix socket (default)
673 Details on the configuration can be found in the [LivestatusListener](09-object-types.md#objecttype-livestatuslistener)
674 object configuration.
676 ### Livestatus GET Queries <a id="livestatus-get-queries"></a>
680 > All Livestatus queries require an additional empty line as query end identifier.
681 > The `nc` tool (`netcat`) provides the `-U` parameter to communicate using
684 There also is a Perl module available in CPAN for accessing the Livestatus socket
685 programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Monitoring-Livestatus-0.74/)
688 Example using the unix socket:
691 # echo -e "GET services\n" | /usr/bin/nc -U /var/run/icinga2/cmd/livestatus
693 Example using the tcp socket listening on port `6558`:
695 # echo -e 'GET services\n' | netcat 127.0.0.1 6558
697 # cat servicegroups <<EOF
702 (cat servicegroups; sleep 1) | netcat 127.0.0.1 6558
705 ### Livestatus COMMAND Queries <a id="livestatus-command-queries"></a>
707 A list of available external commands and their parameters can be found [here](24-appendix.md#external-commands-list-detail)
710 $ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
713 ### Livestatus Filters <a id="livestatus-filters"></a>
717 Operator | Negate | Description
718 ----------|----------|-------------
721 =~ | !=~ | Equality ignoring case
722 ~~ | !~~ | Regex ignoring case
725 <= | | Less than or equal
726 >= | | Greater than or equal
729 ### Livestatus Stats <a id="livestatus-stats"></a>
731 Schema: "Stats: aggregatefunction aggregateattribute"
733 Aggregate Function | Description
734 -------------------|--------------
739 std | standard deviation
740 suminv | sum (1 / value)
741 avginv | suminv / count
742 count | ordinary default for any stats query if not aggregate function defined
748 Filter: has_been_checked = 1
749 Filter: check_type = 0
750 Stats: sum execution_time
752 Stats: sum percent_state_change
753 Stats: min execution_time
755 Stats: min percent_state_change
756 Stats: max execution_time
758 Stats: max percent_state_change
760 ResponseHeader: fixed16
763 ### Livestatus Output <a id="livestatus-output"></a>
767 CSV output uses two levels of array separators: The members array separator
768 is a comma (1st level) while extra info and host|service relation separator
769 is a pipe (2nd level).
771 Separators can be set using ASCII codes like:
774 Separators: 10 59 44 124
781 ### Livestatus Error Codes <a id="livestatus-error-codes"></a>
784 ----------|--------------
786 404 | Table does not exist
787 452 | Exception on query
789 ### Livestatus Tables <a id="livestatus-tables"></a>
791 Table | Join |Description
792 --------------|-----------|----------------------------
793 hosts | | host config and status attributes, services counter
794 hostgroups | | hostgroup config, status attributes and host/service counters
795 services | hosts | service config and status attributes
796 servicegroups | | servicegroup config, status attributes and service counters
797 contacts | | contact config and status attributes
798 contactgroups | | contact config, members
799 commands | | command name and line
800 status | | programstatus, config and stats
801 comments | services | status attributes
802 downtimes | services | status attributes
803 timeperiods | | name and is inside flag
804 endpoints | | config and status attributes
805 log | services, hosts, contacts, commands | parses [compatlog](09-object-types.md#objecttype-compatlogger) and shows log attributes
806 statehist | hosts, services | parses [compatlog](09-object-types.md#objecttype-compatlogger) and aggregates state change attributes
807 hostsbygroup | hostgroups | host attributes grouped by hostgroup and its attributes
808 servicesbygroup | servicegroups | service attributes grouped by servicegroup and its attributes
809 servicesbyhostgroup | hostgroups | service attributes grouped by hostgroup and its attributes
811 The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects.
813 A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](24-appendix.md#schema-livestatus).
816 ## Status Data Files <a id="status-data"></a>
820 > This feature is DEPRECATED and will be removed in Icinga 2 v2.11.
822 Icinga 1.x writes object configuration data and status data in a cyclic
823 interval to its `objects.cache` and `status.dat` files. Icinga 2 provides
824 the `StatusDataWriter` object which dumps all configuration objects and
825 status updates in a regular interval.
828 # icinga2 feature enable statusdata
831 If you are not using any web interface or addon which uses these files,
832 you can safely disable this feature.
834 ## Compat Log Files <a id="compat-logging"></a>
838 > This feature is DEPRECATED and will be removed in Icinga 2 v2.11.
840 The Icinga 1.x log format is considered being the `Compat Log`
841 in Icinga 2 provided with the `CompatLogger` object.
843 These logs are used for informational representation in
844 external web interfaces parsing the logs, but also to generate
845 SLA reports and trends.
846 The [Livestatus](14-features.md#setting-up-livestatus) feature uses these logs
847 for answering queries to historical tables.
849 The `CompatLogger` object can be enabled with
852 # icinga2 feature enable compatlog
855 By default, the Icinga 1.x log file called `icinga.log` is located
856 in `/var/log/icinga2/compat`. Rotated log files are moved into
857 `var/log/icinga2/compat/archives`.
859 ## Check Result Files <a id="check-result-files"></a>
863 > This feature is DEPRECATED and will be removed in Icinga 2 v2.11.
865 Icinga 1.x writes its check result files to a temporary spool directory
866 where they are processed in a regular interval.
867 While this is extremely inefficient in performance regards it has been
868 rendered useful for passing passive check results directly into Icinga 1.x
869 skipping the external command pipe.
871 Several clustered/distributed environments and check-aggregation addons
872 use that method. In order to support step-by-step migration of these
873 environments, Icinga 2 supports the `CheckResultReader` object.
875 There is no feature configuration available, but it must be defined
876 on-demand in your Icinga 2 objects configuration.
879 object CheckResultReader "reader" {
880 spool_dir = "/data/check-results"