From: Michael Friedrich Date: Tue, 16 Jun 2015 14:01:02 +0000 (+0200) Subject: Documentation: Move configuration before advanced topics X-Git-Tag: v2.4.0~606 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;ds=sidebyside;h=d70a70753f46bfe40aebd18de6051f8325cce94d;p=icinga2 Documentation: Move configuration before advanced topics fixes #9431 --- diff --git a/doc/10-icinga2-client.md b/doc/10-icinga2-client.md index 0d0c22f89..599a46f48 100644 --- a/doc/10-icinga2-client.md +++ b/doc/10-icinga2-client.md @@ -115,7 +115,7 @@ The setup wizard will do the following: * Generate a new CSR, sign it with the local CA and copying it into `/etc/icinga2/pki` * Generate a local zone and endpoint configuration for this master based on FQDN * Enabling the API feature, and setting optional `bind_host` and `bind_port` -* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](5-configuring-icinga-2.md#constants-conf) +* Setting the `NodeName` and `TicketSalt` constants in [constants.conf](4-configuring-icinga-2.md#constants-conf) The setup wizard does not automatically restart Icinga 2. @@ -166,7 +166,7 @@ Your client setup requires the following If your remote clients are capable of connecting to the central master, Icinga 2 supports CSR auto-signing. -First you'll need to define a secure ticket salt in the [constants.conf](5-configuring-icinga-2.md#constants-conf). +First you'll need to define a secure ticket salt in the [constants.conf](4-configuring-icinga-2.md#constants-conf). The [setup wizard for the master setup](10-icinga2-client.md#icinga2-client-installation-master-setup) will create one for you already. @@ -187,7 +187,7 @@ Example for a client: > **Note** > > You can omit the `--salt` parameter using the `TicketSalt` constant from -> [constants.conf](5-configuring-icinga-2.md#constants-conf) if already defined and Icinga 2 was +> [constants.conf](4-configuring-icinga-2.md#constants-conf) if already defined and Icinga 2 was > reloaded after the master setup. ### Manual SSL Certificate Generation @@ -293,7 +293,7 @@ The setup wizard will do the following: (based on FQDN) * Disabling the `notification` feature for this client * Enabling the `api` feature, and setting optional `bind_host` and `bind_port` -* Setting the `NodeName` constant in [constants.conf](5-configuring-icinga-2.md#constants-conf) +* Setting the `NodeName` constant in [constants.conf](4-configuring-icinga-2.md#constants-conf) The setup wizard does not automatically restart Icinga 2. diff --git a/doc/12-distributed-monitoring-ha.md b/doc/12-distributed-monitoring-ha.md index 91690ed09..ef557cdf5 100644 --- a/doc/12-distributed-monitoring-ha.md +++ b/doc/12-distributed-monitoring-ha.md @@ -263,7 +263,7 @@ configuration from the parent zone. You can define that in the attribute accordingly. You should remove the sample config included in `conf.d` by commenting the `recursive_include` -statement in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf): +statement in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf): //include_recursive "conf.d" @@ -321,7 +321,7 @@ process. > **Note** > -> `zones.d` must not be included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically +> `zones.d` must not be included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf). Icinga 2 automatically > determines the required include directory. This can be overridden using the > [global constant](19-language-reference.md#constants) `ZonesDir`. @@ -811,7 +811,7 @@ Special scenarios might require multiple cluster nodes running on a single host. By default Icinga 2 and its features will place their runtime data below the prefix `LocalStateDir`. By default packages will set that path to `/var`. You can either set that variable as constant configuration -definition in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) or pass it as runtime variable to +definition in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) or pass it as runtime variable to the Icinga 2 daemon. # icinga2 -c /etc/icinga2/node1/icinga2.conf -DLocalStateDir=/opt/node1/var diff --git a/doc/13-addons-plugins.md b/doc/13-addons-plugins.md index 441eb80b7..b4da2afa4 100644 --- a/doc/13-addons-plugins.md +++ b/doc/13-addons-plugins.md @@ -13,7 +13,7 @@ Use your distribution's package manager to install the `pnp4nagios` package. If you're planning to use it configure it to use the [bulk mode with npcd and npcdmod](http://docs.pnp4nagios.org/pnp-0.6/modes#bulk_mode_with_npcd_and_npcdmod) -in combination with Icinga 2's [PerfdataWriter](4-advanced-topics.md#performance-data). NPCD collects the performance +in combination with Icinga 2's [PerfdataWriter](5-advanced-topics.md#performance-data). NPCD collects the performance data files which Icinga 2 generates. Enable performance data writer in icinga 2 @@ -45,7 +45,7 @@ Graphite consists of 3 software components: * whisper - a simple database library for storing time-series data (similar in design to RRD) * graphite webapp - A Django webapp that renders graphs on-demand using Cairo -Use the [GraphiteWriter](4-advanced-topics.md#graphite-carbon-cache-writer) feature +Use the [GraphiteWriter](5-advanced-topics.md#graphite-carbon-cache-writer) feature for sending real-time metrics from Icinga 2 to Graphite. # icinga2 feature enable graphite @@ -55,7 +55,7 @@ There are Graphite addons available for collecting the performance data files to ### 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. ## Visualization @@ -112,7 +112,7 @@ list of popular community sites which host check plugins: * [Icinga Wiki](https://wiki.icinga.org) The recommended way of setting up these plugins is to copy them to a common directory -and create a new global constant, e.g. `CustomPluginDir` in your [constants.conf](5-configuring-icinga-2.md#constants-conf) +and create a new global constant, e.g. `CustomPluginDir` in your [constants.conf](4-configuring-icinga-2.md#constants-conf) configuration file: # cp check_snmp_int.pl /opt/monitoring/plugins @@ -229,7 +229,7 @@ This behavior changed in Icinga 2 compared to Icinga 1.x. Though there are certa fix this: * Create a symlink for example from the `templates.dist/check_ping.php` template to the actual check name in Icinga 2 (`templates/ping4.php`) -* Pass the check command name inside the [format template configuration](4-advanced-topics.md#writing-performance-data-files) +* Pass the check command name inside the [format template configuration](5-advanced-topics.md#writing-performance-data-files) The latter becomes difficult with agent based checks like NRPE or SSH where the first command argument acts as graph template identifier. There is the possibility to define the pnp template name as custom attribute diff --git a/doc/14-alternative-frontends.md b/doc/14-alternative-frontends.md index 6f0c0db73..68a511789 100644 --- a/doc/14-alternative-frontends.md +++ b/doc/14-alternative-frontends.md @@ -3,7 +3,7 @@ ## Setting up Icinga Classic UI 1.x Icinga 2 can write `status.dat` and `objects.cache` files in the format that -is supported by the Icinga 1.x Classic UI. [External commands](4-advanced-topics.md#external-commands) +is supported by the Icinga 1.x Classic UI. [External commands](5-advanced-topics.md#external-commands) (a.k.a. the "command pipe") are also supported. It also supports writing Icinga 1.x log files which are required for the reporting functionality in the Classic UI. @@ -32,8 +32,8 @@ to satisfy this dependency: On all distributions other than Debian you may have to restart both your web server as well as Icinga 2 after installing the Classic UI package. -Icinga Classic UI requires the [StatusDataWriter](4-advanced-topics.md#status-data), [CompatLogger](4-advanced-topics.md#compat-logging) -and [ExternalCommandListener](4-advanced-topics.md#external-commands) features. +Icinga Classic UI requires the [StatusDataWriter](5-advanced-topics.md#status-data), [CompatLogger](5-advanced-topics.md#compat-logging) +and [ExternalCommandListener](5-advanced-topics.md#external-commands) features. Enable these features and restart Icinga 2. # icinga2 feature enable statusdata compatlog command @@ -104,7 +104,7 @@ found in the [Icinga Web documentation](http://docs.icinga.org/latest/en/icinga- # icinga-web-clearcache -Additionally you need to enable the `command` feature for sending [external commands](4-advanced-topics.md#external-commands): +Additionally you need to enable the `command` feature for sending [external commands](5-advanced-topics.md#external-commands): # icinga2 feature enable command diff --git a/doc/16-troubleshooting.md b/doc/16-troubleshooting.md index f72a50315..777f07244 100644 --- a/doc/16-troubleshooting.md +++ b/doc/16-troubleshooting.md @@ -102,7 +102,7 @@ included using include include -in the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden +in the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file. These files are not considered configuration files and will be overridden on upgrade, so please send modifications as proposed patches upstream. The default include path is set to `LocalStateDir + "/share/icinga2/includes"`. @@ -151,7 +151,7 @@ Examples: ## Feature is not working * Make sure that the feature configuration is enabled by symlinking from `features-available/` -to `features-enabled` and that the latter is included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf). +to `features-enabled` and that the latter is included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf). * Are the feature attributes set correctly according to the documentation? * Any errors on the logs? @@ -159,7 +159,7 @@ to `features-enabled` and that the latter is included in [icinga2.conf](5-config * Make sure that the line(s) are not [commented out](19-language-reference.md#comments) (starting with `//` or `#`, or encapsulated by `/* ... */`). -* Is the configuration file included in [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf)? +* Is the configuration file included in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf)? ## Configuration attributes are inherited from diff --git a/doc/18-migrating-from-icinga-1x.md b/doc/18-migrating-from-icinga-1x.md index 538155ef0..76e586cda 100644 --- a/doc/18-migrating-from-icinga-1x.md +++ b/doc/18-migrating-from-icinga-1x.md @@ -739,7 +739,7 @@ included in `icinga2.conf` by default. > **Note** > > Add your own custom templates in the `conf.d/` directory as well, e.g. inside -> the [templates.conf](5-configuring-icinga-2.md#templates-conf) file. +> the [templates.conf](4-configuring-icinga-2.md#templates-conf) file. ### Main Config File @@ -747,7 +747,7 @@ In Icinga 1.x there are many global configuration settings available in `icinga. Icinga 2 only uses a small set of [global constants](19-language-reference.md#constants) allowing you to specify certain different setting such as the `NodeName` in a cluster scenario. -Aside from that, the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) should take care of including +Aside from that, the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) should take care of including global constants, enabled [features](8-cli-commands.md#features) and the object configuration. ### Include Files and Directories diff --git a/doc/2-getting-started.md b/doc/2-getting-started.md index 2fa4c0ddd..2ec661b1b 100644 --- a/doc/2-getting-started.md +++ b/doc/2-getting-started.md @@ -154,7 +154,7 @@ FreeBSD | nagios-plugins | /usr/local/libexec/nagios OS X (MacPorts) | nagios-plugins | /opt/local/libexec Depending on which directory your plugins are installed into you may need to -update the global `PluginDir` constant in your [Icinga 2 configuration](5-configuring-icinga-2.md#constants-conf). +update the global `PluginDir` constant in your [Icinga 2 configuration](4-configuring-icinga-2.md#constants-conf). This constant is used by the check command definitions contained in the Icinga Template Library to determine where to find the plugin binaries. diff --git a/doc/3-monitoring-basics.md b/doc/3-monitoring-basics.md index 1af403ae7..9bddb34e6 100644 --- a/doc/3-monitoring-basics.md +++ b/doc/3-monitoring-basics.md @@ -197,7 +197,7 @@ value of arbitrary macro expressions: }} Acessing object attributes at runtime inside these functions is described in the -[advanced topics](4-advanced-topics.md#access-object-attributes-at-runtime) chapter. +[advanced topics](5-advanced-topics.md#access-object-attributes-at-runtime) chapter. ## Runtime Macros @@ -407,7 +407,7 @@ based on attribute identifiers for example `host_name` objects can be [applied]( Before you start using the apply rules keep the following in mind: * Define the best match. - * A set of unique [custom attributes](#custom-attributes-apply) for these hosts/services? + * A set of unique [custom attributes](3-monitoring-basics.md#custom-attributes) for these hosts/services? * Or [group](3-monitoring-basics.md#groups) memberships, e.g. a host being a member of a hostgroup, applying services to it? * A generic pattern [match](19-language-reference.md#function-calls) on the host/service name? * [Multiple expressions combined](3-monitoring-basics.md#using-apply-expressions) with `&&` or `||` [operators](19-language-reference.md#expression-operators) @@ -429,7 +429,7 @@ for not only matching for their existance or values in apply expressions, but al A more advanced example is using [apply with for loops on arrays or dictionaries](#using-apply-for) for example provided by -[custom atttributes](#custom-attributes-apply) or groups. +[custom atttributes](3-monitoring-basics.md#custom-attributes) or groups. > **Tip** > @@ -492,8 +492,8 @@ The notification is ignored for services whose host name ends with `*internal` ### Apply Services to Hosts -The sample configuration already includes a detailed example in [hosts.conf](5-configuring-icinga-2.md#hosts-conf) -and [services.conf](5-configuring-icinga-2.md#services-conf) for this use case. +The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf) +and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case. The example for `ssh` applies a service object to all hosts with the `address` attribute being defined and the custom attribute `os` set to the string `Linux` in `vars`. @@ -508,7 +508,7 @@ attribute being defined and the custom attribute `os` set to the string `Linux` Other detailed scenario examples are used in their respective chapters, for example -[apply services with custom command arguments](#using-apply-services-command-arguments). +[apply services with custom command arguments](3-monitoring-basics.md#command-passing-parameters). ### Apply Notifications to Hosts and Services @@ -535,9 +535,9 @@ Detailed examples can be found in the [dependencies](3-monitoring-basics.md#depe ### 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. ### Using Apply For Rules @@ -546,8 +546,8 @@ Next to the standard way of using [apply rules](3-monitoring-basics.md#using-app there is the requirement of generating apply rules objects based on set (array or dictionary). -The sample configuration already includes a detailed example in [hosts.conf](5-configuring-icinga-2.md#hosts-conf) -and [services.conf](5-configuring-icinga-2.md#services-conf) for this use case. +The sample configuration already includes a detailed example in [hosts.conf](4-configuring-icinga-2.md#hosts-conf) +and [services.conf](4-configuring-icinga-2.md#services-conf) for this use case. Take the following example: A host provides the snmp oids for different service check types. This could look like the following example: @@ -604,7 +604,7 @@ with many interfaces (services). The following requirements/problems apply: dynamically generated -Tip: Define the snmp community as global constant in your [constants.conf](5-configuring-icinga-2.md#constants-conf) file. +Tip: Define the snmp community as global constant in your [constants.conf](4-configuring-icinga-2.md#constants-conf) file. const IftrafficSnmpCommunity = "public" @@ -722,7 +722,7 @@ if set. This example makes use of the [check_iftraffic](https://exchange.icinga.org/exchange/iftraffic) plugin. The `CheckCommand` definition can be found in the [contributed plugin check commands](7-icinga-template-library.md#plugins-contrib-command-iftraffic) -- make sure to include them in your [icinga2 configuration file](5-configuring-icinga-2.md#icinga2-conf). +- make sure to include them in your [icinga2 configuration file](4-configuring-icinga-2.md#icinga2-conf). > **Tip** @@ -1014,7 +1014,7 @@ notifications between start and end time. vars.mobile = "+1 555 424642" } -Define an additional [NotificationCommand](#notification) for SMS notifications. +Define an additional [NotificationCommand](3-monitoring-basics.md#notification-commands) for SMS notifications. > **Note** > @@ -1165,7 +1165,7 @@ using the `check_command` attribute. `plugin-check-command` to support native plugin based check methods. Unless you have done so already, download your check plugin and put it -into the [PluginDir](5-configuring-icinga-2.md#constants-conf) directory. The following example uses the +into the [PluginDir](4-configuring-icinga-2.md#constants-conf) directory. The following example uses the `check_disk` plugin contained in the Monitoring Plugins package. The plugin path and all command arguments are made a list of @@ -1292,7 +1292,7 @@ string values for passing multiple partitions to the `check_disk` check plugin. More details on using arrays in custom attributes can be found in -[this chapter](#runtime-custom-attributes). +[this chapter](3-monitoring-basics.md#custom-attributes). #### Command Arguments diff --git a/doc/5-configuring-icinga-2.md b/doc/4-configuring-icinga-2.md similarity index 92% rename from doc/5-configuring-icinga-2.md rename to doc/4-configuring-icinga-2.md index 15bcadd0c..f5686365e 100644 --- a/doc/5-configuring-icinga-2.md +++ b/doc/4-configuring-icinga-2.md @@ -37,7 +37,7 @@ host and service basis. Then you should look for the object specific configuration setting `host_name` etc accordingly. Finding the best files and directory tree for your configuration is up to you. Make sure that -the [icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file includes them, +the [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file includes them, and then think about: * tree-based on locations, hostgroups, specific host attributes with sub levels of directories. @@ -53,7 +53,7 @@ You can later use them for applying assign/ignore rules, or export them into ext * Put hosts into hostgroups, services into servicegroups and use these attributes for your apply rules. * Use templates to store generic attributes for your objects and apply rules making your configuration more readable. Details can be found in the [using templates](3-monitoring-basics.md#object-inheritance-using-templates) chapter. -* Apply rules may overlap. Keep a central place (for example, [services.conf](5-configuring-icinga-2.md#services-conf) or [notifications.conf](5-configuring-icinga-2.md#notifications-conf)) storing +* Apply rules may overlap. Keep a central place (for example, [services.conf](4-configuring-icinga-2.md#services-conf) or [notifications.conf](4-configuring-icinga-2.md#notifications-conf)) storing the configuration instead of defining apply rules deep in your configuration tree. * Every plugin used as check, notification or event command requires a `Command` definition. Further details can be looked up in the [check commands](3-monitoring-basics.md#check-commands) chapter. @@ -133,7 +133,7 @@ and their generated configuration described in */ include_recursive "conf.d" -You can put your own configuration files in the [conf.d](5-configuring-icinga-2.md#conf-d) directory. This +You can put your own configuration files in the [conf.d](4-configuring-icinga-2.md#conf-d) directory. This directive makes sure that all of your own configuration files are included. ### constants.conf @@ -178,35 +178,35 @@ and distributed setups only. This directory contains example configuration which should help you get started with monitoring the local host and its services. It is included in the -[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file by default. +[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file by default. It can be used as reference example for your own configuration strategy. Just keep in mind to include the main directories in the -[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) file. +[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) file. You are certainly not bound to it. Remove it, if you prefer your own way of deploying Icinga 2 configuration. Further details on configuration best practice and how to build your -own strategy is described in [this chapter](5-configuring-icinga-2.md#configuration-best-practice). +own strategy is described in [this chapter](4-configuring-icinga-2.md#configuration-best-practice). Available configuration files which are installed by default: -* [hosts.conf](5-configuring-icinga-2.md#hosts-conf) -* [services.conf](5-configuring-icinga-2.md#services-conf) -* [users.conf](5-configuring-icinga-2.md#users-conf) -* [notifications.conf](5-configuring-icinga-2.md#notifications-conf) -* [commands.conf](5-configuring-icinga-2.md#commands-conf) -* [groups.conf](5-configuring-icinga-2.md#groups-conf) -* [templates.conf](5-configuring-icinga-2.md#templates-conf) -* [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf) -* [timeperiods.conf](5-configuring-icinga-2.md#timeperiods-conf) -* [satellite.conf](5-configuring-icinga-2.md#satellite-conf) +* [hosts.conf](4-configuring-icinga-2.md#hosts-conf) +* [services.conf](4-configuring-icinga-2.md#services-conf) +* [users.conf](4-configuring-icinga-2.md#users-conf) +* [notifications.conf](4-configuring-icinga-2.md#notifications-conf) +* [commands.conf](4-configuring-icinga-2.md#commands-conf) +* [groups.conf](4-configuring-icinga-2.md#groups-conf) +* [templates.conf](4-configuring-icinga-2.md#templates-conf) +* [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf) +* [timeperiods.conf](4-configuring-icinga-2.md#timeperiods-conf) +* [satellite.conf](4-configuring-icinga-2.md#satellite-conf) #### hosts.conf The `hosts.conf` file contains an example host based on your -`NodeName` setting in [constants.conf](5-configuring-icinga-2.md#constants-conf). You +`NodeName` setting in [constants.conf](4-configuring-icinga-2.md#constants-conf). You can use global constants for your object names instead of string values. @@ -219,20 +219,20 @@ for check and notification commands. Most of the [Plugin Check Commands](7-icing in the Icinga Template Library require an `address` attribute. The custom attribute `os` is evaluated by the `linux-servers` group in -[groups.conf](5-configuring-icinga-2.md#groups-conf) making the local host a member. +[groups.conf](4-configuring-icinga-2.md#groups-conf) making the local host a member. The example host will show you how to * define http vhost attributes for the `http` service apply rule defined -in [services.conf](5-configuring-icinga-2.md#services-conf). +in [services.conf](4-configuring-icinga-2.md#services-conf). * define disks (all, specific `/`) and their attributes for the `disk` -service apply rule defined in [services.conf](5-configuring-icinga-2.md#services-conf). +service apply rule defined in [services.conf](4-configuring-icinga-2.md#services-conf). * define notification types (`mail`) and set the groups attribute. This will be used by notification apply rules in [notifications.conf](notifications-conf). If you've installed [Icinga Web 2](2-getting-started.md#setting-up-icingaweb2) you can uncomment the http vhost attributes and reload Icinga 2. The apply -rules in [services.conf](5-configuring-icinga-2.md#services-conf) will automatically +rules in [services.conf](4-configuring-icinga-2.md#services-conf) will automatically generate a new service checking the `/icingaweb2` URI using the `http` check. @@ -289,7 +289,7 @@ check. } This is only the host object definition. Now we'll need to make sure that this -host and your additional hosts are getting [services](5-configuring-icinga-2.md#services-conf) applied. +host and your additional hosts are getting [services](4-configuring-icinga-2.md#services-conf) applied. > **Tip** > @@ -343,7 +343,7 @@ attributes. The custom attribe `backup_downtime` is defined to a specific timerange string. This variable value will be used for applying a `ScheduledDowntime` object to -these services in [downtimes.conf](5-configuring-icinga-2.md#downtimes-conf). +these services in [downtimes.conf](4-configuring-icinga-2.md#downtimes-conf). In this example the `assign where` condition is a boolean expression which is evaluated for all objects of type `Host` and a new service with name "load" @@ -374,10 +374,10 @@ rules. While one `apply` rule for `ssh` will only create a service for matching hosts, you can go one step further: Generate apply rules based on array items or dictionary key-value pairs. -The idea is simple: Your host in [hosts.conf](5-configuring-icinga-2.md#hosts-conf) defines the +The idea is simple: Your host in [hosts.conf](4-configuring-icinga-2.md#hosts-conf) defines the `disks` dictionary as custom attribute in `vars`. -Remember the example from [hosts.conf](5-configuring-icinga-2.md#hosts-conf): +Remember the example from [hosts.conf](4-configuring-icinga-2.md#hosts-conf): ... @@ -429,7 +429,7 @@ A similar example is used for the `http` services. That way you can make your host the information provider for all apply rules. Define them once, and only manage your hosts. -Look into [notifications.conf](5-configuring-icinga-2.md#notifications-conf) how this technique is used +Look into [notifications.conf](4-configuring-icinga-2.md#notifications-conf) how this technique is used for applying notifications to hosts and services using their type and user attributes. @@ -442,8 +442,8 @@ Further details on the monitoring configuration can be found in the #### users.conf Defines the `icingaadmin` User and the `icingaadmins` UserGroup. The latter is used in -[hosts.conf](5-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in -[notifications.conf](5-configuring-icinga-2.md#notifications-conf) for notification apply rules. +[hosts.conf](4-configuring-icinga-2.md#hosts-conf) for defining a custom host attribute later used in +[notifications.conf](4-configuring-icinga-2.md#notifications-conf) for notification apply rules. object User "icingaadmin" { import "generic-user" @@ -470,13 +470,13 @@ nested dictionary attribute `notification.mail` is set. Please note that the `to` keyword is important in [notification apply rules](3-monitoring-basics.md#using-apply-notifications) defining whether these notifications are applies to hosts or services. -The `import` keyword imports the specific mail templates defined in [templates.conf](5-configuring-icinga-2.md#templates-conf). +The `import` keyword imports the specific mail templates defined in [templates.conf](4-configuring-icinga-2.md#templates-conf). The `interval` attribute is not explicitly set - it [defaults to 30 minutes](6-object-types.md#objecttype-notification). By setting the `user_groups` to the value provided by the -respective [host.vars.notification.mail](5-configuring-icinga-2.md#hosts-conf) attribute we'll -implicitely use the `icingaadmins` UserGroup defined in [users.conf](5-configuring-icinga-2.md#users-conf). +respective [host.vars.notification.mail](4-configuring-icinga-2.md#hosts-conf) attribute we'll +implicitely use the `icingaadmins` UserGroup defined in [users.conf](4-configuring-icinga-2.md#users-conf). apply Notification "mail-icingaadmin" to Host { import "mail-host-notification" @@ -502,7 +502,7 @@ filters can be read in [this chapter](3-monitoring-basics.md#notifications). ### commands.conf This is the place where your own command configuration can be defined. By default -only the notification commands used by the notification templates defined in [templates.conf](5-configuring-icinga-2.md#templates-conf). +only the notification commands used by the notification templates defined in [templates.conf](4-configuring-icinga-2.md#templates-conf). You can freely customize these notification commands, and adapt them for your needs. Read more on that topic [here](3-monitoring-basics.md#notification-commands). @@ -601,7 +601,7 @@ More details on `Notification` object attributes can be found [here](6-object-ty #### 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 diff --git a/doc/4-advanced-topics.md b/doc/5-advanced-topics.md similarity index 99% rename from doc/4-advanced-topics.md rename to doc/5-advanced-topics.md index b12d495ec..34effc4e0 100644 --- a/doc/4-advanced-topics.md +++ b/doc/5-advanced-topics.md @@ -53,7 +53,7 @@ is removed (may happen before or after the actual end time!). ### Scheduling a downtime -This can either happen through a web interface or by sending an [external command](4-advanced-topics.md#external-commands) +This can either happen through a web interface or by sending an [external command](5-advanced-topics.md#external-commands) to the external command pipe provided by the `ExternalCommandListener` configuration. Fixed downtimes require a start and end time (a duration will be ignored). @@ -462,7 +462,7 @@ You can customize the metric prefix name by using the `host_name_template` and The example below uses [runtime macros](3-monitoring-basics.md#runtime-macros) and a [global constant](19-language-reference.md#constants) named `GraphiteEnv`. The constant name -is freely definable and should be put in the [constants.conf](5-configuring-icinga-2.md#constants-conf) file. +is freely definable and should be put in the [constants.conf](4-configuring-icinga-2.md#constants-conf) file. const GraphiteEnv = "icinga.env1" diff --git a/doc/6-object-types.md b/doc/6-object-types.md index 6721803c4..be38d2d5f 100644 --- a/doc/6-object-types.md +++ b/doc/6-object-types.md @@ -11,7 +11,7 @@ description are explained as well. ApiListener objects are used for distributed monitoring setups specifying the certificate files used for ssl authorization. -The `NodeName` constant must be defined in [constants.conf](5-configuring-icinga-2.md#constants-conf). +The `NodeName` constant must be defined in [constants.conf](4-configuring-icinga-2.md#constants-conf). Example: @@ -319,31 +319,6 @@ Configuration Attributes: log_duration |**Optional.** Duration for keeping replay logs on connection loss. Defaults to `1d`. -## 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. - - ## EventCommand An event command definition. @@ -999,7 +974,7 @@ ScheduledDowntime objects can be used to set up recurring downtimes for hosts/se > to just create a `ScheduledDowntime` template and use the `apply` keyword to assign the > scheduled downtime to a number of hosts or services. Use the `to` keyword to set the specific target > type for `Host` or `Service`. -> Check the [recurring downtimes](4-advanced-topics.md#recurring-downtimes) example for details. +> Check the [recurring downtimes](5-advanced-topics.md#recurring-downtimes) example for details. Example: diff --git a/doc/7-icinga-template-library.md b/doc/7-icinga-template-library.md index 8b1bd6c86..e869c034c 100644 --- a/doc/7-icinga-template-library.md +++ b/doc/7-icinga-template-library.md @@ -1053,12 +1053,12 @@ users\_win\_crit | **Optional**. The critical threshold. Icinga 2 can use the `nscp client` command to run arbitrary NSClient++ checks. You can enable these check commands by adding the following the include directive in your -[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file: +[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file: include You can also optionally specify an alternative installation directory for NSClient++ by adding -the NscpPath constant in your [constants.conf](5-configuring-icinga-2.md#constants-conf) configuration +the NscpPath constant in your [constants.conf](4-configuring-icinga-2.md#constants-conf) configuration file: const NscpPath = "C:\\Program Files (x86)\\NSClient++" @@ -1146,7 +1146,7 @@ The SNMP manubulon plugin check commands assume that the global constant named ` is set to the path where the Manubublon SNMP plugins are installed. You can enable these plugin check commands by adding the following the include directive in your -[icinga2.conf](5-configuring-icinga-2.md#icinga2-conf) configuration file: +[icinga2.conf](4-configuring-icinga-2.md#icinga2-conf) configuration file: include diff --git a/doc/9-monitoring-remote-systems.md b/doc/9-monitoring-remote-systems.md index 105a43260..9b44ccf0f 100644 --- a/doc/9-monitoring-remote-systems.md +++ b/doc/9-monitoring-remote-systems.md @@ -36,7 +36,7 @@ Start your search at * [Icinga Wiki](https://wiki.icinga.org) An example is provided in the sample configuration in the getting started -section shipped with Icinga 2 ([hosts.conf](5-configuring-icinga-2.md#hosts-conf), [services.conf](5-configuring-icinga-2.md#services-conf)). +section provided by Icinga 2 ([hosts.conf](4-configuring-icinga-2.md#hosts-conf), [services.conf](4-configuring-icinga-2.md#services-conf)). ## Agent-based Checks diff --git a/mkdocs.yml b/mkdocs.yml index cdc650086..bdedfbe46 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -5,8 +5,8 @@ pages: - [1-about.md, About Icinga 2] - [2-getting-started.md, Getting Started] - [3-monitoring-basics.md, Monitoring Basics] -- [4-advanced-topics.md, Advanced Topics] -- [5-configuring-icinga-2.md, Configuring Icinga 2] +- [4-configuring-icinga-2.md, Configuring Icinga 2] +- [5-advanced-topics.md, Advanced Topics] - [6-object-types.md, Object Types] - [7-icinga-template-library.md, Icinga Template Library] - [8-cli-commands.md, CLI Commands]