tyler.durden
/
icinga2
mirror of https://github.com/Icinga/icinga2.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update documentation

This commit is contained in:
Gunnar Beutner 2015-01-23 15:32:41 +01:00
parent ceaaf58145
commit 51aa2dff13
10 changed files with 114 additions and 107 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/12-troubleshooting.md
View File

@ -109,7 +109,7 @@ or similar.
* Check the debug log to see if the check command gets executed
* Verify that failed depedencies do not prevent command execution
* Make sure that the plugin is executable by the Icinga 2 user (run a manual test)
* Make sure the [checker](8-cli-commands.md#features) feature is enabled.
* Make sure the [checker](7-cli-commands.md#features) feature is enabled.
Examples:
@ -131,7 +131,7 @@ Verify the following configuration
* Do the notification attributes `states`, `types`, `period` match the notification conditions?
* Do the user attributes `states`, `types`, `period` match the notification conditions?
* Are there any notification `begin` and `end` times configured?
* Make sure the [notification](8-cli-commands.md#features) feature is enabled.
* Make sure the [notification](7-cli-commands.md#features) feature is enabled.
* Does the referenced NotificationCommand work when executed as Icinga user on the shell?
If notifications are to be sent via mail make sure that the mail program specified exists.
@ -164,7 +164,7 @@ or modify these attributes in the current object.
## <a id="troubleshooting-cluster"></a> Cluster Troubleshooting
You should configure the [cluster health checks](7-monitoring-remote-systems.md#cluster-health-check) if you haven't
You should configure the [cluster health checks](8-monitoring-remote-systems.md#cluster-health-check) if you haven't
done so already.
> **Note**
@ -218,7 +218,7 @@ If the cluster zones do not sync their configuration, make sure to check the fol
* Within a config master zone, only one configuration master is allowed to have its config in `/etc/icinga2/zones.d`.
** The master syncs the configuration to `/var/lib/icinga2/api/zones/` during startup and only syncs valid configuration to the other nodes
** The other nodes receive the configuration into `/var/lib/icinga2/api/zones/`
* The `icinga2.log` log file will indicate whether this ApiListener [accepts config](7-monitoring-remote-systems.md#zone-config-sync-permissions), or not
* The `icinga2.log` log file will indicate whether this ApiListener [accepts config](8-monitoring-remote-systems.md#zone-config-sync-permissions), or not
## <a id="debug"></a> Debug Icinga 2

10
doc/14-migrating-from-icinga-1x.md
View File

@ -721,9 +721,9 @@ daemon for passing check results between instances.
* Icinga 2 does not support any 1.x NEB addons for check load distribution
* If your current setup consists of instances distributing the check load, you should consider
building a [load distribution](7-monitoring-remote-systems.md#cluster-scenarios-load-distribution) setup with Icinga 2.
building a [load distribution](8-monitoring-remote-systems.md#cluster-scenarios-load-distribution) setup with Icinga 2.
* If your current setup includes active/passive clustering with external tools like Pacemaker/DRBD
consider the [High Availability](7-monitoring-remote-systems.md#cluster-scenarios-high-availability) setup.
consider the [High Availability](8-monitoring-remote-systems.md#cluster-scenarios-high-availability) setup.
* If you have build your own custom configuration deployment and check result collecting mechanism
you should re-design your setup and re-evaluate your requirements, and how they may be fulfilled
using the Icinga 2 cluster capabilities.
@ -777,7 +777,7 @@ Icinga 2 only uses a small set of [global constants](15-language-reference.md#co
you to specify certain different setting such as the `NodeName` in a cluster scenario.
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.
global constants, enabled [features](7-cli-commands.md#features) and the object configuration.
### <a id="differences-1x-2-include-files-dirs"></a> Include Files and Directories
@ -1436,7 +1436,7 @@ Unlike Icinga 1.x the Icinga 2 daemon reload happens asynchronously.
* parent process continues with old configuration objects and the event scheduling
(doing checks, replicating cluster events, triggering alert notifications, etc.)
* validation NOT ok: child process terminates, parent process continues with old configuration state
(this is ESSENTIAL for the [cluster config synchronisation](7-monitoring-remote-systems.md#cluster-zone-config-sync))
(this is ESSENTIAL for the [cluster config synchronisation](8-monitoring-remote-systems.md#cluster-zone-config-sync))
* validation ok: child process signals parent process to terminate and save its current state
(all events until now) into the icinga2 state file
* parent process shuts down writing icinga2.state file
@ -1491,6 +1491,6 @@ distribution out-of-the-box. Furthermore comments, downtimes, and other stateful
not synced between the master and slave nodes. There are addons available solving the check
and configuration distribution problems Icinga 1.x distributed monitoring currently suffers from.
Icinga 2 implements a new built-in [distributed monitoring architecture](7-monitoring-remote-systems.md#distributed-monitoring-high-availability),
Icinga 2 implements a new built-in [distributed monitoring architecture](8-monitoring-remote-systems.md#distributed-monitoring-high-availability),
including config and check distribution, IPv4/IPv6 support, SSL certificates and zone support for DMZ.
High Availability and load balancing are also part of the Icinga 2 Cluster setup.

2
doc/15-language-reference.md
View File

@ -487,7 +487,7 @@ Note the use of angle brackets instead of double quotes. This causes the
config compiler to search the include search paths for the specified
file. By default $PREFIX/share/icinga2/include is included in the list of search
paths. Additional include search paths can be added using
[command-line options](8-cli-commands.md#config-include-path).
[command-line options](7-cli-commands.md#config-include-path).
Wildcards are not permitted when using angle brackets.

4
doc/2-getting-started.md
View File

@ -112,7 +112,7 @@ Icinga 2 installation:
* `notification` for sending notifications
* `mainlog` for writing the `icinga2.log` file
You can verify that by calling `icinga2 feature list` [CLI command](8-cli-commands.md#cli-command-feature)
You can verify that by calling `icinga2 feature list` [CLI command](7-cli-commands.md#cli-command-feature)
to see which features are enabled and disabled.
# icinga2 feature list
@ -491,7 +491,7 @@ The `systemctl` command supports the following actions:
status | The `status` action checks if Icinga 2 is running.
enable | The `enable` action enables the service being started at system boot time (similar to `chkconfig`)
If you're stuck with configuration errors, you can manually invoke the [configuration validation](8-cli-commands.md#config-validation).
If you're stuck with configuration errors, you can manually invoke the [configuration validation](7-cli-commands.md#config-validation).
# systemctl enable icinga2

16
doc/3-monitoring-basics.md
View File

@ -248,8 +248,8 @@ dictionaries](#using-apply-for) for example provided by
> **Tip**
>
> Building configuration in that dynamic way requires detailed information
> of the generated objects. Use the `object list` [CLI command](8-cli-commands.md#cli-command-object)
> after successful [configuration validation](8-cli-commands.md#config-validation).
> of the generated objects. Use the `object list` [CLI command](7-cli-commands.md#cli-command-object)
> after successful [configuration validation](7-cli-commands.md#config-validation).
#### <a id="using-apply-expressions"></a> Apply Rules Expressions
@ -437,8 +437,8 @@ This can be achieved by wrapping them into the [string()](15-language-reference.
> **Tip**
>
> Building configuration in that dynamic way requires detailed information
> of the generated objects. Use the `object list` [CLI command](8-cli-commands.md#cli-command-object)
> after successful [configuration validation](8-cli-commands.md#config-validation).
> of the generated objects. Use the `object list` [CLI command](7-cli-commands.md#cli-command-object)
> after successful [configuration validation](7-cli-commands.md#config-validation).
#### <a id="using-apply-object attributes"></a> Use Object Attributes in Apply Rules
@ -594,7 +594,7 @@ Details on troubleshooting notification problems can be found [here](12-troubles
> **Note**
>
> Make sure that the [notification](8-cli-commands.md#features) feature is enabled on your master instance
> Make sure that the [notification](7-cli-commands.md#features) feature is enabled on your master instance
> in order to execute notification commands.
You should choose which information you (and your notified users) are interested in
@ -895,7 +895,7 @@ using the `check_command` attribute.
> **Note**
>
> Make sure that the [checker](8-cli-commands.md#features) feature is enabled in order to
> Make sure that the [checker](7-cli-commands.md#features) feature is enabled in order to
> execute checks.
#### <a id="command-plugin-integration"></a> Integrate the Plugin with a CheckCommand Definition
@ -1156,7 +1156,7 @@ interfaces (E-Mail, XMPP, IRC, Twitter, etc).
> **Note**
>
> Make sure that the [notification](8-cli-commands.md#features) feature is enabled on your master instance
> Make sure that the [notification](7-cli-commands.md#features) feature is enabled on your master instance
> in order to execute notification commands.
Below is an example using runtime macros from Icinga 2 (such as `$service.output$` for
@ -2437,7 +2437,7 @@ chapter. Details on the configuration can be found in the
[IdoMysqlConnection](5-object-types.md#objecttype-idomysqlconnection) and
[IdoPgsqlConnection](5-object-types.md#objecttype-idopgsqlconnection)
object configuration documentation.
The DB IDO feature supports [High Availability](7-monitoring-remote-systems.md#high-availability-db-ido) in
The DB IDO feature supports [High Availability](8-monitoring-remote-systems.md#high-availability-db-ido) in
the Icinga 2 cluster.
The following example query checks the health of the current Icinga 2 instance

15
doc/4-configuring-icinga-2.md
View File

@ -1,5 +1,12 @@
# <a id="configuring-icinga2-first-steps"></a> Configuring Icinga 2: First Steps
This chapter prodides an introduction to the configuration files which are automatically created
when installing the Icinga 2 packages.
If you're interested in a detailed explanation of each language feature used in those
configuration files you can find more information in the [Language Reference](15-language-reference.md#language-reference)
chapter.
## <a id="icinga2-conf"></a> icinga2.conf
An example configuration file is installed for you in `/etc/icinga2/icinga2.conf`.
@ -49,7 +56,7 @@ The `include` directive can be used to include other files.
This `include` directive takes care of including the configuration files for all
the features which have been enabled with `icinga2 feature enable`. See
[Enabling/Disabling Features](8-cli-commands.md#features) for more details.
[Enabling/Disabling Features](7-cli-commands.md#features) for more details.
/**
* The repository.d directory contains all configuration objects
@ -59,7 +66,7 @@ the features which have been enabled with `icinga2 feature enable`. See
This `include_recursive` directive is used for discovery of services on remote clients
and their generated configuration described in
[this chapter](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config).
[this chapter](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config).
/**
@ -586,8 +593,8 @@ objects such as hosts, services or notifications.
### <a id="satellite-conf"></a> satellite.conf
Ships default templates and dependencies for [monitoring remote clients](7-monitoring-remote-systems.md#icinga2-remote-client-monitoring)
using service discovery and [config generation](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config)
Ships default templates and dependencies for [monitoring remote clients](8-monitoring-remote-systems.md#icinga2-remote-client-monitoring)
using service discovery and [config generation](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-generate-config)
on the master. Can be ignored/removed on setups not using this features.

8
doc/5-object-types.md
View File

@ -805,8 +805,8 @@ Attributes:
table\_prefix |**Optional.** MySQL database table prefix. Defaults to "icinga\_".
instance\_name |**Optional.** Unique identifier for the local Icinga 2 instance. Defaults to "default".
instance\_description|**Optional.** Description for the Icinga 2 instance.
enable_ha |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](7-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](7-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
enable_ha |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](8-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](8-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
cleanup |**Optional.** Dictionary with items for historical table cleanup.
categories |**Optional.** The types of information that should be written to the database.
@ -894,8 +894,8 @@ Attributes:
table\_prefix |**Optional.** PostgreSQL database table prefix. Defaults to "icinga\_".
instance\_name |**Optional.** Unique identifier for the local Icinga 2 instance. Defaults to "default".
instance\_description|**Optional.** Description for the Icinga 2 instance.
enable_ha |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](7-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](7-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
enable_ha |**Optional.** Enable the high availability functionality. Only valid in a [cluster setup](8-monitoring-remote-systems.md#high-availability-db-ido). Defaults to "true".
failover_timeout | **Optional.** Set the failover timeout in a [HA cluster](8-monitoring-remote-systems.md#high-availability-db-ido). Must not be lower than 60s. Defaults to "60s".
cleanup |**Optional.** Dictionary with items for historical table cleanup.
categories |**Optional.** The types of information that should be written to the database.

18
doc/8-cli-commands.md → doc/7-cli-commands.md
View File

@ -132,7 +132,7 @@ added.
### <a id="cli-command-daemon"></a> CLI command: Daemon
The CLI command `daemon` provides the functionality to start/stop Icinga 2.
Furthermore it provides the [configuration validation](8-cli-commands.md#config-validation).
Furthermore it provides the [configuration validation](7-cli-commands.md#config-validation).
# icinga2 daemon --help
icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
@ -176,7 +176,7 @@ Icinga 2 automatically falls back to using the configuration file
The `--validate` option can be used to check if your configuration files
contain errors. If any errors are found the exit status is 1, otherwise 0
is returned. More details in the [configuration validation](8-cli-commands.md#config-validation) chapter.
is returned. More details in the [configuration validation](7-cli-commands.md#config-validation) chapter.
### <a id="cli-command-feature"></a> CLI command: Feature
@ -195,8 +195,8 @@ feature will only bring up all enabled features.
### <a id="cli-command-node"></a> CLI command: Node
Provides the functionality to install and manage master and client
nodes in a [remote monitoring ](7-monitoring-remote-systems.md#icinga2-remote-client-monitoring) or
[distributed cluster](7-monitoring-remote-systems.md#distributed-monitoring-high-availability) scenario.
nodes in a [remote monitoring ](8-monitoring-remote-systems.md#icinga2-remote-client-monitoring) or
[distributed cluster](8-monitoring-remote-systems.md#distributed-monitoring-high-availability) scenario.
# icinga2 node --help
@ -281,7 +281,7 @@ Provides the CLI commands to
* request a signed certificate from the master
* generate a new ticket for the client setup
This functionality is used by the [node setup/wizard](8-cli-commands.md#cli-command-pki) CLI commands too.
This functionality is used by the [node setup/wizard](7-cli-commands.md#cli-command-pki) CLI commands too.
# icinga2 pki --help
icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
@ -370,7 +370,7 @@ cleared after review.
### <a id="cli-command-variable"></a> CLI command: Variable
Lists all configured variables (constants) in a similar fasion like [object list](8-cli-commands.md#cli-command-object).
Lists all configured variables (constants) in a similar fasion like [object list](7-cli-commands.md#cli-command-object).
# icinga2 variable --help
icinga2 - The Icinga 2 network monitoring daemon (version: v2.1.1-299-gf695275)
@ -406,7 +406,7 @@ Lists all configured variables (constants) in a similar fasion like [object list
Icinga 2 provides configuration files for some commonly used features. These
are installed in the `/etc/icinga2/features-available` directory and can be
enabled and disabled using the `icinga2 feature enable` and `icinga2 feature disable`
[CLI commands](8-cli-commands.md#cli-command-feature), respectively.
[CLI commands](7-cli-commands.md#cli-command-feature), respectively.
The `icinga2 feature enable` CLI command creates symlinks in the
`/etc/icinga2/features-enabled` directory which is included by default
@ -486,7 +486,7 @@ Or manually passing the `-C` argument:
If you encouter errors during configuration validation, please make sure
to read the [troubleshooting](12-troubleshooting.md#troubleshooting) chapter.
You can also use the [CLI command](8-cli-commands.md#cli-command-object) `icinga2 object list`
You can also use the [CLI command](7-cli-commands.md#cli-command-object) `icinga2 object list`
after validation passes to analyze object attributes, inheritance or created
objects by apply rules.
Find more on troubleshooting with `object list` in [this chapter](12-troubleshooting.md#list-configuration-objects).
@ -522,7 +522,7 @@ Example filtered by `Service` objects with the name `ping*`:
## <a id="config-change-reload"></a> Reload on Configuration Changes
Everytime you have changed your configuration you should first tell Icinga 2
to [validate](8-cli-commands.md#config-validation). If there are no validation errors you can
to [validate](7-cli-commands.md#config-validation). If there are no validation errors you can
safely reload the Icinga 2 daemon.
# /etc/init.d/icinga2 reload

136
doc/7-monitoring-remote-systems.md → doc/8-monitoring-remote-systems.md
View File

@ -1,17 +1,17 @@
# <a id="monitoring-remote-systems"></a> Monitoring Remote Systems
There are multiple ways you can monitor remote clients. Be it using [agent-less](7-monitoring-remote-systems.md#agent-less-checks)
There are multiple ways you can monitor remote clients. Be it using [agent-less](8-monitoring-remote-systems.md#agent-less-checks)
or [agent-based](agent-based-checks-addons) using additional addons & tools.
Icinga 2 uses its own unique and secure communitication protol amongst instances.
Be it an High-Availability cluster setup, distributed load-balanced setup or just a single
agent [monitoring a remote client](7-monitoring-remote-systems.md#icinga2-remote-client-monitoring).
agent [monitoring a remote client](8-monitoring-remote-systems.md#icinga2-remote-client-monitoring).
All communication is secured by TLS with certificates, and fully supports IPv4 and IPv6.
If you are planning to use the native Icinga 2 cluster feature for distributed
monitoring and high-availability, please continue reading in
[this chapter](7-monitoring-remote-systems.md#distributed-monitoring-high-availability).
[this chapter](8-monitoring-remote-systems.md#distributed-monitoring-high-availability).
> **Tip**
>
@ -58,13 +58,13 @@ First, you should decide which role the remote client has:
* a remote command execution client (similar to NRPE, NSClient++, etc)
Later on, you will be asked again and told how to proceed with these
different [roles](7-monitoring-remote-systems.md#icinga2-remote-monitoring-client-roles).
different [roles](8-monitoring-remote-systems.md#icinga2-remote-monitoring-client-roles).
> **Note**
>
> If you are planning to build an Icinga 2 distributed setup using the cluster feature, please skip
> the following instructions and jump directly to the
> [cluster setup instructions](7-monitoring-remote-systems.md#distributed-monitoring-high-availability).
> [cluster setup instructions](8-monitoring-remote-systems.md#distributed-monitoring-high-availability).
> **Note**
>
@ -73,7 +73,7 @@ different [roles](7-monitoring-remote-systems.md#icinga2-remote-monitoring-clien
## <a id="icinga2-remote-monitoring-master"></a> Master Setup for Remote Monitoring
If you are planning to use the [remote Icinga 2 clients](7-monitoring-remote-systems.md#icinga2-remote-monitoring-client)
If you are planning to use the [remote Icinga 2 clients](8-monitoring-remote-systems.md#icinga2-remote-monitoring-client)
you'll first need to update your master setup.
Your master setup requires the following
@ -82,7 +82,7 @@ Your master setup requires the following
* Enabled API feature, and a local Endpoint and Zone object configuration
* Firewall ACLs for the communication port (default 5665)
You can use the [CLI command](8-cli-commands.md#cli-command-node) `node wizard` for setting up a new node
You can use the [CLI command](7-cli-commands.md#cli-command-node) `node wizard` for setting up a new node
on the master. The command must be run as root, all Icinga 2 specific files
will be updated to the icinga user the daemon is running as (certificate files
for example).
@ -148,13 +148,13 @@ The setup wizard does not automatically restart Icinga 2.
## <a id="icinga2-remote-monitoring-client"></a> Client Setup for Remote Monitoring
Icinga 2 can be installed on Linux/Unix and Windows. While
[Linux/Unix](7-monitoring-remote-systems.md#icinga2-remote-monitoring-client-linux) will be using the [CLI command](8-cli-commands.md#cli-command-node)
[Linux/Unix](8-monitoring-remote-systems.md#icinga2-remote-monitoring-client-linux) will be using the [CLI command](7-cli-commands.md#cli-command-node)
`node wizard` for a guided setup, you will need to use the
graphical installer for Windows based client setup.
Your client setup requires the following
* A ready configured and installed [master node](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
* A ready configured and installed [master node](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
* SSL signed certificate for communication with the master (Use [CSR auto-signing](certifiates-csr-autosigning)).
* Enabled API feature, and a local Endpoint and Zone object configuration
* Firewall ACLs for the communication port (default 5665)
@ -169,7 +169,7 @@ 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](4-configuring-icinga-2.md#constants-conf).
The [setup wizard for the master setup](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master) will create
The [setup wizard for the master setup](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master) will create
one for you already.
# grep TicketSalt /etc/icinga2/constants.conf
@ -193,11 +193,11 @@ Example for a client notebook:
#### <a id="certificates-manual-creation"></a> Manual SSL Certificate Generation
This is described separately in the [cluster setup chapter](7-monitoring-remote-systems.md#manual-certificate-generation).
This is described separately in the [cluster setup chapter](8-monitoring-remote-systems.md#manual-certificate-generation).
> **Note**
>
> If you're using [CSR Auto-Signing](7-monitoring-remote-systems.md#csr-autosigning-requirements), skip this step.
> If you're using [CSR Auto-Signing](8-monitoring-remote-systems.md#csr-autosigning-requirements), skip this step.
#### <a id="icinga2-remote-monitoring-client-linux-setup"></a> Linux Client Setup Wizard for Remote Monitoring
@ -205,8 +205,8 @@ This is described separately in the [cluster setup chapter](7-monitoring-remote-
Install Icinga 2 from your distribution's package repository as described in the
general [installation instructions](2-getting-started.md#setting-up-icinga2).
Please make sure that either [CSR Auto-Signing](7-monitoring-remote-systems.md#csr-autosigning-requirements) requirements
are fulfilled, or that you're using [manual SSL certificate generation](7-monitoring-remote-systems.md#manual-certificate-generation).
Please make sure that either [CSR Auto-Signing](8-monitoring-remote-systems.md#csr-autosigning-requirements) requirements
are fulfilled, or that you're using [manual SSL certificate generation](8-monitoring-remote-systems.md#manual-certificate-generation).
> **Note**
>
@ -222,7 +222,7 @@ You'll need the following configuration details:
* The client's local zone name. Defaults to FQDN.
* The master endpoint name. Look into your master setup `zones.conf` file for the proper name.
* The master endpoint connection information. Your master's IP address and port (defaults to 5665)
* The [request ticket number](7-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
* The [request ticket number](8-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
for CSR Auto-Signing
* Bind host/port for the Api feature (optional)
@ -325,7 +325,7 @@ You'll need the following configuration details:
* The client's local zone name. Defaults to FQDN.
* The master endpoint name. Look into your master setup `zones.conf` file for the proper name.
* The master endpoint connection information. Your master's IP address and port (defaults to 5665)
* The [request ticket number](7-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
* The [request ticket number](8-monitoring-remote-systems.md#csr-autosigning-requirements) generated on your master
for CSR Auto-Signing
* Bind host/port for the Api feature (optional)
@ -395,8 +395,8 @@ in [zones.conf](#zones-conf) and define a trusted master zone as `parent`.
}
More details here:
* [configure endpoints](7-monitoring-remote-systems.md#configure-cluster-endpoints)
* [configure zones](7-monitoring-remote-systems.md#configure-cluster-zones)
* [configure endpoints](8-monitoring-remote-systems.md#configure-cluster-endpoints)
* [configure zones](8-monitoring-remote-systems.md#configure-cluster-zones)
Configuration example for host and service objects running commands on the remote endpoint `remote-client1`:
@ -447,7 +447,7 @@ schedule client updates in your management tool (e.g. Puppet).
> clients. There are no local configured objects available.
>
> If you require this, please install a full-featured
> [local client](7-monitoring-remote-systems.md#icinga2-remote-monitoring-client-local-config).
> [local client](8-monitoring-remote-systems.md#icinga2-remote-monitoring-client-local-config).
### <a id="icinga2-remote-monitoring-client-local-config"></a> Remote Client with Local Configuration
@ -519,7 +519,7 @@ using the following CLI command:
> **Note**
>
> Better use [blacklists and/or whitelists](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-blacklist-whitelist)
> Better use [blacklists and/or whitelists](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master-discovery-blacklist-whitelist)
> to control which clients and hosts/services are integrated into your master configuration repository.
### <a id="icinga2-remote-monitoring-master-discovery-generate-config"></a> Generate Icinga 2 Configuration for Client Services on the Master
@ -602,13 +602,13 @@ You can `list` and `remove` existing blacklists:
Define a [Zone](5-object-types.md#objecttype-zone) with a new [Endpoint](5-object-types.md#objecttype-endpoint) similar to the cluster setup.
* [configure the node name](7-monitoring-remote-systems.md#configure-nodename)
* [configure the ApiListener object](7-monitoring-remote-systems.md#configure-apilistener-object)
* [configure cluster endpoints](7-monitoring-remote-systems.md#configure-cluster-endpoints)
* [configure cluster zones](7-monitoring-remote-systems.md#configure-cluster-zones)
* [configure the node name](8-monitoring-remote-systems.md#configure-nodename)
* [configure the ApiListener object](8-monitoring-remote-systems.md#configure-apilistener-object)
* [configure cluster endpoints](8-monitoring-remote-systems.md#configure-cluster-endpoints)
* [configure cluster zones](8-monitoring-remote-systems.md#configure-cluster-zones)
on a per remote client basis. If you prefer to synchronize the configuration to remote
clients, you can also use the cluster provided [configuration sync](7-monitoring-remote-systems.md#cluster-zone-config-sync)
clients, you can also use the cluster provided [configuration sync](8-monitoring-remote-systems.md#cluster-zone-config-sync)
in `zones.d`.
@ -676,7 +676,7 @@ remote client.
> The NRPE protocol is considered insecure and has multiple flaws in its
> design. Upstream is not willing to fix these issues.
>
> In order to stay safe, please use the native [Icinga 2 client](7-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
> In order to stay safe, please use the native [Icinga 2 client](8-monitoring-remote-systems.md#icinga2-remote-monitoring-master)
> instead.
The NRPE daemon uses its own configuration format in nrpe.cfg while `check_nrpe`
@ -742,7 +742,7 @@ executed by the NRPE daemon looks similar to that:
/usr/local/icinga/libexec/check_disk -w 20% -c 10% -p /
You can pass arguments in a similar manner to [NSClient++](7-monitoring-remote-systems.md#agent-based-checks-nsclient)
You can pass arguments in a similar manner to [NSClient++](8-monitoring-remote-systems.md#agent-based-checks-nsclient)
when using its NRPE supported check method.
### <a id="agent-based-checks-nsclient"></a> NSClient++
@ -973,9 +973,9 @@ passive update with the state and text from the second and third varbind:
Building distributed environments with high availability included is fairly easy with Icinga 2.
The cluster feature is built-in and allows you to build many scenarios based on your requirements:
* [High Availability](7-monitoring-remote-systems.md#cluster-scenarios-high-availability). All instances in the `Zone` elect one active master and run as Active/Active cluster.
* [Distributed Zones](7-monitoring-remote-systems.md#cluster-scenarios-distributed-zones). A master zone and one or more satellites in their zones.
* [Load Distribution](7-monitoring-remote-systems.md#cluster-scenarios-load-distribution). A configuration master and multiple checker satellites.
* [High Availability](8-monitoring-remote-systems.md#cluster-scenarios-high-availability). All instances in the `Zone` elect one active master and run as Active/Active cluster.
* [Distributed Zones](8-monitoring-remote-systems.md#cluster-scenarios-distributed-zones). A master zone and one or more satellites in their zones.
* [Load Distribution](8-monitoring-remote-systems.md#cluster-scenarios-load-distribution). A configuration master and multiple checker satellites.
You can combine these scenarios into a global setup fitting your requirements.
@ -999,7 +999,7 @@ Before you start deploying, keep the following things in mind:
* cluster zones can be built in a Top-Down-design where the child trusts the parent
* communication between zones happens bi-directional which means that a DMZ-located node can still reach the master node, or vice versa
* Update firewall rules and ACLs
* Decide whether to use the built-in [configuration syncronization](7-monitoring-remote-systems.md#cluster-zone-config-sync) or use an external tool (Puppet, Ansible, Chef, Salt, etc) to manage the configuration deployment
* Decide whether to use the built-in [configuration syncronization](8-monitoring-remote-systems.md#cluster-zone-config-sync) or use an external tool (Puppet, Ansible, Chef, Salt, etc) to manage the configuration deployment
> **Tip**
@ -1010,7 +1010,7 @@ Before you start deploying, keep the following things in mind:
### <a id="manual-certificate-generation"></a> Manual SSL Certificate Generation
Icinga 2 ships [CLI commands](8-cli-commands.md#cli-command-pki) assisting with CA and node certificate creation
Icinga 2 ships [CLI commands](7-cli-commands.md#cli-command-pki) assisting with CA and node certificate creation
for your Icinga 2 distributed setup.
> **Note**
@ -1079,7 +1079,7 @@ The [Endpoint](5-object-types.md#objecttype-endpoint) name is further referenced
endpoints = [ "icinga2a", "icinga2b" ]
}
Specifying the local node name using the [NodeName](7-monitoring-remote-systems.md#configure-nodename) variable requires
Specifying the local node name using the [NodeName](8-monitoring-remote-systems.md#configure-nodename) variable requires
the same name as used for the endpoint name and common name above. If not set, the FQDN is used.
const NodeName = "icinga2a"
@ -1090,14 +1090,14 @@ the same name as used for the endpoint name and common name above. If not set, t
The following section describe which configuration must be updated/created
in order to get your cluster running with basic functionality.
* [configure the node name](7-monitoring-remote-systems.md#configure-nodename)
* [configure the ApiListener object](7-monitoring-remote-systems.md#configure-apilistener-object)
* [configure cluster endpoints](7-monitoring-remote-systems.md#configure-cluster-endpoints)
* [configure cluster zones](7-monitoring-remote-systems.md#configure-cluster-zones)
* [configure the node name](8-monitoring-remote-systems.md#configure-nodename)
* [configure the ApiListener object](8-monitoring-remote-systems.md#configure-apilistener-object)
* [configure cluster endpoints](8-monitoring-remote-systems.md#configure-cluster-endpoints)
* [configure cluster zones](8-monitoring-remote-systems.md#configure-cluster-zones)
Once you're finished with the basic setup the following section will
describe how to use [zone configuration synchronisation](7-monitoring-remote-systems.md#cluster-zone-config-sync)
and configure [cluster scenarios](7-monitoring-remote-systems.md#cluster-scenarios).
describe how to use [zone configuration synchronisation](8-monitoring-remote-systems.md#cluster-zone-config-sync)
and configure [cluster scenarios](8-monitoring-remote-systems.md#cluster-scenarios).
#### <a id="configure-nodename"></a> Configure the Icinga Node Name
@ -1112,7 +1112,7 @@ that value using the [NodeName](15-language-reference.md#constants) constant.
This setting must be unique for each node, and must also match
the name of the local [Endpoint](5-object-types.md#objecttype-endpoint) object and the
SSL certificate common name as described in the
[cluster naming convention](7-monitoring-remote-systems.md#cluster-naming-convention).
[cluster naming convention](8-monitoring-remote-systems.md#cluster-naming-convention).
vim /etc/icinga2/constants.conf
@ -1122,7 +1122,7 @@ SSL certificate common name as described in the
const NodeName = "icinga2a"
Read further about additional [naming conventions](7-monitoring-remote-systems.md#cluster-naming-convention).
Read further about additional [naming conventions](8-monitoring-remote-systems.md#cluster-naming-convention).
Not specifying the node name will make Icinga 2 using the FQDN. Make sure that all
configured endpoint names and common names are in sync.
@ -1177,9 +1177,9 @@ If this endpoint object is reachable on a different port, you must configure the
`Zone` objects specify the endpoints located in a zone. That way your distributed setup can be
seen as zones connected together instead of multiple instances in that specific zone.
Zones can be used for [high availability](7-monitoring-remote-systems.md#cluster-scenarios-high-availability),
[distributed setups](7-monitoring-remote-systems.md#cluster-scenarios-distributed-zones) and
[load distribution](7-monitoring-remote-systems.md#cluster-scenarios-load-distribution).
Zones can be used for [high availability](8-monitoring-remote-systems.md#cluster-scenarios-high-availability),
[distributed setups](8-monitoring-remote-systems.md#cluster-scenarios-distributed-zones) and
[load distribution](8-monitoring-remote-systems.md#cluster-scenarios-load-distribution).
Each Icinga 2 `Endpoint` must be put into its respective `Zone`. In this example, you will
define the zone `config-ha-master` where the `icinga2a` and `icinga2b` endpoints
@ -1214,7 +1214,7 @@ on the configuration master.
Your child zones and endpoint members **must not** have their config copied to `zones.d`.
The built-in configuration synchronisation takes care of that if your nodes accept
configuration from the parent zone. You can define that in the
[ApiListener](7-monitoring-remote-systems.md#configure-apilistener-object) object by configuring the `accept_config`
[ApiListener](8-monitoring-remote-systems.md#configure-apilistener-object) object by configuring the `accept_config`
attribute accordingly.
You should remove the sample config included in `conf.d` by commenting the `recursive_include`
@ -1224,11 +1224,11 @@ statement in [icinga2.conf](4-configuring-icinga-2.md#icinga2-conf):
Better use a dedicated directory name like `cluster` or similar, and include that
one if your nodes require local configuration not being synced to other nodes. That's
useful for local [health checks](7-monitoring-remote-systems.md#cluster-health-check) for example.
useful for local [health checks](8-monitoring-remote-systems.md#cluster-health-check) for example.
> **Note**
>
> In a [high availability](7-monitoring-remote-systems.md#cluster-scenarios-high-availability)
> In a [high availability](8-monitoring-remote-systems.md#cluster-scenarios-high-availability)
> setup only one assigned node can act as configuration master. All other zone
> member nodes **must not** have the `/etc/icinga2/zones.d` directory populated.
@ -1237,7 +1237,7 @@ to their respective target zone instances.
Each configured zone must exist with the same directory name. The parent zone
syncs the configuration to the child zones, if allowed using the `accept_config`
attribute of the [ApiListener](7-monitoring-remote-systems.md#configure-apilistener-object) object.
attribute of the [ApiListener](8-monitoring-remote-systems.md#configure-apilistener-object) object.
Config on node `icinga2a`:
@ -1395,7 +1395,7 @@ additional security itself:
* Child zones only receive event updates (check results, commands, etc) for their configured updates.
* Zones cannot influence/interfere other zones. Each checked object is assigned to only one zone.
* All nodes in a zone trust each other.
* [Configuration sync](7-monitoring-remote-systems.md#zone-config-sync-permissions) is disabled by default.
* [Configuration sync](8-monitoring-remote-systems.md#zone-config-sync-permissions) is disabled by default.
#### <a id="cluster-scenarios-features"></a> Features in Cluster Zones
@ -1406,11 +1406,11 @@ re-schedule a check or acknowledge a problem on the master, and it gets replicat
actual slave checker node.
DB IDO on the left, graphite on the right side - works (if you disable
[DB IDO HA](7-monitoring-remote-systems.md#high-availability-db-ido)).
[DB IDO HA](8-monitoring-remote-systems.md#high-availability-db-ido)).
Icinga Web 2 on the left, checker and notifications on the right side - works too.
Everything on the left and on the right side - make sure to deal with
[load-balanced notifications and checks](7-monitoring-remote-systems.md#high-availability-features) in a
[HA zone](7-monitoring-remote-systems.md#cluster-scenarios-high-availability).
[load-balanced notifications and checks](8-monitoring-remote-systems.md#high-availability-features) in a
[HA zone](8-monitoring-remote-systems.md#cluster-scenarios-high-availability).
configure-cluster-zones
#### <a id="cluster-scenarios-distributed-zones"></a> Distributed Zones
@ -1425,7 +1425,7 @@ graphing, etc. in their own specified zone.
Imagine the following example with a master node in Nuremberg, and two remote DMZ
based instances in Berlin and Vienna. Additonally you'll specify
[global templates](7-monitoring-remote-systems.md#zone-global-config-templates) available in all zones.
[global templates](8-monitoring-remote-systems.md#zone-global-config-templates) available in all zones.
The configuration tree on the master instance `nuremberg` could look like this:
@ -1489,7 +1489,7 @@ check results from the satellite nodes in the zones `berlin` and `vienna`.
> The child zones `berlin` and `vienna` will get their configuration synchronised
> from the configuration master 'nuremberg'. The endpoints in the child
> zones **must not** have their `zones.d` directory populated if this endpoint
> [accepts synced configuration](7-monitoring-remote-systems.md#zone-config-sync-permissions).
> [accepts synced configuration](8-monitoring-remote-systems.md#zone-config-sync-permissions).
#### <a id="cluster-scenarios-load-distribution"></a> Load Distribution
@ -1548,15 +1548,15 @@ Zones:
> The child zones `checker` will get its configuration synchronised
> from the configuration master 'master'. The endpoints in the child
> zone **must not** have their `zones.d` directory populated if this endpoint
> [accepts synced configuration](7-monitoring-remote-systems.md#zone-config-sync-permissions).
> [accepts synced configuration](8-monitoring-remote-systems.md#zone-config-sync-permissions).
#### <a id="cluster-scenarios-high-availability"></a> Cluster High Availability
High availability with Icinga 2 is possible by putting multiple nodes into
a dedicated [zone](7-monitoring-remote-systems.md#configure-cluster-zones). All nodes will elect one
a dedicated [zone](8-monitoring-remote-systems.md#configure-cluster-zones). All nodes will elect one
active master, and retry an election once the current active master is down.
Selected features provide advanced [HA functionality](7-monitoring-remote-systems.md#high-availability-features).
Selected features provide advanced [HA functionality](8-monitoring-remote-systems.md#high-availability-features).
Checks and notifications are load-balanced between nodes in the high availability
zone.
@ -1568,17 +1568,17 @@ commands, etc.
endpoints = [ "icinga2a", "icinga2b", "icinga2c" ]
}
Two or more nodes in a high availability setup require an [initial cluster sync](7-monitoring-remote-systems.md#initial-cluster-sync).
Two or more nodes in a high availability setup require an [initial cluster sync](8-monitoring-remote-systems.md#initial-cluster-sync).
> **Note**
>
> Keep in mind that **only one node acts as configuration master** having the
> configuration files in the `zones.d` directory. All other nodes **must not**
> have that directory populated. Instead they are required to
> [accept synced configuration](7-monitoring-remote-systems.md#zone-config-sync-permissions).
> Details in the [Configuration Sync Chapter](7-monitoring-remote-systems.md#cluster-zone-config-sync).
> [accept synced configuration](8-monitoring-remote-systems.md#zone-config-sync-permissions).
> Details in the [Configuration Sync Chapter](8-monitoring-remote-systems.md#cluster-zone-config-sync).
#### <a id="cluster-scenarios-multiple-hierachies"></a> Multiple Hierachies
#### <a id="cluster-scenarios-multiple-hierarchies"></a> Multiple Hierarchies
Your master zone collects all check results for reporting and graphing and also
does some sort of additional notifications.
@ -1610,9 +1610,9 @@ amongst them.
By default the following features provide advanced HA functionality:
* [Checks](7-monitoring-remote-systems.md#high-availability-checks) (load balanced, automated failover)
* [Notifications](7-monitoring-remote-systems.md#high-availability-notifications) (load balanced, automated failover)
* [DB IDO](7-monitoring-remote-systems.md#high-availability-db-ido) (Run-Once, automated failover)
* [Checks](8-monitoring-remote-systems.md#high-availability-checks) (load balanced, automated failover)
* [Notifications](8-monitoring-remote-systems.md#high-availability-notifications) (load balanced, automated failover)
* [DB IDO](8-monitoring-remote-systems.md#high-availability-db-ido) (Run-Once, automated failover)
#### <a id="high-availability-checks"></a> High Availability with Checks
@ -1682,11 +1682,11 @@ These steps are required for integrating a new cluster endpoint:
* generate a new [SSL client certificate](#certificate-authority-certificates)
* identify its location in the zones
* update the `zones.conf` file on each involved node ([endpoint](7-monitoring-remote-systems.md#configure-cluster-endpoints), [zones](7-monitoring-remote-systems.md#configure-cluster-zones))
* update the `zones.conf` file on each involved node ([endpoint](8-monitoring-remote-systems.md#configure-cluster-endpoints), [zones](8-monitoring-remote-systems.md#configure-cluster-zones))
* a new slave zone node requires updates for the master and slave zones
* verify if this endpoints requires [configuration synchronisation](7-monitoring-remote-systems.md#cluster-zone-config-sync) enabled
* if the node requires the existing zone history: [initial cluster sync](7-monitoring-remote-systems.md#initial-cluster-sync)
* add a [cluster health check](7-monitoring-remote-systems.md#cluster-health-check)
* verify if this endpoints requires [configuration synchronisation](8-monitoring-remote-systems.md#cluster-zone-config-sync) enabled
* if the node requires the existing zone history: [initial cluster sync](8-monitoring-remote-systems.md#initial-cluster-sync)
* add a [cluster health check](8-monitoring-remote-systems.md#cluster-health-check)
#### <a id="initial-cluster-sync"></a> Initial Cluster Sync

4
mkdocs.yml
View File

@ -8,8 +8,8 @@ pages:
- [4-configuring-icinga-2.md, Configuring Icinga 2]
- [5-object-types.md, Object Types]
- [6-icinga-template-library.md, Icinga Template Library]
- [7-monitoring-remote-systems.md, Monitoring Remote Systems]
- [8-cli-commands.md, CLI Commands]
- [7-cli-commands.md, CLI Commands]
- [8-monitoring-remote-systems.md, Monitoring Remote Systems]
- [9-addons-plugins.md, Addons and Plugins]
- [10-alternative-frontends.md, Alternative Frontends]
- [11-livestatus.md, Livestatus]