# Getting Started <a id="getting-started"></a>
-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
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
```
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:
`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.
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 <a id="configuring-db-ido-mysql"></a>
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 <a id="configuring-db-ido-postgresql"></a>
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 <a id="icinga2-user-interface-webserver"></a>
### Apply Services to Hosts <a id="using-apply-services"></a>
-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`.
### Apply Recurring Downtimes to Hosts and Services <a id="using-apply-scheduledowntimes"></a>
-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.
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:
> **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"
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**
#### Integrate the Plugin with a CheckCommand Definition <a id="command-plugin-integration"></a>
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
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
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.
```
```
-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" {
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:
* 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.
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 <a id="constants-conf"></a>
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
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.
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 <a id="hosts-conf"></a>
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.
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.
```
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**
>
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"
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):
```
...
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
#### users.conf <a id="users-conf"></a>
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" {
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 {
#### commands.conf <a id="commands-conf"></a>
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).
#### downtimes.conf <a id="downtimes-conf"></a>
-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
```
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:
```
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).
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.
* 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:
```
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
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.
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.
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.
## SNMP <a id="agent-based-checks-snmp"></a>
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.
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" {
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.
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:
## Generic Templates <a id="itl-generic-templates"></a>
-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 <itl>
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 <plugins>
`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
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 <nscp>
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++"
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 <manubulon>
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
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)
>
> 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
* [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`
include <plugins>
```
-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`.
* 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.
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
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 <a id="check-fork-errors"></a>
### Feature is not working <a id="feature-not-working"></a>
* 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?
> **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
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
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 <a id="upgrading-to-2-11-api"></a>
> **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 <a id="icinga-constants"></a>
#### RHEL/CentOS <a id="development-tests-snapshot-packages-rhel"></a>
-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.
> **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 <a id="differences-1x-2-main-config"></a>
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 <a id="differences-1x-2-include-files-dirs"></a>
projects / icinga2 / commitdiff