mirror of https://github.com/Icinga/icinga2.git
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.
|
||||
* 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
|
||||
|
||||
|
|
@ -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
|
||||
* 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
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Keep the [naming convention](13-distributed-monitoring-ha.md#cluster-naming-conv
|
|||
> **Tip**
|
||||
>
|
||||
> 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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
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.
|
||||
|
||||
### <a id="simple-traps"></a> Simple SNMP Traps
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ Decide whether to use the built-in [configuration syncronization](13-distributed
|
|||
> **Tip**
|
||||
>
|
||||
> 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
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
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 **
|
||||
>
|
||||
|
|
@ -346,7 +346,7 @@ process.
|
|||
>
|
||||
> `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
|
||||
> [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
|
||||
|
||||
|
|
@ -406,7 +406,7 @@ master instances anymore.
|
|||
|
||||
> ** 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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
[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.
|
||||
|
||||
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)
|
||||
* 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.
|
||||
|
||||
# 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.
|
||||
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)
|
||||
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
|
||||
|
||||
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).
|
||||
|
||||
### <a id="addons-visualization-nagvis"></a> NagVis
|
||||
|
||||
By using either [Livestatus](16-livestatus.md#setting-up-livestatus) or
|
||||
[DB IDO](5-advanced-topics.md#db-ido) as a backend you can create your own network maps
|
||||
By using either [Livestatus](15-features.md#setting-up-livestatus) or
|
||||
[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).
|
||||
|
||||
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
|
||||
|
||||
[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
|
||||
|
||||
|
|
@ -270,7 +270,7 @@ This behavior changed in Icinga 2 compared to Icinga 1.x. Though there are certa
|
|||
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`)
|
||||
* 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
|
||||
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).
|
||||
|
||||
|
|
@ -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
|
||||
* Provide complete configuration snippets explaining your problem in detail
|
||||
* 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
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ and `debug`.
|
|||
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.
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ or similar.
|
|||
* Check the debug log to see if the check command gets executed
|
||||
* 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 the [checker](8-cli-commands.md#features) feature is enabled.
|
||||
* Make sure the [checker](8-cli-commands.md#enable-features) feature is enabled.
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ Verify the following configuration
|
|||
* Do the notification 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?
|
||||
* 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?
|
||||
|
||||
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
|
||||
|
||||
* 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 `/* ... */`).
|
||||
* 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
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
|
|
@ -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).
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -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,
|
||||
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.
|
||||
|
||||
### <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.
|
||||
* 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.
|
||||
* 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
|
||||
|
||||
|
|
@ -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
|
||||
> 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.
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -357,6 +357,6 @@ will store all events for not connected endpoints in the same and child zones.
|
|||
Check the following:
|
||||
|
||||
* 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?
|
||||
* 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
|
||||
}
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -388,7 +388,7 @@ another group of objects.
|
|||
|
||||
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"
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
[Apply](20-language-reference.md#apply) rules can be extended with the
|
||||
[for loop](20-language-reference.md#for-loops) keyword.
|
||||
[Apply](18-language-reference.md#apply) rules can be extended with the
|
||||
[for loop](18-language-reference.md#for-loops) keyword.
|
||||
|
||||
apply Service "prefix-" for (key => value in host.vars.dictionary) to Host {
|
||||
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
|
||||
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`
|
||||
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.
|
||||
|
||||
Source Type | Variables
|
||||
|
|
@ -490,7 +490,7 @@ Empty dictionary | {} | false
|
|||
Non-empty dictionary | { key = "value" } | true
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -857,7 +857,7 @@ supports:
|
|||
keys(String.prototype)
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -413,7 +413,7 @@ Signature:
|
|||
function contains(str);
|
||||
|
||||
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.
|
||||
|
||||
Example:
|
||||
|
|
@ -522,7 +522,7 @@ object is recursively copied.
|
|||
|
||||
## <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
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -312,10 +312,7 @@ Test it:
|
|||
## <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.
|
||||
This chapter explains how to set up Icinga Web 2. The
|
||||
[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.
|
||||
This chapter explains how to set up Icinga Web 2.
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ object specific policies.
|
|||
For a long-term migration of your configuration you should consider re-creating
|
||||
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.
|
||||
|
||||
### <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
|
||||
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
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ a member and includes all members of the `hg1` hostgroup.
|
|||
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.
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -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)
|
||||
|
||||
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{
|
||||
contact_name testconfig-user
|
||||
|
|
@ -288,7 +288,7 @@ This migration part is explained in the [next chapter](19-migrating-from-icinga-
|
|||
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
|
||||
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
|
||||
[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 ]
|
||||
types = [ Recovery, Problem, Custom ]
|
||||
|
|
@ -577,7 +577,7 @@ enabled.
|
|||
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
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -797,7 +797,7 @@ set in the `constants.conf` configuration file:
|
|||
|
||||
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.
|
||||
|
||||
### <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 (`!`).
|
||||
|
||||
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**
|
||||
>
|
||||
|
|
@ -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)
|
||||
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
|
||||
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
|
||||
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
|
||||
|
||||
|
|
@ -152,13 +152,13 @@ In addition to built-in attributes you can define your own attributes:
|
|||
|
||||
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)
|
||||
* [Arrays](20-language-reference.md#array) and [dictionaries](20-language-reference.md#dictionary)
|
||||
* [Strings](18-language-reference.md#string-literals), [numbers](18-language-reference.md#numeric-literals) and [booleans](18-language-reference.md#boolean-literals)
|
||||
* [Arrays](18-language-reference.md#array) and [dictionaries](18-language-reference.md#dictionary)
|
||||
* [Functions](3-monitoring-basics.md#custom-attributes-functions)
|
||||
|
||||
### <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 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 }}
|
||||
}
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -430,15 +430,15 @@ The following macros provide global statistics:
|
|||
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),
|
||||
[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:
|
||||
|
||||
* Define the best match.
|
||||
* 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?
|
||||
* A generic pattern [match](20-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)
|
||||
* 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](18-language-reference.md#expression-operators)
|
||||
* All expressions must return a boolean value (an empty string is equal to `false` e.g.)
|
||||
|
||||
> **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`.
|
||||
|
||||
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" {
|
||||
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.
|
||||
|
||||
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 {
|
||||
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)
|
||||
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)
|
||||
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.
|
||||
|
||||
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`.
|
||||
|
||||
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.
|
||||
The other way around you can override specific custom attributes inherited from a service template,
|
||||
if set.
|
||||
|
|
@ -974,7 +974,7 @@ hosts or with the `test_server` attribute set to `true` are not added to this
|
|||
group.
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -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`
|
||||
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**
|
||||
>
|
||||
> 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.
|
||||
|
||||
You should choose which information you (and your notified users) are interested in
|
||||
|
|
@ -1231,7 +1231,7 @@ using the `check_command` attribute.
|
|||
|
||||
> **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.
|
||||
|
||||
#### <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**
|
||||
>
|
||||
> 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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ The configuration files which are automatically created when installing the Icin
|
|||
are a good way to start with Icinga 2.
|
||||
|
||||
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.
|
||||
|
||||
## <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.
|
||||
*/
|
||||
|
||||
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.
|
||||
|
|
@ -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
|
||||
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
|
||||
|
|
@ -295,13 +295,13 @@ host and your additional hosts are getting [services](4-configuring-icinga-2.md#
|
|||
|
||||
> **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
|
||||
> that in detail.
|
||||
|
||||
#### <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
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
`Linux`.
|
||||
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")`.
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
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).
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
* 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
|
||||
* 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.
|
||||
|
|
@ -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
|
||||
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
|
||||
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`.
|
||||
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`:
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
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.
|
||||
|
||||
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 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
|
||||
triggering specific actions (for example rescheduling a service check
|
||||
through the web interface).
|
||||
More details can be found in [this chapter](9-icinga2-api.md#icinga2-api).
|
||||
|
||||
In order to enable the `ExternalCommandListener` configuration use the
|
||||
following command and restart Icinga 2 afterwards:
|
||||
## <a id="features"></a> Icinga 2 Feature Configuration
|
||||
|
||||
# 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`
|
||||
using the default configuration.
|
||||
More details can be found in [this chapter](15-features.md#icinga2-features).
|
||||
|
||||
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_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**
|
||||
>
|
||||
> 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:
|
||||
|
||||
|
|
@ -1155,7 +1155,7 @@ A group of services.
|
|||
|
||||
> **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:
|
||||
|
||||
|
|
@ -1342,7 +1342,7 @@ A user group.
|
|||
|
||||
> **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:
|
||||
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -112,12 +112,12 @@ can be specified with the `--app` command-line option.
|
|||
|
||||
### 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.
|
||||
|
||||
### 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
|
||||
|
||||
|
|
@ -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
|
||||
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 - 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
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -472,7 +472,7 @@ Lists all configured variables (constants) in a similar fasion like [object list
|
|||
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
|
||||
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`
|
||||
|
||||
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`
|
||||
after validation passes to analyze object attributes, inheritance or created
|
||||
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*`:
|
||||
|
||||
|
|
@ -604,5 +604,5 @@ safely reload the Icinga 2 daemon.
|
|||
> which will validate the configuration in a separate process and not stop
|
||||
> 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
|
||||
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 = [ "*" ]
|
||||
|
||||
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.
|
||||
|
||||
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`
|
||||
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
|
||||
capabilities for some of the more common targets which do not directly change
|
||||
the configuration.
|
||||
|
|
@ -260,7 +260,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/process-check-result`.
|
|||
Parameter | Type | Description
|
||||
------------------|--------------|--------------
|
||||
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.
|
||||
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.
|
||||
|
|
@ -290,7 +290,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/reschedule-check`.
|
|||
Parameter | Type | Description
|
||||
-------------|-----------|--------------
|
||||
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`.
|
||||
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
|
||||
----------|---------|--------------
|
||||
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.
|
||||
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.
|
||||
|
|
@ -334,7 +334,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/delay-notification`.
|
|||
Parameter | Type | Description
|
||||
----------|-----------|--------------
|
||||
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.
|
||||
|
||||
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
|
||||
----------|-----------|--------------
|
||||
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.
|
||||
comment | string | **Required.** Comment text, may be empty.
|
||||
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
|
||||
----------|--------|--------------
|
||||
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
|
||||
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
|
||||
----------|--------|--------------
|
||||
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.
|
||||
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
|
||||
------------|---------|--------------
|
||||
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.
|
||||
|
||||
|
|
@ -429,12 +429,12 @@ Send a `POST` request to the URL endpoint `/v1/actions/schedule-downtime`.
|
|||
parameter | type | description
|
||||
------------|-----------|--------------
|
||||
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.
|
||||
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.
|
||||
fixed | boolean | **Optional.** Defaults to `false`. If true the downtime is `fixed` otherwise `flexible`. See [downtimes](5-advanced-topics.md#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.
|
||||
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](#Downtimes) for more information on triggered downtimes.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -460,7 +460,7 @@ Send a `POST` request to the URL endpoint `/v1/actions/remove-all-downtimes`.
|
|||
parameter | type | description
|
||||
----------|--------|--------------
|
||||
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.
|
||||
|
||||
|
|
|
|||
17
mkdocs.yml
17
mkdocs.yml
|
|
@ -16,15 +16,14 @@ pages:
|
|||
- [12-agent-based-checks.md, Additional Agent-based Checks]
|
||||
- [13-distributed-monitoring-ha.md, Distributed Monitoring and High Availability]
|
||||
- [14-addons-plugins.md, Addons and Plugins]
|
||||
- [15-alternative-frontends.md, Alternative Frontends]
|
||||
- [16-livestatus.md, Livestatus]
|
||||
- [17-troubleshooting.md, Troubleshooting]
|
||||
- [18-upgrading-icinga-2.md, Upgrading Icinga 2]
|
||||
- [19-migrating-from-icinga-1x.md, Migrating from Icinga 1.x]
|
||||
- [20-language-reference.md, Language Reference]
|
||||
- [21-library-reference.md, Library Reference]
|
||||
- [22-debug.md, Debug]
|
||||
- [23-appendix.md, Appendix]
|
||||
- [15-features.md, Features]
|
||||
- [16-troubleshooting.md, Troubleshooting]
|
||||
- [17-upgrading-icinga-2.md, Upgrading Icinga 2]
|
||||
- [18-language-reference.md, Language Reference]
|
||||
- [19-library-reference.md, Library Reference]
|
||||
- [20-debug.md, Debug]
|
||||
- [21-migrating-from-icinga-1x.md, Migrating from Icinga 1.x]
|
||||
- [22-appendix.md, Appendix]
|
||||
theme: readthedocs
|
||||
markdown_extensions: [smarty]
|
||||
extra_javascript: [scroll.js]
|
||||
|
|
|
|||
Loading…
Reference in New Issue