* Generate a new CSR, sign it with the local CA and copying it into `/etc/icinga2/pki`
* Generate a local zone and endpoint configuration for this master based on FQDN
* Enabling the API feature, and setting optional `bind_host` and `bind_port`
-* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](5-configuring-icinga-2.md#constants-conf)
+* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](4-configuring-icinga-2.md#constants-conf)
The setup wizard does not automatically restart Icinga 2.
If your remote clients are capable of connecting to the central master, Icinga 2
supports CSR auto-signing.
-First you'll need to define a secure ticket salt in the [constants.conf](5-configuring-icinga-2.md#constants-conf).
+First you'll need to define a secure ticket salt in the [constants.conf](4-configuring-icinga-2.md#constants-conf).
The [setup wizard for the master setup](10-icinga2-client.md#icinga2-client-installation-master-setup) will create
one for you already.
> **Note**
>
> You can omit the `--salt` parameter using the `TicketSalt` constant from
-> [constants.conf](5-configuring-icinga-2.md#constants-conf) if already defined and Icinga 2 was
+> [constants.conf](4-configuring-icinga-2.md#constants-conf) if already defined and Icinga 2 was
> reloaded after the master setup.
### <a id="certificates-manual-creation"></a> Manual SSL Certificate Generation
(based on FQDN)
* Disabling the `notification` feature for this client
* Enabling the `api` feature, and setting optional `bind_host` and `bind_port`
-* Setting the `NodeName` constant in [constants.conf](5-configuring-icinga-2.md#constants-conf)
+* Setting the `NodeName` constant in [constants.conf](4-configuring-icinga-2.md#constants-conf)
The setup wizard does not automatically restart Icinga 2.
attribute accordingly.
You should remove the sample config included in `conf.d` by commenting the `recursive_include`
-statement in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf):
+statement in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf):
//include_recursive "conf.d"
> **Note**
>
-> `zones.d` must not be included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically
+> `zones.d` must not be included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically
> determines the required include directory. This can be overridden using the
> [global constant](19-language-reference.md#constants) `ZonesDir`.
By default Icinga 2 and its features will place their runtime data below the prefix
`LocalStateDir`. By default packages will set that path to `/var`.
You can either set that variable as constant configuration
-definition in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) or pass it as runtime variable to
+definition in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) or pass it as runtime variable to
the Icinga 2 daemon.
# icinga2 -c /etc/icinga2/node1/icinga2.conf -DLocalStateDir=/opt/node1/var
If you're planning to use it configure it to use the
[bulk mode with npcd and npcdmod](http://docs.pnp4nagios.org/pnp-0.6/modes#bulk_mode_with_npcd_and_npcdmod)
-in combination with Icinga 2's [PerfdataWriter](4-advanced-topics.md#performance-data). NPCD collects the performance
+in combination with Icinga 2's [PerfdataWriter](5-advanced-topics.md#performance-data). NPCD collects the performance
data files which Icinga 2 generates.
Enable performance data writer in icinga 2
* whisper - a simple database library for storing time-series data (similar in design to RRD)
* graphite webapp - A Django webapp that renders graphs on-demand using Cairo
-Use the [GraphiteWriter](4-advanced-topics.md#graphite-carbon-cache-writer) feature
+Use the [GraphiteWriter](5-advanced-topics.md#graphite-carbon-cache-writer) feature
for sending real-time metrics from Icinga 2 to Graphite.
# icinga2 feature enable graphite
### <a id="addons-graphing-ingraph"></a> inGraph
[inGraph](https://www.netways.org/projects/ingraph/wiki) requires the ingraph-collector addon
-to be configured to point at the perfdata files. Icinga 2's [PerfdataWriter](4-advanced-topics.md#performance-data) will
+to be configured to point at the perfdata files. Icinga 2's [PerfdataWriter](5-advanced-topics.md#performance-data) will
write to the performance data spool directory.
## <a id="addons-visualization"></a> Visualization
* [Icinga Wiki](https://wiki.icinga.org)
The recommended way of setting up these plugins is to copy them to a common directory
-and create a new global constant, e.g. `CustomPluginDir` in your [constants.conf](5-configuring-icinga-2.md#constants-conf)
+and create a new global constant, e.g. `CustomPluginDir` in your [constants.conf](4-configuring-icinga-2.md#constants-conf)
configuration file:
# cp check_snmp_int.pl /opt/monitoring/plugins
fix this:
* Create a symlink for example from the `templates.dist/check_ping.php` template to the actual check name in Icinga 2 (`templates/ping4.php`)
-* Pass the check command name inside the [format template configuration](4-advanced-topics.md#writing-performance-data-files)
+* Pass the check command name inside the [format template configuration](5-advanced-topics.md#writing-performance-data-files)
The latter becomes difficult with agent based checks like NRPE or SSH where the first command argument acts as
graph template identifier. There is the possibility to define the pnp template name as custom attribute
## <a id="setting-up-icinga-classic-ui"></a> Setting up Icinga Classic UI 1.x
Icinga 2 can write `status.dat` and `objects.cache` files in the format that
-is supported by the Icinga 1.x Classic UI. [External commands](4-advanced-topics.md#external-commands)
+is supported by the Icinga 1.x Classic UI. [External commands](5-advanced-topics.md#external-commands)
(a.k.a. the "command pipe") are also supported. It also supports writing Icinga 1.x
log files which are required for the reporting functionality in the Classic UI.
On all distributions other than Debian you may have to restart both your web
server as well as Icinga 2 after installing the Classic UI package.
-Icinga Classic UI requires the [StatusDataWriter](4-advanced-topics.md#status-data), [CompatLogger](4-advanced-topics.md#compat-logging)
-and [ExternalCommandListener](4-advanced-topics.md#external-commands) features.
+Icinga Classic UI requires the [StatusDataWriter](5-advanced-topics.md#status-data), [CompatLogger](5-advanced-topics.md#compat-logging)
+and [ExternalCommandListener](5-advanced-topics.md#external-commands) features.
Enable these features and restart Icinga 2.
# icinga2 feature enable statusdata compatlog command
# icinga-web-clearcache
-Additionally you need to enable the `command` feature for sending [external commands](4-advanced-topics.md#external-commands):
+Additionally you need to enable the `command` feature for sending [external commands](5-advanced-topics.md#external-commands):
# icinga2 feature enable command
include <itl>
include <plugins>
-in the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden
+in the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden
on upgrade, so please send modifications as proposed patches upstream. The default include path is set to
`LocalStateDir + "/share/icinga2/includes"`.
## <a id="feature-not-working"></a> Feature is not working
* Make sure that the feature configuration is enabled by symlinking from `features-available/`
-to `features-enabled` and that the latter is included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf).
+to `features-enabled` and that the latter is included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf).
* Are the feature attributes set correctly according to the documentation?
* Any errors on the logs?
* Make sure that the line(s) are not [commented out](19-language-reference.md#comments) (starting with `//` or `#`, or
encapsulated by `/* ... */`).
-* Is the configuration file included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf)?
+* Is the configuration file included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf)?
## <a id="configuration-attribute-inheritance"></a> Configuration attributes are inherited from
> **Note**
>
> Add your own custom templates in the `conf.d/` directory as well, e.g. inside
-> the [templates.conf](5-configuring-icinga-2.md#templates-conf) file.
+> the [templates.conf](4-configuring-icinga-2.md#templates-conf) file.
### <a id="differences-1x-2-main-config"></a> Main Config File
Icinga 2 only uses a small set of [global constants](19-language-reference.md#constants) allowing
you to specify certain different setting such as the `NodeName` in a cluster scenario.
-Aside from that, the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) should take care of including
+Aside from that, the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) should take care of including
global constants, enabled [features](8-cli-commands.md#features) and the object configuration.
### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories
OS X (MacPorts) | nagios-plugins | /opt/local/libexec
Depending on which directory your plugins are installed into you may need to
-update the global `PluginDir` constant in your [Icinga 2 configuration](5-configuring-icinga-2.md#constants-conf).
+update the global `PluginDir` constant in your [Icinga 2 configuration](4-configuring-icinga-2.md#constants-conf).
This constant is used by the check command definitions contained in the Icinga Template Library
to determine where to find the plugin binaries.
}}
Acessing object attributes at runtime inside these functions is described in the
-[advanced topics](4-advanced-topics.md#access-object-attributes-at-runtime) chapter.
+[advanced topics](5-advanced-topics.md#access-object-attributes-at-runtime) chapter.
## <a id="runtime-macros"></a> Runtime Macros
Before you start using the apply rules keep the following in mind:
* Define the best match.
- * A set of unique [custom attributes](#custom-attributes-apply) for these hosts/services?
+ * A set of unique [custom attributes](3-monitoring-basics.md#custom-attributes) for these hosts/services?
* Or [group](3-monitoring-basics.md#groups) memberships, e.g. a host being a member of a hostgroup, applying services to it?
* A generic pattern [match](19-language-reference.md#function-calls) on the host/service name?
* [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](19-language-reference.md#expression-operators)
A more advanced example is using [apply with for loops on arrays or
dictionaries](#using-apply-for) for example provided by
-[custom atttributes](#custom-attributes-apply) or groups.
+[custom atttributes](3-monitoring-basics.md#custom-attributes) or groups.
> **Tip**
>
### <a id="using-apply-services"></a> Apply Services to Hosts
-The sample configuration already includes a detailed example in [hosts.conf](5-configuring-icinga-2.md#hosts-conf)
-and [services.conf](5-configuring-icinga-2.md#services-conf) for this use case.
+The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
+and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
The example for `ssh` applies a service object to all hosts with the `address`
attribute being defined and the custom attribute `os` set to the string `Linux` in `vars`.
Other detailed scenario examples are used in their respective chapters, for example
-[apply services with custom command arguments](#using-apply-services-command-arguments).
+[apply services with custom command arguments](3-monitoring-basics.md#command-passing-parameters).
### <a id="using-apply-notifications"></a> Apply Notifications to Hosts and Services
### <a id="using-apply-scheduledowntimes"></a> Apply Recurring Downtimes to Hosts and Services
-The sample configuration includes an example in [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf).
+The sample configuration includes an example in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf).
-Detailed examples can be found in the [recurring downtimes](4-advanced-topics.md#recurring-downtimes) chapter.
+Detailed examples can be found in the [recurring downtimes](5-advanced-topics.md#recurring-downtimes) chapter.
### <a id="using-apply-for"></a> Using Apply For Rules
there is the requirement of generating apply rules objects based on set (array or
dictionary).
-The sample configuration already includes a detailed example in [hosts.conf](5-configuring-icinga-2.md#hosts-conf)
-and [services.conf](5-configuring-icinga-2.md#services-conf) for this use case.
+The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
+and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case.
Take the following example: A host provides the snmp oids for different service check
types. This could look like the following example:
dynamically generated
-Tip: Define the snmp community as global constant in your [constants.conf](5-configuring-icinga-2.md#constants-conf) file.
+Tip: Define the snmp community as global constant in your [constants.conf](4-configuring-icinga-2.md#constants-conf) file.
const IftrafficSnmpCommunity = "public"
This example makes use of the [check_iftraffic](https://exchange.icinga.org/exchange/iftraffic) plugin.
The `CheckCommand` definition can be found in the
[contributed plugin check commands](7-icinga-template-library.md#plugins-contrib-command-iftraffic)
-- make sure to include them in your [icinga2 configuration file](5-configuring-icinga-2.md#icinga2-conf).
+- make sure to include them in your [icinga2 configuration file](4-configuring-icinga-2.md#icinga2-conf).
> **Tip**
vars.mobile = "+1 555 424642"
}
-Define an additional [NotificationCommand](#notification) for SMS notifications.
+Define an additional [NotificationCommand](3-monitoring-basics.md#notification-commands) for SMS notifications.
> **Note**
>
`plugin-check-command` to support native plugin based check methods.
Unless you have done so already, download your check plugin and put it
-into the [PluginDir](5-configuring-icinga-2.md#constants-conf) directory. The following example uses the
+into the [PluginDir](4-configuring-icinga-2.md#constants-conf) directory. The following example uses the
`check_disk` plugin contained in the Monitoring Plugins package.
The plugin path and all command arguments are made a list of
More details on using arrays in custom attributes can be found in
-[this chapter](#runtime-custom-attributes).
+[this chapter](3-monitoring-basics.md#custom-attributes).
#### <a id="command-arguments"></a> Command Arguments
Then you should look for the object specific configuration setting `host_name` etc accordingly.
Finding the best files and directory tree for your configuration is up to you. Make sure that
-the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file includes them,
+the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file includes them,
and then think about:
* tree-based on locations, hostgroups, specific host attributes with sub levels of directories.
* Put hosts into hostgroups, services into servicegroups and use these attributes for your apply rules.
* Use templates to store generic attributes for your objects and apply rules making your configuration more readable.
Details can be found in the [using templates](3-monitoring-basics.md#object-inheritance-using-templates) chapter.
-* Apply rules may overlap. Keep a central place (for example, [services.conf](5-configuring-icinga-2.md#services-conf) or [notifications.conf](5-configuring-icinga-2.md#notifications-conf)) storing
+* Apply rules may overlap. Keep a central place (for example, [services.conf](4-configuring-icinga-2.md#services-conf) or [notifications.conf](4-configuring-icinga-2.md#notifications-conf)) storing
the configuration instead of defining apply rules deep in your configuration tree.
* Every plugin used as check, notification or event command requires a `Command` definition.
Further details can be looked up in the [check commands](3-monitoring-basics.md#check-commands) chapter.
*/
include_recursive "conf.d"
-You can put your own configuration files in the [conf.d](5-configuring-icinga-2.md#conf-d) directory. This
+You can put your own configuration files in the [conf.d](4-configuring-icinga-2.md#conf-d) directory. This
directive makes sure that all of your own configuration files are included.
### <a id="constants-conf"></a> constants.conf
This directory contains example configuration which should help you get started
with monitoring the local host and its services. It is included in the
-[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file by default.
+[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file by default.
It can be used as reference example for your own configuration strategy.
Just keep in mind to include the main directories in the
-[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) file.
+[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) file.
You are certainly not bound to it. Remove it, if you prefer your own
way of deploying Icinga 2 configuration.
Further details on configuration best practice and how to build your
-own strategy is described in [this chapter](5-configuring-icinga-2.md#configuration-best-practice).
+own strategy is described in [this chapter](4-configuring-icinga-2.md#configuration-best-practice).
Available configuration files which are installed by default:
-* [hosts.conf](5-configuring-icinga-2.md#hosts-conf)
-* [services.conf](5-configuring-icinga-2.md#services-conf)
-* [users.conf](5-configuring-icinga-2.md#users-conf)
-* [notifications.conf](5-configuring-icinga-2.md#notifications-conf)
-* [commands.conf](5-configuring-icinga-2.md#commands-conf)
-* [groups.conf](5-configuring-icinga-2.md#groups-conf)
-* [templates.conf](5-configuring-icinga-2.md#templates-conf)
-* [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf)
-* [timeperiods.conf](5-configuring-icinga-2.md#timeperiods-conf)
-* [satellite.conf](5-configuring-icinga-2.md#satellite-conf)
+* [hosts.conf](4-configuring-icinga-2.md#hosts-conf)
+* [services.conf](4-configuring-icinga-2.md#services-conf)
+* [users.conf](4-configuring-icinga-2.md#users-conf)
+* [notifications.conf](4-configuring-icinga-2.md#notifications-conf)
+* [commands.conf](4-configuring-icinga-2.md#commands-conf)
+* [groups.conf](4-configuring-icinga-2.md#groups-conf)
+* [templates.conf](4-configuring-icinga-2.md#templates-conf)
+* [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf)
+* [timeperiods.conf](4-configuring-icinga-2.md#timeperiods-conf)
+* [satellite.conf](4-configuring-icinga-2.md#satellite-conf)
#### <a id="hosts-conf"></a> hosts.conf
The `hosts.conf` file contains an example host based on your
-`NodeName` setting in [constants.conf](5-configuring-icinga-2.md#constants-conf). You
+`NodeName` setting in [constants.conf](4-configuring-icinga-2.md#constants-conf). You
can use global constants for your object names instead of string
values.
in the Icinga Template Library require an `address` attribute.
The custom attribute `os` is evaluated by the `linux-servers` group in
-[groups.conf](5-configuring-icinga-2.md#groups-conf) making the local host a member.
+[groups.conf](4-configuring-icinga-2.md#groups-conf) making the local host a member.
The example host will show you how to
* define http vhost attributes for the `http` service apply rule defined
-in [services.conf](5-configuring-icinga-2.md#services-conf).
+in [services.conf](4-configuring-icinga-2.md#services-conf).
* define disks (all, specific `/`) and their attributes for the `disk`
-service apply rule defined in [services.conf](5-configuring-icinga-2.md#services-conf).
+service apply rule defined in [services.conf](4-configuring-icinga-2.md#services-conf).
* define notification types (`mail`) and set the groups attribute. This
will be used by notification apply rules in [notifications.conf](notifications-conf).
If you've installed [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2) you can
uncomment the http vhost attributes and reload Icinga 2. The apply
-rules in [services.conf](5-configuring-icinga-2.md#services-conf) will automatically
+rules in [services.conf](4-configuring-icinga-2.md#services-conf) will automatically
generate a new service checking the `/icingaweb2` URI using the `http`
check.
}
This is only the host object definition. Now we'll need to make sure that this
-host and your additional hosts are getting [services](5-configuring-icinga-2.md#services-conf) applied.
+host and your additional hosts are getting [services](4-configuring-icinga-2.md#services-conf) applied.
> **Tip**
>
The custom attribe `backup_downtime` is defined to a specific timerange string.
This variable value will be used for applying a `ScheduledDowntime` object to
-these services in [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf).
+these services in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf).
In this example the `assign where` condition is a boolean expression which is
evaluated for all objects of type `Host` and a new service with name "load"
hosts, you can go one step further: Generate apply rules based on array items
or dictionary key-value pairs.
-The idea is simple: Your host in [hosts.conf](5-configuring-icinga-2.md#hosts-conf) defines the
+The idea is simple: Your host in [hosts.conf](4-configuring-icinga-2.md#hosts-conf) defines the
`disks` dictionary as custom attribute in `vars`.
-Remember the example from [hosts.conf](5-configuring-icinga-2.md#hosts-conf):
+Remember the example from [hosts.conf](4-configuring-icinga-2.md#hosts-conf):
...
host the information provider for all apply rules. Define them once, and only
manage your hosts.
-Look into [notifications.conf](5-configuring-icinga-2.md#notifications-conf) how this technique is used
+Look into [notifications.conf](4-configuring-icinga-2.md#notifications-conf) how this technique is used
for applying notifications to hosts and services using their type and user
attributes.
#### <a id="users-conf"></a> users.conf
Defines the `icingaadmin` User and the `icingaadmins` UserGroup. The latter is used in
-[hosts.conf](5-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in
-[notifications.conf](5-configuring-icinga-2.md#notifications-conf) for notification apply rules.
+[hosts.conf](4-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in
+[notifications.conf](4-configuring-icinga-2.md#notifications-conf) for notification apply rules.
object User "icingaadmin" {
import "generic-user"
Please note that the `to` keyword is important in [notification apply rules](3-monitoring-basics.md#using-apply-notifications)
defining whether these notifications are applies to hosts or services.
-The `import` keyword imports the specific mail templates defined in [templates.conf](5-configuring-icinga-2.md#templates-conf).
+The `import` keyword imports the specific mail templates defined in [templates.conf](4-configuring-icinga-2.md#templates-conf).
The `interval` attribute is not explicitly set - it [defaults to 30 minutes](6-object-types.md#objecttype-notification).
By setting the `user_groups` to the value provided by the
-respective [host.vars.notification.mail](5-configuring-icinga-2.md#hosts-conf) attribute we'll
-implicitely use the `icingaadmins` UserGroup defined in [users.conf](5-configuring-icinga-2.md#users-conf).
+respective [host.vars.notification.mail](4-configuring-icinga-2.md#hosts-conf) attribute we'll
+implicitely use the `icingaadmins` UserGroup defined in [users.conf](4-configuring-icinga-2.md#users-conf).
apply Notification "mail-icingaadmin" to Host {
import "mail-host-notification"
### <a id="commands-conf"></a> commands.conf
This is the place where your own command configuration can be defined. By default
-only the notification commands used by the notification templates defined in [templates.conf](5-configuring-icinga-2.md#templates-conf).
+only the notification commands used by the notification templates defined in [templates.conf](4-configuring-icinga-2.md#templates-conf).
You can freely customize these notification commands, and adapt them for your needs.
Read more on that topic [here](3-monitoring-basics.md#notification-commands).
#### <a id="downtimes-conf"></a> downtimes.conf
-The `load` service apply rule defined in [services.conf](5-configuring-icinga-2.md#services-conf) defines
+The `load` service apply rule defined in [services.conf](4-configuring-icinga-2.md#services-conf) defines
the `backup_downtime` custom attribute.
The [ScheduledDowntime](6-object-types.md#objecttype-scheduleddowntime) apply rule uses this attribute
### <a id="scheduling-downtime"></a> Scheduling a downtime
-This can either happen through a web interface or by sending an [external command](4-advanced-topics.md#external-commands)
+This can either happen through a web interface or by sending an [external command](5-advanced-topics.md#external-commands)
to the external command pipe provided by the `ExternalCommandListener` configuration.
Fixed downtimes require a start and end time (a duration will be ignored).
The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a
[global constant](19-language-reference.md#constants) named `GraphiteEnv`. The constant name
-is freely definable and should be put in the [constants.conf](5-configuring-icinga-2.md#constants-conf) file.
+is freely definable and should be put in the [constants.conf](4-configuring-icinga-2.md#constants-conf) file.
const GraphiteEnv = "icinga.env1"
ApiListener objects are used for distributed monitoring setups
specifying the certificate files used for ssl authorization.
-The `NodeName` constant must be defined in [constants.conf](5-configuring-icinga-2.md#constants-conf).
+The `NodeName` constant must be defined in [constants.conf](4-configuring-icinga-2.md#constants-conf).
Example:
log_duration |**Optional.** Duration for keeping replay logs on connection loss. Defaults to `1d`.
-## <a id="objecttype-zone"></a> Zone
-
-Zone objects are used to specify which Icinga 2 instances are located in a zone.
-
-Example:
-
- object Zone "config-ha-master" {
- endpoints = [ "icinga2a", "icinga2b" ]
-
- }
-
- object Zone "check-satellite" {
- endpoints = [ "icinga2c" ]
- parent = "config-ha-master"
- }
-
-Configuration Attributes:
-
- Name |Description
- ----------------|----------------
- endpoints |**Optional.** Dictionary with endpoints located in this zone.
- parent |**Optional.** The name of the parent zone.
- global |**Optional.** Whether configuration files for this zone should be synced to all endpoints. Defaults to false.
-
-
## <a id="objecttype-eventcommand"></a> EventCommand
An event command definition.
> to just create a `ScheduledDowntime` template and use the `apply` keyword to assign the
> scheduled downtime to a number of hosts or services. Use the `to` keyword to set the specific target
> type for `Host` or `Service`.
-> Check the [recurring downtimes](4-advanced-topics.md#recurring-downtimes) example for details.
+> Check the [recurring downtimes](5-advanced-topics.md#recurring-downtimes) example for details.
Example:
Icinga 2 can use the `nscp client` command to run arbitrary NSClient++ checks.
You can enable these check commands by adding the following the include directive in your
-[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file:
+[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file:
include <nscp>
You can also optionally specify an alternative installation directory for NSClient++ by adding
-the NscpPath constant in your [constants.conf](5-configuring-icinga-2.md#constants-conf) configuration
+the NscpPath constant in your [constants.conf](4-configuring-icinga-2.md#constants-conf) configuration
file:
const NscpPath = "C:\\Program Files (x86)\\NSClient++"
is set to the path where the Manubublon SNMP plugins are installed.
You can enable these plugin check commands by adding the following the include directive in your
-[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file:
+[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file:
include <manubulon>
* [Icinga Wiki](https://wiki.icinga.org)
An example is provided in the sample configuration in the getting started
-section shipped with Icinga 2 ([hosts.conf](5-configuring-icinga-2.md#hosts-conf), [services.conf](5-configuring-icinga-2.md#services-conf)).
+section provided by Icinga 2 ([hosts.conf](4-configuring-icinga-2.md#hosts-conf), [services.conf](4-configuring-icinga-2.md#services-conf)).
## <a id="agent-based-checks"></a> Agent-based Checks
- [1-about.md, About Icinga 2]
- [2-getting-started.md, Getting Started]
- [3-monitoring-basics.md, Monitoring Basics]
-- [4-advanced-topics.md, Advanced Topics]
-- [5-configuring-icinga-2.md, Configuring Icinga 2]
+- [4-configuring-icinga-2.md, Configuring Icinga 2]
+- [5-advanced-topics.md, Advanced Topics]
- [6-object-types.md, Object Types]
- [7-icinga-template-library.md, Icinga Template Library]
- [8-cli-commands.md, CLI Commands]
projects / icinga2 / commitdiff