tyler.durden/icinga2
1
0
Fork 0
mirror of https://github.com/Icinga/icinga2.git synced 2025-07-26 15:14:07 +02:00
Code Issues Packages Projects Releases Wiki Activity

Update documentation links

Browse Source
This commit is contained in:
Gunnar Beutner 2015-01-22 16:23:23 +01:00
parent e09b8885bd
commit 8734a44cfc
12 changed files with 166 additions and 166 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
doc/1-about.md
View File

@ -46,7 +46,7 @@ More details in the [Icinga FAQ](https://www.icinga.org/icinga/faq/).
* [Register](https://exchange.icinga.org/authentication/register) an Icinga account. * [Register](https://exchange.icinga.org/authentication/register) an Icinga account.
* Create a new issue at the [Icinga 2 Development Tracker](https://dev.icinga.org/projects/i2). * Create a new issue at the [Icinga 2 Development Tracker](https://dev.icinga.org/projects/i2).
* When reporting a bug, please include the details described in the [Troubleshooting](7-troubleshooting.md#troubleshooting-information-required) chapter (version, configs, logs, etc). * When reporting a bug, please include the details described in the [Troubleshooting](8-troubleshooting.md#troubleshooting-information-required) chapter (version, configs, logs, etc).
## <a id="whats-new"></a> What's new ## <a id="whats-new"></a> What's new
@ -88,10 +88,10 @@ event handlers remotely.
Multithreaded and scalable for small embedded systems as well as large scale environments. Multithreaded and scalable for small embedded systems as well as large scale environments.
Running checks every second is no longer a problem and enables real-time monitoring capabilities. Running checks every second is no longer a problem and enables real-time monitoring capabilities.
Checks, notifications and event handlers [do not block Icinga 2](8-migrating-from-icinga-1x.md#differences-1x-2-async-event-execution) Checks, notifications and event handlers [do not block Icinga 2](9-migrating-from-icinga-1x.md#differences-1x-2-async-event-execution)
in its operation. Same goes for performance data writers and the external command pipe, or any in its operation. Same goes for performance data writers and the external command pipe, or any
file writers on disk (`statusdata`). file writers on disk (`statusdata`).
Unlike Icinga 1.x the [daemon reload](8-migrating-from-icinga-1x.md#differences-1x-2-real-reload) happens asynchronously. Unlike Icinga 1.x the [daemon reload](9-migrating-from-icinga-1x.md#differences-1x-2-real-reload) happens asynchronously.
A child daemon validates the new configuration, the parent process is still doing checks, replicating cluster events, triggering alert notifications, etc. If the configuration validation is ok, all remaining events are synchronized and the child process continues as normal. A child daemon validates the new configuration, the parent process is still doing checks, replicating cluster events, triggering alert notifications, etc. If the configuration validation is ok, all remaining events are synchronized and the child process continues as normal.
The DB IDO configuration dump and status/historical event updates also runs asynchronously in a queue not blocking the core anymore. The configuration validation itself runs in parallel allowing fast verification checks. The DB IDO configuration dump and status/historical event updates also runs asynchronously in a queue not blocking the core anymore. The configuration validation itself runs in parallel allowing fast verification checks.
That way you are not blind (anymore) during a configuration reload and benefit from a real scalable architecture. That way you are not blind (anymore) during a configuration reload and benefit from a real scalable architecture.
@ -114,7 +114,7 @@ on a dedicated cluster node. Enable it over there and point it to the carbon cac
Combine Icinga 2 Core with web user interfaces: Use [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2), but also Combine Icinga 2 Core with web user interfaces: Use [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2), but also
Web 1.x or Classic UI or your own preferred addon. Web 1.x or Classic UI or your own preferred addon.
* Native support for the [Livestatus protocol](2-getting-started.md#setting-up-livestatus) * Native support for the [Livestatus protocol](7-livestatus.md#setting-up-livestatus)
In Icinga2, the 'Livestatus' protocol is available for use as either a UNIX, or TCP socket. In Icinga2, the 'Livestatus' protocol is available for use as either a UNIX, or TCP socket.
@ -124,7 +124,7 @@ Icinga 2 still supports writing performance data files for graphing addons, but
capability of writing performance data directly into a Graphite TCP socket simplifying realtime capability of writing performance data directly into a Graphite TCP socket simplifying realtime
monitoring graphs. monitoring graphs.
* Native support for writing log events to [GELF](11-object-types.md#objecttype-gelfwriter) receivers (graylog2, Logstash) * Native support for writing log events to [GELF](12-object-types.md#objecttype-gelfwriter) receivers (graylog2, Logstash)
Icinga 2 will write all check result, state change and notification event logs into a defined Icinga 2 will write all check result, state change and notification event logs into a defined
[GELF](3-monitoring-basics.md#gelfwriter) input receiver. Natively provided by [graylog2](http://www.graylog2.org), [GELF](3-monitoring-basics.md#gelfwriter) input receiver. Natively provided by [graylog2](http://www.graylog2.org),
@ -132,14 +132,14 @@ and as additional input type provided by [Logstash](http://logstash.net).
* Dynamic configuration language * Dynamic configuration language
Simple [apply](3-monitoring-basics.md#using-apply) and [assign](9-language-reference.md#group-assign) rules for creating configuration object Simple [apply](3-monitoring-basics.md#using-apply) and [assign](10-language-reference.md#group-assign) rules for creating configuration object
relationships based on patterns. More advanced features for dynamic object generation using relationships based on patterns. More advanced features for dynamic object generation using
[apply for rules](3-monitoring-basics.md#using-apply-for) helped with arrays and dictionaries for [apply for rules](3-monitoring-basics.md#using-apply-for) helped with arrays and dictionaries for
[custom attributes](3-monitoring-basics.md#custom-attributes-apply). [custom attributes](3-monitoring-basics.md#custom-attributes-apply).
Supported with [duration literals](9-language-reference.md#duration-literals) for interval Supported with [duration literals](10-language-reference.md#duration-literals) for interval
attributes, [expression operators](9-language-reference.md#expression-operators), [function calls](9-language-reference.md#function-calls) for attributes, [expression operators](10-language-reference.md#expression-operators), [function calls](10-language-reference.md#function-calls) for
pattern and regex matching and (global) [constants](9-language-reference.md#constants). pattern and regex matching and (global) [constants](10-language-reference.md#constants).
[Check command configuration](12-icinga-template-library.md#plugin-check-commands) for common plugins is shipped with Icinga 2 as part of the [Icinga Template Library](12-icinga-template-library.md#icinga-template-library). [Check command configuration](13-icinga-template-library.md#plugin-check-commands) for common plugins is shipped with Icinga 2 as part of the [Icinga Template Library](13-icinga-template-library.md#icinga-template-library).
* Revamped Commands * Revamped Commands
@ -163,7 +163,7 @@ the command line, environment variables and custom attribute assignments.
Multiple [notifications](3-monitoring-basics.md#notifications) for one host or service with existing users Multiple [notifications](3-monitoring-basics.md#notifications) for one host or service with existing users
and notification commands. No more duplicated contacts for different notification types. and notification commands. No more duplicated contacts for different notification types.
Telling notification filters by state and type, even more fine-grained than Icinga 1.x. Telling notification filters by state and type, even more fine-grained than Icinga 1.x.
[Escalation notifications](#notification-escalations) and [delayed notifications](#first-notification-delay) [Escalation notifications](3-monitoring-basics.md#notification-escalations) and [delayed notifications](#first-notification-delay)
are just notifications with an additional begin and/or end time attribute. are just notifications with an additional begin and/or end time attribute.
* Dependencies between Hosts and Services * Dependencies between Hosts and Services
@ -183,7 +183,7 @@ objects and specify their active time window.
* Embedded Health Checks * Embedded Health Checks
No more external statistic tool but an [instance](12-icinga-template-library.md#itl-icinga) and [cluster](12-icinga-template-library.md#itl-icinga-cluster) health No more external statistic tool but an [instance](13-icinga-template-library.md#itl-icinga) and [cluster](13-icinga-template-library.md#itl-icinga-cluster) health
check providing direct statistics as performance data for your graphing addon, for example Graphite. check providing direct statistics as performance data for your graphing addon, for example Graphite.
* Compatibility with Icinga 1.x * Compatibility with Icinga 1.x
@ -194,11 +194,11 @@ All known interfaces are optionally available: [status files](3-monitoring-basic
[checkresult file reader](3-monitoring-basics.md#check-result-files) too. [checkresult file reader](3-monitoring-basics.md#check-result-files) too.
All [Monitoring Plugins](2-getting-started.md#setting-up-check-plugins) can be integrated into Icinga 2 with All [Monitoring Plugins](2-getting-started.md#setting-up-check-plugins) can be integrated into Icinga 2 with
newly created check command configuration if not already provided. newly created check command configuration if not already provided.
[Configuration migration](8-migrating-from-icinga-1x.md#configuration-migration) is possible through an external migration tool. [Configuration migration](9-migrating-from-icinga-1x.md#configuration-migration) is possible through an external migration tool.
Detailed [migration hints](8-migrating-from-icinga-1x.md#manual-config-migration-hints) explain migration of the Icinga 1.x Detailed [migration hints](9-migrating-from-icinga-1x.md#manual-config-migration-hints) explain migration of the Icinga 1.x
configuration objects into the native Icinga 2 configuration schema. configuration objects into the native Icinga 2 configuration schema.
Additional information on the differences is documented in the [migration](8-migrating-from-icinga-1x.md#differences-1x-2) chapter. Additional information on the differences is documented in the [migration](9-migrating-from-icinga-1x.md#differences-1x-2) chapter.
* Configuration Syntax Highlighting * Configuration Syntax Highlighting

8
doc/10-language-reference.md
View File

@ -188,7 +188,7 @@ Functions can be called using the `()` operator:
check_interval = len(MyGroups) * 1m check_interval = len(MyGroups) * 1m
} }
A list of available functions is available in the [Library Reference](10-library-reference.md#library-reference) chapter. A list of available functions is available in the [Library Reference](11-library-reference.md#library-reference) chapter.
## <a id="dictionary-operators"></a> Assignments ## <a id="dictionary-operators"></a> Assignments
@ -383,7 +383,7 @@ another group of objects.
In this example the `assign where` condition is a boolean expression which is In this example the `assign where` condition is a boolean expression which is
evaluated for all objects of type `Host` and a new service with name "ping" evaluated for all objects of type `Host` and a new service with name "ping"
is created for each matching host. [Expression operators](9-language-reference.md#expression-operators) is created for each matching host. [Expression operators](10-language-reference.md#expression-operators)
may be used in `assign where` conditions. may be used in `assign where` conditions.
The `to` keyword and the target type may be omitted if there is only one target The `to` keyword and the target type may be omitted if there is only one target
@ -420,7 +420,7 @@ and `ignore where` conditions.
In this example the `assign where` condition is a boolean expression which is evaluated In this example the `assign where` condition is a boolean expression which is evaluated
for all objects of the type `Host`. Each matching host is added as member to the host group for all objects of the type `Host`. Each matching host is added as member to the host group
with the name "linux-servers". Membership exclusion can be controlled using the `ignore where` with the name "linux-servers". Membership exclusion can be controlled using the `ignore where`
condition. [Expression operators](9-language-reference.md#expression-operators) may be used in `assign where` and condition. [Expression operators](10-language-reference.md#expression-operators) may be used in `assign where` and
`ignore where` conditions. `ignore where` conditions.
Source Type | Variables Source Type | Variables
@ -449,7 +449,7 @@ Empty dictionary | {} | false
Non-empty dictionary | { key = "value" } | true Non-empty dictionary | { key = "value" } | true
For a list of supported expression operators for `assign where` and `ignore where` For a list of supported expression operators for `assign where` and `ignore where`
statements, see [expression operators](9-language-reference.md#expression-operators). statements, see [expression operators](10-language-reference.md#expression-operators).
## <a id="comments"></a> Comments ## <a id="comments"></a> Comments

12
doc/12-object-types.md
View File

@ -59,7 +59,7 @@ A group of hosts.
> **Best Practice** > **Best Practice**
> >
> Assign host group members using the [group assign](9-language-reference.md#group-assign) rules. > Assign host group members using the [group assign](10-language-reference.md#group-assign) rules.
Example: Example:
@ -145,7 +145,7 @@ A group of services.
> **Best Practice** > **Best Practice**
> >
> Assign service group members using the [group assign](9-language-reference.md#group-assign) rules. > Assign service group members using the [group assign](10-language-reference.md#group-assign) rules.
Example: Example:
@ -224,7 +224,7 @@ A user group.
> **Best Practice** > **Best Practice**
> >
> Assign user group members using the [group assign](9-language-reference.md#group-assign) rules. > Assign user group members using the [group assign](10-language-reference.md#group-assign) rules.
Example: Example:
@ -398,7 +398,7 @@ Attributes:
zone |**Optional.** The zone this object is a member of. zone |**Optional.** The zone this object is a member of.
arguments |**Optional.** A dictionary of command arguments. arguments |**Optional.** A dictionary of command arguments.
Command arguments can be used the same way as for [CheckCommand objects](11-object-types.md#objecttype-checkcommand-arguments). Command arguments can be used the same way as for [CheckCommand objects](12-object-types.md#objecttype-checkcommand-arguments).
## <a id="objecttype-eventcommand"></a> EventCommand ## <a id="objecttype-eventcommand"></a> EventCommand
@ -425,7 +425,7 @@ Attributes:
timeout |**Optional.** The command timeout in seconds. Defaults to 60 seconds. timeout |**Optional.** The command timeout in seconds. Defaults to 60 seconds.
arguments |**Optional.** A dictionary of command arguments. arguments |**Optional.** A dictionary of command arguments.
Command arguments can be used the same way as for [CheckCommand objects](11-object-types.md#objecttype-checkcommand-arguments). Command arguments can be used the same way as for [CheckCommand objects](12-object-types.md#objecttype-checkcommand-arguments).
## <a id="objecttype-notification"></a> Notification ## <a id="objecttype-notification"></a> Notification
@ -737,7 +737,7 @@ Attributes:
Metric prefix names can be modified using [runtime macros](3-monitoring-basics.md#runtime-macros). Metric prefix names can be modified using [runtime macros](3-monitoring-basics.md#runtime-macros).
Example with your custom [global constant](9-language-reference.md#constants) `GraphiteEnv`: Example with your custom [global constant](10-language-reference.md#constants) `GraphiteEnv`:
const GraphiteEnv = "icinga.env1" const GraphiteEnv = "icinga.env1"

44
doc/2-getting-started.md
View File

@ -4,7 +4,7 @@ This tutorial is a step-by-step introduction to installing Icinga 2 and
available Icinga web interfaces. It assumes that you are familiar with available Icinga web interfaces. It assumes that you are familiar with
the system you're installing Icinga 2 on. the system you're installing Icinga 2 on.
Details on troubleshooting problems can be found [here](7-troubleshooting.md#troubleshooting). Details on troubleshooting problems can be found [here](8-troubleshooting.md#troubleshooting).
## <a id="setting-up-icinga2"></a> Setting up Icinga 2 ## <a id="setting-up-icinga2"></a> Setting up Icinga 2
@ -192,7 +192,7 @@ Here's a brief description of the example configuration:
* to the documentation that is distributed as part of Icinga 2. * to the documentation that is distributed as part of Icinga 2.
*/ */
Icinga 2 supports [C/C++-style comments](9-language-reference.md#comments). Icinga 2 supports [C/C++-style comments](10-language-reference.md#comments).
/** /**
* The constants.conf defines global constants. * The constants.conf defines global constants.
@ -263,7 +263,7 @@ By default, you need to make sure to set these constants:
* The `PluginDir` constant must be pointed to your [check plugins](2-getting-started.md#setting-up-check-plugins) path. * The `PluginDir` constant must be pointed to your [check plugins](2-getting-started.md#setting-up-check-plugins) path.
This constant is required by the shipped This constant is required by the shipped
[plugin check command configuration](12-icinga-template-library.md#plugin-check-commands). [plugin check command configuration](13-icinga-template-library.md#plugin-check-commands).
* The `NodeName` constant defines your local node name. Should be set to FQDN which is the default * The `NodeName` constant defines your local node name. Should be set to FQDN which is the default
if not set. This constant is required for local host configuration, monitoring remote clients and if not set. This constant is required for local host configuration, monitoring remote clients and
cluster setup. cluster setup.
@ -334,7 +334,7 @@ takes care of setting up the host check command to `hostalive`. If you
require a different check command, you can override it in the object definition. require a different check command, you can override it in the object definition.
The `vars` attribute can be used to define custom attributes which are available The `vars` attribute can be used to define custom attributes which are available
for check and notification commands. Most of the [Plugin Check Commands](12-icinga-template-library.md#plugin-check-commands) for check and notification commands. Most of the [Plugin Check Commands](13-icinga-template-library.md#plugin-check-commands)
in the Icinga Template Library require an `address` attribute. in the Icinga Template Library require an `address` attribute.
The custom attribute `os` is evaluated by the `linux-servers` group in The custom attribute `os` is evaluated by the `linux-servers` group in
@ -412,13 +412,13 @@ host and your additional hosts are getting [services](2-getting-started.md#servi
> **Tip** > **Tip**
> >
> If you don't understand all the attributes and how to use [apply rules](9-language-reference.md#apply) > If you don't understand all the attributes and how to use [apply rules](10-language-reference.md#apply)
> don't worry - the [monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter will explain > don't worry - the [monitoring basics](3-monitoring-basics.md#monitoring-basics) chapter will explain
> that in detail. > that in detail.
#### <a id="services-conf"></a> services.conf #### <a id="services-conf"></a> services.conf
These service [apply rules](9-language-reference.md#apply) will show you how to monitor These service [apply rules](10-language-reference.md#apply) will show you how to monitor
the local host, but also allow you to re-use or modify them for the local host, but also allow you to re-use or modify them for
your own requirements. your own requirements.
@ -438,8 +438,8 @@ Service(s) | Applied on host(s)
The Debian packages also ship an additional `apt` service check applied to the local host. The Debian packages also ship an additional `apt` service check applied to the local host.
The command object `icinga` for the embedded health check is provided by the The command object `icinga` for the embedded health check is provided by the
[Icinga Template Library (ITL)](12-icinga-template-library.md#icinga-template-library) while `http_ip`, `ssh`, `load`, `processes`, [Icinga Template Library (ITL)](13-icinga-template-library.md#icinga-template-library) while `http_ip`, `ssh`, `load`, `processes`,
`users` and `disk` are all provided by the [Plugin Check Commands](12-icinga-template-library.md#plugin-check-commands) `users` and `disk` are all provided by the [Plugin Check Commands](13-icinga-template-library.md#plugin-check-commands)
which we enabled earlier by including the `itl` and `plugins` configuration file. which we enabled earlier by including the `itl` and `plugins` configuration file.
@ -466,7 +466,7 @@ these services in [downtimes.conf](2-getting-started.md#downtimes-conf).
In this example the `assign where` condition is a boolean expression which is In this example the `assign where` condition is a boolean expression which is
evaluated for all objects of type `Host` and a new service with name "load" evaluated for all objects of type `Host` and a new service with name "load"
is created for each matching host. [Expression operators](9-language-reference.md#expression-operators) is created for each matching host. [Expression operators](10-language-reference.md#expression-operators)
may be used in `assign where` conditions. may be used in `assign where` conditions.
Multiple `assign where` condition can be combined with `AND` using the `&&` operator Multiple `assign where` condition can be combined with `AND` using the `&&` operator
@ -484,7 +484,7 @@ In this example, the service `ssh` is applied to all hosts having the `address`
attribute defined `AND` having the custom attribute `os` set to the string attribute defined `AND` having the custom attribute `os` set to the string
`Linux`. `Linux`.
You can modify this condition to match multiple expressions by combinding `AND` You can modify this condition to match multiple expressions by combinding `AND`
and `OR` using `&&` and `||` [operators](9-language-reference.md#expression-operators), for example and `OR` using `&&` and `||` [operators](10-language-reference.md#expression-operators), for example
`assign where host.address && (vars.os == "Linux" || vars.os == "Windows")`. `assign where host.address && (vars.os == "Linux" || vars.os == "Windows")`.
@ -530,7 +530,7 @@ Once defined like this, the `apply` rule defined below will do the following:
* loop through all entries in the `host.vars.disks` dictionary. That's `disk` and `disk /` as keys. * loop through all entries in the `host.vars.disks` dictionary. That's `disk` and `disk /` as keys.
* call `apply` on each, and set the service object name from the provided key * call `apply` on each, and set the service object name from the provided key
* inside apply, the `generic-service` template is imported * inside apply, the `generic-service` template is imported
* defining the [disk](12-icinga-template-library.md#plugin-check-command-disk) check command requiring command arguments like `disk_partition` * defining the [disk](13-icinga-template-library.md#plugin-check-command-disk) check command requiring command arguments like `disk_partition`
* adding the `config` dictionary items to `vars`. Simply said, there's now `vars.disk_partition` defined for the * adding the `config` dictionary items to `vars`. Simply said, there's now `vars.disk_partition` defined for the
generated service generated service
@ -593,7 +593,7 @@ Please note that the `to` keyword is important in [notification apply rules](3-m
defining whether these notifications are applies to hosts or services. defining whether these notifications are applies to hosts or services.
The `import` keyword imports the specific mail templates defined in [templates.conf](2-getting-started.md#templates-conf). The `import` keyword imports the specific mail templates defined in [templates.conf](2-getting-started.md#templates-conf).
The `interval` attribute is not explicitly set - it [defaults to 30 minutes](11-object-types.md#objecttype-notification). The `interval` attribute is not explicitly set - it [defaults to 30 minutes](12-object-types.md#objecttype-notification).
By setting the `user_groups` to the value provided by the By setting the `user_groups` to the value provided by the
respective [host.vars.notification.mail](2-getting-started.md#hosts-conf) attribute we'll respective [host.vars.notification.mail](2-getting-started.md#hosts-conf) attribute we'll
@ -626,8 +626,8 @@ only the notification commands used by the notification templates defined in [te
> **Tip** > **Tip**
> >
> Icinga 2 ships the most common command definitions already in the > Icinga 2 ships the most common command definitions already in the
> [Plugin Check Commands](12-icinga-template-library.md#plugin-check-commands) definitions. More details on > [Plugin Check Commands](13-icinga-template-library.md#plugin-check-commands) definitions. More details on
> that topic in the [troubleshooting section](7-troubleshooting.md#check-command-definitions). > that topic in the [troubleshooting section](8-troubleshooting.md#check-command-definitions).
You can freely customize these notification commands, and adapt them for your needs. You can freely customize these notification commands, and adapt them for your needs.
Read more on that topic [here](3-monitoring-basics.md#notification-commands). Read more on that topic [here](3-monitoring-basics.md#notification-commands).
@ -638,7 +638,7 @@ The example host defined in [hosts.conf](hosts-conf) already has the
custom attribute `os` set to `Linux` and is therefore automatically custom attribute `os` set to `Linux` and is therefore automatically
a member of the host group `linux-servers`. a member of the host group `linux-servers`.
This is done by using the [group assign](9-language-reference.md#group-assign) expressions similar This is done by using the [group assign](10-language-reference.md#group-assign) expressions similar
to previously seen [apply rules](3-monitoring-basics.md#using-apply). to previously seen [apply rules](3-monitoring-basics.md#using-apply).
object HostGroup "linux-servers" { object HostGroup "linux-servers" {
@ -654,7 +654,7 @@ to previously seen [apply rules](3-monitoring-basics.md#using-apply).
} }
Service groups can be grouped together by similar pattern matches. Service groups can be grouped together by similar pattern matches.
The [match() function](9-language-reference.md#function-calls) expects a wildcard match string The [match() function](10-language-reference.md#function-calls) expects a wildcard match string
and the attribute string to match with. and the attribute string to match with.
object ServiceGroup "ping" { object ServiceGroup "ping" {
@ -700,7 +700,7 @@ the default `states` and `types` filters for notification apply rules defined in
} }
The `hostalive` check command is shipped with Icinga 2 in the The `hostalive` check command is shipped with Icinga 2 in the
[Plugin Check Commands](12-icinga-template-library.md#plugin-check-commands). [Plugin Check Commands](13-icinga-template-library.md#plugin-check-commands).
template Notification "mail-host-notification" { template Notification "mail-host-notification" {
@ -725,7 +725,7 @@ The `hostalive` check command is shipped with Icinga 2 in the
period = "24x7" period = "24x7"
} }
More details on `Notification` object attributes can be found [here](11-object-types.md#objecttype-notification). More details on `Notification` object attributes can be found [here](12-object-types.md#objecttype-notification).
#### <a id="downtimes-conf"></a> downtimes.conf #### <a id="downtimes-conf"></a> downtimes.conf
@ -733,7 +733,7 @@ More details on `Notification` object attributes can be found [here](11-object-t
The `load` service apply rule defined in [services.conf](2-getting-started.md#services-conf) defines The `load` service apply rule defined in [services.conf](2-getting-started.md#services-conf) defines
the `backup_downtime` custom attribute. the `backup_downtime` custom attribute.
The [ScheduledDowntime](11-object-types.md#objecttype-scheduleddowntime) apply rule uses this attribute The [ScheduledDowntime](12-object-types.md#objecttype-scheduleddowntime) apply rule uses this attribute
to define the default value for the time ranges required for recurring downtime slots. to define the default value for the time ranges required for recurring downtime slots.
apply ScheduledDowntime "backup-downtime" to Service { apply ScheduledDowntime "backup-downtime" to Service {
@ -922,7 +922,7 @@ The package provides a new configuration file that is installed in
`/etc/icinga2/features-available/ido-mysql.conf`. You will need to update the `/etc/icinga2/features-available/ido-mysql.conf`. You will need to update the
database credentials in this file. database credentials in this file.
All available attributes are listed in the All available attributes are listed in the
[IdoMysqlConnection object](11-object-types.md#objecttype-idomysqlconnection) configuration details. [IdoMysqlConnection object](12-object-types.md#objecttype-idomysqlconnection) configuration details.
You can enable the `ido-mysql` feature configuration file using `icinga2 feature enable`: You can enable the `ido-mysql` feature configuration file using `icinga2 feature enable`:
@ -1036,7 +1036,7 @@ The package provides a new configuration file that is installed in
`/etc/icinga2/features-available/ido-pgsql.conf`. You will need to update the `/etc/icinga2/features-available/ido-pgsql.conf`. You will need to update the
database credentials in this file. database credentials in this file.
All available attributes are listed in the All available attributes are listed in the
[IdoPgsqlConnection object](11-object-types.md#objecttype-idopgsqlconnection) configuration details. [IdoPgsqlConnection object](12-object-types.md#objecttype-idopgsqlconnection) configuration details.
You can enable the `ido-pgsql` feature configuration file using `icinga2 feature enable`: You can enable the `ido-pgsql` feature configuration file using `icinga2 feature enable`:
@ -1102,7 +1102,7 @@ Icinga 2 also is compatible with Icinga 1.x user interfaces
by providing additional features required as backends. by providing additional features required as backends.
Some Icinga 1.x interface features will only work in a limited manner due to Some Icinga 1.x interface features will only work in a limited manner due to
[compatibility reasons](8-migrating-from-icinga-1x.md#differences-1x-2), other features like the [compatibility reasons](9-migrating-from-icinga-1x.md#differences-1x-2), other features like the
statusmap parents are available by dumping the host dependencies as parents. statusmap parents are available by dumping the host dependencies as parents.
Special restrictions are noted specifically in the sections below. Special restrictions are noted specifically in the sections below.

90
doc/3-monitoring-basics.md
View File

@ -43,7 +43,7 @@ check command.
The `address` attribute is used by check commands to determine which network The `address` attribute is used by check commands to determine which network
address is associated with the host object. address is associated with the host object.
Details on troubleshooting check problems can be found [here](7-troubleshooting.md#troubleshooting). Details on troubleshooting check problems can be found [here](8-troubleshooting.md#troubleshooting).
### <a id="host-states"></a> Host States ### <a id="host-states"></a> Host States
@ -97,7 +97,7 @@ there is no check available, the `dummy` check command.
Service checks could also use a `dummy` check, but the common strategy is to Service checks could also use a `dummy` check, but the common strategy is to
[integrate an existing plugin](3-monitoring-basics.md#command-plugin-integration) as [integrate an existing plugin](3-monitoring-basics.md#command-plugin-integration) as
[check command](3-monitoring-basics.md#check-commands) and [reference](3-monitoring-basics.md#command-passing-parameters) [check command](3-monitoring-basics.md#check-commands) and [reference](3-monitoring-basics.md#command-passing-parameters)
that in your [Service](11-object-types.md#objecttype-service) object definition. that in your [Service](12-object-types.md#objecttype-service) object definition.
## <a id="configuration-best-practice"></a> Configuration Best Practice ## <a id="configuration-best-practice"></a> Configuration Best Practice
@ -213,18 +213,18 @@ Example for importing objects:
### <a id="using-apply"></a> Apply objects based on rules ### <a id="using-apply"></a> Apply objects based on rules
Instead of assigning each object ([Service](11-object-types.md#objecttype-service), Instead of assigning each object ([Service](12-object-types.md#objecttype-service),
[Notification](11-object-types.md#objecttype-notification), [Dependency](11-object-types.md#objecttype-dependency), [Notification](12-object-types.md#objecttype-notification), [Dependency](12-object-types.md#objecttype-dependency),
[ScheduledDowntime](11-object-types.md#objecttype-scheduleddowntime)) [ScheduledDowntime](12-object-types.md#objecttype-scheduleddowntime))
based on attribute identifiers for example `host_name` objects can be [applied](9-language-reference.md#apply). based on attribute identifiers for example `host_name` objects can be [applied](10-language-reference.md#apply).
Before you start using the apply rules keep the following in mind: Before you start using the apply rules keep the following in mind:
* Define the best match. * Define the best match.
* A set of unique [custom attributes](3-monitoring-basics.md#custom-attributes-apply) for these hosts/services? * A set of unique [custom attributes](3-monitoring-basics.md#custom-attributes-apply) for these hosts/services?
* Or [group](3-monitoring-basics.md#groups) memberships, e.g. a host being a member of a hostgroup, applying services to it? * Or [group](3-monitoring-basics.md#groups) memberships, e.g. a host being a member of a hostgroup, applying services to it?
* A generic pattern [match](9-language-reference.md#function-calls) on the host/service name? * A generic pattern [match](10-language-reference.md#function-calls) on the host/service name?
* [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](9-language-reference.md#expression-operators) * [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](10-language-reference.md#expression-operators)
* All expressions must return a boolean value (an empty string is equal to `false` e.g.) * All expressions must return a boolean value (an empty string is equal to `false` e.g.)
> **Note** > **Note**
@ -288,7 +288,7 @@ two condition passes: Either the `customer` host custom attribute is set to `cus
`OR` the host custom attribute `always_notify` is set to `true`. `OR` the host custom attribute `always_notify` is set to `true`.
The notification is ignored for services whose host name ends with `*internal` The notification is ignored for services whose host name ends with `*internal`
`OR` the `priority` custom attribute is [less than](9-language-reference.md#expression-operators) `2`. `OR` the `priority` custom attribute is [less than](10-language-reference.md#expression-operators) `2`.
template Notification "cust-xy-notification" { template Notification "cust-xy-notification" {
users = [ "noc-xy", "mgmt-xy" ] users = [ "noc-xy", "mgmt-xy" ]
@ -432,7 +432,7 @@ You can also specifiy the check command that way.
} }
Note that numbers must be explicitely casted to string when adding to strings. Note that numbers must be explicitely casted to string when adding to strings.
This can be achieved by wrapping them into the [string()](9-language-reference.md#function-calls) function. This can be achieved by wrapping them into the [string()](10-language-reference.md#function-calls) function.
> **Tip** > **Tip**
> >
@ -545,7 +545,7 @@ the user groups are associated as attributes in `Notification` objects.
If there is a certain number of hosts, services, or users matching a pattern If there is a certain number of hosts, services, or users matching a pattern
it's reasonable to assign the group object to these members. it's reasonable to assign the group object to these members.
Details on the `assign where` syntax can be found [here](9-language-reference.md#apply) Details on the `assign where` syntax can be found [here](10-language-reference.md#apply)
object HostGroup "prod-mssql" { object HostGroup "prod-mssql" {
display_name = "Production MSSQL Servers" display_name = "Production MSSQL Servers"
@ -590,7 +590,7 @@ The user `icingaadmin` in the example below will get notified only on `WARNING`
If you don't set the `states` and `types` configuration attributes for the `User` If you don't set the `states` and `types` configuration attributes for the `User`
object, notifications for all states and types will be sent. object, notifications for all states and types will be sent.
Details on troubleshooting notification problems can be found [here](7-troubleshooting.md#troubleshooting). Details on troubleshooting notification problems can be found [here](8-troubleshooting.md#troubleshooting).
> **Note** > **Note**
> >
@ -886,11 +886,11 @@ Please check [Runtime Custom Attributes as Environment Variables](3-monitoring-b
### <a id="check-commands"></a> Check Commands ### <a id="check-commands"></a> Check Commands
[CheckCommand](11-object-types.md#objecttype-checkcommand) objects define the command line how [CheckCommand](12-object-types.md#objecttype-checkcommand) objects define the command line how
a check is called. a check is called.
[CheckCommand](11-object-types.md#objecttype-checkcommand) objects are referenced by [CheckCommand](12-object-types.md#objecttype-checkcommand) objects are referenced by
[Host](11-object-types.md#objecttype-host) and [Service](11-object-types.md#objecttype-service) objects [Host](12-object-types.md#objecttype-host) and [Service](12-object-types.md#objecttype-service) objects
using the `check_command` attribute. using the `check_command` attribute.
> **Note** > **Note**
@ -900,7 +900,7 @@ using the `check_command` attribute.
#### <a id="command-plugin-integration"></a> Integrate the Plugin with a CheckCommand Definition #### <a id="command-plugin-integration"></a> Integrate the Plugin with a CheckCommand Definition
[CheckCommand](11-object-types.md#objecttype-checkcommand) objects require the [ITL template](12-icinga-template-library.md#itl-plugin-check-command) [CheckCommand](12-object-types.md#objecttype-checkcommand) objects require the [ITL template](13-icinga-template-library.md#itl-plugin-check-command)
`plugin-check-command` to support native plugin based check methods. `plugin-check-command` to support native plugin based check methods.
Unless you have done so already, download your check plugin and put it Unless you have done so already, download your check plugin and put it
@ -932,7 +932,7 @@ partition defined (`-p`) it will check all local partitions.
> Don't execute plugins as `root` and always use the absolute path to the plugin! Trust us. > Don't execute plugins as `root` and always use the absolute path to the plugin! Trust us.
Next step is to understand how command parameters are being passed from Next step is to understand how command parameters are being passed from
a host or service object, and add a [CheckCommand](11-object-types.md#objecttype-checkcommand) a host or service object, and add a [CheckCommand](12-object-types.md#objecttype-checkcommand)
definition based on these required parameters and/or default values. definition based on these required parameters and/or default values.
#### <a id="command-passing-parameters"></a> Passing Check Command Parameters from Host or Service #### <a id="command-passing-parameters"></a> Passing Check Command Parameters from Host or Service
@ -976,7 +976,7 @@ can also be inherited from a parent template using additive inheritance (`+=`).
> **Note** > **Note**
> >
> A proper example for the `check_disk` plugin is already shipped with Icinga 2 > A proper example for the `check_disk` plugin is already shipped with Icinga 2
> ready to use with the [plugin check commands](12-icinga-template-library.md#plugin-check-command-disk). > ready to use with the [plugin check commands](13-icinga-template-library.md#plugin-check-command-disk).
The host `localhost` with the applied service `basic-partitions` checks a basic set of disk partitions The host `localhost` with the applied service `basic-partitions` checks a basic set of disk partitions
with modified custom attributes (warning thresholds at `10%`, critical thresholds at `5%` with modified custom attributes (warning thresholds at `10%`, critical thresholds at `5%`
@ -1072,7 +1072,7 @@ That way you can use the `check_http` command definition for both, with and
without SSL enabled checks saving you duplicated command definitions. without SSL enabled checks saving you duplicated command definitions.
Details on all available options can be found in the Details on all available options can be found in the
[CheckCommand object definition](11-object-types.md#objecttype-checkcommand). [CheckCommand object definition](12-object-types.md#objecttype-checkcommand).
### <a id="using-apply-services-command-arguments"></a> Apply Services with Custom Command Arguments ### <a id="using-apply-services-command-arguments"></a> Apply Services with Custom Command Arguments
@ -1100,7 +1100,7 @@ the `my-host2` host requires a different port on 2222. Both hosts are in the hos
} }
All hosts in the `my-linux-servers` hostgroup should get the `my-ssh` service applied based on an All hosts in the `my-linux-servers` hostgroup should get the `my-ssh` service applied based on an
[apply rule](9-language-reference.md#apply). The optional `ssh_port` command argument should be inherited from the host [apply rule](10-language-reference.md#apply). The optional `ssh_port` command argument should be inherited from the host
the service is applied to. If not set, the check command `my-ssh` will omit the argument. the service is applied to. If not set, the check command `my-ssh` will omit the argument.
The `host` argument is special: `skip_key` tells Icinga 2 to ignore the key, and directly put the The `host` argument is special: `skip_key` tells Icinga 2 to ignore the key, and directly put the
value onto the command line. The `order` attribute specifies that this argument is the first one value onto the command line. The `order` attribute specifies that this argument is the first one
@ -1145,13 +1145,13 @@ The `my-host2` will inherit the `custom_ssh_port` variable to the service and ex
### <a id="notification-commands"></a> Notification Commands ### <a id="notification-commands"></a> Notification Commands
[NotificationCommand](11-object-types.md#objecttype-notificationcommand) objects define how notifications are delivered to external [NotificationCommand](12-object-types.md#objecttype-notificationcommand) objects define how notifications are delivered to external
interfaces (E-Mail, XMPP, IRC, Twitter, etc). interfaces (E-Mail, XMPP, IRC, Twitter, etc).
[NotificationCommand](11-object-types.md#objecttype-notificationcommand) objects are referenced by [NotificationCommand](12-object-types.md#objecttype-notificationcommand) objects are referenced by
[Notification](11-object-types.md#objecttype-notification) objects using the `command` attribute. [Notification](12-object-types.md#objecttype-notification) objects using the `command` attribute.
`NotificationCommand` objects require the [ITL template](12-icinga-template-library.md#itl-plugin-notification-command) `NotificationCommand` objects require the [ITL template](13-icinga-template-library.md#itl-plugin-notification-command)
`plugin-notification-command` to support native plugin-based notifications. `plugin-notification-command` to support native plugin-based notifications.
> **Note** > **Note**
@ -1231,8 +1231,8 @@ check execution if one of these conditions match:
* The host/service state changes into a [hard state](3-monitoring-basics.md#hard-soft-states) * The host/service state changes into a [hard state](3-monitoring-basics.md#hard-soft-states)
* The host/service state recovers from a [soft or hard state](3-monitoring-basics.md#hard-soft-states) to [OK](3-monitoring-basics.md#service-states)/[Up](3-monitoring-basics.md#host-states) * The host/service state recovers from a [soft or hard state](3-monitoring-basics.md#hard-soft-states) to [OK](3-monitoring-basics.md#service-states)/[Up](3-monitoring-basics.md#host-states)
[EventCommand](11-object-types.md#objecttype-eventcommand) objects are referenced by [EventCommand](12-object-types.md#objecttype-eventcommand) objects are referenced by
[Host](11-object-types.md#objecttype-host) and [Service](11-object-types.md#objecttype-service) objects [Host](12-object-types.md#objecttype-host) and [Service](12-object-types.md#objecttype-service) objects
using the `event_command` attribute. using the `event_command` attribute.
Therefore the `EventCommand` object should define a command line Therefore the `EventCommand` object should define a command line
@ -1269,7 +1269,7 @@ Example on Debian:
icinga ALL=(ALL) NOPASSWD: /etc/init.d/apache2 restart icinga ALL=(ALL) NOPASSWD: /etc/init.d/apache2 restart
Define a generic [EventCommand](11-object-types.md#objecttype-eventcommand) object `event_by_ssh` Define a generic [EventCommand](12-object-types.md#objecttype-eventcommand) object `event_by_ssh`
which can be used for all event commands triggered using ssh: which can be used for all event commands triggered using ssh:
/* pass event commands through ssh */ /* pass event commands through ssh */
@ -1370,7 +1370,7 @@ Remote Host Terminal:
## <a id="dependencies"></a> Dependencies ## <a id="dependencies"></a> Dependencies
Icinga 2 uses host and service [Dependency](11-object-types.md#objecttype-dependency) objects Icinga 2 uses host and service [Dependency](12-object-types.md#objecttype-dependency) objects
for determing their network reachability. for determing their network reachability.
A service can depend on a host, and vice versa. A service has an implicit A service can depend on a host, and vice versa. A service has an implicit
@ -1405,7 +1405,7 @@ Rephrased: If the parent service object changes into the `Warning` state, this
dependency will fail and render all child objects (hosts or services) unreachable. dependency will fail and render all child objects (hosts or services) unreachable.
You can determine the child's reachability by querying the `is_reachable` attribute You can determine the child's reachability by querying the `is_reachable` attribute
in for example [DB IDO](13-appendix.md#schema-db-ido-extensions). in for example [DB IDO](14-appendix.md#schema-db-ido-extensions).
### <a id="dependencies-implicit-host-service"></a> Implicit Dependencies for Services on Host ### <a id="dependencies-implicit-host-service"></a> Implicit Dependencies for Services on Host
@ -1657,7 +1657,7 @@ downtime on NOT-OK state change.
### <a id="recurring-downtimes"></a> Recurring Downtimes ### <a id="recurring-downtimes"></a> Recurring Downtimes
[ScheduledDowntime objects](11-object-types.md#objecttype-scheduleddowntime) can be used to set up [ScheduledDowntime objects](12-object-types.md#objecttype-scheduleddowntime) can be used to set up
recurring downtimes for services. recurring downtimes for services.
Example: Example:
@ -1728,9 +1728,9 @@ for applying objects for dynamic config generation.
There are several ways of using custom attributes with [apply rules](3-monitoring-basics.md#using-apply): There are several ways of using custom attributes with [apply rules](3-monitoring-basics.md#using-apply):
* As simple attribute literal ([number](9-language-reference.md#numeric-literals), [string](9-language-reference.md#string-literals), * As simple attribute literal ([number](10-language-reference.md#numeric-literals), [string](10-language-reference.md#string-literals),
[boolean](9-language-reference.md#boolean-literals)) for expression conditions (`assign where`, `ignore where`) [boolean](10-language-reference.md#boolean-literals)) for expression conditions (`assign where`, `ignore where`)
* As [array](9-language-reference.md#array) or [dictionary](9-language-reference.md#dictionary) attribute with nested values * As [array](10-language-reference.md#array) or [dictionary](10-language-reference.md#dictionary) attribute with nested values
(e.g. dictionaries in dictionaries) in [apply for](3-monitoring-basics.md#using-apply-for) rules. (e.g. dictionaries in dictionaries) in [apply for](3-monitoring-basics.md#using-apply-for) rules.
Features like [DB IDO](3-monitoring-basics.md#db-ido), Livestatus(#livestatus) or StatusData(#status-data) Features like [DB IDO](3-monitoring-basics.md#db-ido), Livestatus(#livestatus) or StatusData(#status-data)
@ -1751,7 +1751,7 @@ which use custom runtime attributes to format their output.
> **Tip** > **Tip**
> >
> Custom attributes are identified by the `vars` dictionary attribute as short name. > Custom attributes are identified by the `vars` dictionary attribute as short name.
> Accessing the different attribute keys is possible using the [index accessor](9-language-reference.md#indexer) `.`. > Accessing the different attribute keys is possible using the [index accessor](10-language-reference.md#indexer) `.`.
Custom attributes in command definitions or performance data templates are evaluated at Custom attributes in command definitions or performance data templates are evaluated at
runtime when executing a command. These custom attributes cannot be used somewhere else runtime when executing a command. These custom attributes cannot be used somewhere else
@ -1764,13 +1764,13 @@ Arrays can be used to pass multiple arguments with or without repeating the key
This helps passing multiple parameters to check plugins requiring them. Prominent This helps passing multiple parameters to check plugins requiring them. Prominent
plugin examples are: plugin examples are:
* [check_disk -p](12-icinga-template-library.md#plugin-check-command-disk) * [check_disk -p](13-icinga-template-library.md#plugin-check-command-disk)
* [check_nrpe -a](12-icinga-template-library.md#plugin-check-command-nrpe) * [check_nrpe -a](13-icinga-template-library.md#plugin-check-command-nrpe)
* [check_nscp -l](12-icinga-template-library.md#plugin-check-command-nscp) * [check_nscp -l](13-icinga-template-library.md#plugin-check-command-nscp)
* [check_dns -a](12-icinga-template-library.md#plugin-check-command-dns) * [check_dns -a](13-icinga-template-library.md#plugin-check-command-dns)
More details on how to use `repeat_key` and other command argument options can be More details on how to use `repeat_key` and other command argument options can be
found in [this section](11-object-types.md#objecttype-checkcommand-arguments). found in [this section](12-object-types.md#objecttype-checkcommand-arguments).
> **Note** > **Note**
> >
@ -2204,7 +2204,7 @@ a forced service check:
### <a id="external-command-list"></a> External Command List ### <a id="external-command-list"></a> External Command List
A list of currently supported external commands can be found [here](13-appendix.md#external-commands-list-detail). A list of currently supported external commands can be found [here](14-appendix.md#external-commands-list-detail).
Detailed information on the commands and their required parameters can be found 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). on the [Icinga 1.x documentation](http://docs.icinga.org/latest/en/extcommands2.html).
@ -2291,7 +2291,7 @@ You can customize the metric prefix name by using the `host_name_template` and
`service_name_template` configuration attributes. `service_name_template` configuration attributes.
The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a
[global constant](9-language-reference.md#constants) named `GraphiteEnv`. The constant name [global constant](10-language-reference.md#constants) named `GraphiteEnv`. The constant name
is freely definable and should be put in the [constants.conf](2-getting-started.md#constants-conf) file. is freely definable and should be put in the [constants.conf](2-getting-started.md#constants-conf) file.
const GraphiteEnv = "icinga.env1" const GraphiteEnv = "icinga.env1"
@ -2385,7 +2385,7 @@ in Icinga 2 provided with the `CompatLogger` object.
These logs are not only used for informational representation in These logs are not only used for informational representation in
external web interfaces parsing the logs, but also to generate external web interfaces parsing the logs, but also to generate
SLA reports and trends in Icinga 1.x Classic UI. Furthermore the SLA reports and trends in Icinga 1.x Classic UI. Furthermore the
[Livestatus](3-monitoring-basics.md#livestatus) feature uses these logs for answering queries to [Livestatus](#livestatus) feature uses these logs for answering queries to
historical tables. historical tables.
The `CompatLogger` object can be enabled with The `CompatLogger` object can be enabled with
@ -2434,8 +2434,8 @@ 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) Details on the installation can be found in the [Configuring DB IDO](2-getting-started.md#configuring-db-ido)
chapter. Details on the configuration can be found in the chapter. Details on the configuration can be found in the
[IdoMysqlConnection](11-object-types.md#objecttype-idomysqlconnection) and [IdoMysqlConnection](12-object-types.md#objecttype-idomysqlconnection) and
[IdoPgsqlConnection](11-object-types.md#objecttype-idopgsqlconnection) [IdoPgsqlConnection](12-object-types.md#objecttype-idopgsqlconnection)
object configuration documentation. object configuration documentation.
The DB IDO feature supports [High Availability](4-monitoring-remote-systems.md#high-availability-db-ido) in The DB IDO feature supports [High Availability](4-monitoring-remote-systems.md#high-availability-db-ido) in
the Icinga 2 cluster. the Icinga 2 cluster.
@ -2479,7 +2479,7 @@ Example for PostgreSQL:
(1 Zeile) (1 Zeile)
A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](13-appendix.md#schema-db-ido). A detailed list on the available table attributes can be found in the [DB IDO Schema documentation](14-appendix.md#schema-db-ido).
## <a id="check-result-files"></a> Check Result Files ## <a id="check-result-files"></a> Check Result Files

70
doc/4-monitoring-remote-systems.md
View File

@ -24,19 +24,19 @@ monitoring and high-availability, please continue reading in
If the remote service is available using a network protocol and port, If the remote service is available using a network protocol and port,
and a [check plugin](2-getting-started.md#setting-up-check-plugins) is available, you don't and a [check plugin](2-getting-started.md#setting-up-check-plugins) is available, you don't
necessarily need a local client installed. Rather choose a plugin and necessarily need a local client installed. Rather choose a plugin and
configure all parameters and thresholds. The [Icinga 2 Template Library](12-icinga-template-library.md#icinga-template-library) configure all parameters and thresholds. The [Icinga 2 Template Library](13-icinga-template-library.md#icinga-template-library)
already ships various examples like already ships various examples like
* [ping4](12-icinga-template-library.md#plugin-check-command-ping4), [ping6](12-icinga-template-library.md#plugin-check-command-ping6), * [ping4](13-icinga-template-library.md#plugin-check-command-ping4), [ping6](13-icinga-template-library.md#plugin-check-command-ping6),
[fping4](12-icinga-template-library.md#plugin-check-command-fping4), [fping6](12-icinga-template-library.md#plugin-check-command-fping6), [hostalive](12-icinga-template-library.md#plugin-check-command-hostalive) [fping4](13-icinga-template-library.md#plugin-check-command-fping4), [fping6](13-icinga-template-library.md#plugin-check-command-fping6), [hostalive](13-icinga-template-library.md#plugin-check-command-hostalive)
* [tcp](12-icinga-template-library.md#plugin-check-command-tcp), [udp](12-icinga-template-library.md#plugin-check-command-udp), [ssl](12-icinga-template-library.md#plugin-check-command-ssl) * [tcp](13-icinga-template-library.md#plugin-check-command-tcp), [udp](13-icinga-template-library.md#plugin-check-command-udp), [ssl](13-icinga-template-library.md#plugin-check-command-ssl)
* [http](12-icinga-template-library.md#plugin-check-command-http), [ftp](12-icinga-template-library.md#plugin-check-command-ftp) * [http](13-icinga-template-library.md#plugin-check-command-http), [ftp](13-icinga-template-library.md#plugin-check-command-ftp)
* [smtp](12-icinga-template-library.md#plugin-check-command-smtp), [ssmtp](12-icinga-template-library.md#plugin-check-command-ssmtp), * [smtp](13-icinga-template-library.md#plugin-check-command-smtp), [ssmtp](13-icinga-template-library.md#plugin-check-command-ssmtp),
[imap](12-icinga-template-library.md#plugin-check-command-imap), [simap](12-icinga-template-library.md#plugin-check-command-simap), [imap](13-icinga-template-library.md#plugin-check-command-imap), [simap](13-icinga-template-library.md#plugin-check-command-simap),
[pop](12-icinga-template-library.md#plugin-check-command-pop), [spop](12-icinga-template-library.md#plugin-check-command-spop) [pop](13-icinga-template-library.md#plugin-check-command-pop), [spop](13-icinga-template-library.md#plugin-check-command-spop)
* [ntp_time](12-icinga-template-library.md#plugin-check-command-ntp-time) * [ntp_time](13-icinga-template-library.md#plugin-check-command-ntp-time)
* [ssh](12-icinga-template-library.md#plugin-check-command-ssh) * [ssh](13-icinga-template-library.md#plugin-check-command-ssh)
* [dns](12-icinga-template-library.md#plugin-check-command-dns), [dig](12-icinga-template-library.md#plugin-check-command-dig), [dhcp](12-icinga-template-library.md#plugin-check-command-dhcp) * [dns](13-icinga-template-library.md#plugin-check-command-dns), [dig](13-icinga-template-library.md#plugin-check-command-dig), [dhcp](13-icinga-template-library.md#plugin-check-command-dhcp)
There are numerous check plugins contributed by community members available There are numerous check plugins contributed by community members available
on the internet. If you found one for your requirements, [integrate them into Icinga 2](3-monitoring-basics.md#command-plugin-integration). on the internet. If you found one for your requirements, [integrate them into Icinga 2](3-monitoring-basics.md#command-plugin-integration).
@ -348,8 +348,8 @@ This scenario allows you to configure the checkable objects (hosts, services) on
your Icinga 2 master or satellite, and only send commands remotely. your Icinga 2 master or satellite, and only send commands remotely.
Requirements: Requirements:
* Exact same [CheckCommand](11-object-types.md#objecttype-checkcommand) (and * Exact same [CheckCommand](12-object-types.md#objecttype-checkcommand) (and
[EventCommand](11-object-types.md#objecttype-eventcommand)) configuration objects [EventCommand](12-object-types.md#objecttype-eventcommand)) configuration objects
on the master and the remote client(s). on the master and the remote client(s).
* Installed plugin scripts on the remote client (`PluginDir` constant can be locally modified) * Installed plugin scripts on the remote client (`PluginDir` constant can be locally modified)
* `Zone` and `Endpoint` configuration for the client on the master * `Zone` and `Endpoint` configuration for the client on the master
@ -357,7 +357,7 @@ on the master and the remote client(s).
endpoint endpoint
`CheckCommand` objects are already shipped with the Icinga 2 ITL `CheckCommand` objects are already shipped with the Icinga 2 ITL
as [plugin check commands](12-icinga-template-library.md#plugin-check-commands). If you are as [plugin check commands](13-icinga-template-library.md#plugin-check-commands). If you are
using your own configuration definitions for example in using your own configuration definitions for example in
[commands.conf](2-getting-started.md#commands-conf) make sure to copy/sync it [commands.conf](2-getting-started.md#commands-conf) make sure to copy/sync it
on your remote client. on your remote client.
@ -600,7 +600,7 @@ You can `list` and `remove` existing blacklists:
### <a id="icinga2-remote-monitoring-master-manual-add-endpoint-zone"></a> Manually add Client Endpoint and Zone Objects on the Master ### <a id="icinga2-remote-monitoring-master-manual-add-endpoint-zone"></a> Manually add Client Endpoint and Zone Objects on the Master
Define a [Zone](11-object-types.md#objecttype-zone) with a new [Endpoint](11-object-types.md#objecttype-endpoint) similar to the cluster setup. Define a [Zone](12-object-types.md#objecttype-zone) with a new [Endpoint](12-object-types.md#objecttype-endpoint) similar to the cluster setup.
* [configure the node name](4-monitoring-remote-systems.md#configure-nodename) * [configure the node name](4-monitoring-remote-systems.md#configure-nodename)
* [configure the ApiListener object](4-monitoring-remote-systems.md#configure-apilistener-object) * [configure the ApiListener object](4-monitoring-remote-systems.md#configure-apilistener-object)
@ -625,7 +625,7 @@ binaries. The [Monitoring Plugins package](2-getting-started.md#setting-up-check
the `check_snmp` plugin binary, but there are plenty of [existing plugins](6-addons-plugins.md#plugins) the `check_snmp` plugin binary, but there are plenty of [existing plugins](6-addons-plugins.md#plugins)
for specific use cases already around, for example monitoring Cisco routers. for specific use cases already around, for example monitoring Cisco routers.
The following example uses the [SNMP ITL](12-icinga-template-library.md#plugin-check-command-snmp) `CheckCommand` and just The following example uses the [SNMP ITL](13-icinga-template-library.md#plugin-check-command-snmp) `CheckCommand` and just
overrides the `snmp_oid` custom attribute. A service is created for all hosts which overrides the `snmp_oid` custom attribute. A service is created for all hosts which
have the `snmp-community` custom attribute. have the `snmp-community` custom attribute.
@ -638,7 +638,7 @@ have the `snmp-community` custom attribute.
assign where host.vars.snmp_community != "" assign where host.vars.snmp_community != ""
} }
Additional SNMP plugins are available using the [Manubulon SNMP Plugins](12-icinga-template-library.md#snmp-manubulon-plugin-check-commands). Additional SNMP plugins are available using the [Manubulon SNMP Plugins](13-icinga-template-library.md#snmp-manubulon-plugin-check-commands).
### <a id="agent-based-checks-ssh"></a> SSH ### <a id="agent-based-checks-ssh"></a> SSH
@ -683,7 +683,7 @@ The NRPE daemon uses its own configuration format in nrpe.cfg while `check_nrpe`
can be embedded into the Icinga 2 `CheckCommand` configuration syntax. can be embedded into the Icinga 2 `CheckCommand` configuration syntax.
You can use the `check_nrpe` plugin from the NRPE project to query the NRPE daemon. You can use the `check_nrpe` plugin from the NRPE project to query the NRPE daemon.
Icinga 2 provides the [nrpe check command](12-icinga-template-library.md#plugin-check-command-nrpe) for this: Icinga 2 provides the [nrpe check command](13-icinga-template-library.md#plugin-check-command-nrpe) for this:
Example: Example:
@ -753,7 +753,7 @@ but using `NSClient++` will allow you to run local scripts similar to check plug
the required output and performance counters. the required output and performance counters.
You can use the `check_nt` plugin from the Monitoring Plugins project to query NSClient++. You can use the `check_nt` plugin from the Monitoring Plugins project to query NSClient++.
Icinga 2 provides the [nscp check command](12-icinga-template-library.md#plugin-check-command-nscp) for this: Icinga 2 provides the [nscp check command](13-icinga-template-library.md#plugin-check-command-nscp) for this:
Example: Example:
@ -789,7 +789,7 @@ SNMP Traps can be received and filtered by using [SNMPTT](http://snmptt.sourcefo
and specific trap handlers passing the check results to Icinga 2. and specific trap handlers passing the check results to Icinga 2.
Following the SNMPTT [Format](http://snmptt.sourceforge.net/docs/snmptt.shtml#SNMPTT.CONF-FORMAT) Following the SNMPTT [Format](http://snmptt.sourceforge.net/docs/snmptt.shtml#SNMPTT.CONF-FORMAT)
documentation and the Icinga external command syntax found [here](13-appendix.md#external-commands-list-detail) documentation and the Icinga external command syntax found [here](14-appendix.md#external-commands-list-detail)
we can create generic services that can accommodate any number of hosts for a given scenario. we can create generic services that can accommodate any number of hosts for a given scenario.
#### <a id="simple-traps"></a> Simple SNMP Traps #### <a id="simple-traps"></a> Simple SNMP Traps
@ -1005,7 +1005,7 @@ Before you start deploying, keep the following things in mind:
> **Tip** > **Tip**
> >
> If you're looking for troubleshooting cluster problems, check the general > If you're looking for troubleshooting cluster problems, check the general
> [troubleshooting](7-troubleshooting.md#troubleshooting-cluster) section. > [troubleshooting](8-troubleshooting.md#troubleshooting-cluster) section.
### <a id="manual-certificate-generation"></a> Manual SSL Certificate Generation ### <a id="manual-certificate-generation"></a> Manual SSL Certificate Generation
@ -1053,8 +1053,8 @@ the host's FQDN):
#### <a id="cluster-naming-convention"></a> Cluster Naming Convention #### <a id="cluster-naming-convention"></a> Cluster Naming Convention
The SSL certificate common name (CN) will be used by the [ApiListener](11-object-types.md#objecttype-apilistener) The SSL certificate common name (CN) will be used by the [ApiListener](12-object-types.md#objecttype-apilistener)
object to determine the local authority. This name must match the local [Endpoint](11-object-types.md#objecttype-endpoint) object to determine the local authority. This name must match the local [Endpoint](12-object-types.md#objecttype-endpoint)
object name. object name.
Example: Example:
@ -1068,8 +1068,8 @@ Example:
host = "icinga2a.icinga.org" host = "icinga2a.icinga.org"
} }
The [Endpoint](11-object-types.md#objecttype-endpoint) name is further referenced as `endpoints` attribute on the The [Endpoint](12-object-types.md#objecttype-endpoint) name is further referenced as `endpoints` attribute on the
[Zone](11-object-types.md#objecttype-zone) object. [Zone](12-object-types.md#objecttype-zone) object.
object Endpoint "icinga2b" { object Endpoint "icinga2b" {
host = "icinga2b.icinga.org" host = "icinga2b.icinga.org"
@ -1102,7 +1102,7 @@ and configure [cluster scenarios](4-monitoring-remote-systems.md#cluster-scenari
#### <a id="configure-nodename"></a> Configure the Icinga Node Name #### <a id="configure-nodename"></a> Configure the Icinga Node Name
Instead of using the default FQDN as node name you can optionally set Instead of using the default FQDN as node name you can optionally set
that value using the [NodeName](9-language-reference.md#constants) constant. that value using the [NodeName](10-language-reference.md#constants) constant.
> ** Note ** > ** Note **
> >
@ -1110,7 +1110,7 @@ that value using the [NodeName](9-language-reference.md#constants) constant.
> in `/etc/icinga2/constants.conf`. > in `/etc/icinga2/constants.conf`.
This setting must be unique for each node, and must also match This setting must be unique for each node, and must also match
the name of the local [Endpoint](11-object-types.md#objecttype-endpoint) object and the the name of the local [Endpoint](12-object-types.md#objecttype-endpoint) object and the
SSL certificate common name as described in the SSL certificate common name as described in the
[cluster naming convention](4-monitoring-remote-systems.md#cluster-naming-convention). [cluster naming convention](4-monitoring-remote-systems.md#cluster-naming-convention).
@ -1129,7 +1129,7 @@ configured endpoint names and common names are in sync.
#### <a id="configure-apilistener-object"></a> Configure the ApiListener Object #### <a id="configure-apilistener-object"></a> Configure the ApiListener Object
The [ApiListener](11-object-types.md#objecttype-apilistener) object needs to be configured on The [ApiListener](12-object-types.md#objecttype-apilistener) object needs to be configured on
every node in the cluster with the following settings: every node in the cluster with the following settings:
A sample config looks like: A sample config looks like:
@ -1278,7 +1278,7 @@ process.
> >
> `zones.d` must not be included in [icinga2.conf](2-getting-started.md#icinga2-conf). Icinga 2 automatically > `zones.d` must not be included in [icinga2.conf](2-getting-started.md#icinga2-conf). Icinga 2 automatically
> determines the required include directory. This can be overridden using the > determines the required include directory. This can be overridden using the
> [global constant](9-language-reference.md#constants) `ZonesDir`. > [global constant](10-language-reference.md#constants) `ZonesDir`.
#### <a id="zone-global-config-templates"></a> Global Configuration Zone for Templates #### <a id="zone-global-config-templates"></a> Global Configuration Zone for Templates
@ -1325,7 +1325,7 @@ If you don't require any global configuration, skip this setting.
#### <a id="zone-config-sync-permissions"></a> Zone Configuration Synchronisation Permissions #### <a id="zone-config-sync-permissions"></a> Zone Configuration Synchronisation Permissions
Each [ApiListener](11-object-types.md#objecttype-apilistener) object must have the `accept_config` attribute Each [ApiListener](12-object-types.md#objecttype-apilistener) object must have the `accept_config` attribute
set to `true` to receive configuration from the parent `Zone` members. Default value is `false`. set to `true` to receive configuration from the parent `Zone` members. Default value is `false`.
object ApiListener "api" { object ApiListener "api" {
@ -1340,13 +1340,13 @@ master instances anymore.
> ** Tip ** > ** Tip **
> >
> Look into the [troubleshooting guides](7-troubleshooting.md#troubleshooting-cluster-config-sync) for debugging > Look into the [troubleshooting guides](8-troubleshooting.md#troubleshooting-cluster-config-sync) for debugging
> problems with the configuration synchronisation. > problems with the configuration synchronisation.
### <a id="cluster-health-check"></a> Cluster Health Check ### <a id="cluster-health-check"></a> Cluster Health Check
The Icinga 2 [ITL](12-icinga-template-library.md#icinga-template-library) ships an internal check command checking all configured The Icinga 2 [ITL](13-icinga-template-library.md#icinga-template-library) ships an internal check command checking all configured
`EndPoints` in the cluster setup. The check result will become critical if `EndPoints` in the cluster setup. The check result will become critical if
one or more configured nodes are not connected. one or more configured nodes are not connected.
@ -1633,7 +1633,7 @@ Notifications are load balanced amongst all nodes in a zone. By default this fun
is enabled. is enabled.
If your nodes should notify independent from any other nodes (this will cause If your nodes should notify independent from any other nodes (this will cause
duplicated notifications if not properly handled!), you can set `enable_ha = false` duplicated notifications if not properly handled!), you can set `enable_ha = false`
in the [NotificationComponent](11-object-types.md#objecttype-notificationcomponent) feature. in the [NotificationComponent](12-object-types.md#objecttype-notificationcomponent) feature.
#### <a id="high-availability-db-ido"></a> High Availability with DB IDO #### <a id="high-availability-db-ido"></a> High Availability with DB IDO
@ -1651,8 +1651,8 @@ nodes disable the active IDO database connection at runtime.
> **Note** > **Note**
> >
> The DB IDO HA feature can be disabled by setting the `enable_ha` attribute to `false` > The DB IDO HA feature can be disabled by setting the `enable_ha` attribute to `false`
> for the [IdoMysqlConnection](11-object-types.md#objecttype-idomysqlconnection) or > for the [IdoMysqlConnection](12-object-types.md#objecttype-idomysqlconnection) or
> [IdoPgsqlConnection](11-object-types.md#objecttype-idopgsqlconnection) object on all nodes in the > [IdoPgsqlConnection](12-object-types.md#objecttype-idopgsqlconnection) object on all nodes in the
> same zone. > same zone.
> >
> All endpoints will enable the DB IDO feature then, connect to the configured > All endpoints will enable the DB IDO feature then, connect to the configured

14
doc/5-cli-commands.md
View File

@ -105,12 +105,12 @@ Debian/Ubuntu:
#### Libraries #### Libraries
Instead of loading libraries using the [`library` config directive](9-language-reference.md#library) Instead of loading libraries using the [`library` config directive](10-language-reference.md#library)
you can also use the `--library` command-line option. you can also use the `--library` command-line option.
#### Constants #### Constants
[Global constants](9-language-reference.md#constants) can be set using the `--define` command-line option. [Global constants](10-language-reference.md#constants) can be set using the `--define` command-line option.
#### <a id="config-include-path"> Config Include Path #### <a id="config-include-path"> Config Include Path
@ -240,9 +240,9 @@ nodes in a [remote monitoring ](4-monitoring-remote-systems.md#icinga2-remote-cl
The `object` CLI command can be used to list all configuration objects and their The `object` CLI command can be used to list all configuration objects and their
attributes. The command also shows where each of the attributes was modified. attributes. The command also shows where each of the attributes was modified.
That way you can also identify which objects have been created from your [apply rules](9-language-reference.md#apply). That way you can also identify which objects have been created from your [apply rules](10-language-reference.md#apply).
More information can be found in the [troubleshooting](7-troubleshooting.md#list-configuration-objects) section. More information can be found in the [troubleshooting](8-troubleshooting.md#list-configuration-objects) section.
# icinga2 object --help # icinga2 object --help
icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275) icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
@ -484,12 +484,12 @@ Or manually passing the `-C` argument:
> `# icinga2 daemon -C` > `# icinga2 daemon -C`
If you encouter errors during configuration validation, please make sure If you encouter errors during configuration validation, please make sure
to read the [troubleshooting](7-troubleshooting.md#troubleshooting) chapter. to read the [troubleshooting](8-troubleshooting.md#troubleshooting) chapter.
You can also use the [CLI command](5-cli-commands.md#cli-command-object) `icinga2 object list` You can also use the [CLI command](5-cli-commands.md#cli-command-object) `icinga2 object list`
after validation passes to analyze object attributes, inheritance or created after validation passes to analyze object attributes, inheritance or created
objects by apply rules. objects by apply rules.
Find more on troubleshooting with `object list` in [this chapter](7-troubleshooting.md#list-configuration-objects). Find more on troubleshooting with `object list` in [this chapter](8-troubleshooting.md#list-configuration-objects).
Example filtered by `Service` objects with the name `ping*`: Example filtered by `Service` objects with the name `ping*`:
@ -533,5 +533,5 @@ safely reload the Icinga 2 daemon.
> which will validate the configuration in a separate process and not stop > which will validate the configuration in a separate process and not stop
> the other events like check execution, notifications, etc. > the other events like check execution, notifications, etc.
> >
> Details can be found [here](8-migrating-from-icinga-1x.md#differences-1x-2-real-reload). > Details can be found [here](9-migrating-from-icinga-1x.md#differences-1x-2-real-reload).

12
doc/6-addons-plugins.md
View File

@ -39,7 +39,7 @@ based on your monitoring configuration and status data using [NagVis](http://www
As well as the Icinga supported web interfaces (Classic UI 1.x, Web 1.x, Web 2) there are a As well as the Icinga supported web interfaces (Classic UI 1.x, Web 1.x, Web 2) there are a
number of community provided web interfaces too: number of community provided web interfaces too:
* [Thruk](http://www.thruk.org) based on the [Livestatus](3-monitoring-basics.md#livestatus) feature * [Thruk](http://www.thruk.org) based on the [Livestatus](#livestatus) feature
## <a id="plugins"></a> Plugins ## <a id="plugins"></a> Plugins
@ -81,9 +81,9 @@ documentation and/or plugin provided README for installation instructions.
Sometimes plugins contain hard-coded paths to other components. Instead of changing Sometimes plugins contain hard-coded paths to other components. Instead of changing
the plugin it might be easier to create logical links which is (more) update-safe. the plugin it might be easier to create logical links which is (more) update-safe.
Each plugin requires a [CheckCommand](11-object-types.md#objecttype-checkcommand) object in your Each plugin requires a [CheckCommand](12-object-types.md#objecttype-checkcommand) object in your
configuration which can be used in the [Service](11-object-types.md#objecttype-service) or configuration which can be used in the [Service](12-object-types.md#objecttype-service) or
[Host](11-object-types.md#objecttype-host) object definition. [Host](12-object-types.md#objecttype-host) object definition.
There are the following conventions to follow when adding a new command object definition: There are the following conventions to follow when adding a new command object definition:
@ -93,7 +93,7 @@ in `[ ... ]` then for shell escaping.
* Define a unique `prefix` for the command's specific command arguments. That way you can safely * Define a unique `prefix` for the command's specific command arguments. That way you can safely
set them on host/service level and you'll always know which command they control. set them on host/service level and you'll always know which command they control.
* Use command argument default values, e.g. for thresholds * Use command argument default values, e.g. for thresholds
* Use [advanced conditions](11-object-types.md#objecttype-checkcommand) like `set_if` definitions. * Use [advanced conditions](12-object-types.md#objecttype-checkcommand) like `set_if` definitions.
Example for a custom `my-snmp-int` check command: Example for a custom `my-snmp-int` check command:
@ -124,7 +124,7 @@ Example for a custom `my-snmp-int` check command:
} }
You can find an existing `CheckCommand` definition for the `check_snmp_int.pl` plugin You can find an existing `CheckCommand` definition for the `check_snmp_int.pl` plugin
shipped with the optional [Manubulon Plugin Check Command](12-icinga-template-library.md#snmp-manubulon-plugin-check-commands) shipped with the optional [Manubulon Plugin Check Command](13-icinga-template-library.md#snmp-manubulon-plugin-check-commands)
definitions already. definitions already.

12
doc/7-livestatus.md
View File

@ -16,7 +16,7 @@ re-implementation of the Livestatus protocol which is compatible with MK
Livestatus. Livestatus.
Details on the available tables and attributes with Icinga 2 can be found Details on the available tables and attributes with Icinga 2 can be found
in the [Livestatus](3-monitoring-basics.md#livestatus) section. in the [Livestatus](#livestatus) section.
You can enable Livestatus using icinga2 feature enable: You can enable Livestatus using icinga2 feature enable:
@ -59,7 +59,7 @@ Other to the Icinga 1.x Addon, Icinga 2 supports two socket types
* Unix socket (default) * Unix socket (default)
* TCP socket * TCP socket
Details on the configuration can be found in the [LivestatusListener](11-object-types.md#objecttype-livestatuslistener) Details on the configuration can be found in the [LivestatusListener](12-object-types.md#objecttype-livestatuslistener)
object configuration. object configuration.
### <a id="livestatus-get-queries"></a> Livestatus GET Queries ### <a id="livestatus-get-queries"></a> Livestatus GET Queries
@ -92,7 +92,7 @@ Example using the tcp socket listening on port `6558`:
### <a id="livestatus-command-queries"></a> Livestatus COMMAND Queries ### <a id="livestatus-command-queries"></a> Livestatus COMMAND Queries
A list of available external commands and their parameters can be found [here](13-appendix.md#external-commands-list-detail) A list of available external commands and their parameters can be found [here](14-appendix.md#external-commands-list-detail)
$ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558 $ echo -e 'COMMAND <externalcommandstring>' | netcat 127.0.0.1 6558
@ -185,10 +185,10 @@ Default separators.
downtimes | services | status attributes downtimes | services | status attributes
timeperiods | &nbsp; | name and is inside flag timeperiods | &nbsp; | name and is inside flag
endpoints | &nbsp; | config and status attributes endpoints | &nbsp; | config and status attributes
log | services, hosts, contacts, commands | parses [compatlog](11-object-types.md#objecttype-compatlogger) and shows log attributes log | services, hosts, contacts, commands | parses [compatlog](12-object-types.md#objecttype-compatlogger) and shows log attributes
statehist | hosts, services | parses [compatlog](11-object-types.md#objecttype-compatlogger) and aggregates state change attributes statehist | hosts, services | parses [compatlog](12-object-types.md#objecttype-compatlogger) and aggregates state change attributes
The `commands` table is populated with `CheckCommand`, `EventCommand` and `NotificationCommand` objects. 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](13-appendix.md#schema-livestatus). A detailed list on the available table attributes can be found in the [Livestatus Schema documentation](14-appendix.md#schema-livestatus).

10
doc/8-troubleshooting.md
View File

@ -8,7 +8,7 @@
* Provide complete configuration snippets explaining your problem in detail * Provide complete configuration snippets explaining your problem in detail
* Provide complete logs targetting your problem * Provide complete logs targetting your problem
* If the check command failed - what's the output of your manual plugin tests? * If the check command failed - what's the output of your manual plugin tests?
* In case of [debugging](7-troubleshooting.md#debug) Icinga 2, the full back traces and outputs * In case of [debugging](8-troubleshooting.md#debug) Icinga 2, the full back traces and outputs
## <a id="troubleshooting-enable-debug-output"></a> Enable Debug Output ## <a id="troubleshooting-enable-debug-output"></a> Enable Debug Output
@ -32,7 +32,7 @@ You can find the debug log file in `/var/log/icinga2/debug.log`.
The `icinga2 object list` CLI command can be used to list all configuration objects and their The `icinga2 object list` CLI command can be used to list all configuration objects and their
attributes. The tool also shows where each of the attributes was modified. attributes. The tool also shows where each of the attributes was modified.
That way you can also identify which objects have been created from your [apply rules](9-language-reference.md#apply). That way you can also identify which objects have been created from your [apply rules](10-language-reference.md#apply).
# icinga2 object list # icinga2 object list
@ -91,7 +91,7 @@ You can also filter by name and type:
## <a id="check-command-definitions"></a> Where are the check command definitions? ## <a id="check-command-definitions"></a> Where are the check command definitions?
Icinga 2 ships additional [plugin check command definitions](12-icinga-template-library.md#plugin-check-commands) which are Icinga 2 ships additional [plugin check command definitions](13-icinga-template-library.md#plugin-check-commands) which are
included using included using
include <itl> include <itl>
@ -152,13 +152,13 @@ to `features-enabled` and that the latter is included in [icinga2.conf](2-gettin
## <a id="configuration-ignored"></a> Configuration is ignored ## <a id="configuration-ignored"></a> Configuration is ignored
* Make sure that the line(s) are not [commented out](9-language-reference.md#comments) (starting with `//` or `#`, or * Make sure that the line(s) are not [commented out](10-language-reference.md#comments) (starting with `//` or `#`, or
encapsulated by `/* ... */`). encapsulated by `/* ... */`).
* Is the configuration file included in [icinga2.conf](2-getting-started.md#icinga2-conf)? * Is the configuration file included in [icinga2.conf](2-getting-started.md#icinga2-conf)?
## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from ## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from
Icinga 2 allows you to import templates using the [import](9-language-reference.md#template-imports) keyword. If these templates Icinga 2 allows you to import templates using the [import](10-language-reference.md#template-imports) keyword. If these templates
contain additional attributes, your objects will automatically inherit them. You can override contain additional attributes, your objects will automatically inherit them. You can override
or modify these attributes in the current object. or modify these attributes in the current object.

28
doc/9-migrating-from-icinga-1x.md
View File

@ -27,7 +27,7 @@ If you encounter a bug, please open an issue at https://dev.icinga.org.
For a long-term migration of your configuration you should consider re-creating For a long-term migration of your configuration you should consider re-creating
your configuration based on the proposed Icinga 2 configuration paradigm. your configuration based on the proposed Icinga 2 configuration paradigm.
Please read the [next chapter](8-migrating-from-icinga-1x.md#differences-1x-2) to find out more about the differences Please read the [next chapter](9-migrating-from-icinga-1x.md#differences-1x-2) to find out more about the differences
between 1.x and 2. between 1.x and 2.
### <a id="manual-config-migration-hints"></a> Manual Config Migration Hints ### <a id="manual-config-migration-hints"></a> Manual Config Migration Hints
@ -39,7 +39,7 @@ Icinga 1.x configuration.
The examples are taken from Icinga 1.x test and production environments and converted The examples are taken from Icinga 1.x test and production environments and converted
straight into a possible Icinga 2 format. If you found a different strategy, send a patch! straight into a possible Icinga 2 format. If you found a different strategy, send a patch!
If you require in-depth explanations, please check the [next chapter](8-migrating-from-icinga-1x.md#differences-1x-2). If you require in-depth explanations, please check the [next chapter](9-migrating-from-icinga-1x.md#differences-1x-2).
#### <a id="manual-config-migration-hints-Intervals"></a> Manual Config Migration Hints for Intervals #### <a id="manual-config-migration-hints-Intervals"></a> Manual Config Migration Hints for Intervals
@ -127,7 +127,7 @@ a member and includes all members of the `hg1` hostgroup.
hostgroup_members hg1 hostgroup_members hg1
} }
This can be migrated to Icinga 2 and [using group assign](9-language-reference.md#group-assign). The additional nested hostgroup This can be migrated to Icinga 2 and [using group assign](10-language-reference.md#group-assign). The additional nested hostgroup
`hg1` is included into `hg2` with the `groups` attribute. `hg1` is included into `hg2` with the `groups` attribute.
@ -217,8 +217,8 @@ directory - one major problem solved.
For the check command it is required to For the check command it is required to
* Escape all double quotes with an additional `\`. * Escape all double quotes with an additional `\`.
* Replace all [runtime macros](8-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-macros), e.g. `$HOSTADDRESS$` with `$address$`. * Replace all [runtime macros](9-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-macros), e.g. `$HOSTADDRESS$` with `$address$`.
* Replace [custom variable macros](8-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-custom-attributes) if any. * Replace [custom variable macros](9-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-custom-attributes) if any.
* Keep `$ARGn$` macros. * Keep `$ARGn$` macros.
The final check command looks like this in Icinga2: The final check command looks like this in Icinga2:
@ -257,7 +257,7 @@ That way the old command arguments fashion can be applied for Icinga 2, although
#### <a id="manual-config-migration-hints-runtime-macros"></a> Manual Config Migration Hints for Runtime Macros #### <a id="manual-config-migration-hints-runtime-macros"></a> Manual Config Migration Hints for Runtime Macros
Runtime macros have been renamed. A detailed comparison table can be found [here](8-migrating-from-icinga-1x.md#differences-1x-2-runtime-macros). Runtime macros have been renamed. A detailed comparison table can be found [here](9-migrating-from-icinga-1x.md#differences-1x-2-runtime-macros).
For example, accessing the service check output looks like the following in Icinga 1.x: For example, accessing the service check output looks like the following in Icinga 1.x:
@ -318,7 +318,7 @@ while the service check command resolves its value to the service attribute attr
#### <a id="manual-config-migration-hints-contacts-users"></a> Manual Config Migration Hints for Contacts (Users) #### <a id="manual-config-migration-hints-contacts-users"></a> Manual Config Migration Hints for Contacts (Users)
Contacts in Icinga 1.x act as users in Icinga 2, but do not have any notification commands specified. Contacts in Icinga 1.x act as users in Icinga 2, but do not have any notification commands specified.
This migration part is explained in the [next chapter](8-migrating-from-icinga-1x.md#manual-config-migration-hints-notifications). This migration part is explained in the [next chapter](9-migrating-from-icinga-1x.md#manual-config-migration-hints-notifications).
define contact{ define contact{
contact_name testconfig-user contact_name testconfig-user
@ -328,7 +328,7 @@ This migration part is explained in the [next chapter](8-migrating-from-icinga-1
email icinga@localhost email icinga@localhost
} }
The `service_notification_options` can be [mapped](8-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters) The `service_notification_options` can be [mapped](9-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters)
into generic `state` and `type` filters, if additional notification filtering is required. `alias` gets into generic `state` and `type` filters, if additional notification filtering is required. `alias` gets
renamed to `display_name`. renamed to `display_name`.
@ -380,7 +380,7 @@ Assign it to the host or service and set the newly generated notification comman
Convert the `notification_options` attribute from Icinga 1.x to Icinga 2 `states` and `types`. Details Convert the `notification_options` attribute from Icinga 1.x to Icinga 2 `states` and `types`. Details
[here](8-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters). Add the notification period. [here](9-migrating-from-icinga-1x.md#manual-config-migration-hints-notification-filters). Add the notification period.
states = [ OK, Warning, Critical ] states = [ OK, Warning, Critical ]
types = [ Recovery, Problem, Custom ] types = [ Recovery, Problem, Custom ]
@ -617,7 +617,7 @@ enabled.
assign where "hg_svcdep2" in host.groups assign where "hg_svcdep2" in host.groups
} }
Host dependencies are explained in the [next chapter](8-migrating-from-icinga-1x.md#manual-config-migration-hints-host-parents). Host dependencies are explained in the [next chapter](9-migrating-from-icinga-1x.md#manual-config-migration-hints-host-parents).
@ -773,7 +773,7 @@ included in `icinga2.conf` by default.
### <a id="differences-1x-2-main-config"></a> Main Config File ### <a id="differences-1x-2-main-config"></a> Main Config File
In Icinga 1.x there are many global configuration settings available in `icinga.cfg`. In Icinga 1.x there are many global configuration settings available in `icinga.cfg`.
Icinga 2 only uses a small set of [global constants](9-language-reference.md#constants) allowing Icinga 2 only uses a small set of [global constants](10-language-reference.md#constants) allowing
you to specify certain different setting such as the `NodeName` in a cluster scenario. you to specify certain different setting such as the `NodeName` in a cluster scenario.
Aside from that, the [icinga2.conf](2-getting-started.md#icinga2-conf) should take care of including Aside from that, the [icinga2.conf](2-getting-started.md#icinga2-conf) should take care of including
@ -826,7 +826,7 @@ set in the `constants.conf` configuration file:
const PluginDir = "/usr/lib/nagios/plugins" const PluginDir = "/usr/lib/nagios/plugins"
[Global macros](9-language-reference.md#constants) can only be defined once. Trying to modify a [Global macros](10-language-reference.md#constants) can only be defined once. Trying to modify a
global constant will result in an error. global constant will result in an error.
### <a id="differences-1x-2-configuration-comments"></a> Configuration Comments ### <a id="differences-1x-2-configuration-comments"></a> Configuration Comments
@ -1251,7 +1251,7 @@ timeout. This was essentially bad when there only was a couple of check plugins
requiring some command timeouts to be extended. requiring some command timeouts to be extended.
Icinga 2 allows you to specify the command timeout directly on the command. So Icinga 2 allows you to specify the command timeout directly on the command. So
if your VMVware check plugin takes 15 minutes, [increase the timeout](11-object-types.md#objecttype-checkcommand) if your VMVware check plugin takes 15 minutes, [increase the timeout](12-object-types.md#objecttype-checkcommand)
accordingly. accordingly.
@ -1386,7 +1386,7 @@ child attributes may be omitted.
For detailed examples on how to use the dependencies please check the [dependencies](3-monitoring-basics.md#dependencies) For detailed examples on how to use the dependencies please check the [dependencies](3-monitoring-basics.md#dependencies)
chapter. chapter.
Dependencies can be applied to hosts or services using the [apply rules](9-language-reference.md#apply). Dependencies can be applied to hosts or services using the [apply rules](10-language-reference.md#apply).
The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types The `StatusDataWriter`, `IdoMysqlConnection` and `LivestatusListener` types
support the Icinga 1.x schema with dependencies and parent attributes for support the Icinga 1.x schema with dependencies and parent attributes for

2
doc/update-links.py
View File

@ -51,5 +51,5 @@ def update_anchor(match):
for file in sys.argv[1:]: for file in sys.argv[1:]:
text = open(file).read() text = open(file).read()
new_text = re.sub(r"\[(?P<text>.*)\]\((?P<file>[0-9-[a-z]\.]+)?#(?P<id>[^#\)]+)\)", update_anchor, text) new_text = re.sub(r"\[(?P<text>.*?)\]\((?P<file>[0-9-a-z\.]+)?#(?P<id>[^#\)]+)\)", update_anchor, text)
open(file, "w").write(new_text) open(file, "w").write(new_text)