mirror of https://github.com/Icinga/icinga2.git
Docs: Update URLs from rename
This commit is contained in:
Michael Friedrich
parent
6cc8443bad
commit
36140fd17e
|
|
@ -1,7 +1,7 @@
|
|||
# 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
|
||||
|
|
@ -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 <a id="configuring-db-ido-mysql"></a>
|
||||
|
||||
|
|
@ -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 <a id="configuring-db-ido-postgresql"></a>
|
||||
|
||||
|
|
@ -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 <a id="icinga2-user-interface-webserver"></a>
|
||||
|
||||
|
|
|
|||
|
|
@ -867,8 +867,8 @@ More advanced examples are covered [here](08-advanced-topics.md#use-functions-as
|
|||
|
||||
### 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`.
|
||||
|
|
@ -964,7 +964,7 @@ Detailed examples can be found in the [dependencies](03-monitoring-basics.md#dep
|
|||
|
||||
### 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.
|
||||
|
||||
|
|
@ -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 <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
|
||||
|
|
@ -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" {
|
||||
|
|
|
|||
|
|
@ -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 <a id="constants-conf"></a>
|
||||
|
|
@ -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 <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.
|
||||
|
||||
|
|
@ -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 <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" {
|
||||
|
|
@ -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 <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).
|
||||
|
|
@ -680,7 +680,7 @@ More details on `Notification` object attributes can be found [here](09-object-t
|
|||
|
||||
#### 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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ become handy.
|
|||
## 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.
|
||||
|
||||
|
|
@ -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" {
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ You are advised to create your own CheckCommand definitions in
|
|||
|
||||
## 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>
|
||||
|
|
@ -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 <plugins>
|
||||
|
|
@ -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 <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++"
|
||||
|
|
@ -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 <manubulon>
|
||||
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 <itl>
|
|||
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`.
|
||||
|
||||
|
|
@ -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 <a id="check-fork-errors"></a>
|
||||
|
||||
|
|
@ -712,7 +712,7 @@ $ curl -k -s -u root:icinga -H 'Accept: application/json' -X POST 'https://local
|
|||
### 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?
|
||||
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 <a id="upgrading-to-2-11-api"></a>
|
||||
|
||||
|
|
|
|||
|
|
@ -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 <a id="icinga-constants"></a>
|
||||
|
||||
|
|
|
|||
|
|
@ -432,7 +432,7 @@ on GitHub and mention that you're testing the snapshot packages.
|
|||
|
||||
#### 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.
|
||||
|
|
|
|||
|
|
@ -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 <a id="differences-1x-2-main-config"></a>
|
||||
|
||||
|
|
@ -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 <a id="differences-1x-2-include-files-dirs"></a>
|
||||
|
|
|
|||
Loading…
Reference in New Issue