tyler.durden
/
icinga2
mirror of https://github.com/Icinga/icinga2.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update documentation links

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.
* 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
@ -88,10 +88,10 @@ event handlers remotely.
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.
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
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.
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.
@ -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
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.
@ -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
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
[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
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
[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).
Supported with [duration literals](9-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
pattern and regex matching and (global) [constants](9-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).
Supported with [duration literals](10-language-reference.md#duration-literals) for interval
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](10-language-reference.md#constants).
[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
@ -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
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.
[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.
* Dependencies between Hosts and Services
@ -183,7 +183,7 @@ objects and specify their active time window.
* 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.
* 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.
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.
[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.
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

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

@ -188,7 +188,7 @@ Functions can be called using the `()` operator:
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
@ -383,7 +383,7 @@ another group of objects.
In this example the `assign where` condition is a boolean expression which is
evaluated for all objects of type `Host` and a new service with name "ping"
is created for each matching host. [Expression operators](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.
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
for all objects of the type `Host`. Each matching host is added as member to the host group
with the name "linux-servers". Membership exclusion can be controlled using the `ignore where`
condition. [Expression operators](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.
Source Type | Variables
@ -449,7 +449,7 @@ Empty dictionary | {} | false
Non-empty dictionary | { key = "value" } | true
For a list of supported expression operators for `assign where` and `ignore where`
statements, see [expression operators](9-language-reference.md#expression-operators).
statements, see [expression operators](10-language-reference.md#expression-operators).
## <a id="comments"></a> Comments

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

@ -59,7 +59,7 @@ A group of hosts.
> **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:
@ -145,7 +145,7 @@ A group of services.
> **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:
@ -224,7 +224,7 @@ A user group.
> **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:
@ -398,7 +398,7 @@ Attributes:
zone |**Optional.** The zone this object is a member of.
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
@ -425,7 +425,7 @@ Attributes:
timeout |**Optional.** The command timeout in seconds. Defaults to 60 seconds.
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
@ -737,7 +737,7 @@ Attributes:
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"

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
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
@ -192,7 +192,7 @@ Here's a brief description of the example configuration:
* to the documentation that is distributed as part of Icinga 2.
*/
Icinga 2 supports [C/C++-style comments](9-language-reference.md#comments).
Icinga 2 supports [C/C++-style comments](10-language-reference.md#comments).
/**
* 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.
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
if not set. This constant is required for local host configuration, monitoring remote clients and
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.
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.
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**
>
> 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
> that in detail.
#### <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
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 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`,
`users` and `disk` are all provided by the [Plugin Check Commands](12-icinga-template-library.md#plugin-check-commands)
[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](13-icinga-template-library.md#plugin-check-commands)
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
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.
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
`Linux`.
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")`.
@ -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.
* call `apply` on each, and set the service object name from the provided key
* 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
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.
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
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**
>
> 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
> that topic in the [troubleshooting section](7-troubleshooting.md#check-command-definitions).
> [Plugin Check Commands](13-icinga-template-library.md#plugin-check-commands) definitions. More details on
> 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.
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
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).
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.
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.
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
[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" {
@ -725,7 +725,7 @@ The `hostalive` check command is shipped with Icinga 2 in the
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
@ -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 `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.
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
database credentials in this file.
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`:
@ -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
database credentials in this file.
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`:
@ -1102,7 +1102,7 @@ Icinga 2 also is compatible with Icinga 1.x user interfaces
by providing additional features required as backends.
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.
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
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
@ -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
[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)
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
@ -213,18 +213,18 @@ Example for importing objects:
### <a id="using-apply"></a> Apply objects based on rules
Instead of assigning each object ([Service](11-object-types.md#objecttype-service),
[Notification](11-object-types.md#objecttype-notification), [Dependency](11-object-types.md#objecttype-dependency),
[ScheduledDowntime](11-object-types.md#objecttype-scheduleddowntime))
based on attribute identifiers for example `host_name` objects can be [applied](9-language-reference.md#apply).
Instead of assigning each object ([Service](12-object-types.md#objecttype-service),
[Notification](12-object-types.md#objecttype-notification), [Dependency](12-object-types.md#objecttype-dependency),
[ScheduledDowntime](12-object-types.md#objecttype-scheduleddowntime))
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:
* Define the best match.
* 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?
* A generic pattern [match](9-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)
* 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](10-language-reference.md#expression-operators)
* All expressions must return a boolean value (an empty string is equal to `false` e.g.)
> **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`.
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" {
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.
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**
>
@ -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
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" {
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`
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**
>
@ -886,11 +886,11 @@ Please check [Runtime Custom Attributes as Environment Variables](3-monitoring-b
### <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.
[CheckCommand](11-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
[CheckCommand](12-object-types.md#objecttype-checkcommand) objects are referenced by
[Host](12-object-types.md#objecttype-host) and [Service](12-object-types.md#objecttype-service) objects
using the `check_command` attribute.
> **Note**
@ -900,7 +900,7 @@ using the `check_command` attribute.
#### <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.
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.
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.
#### <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**
>
> 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
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.
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
@ -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
[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 `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
@ -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
[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).
[NotificationCommand](11-object-types.md#objecttype-notificationcommand) objects are referenced by
[Notification](11-object-types.md#objecttype-notification) objects using the `command` attribute.
[NotificationCommand](12-object-types.md#objecttype-notificationcommand) objects are referenced by
[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.
> **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 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
[Host](11-object-types.md#objecttype-host) and [Service](11-object-types.md#objecttype-service) objects
[EventCommand](12-object-types.md#objecttype-eventcommand) objects are referenced by
[Host](12-object-types.md#objecttype-host) and [Service](12-object-types.md#objecttype-service) objects
using the `event_command` attribute.
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
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:
/* pass event commands through ssh */
@ -1370,7 +1370,7 @@ Remote Host Terminal:
## <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.
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.
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
@ -1657,7 +1657,7 @@ downtime on NOT-OK state change.
### <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.
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):
* As simple attribute literal ([number](9-language-reference.md#numeric-literals), [string](9-language-reference.md#string-literals),
[boolean](9-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 simple attribute literal ([number](10-language-reference.md#numeric-literals), [string](10-language-reference.md#string-literals),
[boolean](10-language-reference.md#boolean-literals)) for expression conditions (`assign where`, `ignore where`)
* 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.
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**
>
> 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
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
plugin examples are:
* [check_disk -p](12-icinga-template-library.md#plugin-check-command-disk)
* [check_nrpe -a](12-icinga-template-library.md#plugin-check-command-nrpe)
* [check_nscp -l](12-icinga-template-library.md#plugin-check-command-nscp)
* [check_dns -a](12-icinga-template-library.md#plugin-check-command-dns)
* [check_disk -p](13-icinga-template-library.md#plugin-check-command-disk)
* [check_nrpe -a](13-icinga-template-library.md#plugin-check-command-nrpe)
* [check_nscp -l](13-icinga-template-library.md#plugin-check-command-nscp)
* [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
found in [this section](11-object-types.md#objecttype-checkcommand-arguments).
found in [this section](12-object-types.md#objecttype-checkcommand-arguments).
> **Note**
>
@ -2204,7 +2204,7 @@ a forced service check:
### <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
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.
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.
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
external web interfaces parsing the logs, but also to generate
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.
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)
chapter. Details on the configuration can be found in the
[IdoMysqlConnection](11-object-types.md#objecttype-idomysqlconnection) and
[IdoPgsqlConnection](11-object-types.md#objecttype-idopgsqlconnection)
[IdoMysqlConnection](12-object-types.md#objecttype-idomysqlconnection) and
[IdoPgsqlConnection](12-object-types.md#objecttype-idopgsqlconnection)
object configuration documentation.
The DB IDO feature supports [High Availability](4-monitoring-remote-systems.md#high-availability-db-ido) in
the Icinga 2 cluster.
@ -2479,7 +2479,7 @@ Example for PostgreSQL:
(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

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,
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
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
* [ping4](12-icinga-template-library.md#plugin-check-command-ping4), [ping6](12-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)
* [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)
* [http](12-icinga-template-library.md#plugin-check-command-http), [ftp](12-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),
[imap](12-icinga-template-library.md#plugin-check-command-imap), [simap](12-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)
* [ntp_time](12-icinga-template-library.md#plugin-check-command-ntp-time)
* [ssh](12-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)
* [ping4](13-icinga-template-library.md#plugin-check-command-ping4), [ping6](13-icinga-template-library.md#plugin-check-command-ping6),
[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](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](13-icinga-template-library.md#plugin-check-command-http), [ftp](13-icinga-template-library.md#plugin-check-command-ftp)
* [smtp](13-icinga-template-library.md#plugin-check-command-smtp), [ssmtp](13-icinga-template-library.md#plugin-check-command-ssmtp),
[imap](13-icinga-template-library.md#plugin-check-command-imap), [simap](13-icinga-template-library.md#plugin-check-command-simap),
[pop](13-icinga-template-library.md#plugin-check-command-pop), [spop](13-icinga-template-library.md#plugin-check-command-spop)
* [ntp_time](13-icinga-template-library.md#plugin-check-command-ntp-time)
* [ssh](13-icinga-template-library.md#plugin-check-command-ssh)
* [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
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.
Requirements:
* Exact same [CheckCommand](11-object-types.md#objecttype-checkcommand) (and
[EventCommand](11-object-types.md#objecttype-eventcommand)) configuration objects
* Exact same [CheckCommand](12-object-types.md#objecttype-checkcommand) (and
[EventCommand](12-object-types.md#objecttype-eventcommand)) configuration objects
on the master and the remote client(s).
* Installed plugin scripts on the remote client (`PluginDir` constant can be locally modified)
* `Zone` and `Endpoint` configuration for the client on the master
@ -357,7 +357,7 @@ on the master and the remote client(s).
endpoint
`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
[commands.conf](2-getting-started.md#commands-conf) make sure to copy/sync it
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
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 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)
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
have the `snmp-community` custom attribute.
@ -638,7 +638,7 @@ have the `snmp-community` custom attribute.
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
@ -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.
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:
@ -753,7 +753,7 @@ but using `NSClient++` will allow you to run local scripts similar to check plug
the required output and performance counters.
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:
@ -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.
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.
#### <a id="simple-traps"></a> Simple SNMP Traps
@ -1005,7 +1005,7 @@ Before you start deploying, keep the following things in mind:
> **Tip**
>
> 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
@ -1053,8 +1053,8 @@ the host's FQDN):
#### <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)
object to determine the local authority. This name must match the local [Endpoint](11-object-types.md#objecttype-endpoint)
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](12-object-types.md#objecttype-endpoint)
object name.
Example:
@ -1068,8 +1068,8 @@ Example:
host = "icinga2a.icinga.org"
}
The [Endpoint](11-object-types.md#objecttype-endpoint) name is further referenced as `endpoints` attribute on the
[Zone](11-object-types.md#objecttype-zone) object.
The [Endpoint](12-object-types.md#objecttype-endpoint) name is further referenced as `endpoints` attribute on the
[Zone](12-object-types.md#objecttype-zone) object.
object Endpoint "icinga2b" {
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
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 **
>
@ -1110,7 +1110,7 @@ that value using the [NodeName](9-language-reference.md#constants) constant.
> in `/etc/icinga2/constants.conf`.
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
[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
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:
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
> 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
@ -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
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`.
object ApiListener "api" {
@ -1340,13 +1340,13 @@ master instances anymore.
> ** 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.
### <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
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.
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`
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
@ -1651,8 +1651,8 @@ nodes disable the active IDO database connection at runtime.
> **Note**
>
> 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
> [IdoPgsqlConnection](11-object-types.md#objecttype-idopgsqlconnection) object on all nodes in the
> for the [IdoMysqlConnection](12-object-types.md#objecttype-idomysqlconnection) or
> [IdoPgsqlConnection](12-object-types.md#objecttype-idopgsqlconnection) object on all nodes in the
> same zone.
>
> 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
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.
#### 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
@ -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
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 - 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`
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`
after validation passes to analyze object attributes, inheritance or created
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*`:
@ -533,5 +533,5 @@ safely reload the Icinga 2 daemon.
> which will validate the configuration in a separate process and not stop
> the other events like check execution, notifications, etc.
>
> Details can be found [here](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
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
@ -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
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
configuration which can be used in the [Service](11-object-types.md#objecttype-service) or
[Host](11-object-types.md#objecttype-host) object definition.
Each plugin requires a [CheckCommand](12-object-types.md#objecttype-checkcommand) object in your
configuration which can be used in the [Service](12-object-types.md#objecttype-service) or
[Host](12-object-types.md#objecttype-host) 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
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 [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:
@ -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
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.

12
doc/7-livestatus.md
View File

@ -16,7 +16,7 @@ re-implementation of the Livestatus protocol which is compatible with MK
Livestatus.
Details on the available tables and attributes with Icinga 2 can be found
in the [Livestatus](3-monitoring-basics.md#livestatus) section.
in the [Livestatus](#livestatus) section.
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)
* 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.
### <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 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
@ -185,10 +185,10 @@ Default separators.
downtimes | services | status attributes
timeperiods | &nbsp; | name and is inside flag
endpoints | &nbsp; | config and status attributes
log | services, hosts, contacts, commands | parses [compatlog](11-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
log | services, hosts, contacts, commands | parses [compatlog](12-object-types.md#objecttype-compatlogger) and shows log 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.
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 logs targetting your problem
* 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
@ -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
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
@ -91,7 +91,7 @@ You can also filter by name and type:
## <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
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
* 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 `/* ... */`).
* 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
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
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
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.
### <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
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
@ -127,7 +127,7 @@ a member and includes all members of the `hg1` hostgroup.
hostgroup_members hg1
}
This can be migrated to Icinga 2 and [using group assign](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.
@ -217,8 +217,8 @@ directory - one major problem solved.
For the check command it is required to
* 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 [custom variable macros](8-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-custom-attributes) if any.
* 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](9-migrating-from-icinga-1x.md#manual-config-migration-hints-runtime-custom-attributes) if any.
* Keep `$ARGn$` macros.
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
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:
@ -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)
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{
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
}
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
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
[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 ]
types = [ Recovery, Problem, Custom ]
@ -617,7 +617,7 @@ enabled.
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
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.
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"
[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.
### <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.
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.
@ -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)
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
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:]:
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)