mirror of
https://github.com/Icinga/icinga2.git
synced 2025-07-26 07:04:37 +02:00
Documentation: Reorganize Livestatus and alternative Frontends
fixes #10482
This commit is contained in:
Michael Friedrich
parent
050c520b2a
commit
46e892cc60
@ -50,7 +50,7 @@ More details in the [Icinga FAQ](https://www.icinga.org/icinga/faq/).
|
|||||||
|
|
||||||
* [Register](https://accounts.icinga.org/register) an Icinga account.
|
* [Register](https://accounts.icinga.org/register) an Icinga account.
|
||||||
* Create a new issue at the [Icinga 2 Development Tracker](https://dev.icinga.org/projects/i2).
|
* Create a new issue at the [Icinga 2 Development Tracker](https://dev.icinga.org/projects/i2).
|
||||||
* When reporting a bug, please include the details described in the [Troubleshooting](17-troubleshooting.md#troubleshooting-information-required) chapter (version, configs, logs, etc).
|
* When reporting a bug, please include the details described in the [Troubleshooting](16-troubleshooting.md#troubleshooting-information-required) chapter (version, configs, logs, etc).
|
||||||
|
|
||||||
## <a id="whats-new"></a> What's New
|
## <a id="whats-new"></a> What's New
|
||||||
|
|
||||||
@ -506,7 +506,7 @@ Please note that this version fixes the default thresholds for the disk check wh
|
|||||||
* Solved a number of issues where cluster instances would not reconnect after intermittent connection problems
|
* Solved a number of issues where cluster instances would not reconnect after intermittent connection problems
|
||||||
* A lot of other, minor changes
|
* A lot of other, minor changes
|
||||||
|
|
||||||
* [DB IDO schema upgrade](18-upgrading-icinga-2.md#upgrading-icinga-2) to `1.13.0` required!
|
* [DB IDO schema upgrade](17-upgrading-icinga-2.md#upgrading-icinga-2) to `1.13.0` required!
|
||||||
|
|
||||||
#### Features
|
#### Features
|
||||||
|
|
||||||
|
|||||||
@ -30,7 +30,7 @@ Keep the [naming convention](13-distributed-monitoring-ha.md#cluster-naming-conv
|
|||||||
> **Tip**
|
> **Tip**
|
||||||
>
|
>
|
||||||
> If you're looking for troubleshooting clients problems, check the general
|
> If you're looking for troubleshooting clients problems, check the general
|
||||||
> [cluster troubleshooting](17-troubleshooting.md#troubleshooting-cluster) section.
|
> [cluster troubleshooting](16-troubleshooting.md#troubleshooting-cluster) section.
|
||||||
|
|
||||||
### <a id="icinga2-client-configuration-combined-scenarios"></a> Combined Client Scenarios
|
### <a id="icinga2-client-configuration-combined-scenarios"></a> Combined Client Scenarios
|
||||||
|
|
||||||
|
|||||||
@ -181,7 +181,7 @@ SNMP Traps can be received and filtered by using [SNMPTT](http://snmptt.sourcefo
|
|||||||
and specific trap handlers passing the check results to Icinga 2.
|
and specific trap handlers passing the check results to Icinga 2.
|
||||||
|
|
||||||
Following the SNMPTT [Format](http://snmptt.sourceforge.net/docs/snmptt.shtml#SNMPTT.CONF-FORMAT)
|
Following the SNMPTT [Format](http://snmptt.sourceforge.net/docs/snmptt.shtml#SNMPTT.CONF-FORMAT)
|
||||||
documentation and the Icinga external command syntax found [here](23-appendix.md#external-commands-list-detail)
|
documentation and the Icinga external command syntax found [here](22-appendix.md#external-commands-list-detail)
|
||||||
we can create generic services that can accommodate any number of hosts for a given scenario.
|
we can create generic services that can accommodate any number of hosts for a given scenario.
|
||||||
|
|
||||||
### <a id="simple-traps"></a> Simple SNMP Traps
|
### <a id="simple-traps"></a> Simple SNMP Traps
|
||||||
|
|||||||
@ -43,7 +43,7 @@ Decide whether to use the built-in [configuration syncronization](13-distributed
|
|||||||
> **Tip**
|
> **Tip**
|
||||||
>
|
>
|
||||||
> If you're looking for troubleshooting cluster problems, check the general
|
> If you're looking for troubleshooting cluster problems, check the general
|
||||||
> [troubleshooting](17-troubleshooting.md#troubleshooting-cluster) section.
|
> [troubleshooting](16-troubleshooting.md#troubleshooting-cluster) section.
|
||||||
|
|
||||||
## <a id="manual-certificate-generation"></a> Manual SSL Certificate Generation
|
## <a id="manual-certificate-generation"></a> Manual SSL Certificate Generation
|
||||||
|
|
||||||
@ -153,7 +153,7 @@ and configure [cluster scenarios](13-distributed-monitoring-ha.md#cluster-scenar
|
|||||||
### <a id="configure-nodename"></a> Configure the Icinga Node Name
|
### <a id="configure-nodename"></a> Configure the Icinga Node Name
|
||||||
|
|
||||||
Instead of using the default FQDN as node name you can optionally set
|
Instead of using the default FQDN as node name you can optionally set
|
||||||
that value using the [NodeName](20-language-reference.md#constants) constant.
|
that value using the [NodeName](18-language-reference.md#constants) constant.
|
||||||
|
|
||||||
> ** Note **
|
> ** Note **
|
||||||
>
|
>
|
||||||
@ -346,7 +346,7 @@ process.
|
|||||||
>
|
>
|
||||||
> `zones.d` must not be included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically
|
> `zones.d` must not be included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically
|
||||||
> determines the required include directory. This can be overridden using the
|
> determines the required include directory. This can be overridden using the
|
||||||
> [global constant](20-language-reference.md#constants) `ZonesDir`.
|
> [global constant](18-language-reference.md#constants) `ZonesDir`.
|
||||||
|
|
||||||
### <a id="zone-global-config-templates"></a> Global Configuration Zone for Templates
|
### <a id="zone-global-config-templates"></a> Global Configuration Zone for Templates
|
||||||
|
|
||||||
@ -406,7 +406,7 @@ master instances anymore.
|
|||||||
|
|
||||||
> ** Tip **
|
> ** Tip **
|
||||||
>
|
>
|
||||||
> Look into the [troubleshooting guides](17-troubleshooting.md#troubleshooting-cluster-config-sync) for debugging
|
> Look into the [troubleshooting guides](16-troubleshooting.md#troubleshooting-cluster-config-sync) for debugging
|
||||||
> problems with the configuration synchronisation.
|
> problems with the configuration synchronisation.
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@ -13,7 +13,7 @@ Use your distribution's package manager to install the `pnp4nagios` package.
|
|||||||
|
|
||||||
If you're planning to use it configure it to use the
|
If you're planning to use it configure it to use the
|
||||||
[bulk mode with npcd and npcdmod](http://docs.pnp4nagios.org/pnp-0.6/modes#bulk_mode_with_npcd_and_npcdmod)
|
[bulk mode with npcd and npcdmod](http://docs.pnp4nagios.org/pnp-0.6/modes#bulk_mode_with_npcd_and_npcdmod)
|
||||||
in combination with Icinga 2's [PerfdataWriter](5-advanced-topics.md#performance-data). NPCD collects the performance
|
in combination with Icinga 2's [PerfdataWriter](15-features.md#performance-data). NPCD collects the performance
|
||||||
data files which Icinga 2 generates.
|
data files which Icinga 2 generates.
|
||||||
|
|
||||||
Enable performance data writer in icinga 2
|
Enable performance data writer in icinga 2
|
||||||
@ -45,7 +45,7 @@ Graphite consists of 3 software components:
|
|||||||
* whisper - a simple database library for storing time-series data (similar in design to RRD)
|
* whisper - a simple database library for storing time-series data (similar in design to RRD)
|
||||||
* graphite webapp - A Django webapp that renders graphs on-demand using Cairo
|
* graphite webapp - A Django webapp that renders graphs on-demand using Cairo
|
||||||
|
|
||||||
Use the [GraphiteWriter](5-advanced-topics.md#graphite-carbon-cache-writer) feature
|
Use the [GraphiteWriter](15-features.md#graphite-carbon-cache-writer) feature
|
||||||
for sending real-time metrics from Icinga 2 to Graphite.
|
for sending real-time metrics from Icinga 2 to Graphite.
|
||||||
|
|
||||||
# icinga2 feature enable graphite
|
# icinga2 feature enable graphite
|
||||||
@ -59,7 +59,7 @@ A popular alternative frontend for Graphite is for example [Grafana](http://graf
|
|||||||
[InfluxDB](https://influxdb.com) is a time series, metrics, and analytics database.
|
[InfluxDB](https://influxdb.com) is a time series, metrics, and analytics database.
|
||||||
It’s written in Go and has no external dependencies.
|
It’s written in Go and has no external dependencies.
|
||||||
|
|
||||||
Use the [GraphiteWriter](5-advanced-topics.md#graphite-carbon-cache-writer) feature
|
Use the [GraphiteWriter](15-features.md#graphite-carbon-cache-writer) feature
|
||||||
for sending real-time metrics from Icinga 2 to InfluxDB. Note: There are [API changes](https://github.com/influxdb/influxdb/issues/2102)
|
for sending real-time metrics from Icinga 2 to InfluxDB. Note: There are [API changes](https://github.com/influxdb/influxdb/issues/2102)
|
||||||
in InfluxDB 0.9.x.
|
in InfluxDB 0.9.x.
|
||||||
|
|
||||||
@ -71,13 +71,13 @@ A popular frontend for InfluxDB is for example [Grafana](http://grafana.org).
|
|||||||
|
|
||||||
### <a id="addons-visualization-reporting"></a> Icinga Reporting
|
### <a id="addons-visualization-reporting"></a> Icinga Reporting
|
||||||
|
|
||||||
By enabling the [DB IDO](5-advanced-topics.md#db-ido) feature you can use the
|
By enabling the [DB IDO](15-features.md#db-ido) feature you can use the
|
||||||
[Icinga Reporting package](https://wiki.icinga.org/display/howtos/Setting+up+Icinga+with+Reporting).
|
[Icinga Reporting package](https://wiki.icinga.org/display/howtos/Setting+up+Icinga+with+Reporting).
|
||||||
|
|
||||||
### <a id="addons-visualization-nagvis"></a> NagVis
|
### <a id="addons-visualization-nagvis"></a> NagVis
|
||||||
|
|
||||||
By using either [Livestatus](16-livestatus.md#setting-up-livestatus) or
|
By using either [Livestatus](15-features.md#setting-up-livestatus) or
|
||||||
[DB IDO](5-advanced-topics.md#db-ido) as a backend you can create your own network maps
|
[DB IDO](15-features.md#db-ido) as a backend you can create your own network maps
|
||||||
based on your monitoring configuration and status data using [NagVis](http://www.nagvis.org).
|
based on your monitoring configuration and status data using [NagVis](http://www.nagvis.org).
|
||||||
|
|
||||||
The configuration in nagvis.ini.php should look like this for Livestatus for example:
|
The configuration in nagvis.ini.php should look like this for Livestatus for example:
|
||||||
@ -91,7 +91,7 @@ If you are planning an integration into Icinga Web 2, look at [this module](http
|
|||||||
### <a id="addons-visualization-thruk"></a> Thruk
|
### <a id="addons-visualization-thruk"></a> Thruk
|
||||||
|
|
||||||
[Thruk](http://www.thruk.org) is an alternative web interface which can be used with Icinga 2
|
[Thruk](http://www.thruk.org) is an alternative web interface which can be used with Icinga 2
|
||||||
and the [Livestatus](16-livestatus.md#setting-up-livestatus) feature.
|
and the [Livestatus](15-features.md#setting-up-livestatus) feature.
|
||||||
|
|
||||||
## <a id="log-monitoring"></a> Log Monitoring
|
## <a id="log-monitoring"></a> Log Monitoring
|
||||||
|
|
||||||
@ -270,7 +270,7 @@ This behavior changed in Icinga 2 compared to Icinga 1.x. Though there are certa
|
|||||||
fix this:
|
fix this:
|
||||||
|
|
||||||
* Create a symlink for example from the `templates.dist/check_ping.php` template to the actual check name in Icinga 2 (`templates/ping4.php`)
|
* Create a symlink for example from the `templates.dist/check_ping.php` template to the actual check name in Icinga 2 (`templates/ping4.php`)
|
||||||
* Pass the check command name inside the [format template configuration](5-advanced-topics.md#writing-performance-data-files)
|
* Pass the check command name inside the [format template configuration](15-features.md#writing-performance-data-files)
|
||||||
|
|
||||||
The latter becomes difficult with agent based checks like NRPE or SSH where the first command argument acts as
|
The latter becomes difficult with agent based checks like NRPE or SSH where the first command argument acts as
|
||||||
graph template identifier. There is the possibility to define the pnp template name as custom attribute
|
graph template identifier. There is the possibility to define the pnp template name as custom attribute
|
||||||
|
|||||||
@ -1,175 +0,0 @@
|
|||||||
# <a id="alternative-frontends"></a> Alternative Frontends
|
|
||||||
|
|
||||||
## <a id="setting-up-icinga-classic-ui"></a> Setting up Icinga Classic UI 1.x
|
|
||||||
|
|
||||||
Icinga 2 can write `status.dat` and `objects.cache` files in the format that
|
|
||||||
is supported by the Icinga 1.x Classic UI. [External commands](5-advanced-topics.md#external-commands)
|
|
||||||
(a.k.a. the "command pipe") are also supported. It also supports writing Icinga 1.x
|
|
||||||
log files which are required for the reporting functionality in the Classic UI.
|
|
||||||
|
|
||||||
### <a id="installing-icinga-classic-ui"></a> Installing Icinga Classic UI 1.x
|
|
||||||
|
|
||||||
The Icinga package repository has both Debian and RPM packages. You can install
|
|
||||||
the Classic UI using the following packages:
|
|
||||||
|
|
||||||
Distribution | Packages
|
|
||||||
--------------|---------------------
|
|
||||||
Debian | icinga2-classicui
|
|
||||||
RHEL/SUSE | icinga2-classicui-config icinga-gui
|
|
||||||
|
|
||||||
The Debian packages require additional packages which are provided by the
|
|
||||||
[Debian Monitoring Project](http://www.debmon.org) (`debmon`) repository.
|
|
||||||
|
|
||||||
`libjs-jquery-ui` requires at least version `1.10.*` which is not available
|
|
||||||
in Debian 7 (Wheezy) and Ubuntu 12.04 LTS (Precise). Add the following repositories
|
|
||||||
to satisfy this dependency:
|
|
||||||
|
|
||||||
Distribution | Package Repositories
|
|
||||||
------------------------------|------------------------------
|
|
||||||
Debian Wheezy | [wheezy-backports](http://backports.debian.org/Instructions/) or [debmon](http://www.debmon.org)
|
|
||||||
Ubuntu 12.04 LTS (Precise) | [Icinga PPA](https://launchpad.net/~formorer/+archive/icinga)
|
|
||||||
|
|
||||||
On all distributions other than Debian you may have to restart both your web
|
|
||||||
server as well as Icinga 2 after installing the Classic UI package.
|
|
||||||
|
|
||||||
Icinga Classic UI requires the [StatusDataWriter](5-advanced-topics.md#status-data), [CompatLogger](5-advanced-topics.md#compat-logging)
|
|
||||||
and [ExternalCommandListener](5-advanced-topics.md#external-commands) features.
|
|
||||||
Enable these features and restart Icinga 2.
|
|
||||||
|
|
||||||
# icinga2 feature enable statusdata compatlog command
|
|
||||||
|
|
||||||
In order for commands to work you will need to [setup the external command pipe](2-getting-started.md#setting-up-external-command-pipe).
|
|
||||||
|
|
||||||
### <a id="setting-up-icinga-classic-ui-summary"></a> Setting Up Icinga Classic UI 1.x Summary
|
|
||||||
|
|
||||||
Verify that your Icinga 1.x Classic UI works by browsing to your Classic
|
|
||||||
UI installation URL:
|
|
||||||
|
|
||||||
Distribution | URL | Default Login
|
|
||||||
--------------|--------------------------------------------------------------------------|--------------------------
|
|
||||||
Debian | [http://localhost/icinga2-classicui](http://localhost/icinga2-classicui) | asked during installation
|
|
||||||
all others | [http://localhost/icinga](http://localhost/icinga) | icingaadmin/icingaadmin
|
|
||||||
|
|
||||||
For further information on configuration, troubleshooting and interface documentation
|
|
||||||
please check the official [Icinga 1.x user interface documentation](http://docs.icinga.org/latest/en/ch06.html).
|
|
||||||
|
|
||||||
## <a id="setting-up-icinga-web"></a> Setting up Icinga Web 1.x
|
|
||||||
|
|
||||||
Icinga 2 can write to the same schema supplied by `Icinga IDOUtils 1.x` which
|
|
||||||
is an explicit requirement to run `Icinga Web` next to the external command pipe.
|
|
||||||
Therefore you need to setup the [DB IDO feature](2-getting-started.md#configuring-db-ido-mysql) remarked in the previous sections.
|
|
||||||
|
|
||||||
### <a id="installing-icinga-web"></a> Installing Icinga Web 1.x
|
|
||||||
|
|
||||||
The Icinga package repository has both Debian and RPM packages. You can install
|
|
||||||
Icinga Web using the following packages:
|
|
||||||
|
|
||||||
Distribution | Packages
|
|
||||||
--------------|-------------------------------------------------------
|
|
||||||
RHEL/SUSE | icinga-web icinga-web-{mysql,pgsql}
|
|
||||||
Debian | icinga-web icinga-web-config-icinga2-ido-{mysql,pgsql}
|
|
||||||
|
|
||||||
### <a id="icinga-web-rpm-notes"></a> Icinga Web 1.x on RPM based systems
|
|
||||||
|
|
||||||
Additionally you need to setup the `icinga_web` database and import the database schema.
|
|
||||||
Details can be found in the package `README` files, for example [README.RHEL](https://github.com/Icinga/icinga-web/blob/master/doc/README.RHEL)
|
|
||||||
|
|
||||||
The Icinga Web RPM packages install the schema files into
|
|
||||||
`/usr/share/doc/icinga-web-*/schema` (`*` means package version).
|
|
||||||
|
|
||||||
On SuSE-based distributions the schema files are installed in
|
|
||||||
`/usr/share/doc/packages/icinga-web/schema`.
|
|
||||||
|
|
||||||
Example for RHEL and MySQL:
|
|
||||||
|
|
||||||
# mysql -u root -p
|
|
||||||
|
|
||||||
mysql> CREATE DATABASE icinga_web;
|
|
||||||
GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX, EXECUTE ON icinga_web.* TO 'icinga_web'@'localhost' IDENTIFIED BY 'icinga_web';
|
|
||||||
quit
|
|
||||||
|
|
||||||
# mysql -u root -p icinga_web < /usr/share/doc/icinga-web-<version>/schema/mysql.sql
|
|
||||||
|
|
||||||
Icinga Web requires the IDO feature as database backend using MySQL or PostgreSQL.
|
|
||||||
Enable that feature, e.g. for MySQL.
|
|
||||||
|
|
||||||
# icinga2 feature enable ido-mysql
|
|
||||||
|
|
||||||
If you've changed your default credentials you may either create a read-only user
|
|
||||||
or use the credentials defined in the IDO feature for Icinga Web backend configuration.
|
|
||||||
Edit `databases.xml` accordingly and clear the cache afterwards. Further details can be
|
|
||||||
found in the [Icinga Web documentation](http://docs.icinga.org/latest/en/icinga-web-config.html).
|
|
||||||
|
|
||||||
# vim /etc/icinga-web/conf.d/databases.xml
|
|
||||||
|
|
||||||
# icinga-web-clearcache
|
|
||||||
|
|
||||||
Additionally you need to enable the `command` feature for sending [external commands](5-advanced-topics.md#external-commands):
|
|
||||||
|
|
||||||
# icinga2 feature enable command
|
|
||||||
|
|
||||||
In order for commands to work you will need to [setup the external command pipe](2-getting-started.md#setting-up-external-command-pipe).
|
|
||||||
|
|
||||||
Then edit the Icinga Web configuration for sending commands in `/etc/icinga-web/conf.d/access.xml`
|
|
||||||
(RHEL) or `/etc/icinga-web/access.xml` (SUSE) setting the command pipe path
|
|
||||||
to the default used in Icinga 2. Make sure to clear the cache afterwards.
|
|
||||||
|
|
||||||
# vim /etc/icinga-web/conf.d/access.xml
|
|
||||||
|
|
||||||
<write>
|
|
||||||
<files>
|
|
||||||
<resource name="icinga_pipe">/var/run/icinga2/cmd/icinga2.cmd</resource>
|
|
||||||
</files>
|
|
||||||
</write>
|
|
||||||
|
|
||||||
# icinga-web-clearcache
|
|
||||||
|
|
||||||
> **Note**
|
|
||||||
>
|
|
||||||
> The path to the Icinga Web `clearcache` script may differ. Please check the
|
|
||||||
> [Icinga Web documentation](https://docs.icinga.org) for details.
|
|
||||||
|
|
||||||
### <a id="icinga-web-debian-notes"></a> Icinga Web on Debian systems
|
|
||||||
|
|
||||||
Since Icinga Web `1.11.1-2` the IDO auto-configuration has been moved into
|
|
||||||
additional packages on Debian and Ubuntu.
|
|
||||||
|
|
||||||
The package `icinga-web` no longer configures the IDO connection. You must now
|
|
||||||
use one of the config packages:
|
|
||||||
|
|
||||||
- `icinga-web-config-icinga2-ido-mysql`
|
|
||||||
- `icinga-web-config-icinga2-ido-pgsql`
|
|
||||||
|
|
||||||
These packages take care of setting up the [DB IDO](2-getting-started.md#configuring-db-ido-mysql) configuration,
|
|
||||||
enabling the external command pipe for Icinga Web and depend on
|
|
||||||
the corresponding packages of Icinga 2.
|
|
||||||
|
|
||||||
Please read the `README.Debian` files for details and advanced configuration:
|
|
||||||
|
|
||||||
- `/usr/share/doc/icinga-web/README.Debian`
|
|
||||||
- `/usr/share/doc/icinga-web-config-icinga2-ido-mysql/README.Debian`
|
|
||||||
- `/usr/share/doc/icinga-web-config-icinga2-ido-pgsql/README.Debian`
|
|
||||||
|
|
||||||
When changing Icinga Web configuration files make sure to clear the config cache:
|
|
||||||
|
|
||||||
# /usr/lib/icinga-web/bin/clearcache.sh
|
|
||||||
|
|
||||||
> **Note**
|
|
||||||
>
|
|
||||||
> If you are using an older version of Icinga Web, install it like this and adapt
|
|
||||||
> the configuration manually as shown in [the RPM notes](15-alternative-frontends.md#icinga-web-rpm-notes):
|
|
||||||
>
|
|
||||||
> `apt-get install --no-install-recommends icinga-web`
|
|
||||||
|
|
||||||
### <a id="setting-up-icinga-web-summary"></a> Setting Up Icinga Web 1.x Summary
|
|
||||||
|
|
||||||
Verify that your Icinga 1.x Web works by browsing to your Web installation URL:
|
|
||||||
|
|
||||||
Distribution | URL | Default Login
|
|
||||||
--------------|-------------------------------------------------------------|--------------------------
|
|
||||||
Debian | [http://localhost/icinga-web](http://localhost/icinga-web) | asked during installation
|
|
||||||
all others | [http://localhost/icinga-web](http://localhost/icinga-web) | root/password
|
|
||||||
|
|
||||||
For further information on configuration, troubleshooting and interface documentation
|
|
||||||
please check the official [Icinga 1.x user interface documentation](http://docs.icinga.org/latest/en/ch06.html).
|
|
||||||
|
|
||||||
679
doc/15-features.md
Normal file
679
doc/15-features.md
Normal file
@ -0,0 +1,679 @@
|
|||||||
|
# <a id="icinga2-features"></a> Icinga 2 Features
|
||||||
|
|
||||||
|
## <a id="logging"></a> Logging
|
||||||
|
|
||||||
|
Icinga 2 supports three different types of logging:
|
||||||
|
|
||||||
|
* File logging
|
||||||
|
* Syslog (on *NIX-based operating systems)
|
||||||
|
* Console logging (`STDOUT` on tty)
|
||||||
|
|
||||||
|
You can enable additional loggers using the `icinga2 feature enable`
|
||||||
|
and `icinga2 feature disable` commands to configure loggers:
|
||||||
|
|
||||||
|
Feature | Description
|
||||||
|
---------|------------
|
||||||
|
debuglog | Debug log (path: `/var/log/icinga2/debug.log`, severity: `debug` or higher)
|
||||||
|
mainlog | Main log (path: `/var/log/icinga2/icinga2.log`, severity: `information` or higher)
|
||||||
|
syslog | Syslog (severity: `warning` or higher)
|
||||||
|
|
||||||
|
By default file the `mainlog` feature is enabled. When running Icinga 2
|
||||||
|
on a terminal log messages with severity `information` or higher are
|
||||||
|
written to the console.
|
||||||
|
|
||||||
|
## <a id="db-ido"></a> DB IDO
|
||||||
|
|
||||||
|
The IDO (Icinga Data Output) modules for Icinga 2 take care of exporting all
|
||||||
|
configuration and status information into a database. The IDO database is used
|
||||||
|
by a number of projects including Icinga Web 1.x and 2.
|
||||||
|
|
||||||
|
Details on the installation can be found in the [Configuring DB IDO](2-getting-started.md#configuring-db-ido-mysql)
|
||||||
|
chapter. Details on the configuration can be found in the
|
||||||
|
[IdoMysqlConnection](6-object-types.md#objecttype-idomysqlconnection) and
|
||||||
|
[IdoPgsqlConnection](6-object-types.md#objecttype-idopgsqlconnection)
|
||||||
|
object configuration documentation.
|
||||||
|
The DB IDO feature supports [High Availability](13-distributed-monitoring-ha.md#high-availability-db-ido) in
|
||||||
|
the Icinga 2 cluster.
|
||||||
|
|
||||||
|
The following example query checks the health of the current Icinga 2 instance
|
||||||
|
writing its current status to the DB IDO backend table `icinga_programstatus`
|
||||||
|
every 10 seconds. By default it checks 60 seconds into the past which is a reasonable
|
||||||
|
amount of time - adjust it for your requirements. If the condition is not met,
|
||||||
|
the query returns an empty result.
|
||||||
|
|
||||||
|
> **Tip**
|
||||||
|
>
|
||||||
|
> Use [check plugins](14-addons-plugins.md#plugins) to monitor the backend.
|
||||||
|
|
||||||
|
Replace the `default` string with your instance name, if different.
|
||||||
|
|
||||||
|
Example for MySQL:
|
||||||
|
|
||||||
|
# mysql -u root -p icinga -e "SELECT status_update_time FROM icinga_programstatus ps
|
||||||
|
JOIN icinga_instances i ON ps.instance_id=i.instance_id
|
||||||
|
WHERE (UNIX_TIMESTAMP(ps.status_update_time) > UNIX_TIMESTAMP(NOW())-60)
|
||||||
|
AND i.instance_name='default';"
|
||||||
|
|
||||||
|
+---------------------+
|
||||||
|
| status_update_time |
|
||||||
|
+---------------------+
|
||||||
|
| 2014-05-29 14:29:56 |
|
||||||
|
+---------------------+
|
||||||
|
|
||||||
|
|
||||||
|
Example for PostgreSQL:
|
||||||
|
|
||||||
|
# export PGPASSWORD=icinga; psql -U icinga -d icinga -c "SELECT ps.status_update_time FROM icinga_programstatus AS ps
|
||||||
|
JOIN icinga_instances AS i ON ps.instance_id=i.instance_id
|
||||||
|
WHERE ((SELECT extract(epoch from status_update_time) FROM icinga_programstatus) > (SELECT extract(epoch from now())-60))
|
||||||
|
AND i.instance_name='default'";
|
||||||
|
|
||||||
|
status_update_time
|
||||||
|
------------------------
|
||||||
|
2014-05-29 15:11:38+02
|
||||||
|
(1 Zeile)
|
||||||
|
|
||||||
|
|
||||||
|
A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](22-appendix.md#schema-db-ido).
|
||||||
|
|
||||||
|
|
||||||
|
## <a id="external-commands"></a> External Commands
|
||||||
|
|
||||||
|
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 'ping4'
|
||||||
|
|
||||||
|
A list of currently supported external commands can be found [here](22-appendix.md#external-commands-list-detail).
|
||||||
|
|
||||||
|
Detailed information on the commands and their required parameters can be found
|
||||||
|
on the [Icinga 1.x documentation](http://docs.icinga.org/latest/en/extcommands2.html).
|
||||||
|
|
||||||
|
## <a id="performance-data"></a> Performance Data
|
||||||
|
|
||||||
|
When a host or service check is executed plugins should provide so-called
|
||||||
|
`performance data`. Next to that additional check performance data
|
||||||
|
can be fetched using Icinga 2 runtime macros such as the check latency
|
||||||
|
or the current service state (or additional custom attributes).
|
||||||
|
|
||||||
|
The performance data can be passed to external applications which aggregate and
|
||||||
|
store them in their backends. These tools usually generate graphs for historical
|
||||||
|
reporting and trending.
|
||||||
|
|
||||||
|
Well-known addons processing Icinga performance data are [PNP4Nagios](14-addons-plugins.md#addons-graphing-pnp),
|
||||||
|
[Graphite](14-addons-plugins.md#addons-graphing-graphite) or [OpenTSDB](15-features.md#opentsdb-writer).
|
||||||
|
|
||||||
|
### <a id="writing-performance-data-files"></a> Writing Performance Data Files
|
||||||
|
|
||||||
|
PNP4Nagios and Graphios use performance data collector daemons to fetch
|
||||||
|
the current performance files for their backend updates.
|
||||||
|
|
||||||
|
Therefore the Icinga 2 [PerfdataWriter](6-object-types.md#objecttype-perfdatawriter)
|
||||||
|
feature allows you to define the output template format for host and services helped
|
||||||
|
with Icinga 2 runtime vars.
|
||||||
|
|
||||||
|
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$"
|
||||||
|
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$"
|
||||||
|
|
||||||
|
The default templates are already provided with the Icinga 2 feature configuration
|
||||||
|
which can be enabled using
|
||||||
|
|
||||||
|
# icinga2 feature enable perfdata
|
||||||
|
|
||||||
|
By default all performance data files are rotated in a 15 seconds interval into
|
||||||
|
the `/var/spool/icinga2/perfdata/` directory as `host-perfdata.<timestamp>` and
|
||||||
|
`service-perfdata.<timestamp>`.
|
||||||
|
External collectors need to parse the rotated performance data files and then
|
||||||
|
remove the processed files.
|
||||||
|
|
||||||
|
### <a id="graphite-carbon-cache-writer"></a> Graphite Carbon Cache Writer
|
||||||
|
|
||||||
|
While there are some [Graphite](14-addons-plugins.md#addons-graphing-graphite)
|
||||||
|
collector scripts and daemons like Graphios available for Icinga 1.x it's more
|
||||||
|
reasonable to directly process the check and plugin performance
|
||||||
|
in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
|
||||||
|
write them to the defined Graphite Carbon daemon tcp socket.
|
||||||
|
|
||||||
|
You can enable the feature using
|
||||||
|
|
||||||
|
# icinga2 feature enable graphite
|
||||||
|
|
||||||
|
By default the [GraphiteWriter](6-object-types.md#objecttype-graphitewriter) feature
|
||||||
|
expects the Graphite Carbon Cache to listen at `127.0.0.1` on TCP port `2003`.
|
||||||
|
|
||||||
|
#### <a id="graphite-carbon-cache-writer-schema"></a> Current Graphite Schema
|
||||||
|
|
||||||
|
The current naming schema is defined as follows. The official Icinga Web 2 Graphite
|
||||||
|
module will use that schema too.
|
||||||
|
|
||||||
|
The default prefix for hosts and services is configured using
|
||||||
|
[runtime macros](3-monitoring-basics.md#runtime-macros)like this:
|
||||||
|
|
||||||
|
icinga2.$host.name$.host.$host.check_command$
|
||||||
|
icinga2.$host.name$.services.$service.name$.$service.check_command$
|
||||||
|
|
||||||
|
You can customize the prefix name by using the `host_name_template` and
|
||||||
|
`service_name_template` configuration attributes.
|
||||||
|
|
||||||
|
The additional levels will allow fine granular filters and also template
|
||||||
|
capabilities, e.g. by using the check command `disk` for specific
|
||||||
|
graph templates in web applications rendering the Graphite data.
|
||||||
|
|
||||||
|
The following characters are escaped in prefix labels:
|
||||||
|
|
||||||
|
Character | Escaped character
|
||||||
|
--------------|--------------------------
|
||||||
|
whitespace | _
|
||||||
|
. | _
|
||||||
|
\ | _
|
||||||
|
/ | _
|
||||||
|
|
||||||
|
Metric values are stored like this:
|
||||||
|
|
||||||
|
<prefix>.perfdata.<perfdata-label>.value
|
||||||
|
|
||||||
|
The following characters are escaped in perfdata labels:
|
||||||
|
|
||||||
|
Character | Escaped character
|
||||||
|
--------------|--------------------------
|
||||||
|
whitespace | _
|
||||||
|
\ | _
|
||||||
|
/ | _
|
||||||
|
:: | .
|
||||||
|
|
||||||
|
Note that perfdata labels may contain dots (`.`) allowing to
|
||||||
|
add more subsequent levels inside the Graphite tree.
|
||||||
|
`::` adds support for [multi performance labels](http://my-plugin.de/wiki/projects/check_multi/configuration/performance)
|
||||||
|
and is therefore replaced by `.`.
|
||||||
|
|
||||||
|
By enabling `enable_send_thresholds` Icinga 2 automatically adds the following threshold metrics:
|
||||||
|
|
||||||
|
<prefix>.perfdata.<perfdata-label>.min
|
||||||
|
<prefix>.perfdata.<perfdata-label>.max
|
||||||
|
<prefix>.perfdata.<perfdata-label>.warn
|
||||||
|
<prefix>.perfdata.<perfdata-label>.crit
|
||||||
|
|
||||||
|
By enabling `enable_send_metadata` Icinga 2 automatically adds the following metadata metrics:
|
||||||
|
|
||||||
|
<prefix>.metadata.current_attempt
|
||||||
|
<prefix>.metadata.downtime_depth
|
||||||
|
<prefix>.metadata.execution_time
|
||||||
|
<prefix>.metadata.latency
|
||||||
|
<prefix>.metadata.max_check_attempts
|
||||||
|
<prefix>.metadata.reachable
|
||||||
|
<prefix>.metadata.state
|
||||||
|
<prefix>.metadata.state_type
|
||||||
|
|
||||||
|
Metadata metric overview:
|
||||||
|
|
||||||
|
metric | description
|
||||||
|
-------------------|------------------------------------------
|
||||||
|
current_attempt | current check attempt
|
||||||
|
max_check_attempts | maximum check attempts until the hard state is reached
|
||||||
|
reachable | checked object is reachable
|
||||||
|
downtime_depth | number of downtimes this object is in
|
||||||
|
execution_time | check execution time
|
||||||
|
latency | check latency
|
||||||
|
state | current state of the checked object
|
||||||
|
state_type | 0=SOFT, 1=HARD state
|
||||||
|
|
||||||
|
The following example illustrates how to configure the storage schemas for Graphite Carbon
|
||||||
|
Cache.
|
||||||
|
|
||||||
|
[icinga2_default]
|
||||||
|
# intervals like PNP4Nagios uses them per default
|
||||||
|
pattern = ^icinga2\.
|
||||||
|
retentions = 1m:2d,5m:10d,30m:90d,360m:4y
|
||||||
|
|
||||||
|
#### <a id="graphite-carbon-cache-writer-schema-legacy"></a> Graphite Schema < 2.4
|
||||||
|
|
||||||
|
In order to restore the old legacy schema, you'll need to adopt the `GraphiteWriter`
|
||||||
|
configuration:
|
||||||
|
|
||||||
|
object GraphiteWriter "graphite" {
|
||||||
|
|
||||||
|
enable_legacy_mode = true
|
||||||
|
|
||||||
|
host_name_template = "icinga.$host.name$"
|
||||||
|
service_name_template = "icinga.$host.name$.$service.name$"
|
||||||
|
}
|
||||||
|
|
||||||
|
The old legacy naming schema is
|
||||||
|
|
||||||
|
icinga.<hostname>.<metricname>
|
||||||
|
icinga.<hostname>.<servicename>.<metricname>
|
||||||
|
|
||||||
|
You can customize the metric prefix name by using the `host_name_template` and
|
||||||
|
`service_name_template` configuration attributes.
|
||||||
|
|
||||||
|
The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a
|
||||||
|
[global constant](18-language-reference.md#constants) named `GraphiteEnv`. The constant name
|
||||||
|
is freely definable and should be put in the [constants.conf](4-configuring-icinga-2.md#constants-conf) file.
|
||||||
|
|
||||||
|
const GraphiteEnv = "icinga.env1"
|
||||||
|
|
||||||
|
object GraphiteWriter "graphite" {
|
||||||
|
host_name_template = GraphiteEnv + ".$host.name$"
|
||||||
|
service_name_template = GraphiteEnv + ".$host.name$.$service.name$"
|
||||||
|
}
|
||||||
|
|
||||||
|
To make sure Icinga 2 writes a valid label into Graphite some characters are replaced
|
||||||
|
with `_` in the target name:
|
||||||
|
|
||||||
|
\/.- (and space)
|
||||||
|
|
||||||
|
The resulting name in Graphite might look like:
|
||||||
|
|
||||||
|
www-01 / http-cert / response time
|
||||||
|
icinga.www_01.http_cert.response_time
|
||||||
|
|
||||||
|
In addition to the performance data retrieved from the check plugin, Icinga 2 sends
|
||||||
|
internal check statistic data to Graphite:
|
||||||
|
|
||||||
|
metric | description
|
||||||
|
-------------------|------------------------------------------
|
||||||
|
current_attempt | current check attempt
|
||||||
|
max_check_attempts | maximum check attempts until the hard state is reached
|
||||||
|
reachable | checked object is reachable
|
||||||
|
downtime_depth | number of downtimes this object is in
|
||||||
|
execution_time | check execution time
|
||||||
|
latency | check latency
|
||||||
|
state | current state of the checked object
|
||||||
|
state_type | 0=SOFT, 1=HARD state
|
||||||
|
|
||||||
|
The following example illustrates how to configure the storage-schemas for Graphite Carbon
|
||||||
|
Cache. Please make sure that the order is correct because the first match wins.
|
||||||
|
|
||||||
|
[icinga_internals]
|
||||||
|
pattern = ^icinga\..*\.(max_check_attempts|reachable|current_attempt|execution_time|latency|state|state_type)
|
||||||
|
retentions = 5m:7d
|
||||||
|
|
||||||
|
[icinga_default]
|
||||||
|
# intervals like PNP4Nagios uses them per default
|
||||||
|
pattern = ^icinga\.
|
||||||
|
retentions = 1m:2d,5m:10d,30m:90d,360m:4y
|
||||||
|
|
||||||
|
### <a id="gelfwriter"></a> GELF Writer
|
||||||
|
|
||||||
|
The `Graylog Extended Log Format` (short: [GELF](http://www.graylog2.org/resources/gelf))
|
||||||
|
can be used to send application logs directly to a TCP socket.
|
||||||
|
|
||||||
|
While it has been specified by the [graylog2](http://www.graylog2.org/) project as their
|
||||||
|
[input resource standard](http://www.graylog2.org/resources/gelf), other tools such as
|
||||||
|
[Logstash](http://www.logstash.net) also support `GELF` as
|
||||||
|
[input type](http://logstash.net/docs/latest/inputs/gelf).
|
||||||
|
|
||||||
|
You can enable the feature using
|
||||||
|
|
||||||
|
# icinga2 feature enable gelf
|
||||||
|
|
||||||
|
By default the `GelfWriter` object expects the GELF receiver to listen at `127.0.0.1` on TCP port `12201`.
|
||||||
|
The default `source` attribute is set to `icinga2`. You can customize that for your needs if required.
|
||||||
|
|
||||||
|
Currently these events are processed:
|
||||||
|
* Check results
|
||||||
|
* State changes
|
||||||
|
* Notifications
|
||||||
|
|
||||||
|
### <a id="opentsdb-writer"></a> OpenTSDB Writer
|
||||||
|
|
||||||
|
While there are some OpenTSDB collector scripts and daemons like tcollector available for
|
||||||
|
Icinga 1.x it's more reasonable to directly process the check and plugin performance
|
||||||
|
in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
|
||||||
|
write them to the defined TSDB TCP socket.
|
||||||
|
|
||||||
|
You can enable the feature using
|
||||||
|
|
||||||
|
# icinga2 feature enable opentsdb
|
||||||
|
|
||||||
|
By default the `OpenTsdbWriter` object expects the TSD to listen at
|
||||||
|
`127.0.0.1` on port `4242`.
|
||||||
|
|
||||||
|
The current naming schema is
|
||||||
|
|
||||||
|
icinga.host.<metricname>
|
||||||
|
icinga.service.<servicename>.<metricname>
|
||||||
|
|
||||||
|
for host and service checks. The tag host is always applied.
|
||||||
|
|
||||||
|
To make sure Icinga 2 writes a valid metric into OpenTSDB some characters are replaced
|
||||||
|
with `_` in the target name:
|
||||||
|
|
||||||
|
\ (and space)
|
||||||
|
|
||||||
|
The resulting name in OpenTSDB might look like:
|
||||||
|
|
||||||
|
www-01 / http-cert / response time
|
||||||
|
icinga.http_cert.response_time
|
||||||
|
|
||||||
|
In addition to the performance data retrieved from the check plugin, Icinga 2 sends
|
||||||
|
internal check statistic data to OpenTSDB:
|
||||||
|
|
||||||
|
metric | description
|
||||||
|
-------------------|------------------------------------------
|
||||||
|
current_attempt | current check attempt
|
||||||
|
max_check_attempts | maximum check attempts until the hard state is reached
|
||||||
|
reachable | checked object is reachable
|
||||||
|
downtime_depth | number of downtimes this object is in
|
||||||
|
execution_time | check execution time
|
||||||
|
latency | check latency
|
||||||
|
state | current state of the checked object
|
||||||
|
state_type | 0=SOFT, 1=HARD state
|
||||||
|
|
||||||
|
While reachable, state and state_type are metrics for the host or service the
|
||||||
|
other metrics follow the current naming schema
|
||||||
|
|
||||||
|
icinga.check.<metricname>
|
||||||
|
|
||||||
|
with the following tags
|
||||||
|
|
||||||
|
tag | description
|
||||||
|
--------|------------------------------------------
|
||||||
|
type | the check type, one of [host, service]
|
||||||
|
host | hostname, the check ran on
|
||||||
|
service | the service name (if type=service)
|
||||||
|
|
||||||
|
> **Note**
|
||||||
|
>
|
||||||
|
> You might want to set the tsd.core.auto_create_metrics setting to `true`
|
||||||
|
> in your opentsdb.conf configuration file.
|
||||||
|
|
||||||
|
|
||||||
|
## <a id="setting-up-livestatus"></a> Livestatus
|
||||||
|
|
||||||
|
The [MK Livestatus](http://mathias-kettner.de/checkmk_livestatus.html) project
|
||||||
|
implements a query protocol that lets users query their Icinga instance for
|
||||||
|
status information. It can also be used to send commands.
|
||||||
|
|
||||||
|
> **Tip**
|
||||||
|
>
|
||||||
|
> Only install the Livestatus feature if your web interface or addon requires
|
||||||
|
> you to do so (for example, [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2)).
|
||||||
|
> Icinga Classic UI 1.x and Icinga Web 1.x do not use Livestatus as backend.
|
||||||
|
|
||||||
|
The Livestatus component that is distributed as part of Icinga 2 is a
|
||||||
|
re-implementation of the Livestatus protocol which is compatible with MK
|
||||||
|
Livestatus.
|
||||||
|
|
||||||
|
Details on the available tables and attributes with Icinga 2 can be found
|
||||||
|
in the [Livestatus Schema](22-appendix.md#schema-livestatus) section.
|
||||||
|
|
||||||
|
You can enable Livestatus using icinga2 feature enable:
|
||||||
|
|
||||||
|
# icinga2 feature enable livestatus
|
||||||
|
|
||||||
|
After that you will have to restart Icinga 2:
|
||||||
|
|
||||||
|
Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
|
||||||
|
|
||||||
|
# service icinga2 restart
|
||||||
|
|
||||||
|
RHEL/CentOS 7 and Fedora:
|
||||||
|
|
||||||
|
# systemctl restart icinga2
|
||||||
|
|
||||||
|
By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
|
||||||
|
|
||||||
|
In order for queries and commands to work you will need to add your query user
|
||||||
|
(e.g. your web server) to the `icingacmd` group:
|
||||||
|
|
||||||
|
# usermod -a -G icingacmd www-data
|
||||||
|
|
||||||
|
The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to
|
||||||
|
`nagios` if you're using Debian.
|
||||||
|
|
||||||
|
Change `www-data` to the user you're using to run queries.
|
||||||
|
|
||||||
|
In order to use the historical tables provided by the livestatus feature (for example, the
|
||||||
|
`log` table) you need to have the `CompatLogger` feature enabled. By default these logs
|
||||||
|
are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
|
||||||
|
`compat_log_path` configuration attribute.
|
||||||
|
|
||||||
|
# icinga2 feature enable compatlog
|
||||||
|
|
||||||
|
|
||||||
|
### <a id="livestatus-sockets"></a> Livestatus Sockets
|
||||||
|
|
||||||
|
Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
|
||||||
|
|
||||||
|
* Unix socket (default)
|
||||||
|
* TCP socket
|
||||||
|
|
||||||
|
Details on the configuration can be found in the [LivestatusListener](6-object-types.md#objecttype-livestatuslistener)
|
||||||
|
object configuration.
|
||||||
|
|
||||||
|
### <a id="livestatus-get-queries"></a> Livestatus GET Queries
|
||||||
|
|
||||||
|
> **Note**
|
||||||
|
>
|
||||||
|
> All Livestatus queries require an additional empty line as query end identifier.
|
||||||
|
> The `nc` tool (`netcat`) provides the `-U` parameter to communicate using
|
||||||
|
> a unix socket.
|
||||||
|
|
||||||
|
There also is a Perl module available in CPAN for accessing the Livestatus socket
|
||||||
|
programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Monitoring-Livestatus-0.74/)
|
||||||
|
|
||||||
|
|
||||||
|
Example using the unix socket:
|
||||||
|
|
||||||
|
# echo -e "GET services\n" | /usr/bin/nc -U /var/run/icinga2/cmd/livestatus
|
||||||
|
|
||||||
|
Example using the tcp socket listening on port `6558`:
|
||||||
|
|
||||||
|
# echo -e 'GET services\n' | netcat 127.0.0.1 6558
|
||||||
|
|
||||||
|
# cat servicegroups <<EOF
|
||||||
|
GET servicegroups
|
||||||
|
|
||||||
|
EOF
|
||||||
|
|
||||||
|
(cat servicegroups; sleep 1) | netcat 127.0.0.1 6558
|
||||||
|
|
||||||
|
|
||||||
|
### <a id="livestatus-command-queries"></a> Livestatus COMMAND Queries
|
||||||
|
|
||||||
|
A list of available external commands and their parameters can be found [here](22-appendix.md#external-commands-list-detail)
|
||||||
|
|
||||||
|
$ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
|
||||||
|
|
||||||
|
|
||||||
|
### <a id="livestatus-filters"></a> Livestatus Filters
|
||||||
|
|
||||||
|
and, or, negate
|
||||||
|
|
||||||
|
Operator | Negate | Description
|
||||||
|
----------|------------------------
|
||||||
|
= | != | Equality
|
||||||
|
~ | !~ | Regex match
|
||||||
|
=~ | !=~ | Equality ignoring case
|
||||||
|
~~ | !~~ | Regex ignoring case
|
||||||
|
< | | Less than
|
||||||
|
> | | Greater than
|
||||||
|
<= | | Less than or equal
|
||||||
|
>= | | Greater than or equal
|
||||||
|
|
||||||
|
|
||||||
|
### <a id="livestatus-stats"></a> Livestatus Stats
|
||||||
|
|
||||||
|
Schema: "Stats: aggregatefunction aggregateattribute"
|
||||||
|
|
||||||
|
Aggregate Function | Description
|
||||||
|
-------------------|--------------
|
||||||
|
sum |
|
||||||
|
min |
|
||||||
|
max |
|
||||||
|
avg | sum / count
|
||||||
|
std | standard deviation
|
||||||
|
suminv | sum (1 / value)
|
||||||
|
avginv | suminv / count
|
||||||
|
count | ordinary default for any stats query if not aggregate function defined
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
GET hosts
|
||||||
|
Filter: has_been_checked = 1
|
||||||
|
Filter: check_type = 0
|
||||||
|
Stats: sum execution_time
|
||||||
|
Stats: sum latency
|
||||||
|
Stats: sum percent_state_change
|
||||||
|
Stats: min execution_time
|
||||||
|
Stats: min latency
|
||||||
|
Stats: min percent_state_change
|
||||||
|
Stats: max execution_time
|
||||||
|
Stats: max latency
|
||||||
|
Stats: max percent_state_change
|
||||||
|
OutputFormat: json
|
||||||
|
ResponseHeader: fixed16
|
||||||
|
|
||||||
|
### <a id="livestatus-output"></a> Livestatus Output
|
||||||
|
|
||||||
|
* CSV
|
||||||
|
|
||||||
|
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 pipe (2nd level).
|
||||||
|
|
||||||
|
Separators can be set using ASCII codes like:
|
||||||
|
|
||||||
|
Separators: 10 59 44 124
|
||||||
|
|
||||||
|
* JSON
|
||||||
|
|
||||||
|
Default separators.
|
||||||
|
|
||||||
|
### <a id="livestatus-error-codes"></a> Livestatus Error Codes
|
||||||
|
|
||||||
|
Code | Description
|
||||||
|
----------|--------------
|
||||||
|
200 | OK
|
||||||
|
404 | Table does not exist
|
||||||
|
452 | Exception on query
|
||||||
|
|
||||||
|
### <a id="livestatus-tables"></a> Livestatus Tables
|
||||||
|
|
||||||
|
Table | Join |Description
|
||||||
|
--------------|-----------|----------------------------
|
||||||
|
hosts | | host config and status attributes, services counter
|
||||||
|
hostgroups | | hostgroup config, status attributes and host/service counters
|
||||||
|
services | hosts | service config and status attributes
|
||||||
|
servicegroups | | servicegroup config, status attributes and service counters
|
||||||
|
contacts | | contact config and status attributes
|
||||||
|
contactgroups | | contact config, members
|
||||||
|
commands | | command name and line
|
||||||
|
status | | programstatus, config and stats
|
||||||
|
comments | services | status attributes
|
||||||
|
downtimes | services | status attributes
|
||||||
|
timeperiods | | name and is inside flag
|
||||||
|
endpoints | | config and status attributes
|
||||||
|
log | services, hosts, contacts, commands | parses [compatlog](6-object-types.md#objecttype-compatlogger) and shows log attributes
|
||||||
|
statehist | hosts, services | parses [compatlog](6-object-types.md#objecttype-compatlogger) and aggregates state change attributes
|
||||||
|
hostsbygroup | hostgroups | host attributes grouped by hostgroup and its attributes
|
||||||
|
servicesbygroup | servicegroups | service attributes grouped by servicegroup and its attributes
|
||||||
|
servicesbyhostgroup | hostgroups | service attributes grouped by hostgroup and its attributes
|
||||||
|
|
||||||
|
The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects.
|
||||||
|
|
||||||
|
A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](22-appendix.md#schema-livestatus).
|
||||||
|
|
||||||
|
|
||||||
|
## <a id="status-data"></a> Status Data Files
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
Icinga 1.x Classic UI requires this data set as part of its backend.
|
||||||
|
|
||||||
|
> **Note**
|
||||||
|
>
|
||||||
|
> If you are not using any web interface or addon which uses these files
|
||||||
|
> you can safely disable this feature.
|
||||||
|
|
||||||
|
|
||||||
|
## <a id="compat-logging"></a> Compat Log Files
|
||||||
|
|
||||||
|
The Icinga 1.x log format is considered being the `Compat Log`
|
||||||
|
in Icinga 2 provided with the `CompatLogger` object.
|
||||||
|
|
||||||
|
These logs are not only used for informational representation in
|
||||||
|
external web interfaces parsing the logs, but also to generate
|
||||||
|
SLA reports and trends in Icinga 1.x Classic UI. Furthermore the
|
||||||
|
[Livestatus](15-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`.
|
||||||
|
|
||||||
|
The format cannot be changed without breaking compatibility to
|
||||||
|
existing log parsers.
|
||||||
|
|
||||||
|
# tail -f /var/log/icinga2/compat/icinga.log
|
||||||
|
|
||||||
|
[1382115688] LOG ROTATION: HOURLY
|
||||||
|
[1382115688] LOG VERSION: 2.0
|
||||||
|
[1382115688] HOST STATE: CURRENT;localhost;UP;HARD;1;
|
||||||
|
[1382115688] SERVICE STATE: CURRENT;localhost;disk;WARNING;HARD;1;
|
||||||
|
[1382115688] SERVICE STATE: CURRENT;localhost;http;OK;HARD;1;
|
||||||
|
[1382115688] SERVICE STATE: CURRENT;localhost;load;OK;HARD;1;
|
||||||
|
[1382115688] SERVICE STATE: CURRENT;localhost;ping4;OK;HARD;1;
|
||||||
|
[1382115688] SERVICE STATE: CURRENT;localhost;ping6;OK;HARD;1;
|
||||||
|
[1382115688] SERVICE STATE: CURRENT;localhost;processes;WARNING;HARD;1;
|
||||||
|
[1382115688] SERVICE STATE: CURRENT;localhost;ssh;OK;HARD;1;
|
||||||
|
[1382115688] SERVICE STATE: CURRENT;localhost;users;OK;HARD;1;
|
||||||
|
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;disk;1382115705
|
||||||
|
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;http;1382115705
|
||||||
|
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;load;1382115705
|
||||||
|
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382115705
|
||||||
|
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping6;1382115705
|
||||||
|
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;processes;1382115705
|
||||||
|
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ssh;1382115705
|
||||||
|
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;users;1382115705
|
||||||
|
[1382115731] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;localhost;ping6;2;critical test|
|
||||||
|
[1382115731] SERVICE ALERT: localhost;ping6;CRITICAL;SOFT;2;critical test
|
||||||
|
|
||||||
|
|
||||||
|
## <a id="check-result-files"></a> Check Result Files
|
||||||
|
|
||||||
|
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"
|
||||||
|
}
|
||||||
|
|
||||||
@ -1,197 +0,0 @@
|
|||||||
## <a id="setting-up-livestatus"></a> Livestatus
|
|
||||||
|
|
||||||
The [MK Livestatus](http://mathias-kettner.de/checkmk_livestatus.html) project
|
|
||||||
implements a query protocol that lets users query their Icinga instance for
|
|
||||||
status information. It can also be used to send commands.
|
|
||||||
|
|
||||||
> **Tip**
|
|
||||||
>
|
|
||||||
> Only install the Livestatus feature if your web interface or addon requires
|
|
||||||
> you to do so (for example, [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2)).
|
|
||||||
> [Icinga Classic UI](15-alternative-frontends.md#setting-up-icinga-classic-ui) and [Icinga Web](15-alternative-frontends.md#setting-up-icinga-web)
|
|
||||||
> do not use Livestatus as backend.
|
|
||||||
|
|
||||||
The Livestatus component that is distributed as part of Icinga 2 is a
|
|
||||||
re-implementation of the Livestatus protocol which is compatible with MK
|
|
||||||
Livestatus.
|
|
||||||
|
|
||||||
Details on the available tables and attributes with Icinga 2 can be found
|
|
||||||
in the [Livestatus Schema](23-appendix.md#schema-livestatus) section.
|
|
||||||
|
|
||||||
You can enable Livestatus using icinga2 feature enable:
|
|
||||||
|
|
||||||
# icinga2 feature enable livestatus
|
|
||||||
|
|
||||||
After that you will have to restart Icinga 2:
|
|
||||||
|
|
||||||
Debian/Ubuntu, RHEL/CentOS 6 and SUSE:
|
|
||||||
|
|
||||||
# service icinga2 restart
|
|
||||||
|
|
||||||
RHEL/CentOS 7 and Fedora:
|
|
||||||
|
|
||||||
# systemctl restart icinga2
|
|
||||||
|
|
||||||
By default the Livestatus socket is available in `/var/run/icinga2/cmd/livestatus`.
|
|
||||||
|
|
||||||
In order for queries and commands to work you will need to add your query user
|
|
||||||
(e.g. your web server) to the `icingacmd` group:
|
|
||||||
|
|
||||||
# usermod -a -G icingacmd www-data
|
|
||||||
|
|
||||||
The Debian packages use `nagios` as the user and group name. Make sure to change `icingacmd` to
|
|
||||||
`nagios` if you're using Debian.
|
|
||||||
|
|
||||||
Change `www-data` to the user you're using to run queries.
|
|
||||||
|
|
||||||
In order to use the historical tables provided by the livestatus feature (for example, the
|
|
||||||
`log` table) you need to have the `CompatLogger` feature enabled. By default these logs
|
|
||||||
are expected to be in `/var/log/icinga2/compat`. A different path can be set using the
|
|
||||||
`compat_log_path` configuration attribute.
|
|
||||||
|
|
||||||
# icinga2 feature enable compatlog
|
|
||||||
|
|
||||||
|
|
||||||
### <a id="livestatus-sockets"></a> Livestatus Sockets
|
|
||||||
|
|
||||||
Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
|
|
||||||
|
|
||||||
* Unix socket (default)
|
|
||||||
* TCP socket
|
|
||||||
|
|
||||||
Details on the configuration can be found in the [LivestatusListener](6-object-types.md#objecttype-livestatuslistener)
|
|
||||||
object configuration.
|
|
||||||
|
|
||||||
### <a id="livestatus-get-queries"></a> Livestatus GET Queries
|
|
||||||
|
|
||||||
> **Note**
|
|
||||||
>
|
|
||||||
> All Livestatus queries require an additional empty line as query end identifier.
|
|
||||||
> The `nc` tool (`netcat`) provides the `-U` parameter to communicate using
|
|
||||||
> a unix socket.
|
|
||||||
|
|
||||||
There also is a Perl module available in CPAN for accessing the Livestatus socket
|
|
||||||
programmatically: [Monitoring::Livestatus](http://search.cpan.org/~nierlein/Monitoring-Livestatus-0.74/)
|
|
||||||
|
|
||||||
|
|
||||||
Example using the unix socket:
|
|
||||||
|
|
||||||
# echo -e "GET services\n" | /usr/bin/nc -U /var/run/icinga2/cmd/livestatus
|
|
||||||
|
|
||||||
Example using the tcp socket listening on port `6558`:
|
|
||||||
|
|
||||||
# echo -e 'GET services\n' | netcat 127.0.0.1 6558
|
|
||||||
|
|
||||||
# cat servicegroups <<EOF
|
|
||||||
GET servicegroups
|
|
||||||
|
|
||||||
EOF
|
|
||||||
|
|
||||||
(cat servicegroups; sleep 1) | netcat 127.0.0.1 6558
|
|
||||||
|
|
||||||
|
|
||||||
### <a id="livestatus-command-queries"></a> Livestatus COMMAND Queries
|
|
||||||
|
|
||||||
A list of available external commands and their parameters can be found [here](23-appendix.md#external-commands-list-detail)
|
|
||||||
|
|
||||||
$ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
|
|
||||||
|
|
||||||
|
|
||||||
### <a id="livestatus-filters"></a> Livestatus Filters
|
|
||||||
|
|
||||||
and, or, negate
|
|
||||||
|
|
||||||
Operator | Negate | Description
|
|
||||||
----------|------------------------
|
|
||||||
= | != | Equality
|
|
||||||
~ | !~ | Regex match
|
|
||||||
=~ | !=~ | Equality ignoring case
|
|
||||||
~~ | !~~ | Regex ignoring case
|
|
||||||
< | | Less than
|
|
||||||
> | | Greater than
|
|
||||||
<= | | Less than or equal
|
|
||||||
>= | | Greater than or equal
|
|
||||||
|
|
||||||
|
|
||||||
### <a id="livestatus-stats"></a> Livestatus Stats
|
|
||||||
|
|
||||||
Schema: "Stats: aggregatefunction aggregateattribute"
|
|
||||||
|
|
||||||
Aggregate Function | Description
|
|
||||||
-------------------|--------------
|
|
||||||
sum |
|
|
||||||
min |
|
|
||||||
max |
|
|
||||||
avg | sum / count
|
|
||||||
std | standard deviation
|
|
||||||
suminv | sum (1 / value)
|
|
||||||
avginv | suminv / count
|
|
||||||
count | ordinary default for any stats query if not aggregate function defined
|
|
||||||
|
|
||||||
Example:
|
|
||||||
|
|
||||||
GET hosts
|
|
||||||
Filter: has_been_checked = 1
|
|
||||||
Filter: check_type = 0
|
|
||||||
Stats: sum execution_time
|
|
||||||
Stats: sum latency
|
|
||||||
Stats: sum percent_state_change
|
|
||||||
Stats: min execution_time
|
|
||||||
Stats: min latency
|
|
||||||
Stats: min percent_state_change
|
|
||||||
Stats: max execution_time
|
|
||||||
Stats: max latency
|
|
||||||
Stats: max percent_state_change
|
|
||||||
OutputFormat: json
|
|
||||||
ResponseHeader: fixed16
|
|
||||||
|
|
||||||
### <a id="livestatus-output"></a> Livestatus Output
|
|
||||||
|
|
||||||
* CSV
|
|
||||||
|
|
||||||
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 pipe (2nd level).
|
|
||||||
|
|
||||||
Separators can be set using ASCII codes like:
|
|
||||||
|
|
||||||
Separators: 10 59 44 124
|
|
||||||
|
|
||||||
* JSON
|
|
||||||
|
|
||||||
Default separators.
|
|
||||||
|
|
||||||
### <a id="livestatus-error-codes"></a> Livestatus Error Codes
|
|
||||||
|
|
||||||
Code | Description
|
|
||||||
----------|--------------
|
|
||||||
200 | OK
|
|
||||||
404 | Table does not exist
|
|
||||||
452 | Exception on query
|
|
||||||
|
|
||||||
### <a id="livestatus-tables"></a> Livestatus Tables
|
|
||||||
|
|
||||||
Table | Join |Description
|
|
||||||
--------------|-----------|----------------------------
|
|
||||||
hosts | | host config and status attributes, services counter
|
|
||||||
hostgroups | | hostgroup config, status attributes and host/service counters
|
|
||||||
services | hosts | service config and status attributes
|
|
||||||
servicegroups | | servicegroup config, status attributes and service counters
|
|
||||||
contacts | | contact config and status attributes
|
|
||||||
contactgroups | | contact config, members
|
|
||||||
commands | | command name and line
|
|
||||||
status | | programstatus, config and stats
|
|
||||||
comments | services | status attributes
|
|
||||||
downtimes | services | status attributes
|
|
||||||
timeperiods | | name and is inside flag
|
|
||||||
endpoints | | config and status attributes
|
|
||||||
log | services, hosts, contacts, commands | parses [compatlog](6-object-types.md#objecttype-compatlogger) and shows log attributes
|
|
||||||
statehist | hosts, services | parses [compatlog](6-object-types.md#objecttype-compatlogger) and aggregates state change attributes
|
|
||||||
hostsbygroup | hostgroups | host attributes grouped by hostgroup and its attributes
|
|
||||||
servicesbygroup | servicegroups | service attributes grouped by servicegroup and its attributes
|
|
||||||
servicesbyhostgroup | hostgroups | service attributes grouped by hostgroup and its attributes
|
|
||||||
|
|
||||||
The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects.
|
|
||||||
|
|
||||||
A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](23-appendix.md#schema-livestatus).
|
|
||||||
|
|
||||||
@ -13,7 +13,7 @@
|
|||||||
* How was Icinga 2 installed (and which repository in case) and which distribution are you using
|
* How was Icinga 2 installed (and which repository in case) and which distribution are you using
|
||||||
* Provide complete configuration snippets explaining your problem in detail
|
* Provide complete configuration snippets explaining your problem in detail
|
||||||
* If the check command failed - what's the output of your manual plugin tests?
|
* If the check command failed - what's the output of your manual plugin tests?
|
||||||
* In case of [debugging](22-debug.md#debug) Icinga 2, the full back traces and outputs
|
* In case of [debugging](20-debug.md#debug) Icinga 2, the full back traces and outputs
|
||||||
|
|
||||||
## <a id="troubleshooting-enable-debug-output"></a> Enable Debug Output
|
## <a id="troubleshooting-enable-debug-output"></a> Enable Debug Output
|
||||||
|
|
||||||
@ -37,7 +37,7 @@ and `debug`.
|
|||||||
The `icinga2 object list` CLI command can be used to list all configuration objects and their
|
The `icinga2 object list` CLI command can be used to list all configuration objects and their
|
||||||
attributes. The tool also shows where each of the attributes was modified.
|
attributes. The tool also shows where each of the attributes was modified.
|
||||||
|
|
||||||
That way you can also identify which objects have been created from your [apply rules](20-language-reference.md#apply).
|
That way you can also identify which objects have been created from your [apply rules](18-language-reference.md#apply).
|
||||||
|
|
||||||
# icinga2 object list
|
# icinga2 object list
|
||||||
|
|
||||||
@ -114,7 +114,7 @@ or similar.
|
|||||||
* Check the debug log to see if the check command gets executed
|
* Check the debug log to see if the check command gets executed
|
||||||
* Verify that failed depedencies do not prevent command execution
|
* Verify that failed depedencies do not prevent command execution
|
||||||
* Make sure that the plugin is executable by the Icinga 2 user (run a manual test)
|
* Make sure that the plugin is executable by the Icinga 2 user (run a manual test)
|
||||||
* Make sure the [checker](8-cli-commands.md#features) feature is enabled.
|
* Make sure the [checker](8-cli-commands.md#enable-features) feature is enabled.
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
|
|
||||||
@ -136,7 +136,7 @@ Verify the following configuration
|
|||||||
* Do the notification attributes `states`, `types`, `period` match the notification conditions?
|
* Do the notification attributes `states`, `types`, `period` match the notification conditions?
|
||||||
* Do the user attributes `states`, `types`, `period` match the notification conditions?
|
* Do the user attributes `states`, `types`, `period` match the notification conditions?
|
||||||
* Are there any notification `begin` and `end` times configured?
|
* Are there any notification `begin` and `end` times configured?
|
||||||
* Make sure the [notification](8-cli-commands.md#features) feature is enabled.
|
* Make sure the [notification](8-cli-commands.md#enable-features) feature is enabled.
|
||||||
* Does the referenced NotificationCommand work when executed as Icinga user on the shell?
|
* Does the referenced NotificationCommand work when executed as Icinga user on the shell?
|
||||||
|
|
||||||
If notifications are to be sent via mail make sure that the mail program specified exists.
|
If notifications are to be sent via mail make sure that the mail program specified exists.
|
||||||
@ -157,13 +157,13 @@ to `features-enabled` and that the latter is included in [icinga2.conf](4-config
|
|||||||
|
|
||||||
## <a id="configuration-ignored"></a> Configuration is ignored
|
## <a id="configuration-ignored"></a> Configuration is ignored
|
||||||
|
|
||||||
* Make sure that the line(s) are not [commented out](20-language-reference.md#comments) (starting with `//` or `#`, or
|
* Make sure that the line(s) are not [commented out](18-language-reference.md#comments) (starting with `//` or `#`, or
|
||||||
encapsulated by `/* ... */`).
|
encapsulated by `/* ... */`).
|
||||||
* Is the configuration file included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf)?
|
* Is the configuration file included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf)?
|
||||||
|
|
||||||
## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from
|
## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from
|
||||||
|
|
||||||
Icinga 2 allows you to import templates using the [import](20-language-reference.md#template-imports) keyword. If these templates
|
Icinga 2 allows you to import templates using the [import](18-language-reference.md#template-imports) keyword. If these templates
|
||||||
contain additional attributes, your objects will automatically inherit them. You can override
|
contain additional attributes, your objects will automatically inherit them. You can override
|
||||||
or modify these attributes in the current object.
|
or modify these attributes in the current object.
|
||||||
|
|
||||||
@ -248,7 +248,7 @@ Try to manually connect from `icinga2-node2.localdomain` to the master node `ici
|
|||||||
---
|
---
|
||||||
...
|
...
|
||||||
|
|
||||||
If the connection attempt fails or your CA does not match, [verify the master and client certificates](17-troubleshooting.md#troubleshooting-cluster-ssl-certificate-verification).
|
If the connection attempt fails or your CA does not match, [verify the master and client certificates](16-troubleshooting.md#troubleshooting-cluster-ssl-certificate-verification).
|
||||||
|
|
||||||
#### <a id="troubleshooting-cluster-unauthenticated-clients"></a> Cluster Troubleshooting Unauthenticated Clients
|
#### <a id="troubleshooting-cluster-unauthenticated-clients"></a> Cluster Troubleshooting Unauthenticated Clients
|
||||||
|
|
||||||
@ -263,7 +263,7 @@ Client as command execution bridge:
|
|||||||
|
|
||||||
[2015-07-13 18:29:26 +1000] notice/ApiEvents: Discarding 'execute command' message from 'icinga-master': Invalid endpoint origin (client not allowed).
|
[2015-07-13 18:29:26 +1000] notice/ApiEvents: Discarding 'execute command' message from 'icinga-master': Invalid endpoint origin (client not allowed).
|
||||||
|
|
||||||
If these messages do not go away, make sure to [verify the master and client certificates](17-troubleshooting.md#troubleshooting-cluster-ssl-certificate-verification).
|
If these messages do not go away, make sure to [verify the master and client certificates](16-troubleshooting.md#troubleshooting-cluster-ssl-certificate-verification).
|
||||||
|
|
||||||
#### <a id="troubleshooting-cluster-ssl-certificate-verification"></a> Cluster Troubleshooting SSL Certificate Verification
|
#### <a id="troubleshooting-cluster-ssl-certificate-verification"></a> Cluster Troubleshooting SSL Certificate Verification
|
||||||
|
|
||||||
@ -289,7 +289,7 @@ At some point, when the network connection is broken or gone, the Icinga 2 insta
|
|||||||
will be disconnected. If the connection can't be re-established between zones and endpoints,
|
will be disconnected. If the connection can't be re-established between zones and endpoints,
|
||||||
they remain in a Split-Brain-mode and history may differ.
|
they remain in a Split-Brain-mode and history may differ.
|
||||||
|
|
||||||
Although the Icinga 2 cluster protocol stores historical events in a [replay log](17-troubleshooting.md#troubleshooting-cluster-replay-log)
|
Although the Icinga 2 cluster protocol stores historical events in a [replay log](16-troubleshooting.md#troubleshooting-cluster-replay-log)
|
||||||
for later synchronisation, you should make sure to check why the network connection failed.
|
for later synchronisation, you should make sure to check why the network connection failed.
|
||||||
|
|
||||||
### <a id="troubleshooting-cluster-command-endpoint-errors"></a> Cluster Troubleshooting Command Endpoint Errors
|
### <a id="troubleshooting-cluster-command-endpoint-errors"></a> Cluster Troubleshooting Command Endpoint Errors
|
||||||
@ -306,7 +306,7 @@ the following (e.g. by invoking a forced check from the web interface):
|
|||||||
* Referenced check plugin not found on the remote client.
|
* Referenced check plugin not found on the remote client.
|
||||||
* Runtime warnings and errors, e.g. unresolved runtime macros or configuration problems.
|
* Runtime warnings and errors, e.g. unresolved runtime macros or configuration problems.
|
||||||
* Specific error messages are also populated into `UNKNOWN` check results including a detailed error message in their output.
|
* Specific error messages are also populated into `UNKNOWN` check results including a detailed error message in their output.
|
||||||
* More verbose logs are found inside the [debug log](17-troubleshooting.md#troubleshooting-enable-debug-output).
|
* More verbose logs are found inside the [debug log](16-troubleshooting.md#troubleshooting-enable-debug-output).
|
||||||
|
|
||||||
### <a id="troubleshooting-cluster-config-sync"></a> Cluster Troubleshooting Config Sync
|
### <a id="troubleshooting-cluster-config-sync"></a> Cluster Troubleshooting Config Sync
|
||||||
|
|
||||||
@ -333,10 +333,10 @@ certificate's CN, the master will deny all events.
|
|||||||
> [Icinga Web 2](2-getting-started.md#setting-up-the-user-interface) provides a dashboard view
|
> [Icinga Web 2](2-getting-started.md#setting-up-the-user-interface) provides a dashboard view
|
||||||
> for overdue check results.
|
> for overdue check results.
|
||||||
|
|
||||||
Enable the [debug log](17-troubleshooting.md#troubleshooting-enable-debug-output) on the master
|
Enable the [debug log](16-troubleshooting.md#troubleshooting-enable-debug-output) on the master
|
||||||
for more verbose insights.
|
for more verbose insights.
|
||||||
|
|
||||||
If the client cannot authenticate, it's a more general [problem](17-troubleshooting.md#troubleshooting-cluster-unauthenticated-clients).
|
If the client cannot authenticate, it's a more general [problem](16-troubleshooting.md#troubleshooting-cluster-unauthenticated-clients).
|
||||||
|
|
||||||
The client's endpoint is not configured on nor trusted by the master node:
|
The client's endpoint is not configured on nor trusted by the master node:
|
||||||
|
|
||||||
@ -357,6 +357,6 @@ will store all events for not connected endpoints in the same and child zones.
|
|||||||
Check the following:
|
Check the following:
|
||||||
|
|
||||||
* All clients are connected? (e.g. [cluster health check](13-distributed-monitoring-ha.md#cluster-health-check)).
|
* All clients are connected? (e.g. [cluster health check](13-distributed-monitoring-ha.md#cluster-health-check)).
|
||||||
* Check your [connection](17-troubleshooting.md#troubleshooting-cluster-connection-errors) in general.
|
* Check your [connection](16-troubleshooting.md#troubleshooting-cluster-connection-errors) in general.
|
||||||
* Does the log replay work, e.g. are all events processed and the directory gets cleared up over time?
|
* Does the log replay work, e.g. are all events processed and the directory gets cleared up over time?
|
||||||
* Decrease the `log_duration` attribute value for that specific [endpoint](6-object-types.md#objecttype-endpoint).
|
* Decrease the `log_duration` attribute value for that specific [endpoint](6-object-types.md#objecttype-endpoint).
|
||||||
@ -199,7 +199,7 @@ Functions can be called using the `()` operator:
|
|||||||
check_interval = len(MyGroups) * 1m
|
check_interval = len(MyGroups) * 1m
|
||||||
}
|
}
|
||||||
|
|
||||||
A list of available functions is available in the [Library Reference](21-library-reference.md#library-reference) chapter.
|
A list of available functions is available in the [Library Reference](19-library-reference.md#library-reference) chapter.
|
||||||
|
|
||||||
## <a id="dictionary-operators"></a> Assignments
|
## <a id="dictionary-operators"></a> Assignments
|
||||||
|
|
||||||
@ -388,7 +388,7 @@ another group of objects.
|
|||||||
|
|
||||||
In this example the `assign where` condition is a boolean expression which is
|
In this example the `assign where` condition is a boolean expression which is
|
||||||
evaluated for all objects of type `Host` and a new service with name "ping"
|
evaluated for all objects of type `Host` and a new service with name "ping"
|
||||||
is created for each matching host. [Expression operators](20-language-reference.md#expression-operators)
|
is created for each matching host. [Expression operators](18-language-reference.md#expression-operators)
|
||||||
may be used in `assign where` conditions.
|
may be used in `assign where` conditions.
|
||||||
|
|
||||||
The `to` keyword and the target type may be omitted if there is only one target
|
The `to` keyword and the target type may be omitted if there is only one target
|
||||||
@ -416,8 +416,8 @@ chapter.
|
|||||||
|
|
||||||
## <a id="apply-for"></a> Apply For
|
## <a id="apply-for"></a> Apply For
|
||||||
|
|
||||||
[Apply](20-language-reference.md#apply) rules can be extended with the
|
[Apply](18-language-reference.md#apply) rules can be extended with the
|
||||||
[for loop](20-language-reference.md#for-loops) keyword.
|
[for loop](18-language-reference.md#for-loops) keyword.
|
||||||
|
|
||||||
apply Service "prefix-" for (key => value in host.vars.dictionary) to Host {
|
apply Service "prefix-" for (key => value in host.vars.dictionary) to Host {
|
||||||
import "generic-service"
|
import "generic-service"
|
||||||
@ -461,7 +461,7 @@ and `ignore where` conditions.
|
|||||||
In this example the `assign where` condition is a boolean expression which is evaluated
|
In this example the `assign where` condition is a boolean expression which is evaluated
|
||||||
for all objects of the type `Host`. Each matching host is added as member to the host group
|
for all objects of the type `Host`. Each matching host is added as member to the host group
|
||||||
with the name "linux-servers". Membership exclusion can be controlled using the `ignore where`
|
with the name "linux-servers". Membership exclusion can be controlled using the `ignore where`
|
||||||
condition. [Expression operators](20-language-reference.md#expression-operators) may be used in `assign where` and
|
condition. [Expression operators](18-language-reference.md#expression-operators) may be used in `assign where` and
|
||||||
`ignore where` conditions.
|
`ignore where` conditions.
|
||||||
|
|
||||||
Source Type | Variables
|
Source Type | Variables
|
||||||
@ -490,7 +490,7 @@ Empty dictionary | {} | false
|
|||||||
Non-empty dictionary | { key = "value" } | true
|
Non-empty dictionary | { key = "value" } | true
|
||||||
|
|
||||||
For a list of supported expression operators for `assign where` and `ignore where`
|
For a list of supported expression operators for `assign where` and `ignore where`
|
||||||
statements, see [expression operators](20-language-reference.md#expression-operators).
|
statements, see [expression operators](18-language-reference.md#expression-operators).
|
||||||
|
|
||||||
## <a id="comments"></a> Comments
|
## <a id="comments"></a> Comments
|
||||||
|
|
||||||
@ -857,7 +857,7 @@ supports:
|
|||||||
keys(String.prototype)
|
keys(String.prototype)
|
||||||
|
|
||||||
Additional documentation on type methods is available in the
|
Additional documentation on type methods is available in the
|
||||||
[library reference](21-library-reference.md#library-reference).
|
[library reference](19-library-reference.md#library-reference).
|
||||||
|
|
||||||
## <a id="reserved-keywords"></a> Reserved Keywords
|
## <a id="reserved-keywords"></a> Reserved Keywords
|
||||||
|
|
||||||
@ -413,7 +413,7 @@ Signature:
|
|||||||
function contains(str);
|
function contains(str);
|
||||||
|
|
||||||
Returns `true` if the string `str` was found in the string. If the string
|
Returns `true` if the string `str` was found in the string. If the string
|
||||||
was not found `false` is returned. Use [find](21-library-reference.md#string-find)
|
was not found `false` is returned. Use [find](19-library-reference.md#string-find)
|
||||||
for getting the index instead.
|
for getting the index instead.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
@ -522,7 +522,7 @@ object is recursively copied.
|
|||||||
|
|
||||||
## <a id="array-type"></a> Array type
|
## <a id="array-type"></a> Array type
|
||||||
|
|
||||||
Inherits methods from the [object type](21-library-reference.md#object-type).
|
Inherits methods from the [object type](19-library-reference.md#object-type).
|
||||||
|
|
||||||
### <a id="array-add"></a> Array#add
|
### <a id="array-add"></a> Array#add
|
||||||
|
|
||||||
@ -616,7 +616,7 @@ Returns a new array with all elements of the current array in reverse order.
|
|||||||
|
|
||||||
## <a id="dictionary-type"></a> Dictionary type
|
## <a id="dictionary-type"></a> Dictionary type
|
||||||
|
|
||||||
Inherits methods from the [object type](21-library-reference.md#object-type).
|
Inherits methods from the [object type](19-library-reference.md#object-type).
|
||||||
|
|
||||||
### <a id="dictionary-shallow-clone"></a> Dictionary#shallow_clone
|
### <a id="dictionary-shallow-clone"></a> Dictionary#shallow_clone
|
||||||
|
|
||||||
@ -312,10 +312,7 @@ Test it:
|
|||||||
## <a id="setting-up-the-user-interface"></a> Setting up Icinga Web 2
|
## <a id="setting-up-the-user-interface"></a> Setting up Icinga Web 2
|
||||||
|
|
||||||
Icinga 2 can be used with Icinga Web 2 and a number of other web interfaces.
|
Icinga 2 can be used with Icinga Web 2 and a number of other web interfaces.
|
||||||
This chapter explains how to set up Icinga Web 2. The
|
This chapter explains how to set up Icinga Web 2.
|
||||||
[Alternative Frontends](15-alternative-frontends.md#alternative-frontends)
|
|
||||||
chapter can be used as a starting point for installing some of the other web
|
|
||||||
interfaces which are also available.
|
|
||||||
|
|
||||||
The DB IDO (Database Icinga Data Output) modules for Icinga 2 take care of
|
The DB IDO (Database Icinga Data Output) modules for Icinga 2 take care of
|
||||||
exporting all configuration and status information into a database. The IDO
|
exporting all configuration and status information into a database. The IDO
|
||||||
|
|||||||
@ -29,7 +29,7 @@ object specific policies.
|
|||||||
For a long-term migration of your configuration you should consider re-creating
|
For a long-term migration of your configuration you should consider re-creating
|
||||||
your configuration based on the proposed Icinga 2 configuration paradigm.
|
your configuration based on the proposed Icinga 2 configuration paradigm.
|
||||||
|
|
||||||
Please read the [next chapter](19-migrating-from-icinga-1x.md#differences-1x-2) to find out more about the differences
|
Please read the [next chapter](21-migrating-from-icinga-1x.md#differences-1x-2) to find out more about the differences
|
||||||
between 1.x and 2.
|
between 1.x and 2.
|
||||||
|
|
||||||
### <a id="manual-config-migration-hints"></a> Manual Config Migration Hints
|
### <a id="manual-config-migration-hints"></a> Manual Config Migration Hints
|
||||||
@ -42,7 +42,7 @@ The examples are taken from Icinga 1.x test and production environments and conv
|
|||||||
straight into a possible Icinga 2 format. If you found a different strategy, please
|
straight into a possible Icinga 2 format. If you found a different strategy, please
|
||||||
let us know!
|
let us know!
|
||||||
|
|
||||||
If you require in-depth explanations, please check the [next chapter](19-migrating-from-icinga-1x.md#differences-1x-2).
|
If you require in-depth explanations, please check the [next chapter](21-migrating-from-icinga-1x.md#differences-1x-2).
|
||||||
|
|
||||||
#### <a id="manual-config-migration-hints-Intervals"></a> Manual Config Migration Hints for Intervals
|
#### <a id="manual-config-migration-hints-Intervals"></a> Manual Config Migration Hints for Intervals
|
||||||
|
|
||||||
@ -129,7 +129,7 @@ a member and includes all members of the `hg1` hostgroup.
|
|||||||
hostgroup_members hg1
|
hostgroup_members hg1
|
||||||
}
|
}
|
||||||
|
|
||||||
This can be migrated to Icinga 2 and [using group assign](20-language-reference.md#group-assign). The additional nested hostgroup
|
This can be migrated to Icinga 2 and [using group assign](18-language-reference.md#group-assign). The additional nested hostgroup
|
||||||
`hg1` is included into `hg2` with the `groups` attribute.
|
`hg1` is included into `hg2` with the `groups` attribute.
|
||||||
|
|
||||||
|
|
||||||
@ -205,7 +205,7 @@ While you could manually migrate this like (please note the new generic command
|
|||||||
|
|
||||||
#### <a id="manual-config-migration-hints-runtime-macros"></a> Manual Config Migration Hints for Runtime Macros
|
#### <a id="manual-config-migration-hints-runtime-macros"></a> Manual Config Migration Hints for Runtime Macros
|
||||||
|
|
||||||
Runtime macros have been renamed. A detailed comparison table can be found [here](19-migrating-from-icinga-1x.md#differences-1x-2-runtime-macros).
|
Runtime macros have been renamed. A detailed comparison table can be found [here](21-migrating-from-icinga-1x.md#differences-1x-2-runtime-macros).
|
||||||
|
|
||||||
For example, accessing the service check output looks like the following in Icinga 1.x:
|
For example, accessing the service check output looks like the following in Icinga 1.x:
|
||||||
|
|
||||||
@ -278,7 +278,7 @@ while the service check command resolves its value to the service attribute attr
|
|||||||
#### <a id="manual-config-migration-hints-contacts-users"></a> Manual Config Migration Hints for Contacts (Users)
|
#### <a id="manual-config-migration-hints-contacts-users"></a> Manual Config Migration Hints for Contacts (Users)
|
||||||
|
|
||||||
Contacts in Icinga 1.x act as users in Icinga 2, but do not have any notification commands specified.
|
Contacts in Icinga 1.x act as users in Icinga 2, but do not have any notification commands specified.
|
||||||
This migration part is explained in the [next chapter](19-migrating-from-icinga-1x.md#manual-config-migration-hints-notifications).
|
This migration part is explained in the [next chapter](21-migrating-from-icinga-1x.md#manual-config-migration-hints-notifications).
|
||||||
|
|
||||||
define contact{
|
define contact{
|
||||||
contact_name testconfig-user
|
contact_name testconfig-user
|
||||||
@ -288,7 +288,7 @@ This migration part is explained in the [next chapter](19-migrating-from-icinga-
|
|||||||
email icinga@localhost
|
email icinga@localhost
|
||||||
}
|
}
|
||||||
|
|
||||||
The `service_notification_options` can be [mapped](19-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters)
|
The `service_notification_options` can be [mapped](21-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters)
|
||||||
into generic `state` and `type` filters, if additional notification filtering is required. `alias` gets
|
into generic `state` and `type` filters, if additional notification filtering is required. `alias` gets
|
||||||
renamed to `display_name`.
|
renamed to `display_name`.
|
||||||
|
|
||||||
@ -340,7 +340,7 @@ Assign it to the host or service and set the newly generated notification comman
|
|||||||
|
|
||||||
|
|
||||||
Convert the `notification_options` attribute from Icinga 1.x to Icinga 2 `states` and `types`. Details
|
Convert the `notification_options` attribute from Icinga 1.x to Icinga 2 `states` and `types`. Details
|
||||||
[here](19-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters). Add the notification period.
|
[here](21-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters). Add the notification period.
|
||||||
|
|
||||||
states = [ OK, Warning, Critical ]
|
states = [ OK, Warning, Critical ]
|
||||||
types = [ Recovery, Problem, Custom ]
|
types = [ Recovery, Problem, Custom ]
|
||||||
@ -577,7 +577,7 @@ enabled.
|
|||||||
assign where "hg_svcdep2" in host.groups
|
assign where "hg_svcdep2" in host.groups
|
||||||
}
|
}
|
||||||
|
|
||||||
Host dependencies are explained in the [next chapter](19-migrating-from-icinga-1x.md#manual-config-migration-hints-host-parents).
|
Host dependencies are explained in the [next chapter](21-migrating-from-icinga-1x.md#manual-config-migration-hints-host-parents).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -744,11 +744,11 @@ included in `icinga2.conf` by default.
|
|||||||
### <a id="differences-1x-2-main-config"></a> Main Config File
|
### <a id="differences-1x-2-main-config"></a> Main Config File
|
||||||
|
|
||||||
In Icinga 1.x there are many global configuration settings available in `icinga.cfg`.
|
In Icinga 1.x there are many global configuration settings available in `icinga.cfg`.
|
||||||
Icinga 2 only uses a small set of [global constants](20-language-reference.md#constants) allowing
|
Icinga 2 only uses a small set of [global constants](18-language-reference.md#constants) allowing
|
||||||
you to specify certain different setting such as the `NodeName` in a cluster scenario.
|
you to specify certain different setting such as the `NodeName` in a cluster scenario.
|
||||||
|
|
||||||
Aside from that, the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) should take care of including
|
Aside from that, the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) should take care of including
|
||||||
global constants, enabled [features](8-cli-commands.md#features) and the object configuration.
|
global constants, enabled [features](8-cli-commands.md#enable-features) and the object configuration.
|
||||||
|
|
||||||
### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories
|
### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories
|
||||||
|
|
||||||
@ -797,7 +797,7 @@ set in the `constants.conf` configuration file:
|
|||||||
|
|
||||||
const PluginDir = "/usr/lib/nagios/plugins"
|
const PluginDir = "/usr/lib/nagios/plugins"
|
||||||
|
|
||||||
[Global macros](20-language-reference.md#constants) can only be defined once. Trying to modify a
|
[Global macros](18-language-reference.md#constants) can only be defined once. Trying to modify a
|
||||||
global constant will result in an error.
|
global constant will result in an error.
|
||||||
|
|
||||||
### <a id="differences-1x-2-configuration-comments"></a> Configuration Comments
|
### <a id="differences-1x-2-configuration-comments"></a> Configuration Comments
|
||||||
@ -948,7 +948,7 @@ In Icinga 1.x arguments are specified in the `check_command` attribute and
|
|||||||
are separated from the command name using an exclamation mark (`!`).
|
are separated from the command name using an exclamation mark (`!`).
|
||||||
|
|
||||||
Please check the migration hints for a detailed
|
Please check the migration hints for a detailed
|
||||||
[migration example](19-migrating-from-icinga-1x.md#manual-config-migration-hints-check-command-arguments).
|
[migration example](21-migrating-from-icinga-1x.md#manual-config-migration-hints-check-command-arguments).
|
||||||
|
|
||||||
> **Note**
|
> **Note**
|
||||||
>
|
>
|
||||||
@ -1340,7 +1340,7 @@ child attributes may be omitted.
|
|||||||
For detailed examples on how to use the dependencies please check the [dependencies](3-monitoring-basics.md#dependencies)
|
For detailed examples on how to use the dependencies please check the [dependencies](3-monitoring-basics.md#dependencies)
|
||||||
chapter.
|
chapter.
|
||||||
|
|
||||||
Dependencies can be applied to hosts or services using the [apply rules](20-language-reference.md#apply).
|
Dependencies can be applied to hosts or services using the [apply rules](18-language-reference.md#apply).
|
||||||
|
|
||||||
The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
|
The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
|
||||||
support the Icinga 1.x schema with dependencies and parent attributes for
|
support the Icinga 1.x schema with dependencies and parent attributes for
|
||||||
@ -46,7 +46,7 @@ check command.
|
|||||||
The `address` attribute is used by check commands to determine which network
|
The `address` attribute is used by check commands to determine which network
|
||||||
address is associated with the host object.
|
address is associated with the host object.
|
||||||
|
|
||||||
Details on troubleshooting check problems can be found [here](17-troubleshooting.md#troubleshooting).
|
Details on troubleshooting check problems can be found [here](16-troubleshooting.md#troubleshooting).
|
||||||
|
|
||||||
### <a id="host-states"></a> Host States
|
### <a id="host-states"></a> Host States
|
||||||
|
|
||||||
@ -152,13 +152,13 @@ In addition to built-in attributes you can define your own attributes:
|
|||||||
|
|
||||||
Valid values for custom attributes include:
|
Valid values for custom attributes include:
|
||||||
|
|
||||||
* [Strings](20-language-reference.md#string-literals), [numbers](20-language-reference.md#numeric-literals) and [booleans](20-language-reference.md#boolean-literals)
|
* [Strings](18-language-reference.md#string-literals), [numbers](18-language-reference.md#numeric-literals) and [booleans](18-language-reference.md#boolean-literals)
|
||||||
* [Arrays](20-language-reference.md#array) and [dictionaries](20-language-reference.md#dictionary)
|
* [Arrays](18-language-reference.md#array) and [dictionaries](18-language-reference.md#dictionary)
|
||||||
* [Functions](3-monitoring-basics.md#custom-attributes-functions)
|
* [Functions](3-monitoring-basics.md#custom-attributes-functions)
|
||||||
|
|
||||||
### <a id="custom-attributes-functions"></a> Functions as Custom Attributes
|
### <a id="custom-attributes-functions"></a> Functions as Custom Attributes
|
||||||
|
|
||||||
Icinga 2 lets you specify [functions](20-language-reference.md#functions) for custom attributes.
|
Icinga 2 lets you specify [functions](18-language-reference.md#functions) for custom attributes.
|
||||||
The special case here is that whenever Icinga 2 needs the value for such a custom attribute it runs
|
The special case here is that whenever Icinga 2 needs the value for such a custom attribute it runs
|
||||||
the function and uses whatever value the function returns:
|
the function and uses whatever value the function returns:
|
||||||
|
|
||||||
@ -170,7 +170,7 @@ the function and uses whatever value the function returns:
|
|||||||
vars.text = {{ Math.random() * 100 }}
|
vars.text = {{ Math.random() * 100 }}
|
||||||
}
|
}
|
||||||
|
|
||||||
This example uses the [abbreviated lambda syntax](20-language-reference.md#nullary-lambdas).
|
This example uses the [abbreviated lambda syntax](18-language-reference.md#nullary-lambdas).
|
||||||
|
|
||||||
These functions have access to a number of variables:
|
These functions have access to a number of variables:
|
||||||
|
|
||||||
@ -430,15 +430,15 @@ The following macros provide global statistics:
|
|||||||
Instead of assigning each object ([Service](6-object-types.md#objecttype-service),
|
Instead of assigning each object ([Service](6-object-types.md#objecttype-service),
|
||||||
[Notification](6-object-types.md#objecttype-notification), [Dependency](6-object-types.md#objecttype-dependency),
|
[Notification](6-object-types.md#objecttype-notification), [Dependency](6-object-types.md#objecttype-dependency),
|
||||||
[ScheduledDowntime](6-object-types.md#objecttype-scheduleddowntime))
|
[ScheduledDowntime](6-object-types.md#objecttype-scheduleddowntime))
|
||||||
based on attribute identifiers for example `host_name` objects can be [applied](20-language-reference.md#apply).
|
based on attribute identifiers for example `host_name` objects can be [applied](18-language-reference.md#apply).
|
||||||
|
|
||||||
Before you start using the apply rules keep the following in mind:
|
Before you start using the apply rules keep the following in mind:
|
||||||
|
|
||||||
* Define the best match.
|
* Define the best match.
|
||||||
* A set of unique [custom attributes](3-monitoring-basics.md#custom-attributes) for these hosts/services?
|
* A set of unique [custom attributes](3-monitoring-basics.md#custom-attributes) for these hosts/services?
|
||||||
* Or [group](3-monitoring-basics.md#groups) memberships, e.g. a host being a member of a hostgroup, applying services to it?
|
* Or [group](3-monitoring-basics.md#groups) memberships, e.g. a host being a member of a hostgroup, applying services to it?
|
||||||
* A generic pattern [match](20-language-reference.md#function-calls) on the host/service name?
|
* A generic pattern [match](18-language-reference.md#function-calls) on the host/service name?
|
||||||
* [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](20-language-reference.md#expression-operators)
|
* [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](18-language-reference.md#expression-operators)
|
||||||
* All expressions must return a boolean value (an empty string is equal to `false` e.g.)
|
* All expressions must return a boolean value (an empty string is equal to `false` e.g.)
|
||||||
|
|
||||||
> **Note**
|
> **Note**
|
||||||
@ -502,7 +502,7 @@ two condition passes: Either the `customer` host custom attribute is set to `cus
|
|||||||
`OR` the host custom attribute `always_notify` is set to `true`.
|
`OR` the host custom attribute `always_notify` is set to `true`.
|
||||||
|
|
||||||
The notification is ignored for services whose host name ends with `*internal`
|
The notification is ignored for services whose host name ends with `*internal`
|
||||||
`OR` the `priority` custom attribute is [less than](20-language-reference.md#expression-operators) `2`.
|
`OR` the `priority` custom attribute is [less than](18-language-reference.md#expression-operators) `2`.
|
||||||
|
|
||||||
template Notification "cust-xy-notification" {
|
template Notification "cust-xy-notification" {
|
||||||
users = [ "noc-xy", "mgmt-xy" ]
|
users = [ "noc-xy", "mgmt-xy" ]
|
||||||
@ -556,7 +556,7 @@ In this example the `mail-noc` notification will be created as object for all se
|
|||||||
and all members of the user group `noc` will get notified.
|
and all members of the user group `noc` will get notified.
|
||||||
|
|
||||||
It is also possible to generally apply a notification template and dynamically overwrite values from
|
It is also possible to generally apply a notification template and dynamically overwrite values from
|
||||||
the template by checking for custom attributes. This can be achieved by using [conditional statements](20-language-reference.md#conditional-statements):
|
the template by checking for custom attributes. This can be achieved by using [conditional statements](18-language-reference.md#conditional-statements):
|
||||||
|
|
||||||
apply Notification "host-mail-noc" to Host {
|
apply Notification "host-mail-noc" to Host {
|
||||||
import "mail-host-notification"
|
import "mail-host-notification"
|
||||||
@ -616,7 +616,7 @@ Detailed examples can be found in the [recurring downtimes](5-advanced-topics.md
|
|||||||
|
|
||||||
Next to the standard way of using [apply rules](3-monitoring-basics.md#using-apply)
|
Next to the standard way of using [apply rules](3-monitoring-basics.md#using-apply)
|
||||||
there is the requirement of applying objects based on a set (array or
|
there is the requirement of applying objects based on a set (array or
|
||||||
dictionary) using [apply for](20-language-reference.md#apply-for) expressions.
|
dictionary) using [apply for](18-language-reference.md#apply-for) expressions.
|
||||||
|
|
||||||
The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
|
The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
|
||||||
and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
|
and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
|
||||||
@ -732,10 +732,10 @@ After `vars` is fully populated, all object attributes can be set calculated fro
|
|||||||
provided host attributes. For strings, you can use string concatention with the `+` operator.
|
provided host attributes. For strings, you can use string concatention with the `+` operator.
|
||||||
|
|
||||||
You can also specifiy the display_name, check command, interval, notes, notes_url, action_url, etc.
|
You can also specifiy the display_name, check command, interval, notes, notes_url, action_url, etc.
|
||||||
attributes that way. Attribute strings can be [concatenated](20-language-reference.md#expression-operators),
|
attributes that way. Attribute strings can be [concatenated](18-language-reference.md#expression-operators),
|
||||||
for example for adding a more detailed service `display_name`.
|
for example for adding a more detailed service `display_name`.
|
||||||
|
|
||||||
This example also uses [if conditions](20-language-reference.md#conditional-statements)
|
This example also uses [if conditions](18-language-reference.md#conditional-statements)
|
||||||
if specific values are not set, adding a local default value.
|
if specific values are not set, adding a local default value.
|
||||||
The other way around you can override specific custom attributes inherited from a service template,
|
The other way around you can override specific custom attributes inherited from a service template,
|
||||||
if set.
|
if set.
|
||||||
@ -974,7 +974,7 @@ hosts or with the `test_server` attribute set to `true` are not added to this
|
|||||||
group.
|
group.
|
||||||
|
|
||||||
Details on the `assign where` syntax can be found in the
|
Details on the `assign where` syntax can be found in the
|
||||||
[Language Reference](20-language-reference.md#apply)
|
[Language Reference](18-language-reference.md#apply)
|
||||||
|
|
||||||
## <a id="notifications"></a> Notifications
|
## <a id="notifications"></a> Notifications
|
||||||
|
|
||||||
@ -1010,11 +1010,11 @@ The user `icingaadmin` in the example below will get notified only on `WARNING`
|
|||||||
If you don't set the `states` and `types` configuration attributes for the `User`
|
If you don't set the `states` and `types` configuration attributes for the `User`
|
||||||
object, notifications for all states and types will be sent.
|
object, notifications for all states and types will be sent.
|
||||||
|
|
||||||
Details on troubleshooting notification problems can be found [here](17-troubleshooting.md#troubleshooting).
|
Details on troubleshooting notification problems can be found [here](16-troubleshooting.md#troubleshooting).
|
||||||
|
|
||||||
> **Note**
|
> **Note**
|
||||||
>
|
>
|
||||||
> Make sure that the [notification](8-cli-commands.md#features) feature is enabled
|
> Make sure that the [notification](8-cli-commands.md#enable-features) feature is enabled
|
||||||
> in order to execute notification commands.
|
> in order to execute notification commands.
|
||||||
|
|
||||||
You should choose which information you (and your notified users) are interested in
|
You should choose which information you (and your notified users) are interested in
|
||||||
@ -1231,7 +1231,7 @@ using the `check_command` attribute.
|
|||||||
|
|
||||||
> **Note**
|
> **Note**
|
||||||
>
|
>
|
||||||
> Make sure that the [checker](8-cli-commands.md#features) feature is enabled in order to
|
> Make sure that the [checker](8-cli-commands.md#enable-features) feature is enabled in order to
|
||||||
> execute checks.
|
> execute checks.
|
||||||
|
|
||||||
#### <a id="command-plugin-integration"></a> Integrate the Plugin with a CheckCommand Definition
|
#### <a id="command-plugin-integration"></a> Integrate the Plugin with a CheckCommand Definition
|
||||||
@ -1524,7 +1524,7 @@ interfaces (E-Mail, XMPP, IRC, Twitter, etc).
|
|||||||
|
|
||||||
> **Note**
|
> **Note**
|
||||||
>
|
>
|
||||||
> Make sure that the [notification](8-cli-commands.md#features) feature is enabled
|
> Make sure that the [notification](8-cli-commands.md#enable-features) feature is enabled
|
||||||
> in order to execute notification commands.
|
> in order to execute notification commands.
|
||||||
|
|
||||||
Below is an example using runtime macros from Icinga 2 (such as `$service.output$` for
|
Below is an example using runtime macros from Icinga 2 (such as `$service.output$` for
|
||||||
@ -1774,7 +1774,7 @@ Rephrased: If the parent service object changes into the `Warning` state, this
|
|||||||
dependency will fail and render all child objects (hosts or services) unreachable.
|
dependency will fail and render all child objects (hosts or services) unreachable.
|
||||||
|
|
||||||
You can determine the child's reachability by querying the `is_reachable` attribute
|
You can determine the child's reachability by querying the `is_reachable` attribute
|
||||||
in for example [DB IDO](23-appendix.md#schema-db-ido-extensions).
|
in for example [DB IDO](22-appendix.md#schema-db-ido-extensions).
|
||||||
|
|
||||||
### <a id="dependencies-implicit-host-service"></a> Implicit Dependencies for Services on Host
|
### <a id="dependencies-implicit-host-service"></a> Implicit Dependencies for Services on Host
|
||||||
|
|
||||||
|
|||||||
@ -5,7 +5,7 @@ The configuration files which are automatically created when installing the Icin
|
|||||||
are a good way to start with Icinga 2.
|
are a good way to start with Icinga 2.
|
||||||
|
|
||||||
If you're interested in a detailed explanation of each language feature used in those
|
If you're interested in a detailed explanation of each language feature used in those
|
||||||
configuration files you can find more information in the [Language Reference](20-language-reference.md#language-reference)
|
configuration files you can find more information in the [Language Reference](18-language-reference.md#language-reference)
|
||||||
chapter.
|
chapter.
|
||||||
|
|
||||||
## <a id="configuration-best-practice"></a> Configuration Best Practice
|
## <a id="configuration-best-practice"></a> Configuration Best Practice
|
||||||
@ -79,7 +79,7 @@ Here's a brief description of the example configuration:
|
|||||||
* to the documentation that is distributed as part of Icinga 2.
|
* to the documentation that is distributed as part of Icinga 2.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
Icinga 2 supports [C/C++-style comments](20-language-reference.md#comments).
|
Icinga 2 supports [C/C++-style comments](18-language-reference.md#comments).
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* The constants.conf defines global constants.
|
* The constants.conf defines global constants.
|
||||||
@ -113,7 +113,7 @@ The `include` directive can be used to include other files.
|
|||||||
|
|
||||||
This `include` directive takes care of including the configuration files for all
|
This `include` directive takes care of including the configuration files for all
|
||||||
the features which have been enabled with `icinga2 feature enable`. See
|
the features which have been enabled with `icinga2 feature enable`. See
|
||||||
[Enabling/Disabling Features](8-cli-commands.md#features) for more details.
|
[Enabling/Disabling Features](8-cli-commands.md#enable-features) for more details.
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* The repository.d directory contains all configuration objects
|
* The repository.d directory contains all configuration objects
|
||||||
@ -295,13 +295,13 @@ host and your additional hosts are getting [services](4-configuring-icinga-2.md#
|
|||||||
|
|
||||||
> **Tip**
|
> **Tip**
|
||||||
>
|
>
|
||||||
> If you don't understand all the attributes and how to use [apply rules](20-language-reference.md#apply)
|
> If you don't understand all the attributes and how to use [apply rules](18-language-reference.md#apply)
|
||||||
> don't worry - the [monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter will explain
|
> don't worry - the [monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter will explain
|
||||||
> that in detail.
|
> that in detail.
|
||||||
|
|
||||||
#### <a id="services-conf"></a> services.conf
|
#### <a id="services-conf"></a> services.conf
|
||||||
|
|
||||||
These service [apply rules](20-language-reference.md#apply) will show you how to monitor
|
These service [apply rules](18-language-reference.md#apply) will show you how to monitor
|
||||||
the local host, but also allow you to re-use or modify them for
|
the local host, but also allow you to re-use or modify them for
|
||||||
your own requirements.
|
your own requirements.
|
||||||
|
|
||||||
@ -349,7 +349,7 @@ these services in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf).
|
|||||||
|
|
||||||
In this example the `assign where` condition is a boolean expression which is
|
In this example the `assign where` condition is a boolean expression which is
|
||||||
evaluated for all objects of type `Host` and a new service with name "load"
|
evaluated for all objects of type `Host` and a new service with name "load"
|
||||||
is created for each matching host. [Expression operators](20-language-reference.md#expression-operators)
|
is created for each matching host. [Expression operators](18-language-reference.md#expression-operators)
|
||||||
may be used in `assign where` conditions.
|
may be used in `assign where` conditions.
|
||||||
|
|
||||||
Multiple `assign where` condition can be combined with `AND` using the `&&` operator
|
Multiple `assign where` condition can be combined with `AND` using the `&&` operator
|
||||||
@ -367,7 +367,7 @@ In this example, the service `ssh` is applied to all hosts having the `address`
|
|||||||
attribute defined `AND` having the custom attribute `os` set to the string
|
attribute defined `AND` having the custom attribute `os` set to the string
|
||||||
`Linux`.
|
`Linux`.
|
||||||
You can modify this condition to match multiple expressions by combinding `AND`
|
You can modify this condition to match multiple expressions by combinding `AND`
|
||||||
and `OR` using `&&` and `||` [operators](20-language-reference.md#expression-operators), for example
|
and `OR` using `&&` and `||` [operators](18-language-reference.md#expression-operators), for example
|
||||||
`assign where host.address && (vars.os == "Linux" || vars.os == "Windows")`.
|
`assign where host.address && (vars.os == "Linux" || vars.os == "Windows")`.
|
||||||
|
|
||||||
|
|
||||||
@ -515,7 +515,7 @@ The example host defined in [hosts.conf](hosts-conf) already has the
|
|||||||
custom attribute `os` set to `Linux` and is therefore automatically
|
custom attribute `os` set to `Linux` and is therefore automatically
|
||||||
a member of the host group `linux-servers`.
|
a member of the host group `linux-servers`.
|
||||||
|
|
||||||
This is done by using the [group assign](20-language-reference.md#group-assign) expressions similar
|
This is done by using the [group assign](18-language-reference.md#group-assign) expressions similar
|
||||||
to previously seen [apply rules](3-monitoring-basics.md#using-apply).
|
to previously seen [apply rules](3-monitoring-basics.md#using-apply).
|
||||||
|
|
||||||
object HostGroup "linux-servers" {
|
object HostGroup "linux-servers" {
|
||||||
@ -531,7 +531,7 @@ to previously seen [apply rules](3-monitoring-basics.md#using-apply).
|
|||||||
}
|
}
|
||||||
|
|
||||||
Service groups can be grouped together by similar pattern matches.
|
Service groups can be grouped together by similar pattern matches.
|
||||||
The [match() function](20-language-reference.md#function-calls) expects a wildcard match string
|
The [match() function](18-language-reference.md#function-calls) expects a wildcard match string
|
||||||
and the attribute string to match with.
|
and the attribute string to match with.
|
||||||
|
|
||||||
object ServiceGroup "ping" {
|
object ServiceGroup "ping" {
|
||||||
|
|||||||
@ -53,7 +53,7 @@ is removed (may happen before or after the actual end time!).
|
|||||||
|
|
||||||
### <a id="scheduling-downtime"></a> Scheduling a downtime
|
### <a id="scheduling-downtime"></a> Scheduling a downtime
|
||||||
|
|
||||||
This can either happen through a web interface or by sending an [external command](5-advanced-topics.md#external-commands)
|
This can either happen through a web interface or by sending an [external command](15-features.md#external-commands)
|
||||||
to the external command pipe provided by the `ExternalCommandListener` configuration.
|
to the external command pipe provided by the `ExternalCommandListener` configuration.
|
||||||
|
|
||||||
Fixed downtimes require a start and end time (a duration will be ignored).
|
Fixed downtimes require a start and end time (a duration will be ignored).
|
||||||
@ -226,7 +226,7 @@ The other way around you can create objects dynamically using your own global fu
|
|||||||
|
|
||||||
Tips when implementing functions:
|
Tips when implementing functions:
|
||||||
|
|
||||||
* Use [log()](21-library-reference.md#global-functions) to dump variables. You can see the output
|
* Use [log()](19-library-reference.md#global-functions) to dump variables. You can see the output
|
||||||
inside the `icinga2.log` file depending in your log severity
|
inside the `icinga2.log` file depending in your log severity
|
||||||
* Use the `icinga2 console` to test basic functionality (e.g. iterating over a dictionary)
|
* Use the `icinga2 console` to test basic functionality (e.g. iterating over a dictionary)
|
||||||
* Build them step-by-step. You can always refactor your code later on.
|
* Build them step-by-step. You can always refactor your code later on.
|
||||||
@ -255,7 +255,7 @@ dictionary named `compellent` with the key `disks`. This was then used inside se
|
|||||||
The more significant problem was to only add the command parameter `--disk` to the plugin call
|
The more significant problem was to only add the command parameter `--disk` to the plugin call
|
||||||
when the dictionary `compellent` contains the key `disks`, and omit it if not found.
|
when the dictionary `compellent` contains the key `disks`, and omit it if not found.
|
||||||
|
|
||||||
By defining `set_if` as [abbreviated lambda function](20-language-reference.md#nullary-lambdas)
|
By defining `set_if` as [abbreviated lambda function](18-language-reference.md#nullary-lambdas)
|
||||||
and evaluating the host custom attribute `compellent` containing the `disks` this problem was
|
and evaluating the host custom attribute `compellent` containing the `disks` this problem was
|
||||||
solved like this:
|
solved like this:
|
||||||
|
|
||||||
@ -275,9 +275,9 @@ solved like this:
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
This implementation uses the dictionary type method [contains](21-library-reference.md#dictionary-contains)
|
This implementation uses the dictionary type method [contains](19-library-reference.md#dictionary-contains)
|
||||||
and will fail if `host.vars.compellent` is not of the type `Dictionary`.
|
and will fail if `host.vars.compellent` is not of the type `Dictionary`.
|
||||||
Therefore you can extend the checks using the [typeof](20-language-reference.md#types) function.
|
Therefore you can extend the checks using the [typeof](18-language-reference.md#types) function.
|
||||||
|
|
||||||
You can test the types using the `icinga2 console`:
|
You can test the types using the `icinga2 console`:
|
||||||
|
|
||||||
@ -370,7 +370,7 @@ You can omit the `log()` calls, they only help debugging.
|
|||||||
|
|
||||||
## <a id="access-object-attributes-at-runtime"></a> Access Object Attributes at Runtime
|
## <a id="access-object-attributes-at-runtime"></a> Access Object Attributes at Runtime
|
||||||
|
|
||||||
The [Object Accessor Functions](21-library-reference.md#object-accessor-functions)
|
The [Object Accessor Functions](19-library-reference.md#object-accessor-functions)
|
||||||
can be used to retrieve references to other objects by name.
|
can be used to retrieve references to other objects by name.
|
||||||
|
|
||||||
This allows you to access configuration and runtime object attributes. A detailed
|
This allows you to access configuration and runtime object attributes. A detailed
|
||||||
@ -509,485 +509,17 @@ state type if the service stays in a `NOT-OK` state. That way each
|
|||||||
service recheck will automatically trigger a notification unless the
|
service recheck will automatically trigger a notification unless the
|
||||||
service is acknowledged or in a scheduled downtime.
|
service is acknowledged or in a scheduled downtime.
|
||||||
|
|
||||||
|
## <a id="api"></a> Icinga 2 API
|
||||||
|
|
||||||
## <a id="external-commands"></a> External Commands
|
The Icinga 2 API allows you to manage configuration objects
|
||||||
|
and resources in a simple, programmatic way using HTTP requests.
|
||||||
|
|
||||||
Icinga 2 provides an external command pipe for processing commands
|
More details can be found in [this chapter](9-icinga2-api.md#icinga2-api).
|
||||||
triggering specific actions (for example rescheduling a service check
|
|
||||||
through the web interface).
|
|
||||||
|
|
||||||
In order to enable the `ExternalCommandListener` configuration use the
|
## <a id="features"></a> Icinga 2 Feature Configuration
|
||||||
following command and restart Icinga 2 afterwards:
|
|
||||||
|
|
||||||
# icinga2 feature enable command
|
Icinga 2 provides several features which can be enabled using [CLI commands](8-cli-commands.md#cli-command-feature).
|
||||||
|
|
||||||
Icinga 2 creates the command pipe file as `/var/run/icinga2/cmd/icinga2.cmd`
|
More details can be found in [this chapter](15-features.md#icinga2-features).
|
||||||
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 'ping4'
|
|
||||||
|
|
||||||
A list of currently supported external commands can be found [here](23-appendix.md#external-commands-list-detail).
|
|
||||||
|
|
||||||
Detailed information on the commands and their required parameters can be found
|
|
||||||
on the [Icinga 1.x documentation](http://docs.icinga.org/latest/en/extcommands2.html).
|
|
||||||
|
|
||||||
## <a id="logging"></a> Logging
|
|
||||||
|
|
||||||
Icinga 2 supports three different types of logging:
|
|
||||||
|
|
||||||
* File logging
|
|
||||||
* Syslog (on *NIX-based operating systems)
|
|
||||||
* Console logging (`STDOUT` on tty)
|
|
||||||
|
|
||||||
You can enable additional loggers using the `icinga2 feature enable`
|
|
||||||
and `icinga2 feature disable` commands to configure loggers:
|
|
||||||
|
|
||||||
Feature | Description
|
|
||||||
---------|------------
|
|
||||||
debuglog | Debug log (path: `/var/log/icinga2/debug.log`, severity: `debug` or higher)
|
|
||||||
mainlog | Main log (path: `/var/log/icinga2/icinga2.log`, severity: `information` or higher)
|
|
||||||
syslog | Syslog (severity: `warning` or higher)
|
|
||||||
|
|
||||||
By default file the `mainlog` feature is enabled. When running Icinga 2
|
|
||||||
on a terminal log messages with severity `information` or higher are
|
|
||||||
written to the console.
|
|
||||||
|
|
||||||
## <a id="performance-data"></a> Performance Data
|
|
||||||
|
|
||||||
When a host or service check is executed plugins should provide so-called
|
|
||||||
`performance data`. Next to that additional check performance data
|
|
||||||
can be fetched using Icinga 2 runtime macros such as the check latency
|
|
||||||
or the current service state (or additional custom attributes).
|
|
||||||
|
|
||||||
The performance data can be passed to external applications which aggregate and
|
|
||||||
store them in their backends. These tools usually generate graphs for historical
|
|
||||||
reporting and trending.
|
|
||||||
|
|
||||||
Well-known addons processing Icinga performance data are [PNP4Nagios](14-addons-plugins.md#addons-graphing-pnp),
|
|
||||||
[Graphite](14-addons-plugins.md#addons-graphing-graphite) or [OpenTSDB](5-advanced-topics.md#opentsdb-writer).
|
|
||||||
|
|
||||||
### <a id="writing-performance-data-files"></a> Writing Performance Data Files
|
|
||||||
|
|
||||||
PNP4Nagios and Graphios use performance data collector daemons to fetch
|
|
||||||
the current performance files for their backend updates.
|
|
||||||
|
|
||||||
Therefore the Icinga 2 [PerfdataWriter](6-object-types.md#objecttype-perfdatawriter)
|
|
||||||
feature allows you to define the output template format for host and services helped
|
|
||||||
with Icinga 2 runtime vars.
|
|
||||||
|
|
||||||
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$"
|
|
||||||
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$"
|
|
||||||
|
|
||||||
The default templates are already provided with the Icinga 2 feature configuration
|
|
||||||
which can be enabled using
|
|
||||||
|
|
||||||
# icinga2 feature enable perfdata
|
|
||||||
|
|
||||||
By default all performance data files are rotated in a 15 seconds interval into
|
|
||||||
the `/var/spool/icinga2/perfdata/` directory as `host-perfdata.<timestamp>` and
|
|
||||||
`service-perfdata.<timestamp>`.
|
|
||||||
External collectors need to parse the rotated performance data files and then
|
|
||||||
remove the processed files.
|
|
||||||
|
|
||||||
### <a id="graphite-carbon-cache-writer"></a> Graphite Carbon Cache Writer
|
|
||||||
|
|
||||||
While there are some [Graphite](14-addons-plugins.md#addons-graphing-graphite)
|
|
||||||
collector scripts and daemons like Graphios available for Icinga 1.x it's more
|
|
||||||
reasonable to directly process the check and plugin performance
|
|
||||||
in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
|
|
||||||
write them to the defined Graphite Carbon daemon tcp socket.
|
|
||||||
|
|
||||||
You can enable the feature using
|
|
||||||
|
|
||||||
# icinga2 feature enable graphite
|
|
||||||
|
|
||||||
By default the [GraphiteWriter](6-object-types.md#objecttype-graphitewriter) feature
|
|
||||||
expects the Graphite Carbon Cache to listen at `127.0.0.1` on TCP port `2003`.
|
|
||||||
|
|
||||||
#### <a id="graphite-carbon-cache-writer-schema"></a> Current Graphite Schema
|
|
||||||
|
|
||||||
The current naming schema is defined as follows. The official Icinga Web 2 Graphite
|
|
||||||
module will use that schema too.
|
|
||||||
|
|
||||||
The default prefix for hosts and services is configured using
|
|
||||||
[runtime macros](3-monitoring-basics.md#runtime-macros)like this:
|
|
||||||
|
|
||||||
icinga2.$host.name$.host.$host.check_command$
|
|
||||||
icinga2.$host.name$.services.$service.name$.$service.check_command$
|
|
||||||
|
|
||||||
You can customize the prefix name by using the `host_name_template` and
|
|
||||||
`service_name_template` configuration attributes.
|
|
||||||
|
|
||||||
The additional levels will allow fine granular filters and also template
|
|
||||||
capabilities, e.g. by using the check command `disk` for specific
|
|
||||||
graph templates in web applications rendering the Graphite data.
|
|
||||||
|
|
||||||
The following characters are escaped in prefix labels:
|
|
||||||
|
|
||||||
Character | Escaped character
|
|
||||||
--------------|--------------------------
|
|
||||||
whitespace | _
|
|
||||||
. | _
|
|
||||||
\ | _
|
|
||||||
/ | _
|
|
||||||
|
|
||||||
Metric values are stored like this:
|
|
||||||
|
|
||||||
<prefix>.perfdata.<perfdata-label>.value
|
|
||||||
|
|
||||||
The following characters are escaped in perfdata labels:
|
|
||||||
|
|
||||||
Character | Escaped character
|
|
||||||
--------------|--------------------------
|
|
||||||
whitespace | _
|
|
||||||
\ | _
|
|
||||||
/ | _
|
|
||||||
:: | .
|
|
||||||
|
|
||||||
Note that perfdata labels may contain dots (`.`) allowing to
|
|
||||||
add more subsequent levels inside the Graphite tree.
|
|
||||||
`::` adds support for [multi performance labels](http://my-plugin.de/wiki/projects/check_multi/configuration/performance)
|
|
||||||
and is therefore replaced by `.`.
|
|
||||||
|
|
||||||
By enabling `enable_send_thresholds` Icinga 2 automatically adds the following threshold metrics:
|
|
||||||
|
|
||||||
<prefix>.perfdata.<perfdata-label>.min
|
|
||||||
<prefix>.perfdata.<perfdata-label>.max
|
|
||||||
<prefix>.perfdata.<perfdata-label>.warn
|
|
||||||
<prefix>.perfdata.<perfdata-label>.crit
|
|
||||||
|
|
||||||
By enabling `enable_send_metadata` Icinga 2 automatically adds the following metadata metrics:
|
|
||||||
|
|
||||||
<prefix>.metadata.current_attempt
|
|
||||||
<prefix>.metadata.downtime_depth
|
|
||||||
<prefix>.metadata.execution_time
|
|
||||||
<prefix>.metadata.latency
|
|
||||||
<prefix>.metadata.max_check_attempts
|
|
||||||
<prefix>.metadata.reachable
|
|
||||||
<prefix>.metadata.state
|
|
||||||
<prefix>.metadata.state_type
|
|
||||||
|
|
||||||
Metadata metric overview:
|
|
||||||
|
|
||||||
metric | description
|
|
||||||
-------------------|------------------------------------------
|
|
||||||
current_attempt | current check attempt
|
|
||||||
max_check_attempts | maximum check attempts until the hard state is reached
|
|
||||||
reachable | checked object is reachable
|
|
||||||
downtime_depth | number of downtimes this object is in
|
|
||||||
execution_time | check execution time
|
|
||||||
latency | check latency
|
|
||||||
state | current state of the checked object
|
|
||||||
state_type | 0=SOFT, 1=HARD state
|
|
||||||
|
|
||||||
The following example illustrates how to configure the storage schemas for Graphite Carbon
|
|
||||||
Cache.
|
|
||||||
|
|
||||||
[icinga2_default]
|
|
||||||
# intervals like PNP4Nagios uses them per default
|
|
||||||
pattern = ^icinga2\.
|
|
||||||
retentions = 1m:2d,5m:10d,30m:90d,360m:4y
|
|
||||||
|
|
||||||
#### <a id="graphite-carbon-cache-writer-schema-legacy"></a> Graphite Schema < 2.4
|
|
||||||
|
|
||||||
In order to restore the old legacy schema, you'll need to adopt the `GraphiteWriter`
|
|
||||||
configuration:
|
|
||||||
|
|
||||||
object GraphiteWriter "graphite" {
|
|
||||||
|
|
||||||
enable_legacy_mode = true
|
|
||||||
|
|
||||||
host_name_template = "icinga.$host.name$"
|
|
||||||
service_name_template = "icinga.$host.name$.$service.name$"
|
|
||||||
}
|
|
||||||
|
|
||||||
The old legacy naming schema is
|
|
||||||
|
|
||||||
icinga.<hostname>.<metricname>
|
|
||||||
icinga.<hostname>.<servicename>.<metricname>
|
|
||||||
|
|
||||||
You can customize the metric prefix name by using the `host_name_template` and
|
|
||||||
`service_name_template` configuration attributes.
|
|
||||||
|
|
||||||
The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a
|
|
||||||
[global constant](20-language-reference.md#constants) named `GraphiteEnv`. The constant name
|
|
||||||
is freely definable and should be put in the [constants.conf](4-configuring-icinga-2.md#constants-conf) file.
|
|
||||||
|
|
||||||
const GraphiteEnv = "icinga.env1"
|
|
||||||
|
|
||||||
object GraphiteWriter "graphite" {
|
|
||||||
host_name_template = GraphiteEnv + ".$host.name$"
|
|
||||||
service_name_template = GraphiteEnv + ".$host.name$.$service.name$"
|
|
||||||
}
|
|
||||||
|
|
||||||
To make sure Icinga 2 writes a valid label into Graphite some characters are replaced
|
|
||||||
with `_` in the target name:
|
|
||||||
|
|
||||||
\/.- (and space)
|
|
||||||
|
|
||||||
The resulting name in Graphite might look like:
|
|
||||||
|
|
||||||
www-01 / http-cert / response time
|
|
||||||
icinga.www_01.http_cert.response_time
|
|
||||||
|
|
||||||
In addition to the performance data retrieved from the check plugin, Icinga 2 sends
|
|
||||||
internal check statistic data to Graphite:
|
|
||||||
|
|
||||||
metric | description
|
|
||||||
-------------------|------------------------------------------
|
|
||||||
current_attempt | current check attempt
|
|
||||||
max_check_attempts | maximum check attempts until the hard state is reached
|
|
||||||
reachable | checked object is reachable
|
|
||||||
downtime_depth | number of downtimes this object is in
|
|
||||||
execution_time | check execution time
|
|
||||||
latency | check latency
|
|
||||||
state | current state of the checked object
|
|
||||||
state_type | 0=SOFT, 1=HARD state
|
|
||||||
|
|
||||||
The following example illustrates how to configure the storage-schemas for Graphite Carbon
|
|
||||||
Cache. Please make sure that the order is correct because the first match wins.
|
|
||||||
|
|
||||||
[icinga_internals]
|
|
||||||
pattern = ^icinga\..*\.(max_check_attempts|reachable|current_attempt|execution_time|latency|state|state_type)
|
|
||||||
retentions = 5m:7d
|
|
||||||
|
|
||||||
[icinga_default]
|
|
||||||
# intervals like PNP4Nagios uses them per default
|
|
||||||
pattern = ^icinga\.
|
|
||||||
retentions = 1m:2d,5m:10d,30m:90d,360m:4y
|
|
||||||
|
|
||||||
### <a id="gelfwriter"></a> GELF Writer
|
|
||||||
|
|
||||||
The `Graylog Extended Log Format` (short: [GELF](http://www.graylog2.org/resources/gelf))
|
|
||||||
can be used to send application logs directly to a TCP socket.
|
|
||||||
|
|
||||||
While it has been specified by the [graylog2](http://www.graylog2.org/) project as their
|
|
||||||
[input resource standard](http://www.graylog2.org/resources/gelf), other tools such as
|
|
||||||
[Logstash](http://www.logstash.net) also support `GELF` as
|
|
||||||
[input type](http://logstash.net/docs/latest/inputs/gelf).
|
|
||||||
|
|
||||||
You can enable the feature using
|
|
||||||
|
|
||||||
# icinga2 feature enable gelf
|
|
||||||
|
|
||||||
By default the `GelfWriter` object expects the GELF receiver to listen at `127.0.0.1` on TCP port `12201`.
|
|
||||||
The default `source` attribute is set to `icinga2`. You can customize that for your needs if required.
|
|
||||||
|
|
||||||
Currently these events are processed:
|
|
||||||
* Check results
|
|
||||||
* State changes
|
|
||||||
* Notifications
|
|
||||||
|
|
||||||
### <a id="opentsdb-writer"></a> OpenTSDB Writer
|
|
||||||
|
|
||||||
While there are some OpenTSDB collector scripts and daemons like tcollector available for
|
|
||||||
Icinga 1.x it's more reasonable to directly process the check and plugin performance
|
|
||||||
in memory in Icinga 2. Once there are new metrics available, Icinga 2 will directly
|
|
||||||
write them to the defined TSDB TCP socket.
|
|
||||||
|
|
||||||
You can enable the feature using
|
|
||||||
|
|
||||||
# icinga2 feature enable opentsdb
|
|
||||||
|
|
||||||
By default the `OpenTsdbWriter` object expects the TSD to listen at
|
|
||||||
`127.0.0.1` on port `4242`.
|
|
||||||
|
|
||||||
The current naming schema is
|
|
||||||
|
|
||||||
icinga.host.<metricname>
|
|
||||||
icinga.service.<servicename>.<metricname>
|
|
||||||
|
|
||||||
for host and service checks. The tag host is always applied.
|
|
||||||
|
|
||||||
To make sure Icinga 2 writes a valid metric into OpenTSDB some characters are replaced
|
|
||||||
with `_` in the target name:
|
|
||||||
|
|
||||||
\ (and space)
|
|
||||||
|
|
||||||
The resulting name in OpenTSDB might look like:
|
|
||||||
|
|
||||||
www-01 / http-cert / response time
|
|
||||||
icinga.http_cert.response_time
|
|
||||||
|
|
||||||
In addition to the performance data retrieved from the check plugin, Icinga 2 sends
|
|
||||||
internal check statistic data to OpenTSDB:
|
|
||||||
|
|
||||||
metric | description
|
|
||||||
-------------------|------------------------------------------
|
|
||||||
current_attempt | current check attempt
|
|
||||||
max_check_attempts | maximum check attempts until the hard state is reached
|
|
||||||
reachable | checked object is reachable
|
|
||||||
downtime_depth | number of downtimes this object is in
|
|
||||||
execution_time | check execution time
|
|
||||||
latency | check latency
|
|
||||||
state | current state of the checked object
|
|
||||||
state_type | 0=SOFT, 1=HARD state
|
|
||||||
|
|
||||||
While reachable, state and state_type are metrics for the host or service the
|
|
||||||
other metrics follow the current naming schema
|
|
||||||
|
|
||||||
icinga.check.<metricname>
|
|
||||||
|
|
||||||
with the following tags
|
|
||||||
|
|
||||||
tag | description
|
|
||||||
--------|------------------------------------------
|
|
||||||
type | the check type, one of [host, service]
|
|
||||||
host | hostname, the check ran on
|
|
||||||
service | the service name (if type=service)
|
|
||||||
|
|
||||||
> **Note**
|
|
||||||
>
|
|
||||||
> You might want to set the tsd.core.auto_create_metrics setting to `true`
|
|
||||||
> in your opentsdb.conf configuration file.
|
|
||||||
|
|
||||||
|
|
||||||
## <a id="status-data"></a> Status Data
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
Icinga 1.x Classic UI requires this data set as part of its backend.
|
|
||||||
|
|
||||||
> **Note**
|
|
||||||
>
|
|
||||||
> If you are not using any web interface or addon which uses these files
|
|
||||||
> you can safely disable this feature.
|
|
||||||
|
|
||||||
|
|
||||||
## <a id="compat-logging"></a> Compat Logging
|
|
||||||
|
|
||||||
The Icinga 1.x log format is considered being the `Compat Log`
|
|
||||||
in Icinga 2 provided with the `CompatLogger` object.
|
|
||||||
|
|
||||||
These logs are not only used for informational representation in
|
|
||||||
external web interfaces parsing the logs, but also to generate
|
|
||||||
SLA reports and trends in Icinga 1.x Classic UI. Furthermore the
|
|
||||||
[Livestatus](16-livestatus.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`.
|
|
||||||
|
|
||||||
The format cannot be changed without breaking compatibility to
|
|
||||||
existing log parsers.
|
|
||||||
|
|
||||||
# tail -f /var/log/icinga2/compat/icinga.log
|
|
||||||
|
|
||||||
[1382115688] LOG ROTATION: HOURLY
|
|
||||||
[1382115688] LOG VERSION: 2.0
|
|
||||||
[1382115688] HOST STATE: CURRENT;localhost;UP;HARD;1;
|
|
||||||
[1382115688] SERVICE STATE: CURRENT;localhost;disk;WARNING;HARD;1;
|
|
||||||
[1382115688] SERVICE STATE: CURRENT;localhost;http;OK;HARD;1;
|
|
||||||
[1382115688] SERVICE STATE: CURRENT;localhost;load;OK;HARD;1;
|
|
||||||
[1382115688] SERVICE STATE: CURRENT;localhost;ping4;OK;HARD;1;
|
|
||||||
[1382115688] SERVICE STATE: CURRENT;localhost;ping6;OK;HARD;1;
|
|
||||||
[1382115688] SERVICE STATE: CURRENT;localhost;processes;WARNING;HARD;1;
|
|
||||||
[1382115688] SERVICE STATE: CURRENT;localhost;ssh;OK;HARD;1;
|
|
||||||
[1382115688] SERVICE STATE: CURRENT;localhost;users;OK;HARD;1;
|
|
||||||
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;disk;1382115705
|
|
||||||
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;http;1382115705
|
|
||||||
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;load;1382115705
|
|
||||||
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping4;1382115705
|
|
||||||
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ping6;1382115705
|
|
||||||
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;processes;1382115705
|
|
||||||
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;ssh;1382115705
|
|
||||||
[1382115706] EXTERNAL COMMAND: SCHEDULE_FORCED_SVC_CHECK;localhost;users;1382115705
|
|
||||||
[1382115731] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;localhost;ping6;2;critical test|
|
|
||||||
[1382115731] SERVICE ALERT: localhost;ping6;CRITICAL;SOFT;2;critical test
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## <a id="db-ido"></a> DB IDO
|
|
||||||
|
|
||||||
The IDO (Icinga Data Output) modules for Icinga 2 take care of exporting all
|
|
||||||
configuration and status information into a database. The IDO database is used
|
|
||||||
by a number of projects including Icinga Web 1.x and 2.
|
|
||||||
|
|
||||||
Details on the installation can be found in the [Configuring DB IDO](2-getting-started.md#configuring-db-ido-mysql)
|
|
||||||
chapter. Details on the configuration can be found in the
|
|
||||||
[IdoMysqlConnection](6-object-types.md#objecttype-idomysqlconnection) and
|
|
||||||
[IdoPgsqlConnection](6-object-types.md#objecttype-idopgsqlconnection)
|
|
||||||
object configuration documentation.
|
|
||||||
The DB IDO feature supports [High Availability](13-distributed-monitoring-ha.md#high-availability-db-ido) in
|
|
||||||
the Icinga 2 cluster.
|
|
||||||
|
|
||||||
The following example query checks the health of the current Icinga 2 instance
|
|
||||||
writing its current status to the DB IDO backend table `icinga_programstatus`
|
|
||||||
every 10 seconds. By default it checks 60 seconds into the past which is a reasonable
|
|
||||||
amount of time - adjust it for your requirements. If the condition is not met,
|
|
||||||
the query returns an empty result.
|
|
||||||
|
|
||||||
> **Tip**
|
|
||||||
>
|
|
||||||
> Use [check plugins](14-addons-plugins.md#plugins) to monitor the backend.
|
|
||||||
|
|
||||||
Replace the `default` string with your instance name, if different.
|
|
||||||
|
|
||||||
Example for MySQL:
|
|
||||||
|
|
||||||
# mysql -u root -p icinga -e "SELECT status_update_time FROM icinga_programstatus ps
|
|
||||||
JOIN icinga_instances i ON ps.instance_id=i.instance_id
|
|
||||||
WHERE (UNIX_TIMESTAMP(ps.status_update_time) > UNIX_TIMESTAMP(NOW())-60)
|
|
||||||
AND i.instance_name='default';"
|
|
||||||
|
|
||||||
+---------------------+
|
|
||||||
| status_update_time |
|
|
||||||
+---------------------+
|
|
||||||
| 2014-05-29 14:29:56 |
|
|
||||||
+---------------------+
|
|
||||||
|
|
||||||
|
|
||||||
Example for PostgreSQL:
|
|
||||||
|
|
||||||
# export PGPASSWORD=icinga; psql -U icinga -d icinga -c "SELECT ps.status_update_time FROM icinga_programstatus AS ps
|
|
||||||
JOIN icinga_instances AS i ON ps.instance_id=i.instance_id
|
|
||||||
WHERE ((SELECT extract(epoch from status_update_time) FROM icinga_programstatus) > (SELECT extract(epoch from now())-60))
|
|
||||||
AND i.instance_name='default'";
|
|
||||||
|
|
||||||
status_update_time
|
|
||||||
------------------------
|
|
||||||
2014-05-29 15:11:38+02
|
|
||||||
(1 Zeile)
|
|
||||||
|
|
||||||
|
|
||||||
A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](23-appendix.md#schema-db-ido).
|
|
||||||
|
|
||||||
|
|
||||||
## <a id="check-result-files"></a> Check Result Files
|
|
||||||
|
|
||||||
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"
|
|
||||||
}
|
|
||||||
|
|||||||
@ -457,7 +457,7 @@ Configuration Attributes:
|
|||||||
enable_send_metadata | **Optional.** Send additional metadata metrics. Defaults to `false`.
|
enable_send_metadata | **Optional.** Send additional metadata metrics. Defaults to `false`.
|
||||||
enable_legacy_mode | **Optional.** Enable legacy mode for schema < 2.4. **Note**: This will be removed in future versions.
|
enable_legacy_mode | **Optional.** Enable legacy mode for schema < 2.4. **Note**: This will be removed in future versions.
|
||||||
|
|
||||||
Additional usage examples can be found [here](5-advanced-topics.md#graphite-carbon-cache-writer).
|
Additional usage examples can be found [here](15-features.md#graphite-carbon-cache-writer).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -542,7 +542,7 @@ A group of hosts.
|
|||||||
|
|
||||||
> **Best Practice**
|
> **Best Practice**
|
||||||
>
|
>
|
||||||
> Assign host group members using the [group assign](20-language-reference.md#group-assign) rules.
|
> Assign host group members using the [group assign](18-language-reference.md#group-assign) rules.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
@ -1155,7 +1155,7 @@ A group of services.
|
|||||||
|
|
||||||
> **Best Practice**
|
> **Best Practice**
|
||||||
>
|
>
|
||||||
> Assign service group members using the [group assign](20-language-reference.md#group-assign) rules.
|
> Assign service group members using the [group assign](18-language-reference.md#group-assign) rules.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
@ -1342,7 +1342,7 @@ A user group.
|
|||||||
|
|
||||||
> **Best Practice**
|
> **Best Practice**
|
||||||
>
|
>
|
||||||
> Assign user group members using the [group assign](20-language-reference.md#group-assign) rules.
|
> Assign user group members using the [group assign](18-language-reference.md#group-assign) rules.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
@ -112,12 +112,12 @@ can be specified with the `--app` command-line option.
|
|||||||
|
|
||||||
### Libraries
|
### Libraries
|
||||||
|
|
||||||
Instead of loading libraries using the [`library` config directive](20-language-reference.md#library)
|
Instead of loading libraries using the [`library` config directive](18-language-reference.md#library)
|
||||||
you can also use the `--library` command-line option.
|
you can also use the `--library` command-line option.
|
||||||
|
|
||||||
### Constants
|
### Constants
|
||||||
|
|
||||||
[Global constants](20-language-reference.md#constants) can be set using the `--define` command-line option.
|
[Global constants](18-language-reference.md#constants) can be set using the `--define` command-line option.
|
||||||
|
|
||||||
### <a id="config-include-path"></a> Config Include Path
|
### <a id="config-include-path"></a> Config Include Path
|
||||||
|
|
||||||
@ -273,9 +273,9 @@ nodes in a [remote monitoring ](11-icinga2-client.md#icinga2-client) or
|
|||||||
|
|
||||||
The `object` CLI command can be used to list all configuration objects and their
|
The `object` CLI command can be used to list all configuration objects and their
|
||||||
attributes. The command also shows where each of the attributes was modified.
|
attributes. The command also shows where each of the attributes was modified.
|
||||||
That way you can also identify which objects have been created from your [apply rules](20-language-reference.md#apply).
|
That way you can also identify which objects have been created from your [apply rules](18-language-reference.md#apply).
|
||||||
|
|
||||||
More information can be found in the [troubleshooting](17-troubleshooting.md#list-configuration-objects) section.
|
More information can be found in the [troubleshooting](16-troubleshooting.md#list-configuration-objects) section.
|
||||||
|
|
||||||
# icinga2 object --help
|
# icinga2 object --help
|
||||||
icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
|
icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
|
||||||
@ -406,7 +406,7 @@ cleared after review.
|
|||||||
|
|
||||||
## <a id="cli-command-troubleshoot"></a> CLI command: Troubleshoot
|
## <a id="cli-command-troubleshoot"></a> CLI command: Troubleshoot
|
||||||
|
|
||||||
Collects basic information like version, paths, log files and crash reports for troubleshooting purposes and prints them to a file or the console. See [troubleshooting](17-troubleshooting.md#troubleshooting-information-required).
|
Collects basic information like version, paths, log files and crash reports for troubleshooting purposes and prints them to a file or the console. See [troubleshooting](16-troubleshooting.md#troubleshooting-information-required).
|
||||||
|
|
||||||
Its output defaults to a file named `troubleshooting-[TIMESTAMP].log` so it won't overwrite older troubleshooting files.
|
Its output defaults to a file named `troubleshooting-[TIMESTAMP].log` so it won't overwrite older troubleshooting files.
|
||||||
|
|
||||||
@ -472,7 +472,7 @@ Lists all configured variables (constants) in a similar fasion like [object list
|
|||||||
Icinga home page: <https://www.icinga.org/>
|
Icinga home page: <https://www.icinga.org/>
|
||||||
|
|
||||||
|
|
||||||
## <a id="features"></a> Enabling/Disabling Features
|
## <a id="enable-features"></a> Enabling/Disabling Features
|
||||||
|
|
||||||
Icinga 2 provides configuration files for some commonly used features. These
|
Icinga 2 provides configuration files for some commonly used features. These
|
||||||
are installed in the `/etc/icinga2/features-available` directory and can be
|
are installed in the `/etc/icinga2/features-available` directory and can be
|
||||||
@ -555,12 +555,12 @@ Or manually passing the `-C` argument:
|
|||||||
> `# icinga2 daemon -C`
|
> `# icinga2 daemon -C`
|
||||||
|
|
||||||
If you encouter errors during configuration validation, please make sure
|
If you encouter errors during configuration validation, please make sure
|
||||||
to read the [troubleshooting](17-troubleshooting.md#troubleshooting) chapter.
|
to read the [troubleshooting](16-troubleshooting.md#troubleshooting) chapter.
|
||||||
|
|
||||||
You can also use the [CLI command](8-cli-commands.md#cli-command-object) `icinga2 object list`
|
You can also use the [CLI command](8-cli-commands.md#cli-command-object) `icinga2 object list`
|
||||||
after validation passes to analyze object attributes, inheritance or created
|
after validation passes to analyze object attributes, inheritance or created
|
||||||
objects by apply rules.
|
objects by apply rules.
|
||||||
Find more on troubleshooting with `object list` in [this chapter](17-troubleshooting.md#list-configuration-objects).
|
Find more on troubleshooting with `object list` in [this chapter](16-troubleshooting.md#list-configuration-objects).
|
||||||
|
|
||||||
Example filtered by `Service` objects with the name `ping*`:
|
Example filtered by `Service` objects with the name `ping*`:
|
||||||
|
|
||||||
@ -604,5 +604,5 @@ safely reload the Icinga 2 daemon.
|
|||||||
> which will validate the configuration in a separate process and not stop
|
> which will validate the configuration in a separate process and not stop
|
||||||
> the other events like check execution, notifications, etc.
|
> the other events like check execution, notifications, etc.
|
||||||
>
|
>
|
||||||
> Details can be found [here](19-migrating-from-icinga-1x.md#differences-1x-2-real-reload).
|
> Details can be found [here](21-migrating-from-icinga-1x.md#differences-1x-2-real-reload).
|
||||||
|
|
||||||
|
|||||||
@ -72,7 +72,7 @@ Succesful requests will send back a response body containing a `results`
|
|||||||
list. Depending on the number of affected objects in your request, the
|
list. Depending on the number of affected objects in your request, the
|
||||||
results may contain one or more entries.
|
results may contain one or more entries.
|
||||||
|
|
||||||
The [output](9-icinga2-api.md#icinga2-api-output-format) will be sent back as a JSON object:
|
The output will be sent back as a JSON object:
|
||||||
|
|
||||||
|
|
||||||
{
|
{
|
||||||
@ -147,7 +147,7 @@ Example for an API user with all permissions:
|
|||||||
permissions = [ "*" ]
|
permissions = [ "*" ]
|
||||||
|
|
||||||
A yet more sophisticated approach is to specify additional permissions
|
A yet more sophisticated approach is to specify additional permissions
|
||||||
and their filters. The latter must be defined as [lamdba function](20-language-reference.md#nullary-lambdas)
|
and their filters. The latter must be defined as [lamdba function](18-language-reference.md#nullary-lambdas)
|
||||||
returning a boolean expression.
|
returning a boolean expression.
|
||||||
|
|
||||||
The `permission` attribute contains the action and the specific capitalized
|
The `permission` attribute contains the action and the specific capitalized
|
||||||
@ -238,7 +238,7 @@ Please check the respective sections for detailed URL information and parameters
|
|||||||
There are several actions available for Icinga 2 provided by the `actions`
|
There are several actions available for Icinga 2 provided by the `actions`
|
||||||
URL endpoint `/v1/actions`. You can run actions by sending a `POST` request.
|
URL endpoint `/v1/actions`. You can run actions by sending a `POST` request.
|
||||||
|
|
||||||
In case you have been using the [external commands](5-advanced-topics.md#external-commands)
|
In case you have been using the [external commands](15-features.md#external-commands)
|
||||||
in the past, the API actions provide a similar interface with filter
|
in the past, the API actions provide a similar interface with filter
|
||||||
capabilities for some of the more common targets which do not directly change
|
capabilities for some of the more common targets which do not directly change
|
||||||
the configuration.
|
the configuration.
|
||||||
@ -260,7 +260,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/process-check-result`.
|
|||||||
Parameter | Type | Description
|
Parameter | Type | Description
|
||||||
------------------|--------------|--------------
|
------------------|--------------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
exit\_status | integer | **Required.** For services: 0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN, for hosts: 0=OK, 1=CRITICAL.
|
exit\_status | integer | **Required.** For services: 0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN, for hosts: 0=OK, 1=CRITICAL.
|
||||||
plugin\_output | string | **Required.** The plugins main output, i.e. the text before the `|`. Does **not** contain the perfomance data.
|
plugin\_output | string | **Required.** The plugins main output, i.e. the text before the `|`. Does **not** contain the perfomance data.
|
||||||
performance\_data | string array | **Optional.** One array entry per `;` separated block.
|
performance\_data | string array | **Optional.** One array entry per `;` separated block.
|
||||||
@ -290,7 +290,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/reschedule-check`.
|
|||||||
Parameter | Type | Description
|
Parameter | Type | Description
|
||||||
-------------|-----------|--------------
|
-------------|-----------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
next\_check | timestamp | **Optional.** The next check will be run at this timestamp. Defaults to `now`.
|
next\_check | timestamp | **Optional.** The next check will be run at this timestamp. Defaults to `now`.
|
||||||
force\_check | boolean | **Optional.** Defaults to `false`. See blow for further information.
|
force\_check | boolean | **Optional.** Defaults to `false`. See blow for further information.
|
||||||
|
|
||||||
@ -322,7 +322,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/send-custom-notification`
|
|||||||
Parameter | Type | Description
|
Parameter | Type | Description
|
||||||
----------|---------|--------------
|
----------|---------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
author | string | **Required.** Name of the author, may be empty.
|
author | string | **Required.** Name of the author, may be empty.
|
||||||
comment | string | **Required.** Comment text, may be empty.
|
comment | string | **Required.** Comment text, may be empty.
|
||||||
force | boolean | **Optional.** Default: false. If true, the notification is sent regardless of downtimes or whether notifications are enabled or not.
|
force | boolean | **Optional.** Default: false. If true, the notification is sent regardless of downtimes or whether notifications are enabled or not.
|
||||||
@ -334,7 +334,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/delay-notification`.
|
|||||||
Parameter | Type | Description
|
Parameter | Type | Description
|
||||||
----------|-----------|--------------
|
----------|-----------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
timestamp | timestamp | **Required.** Delay notifications until this timestamp.
|
timestamp | timestamp | **Required.** Delay notifications until this timestamp.
|
||||||
|
|
||||||
Note that this will only have an effect if the service stays in the same problem
|
Note that this will only have an effect if the service stays in the same problem
|
||||||
@ -348,7 +348,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/acknowledge-problem`.
|
|||||||
Parameter | Type | Description
|
Parameter | Type | Description
|
||||||
----------|-----------|--------------
|
----------|-----------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
author | string | **Required.** Name of the author, may be empty.
|
author | string | **Required.** Name of the author, may be empty.
|
||||||
comment | string | **Required.** Comment text, may be empty.
|
comment | string | **Required.** Comment text, may be empty.
|
||||||
expiry | timestamp | **Optional.** If set the acknowledgement will vanish after this timestamp.
|
expiry | timestamp | **Optional.** If set the acknowledgement will vanish after this timestamp.
|
||||||
@ -379,7 +379,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/remove-acknowledgement`.
|
|||||||
parameter | type | description
|
parameter | type | description
|
||||||
----------|--------|--------------
|
----------|--------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
|
|
||||||
Remove the acknowledgements for services or hosts. Once the acknowledgement has
|
Remove the acknowledgements for services or hosts. Once the acknowledgement has
|
||||||
been removed notifications will be sent out again.
|
been removed notifications will be sent out again.
|
||||||
@ -391,7 +391,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/add-comment`.
|
|||||||
parameter | type | description
|
parameter | type | description
|
||||||
----------|--------|--------------
|
----------|--------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
author | string | **Required.** name of the author, may be empty.
|
author | string | **Required.** name of the author, may be empty.
|
||||||
comment | string | **Required.** Comment text, may be empty.
|
comment | string | **Required.** Comment text, may be empty.
|
||||||
|
|
||||||
@ -404,7 +404,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/remove-all-comments`.
|
|||||||
parameter | type | description
|
parameter | type | description
|
||||||
------------|---------|--------------
|
------------|---------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
|
|
||||||
Removes all comments for services or hosts.
|
Removes all comments for services or hosts.
|
||||||
|
|
||||||
@ -429,12 +429,12 @@ Send a `POST` request to the URL endpoint `/v1/actions/schedule-downtime`.
|
|||||||
parameter | type | description
|
parameter | type | description
|
||||||
------------|-----------|--------------
|
------------|-----------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
start\_time | timestamp | **Required.** Timestamp marking the begining of the downtime.
|
start\_time | timestamp | **Required.** Timestamp marking the begining of the downtime.
|
||||||
end\_time | timestamp | **Required.** Timestamp marking the end of the downtime.
|
end\_time | timestamp | **Required.** Timestamp marking the end of the downtime.
|
||||||
duration | integer | **Required.** Duration of the downtime in seconds if `fixed` is set to false.
|
duration | integer | **Required.** Duration of the downtime in seconds if `fixed` is set to false.
|
||||||
fixed | boolean | **Optional.** Defaults to `false`. If true the downtime is `fixed` otherwise `flexible`. See [downtimes](5-advanced-topics.md#Downtimes) for more information.
|
fixed | boolean | **Optional.** Defaults to `false`. If true the downtime is `fixed` otherwise `flexible`. See [downtimes](#Downtimes) for more information.
|
||||||
trigger\_id | integer | **Optional.** Sets the trigger for a triggered downtime. See [downtimes](5-advanced-topics.md#Downtimes) for more information on triggered downtimes.
|
trigger\_id | integer | **Optional.** Sets the trigger for a triggered downtime. See [downtimes](#Downtimes) for more information on triggered downtimes.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
@ -460,7 +460,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/remove-all-downtimes`.
|
|||||||
parameter | type | description
|
parameter | type | description
|
||||||
----------|--------|--------------
|
----------|--------|--------------
|
||||||
type | string | **Required.** `Host` or `Service`.
|
type | string | **Required.** `Host` or `Service`.
|
||||||
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api#icinga2-api-filters).
|
filter | string | **Optional.** Apply the action only to objects matching the [filter](9-icinga2-api.md#icinga2-api-filters).
|
||||||
|
|
||||||
Removes all downtimes for services or hosts.
|
Removes all downtimes for services or hosts.
|
||||||
|
|
||||||
|
|||||||
17
mkdocs.yml
17
mkdocs.yml
@ -16,15 +16,14 @@ pages:
|
|||||||
- [12-agent-based-checks.md, Additional Agent-based Checks]
|
- [12-agent-based-checks.md, Additional Agent-based Checks]
|
||||||
- [13-distributed-monitoring-ha.md, Distributed Monitoring and High Availability]
|
- [13-distributed-monitoring-ha.md, Distributed Monitoring and High Availability]
|
||||||
- [14-addons-plugins.md, Addons and Plugins]
|
- [14-addons-plugins.md, Addons and Plugins]
|
||||||
- [15-alternative-frontends.md, Alternative Frontends]
|
- [15-features.md, Features]
|
||||||
- [16-livestatus.md, Livestatus]
|
- [16-troubleshooting.md, Troubleshooting]
|
||||||
- [17-troubleshooting.md, Troubleshooting]
|
- [17-upgrading-icinga-2.md, Upgrading Icinga 2]
|
||||||
- [18-upgrading-icinga-2.md, Upgrading Icinga 2]
|
- [18-language-reference.md, Language Reference]
|
||||||
- [19-migrating-from-icinga-1x.md, Migrating from Icinga 1.x]
|
- [19-library-reference.md, Library Reference]
|
||||||
- [20-language-reference.md, Language Reference]
|
- [20-debug.md, Debug]
|
||||||
- [21-library-reference.md, Library Reference]
|
- [21-migrating-from-icinga-1x.md, Migrating from Icinga 1.x]
|
||||||
- [22-debug.md, Debug]
|
- [22-appendix.md, Appendix]
|
||||||
- [23-appendix.md, Appendix]
|
|
||||||
theme: readthedocs
|
theme: readthedocs
|
||||||
markdown_extensions: [smarty]
|
markdown_extensions: [smarty]
|
||||||
extra_javascript: [scroll.js]
|
extra_javascript: [scroll.js]
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user