1 # <a id="icinga2-features"></a> Icinga 2 Features
3 ## <a id="logging"></a> Logging
5 Icinga 2 supports three different types of logging:
8 * Syslog (on *NIX-based operating systems)
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 ## <a id="db-ido"></a> DB IDO
26 The IDO (Icinga Data Output) modules for Icinga 2 take care of exporting all
27 configuration and status information into a database. The IDO database is used
28 by a number of projects including Icinga Web 1.x and 2.
30 Details on the installation can be found in the [Configuring DB IDO](2-getting-started.md#configuring-db-ido-mysql)
31 chapter. Details on the configuration can be found in the
32 [IdoMysqlConnection](6-object-types.md#objecttype-idomysqlconnection) and
33 [IdoPgsqlConnection](6-object-types.md#objecttype-idopgsqlconnection)
34 object configuration documentation.
35 The DB IDO feature supports [High Availability](13-distributed-monitoring-ha.md#high-availability-db-ido) in
38 The following example query checks the health of the current Icinga 2 instance
39 writing its current status to the DB IDO backend table `icinga_programstatus`
40 every 10 seconds. By default it checks 60 seconds into the past which is a reasonable
41 amount of time -- adjust it for your requirements. If the condition is not met,
42 the query returns an empty result.
46 > Use [check plugins](14-addons-plugins.md#plugins) to monitor the backend.
48 Replace the `default` string with your instance name if different.
52 # mysql -u root -p icinga -e "SELECT status_update_time FROM icinga_programstatus ps
53 JOIN icinga_instances i ON ps.instance_id=i.instance_id
54 WHERE (UNIX_TIMESTAMP(ps.status_update_time) > UNIX_TIMESTAMP(NOW())-60)
55 AND i.instance_name='default';"
57 +---------------------+
58 | status_update_time |
59 +---------------------+
60 | 2014-05-29 14:29:56 |
61 +---------------------+
64 Example for PostgreSQL:
66 # export PGPASSWORD=icinga; psql -U icinga -d icinga -c "SELECT ps.status_update_time FROM icinga_programstatus AS ps
67 JOIN icinga_instances AS i ON ps.instance_id=i.instance_id
68 WHERE ((SELECT extract(epoch from status_update_time) FROM icinga_programstatus) > (SELECT extract(epoch from now())-60))
69 AND i.instance_name='default'";
72 ------------------------
73 2014-05-29 15:11:38+02
77 A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](24-appendix.md#schema-db-ido).
80 ## <a id="external-commands"></a> External Commands
82 Icinga 2 provides an external command pipe for processing commands
83 triggering specific actions (for example rescheduling a service check
84 through the web interface).
86 In order to enable the `ExternalCommandListener` configuration use the
87 following command and restart Icinga 2 afterwards:
89 # icinga2 feature enable command
91 Icinga 2 creates the command pipe file as `/var/run/icinga2/cmd/icinga2.cmd`
92 using the default configuration.
94 Web interfaces and other Icinga addons are able to send commands to
95 Icinga 2 through the external command pipe, for example for rescheduling
96 a forced service check:
98 # /bin/echo "[`date +%s`] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;`date +%s`" >> /var/run/icinga2/cmd/icinga2.cmd
100 # tail -f /var/log/messages
102 Oct 17 15:01:25 icinga-server icinga2: Executing external command: [1382014885] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382014885
103 Oct 17 15:01:25 icinga-server icinga2: Rescheduling next check for service 'ping4'
105 A list of currently supported external commands can be found [here](24-appendix.md#external-commands-list-detail).
107 Detailed information on the commands and their required parameters can be found
108 on the [Icinga 1.x documentation](http://docs.icinga.org/latest/en/extcommands2.html).
110 ## <a id="performance-data"></a> Performance Data
112 When a host or service check is executed plugins should provide so-called
113 `performance data`. Next to that additional check performance data
114 can be fetched using Icinga 2 runtime macros such as the check latency
115 or the current service state (or additional custom attributes).
117 The performance data can be passed to external applications which aggregate and
118 store them in their backends. These tools usually generate graphs for historical
119 reporting and trending.
121 Well-known addons processing Icinga performance data are [PNP4Nagios](14-addons-plugins.md#addons-graphing-pnp),
122 [Graphite](14-addons-plugins.md#addons-graphing-graphite) or [OpenTSDB](15-features.md#opentsdb-writer).
124 ### <a id="writing-performance-data-files"></a> Writing Performance Data Files
126 PNP4Nagios and Graphios use performance data collector daemons to fetch
127 the current performance files for their backend updates.
129 Therefore the Icinga 2 [PerfdataWriter](6-object-types.md#objecttype-perfdatawriter)
130 feature allows you to define the output template format for host and services helped
131 with Icinga 2 runtime vars.
133 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$"
134 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$"
136 The default templates are already provided with the Icinga 2 feature configuration
137 which can be enabled using
139 # icinga2 feature enable perfdata
141 By default all performance data files are rotated in a 15 seconds interval into
142 the `/var/spool/icinga2/perfdata/` directory as `host-perfdata.<timestamp>` and
143 `service-perfdata.<timestamp>`.
144 External collectors need to parse the rotated performance data files and then
145 remove the processed files.
147 ### <a id="graphite-carbon-cache-writer"></a> Graphite Carbon Cache Writer
149 While there are some [Graphite](14-addons-plugins.md#addons-graphing-graphite)
150 collector scripts and daemons like Graphios available for Icinga 1.x it's more
151 reasonable to directly process the check and plugin performance
152 in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
153 write them to the defined Graphite Carbon daemon tcp socket.
155 You can enable the feature using
157 # icinga2 feature enable graphite
159 By default the [GraphiteWriter](6-object-types.md#objecttype-graphitewriter) feature
160 expects the Graphite Carbon Cache to listen at `127.0.0.1` on TCP port `2003`.
162 #### <a id="graphite-carbon-cache-writer-schema"></a> Current Graphite Schema
164 The current naming schema is defined as follows. The official Icinga Web 2 Graphite
165 module will use that schema too.
167 The default prefix for hosts and services is configured using
168 [runtime macros](3-monitoring-basics.md#runtime-macros)like this:
170 icinga2.$host.name$.host.$host.check_command$
171 icinga2.$host.name$.services.$service.name$.$service.check_command$
173 You can customize the prefix name by using the `host_name_template` and
174 `service_name_template` configuration attributes.
176 The additional levels will allow fine granular filters and also template
177 capabilities, e.g. by using the check command `disk` for specific
178 graph templates in web applications rendering the Graphite data.
180 The following characters are escaped in prefix labels:
182 Character | Escaped character
183 --------------|--------------------------
189 Metric values are stored like this:
191 <prefix>.perfdata.<perfdata-label>.value
193 The following characters are escaped in perfdata labels:
195 Character | Escaped character
196 --------------|--------------------------
202 Note that perfdata labels may contain dots (`.`) allowing to
203 add more subsequent levels inside the Graphite tree.
204 `::` adds support for [multi performance labels](http://my-plugin.de/wiki/projects/check_multi/configuration/performance)
205 and is therefore replaced by `.`.
207 By enabling `enable_send_thresholds` Icinga 2 automatically adds the following threshold metrics:
209 <prefix>.perfdata.<perfdata-label>.min
210 <prefix>.perfdata.<perfdata-label>.max
211 <prefix>.perfdata.<perfdata-label>.warn
212 <prefix>.perfdata.<perfdata-label>.crit
214 By enabling `enable_send_metadata` Icinga 2 automatically adds the following metadata metrics:
216 <prefix>.metadata.current_attempt
217 <prefix>.metadata.downtime_depth
218 <prefix>.metadata.acknowledgement
219 <prefix>.metadata.execution_time
220 <prefix>.metadata.latency
221 <prefix>.metadata.max_check_attempts
222 <prefix>.metadata.reachable
223 <prefix>.metadata.state
224 <prefix>.metadata.state_type
226 Metadata metric overview:
229 -------------------|------------------------------------------
230 current_attempt | current check attempt
231 max_check_attempts | maximum check attempts until the hard state is reached
232 reachable | checked object is reachable
233 downtime_depth | number of downtimes this object is in
234 acknowledgement | whether the object is acknowledged or not
235 execution_time | check execution time
236 latency | check latency
237 state | current state of the checked object
238 state_type | 0=SOFT, 1=HARD state
240 The following example illustrates how to configure the storage schemas for Graphite Carbon
244 # intervals like PNP4Nagios uses them per default
246 retentions = 1m:2d,5m:10d,30m:90d,360m:4y
248 #### <a id="graphite-carbon-cache-writer-schema-legacy"></a> Graphite Schema < 2.4
250 In order to restore the old legacy schema, you'll need to adopt the `GraphiteWriter`
253 object GraphiteWriter "graphite" {
255 enable_legacy_mode = true
257 host_name_template = "icinga.$host.name$"
258 service_name_template = "icinga.$host.name$.$service.name$"
261 The old legacy naming schema is
263 icinga.<hostname>.<metricname>
264 icinga.<hostname>.<servicename>.<metricname>
266 You can customize the metric prefix name by using the `host_name_template` and
267 `service_name_template` configuration attributes.
269 The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a
270 [global constant](18-language-reference.md#constants) named `GraphiteEnv`. The constant name
271 is freely definable and should be put in the [constants.conf](4-configuring-icinga-2.md#constants-conf) file.
273 const GraphiteEnv = "icinga.env1"
275 object GraphiteWriter "graphite" {
276 host_name_template = GraphiteEnv + ".$host.name$"
277 service_name_template = GraphiteEnv + ".$host.name$.$service.name$"
280 To make sure Icinga 2 writes a valid label into Graphite some characters are replaced
281 with `_` in the target name:
285 The resulting name in Graphite might look like:
287 www-01 / http-cert / response time
288 icinga.www_01.http_cert.response_time
290 In addition to the performance data retrieved from the check plugin, Icinga 2 sends
291 internal check statistic data to Graphite:
294 -------------------|------------------------------------------
295 current_attempt | current check attempt
296 max_check_attempts | maximum check attempts until the hard state is reached
297 reachable | checked object is reachable
298 downtime_depth | number of downtimes this object is in
299 acknowledgement | whether the object is acknowledged or not
300 execution_time | check execution time
301 latency | check latency
302 state | current state of the checked object
303 state_type | 0=SOFT, 1=HARD state
305 The following example illustrates how to configure the storage-schemas for Graphite Carbon
306 Cache. Please make sure that the order is correct because the first match wins.
309 pattern = ^icinga\..*\.(max_check_attempts|reachable|current_attempt|execution_time|latency|state|state_type)
313 # intervals like PNP4Nagios uses them per default
315 retentions = 1m:2d,5m:10d,30m:90d,360m:4y
317 ### <a id="influxdb-writer"></a> InfluxDB Writer
319 Once there are new metrics available, Icinga 2 will directly write them to the
320 defined InfluxDB HTTP API.
322 You can enable the feature using
324 # icinga2 feature enable influxdb
326 By default the [InfluxdbWriter](6-object-types.md#objecttype-influxdbwriter) feature
327 expects the InfluxDB daemon to listen at `127.0.0.1` on port `8086`.
329 More configuration details can be found [here](6-object-types.md#objecttype-influxdbwriter).
331 ### <a id="gelfwriter"></a> GELF Writer
333 The `Graylog Extended Log Format` (short: [GELF](http://www.graylog2.org/resources/gelf))
334 can be used to send application logs directly to a TCP socket.
336 While it has been specified by the [graylog2](http://www.graylog2.org/) project as their
337 [input resource standard](http://www.graylog2.org/resources/gelf), other tools such as
338 [Logstash](http://www.logstash.net) also support `GELF` as
339 [input type](http://logstash.net/docs/latest/inputs/gelf).
341 You can enable the feature using
343 # icinga2 feature enable gelf
345 By default the `GelfWriter` object expects the GELF receiver to listen at `127.0.0.1` on TCP port `12201`.
346 The default `source` attribute is set to `icinga2`. You can customize that for your needs if required.
348 Currently these events are processed:
353 ### <a id="opentsdb-writer"></a> OpenTSDB Writer
355 While there are some OpenTSDB collector scripts and daemons like tcollector available for
356 Icinga 1.x it's more reasonable to directly process the check and plugin performance
357 in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
358 write them to the defined TSDB TCP socket.
360 You can enable the feature using
362 # icinga2 feature enable opentsdb
364 By default the `OpenTsdbWriter` object expects the TSD to listen at
365 `127.0.0.1` on port `4242`.
367 The current naming schema is
369 icinga.host.<metricname>
370 icinga.service.<servicename>.<metricname>
372 for host and service checks. The tag host is always applied.
374 To make sure Icinga 2 writes a valid metric into OpenTSDB some characters are replaced
375 with `_` in the target name:
379 The resulting name in OpenTSDB might look like:
381 www-01 / http-cert / response time
382 icinga.http_cert.response_time
384 In addition to the performance data retrieved from the check plugin, Icinga 2 sends
385 internal check statistic data to OpenTSDB:
388 -------------------|------------------------------------------
389 current_attempt | current check attempt
390 max_check_attempts | maximum check attempts until the hard state is reached
391 reachable | checked object is reachable
392 downtime_depth | number of downtimes this object is in
393 acknowledgement | whether the object is acknowledged or not
394 execution_time | check execution time
395 latency | check latency
396 state | current state of the checked object
397 state_type | 0=SOFT, 1=HARD state
399 While reachable, state and state_type are metrics for the host or service the
400 other metrics follow the current naming schema
402 icinga.check.<metricname>
404 with the following tags
407 --------|------------------------------------------
408 type | the check type, one of [host, service]
409 host | hostname, the check ran on
410 service | the service name (if type=service)
414 > You might want to set the tsd.core.auto_create_metrics setting to `true`
415 > in your opentsdb.conf configuration file.
418 ## <a id="setting-up-livestatus"></a> Livestatus
420 The [MK Livestatus](http://mathias-kettner.de/checkmk_livestatus.html) project
421 implements a query protocol that lets users query their Icinga instance for
422 status information. It can also be used to send commands.
426 > Only install the Livestatus feature if your web interface or addon requires
427 > you to do so (for example, [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2)).
428 > Icinga Classic UI 1.x and Icinga Web 1.x do not use Livestatus as backend.
430 The Livestatus component that is distributed as part of Icinga 2 is a
431 re-implementation of the Livestatus protocol which is compatible with MK
434 Details on the available tables and attributes with Icinga 2 can be found
435 in the [Livestatus Schema](24-appendix.md#schema-livestatus) section.
437 You can enable Livestatus using icinga2 feature enable:
439 # icinga2 feature enable livestatus
441 After that you will have to restart Icinga 2:
443 Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
445 # service icinga2 restart
447 RHEL/CentOS 7 and Fedora:
449 # systemctl restart icinga2
451 By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
453 In order for queries and commands to work you will need to add your query user
454 (e.g. your web server) to the `icingacmd` group:
456 # usermod -a -G icingacmd www-data
458 The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to
459 `nagios` if you're using Debian.
461 Change `www-data` to the user you're using to run queries.
463 In order to use the historical tables provided by the livestatus feature (for example, the
464 `log` table) you need to have the `CompatLogger` feature enabled. By default these logs
465 are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
466 `compat_log_path` configuration attribute.
468 # icinga2 feature enable compatlog
471 ### <a id="livestatus-sockets"></a> Livestatus Sockets
473 Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
475 * Unix socket (default)
478 Details on the configuration can be found in the [LivestatusListener](6-object-types.md#objecttype-livestatuslistener)
479 object configuration.
481 ### <a id="livestatus-get-queries"></a> Livestatus GET Queries
485 > All Livestatus queries require an additional empty line as query end identifier.
486 > The `nc` tool (`netcat`) provides the `-U` parameter to communicate using
489 There also is a Perl module available in CPAN for accessing the Livestatus socket
490 programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Monitoring-Livestatus-0.74/)
493 Example using the unix socket:
495 # echo -e "GET services\n" | /usr/bin/nc -U /var/run/icinga2/cmd/livestatus
497 Example using the tcp socket listening on port `6558`:
499 # echo -e 'GET services\n' | netcat 127.0.0.1 6558
501 # cat servicegroups <<EOF
506 (cat servicegroups; sleep 1) | netcat 127.0.0.1 6558
509 ### <a id="livestatus-command-queries"></a> Livestatus COMMAND Queries
511 A list of available external commands and their parameters can be found [here](24-appendix.md#external-commands-list-detail)
513 $ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
516 ### <a id="livestatus-filters"></a> Livestatus Filters
520 Operator | Negate | Description
521 ----------|------------------------
524 =~ | !=~ | Equality ignoring case
525 ~~ | !~~ | Regex ignoring case
528 <= | | Less than or equal
529 >= | | Greater than or equal
532 ### <a id="livestatus-stats"></a> Livestatus Stats
534 Schema: "Stats: aggregatefunction aggregateattribute"
536 Aggregate Function | Description
537 -------------------|--------------
542 std | standard deviation
543 suminv | sum (1 / value)
544 avginv | suminv / count
545 count | ordinary default for any stats query if not aggregate function defined
550 Filter: has_been_checked = 1
551 Filter: check_type = 0
552 Stats: sum execution_time
554 Stats: sum percent_state_change
555 Stats: min execution_time
557 Stats: min percent_state_change
558 Stats: max execution_time
560 Stats: max percent_state_change
562 ResponseHeader: fixed16
564 ### <a id="livestatus-output"></a> Livestatus Output
568 CSV output uses two levels of array separators: The members array separator
569 is a comma (1st level) while extra info and host|service relation separator
570 is a pipe (2nd level).
572 Separators can be set using ASCII codes like:
574 Separators: 10 59 44 124
580 ### <a id="livestatus-error-codes"></a> Livestatus Error Codes
583 ----------|--------------
585 404 | Table does not exist
586 452 | Exception on query
588 ### <a id="livestatus-tables"></a> Livestatus Tables
590 Table | Join |Description
591 --------------|-----------|----------------------------
592 hosts | | host config and status attributes, services counter
593 hostgroups | | hostgroup config, status attributes and host/service counters
594 services | hosts | service config and status attributes
595 servicegroups | | servicegroup config, status attributes and service counters
596 contacts | | contact config and status attributes
597 contactgroups | | contact config, members
598 commands | | command name and line
599 status | | programstatus, config and stats
600 comments | services | status attributes
601 downtimes | services | status attributes
602 timeperiods | | name and is inside flag
603 endpoints | | config and status attributes
604 log | services, hosts, contacts, commands | parses [compatlog](6-object-types.md#objecttype-compatlogger) and shows log attributes
605 statehist | hosts, services | parses [compatlog](6-object-types.md#objecttype-compatlogger) and aggregates state change attributes
606 hostsbygroup | hostgroups | host attributes grouped by hostgroup and its attributes
607 servicesbygroup | servicegroups | service attributes grouped by servicegroup and its attributes
608 servicesbyhostgroup | hostgroups | service attributes grouped by hostgroup and its attributes
610 The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects.
612 A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](24-appendix.md#schema-livestatus).
615 ## <a id="status-data"></a> Status Data Files
617 Icinga 1.x writes object configuration data and status data in a cyclic
618 interval to its `objects.cache` and `status.dat` files. Icinga 2 provides
619 the `StatusDataWriter` object which dumps all configuration objects and
620 status updates in a regular interval.
622 # icinga2 feature enable statusdata
624 Icinga 1.x Classic UI requires this data set as part of its backend.
628 > If you are not using any web interface or addon which uses these files,
629 > you can safely disable this feature.
632 ## <a id="compat-logging"></a> Compat Log Files
634 The Icinga 1.x log format is considered being the `Compat Log`
635 in Icinga 2 provided with the `CompatLogger` object.
637 These logs are not only used for informational representation in
638 external web interfaces parsing the logs, but also to generate
639 SLA reports and trends in Icinga 1.x Classic UI. Furthermore the
640 [Livestatus](15-features.md#setting-up-livestatus) feature uses these logs for answering queries to
643 The `CompatLogger` object can be enabled with
645 # icinga2 feature enable compatlog
647 By default, the Icinga 1.x log file called `icinga.log` is located
648 in `/var/log/icinga2/compat`. Rotated log files are moved into
649 `var/log/icinga2/compat/archives`.
651 The format cannot be changed without breaking compatibility to
652 existing log parsers.
654 # tail -f /var/log/icinga2/compat/icinga.log
656 [1382115688] LOG ROTATION: HOURLY
657 [1382115688] LOG VERSION: 2.0
658 [1382115688] HOST STATE: CURRENT;localhost;UP;HARD;1;
659 [1382115688] SERVICE STATE: CURRENT;localhost;disk;WARNING;HARD;1;
660 [1382115688] SERVICE STATE: CURRENT;localhost;http;OK;HARD;1;
661 [1382115688] SERVICE STATE: CURRENT;localhost;load;OK;HARD;1;
662 [1382115688] SERVICE STATE: CURRENT;localhost;ping4;OK;HARD;1;
663 [1382115688] SERVICE STATE: CURRENT;localhost;ping6;OK;HARD;1;
664 [1382115688] SERVICE STATE: CURRENT;localhost;processes;WARNING;HARD;1;
665 [1382115688] SERVICE STATE: CURRENT;localhost;ssh;OK;HARD;1;
666 [1382115688] SERVICE STATE: CURRENT;localhost;users;OK;HARD;1;
667 [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;disk;1382115705
668 [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;http;1382115705
669 [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;load;1382115705
670 [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382115705
671 [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping6;1382115705
672 [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;processes;1382115705
673 [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ssh;1382115705
674 [1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;users;1382115705
675 [1382115731] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;localhost;ping6;2;critical test|
676 [1382115731] SERVICE ALERT: localhost;ping6;CRITICAL;SOFT;2;critical test
679 ## <a id="check-result-files"></a> Check Result Files
681 Icinga 1.x writes its check result files to a temporary spool directory
682 where they are processed in a regular interval.
683 While this is extremely inefficient in performance regards it has been
684 rendered useful for passing passive check results directly into Icinga 1.x
685 skipping the external command pipe.
687 Several clustered/distributed environments and check-aggregation addons
688 use that method. In order to support step-by-step migration of these
689 environments, Icinga 2 supports the `CheckResultReader` object.
691 There is no feature configuration available, but it must be defined
692 on-demand in your Icinga 2 objects configuration.
694 object CheckResultReader "reader" {
695 spool_dir = "/data/check-results"