"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "doc/14-features.md" between
icinga2-2.11.5.tar.gz and icinga2-2.12.0.tar.gz

About: Icinga 2 is an enterprise grade monitoring system which keeps watch over networks and any conceivable network resource.

14-features.md  (icinga2-2.11.5):14-features.md  (icinga2-2.12.0)
skipping to change at line 47 skipping to change at line 47
* `/var/log/icinga2/error.log` * `/var/log/icinga2/error.log`
By default, log files will be rotated daily. By default, log files will be rotated daily.
## Core Backends <a id="core-backends"></a> ## Core Backends <a id="core-backends"></a>
### REST API <a id="core-backends-api"></a> ### REST API <a id="core-backends-api"></a>
The REST API is documented [here](12-icinga2-api.md#icinga2-api) as a core featu re. The REST API is documented [here](12-icinga2-api.md#icinga2-api) as a core featu re.
### Icinga DB <a id="core-backends-icingadb"></a>
Icinga DB provides a new core backend and aims to replace the IDO backend
output. It consists of different components:
* Icinga 2 provides the `icingadb` feature which stores monitoring data in a mem
ory database
* The [IcingaDB service](https://github.com/icinga/icingadb) collects and synchr
onizes monitoring data into its backend
* Icinga Web reads monitoring data from the new IcingaDB backend
Requirements:
* Local Redis instance
* MySQL/MariaDB server with `icingadb` database, user and schema imports
* Icinga 2's `icingadb` feature enabled
* IcingaDB service requires Redis and MySQL/MariaDB server
* Icinga Web module
Consult the [Icinga DB section](02-installation.md#configuring-icinga-db) in the
installation chapter for setup instructions.
### IDO Database (DB IDO) <a id="db-ido"></a> ### IDO Database (DB IDO) <a id="db-ido"></a>
The IDO (Icinga Data Output) feature for Icinga 2 takes care of exporting all The IDO (Icinga Data Output) feature for Icinga 2 takes care of exporting all
configuration and status information into a database. The IDO database is used configuration and status information into a database. The IDO database is used
by Icinga Web 2 as data backend. by Icinga Web 2 as data backend.
Details on the installation can be found in the [Configuring DB IDO](02-installa tion.md#configuring-db-ido-mysql) Details on the installation can be found in the [Configuring DB IDO](02-installa tion.md#configuring-db-ido-mysql)
chapter. Details on the configuration can be found in the chapter. Details on the configuration can be found in the
[IdoMysqlConnection](09-object-types.md#objecttype-idomysqlconnection) and [IdoMysqlConnection](09-object-types.md#objecttype-idomysqlconnection) and
[IdoPgsqlConnection](09-object-types.md#objecttype-idopgsqlconnection) [IdoPgsqlConnection](09-object-types.md#objecttype-idopgsqlconnection)
skipping to change at line 592 skipping to change at line 611
You can enable the feature using You can enable the feature using
``` ```
# icinga2 feature enable opentsdb # icinga2 feature enable opentsdb
``` ```
By default the `OpenTsdbWriter` object expects the TSD to listen at By default the `OpenTsdbWriter` object expects the TSD to listen at
`127.0.0.1` on port `4242`. `127.0.0.1` on port `4242`.
The current naming schema is The current default naming schema is:
``` ```
icinga.host.<metricname> icinga.host.<perfdata_metric_label>
icinga.service.<servicename>.<metricname> icinga.service.<servicename>.<perfdata_metric_label>
``` ```
for host and service checks. The tag host is always applied. for host and service checks. The tag `host` is always applied.
Icinga also sends perfdata warning, critical, minimum and maximum threshold valu
es to OpenTSDB.
These are stored as new OpenTSDB metric names appended with `_warn`, `_crit`, `_
min`, `_max`.
Values are only stored when the corresponding threshold exists in Icinga's perfd
ata.
Example:
```
icinga.service.<servicename>.<perfdata_metric_label>
icinga.service.<servicename>.<perfdata_metric_label>._warn
icinga.service.<servicename>.<perfdata_metric_label>._crit
icinga.service.<servicename>.<perfdata_metric_label>._min
icinga.service.<servicename>.<perfdata_metric_label>._max
```
To make sure Icinga 2 writes a valid metric into OpenTSDB some characters are re placed To make sure Icinga 2 writes a valid metric into OpenTSDB some characters are re placed
with `_` in the target name: with `_` in the target name:
``` ```
\ (and space) \ : (and space)
``` ```
The resulting name in OpenTSDB might look like: The resulting name in OpenTSDB might look like:
``` ```
www-01 / http-cert / response time www-01 / http-cert / response time
icinga.http_cert.response_time icinga.http_cert.response_time
``` ```
In addition to the performance data retrieved from the check plugin, Icinga 2 se nds In addition to the performance data retrieved from the check plugin, Icinga 2 se nds
skipping to change at line 650 skipping to change at line 682
--------|------------------------------------------ --------|------------------------------------------
type | the check type, one of [host, service] type | the check type, one of [host, service]
host | hostname, the check ran on host | hostname, the check ran on
service | the service name (if type=service) service | the service name (if type=service)
> **Note** > **Note**
> >
> You might want to set the tsd.core.auto_create_metrics setting to `true` > You might want to set the tsd.core.auto_create_metrics setting to `true`
> in your opentsdb.conf configuration file. > in your opentsdb.conf configuration file.
#### OpenTSDB Metric Prefix <a id="opentsdb-metric-prefix"></a>
Functionality exists to modify the built in OpenTSDB metric names that the plugi
n
writes to. By default this is `icinga.host` and `icinga.service.<servicename>`.
These prefixes can be modified as necessary to any arbitary string. The prefix
configuration also supports Icinga macros, so if you rather use `<checkcommand>`
or any other variable instead of `<servicename>` you may do so.
To configure OpenTSDB metric name prefixes, create or modify the `host_template`
and/or
`service_template` blocks in the `opentsdb.conf` file, to add a `metric` definit
ion.
These modifications go hand in hand with the **OpenTSDB Custom Tag Support** det
ailed below,
and more information around macro use can be found there.
Additionally, using custom Metric Prefixes or your own macros in the prefix may
be
helpful if you are using the **OpenTSDB Generic Metric** functionality detailed
below.
An example configuration which includes prefix name modification:
```
object OpenTsdbWriter "opentsdb" {
host = "127.0.0.1"
port = 4242
host_template = {
metric = "icinga.myhost"
tags = {
location = "$host.vars.location$"
checkcommand = "$host.check_command$"
}
}
service_template = {
metric = "icinga.service.$service.check_command$"
}
}
```
The above configuration will output the following naming schema:
```
icinga.myhost.<perfdata_metric_label>
icinga.service.<check_command_name>.<perfdata_metric_label>
```
Note how `<perfdata_metric_label>` is always appended in the default naming sche
ma mode.
#### OpenTSDB Generic Metric Naming Schema <a id="opentsdb-generic-metrics"></a>
An alternate naming schema (`Generic Metrics`) is available where OpenTSDB metri
c names are more generic
and do not include the Icinga perfdata label in the metric name. Instead,
perfdata labels are stored in a tag `label` which is stored along with each perf
data value.
This ultimately reduces the number of unique OpenTSDB metric names which may mak
e
querying aggregate data easier. This also allows you to store all perfdata value
s for a
particular check inside one OpenTSDB metric name for each check.
This alternate naming schema can be enabled by setting the following in the Open
TSDBWriter config:
`enable_generic_metrics = true`
> **Tip**
> Consider using `Generic Metrics` along with the **OpenTSDB Metric Prefix** nam
ing options
> described above
An example of this naming schema when compared to the default is:
```
icinga.host
icinga.service.<servicename>
```
> **Note**
> Note how `<perfdata_metric_label>` does not appear in the OpenTSDB metric name
> when using `Generic Metrics`. Instead, a new tag `label` appears on each value
written
> to OpenTSDB which contains the perfdata label.
#### Custom Tags <a id="opentsdb-custom-tags"></a>
In addition to the default tags listed above, it is possible to send
your own custom tags with your data to OpenTSDB.
Note that custom tags are sent **in addition** to the default hostname,
type and service name tags. If you do not include this section in the
config file, no custom tags will be included.
Custom tags can be custom attributes or built in attributes.
Consider a host object:
```
object Host "my-server1" {
address = "10.0.0.1"
check_command = "hostalive"
vars.location = "Australia"
}
```
and a service object:
```
object Service "ping" {
host_name = "localhost"
check_command = "my-ping"
vars.ping_packets = 10
}
```
It is possible to send `vars.location` and `vars.ping_packets` along
with performance data. Additionally, any other attribute can be sent
as a tag, such as `check_command`.
You can make use of the `host_template` and `service_template` blocks
in the `opentsdb.conf` configuration file.
An example OpenTSDB configuration file which makes use of custom tags:
```
object OpenTsdbWriter "opentsdb" {
host = "127.0.0.1"
port = 4242
host_template = {
tags = {
location = "$host.vars.location$"
checkcommand = "$host.check_command$"
}
}
service_template = {
tags = {
location = "$host.vars.location$"
pingpackets = "$service.vars.ping_packets$"
checkcommand = "$service.check_command$"
}
}
}
```
Depending on what keyword the macro begins with, will determine what
attributes are available in the macro context. The below table explains
what attributes are available with links to each object type.
start of macro | description
---------------|------------------------------------------
\$host...$ | Attributes available on a [Host object](09-object-types.md#ob
jecttype-host)
\$service...$ | Attributes available on a [Service object](09-object-types.md
#objecttype-service)
\$icinga...$ | Attributes available on the [IcingaApplication object](09-obj
ect-types.md#objecttype-icingaapplication)
> **Note**
>
> Ensure you do not name your custom attributes with a dot in the name.
> Dots located inside a macro tell the interpreter to expand a
> dictionary.
>
> Do not do this in your object configuration:
>
> `vars["my.attribute"]`
>
> as you will be unable to reference `my.attribute` because it is not a
> dictionary.
>
> Instead, use underscores or another character:
>
> `vars.my_attribute` or `vars["my_attribute"]`
#### OpenTSDB in Cluster HA Zones <a id="opentsdb-writer-cluster-ha"></a> #### OpenTSDB in Cluster HA Zones <a id="opentsdb-writer-cluster-ha"></a>
The OpenTSDB feature supports [high availability](06-distributed-monitoring.md#d istributed-monitoring-high-availability-features) The OpenTSDB feature supports [high availability](06-distributed-monitoring.md#d istributed-monitoring-high-availability-features)
in cluster zones since 2.11. in cluster zones since 2.11.
By default, all endpoints in a zone will activate the feature and start By default, all endpoints in a zone will activate the feature and start
writing events to the OpenTSDB listener. In HA enabled scenarios, writing events to the OpenTSDB listener. In HA enabled scenarios,
it is possible to set `enable_ha = true` in all feature configuration it is possible to set `enable_ha = true` in all feature configuration
files. This allows each endpoint to calculate the feature authority, files. This allows each endpoint to calculate the feature authority,
and only one endpoint actively writes metrics, the other endpoints and only one endpoint actively writes metrics, the other endpoints
skipping to change at line 716 skipping to change at line 907
pause the feature. pause the feature.
When the cluster connection breaks at some point, the remaining endpoint(s) When the cluster connection breaks at some point, the remaining endpoint(s)
in that zone will automatically resume the feature. This built-in failover in that zone will automatically resume the feature. This built-in failover
mechanism ensures that metrics are written even if the cluster fails. mechanism ensures that metrics are written even if the cluster fails.
The recommended way of running Perfdata is to mount the perfdata spool The recommended way of running Perfdata is to mount the perfdata spool
directory via NFS on a central server where PNP with the NPCD collector directory via NFS on a central server where PNP with the NPCD collector
is running on. is running on.
## Livestatus <a id="setting-up-livestatus"></a> ## Deprecated Features <a id="deprecated-features"></a>
### Status Data Files <a id="status-data"></a>
> **Note**
>
> This feature is DEPRECATED and will be removed in future releases.
> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
Icinga 1.x writes object configuration data and status data in a cyclic
interval to its `objects.cache` and `status.dat` files. Icinga 2 provides
the `StatusDataWriter` object which dumps all configuration objects and
status updates in a regular interval.
```
# icinga2 feature enable statusdata
```
If you are not using any web interface or addon which uses these files,
you can safely disable this feature.
### Compat Log Files <a id="compat-logging"></a>
> **Note**
>
> This feature is DEPRECATED and will be removed in future releases.
> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
The Icinga 1.x log format is considered being the `Compat Log`
in Icinga 2 provided with the `CompatLogger` object.
These logs are used for informational representation in
external web interfaces parsing the logs, but also to generate
SLA reports and trends.
The [Livestatus](14-features.md#setting-up-livestatus) feature uses these logs
for answering queries to historical tables.
The `CompatLogger` object can be enabled with
```
# icinga2 feature enable compatlog
```
By default, the Icinga 1.x log file called `icinga.log` is located
in `/var/log/icinga2/compat`. Rotated log files are moved into
`var/log/icinga2/compat/archives`.
### External Command Pipe <a id="external-commands"></a>
> **Note**
>
> Please use the [REST API](12-icinga2-api.md#icinga2-api) as modern and secure
alternative
> for external actions.
> **Note**
>
> This feature is DEPRECATED and will be removed in future releases.
> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
Icinga 2 provides an external command pipe for processing commands
triggering specific actions (for example rescheduling a service check
through the web interface).
In order to enable the `ExternalCommandListener` configuration use the
following command and restart Icinga 2 afterwards:
```
# icinga2 feature enable command
```
Icinga 2 creates the command pipe file as `/var/run/icinga2/cmd/icinga2.cmd`
using the default configuration.
Web interfaces and other Icinga addons are able to send commands to
Icinga 2 through the external command pipe, for example for rescheduling
a forced service check:
```
# /bin/echo "[`date +%s`] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;`date +%s`"
>> /var/run/icinga2/cmd/icinga2.cmd
# tail -f /var/log/messages
Oct 17 15:01:25 icinga-server icinga2: Executing external command: [1382014885]
SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382014885
Oct 17 15:01:25 icinga-server icinga2: Rescheduling next check for service 'ping
4'
```
A list of currently supported external commands can be found [here](24-appendix.
md#external-commands-list-detail).
Detailed information on the commands and their required parameters can be found
on the [Icinga 1.x documentation](https://docs.icinga.com/latest/en/extcommands2
.html).
### Check Result Files <a id="check-result-files"></a>
> **Note**
>
> This feature is DEPRECATED and will be removed in future releases.
> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
Icinga 1.x writes its check result files to a temporary spool directory
where they are processed in a regular interval.
While this is extremely inefficient in performance regards it has been
rendered useful for passing passive check results directly into Icinga 1.x
skipping the external command pipe.
Several clustered/distributed environments and check-aggregation addons
use that method. In order to support step-by-step migration of these
environments, Icinga 2 supports the `CheckResultReader` object.
There is no feature configuration available, but it must be defined
on-demand in your Icinga 2 objects configuration.
```
object CheckResultReader "reader" {
spool_dir = "/data/check-results"
}
```
### Livestatus <a id="setting-up-livestatus"></a>
> **Note**
>
> This feature is DEPRECATED and will be removed in future releases.
> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
The [MK Livestatus](https://mathias-kettner.de/checkmk_livestatus.html) project The [MK Livestatus](https://mathias-kettner.de/checkmk_livestatus.html) project
implements a query protocol that lets users query their Icinga instance for implements a query protocol that lets users query their Icinga instance for
status information. It can also be used to send commands. status information. It can also be used to send commands.
The Livestatus component that is distributed as part of Icinga 2 is a The Livestatus component that is distributed as part of Icinga 2 is a
re-implementation of the Livestatus protocol which is compatible with MK re-implementation of the Livestatus protocol which is compatible with MK
Livestatus. Livestatus.
> **Tip** > **Tip**
skipping to change at line 771 skipping to change at line 1084
In order to use the historical tables provided by the livestatus feature (for ex ample, the In order to use the historical tables provided by the livestatus feature (for ex ample, the
`log` table) you need to have the `CompatLogger` feature enabled. By default the se logs `log` table) you need to have the `CompatLogger` feature enabled. By default the se logs
are expected to be in `/var/log/icinga2/compat`. A different path can be set usi ng the are expected to be in `/var/log/icinga2/compat`. A different path can be set usi ng the
`compat_log_path` configuration attribute. `compat_log_path` configuration attribute.
``` ```
# icinga2 feature enable compatlog # icinga2 feature enable compatlog
``` ```
### Livestatus Sockets <a id="livestatus-sockets"></a> #### Livestatus Sockets <a id="livestatus-sockets"></a>
Other to the Icinga 1.x Addon, Icinga 2 supports two socket types Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
* Unix socket (default) * Unix socket (default)
* TCP socket * TCP socket
Details on the configuration can be found in the [LivestatusListener](09-object- types.md#objecttype-livestatuslistener) Details on the configuration can be found in the [LivestatusListener](09-object- types.md#objecttype-livestatuslistener)
object configuration. object configuration.
### Livestatus GET Queries <a id="livestatus-get-queries"></a> #### Livestatus GET Queries <a id="livestatus-get-queries"></a>
> **Note** > **Note**
> >
> All Livestatus queries require an additional empty line as query end identifie r. > All Livestatus queries require an additional empty line as query end identifie r.
> The `nc` tool (`netcat`) provides the `-U` parameter to communicate using > The `nc` tool (`netcat`) provides the `-U` parameter to communicate using
> a unix socket. > a unix socket.
There also is a Perl module available in CPAN for accessing the Livestatus socke t There also is a Perl module available in CPAN for accessing the Livestatus socke t
programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Moni toring-Livestatus-0.74/) programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Moni toring-Livestatus-0.74/)
skipping to change at line 809 skipping to change at line 1122
# echo -e 'GET services\n' | netcat 127.0.0.1 6558 # echo -e 'GET services\n' | netcat 127.0.0.1 6558
# cat servicegroups <<EOF # cat servicegroups <<EOF
GET servicegroups GET servicegroups
EOF EOF
(cat servicegroups; sleep 1) | netcat 127.0.0.1 6558 (cat servicegroups; sleep 1) | netcat 127.0.0.1 6558
``` ```
### Livestatus COMMAND Queries <a id="livestatus-command-queries"></a> #### Livestatus COMMAND Queries <a id="livestatus-command-queries"></a>
A list of available external commands and their parameters can be found [here](2 4-appendix.md#external-commands-list-detail) A list of available external commands and their parameters can be found [here](2 4-appendix.md#external-commands-list-detail)
``` ```
$ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558 $ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
``` ```
### Livestatus Filters <a id="livestatus-filters"></a> #### Livestatus Filters <a id="livestatus-filters"></a>
and, or, negate and, or, negate
Operator | Negate | Description Operator | Negate | Description
----------|----------|------------- ----------|----------|-------------
= | != | Equality = | != | Equality
~ | !~ | Regex match ~ | !~ | Regex match
=~ | !=~ | Equality ignoring case =~ | !=~ | Equality ignoring case
~~ | !~~ | Regex ignoring case ~~ | !~~ | Regex ignoring case
< | | Less than < | | Less than
> | | Greater than > | | Greater than
<= | | Less than or equal <= | | Less than or equal
>= | | Greater than or equal >= | | Greater than or equal
### Livestatus Stats <a id="livestatus-stats"></a> #### Livestatus Stats <a id="livestatus-stats"></a>
Schema: "Stats: aggregatefunction aggregateattribute" Schema: "Stats: aggregatefunction aggregateattribute"
Aggregate Function | Description Aggregate Function | Description
-------------------|-------------- -------------------|--------------
sum | &nbsp; sum | &nbsp;
min | &nbsp; min | &nbsp;
max | &nbsp; max | &nbsp;
avg | sum / count avg | sum / count
std | standard deviation std | standard deviation
skipping to change at line 866 skipping to change at line 1179
Stats: min execution_time Stats: min execution_time
Stats: min latency Stats: min latency
Stats: min percent_state_change Stats: min percent_state_change
Stats: max execution_time Stats: max execution_time
Stats: max latency Stats: max latency
Stats: max percent_state_change Stats: max percent_state_change
OutputFormat: json OutputFormat: json
ResponseHeader: fixed16 ResponseHeader: fixed16
``` ```
### Livestatus Output <a id="livestatus-output"></a> #### Livestatus Output <a id="livestatus-output"></a>
* CSV * CSV
CSV output uses two levels of array separators: The members array separator CSV output uses two levels of array separators: The members array separator
is a comma (1st level) while extra info and host|service relation separator is a comma (1st level) while extra info and host|service relation separator
is a pipe (2nd level). is a pipe (2nd level).
Separators can be set using ASCII codes like: Separators can be set using ASCII codes like:
``` ```
Separators: 10 59 44 124 Separators: 10 59 44 124
``` ```
* JSON * JSON
Default separators. Default separators.
### Livestatus Error Codes <a id="livestatus-error-codes"></a> #### Livestatus Error Codes <a id="livestatus-error-codes"></a>
Code | Description Code | Description
----------|-------------- ----------|--------------
200 | OK 200 | OK
404 | Table does not exist 404 | Table does not exist
452 | Exception on query 452 | Exception on query
### Livestatus Tables <a id="livestatus-tables"></a> #### Livestatus Tables <a id="livestatus-tables"></a>
Table | Join |Description Table | Join |Description
--------------|-----------|---------------------------- --------------|-----------|----------------------------
hosts | &nbsp; | host config and status attributes, services counte r hosts | &nbsp; | host config and status attributes, services counte r
hostgroups | &nbsp; | hostgroup config, status attributes and host/servi ce counters hostgroups | &nbsp; | hostgroup config, status attributes and host/servi ce counters
services | hosts | service config and status attributes services | hosts | service config and status attributes
servicegroups | &nbsp; | servicegroup config, status attributes and service counters servicegroups | &nbsp; | servicegroup config, status attributes and service counters
contacts | &nbsp; | contact config and status attributes contacts | &nbsp; | contact config and status attributes
contactgroups | &nbsp; | contact config, members contactgroups | &nbsp; | contact config, members
commands | &nbsp; | command name and line commands | &nbsp; | command name and line
skipping to change at line 917 skipping to change at line 1230
endpoints | &nbsp; | config and status attributes endpoints | &nbsp; | config and status attributes
log | services, hosts, contacts, commands | parses [compatlog](09-ob ject-types.md#objecttype-compatlogger) and shows log attributes log | services, hosts, contacts, commands | parses [compatlog](09-ob ject-types.md#objecttype-compatlogger) and shows log attributes
statehist | hosts, services | parses [compatlog](09-object-types.md#object type-compatlogger) and aggregates state change attributes statehist | hosts, services | parses [compatlog](09-object-types.md#object type-compatlogger) and aggregates state change attributes
hostsbygroup | hostgroups | host attributes grouped by hostgroup and its attr ibutes hostsbygroup | hostgroups | host attributes grouped by hostgroup and its attr ibutes
servicesbygroup | servicegroups | service attributes grouped by servicegroup a nd its attributes servicesbygroup | servicegroups | service attributes grouped by servicegroup a nd its attributes
servicesbyhostgroup | hostgroups | service attributes grouped by hostgroup an d its attributes servicesbyhostgroup | hostgroups | service attributes grouped by hostgroup an d its attributes
The `commands` table is populated with `CheckCommand`, `EventCommand` and `Notif icationCommand` objects. The `commands` table is populated with `CheckCommand`, `EventCommand` and `Notif icationCommand` objects.
A detailed list on the available table attributes can be found in the [Livestatu s Schema documentation](24-appendix.md#schema-livestatus). A detailed list on the available table attributes can be found in the [Livestatu s Schema documentation](24-appendix.md#schema-livestatus).
## Deprecated Features <a id="deprecated-features"></a>
### Status Data Files <a id="status-data"></a>
> **Note**
>
> This feature is DEPRECATED and will be removed in future releases.
> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
Icinga 1.x writes object configuration data and status data in a cyclic
interval to its `objects.cache` and `status.dat` files. Icinga 2 provides
the `StatusDataWriter` object which dumps all configuration objects and
status updates in a regular interval.
```
# icinga2 feature enable statusdata
```
If you are not using any web interface or addon which uses these files,
you can safely disable this feature.
### Compat Log Files <a id="compat-logging"></a>
> **Note**
>
> This feature is DEPRECATED and will be removed in future releases.
> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
The Icinga 1.x log format is considered being the `Compat Log`
in Icinga 2 provided with the `CompatLogger` object.
These logs are used for informational representation in
external web interfaces parsing the logs, but also to generate
SLA reports and trends.
The [Livestatus](14-features.md#setting-up-livestatus) feature uses these logs
for answering queries to historical tables.
The `CompatLogger` object can be enabled with
```
# icinga2 feature enable compatlog
```
By default, the Icinga 1.x log file called `icinga.log` is located
in `/var/log/icinga2/compat`. Rotated log files are moved into
`var/log/icinga2/compat/archives`.
### External Command Pipe <a id="external-commands"></a>
> **Note**
>
> Please use the [REST API](12-icinga2-api.md#icinga2-api) as modern and secure
alternative
> for external actions.
> **Note**
>
> This feature is DEPRECATED and will be removed in future releases.
> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
Icinga 2 provides an external command pipe for processing commands
triggering specific actions (for example rescheduling a service check
through the web interface).
In order to enable the `ExternalCommandListener` configuration use the
following command and restart Icinga 2 afterwards:
```
# icinga2 feature enable command
```
Icinga 2 creates the command pipe file as `/var/run/icinga2/cmd/icinga2.cmd`
using the default configuration.
Web interfaces and other Icinga addons are able to send commands to
Icinga 2 through the external command pipe, for example for rescheduling
a forced service check:
```
# /bin/echo "[`date +%s`] SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;`date +%s`"
>> /var/run/icinga2/cmd/icinga2.cmd
# tail -f /var/log/messages
Oct 17 15:01:25 icinga-server icinga2: Executing external command: [1382014885]
SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382014885
Oct 17 15:01:25 icinga-server icinga2: Rescheduling next check for service 'ping
4'
```
A list of currently supported external commands can be found [here](24-appendix.
md#external-commands-list-detail).
Detailed information on the commands and their required parameters can be found
on the [Icinga 1.x documentation](https://docs.icinga.com/latest/en/extcommands2
.html).
### Check Result Files <a id="check-result-files"></a>
> **Note**
>
> This feature is DEPRECATED and will be removed in future releases.
> Check the [roadmap](https://github.com/Icinga/icinga2/milestones).
Icinga 1.x writes its check result files to a temporary spool directory
where they are processed in a regular interval.
While this is extremely inefficient in performance regards it has been
rendered useful for passing passive check results directly into Icinga 1.x
skipping the external command pipe.
Several clustered/distributed environments and check-aggregation addons
use that method. In order to support step-by-step migration of these
environments, Icinga 2 supports the `CheckResultReader` object.
There is no feature configuration available, but it must be defined
on-demand in your Icinga 2 objects configuration.
```
object CheckResultReader "reader" {
spool_dir = "/data/check-results"
}
```
 End of changes. 16 change blocks. 
14 lines changed or deleted 356 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)