diff --git a/doc/02-installation.md b/doc/02-installation.md
index 29dd36ae0..3f1464dc9 100644
--- a/doc/02-installation.md
+++ b/doc/02-installation.md
@@ -1,7 +1,7 @@
# Getting Started
-This tutorial is a step-by-step introduction to installing [Icinga 2](02-getting-started.md#setting-up-icinga2)
-and [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2).
+This tutorial is a step-by-step introduction to installing [Icinga 2](02-installation.md#setting-up-icinga2)
+and [Icinga Web 2](02-installation.md#setting-up-icingaweb2).
It assumes that you are familiar with the operating system you're using to install Icinga 2.
In case you are upgrading an existing setup, please ensure to
@@ -306,7 +306,7 @@ Without plugins Icinga 2 does not know how to check external services. The
an extensive set of plugins which can be used with Icinga 2 to check whether
services are working properly.
-These plugins are required to make the [example configuration](04-configuring-icinga-2.md#configuring-icinga2-overview)
+These plugins are required to make the [example configuration](04-configuration.md#configuring-icinga2-overview)
work out-of-the-box.
For your convenience here is a list of package names for some of the more
@@ -337,7 +337,7 @@ yum install nagios-plugins-all
```
The packages for RHEL/CentOS depend on other packages which are distributed
-as part of the [EPEL repository](02-getting-started.md#package-repositories-rhel-epel).
+as part of the [EPEL repository](02-installation.md#package-repositories-rhel-epel).
Fedora:
@@ -371,7 +371,7 @@ Note: For Alpine you don't need to explicitly add the `monitoring-plugins` packa
`icinga2` and is pulled automatically.
Depending on which directory your plugins are installed into you may need to
-update the global `PluginDir` constant in your [Icinga 2 configuration](04-configuring-icinga-2.md#constants-conf).
+update the global `PluginDir` constant in your [Icinga 2 configuration](04-configuration.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.
@@ -603,8 +603,8 @@ This chapter explains how to set up Icinga Web 2.
The DB IDO (Database Icinga Data Output) feature for Icinga 2 take care of
exporting all configuration and status information into a database.
-Please choose whether to install [MySQL](02-getting-started.md#configuring-db-ido-mysql) or
-[PostgreSQL](02-getting-started.md#configuring-db-ido-postgresql).
+Please choose whether to install [MySQL](02-installation.md#configuring-db-ido-mysql) or
+[PostgreSQL](02-installation.md#configuring-db-ido-postgresql).
### Configuring DB IDO MySQL
@@ -744,7 +744,7 @@ Alpine Linux:
rc-service icinga2 restart
```
-Continue with the [webserver setup](02-getting-started.md#icinga2-user-interface-webserver).
+Continue with the [webserver setup](02-installation.md#icinga2-user-interface-webserver).
### Configuring DB IDO PostgreSQL
@@ -910,7 +910,7 @@ Alpine Linux:
rc-service icinga2 restart
```
-Continue with the [webserver setup](02-getting-started.md#icinga2-user-interface-webserver).
+Continue with the [webserver setup](02-installation.md#icinga2-user-interface-webserver).
### Webserver
diff --git a/doc/03-monitoring-basics.md b/doc/03-monitoring-basics.md
index e1b0b058c..f8fe8cc06 100644
--- a/doc/03-monitoring-basics.md
+++ b/doc/03-monitoring-basics.md
@@ -867,8 +867,8 @@ More advanced examples are covered [here](08-advanced-topics.md#use-functions-as
### Apply Services to Hosts
-The sample configuration already includes a detailed example in [hosts.conf](04-configuring-icinga-2.md#hosts-conf)
-and [services.conf](04-configuring-icinga-2.md#services-conf) for this use case.
+The sample configuration already includes a detailed example in [hosts.conf](04-configuration.md#hosts-conf)
+and [services.conf](04-configuration.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`.
@@ -964,7 +964,7 @@ Detailed examples can be found in the [dependencies](03-monitoring-basics.md#dep
### Apply Recurring Downtimes to Hosts and Services
-The sample configuration includes an example in [downtimes.conf](04-configuring-icinga-2.md#downtimes-conf).
+The sample configuration includes an example in [downtimes.conf](04-configuration.md#downtimes-conf).
Detailed examples can be found in the [recurring downtimes](08-advanced-topics.md#recurring-downtimes) chapter.
@@ -975,8 +975,8 @@ Next to the standard way of using [apply rules](03-monitoring-basics.md#using-ap
there is the requirement of applying objects based on a set (array or
dictionary) using [apply for](17-language-reference.md#apply-for) expressions.
-The sample configuration already includes a detailed example in [hosts.conf](04-configuring-icinga-2.md#hosts-conf)
-and [services.conf](04-configuring-icinga-2.md#services-conf) for this use case.
+The sample configuration already includes a detailed example in [hosts.conf](04-configuration.md#hosts-conf)
+and [services.conf](04-configuration.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:
@@ -1046,7 +1046,7 @@ dynamically generated.
> **Tip**
>
-> Define the SNMP community as global constant in your [constants.conf](04-configuring-icinga-2.md#constants-conf) file.
+> Define the SNMP community as global constant in your [constants.conf](04-configuration.md#constants-conf) file.
```
const IftrafficSnmpCommunity = "public"
@@ -1567,7 +1567,7 @@ A common pattern is to store the users and user groups
on the host or service objects instead of the notification
object itself.
-The sample configuration provided in [hosts.conf](04-configuring-icinga-2.md#hosts-conf) and [notifications.conf](notifications-conf)
+The sample configuration provided in [hosts.conf](04-configuration.md#hosts-conf) and [notifications.conf](notifications-conf)
already provides an example for this question.
> **Tip**
@@ -1874,7 +1874,7 @@ using the `check_command` attribute.
#### Integrate the Plugin with a CheckCommand Definition
Unless you have done so already, download your check plugin and put it
-into the [PluginDir](04-configuring-icinga-2.md#constants-conf) directory. The following example uses the
+into the [PluginDir](04-configuration.md#constants-conf) directory. The following example uses the
`check_mysql` plugin contained in the Monitoring Plugins package.
The plugin path and all command arguments are made a list of
@@ -1913,7 +1913,7 @@ The check command parameters for ITL provided plugin check command definitions a
In order to practice passing command parameters you should [integrate your own plugin](03-monitoring-basics.md#command-plugin-integration).
-The following example will use `check_mysql` provided by the [Monitoring Plugins installation](02-getting-started.md#setting-up-check-plugins).
+The following example will use `check_mysql` provided by the [Monitoring Plugins installation](02-installation.md#setting-up-check-plugins).
Define the default check command custom attributes, for example `mysql_user` and `mysql_password`
(freely definable naming schema) and optional their default threshold values. You can
@@ -1973,7 +1973,7 @@ The check command definition also sets `mysql_host` to the `$address$` default v
this command parameter if for example your MySQL host is not running on the same server's ip address.
Make sure pass all required command parameters, such as `mysql_user`, `mysql_password` and `mysql_database`.
-`MysqlUsername` and `MysqlPassword` are specified as [global constants](04-configuring-icinga-2.md#constants-conf)
+`MysqlUsername` and `MysqlPassword` are specified as [global constants](04-configuration.md#constants-conf)
in this example.
```
@@ -1996,10 +1996,10 @@ apply Service "mysql-icinga-db-health" {
```
-Take a different example: The example host configuration in [hosts.conf](04-configuring-icinga-2.md#hosts-conf)
+Take a different example: The example host configuration in [hosts.conf](04-configuration.md#hosts-conf)
also applies an `ssh` service check. Your host's ssh port is not the default `22`, but set to `2022`.
You can pass the command parameter as custom attribute `ssh_port` directly inside the service apply rule
-inside [services.conf](04-configuring-icinga-2.md#services-conf):
+inside [services.conf](04-configuration.md#services-conf):
```
apply Service "ssh" {
diff --git a/doc/04-configuration.md b/doc/04-configuration.md
index 434b8c9b8..61cce04c1 100644
--- a/doc/04-configuration.md
+++ b/doc/04-configuration.md
@@ -36,7 +36,7 @@ host and service basis.
Then you should look for the object specific configuration setting `host_name` etc. accordingly.
You decide on the "best" layout for configuration files and directories. Ensure that
-the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file includes them.
+the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file includes them.
Consider these ideas:
@@ -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](03-monitoring-basics.md#object-inheritance-using-templates) chapter.
-* Apply rules may overlap. Keep a central place (for example, [services.conf](04-configuring-icinga-2.md#services-conf) or [notifications.conf](04-configuring-icinga-2.md#notifications-conf)) storing
+* Apply rules may overlap. Keep a central place (for example, [services.conf](04-configuration.md#services-conf) or [notifications.conf](04-configuration.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](03-monitoring-basics.md#check-commands) chapter.
@@ -176,7 +176,7 @@ the features which have been enabled with `icinga2 feature enable`. See
include_recursive "conf.d"
```
-You can put your own configuration files in the [conf.d](04-configuring-icinga-2.md#conf-d) directory. This
+You can put your own configuration files in the [conf.d](04-configuration.md#conf-d) directory. This
directive makes sure that all of your own configuration files are included.
### constants.conf
@@ -185,7 +185,7 @@ The `constants.conf` configuration file can be used to define global constants.
By default, you need to make sure to set these constants:
-* The `PluginDir` constant must be set to the path where the [Monitoring Project plugins](02-getting-started.md#setting-up-check-plugins) are installed.
+* The `PluginDir` constant must be set to the path where the [Monitoring Project plugins](02-installation.md#setting-up-check-plugins) are installed.
This constant is used by a number of
[built-in check command definitions](10-icinga-template-library.md#icinga-template-library).
* The `NodeName` constant defines your local node name. Should be set to FQDN which is the default
@@ -224,7 +224,7 @@ This file can be used to specify the required [Zone](09-object-types.md#objectty
and [Endpoint](09-object-types.md#objecttype-endpoint) configuration object for
[distributed monitoring](06-distributed-monitoring.md#distributed-monitoring).
-By default the `NodeName` and `ZoneName` [constants](04-configuring-icinga-2.md#constants-conf) will be used.
+By default the `NodeName` and `ZoneName` [constants](04-configuration.md#constants-conf) will be used.
It also contains several [global zones](06-distributed-monitoring.md#distributed-monitoring-global-zone-config-sync)
for distributed monitoring environments.
@@ -237,38 +237,38 @@ for your `Zone` and `Endpoint` object names.
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](04-configuring-icinga-2.md#icinga2-conf) configuration file by default.
+[icinga2.conf](04-configuration.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](04-configuring-icinga-2.md#icinga2-conf) file.
+[icinga2.conf](04-configuration.md#icinga2-conf) file.
> **Note**
>
-> You can remove the include directive in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf)
+> You can remove the include directive in [icinga2.conf](04-configuration.md#icinga2-conf)
> 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](04-configuring-icinga-2.md#configuration-best-practice).
+own strategy is described in [this chapter](04-configuration.md#configuration-best-practice).
Available configuration files which are installed by default:
-* [hosts.conf](04-configuring-icinga-2.md#hosts-conf)
-* [services.conf](04-configuring-icinga-2.md#services-conf)
-* [users.conf](04-configuring-icinga-2.md#users-conf)
-* [notifications.conf](04-configuring-icinga-2.md#notifications-conf)
-* [commands.conf](04-configuring-icinga-2.md#commands-conf)
-* [groups.conf](04-configuring-icinga-2.md#groups-conf)
-* [templates.conf](04-configuring-icinga-2.md#templates-conf)
-* [downtimes.conf](04-configuring-icinga-2.md#downtimes-conf)
-* [timeperiods.conf](04-configuring-icinga-2.md#timeperiods-conf)
-* [api-users.conf](04-configuring-icinga-2.md#api-users-conf)
-* [app.conf](04-configuring-icinga-2.md#app-conf)
+* [hosts.conf](04-configuration.md#hosts-conf)
+* [services.conf](04-configuration.md#services-conf)
+* [users.conf](04-configuration.md#users-conf)
+* [notifications.conf](04-configuration.md#notifications-conf)
+* [commands.conf](04-configuration.md#commands-conf)
+* [groups.conf](04-configuration.md#groups-conf)
+* [templates.conf](04-configuration.md#templates-conf)
+* [downtimes.conf](04-configuration.md#downtimes-conf)
+* [timeperiods.conf](04-configuration.md#timeperiods-conf)
+* [api-users.conf](04-configuration.md#api-users-conf)
+* [app.conf](04-configuration.md#app-conf)
#### hosts.conf
The `hosts.conf` file contains an example host based on your
-`NodeName` setting in [constants.conf](04-configuring-icinga-2.md#constants-conf). You
+`NodeName` setting in [constants.conf](04-configuration.md#constants-conf). You
can use global constants for your object names instead of string
values.
@@ -281,20 +281,20 @@ for check and notification commands. Most of the [Plugin Check Commands](10-icin
in the Icinga Template Library require an `address` attribute.
The custom attribute `os` is evaluated by the `linux-servers` group in
-[groups.conf](04-configuring-icinga-2.md#groups-conf) making the local host a member.
+[groups.conf](04-configuration.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](04-configuring-icinga-2.md#services-conf).
+in [services.conf](04-configuration.md#services-conf).
* define disks (all, specific `/`) and their attributes for the `disk`
-service apply rule defined in [services.conf](04-configuring-icinga-2.md#services-conf).
+service apply rule defined in [services.conf](04-configuration.md#services-conf).
* define notification types (`mail`) and set the groups attribute. This
-will be used by notification apply rules in [notifications.conf](04-configuring-icinga-2.md#notifications-conf).
+will be used by notification apply rules in [notifications.conf](04-configuration.md#notifications-conf).
-If you've installed [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2), you can
+If you've installed [Icinga Web 2](02-installation.md#setting-up-icingaweb2), you can
uncomment the http vhost attributes and reload Icinga 2. The apply
-rules in [services.conf](04-configuring-icinga-2.md#services-conf) will automatically
+rules in [services.conf](04-configuration.md#services-conf) will automatically
generate a new service checking the `/icingaweb2` URI using the `http`
check.
@@ -353,7 +353,7 @@ object Host NodeName {
```
This is only the host object definition. Now we'll need to make sure that this
-host and your additional hosts are getting [services](04-configuring-icinga-2.md#services-conf) applied.
+host and your additional hosts are getting [services](04-configuration.md#services-conf) applied.
> **Tip**
>
@@ -409,7 +409,7 @@ attributes.
The custom attribute `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](04-configuring-icinga-2.md#downtimes-conf).
+these services in [downtimes.conf](04-configuration.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"
@@ -442,10 +442,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](04-configuring-icinga-2.md#hosts-conf) defines the
+The idea is simple: Your host in [hosts.conf](04-configuration.md#hosts-conf) defines the
`disks` dictionary as custom attribute in `vars`.
-Remember the example from [hosts.conf](04-configuring-icinga-2.md#hosts-conf):
+Remember the example from [hosts.conf](04-configuration.md#hosts-conf):
```
...
@@ -499,11 +499,11 @@ 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](04-configuring-icinga-2.md#notifications-conf) how this technique is used
+Look into [notifications.conf](04-configuration.md#notifications-conf) how this technique is used
for applying notifications to hosts and services using their type and user
attributes.
-Don't forget to install the [check plugins](02-getting-started.md#setting-up-check-plugins) required by
+Don't forget to install the [check plugins](02-installation.md#setting-up-check-plugins) required by
the hosts and services and their check commands.
Further details on the monitoring configuration can be found in the
@@ -512,8 +512,8 @@ Further details on the monitoring configuration can be found in the
#### users.conf
Defines the `icingaadmin` User and the `icingaadmins` UserGroup. The latter is used in
-[hosts.conf](04-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in
-[notifications.conf](04-configuring-icinga-2.md#notifications-conf) for notification apply rules.
+[hosts.conf](04-configuration.md#hosts-conf) for defining a custom host attribute later used in
+[notifications.conf](04-configuration.md#notifications-conf) for notification apply rules.
```
object User "icingaadmin" {
@@ -541,13 +541,13 @@ nested dictionary attribute `notification.mail` is set.
Please note that the `to` keyword is important in [notification apply rules](03-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](04-configuring-icinga-2.md#templates-conf).
+The `import` keyword imports the specific mail templates defined in [templates.conf](04-configuration.md#templates-conf).
The `interval` attribute is not explicitly set -- it [defaults to 30 minutes](09-object-types.md#objecttype-notification).
By setting the `user_groups` to the value provided by the
-respective [host.vars.notification.mail](04-configuring-icinga-2.md#hosts-conf) attribute we'll
-implicitely use the `icingaadmins` UserGroup defined in [users.conf](04-configuring-icinga-2.md#users-conf).
+respective [host.vars.notification.mail](04-configuration.md#hosts-conf) attribute we'll
+implicitely use the `icingaadmins` UserGroup defined in [users.conf](04-configuration.md#users-conf).
```
apply Notification "mail-icingaadmin" to Host {
@@ -575,7 +575,7 @@ filters can be read in [this chapter](03-monitoring-basics.md#alert-notification
#### 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](04-configuring-icinga-2.md#templates-conf).
+only the notification commands used by the notification templates defined in [templates.conf](04-configuration.md#templates-conf).
You can freely customize these notification commands, and adapt them for your needs.
Read more on that topic [here](03-monitoring-basics.md#notification-commands).
@@ -680,7 +680,7 @@ More details on `Notification` object attributes can be found [here](09-object-t
#### downtimes.conf
-The `load` service apply rule defined in [services.conf](04-configuring-icinga-2.md#services-conf) defines
+The `load` service apply rule defined in [services.conf](04-configuration.md#services-conf) defines
the `backup_downtime` custom attribute.
The ScheduledDowntime apply rule uses this attribute to define the default value
diff --git a/doc/05-service-monitoring.md b/doc/05-service-monitoring.md
index 98360dead..b19e284e4 100644
--- a/doc/05-service-monitoring.md
+++ b/doc/05-service-monitoring.md
@@ -130,7 +130,7 @@ chmod +x /opt/monitoring/plugins/check_snmp_int.pl
```
Next create a new global constant, e.g. `CustomPluginDir`
-in your [constants.conf](04-configuring-icinga-2.md#constants-conf)
+in your [constants.conf](04-configuration.md#constants-conf)
configuration file:
```
diff --git a/doc/06-distributed-monitoring.md b/doc/06-distributed-monitoring.md
index e02e6d632..74a95e11c 100644
--- a/doc/06-distributed-monitoring.md
+++ b/doc/06-distributed-monitoring.md
@@ -36,7 +36,7 @@ In case you are planning a huge cluster setup with multiple levels and
lots of clients, read on -- we'll deal with these cases later on.
The installation on each system is the same: You need to install the
-[Icinga 2 package](02-getting-started.md#setting-up-icinga2) and the required [plugins](02-getting-started.md#setting-up-check-plugins).
+[Icinga 2 package](02-installation.md#setting-up-icinga2) and the required [plugins](02-installation.md#setting-up-check-plugins).
The required configuration steps are mostly happening
on the command line. You can also [automate the setup](06-distributed-monitoring.md#distributed-monitoring-automation).
@@ -227,8 +227,8 @@ This section explains how to install a central single master node using
the `node wizard` command. If you prefer to do an automated installation, please
refer to the [automated setup](06-distributed-monitoring.md#distributed-monitoring-automation) section.
-Install the [Icinga 2 package](02-getting-started.md#setting-up-icinga2) and setup
-the required [plugins](02-getting-started.md#setting-up-check-plugins) if you haven't done
+Install the [Icinga 2 package](02-installation.md#setting-up-icinga2) and setup
+the required [plugins](02-installation.md#setting-up-check-plugins) if you haven't done
so already.
**Note**: Windows is not supported for a master node setup.
@@ -250,9 +250,9 @@ The setup wizard will ensure that the following steps are taken:
* Enable the `api` feature.
* Generate a new certificate authority (CA) in `/var/lib/icinga2/ca` if it doesn't exist.
* Create a certificate for this node signed by the CA key.
-* Update the [zones.conf](04-configuring-icinga-2.md#zones-conf) file with the new zone hierarchy.
-* Update the [ApiListener](06-distributed-monitoring.md#distributed-monitoring-apilistener) and [constants](04-configuring-icinga-2.md#constants-conf) configuration.
-* Update the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) to disable the `conf.d` inclusion, and add the `api-users.conf` file inclusion.
+* Update the [zones.conf](04-configuration.md#zones-conf) file with the new zone hierarchy.
+* Update the [ApiListener](06-distributed-monitoring.md#distributed-monitoring-apilistener) and [constants](04-configuration.md#constants-conf) configuration.
+* Update the [icinga2.conf](04-configuration.md#icinga2-conf) to disable the `conf.d` inclusion, and add the `api-users.conf` file inclusion.
Here is an example of a master setup for the `icinga2-master1.localdomain` node on CentOS 7:
@@ -293,7 +293,7 @@ Now restart your Icinga 2 daemon to finish the installation!
```
You can verify that the CA public and private keys are stored in the `/var/lib/icinga2/ca` directory.
-Keep this path secure and include it in your [backups](02-getting-started.md#install-backup).
+Keep this path secure and include it in your [backups](02-installation.md#install-backup).
In case you lose the CA private key you have to generate a new CA for signing new client
certificate requests. You then have to also re-create new signed certificates for all
@@ -473,8 +473,8 @@ Icinga 2 on the master node must be running and accepting connections on port `5
Please ensure that you've run all the steps mentioned in the [client/satellite section](06-distributed-monitoring.md#distributed-monitoring-setup-satellite-client).
-Install the [Icinga 2 package](02-getting-started.md#setting-up-icinga2) and setup
-the required [plugins](02-getting-started.md#setting-up-check-plugins) if you haven't done
+Install the [Icinga 2 package](02-installation.md#setting-up-icinga2) and setup
+the required [plugins](02-installation.md#setting-up-check-plugins) if you haven't done
so already.
The next step is to run the `node wizard` CLI command.
@@ -929,7 +929,7 @@ The host/service object configuration is located on the master/satellite and the
needs the CheckCommand object definitions being used there.
Every endpoint has its own remote check queue. The amount of checks executed simultaneously
-can be limited on the endpoint with the `MaxConcurrentChecks` constant defined in [constants.conf](04-configuring-icinga-2.md#constants-conf). Icinga 2 may discard check requests,
+can be limited on the endpoint with the `MaxConcurrentChecks` constant defined in [constants.conf](04-configuration.md#constants-conf). Icinga 2 may discard check requests,
if the remote check queue is full.
@@ -2817,7 +2817,7 @@ to pick the authoritative running one and copy the following content:
If you need already deployed config packages from the Director, or synced cluster zones,
you can also sync the entire `/var/lib/icinga2/api/packages` directory. This directory should also be
-included in your [backup strategy](02-getting-started.md#install-backup).
+included in your [backup strategy](02-installation.md#install-backup).
Do **not** sync `/var/lib/icinga2/api/zones*` manually - this is an internal directory
and handled by the Icinga cluster config sync itself.
diff --git a/doc/07-agent-based-monitoring.md b/doc/07-agent-based-monitoring.md
index 99e461523..7f75262a4 100644
--- a/doc/07-agent-based-monitoring.md
+++ b/doc/07-agent-based-monitoring.md
@@ -7,7 +7,7 @@ become handy.
## SNMP
The SNMP daemon runs on the remote system and answers SNMP queries by plugin
-binaries. The [Monitoring Plugins package](02-getting-started.md#setting-up-check-plugins) ships
+binaries. The [Monitoring Plugins package](02-installation.md#setting-up-check-plugins) ships
the `check_snmp` plugin binary, but there are plenty of [existing plugins](05-service-monitoring.md#service-monitoring-plugins)
for specific use cases already around, for example monitoring Cisco routers.
@@ -37,7 +37,7 @@ As such, it is recommended to always specify at least one `MIB`.
Calling a plugin using the SSH protocol to execute a plugin on the remote server fetching
its return code and output. The `by_ssh` command object is part of the built-in templates and
-requires the `check_by_ssh` check plugin which is available in the [Monitoring Plugins package](02-getting-started.md#setting-up-check-plugins).
+requires the `check_by_ssh` check plugin which is available in the [Monitoring Plugins package](02-installation.md#setting-up-check-plugins).
```
object CheckCommand "by_ssh_swap" {
diff --git a/doc/08-advanced-topics.md b/doc/08-advanced-topics.md
index d4cb3ab2d..af17e05f4 100644
--- a/doc/08-advanced-topics.md
+++ b/doc/08-advanced-topics.md
@@ -699,7 +699,7 @@ inside the `icinga2.log` file depending in your log severity
in objects and other functions. Keep in mind that these functions are not marked
as side-effect-free and as such are not available via the REST API.
-Add a new configuration file `functions.conf` and include it into the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf)
+Add a new configuration file `functions.conf` and include it into the [icinga2.conf](04-configuration.md#icinga2-conf)
configuration file in the very beginning, e.g. after `constants.conf`. You can also manage global
functions inside `constants.conf` if you prefer.
diff --git a/doc/09-object-types.md b/doc/09-object-types.md
index 8de8a8f87..f9a0f624f 100644
--- a/doc/09-object-types.md
+++ b/doc/09-object-types.md
@@ -1104,7 +1104,7 @@ and API usage specifying the certificate files used for ssl
authorization and additional restrictions.
This configuration object is available as [api feature](11-cli-commands.md#cli-command-feature).
-The `TicketSalt` constant must be defined in [constants.conf](04-configuring-icinga-2.md#constants-conf).
+The `TicketSalt` constant must be defined in [constants.conf](04-configuration.md#constants-conf).
Example:
diff --git a/doc/10-icinga-template-library.md b/doc/10-icinga-template-library.md
index b1e6b01d1..fe1d6fdd9 100644
--- a/doc/10-icinga-template-library.md
+++ b/doc/10-icinga-template-library.md
@@ -23,7 +23,7 @@ You are advised to create your own CheckCommand definitions in
## Generic Templates
-By default the generic templates are included in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file:
+By default the generic templates are included in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file:
```
include
@@ -177,7 +177,7 @@ sleep\_time | **Optional.** The duration of the sleep in seconds. Defaults t
The Plugin Check Commands provides example configuration for plugin check commands
provided by the [Monitoring Plugins](https://www.monitoring-plugins.org) project.
-By default the Plugin Check Commands are included in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration
+By default the Plugin Check Commands are included in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration
file:
include
@@ -1731,7 +1731,7 @@ are not recommended with using the legacy HTTP API.
`check_nscp_api` is part of the Icinga 2 plugins. This plugin is available for
both, Windows and Linux/Unix.
-Verify that the ITL CheckCommand is included in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file:
+Verify that the ITL CheckCommand is included in the [icinga2.conf](04-configuration.md#icinga2-conf) configuration file:
vim /etc/icinga2/icinga2.conf
@@ -1774,12 +1774,12 @@ check_cpu CRITICAL: critical(5m: 48%, 1m: 36%), 5s: 0% | 'total 5m'=48%;40;30 't
Icinga 2 can use the `nscp client` command to run arbitrary NSClient++ checks locally on the client.
You can enable these check commands by adding the following the include directive in your
-[icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file:
+[icinga2.conf](04-configuration.md#icinga2-conf) configuration file:
include
You can also optionally specify an alternative installation directory for NSClient++ by adding
-the NscpPath constant in your [constants.conf](04-configuring-icinga-2.md#constants-conf) configuration
+the NscpPath constant in your [constants.conf](04-configuration.md#constants-conf) configuration
file:
const NscpPath = "C:\\Program Files (x86)\\NSClient++"
@@ -1944,7 +1944,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](04-configuring-icinga-2.md#icinga2-conf) configuration file:
+[icinga2.conf](04-configuration.md#icinga2-conf) configuration file:
include
@@ -2194,7 +2194,7 @@ contributed by community members.
These check commands assume that the global constant named `PluginContribDir`
is set to the path where the user installs custom plugins and can be enabled by
-uncommenting the corresponding line in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf):
+uncommenting the corresponding line in [icinga2.conf](04-configuration.md#icinga2-conf):
```
vim /etc/icinga2/icinga2.conf
diff --git a/doc/14-features.md b/doc/14-features.md
index dff90cd9b..b7c93f45c 100644
--- a/doc/14-features.md
+++ b/doc/14-features.md
@@ -50,7 +50,7 @@ The IDO (Icinga Data Output) feature for Icinga 2 takes care of exporting all
configuration and status information into a database. The IDO database is used
by Icinga Web 2 as data backend.
-Details on the installation can be found in the [Configuring DB IDO](02-getting-started.md#configuring-db-ido-mysql)
+Details on the installation can be found in the [Configuring DB IDO](02-installation.md#configuring-db-ido-mysql)
chapter. Details on the configuration can be found in the
[IdoMysqlConnection](09-object-types.md#objecttype-idomysqlconnection) and
[IdoPgsqlConnection](09-object-types.md#objecttype-idopgsqlconnection)
@@ -736,7 +736,7 @@ Livestatus.
>
> Only install the Livestatus feature if your web interface or addon requires
> you to do so.
-> [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2) does not need
+> [Icinga Web 2](02-installation.md#setting-up-icingaweb2) does not need
> Livestatus.
Details on the available tables and attributes with Icinga 2 can be found
diff --git a/doc/15-troubleshooting.md b/doc/15-troubleshooting.md
index 216fbd975..44310ba36 100644
--- a/doc/15-troubleshooting.md
+++ b/doc/15-troubleshooting.md
@@ -22,8 +22,8 @@ findings and details please.
* [Icinga Web 2 modules](https://icinga.com/products/icinga-web-2-modules/) e.g. the Icinga Director (optional)
* Configuration insights:
* Provide complete configuration snippets explaining your problem in detail
- * Your [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) file
- * If you run multiple Icinga 2 instances, the [zones.conf](04-configuring-icinga-2.md#zones-conf) file (or `icinga2 object list --type Endpoint` and `icinga2 object list --type Zone`) from all affected nodes.
+ * Your [icinga2.conf](04-configuration.md#icinga2-conf) file
+ * If you run multiple Icinga 2 instances, the [zones.conf](04-configuration.md#zones-conf) file (or `icinga2 object list --type Endpoint` and `icinga2 object list --type Zone`) from all affected nodes.
* Logs
* Relevant output from your main and [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) in `/var/log/icinga2`. Please add step-by-step explanations with timestamps if required.
* The newest Icinga 2 crash log if relevant, located in `/var/log/icinga2/crash`
@@ -237,7 +237,7 @@ include
include
```
-in the [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered
+in the [icinga2.conf](04-configuration.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 `/usr/share/icinga2/includes` with the constant `IncludeConfDir`.
@@ -248,7 +248,7 @@ or similar.
* Make sure that the line(s) are not [commented out](17-language-reference.md#comments) (starting with `//` or `#`, or
encapsulated by `/* ... */`).
-* Is the configuration file included in [icinga2.conf](04-configuring-icinga-2.md#icinga2-conf)?
+* Is the configuration file included in [icinga2.conf](04-configuration.md#icinga2-conf)?
Run the [configuration validation](11-cli-commands.md#config-validation) and add `notice` as log severity.
Search for the file which should be included i.e. using the `grep` CLI command.
@@ -481,7 +481,7 @@ critical thresholds are sometimes to applied and unwanted notification
alerts are raised.
This happens because the client itself includes a host object with
-its `NodeName` and a basic set of checks in the [conf.d](04-configuring-icinga-2.md#conf-d)
+its `NodeName` and a basic set of checks in the [conf.d](04-configuration.md#conf-d)
directory, i.e. `disk` with the default thresholds.
Clients which have the `checker` feature enabled will attempt
@@ -494,7 +494,7 @@ master you will receive wrong check results from the client.
Solution:
* Disable the `checker` feature on clients: `icinga2 feature disable checker`.
-* Remove the inclusion of [conf.d](04-configuring-icinga-2.md#conf-d) as suggested in the [client setup docs](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint).
+* Remove the inclusion of [conf.d](04-configuration.md#conf-d) as suggested in the [client setup docs](06-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint).
### Check Fork Errors
@@ -712,7 +712,7 @@ $ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://local
### 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](04-configuring-icinga-2.md#icinga2-conf).
+to `features-enabled` and that the latter is included in [icinga2.conf](04-configuration.md#icinga2-conf).
* Are the feature attributes set correctly according to the documentation?
* Any errors on the logs?
@@ -1236,7 +1236,7 @@ certificate's CN, the master will deny all events.
> **Tip**
>
-> [Icinga Web 2](02-getting-started.md#setting-up-icingaweb2) provides a dashboard view
+> [Icinga Web 2](02-installation.md#setting-up-icingaweb2) provides a dashboard view
> for overdue check results.
Enable the [debug log](15-troubleshooting.md#troubleshooting-enable-debug-output) on the master
@@ -1281,7 +1281,7 @@ Icinga 2 requires the `NodeName` [constant](17-language-reference.md#constants)
This includes loading the TLS certificates, setting the proper check source,
and so on.
-Typically the Windows setup wizard and also the CLI commands populate the [constants.conf](04-configuring-icinga-2.md#constants-conf)
+Typically the Windows setup wizard and also the CLI commands populate the [constants.conf](04-configuration.md#constants-conf)
file with the auto-detected or user-provided FQDN/Common Name.
If this constant is not set during startup, Icinga will try to resolve the
diff --git a/doc/16-upgrading-icinga-2.md b/doc/16-upgrading-icinga-2.md
index 3f5ba1017..756604f8b 100644
--- a/doc/16-upgrading-icinga-2.md
+++ b/doc/16-upgrading-icinga-2.md
@@ -234,7 +234,7 @@ for `ca list`.
The deprecated `concurrent_checks` attribute in the [checker feature](09-object-types.md#objecttype-checkercomponent)
has no effect anymore if set. Please use the [MaxConcurrentChecks](17-language-reference.md#icinga-constants-global-config)
-constant in [constants.conf](04-configuring-icinga-2.md#constants-conf) instead.
+constant in [constants.conf](04-configuration.md#constants-conf) instead.
### REST API
diff --git a/doc/17-language-reference.md b/doc/17-language-reference.md
index 55c73ec58..541c51aee 100644
--- a/doc/17-language-reference.md
+++ b/doc/17-language-reference.md
@@ -473,7 +473,7 @@ once they are set.
> **Tip**
>
-> Best practice is to manage constants in the [constants.conf](04-configuring-icinga-2.md#constants-conf) file.
+> Best practice is to manage constants in the [constants.conf](04-configuration.md#constants-conf) file.
### Icinga 2 Specific Constants
diff --git a/doc/21-development.md b/doc/21-development.md
index 382cf5737..16104ac73 100644
--- a/doc/21-development.md
+++ b/doc/21-development.md
@@ -432,7 +432,7 @@ on GitHub and mention that you're testing the snapshot packages.
#### RHEL/CentOS
-2.11+ requires the [EPEL repository](02-getting-started.md#package-repositories-rhel-epel) for Boost 1.66+.
+2.11+ requires the [EPEL repository](02-installation.md#package-repositories-rhel-epel) for Boost 1.66+.
In addition to that, the `icinga-rpm-release` package already provides the `icinga-snapshot-builds`
repository but it is disabled by default.
diff --git a/doc/23-migrating-from-icinga-1x.md b/doc/23-migrating-from-icinga-1x.md
index 8ae0aaa17..f0df9d019 100644
--- a/doc/23-migrating-from-icinga-1x.md
+++ b/doc/23-migrating-from-icinga-1x.md
@@ -810,7 +810,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](04-configuring-icinga-2.md#templates-conf) file.
+> the [templates.conf](04-configuration.md#templates-conf) file.
### Main Config File
@@ -818,7 +818,7 @@ In Icinga 1.x there are many global configuration settings available in `icinga.
Icinga 2 only uses a small set of [global constants](17-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](04-configuring-icinga-2.md#icinga2-conf) should take care of including
+Aside from that, the [icinga2.conf](04-configuration.md#icinga2-conf) should take care of including
global constants, enabled [features](11-cli-commands.md#enable-features) and the object configuration.
### Include Files and Directories