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

Documentation: Move configuration before advanced topics 

fixes #9431
This commit is contained in:
Michael Friedrich 2015-06-16 16:01:02 +02:00
parent 80990b6af4
commit d70a70753f
14 changed files with 80 additions and 105 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/10-icinga2-client.md
View File

@ -115,7 +115,7 @@ The setup wizard will do the following:
* Generate a new CSR, sign it with the local CA and copying it into `/etc/icinga2/pki`
* Generate a local zone and endpoint configuration for this master based on FQDN
* Enabling the API feature, and setting optional `bind_host` and `bind_port`
* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](5-configuring-icinga-2.md#constants-conf)
* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](4-configuring-icinga-2.md#constants-conf)
The setup wizard does not automatically restart Icinga 2.
@ -166,7 +166,7 @@ Your client setup requires the following
If your remote clients are capable of connecting to the central master, Icinga 2
supports CSR auto-signing.
First you'll need to define a secure ticket salt in the [constants.conf](5-configuring-icinga-2.md#constants-conf).
First you'll need to define a secure ticket salt in the [constants.conf](4-configuring-icinga-2.md#constants-conf).
The [setup wizard for the master setup](10-icinga2-client.md#icinga2-client-installation-master-setup) will create
one for you already.
@ -187,7 +187,7 @@ Example for a client:
> **Note**
>
> You can omit the `--salt` parameter using the `TicketSalt` constant from
> [constants.conf](5-configuring-icinga-2.md#constants-conf) if already defined and Icinga 2 was
> [constants.conf](4-configuring-icinga-2.md#constants-conf) if already defined and Icinga 2 was
> reloaded after the master setup.
### <a id="certificates-manual-creation"></a> Manual SSL Certificate Generation
@ -293,7 +293,7 @@ The setup wizard will do the following:
(based on FQDN)
* Disabling the `notification` feature for this client
* Enabling the `api` feature, and setting optional `bind_host` and `bind_port`
* Setting the `NodeName` constant in [constants.conf](5-configuring-icinga-2.md#constants-conf)
* Setting the `NodeName` constant in [constants.conf](4-configuring-icinga-2.md#constants-conf)
The setup wizard does not automatically restart Icinga 2.

6
doc/12-distributed-monitoring-ha.md
View File

@ -263,7 +263,7 @@ configuration from the parent zone. You can define that in the
attribute accordingly.
You should remove the sample config included in `conf.d` by commenting the `recursive_include`
statement in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf):
statement in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf):
//include_recursive "conf.d"
@ -321,7 +321,7 @@ process.
> **Note**
>
> `zones.d` must not be included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically
> `zones.d` must not be included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically
> determines the required include directory. This can be overridden using the
> [global constant](19-language-reference.md#constants) `ZonesDir`.
@ -811,7 +811,7 @@ Special scenarios might require multiple cluster nodes running on a single host.
By default Icinga 2 and its features will place their runtime data below the prefix
`LocalStateDir`. By default packages will set that path to `/var`.
You can either set that variable as constant configuration
definition in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) or pass it as runtime variable to
definition in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) or pass it as runtime variable to
the Icinga 2 daemon.
# icinga2 -c /etc/icinga2/node1/icinga2.conf -DLocalStateDir=/opt/node1/var

10
doc/13-addons-plugins.md
View File

@ -13,7 +13,7 @@ Use your distribution's package manager to install the `pnp4nagios` package.
If you're planning to use it configure it to use the
[bulk mode with npcd and npcdmod](http://docs.pnp4nagios.org/pnp-0.6/modes#bulk_mode_with_npcd_and_npcdmod)
in combination with Icinga 2's [PerfdataWriter](4-advanced-topics.md#performance-data). NPCD collects the performance
in combination with Icinga 2's [PerfdataWriter](5-advanced-topics.md#performance-data). NPCD collects the performance
data files which Icinga 2 generates.
Enable performance data writer in icinga 2
@ -45,7 +45,7 @@ Graphite consists of 3 software components:
* whisper - a simple database library for storing time-series data (similar in design to RRD)
* graphite webapp - A Django webapp that renders graphs on-demand using Cairo
Use the [GraphiteWriter](4-advanced-topics.md#graphite-carbon-cache-writer) feature
Use the [GraphiteWriter](5-advanced-topics.md#graphite-carbon-cache-writer) feature
for sending real-time metrics from Icinga 2 to Graphite.
# icinga2 feature enable graphite
@ -55,7 +55,7 @@ There are Graphite addons available for collecting the performance data files to
### <a id="addons-graphing-ingraph"></a> inGraph
[inGraph](https://www.netways.org/projects/ingraph/wiki) requires the ingraph-collector addon
to be configured to point at the perfdata files. Icinga 2's [PerfdataWriter](4-advanced-topics.md#performance-data) will
to be configured to point at the perfdata files. Icinga 2's [PerfdataWriter](5-advanced-topics.md#performance-data) will
write to the performance data spool directory.
## <a id="addons-visualization"></a> Visualization
@ -112,7 +112,7 @@ list of popular community sites which host check plugins:
* [Icinga Wiki](https://wiki.icinga.org)
The recommended way of setting up these plugins is to copy them to a common directory
and create a new global constant, e.g. `CustomPluginDir` in your [constants.conf](5-configuring-icinga-2.md#constants-conf)
and create a new global constant, e.g. `CustomPluginDir` in your [constants.conf](4-configuring-icinga-2.md#constants-conf)
configuration file:
# cp check_snmp_int.pl /opt/monitoring/plugins
@ -229,7 +229,7 @@ This behavior changed in Icinga 2 compared to Icinga 1.x. Though there are certa
fix this:
* Create a symlink for example from the `templates.dist/check_ping.php` template to the actual check name in Icinga 2 (`templates/ping4.php`)
* Pass the check command name inside the [format template configuration](4-advanced-topics.md#writing-performance-data-files)
* Pass the check command name inside the [format template configuration](5-advanced-topics.md#writing-performance-data-files)
The latter becomes difficult with agent based checks like NRPE or SSH where the first command argument acts as
graph template identifier. There is the possibility to define the pnp template name as custom attribute

8
doc/14-alternative-frontends.md
View File

@ -3,7 +3,7 @@
## <a id="setting-up-icinga-classic-ui"></a> Setting up Icinga Classic UI 1.x
Icinga 2 can write `status.dat` and `objects.cache` files in the format that
is supported by the Icinga 1.x Classic UI. [External commands](4-advanced-topics.md#external-commands)
is supported by the Icinga 1.x Classic UI. [External commands](5-advanced-topics.md#external-commands)
(a.k.a. the "command pipe") are also supported. It also supports writing Icinga 1.x
log files which are required for the reporting functionality in the Classic UI.
@ -32,8 +32,8 @@ to satisfy this dependency:
On all distributions other than Debian you may have to restart both your web
server as well as Icinga 2 after installing the Classic UI package.
Icinga Classic UI requires the [StatusDataWriter](4-advanced-topics.md#status-data), [CompatLogger](4-advanced-topics.md#compat-logging)
and [ExternalCommandListener](4-advanced-topics.md#external-commands) features.
Icinga Classic UI requires the [StatusDataWriter](5-advanced-topics.md#status-data), [CompatLogger](5-advanced-topics.md#compat-logging)
and [ExternalCommandListener](5-advanced-topics.md#external-commands) features.
Enable these features and restart Icinga 2.
# icinga2 feature enable statusdata compatlog command
@ -104,7 +104,7 @@ found in the [Icinga Web documentation](http://docs.icinga.org/latest/en/icinga-
# icinga-web-clearcache
Additionally you need to enable the `command` feature for sending [external commands](4-advanced-topics.md#external-commands):
Additionally you need to enable the `command` feature for sending [external commands](5-advanced-topics.md#external-commands):
# icinga2 feature enable command

6
doc/16-troubleshooting.md
View File

@ -102,7 +102,7 @@ included using
include <itl>
include <plugins>
in the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden
in the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden
on upgrade, so please send modifications as proposed patches upstream. The default include path is set to
`LocalStateDir + "/share/icinga2/includes"`.
@ -151,7 +151,7 @@ Examples:
## <a id="feature-not-working"></a> Feature is not working
* Make sure that the feature configuration is enabled by symlinking from `features-available/`
to `features-enabled` and that the latter is included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf).
to `features-enabled` and that the latter is included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf).
* Are the feature attributes set correctly according to the documentation?
* Any errors on the logs?
@ -159,7 +159,7 @@ to `features-enabled` and that the latter is included in [icinga2.conf](5-config
* Make sure that the line(s) are not [commented out](19-language-reference.md#comments) (starting with `//` or `#`, or
encapsulated by `/* ... */`).
* Is the configuration file included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf)?
* Is the configuration file included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf)?
## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from

4
doc/18-migrating-from-icinga-1x.md
View File

@ -739,7 +739,7 @@ included in `icinga2.conf` by default.
> **Note**
>
> Add your own custom templates in the `conf.d/` directory as well, e.g. inside
> the [templates.conf](5-configuring-icinga-2.md#templates-conf) file.
> the [templates.conf](4-configuring-icinga-2.md#templates-conf) file.
### <a id="differences-1x-2-main-config"></a> Main Config File
@ -747,7 +747,7 @@ In Icinga 1.x there are many global configuration settings available in `icinga.
Icinga 2 only uses a small set of [global constants](19-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](5-configuring-icinga-2.md#icinga2-conf) should take care of including
Aside from that, the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) should take care of including
global constants, enabled [features](8-cli-commands.md#features) and the object configuration.
### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories

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

@ -154,7 +154,7 @@ FreeBSD | nagios-plugins | /usr/local/libexec/nagios
OS X (MacPorts) | nagios-plugins | /opt/local/libexec
Depending on which directory your plugins are installed into you may need to
update the global `PluginDir` constant in your [Icinga 2 configuration](5-configuring-icinga-2.md#constants-conf).
update the global `PluginDir` constant in your [Icinga 2 configuration](4-configuring-icinga-2.md#constants-conf).
This constant is used by the check command definitions contained in the Icinga Template Library
to determine where to find the plugin binaries.

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

@ -197,7 +197,7 @@ value of arbitrary macro expressions:
}}
Acessing object attributes at runtime inside these functions is described in the
[advanced topics](4-advanced-topics.md#access-object-attributes-at-runtime) chapter.
[advanced topics](5-advanced-topics.md#access-object-attributes-at-runtime) chapter.
## <a id="runtime-macros"></a> Runtime Macros
@ -407,7 +407,7 @@ based on attribute identifiers for example `host_name` objects can be [applied](
Before you start using the apply rules keep the following in mind:
* Define the best match.
* A set of unique [custom attributes](#custom-attributes-apply) for these hosts/services?
* A set of unique [custom attributes](3-monitoring-basics.md#custom-attributes) for these hosts/services?
* Or [group](3-monitoring-basics.md#groups) memberships, e.g. a host being a member of a hostgroup, applying services to it?
* A generic pattern [match](19-language-reference.md#function-calls) on the host/service name?
* [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](19-language-reference.md#expression-operators)
@ -429,7 +429,7 @@ for not only matching for their existance or values in apply expressions, but al
A more advanced example is using [apply with for loops on arrays or
dictionaries](#using-apply-for) for example provided by
[custom atttributes](#custom-attributes-apply) or groups.
[custom atttributes](3-monitoring-basics.md#custom-attributes) or groups.
> **Tip**
>
@ -492,8 +492,8 @@ The notification is ignored for services whose host name ends with `*internal`
### <a id="using-apply-services"></a> Apply Services to Hosts
The sample configuration already includes a detailed example in [hosts.conf](5-configuring-icinga-2.md#hosts-conf)
and [services.conf](5-configuring-icinga-2.md#services-conf) for this use case.
The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
The example for `ssh` applies a service object to all hosts with the `address`
attribute being defined and the custom attribute `os` set to the string `Linux` in `vars`.
@ -508,7 +508,7 @@ attribute being defined and the custom attribute `os` set to the string `Linux`
Other detailed scenario examples are used in their respective chapters, for example
[apply services with custom command arguments](#using-apply-services-command-arguments).
[apply services with custom command arguments](3-monitoring-basics.md#command-passing-parameters).
### <a id="using-apply-notifications"></a> Apply Notifications to Hosts and Services
@ -535,9 +535,9 @@ Detailed examples can be found in the [dependencies](3-monitoring-basics.md#depe
### <a id="using-apply-scheduledowntimes"></a> Apply Recurring Downtimes to Hosts and Services
The sample configuration includes an example in [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf).
The sample configuration includes an example in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf).
Detailed examples can be found in the [recurring downtimes](4-advanced-topics.md#recurring-downtimes) chapter.
Detailed examples can be found in the [recurring downtimes](5-advanced-topics.md#recurring-downtimes) chapter.
### <a id="using-apply-for"></a> Using Apply For Rules
@ -546,8 +546,8 @@ Next to the standard way of using [apply rules](3-monitoring-basics.md#using-app
there is the requirement of generating apply rules objects based on set (array or
dictionary).
The sample configuration already includes a detailed example in [hosts.conf](5-configuring-icinga-2.md#hosts-conf)
and [services.conf](5-configuring-icinga-2.md#services-conf) for this use case.
The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
Take the following example: A host provides the snmp oids for different service check
types. This could look like the following example:
@ -604,7 +604,7 @@ with many interfaces (services). The following requirements/problems apply:
dynamically generated
Tip: Define the snmp community as global constant in your [constants.conf](5-configuring-icinga-2.md#constants-conf) file.
Tip: Define the snmp community as global constant in your [constants.conf](4-configuring-icinga-2.md#constants-conf) file.
const IftrafficSnmpCommunity = "public"
@ -722,7 +722,7 @@ if set.
This example makes use of the [check_iftraffic](https://exchange.icinga.org/exchange/iftraffic) plugin.
The `CheckCommand` definition can be found in the
[contributed plugin check commands](7-icinga-template-library.md#plugins-contrib-command-iftraffic)
- make sure to include them in your [icinga2 configuration file](5-configuring-icinga-2.md#icinga2-conf).
- make sure to include them in your [icinga2 configuration file](4-configuring-icinga-2.md#icinga2-conf).
> **Tip**
@ -1014,7 +1014,7 @@ notifications between start and end time.
vars.mobile = "+1 555 424642"
}
Define an additional [NotificationCommand](#notification) for SMS notifications.
Define an additional [NotificationCommand](3-monitoring-basics.md#notification-commands) for SMS notifications.
> **Note**
>
@ -1165,7 +1165,7 @@ using the `check_command` attribute.
`plugin-check-command` to support native plugin based check methods.
Unless you have done so already, download your check plugin and put it
into the [PluginDir](5-configuring-icinga-2.md#constants-conf) directory. The following example uses the
into the [PluginDir](4-configuring-icinga-2.md#constants-conf) directory. The following example uses the
`check_disk` plugin contained in the Monitoring Plugins package.
The plugin path and all command arguments are made a list of
@ -1292,7 +1292,7 @@ string values for passing multiple partitions to the `check_disk` check plugin.
More details on using arrays in custom attributes can be found in
[this chapter](#runtime-custom-attributes).
[this chapter](3-monitoring-basics.md#custom-attributes).
#### <a id="command-arguments"></a> Command Arguments

66
doc/5-configuring-icinga-2.md → doc/4-configuring-icinga-2.md
View File

@ -37,7 +37,7 @@ host and service basis.
Then you should look for the object specific configuration setting `host_name` etc accordingly.
Finding the best files and directory tree for your configuration is up to you. Make sure that
the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file includes them,
the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file includes them,
and then think about:
* tree-based on locations, hostgroups, specific host attributes with sub levels of directories.
@ -53,7 +53,7 @@ You can later use them for applying assign/ignore rules, or export them into ext
* Put hosts into hostgroups, services into servicegroups and use these attributes for your apply rules.
* Use templates to store generic attributes for your objects and apply rules making your configuration more readable.
Details can be found in the [using templates](3-monitoring-basics.md#object-inheritance-using-templates) chapter.
* Apply rules may overlap. Keep a central place (for example, [services.conf](5-configuring-icinga-2.md#services-conf) or [notifications.conf](5-configuring-icinga-2.md#notifications-conf)) storing
* Apply rules may overlap. Keep a central place (for example, [services.conf](4-configuring-icinga-2.md#services-conf) or [notifications.conf](4-configuring-icinga-2.md#notifications-conf)) storing
the configuration instead of defining apply rules deep in your configuration tree.
* Every plugin used as check, notification or event command requires a `Command` definition.
Further details can be looked up in the [check commands](3-monitoring-basics.md#check-commands) chapter.
@ -133,7 +133,7 @@ and their generated configuration described in
*/
include_recursive "conf.d"
You can put your own configuration files in the [conf.d](5-configuring-icinga-2.md#conf-d) directory. This
You can put your own configuration files in the [conf.d](4-configuring-icinga-2.md#conf-d) directory. This
directive makes sure that all of your own configuration files are included.
### <a id="constants-conf"></a> constants.conf
@ -178,35 +178,35 @@ and distributed setups only.
This directory contains example configuration which should help you get started
with monitoring the local host and its services. It is included in the
[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file by default.
[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file by default.
It can be used as reference example for your own configuration strategy.
Just keep in mind to include the main directories in the
[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) file.
[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) file.
You are certainly not bound to it. Remove it, if you prefer your own
way of deploying Icinga 2 configuration.
Further details on configuration best practice and how to build your
own strategy is described in [this chapter](5-configuring-icinga-2.md#configuration-best-practice).
own strategy is described in [this chapter](4-configuring-icinga-2.md#configuration-best-practice).
Available configuration files which are installed by default:
* [hosts.conf](5-configuring-icinga-2.md#hosts-conf)
* [services.conf](5-configuring-icinga-2.md#services-conf)
* [users.conf](5-configuring-icinga-2.md#users-conf)
* [notifications.conf](5-configuring-icinga-2.md#notifications-conf)
* [commands.conf](5-configuring-icinga-2.md#commands-conf)
* [groups.conf](5-configuring-icinga-2.md#groups-conf)
* [templates.conf](5-configuring-icinga-2.md#templates-conf)
* [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf)
* [timeperiods.conf](5-configuring-icinga-2.md#timeperiods-conf)
* [satellite.conf](5-configuring-icinga-2.md#satellite-conf)
* [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
* [services.conf](4-configuring-icinga-2.md#services-conf)
* [users.conf](4-configuring-icinga-2.md#users-conf)
* [notifications.conf](4-configuring-icinga-2.md#notifications-conf)
* [commands.conf](4-configuring-icinga-2.md#commands-conf)
* [groups.conf](4-configuring-icinga-2.md#groups-conf)
* [templates.conf](4-configuring-icinga-2.md#templates-conf)
* [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf)
* [timeperiods.conf](4-configuring-icinga-2.md#timeperiods-conf)
* [satellite.conf](4-configuring-icinga-2.md#satellite-conf)
#### <a id="hosts-conf"></a> hosts.conf
The `hosts.conf` file contains an example host based on your
`NodeName` setting in [constants.conf](5-configuring-icinga-2.md#constants-conf). You
`NodeName` setting in [constants.conf](4-configuring-icinga-2.md#constants-conf). You
can use global constants for your object names instead of string
values.
@ -219,20 +219,20 @@ for check and notification commands. Most of the [Plugin Check Commands](7-icing
in the Icinga Template Library require an `address` attribute.
The custom attribute `os` is evaluated by the `linux-servers` group in
[groups.conf](5-configuring-icinga-2.md#groups-conf) making the local host a member.
[groups.conf](4-configuring-icinga-2.md#groups-conf) making the local host a member.
The example host will show you how to
* define http vhost attributes for the `http` service apply rule defined
in [services.conf](5-configuring-icinga-2.md#services-conf).
in [services.conf](4-configuring-icinga-2.md#services-conf).
* define disks (all, specific `/`) and their attributes for the `disk`
service apply rule defined in [services.conf](5-configuring-icinga-2.md#services-conf).
service apply rule defined in [services.conf](4-configuring-icinga-2.md#services-conf).
* define notification types (`mail`) and set the groups attribute. This
will be used by notification apply rules in [notifications.conf](notifications-conf).
If you've installed [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2) you can
uncomment the http vhost attributes and reload Icinga 2. The apply
rules in [services.conf](5-configuring-icinga-2.md#services-conf) will automatically
rules in [services.conf](4-configuring-icinga-2.md#services-conf) will automatically
generate a new service checking the `/icingaweb2` URI using the `http`
check.
@ -289,7 +289,7 @@ check.
}
This is only the host object definition. Now we'll need to make sure that this
host and your additional hosts are getting [services](5-configuring-icinga-2.md#services-conf) applied.
host and your additional hosts are getting [services](4-configuring-icinga-2.md#services-conf) applied.
> **Tip**
>
@ -343,7 +343,7 @@ attributes.
The custom attribe `backup_downtime` is defined to a specific timerange string.
This variable value will be used for applying a `ScheduledDowntime` object to
these services in [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf).
these services in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf).
In this example the `assign where` condition is a boolean expression which is
evaluated for all objects of type `Host` and a new service with name "load"
@ -374,10 +374,10 @@ rules. While one `apply` rule for `ssh` will only create a service for matching
hosts, you can go one step further: Generate apply rules based on array items
or dictionary key-value pairs.
The idea is simple: Your host in [hosts.conf](5-configuring-icinga-2.md#hosts-conf) defines the
The idea is simple: Your host in [hosts.conf](4-configuring-icinga-2.md#hosts-conf) defines the
`disks` dictionary as custom attribute in `vars`.
Remember the example from [hosts.conf](5-configuring-icinga-2.md#hosts-conf):
Remember the example from [hosts.conf](4-configuring-icinga-2.md#hosts-conf):
...
@ -429,7 +429,7 @@ A similar example is used for the `http` services. That way you can make your
host the information provider for all apply rules. Define them once, and only
manage your hosts.
Look into [notifications.conf](5-configuring-icinga-2.md#notifications-conf) how this technique is used
Look into [notifications.conf](4-configuring-icinga-2.md#notifications-conf) how this technique is used
for applying notifications to hosts and services using their type and user
attributes.
@ -442,8 +442,8 @@ Further details on the monitoring configuration can be found in the
#### <a id="users-conf"></a> users.conf
Defines the `icingaadmin` User and the `icingaadmins` UserGroup. The latter is used in
[hosts.conf](5-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in
[notifications.conf](5-configuring-icinga-2.md#notifications-conf) for notification apply rules.
[hosts.conf](4-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in
[notifications.conf](4-configuring-icinga-2.md#notifications-conf) for notification apply rules.
object User "icingaadmin" {
import "generic-user"
@ -470,13 +470,13 @@ nested dictionary attribute `notification.mail` is set.
Please note that the `to` keyword is important in [notification apply rules](3-monitoring-basics.md#using-apply-notifications)
defining whether these notifications are applies to hosts or services.
The `import` keyword imports the specific mail templates defined in [templates.conf](5-configuring-icinga-2.md#templates-conf).
The `import` keyword imports the specific mail templates defined in [templates.conf](4-configuring-icinga-2.md#templates-conf).
The `interval` attribute is not explicitly set - it [defaults to 30 minutes](6-object-types.md#objecttype-notification).
By setting the `user_groups` to the value provided by the
respective [host.vars.notification.mail](5-configuring-icinga-2.md#hosts-conf) attribute we'll
implicitely use the `icingaadmins` UserGroup defined in [users.conf](5-configuring-icinga-2.md#users-conf).
respective [host.vars.notification.mail](4-configuring-icinga-2.md#hosts-conf) attribute we'll
implicitely use the `icingaadmins` UserGroup defined in [users.conf](4-configuring-icinga-2.md#users-conf).
apply Notification "mail-icingaadmin" to Host {
import "mail-host-notification"
@ -502,7 +502,7 @@ filters can be read in [this chapter](3-monitoring-basics.md#notifications).
### <a id="commands-conf"></a> commands.conf
This is the place where your own command configuration can be defined. By default
only the notification commands used by the notification templates defined in [templates.conf](5-configuring-icinga-2.md#templates-conf).
only the notification commands used by the notification templates defined in [templates.conf](4-configuring-icinga-2.md#templates-conf).
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).
@ -601,7 +601,7 @@ More details on `Notification` object attributes can be found [here](6-object-ty
#### <a id="downtimes-conf"></a> downtimes.conf
The `load` service apply rule defined in [services.conf](5-configuring-icinga-2.md#services-conf) defines
The `load` service apply rule defined in [services.conf](4-configuring-icinga-2.md#services-conf) defines
the `backup_downtime` custom attribute.
The [ScheduledDowntime](6-object-types.md#objecttype-scheduleddowntime) apply rule uses this attribute

4
doc/4-advanced-topics.md → doc/5-advanced-topics.md
View File

@ -53,7 +53,7 @@ is removed (may happen before or after the actual end time!).
### <a id="scheduling-downtime"></a> Scheduling a downtime
This can either happen through a web interface or by sending an [external command](4-advanced-topics.md#external-commands)
This can either happen through a web interface or by sending an [external command](5-advanced-topics.md#external-commands)
to the external command pipe provided by the `ExternalCommandListener` configuration.
Fixed downtimes require a start and end time (a duration will be ignored).
@ -462,7 +462,7 @@ You can customize the metric prefix name by using the `host_name_template` and
The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a
[global constant](19-language-reference.md#constants) named `GraphiteEnv`. The constant name
is freely definable and should be put in the [constants.conf](5-configuring-icinga-2.md#constants-conf) file.
is freely definable and should be put in the [constants.conf](4-configuring-icinga-2.md#constants-conf) file.
const GraphiteEnv = "icinga.env1"

29
doc/6-object-types.md
View File

@ -11,7 +11,7 @@ description are explained as well.
ApiListener objects are used for distributed monitoring setups
specifying the certificate files used for ssl authorization.
The `NodeName` constant must be defined in [constants.conf](5-configuring-icinga-2.md#constants-conf).
The `NodeName` constant must be defined in [constants.conf](4-configuring-icinga-2.md#constants-conf).
Example:
@ -319,31 +319,6 @@ Configuration Attributes:
log_duration |**Optional.** Duration for keeping replay logs on connection loss. Defaults to `1d`.
## <a id="objecttype-zone"></a> Zone
Zone objects are used to specify which Icinga 2 instances are located in a zone.
Example:
object Zone "config-ha-master" {
endpoints = [ "icinga2a", "icinga2b" ]
}
object Zone "check-satellite" {
endpoints = [ "icinga2c" ]
parent = "config-ha-master"
}
Configuration Attributes:
Name |Description
----------------|----------------
endpoints |**Optional.** Dictionary with endpoints located in this zone.
parent |**Optional.** The name of the parent zone.
global |**Optional.** Whether configuration files for this zone should be synced to all endpoints. Defaults to false.
## <a id="objecttype-eventcommand"></a> EventCommand
An event command definition.
@ -999,7 +974,7 @@ ScheduledDowntime objects can be used to set up recurring downtimes for hosts/se
> to just create a `ScheduledDowntime` template and use the `apply` keyword to assign the
> scheduled downtime to a number of hosts or services. Use the `to` keyword to set the specific target
> type for `Host` or `Service`.
> Check the [recurring downtimes](4-advanced-topics.md#recurring-downtimes) example for details.
> Check the [recurring downtimes](5-advanced-topics.md#recurring-downtimes) example for details.
Example:

6
doc/7-icinga-template-library.md
View File

@ -1053,12 +1053,12 @@ users\_win\_crit | **Optional**. The critical threshold.
Icinga 2 can use the `nscp client` command to run arbitrary NSClient++ checks.
You can enable these check commands by adding the following the include directive in your
[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file:
[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file:
include <nscp>
You can also optionally specify an alternative installation directory for NSClient++ by adding
the NscpPath constant in your [constants.conf](5-configuring-icinga-2.md#constants-conf) configuration
the NscpPath constant in your [constants.conf](4-configuring-icinga-2.md#constants-conf) configuration
file:
const NscpPath = "C:\\Program Files (x86)\\NSClient++"
@ -1146,7 +1146,7 @@ The SNMP manubulon plugin check commands assume that the global constant named `
is set to the path where the Manubublon SNMP plugins are installed.
You can enable these plugin check commands by adding the following the include directive in your
[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file:
[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file:
include <manubulon>

2
doc/9-monitoring-remote-systems.md
View File

@ -36,7 +36,7 @@ Start your search at
* [Icinga Wiki](https://wiki.icinga.org)
An example is provided in the sample configuration in the getting started
section shipped with Icinga 2 ([hosts.conf](5-configuring-icinga-2.md#hosts-conf), [services.conf](5-configuring-icinga-2.md#services-conf)).
section provided by Icinga 2 ([hosts.conf](4-configuring-icinga-2.md#hosts-conf), [services.conf](4-configuring-icinga-2.md#services-conf)).
## <a id="agent-based-checks"></a> Agent-based Checks

4
mkdocs.yml
View File

@ -5,8 +5,8 @@ pages:
- [1-about.md, About Icinga 2]
- [2-getting-started.md, Getting Started]
- [3-monitoring-basics.md, Monitoring Basics]
- [4-advanced-topics.md, Advanced Topics]
- [5-configuring-icinga-2.md, Configuring Icinga 2]
- [4-configuring-icinga-2.md, Configuring Icinga 2]
- [5-advanced-topics.md, Advanced Topics]
- [6-object-types.md, Object Types]
- [7-icinga-template-library.md, Icinga Template Library]
- [8-cli-commands.md, CLI Commands]