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

Fix client names in distributed monitoring docs 

fixes #4996
This commit is contained in:
Michael Friedrich 2017-02-14 12:53:04 +01:00
parent d20a2133ff
commit 2b7cc05060
1 changed files with 77 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

157
doc/6-distributed-monitoring.md
View File

@ -624,7 +624,7 @@ commands, you need to configure the `Zone` and `Endpoint` hierarchy
on all nodes. on all nodes.
* `icinga2-master1.localdomain` is the configuration master in this scenario. * `icinga2-master1.localdomain` is the configuration master in this scenario.
* `icinga2-client2.localdomain` acts as client which receives command execution messages via command endpoint from the master. In addition, it receives the global check command configuration from the master. * `icinga2-client1.localdomain` acts as client which receives command execution messages via command endpoint from the master. In addition, it receives the global check command configuration from the master.
Include the endpoint and zone configuration on **both** nodes in the file `/etc/icinga2/zones.conf`. Include the endpoint and zone configuration on **both** nodes in the file `/etc/icinga2/zones.conf`.
@ -636,8 +636,8 @@ The endpoint configuration could look like this, for example:
host = "192.168.56.101" host = "192.168.56.101"
} }
object Endpoint "icinga2-client2.localdomain" { object Endpoint "icinga2-client1.localdomain" {
host = "192.168.56.112" host = "192.168.56.111"
} }
Next, you need to define two zones. There is no naming convention, best practice is to either use `master`, `satellite`/`client-fqdn` or to choose region names for example `Europe`, `USA` and `Asia`, though. Next, you need to define two zones. There is no naming convention, best practice is to either use `master`, `satellite`/`client-fqdn` or to choose region names for example `Europe`, `USA` and `Asia`, though.
@ -645,7 +645,7 @@ Next, you need to define two zones. There is no naming convention, best practice
**Note**: Each client requires its own zone and endpoint configuration. Best practice **Note**: Each client requires its own zone and endpoint configuration. Best practice
is to use the client's FQDN for all object names. is to use the client's FQDN for all object names.
The `master` zone is a parent of the `icinga2-client2.localdomain` zone: The `master` zone is a parent of the `icinga2-client1.localdomain` zone:
[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf [root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
@ -653,8 +653,8 @@ The `master` zone is a parent of the `icinga2-client2.localdomain` zone:
endpoints = [ "icinga2-master1.localdomain" ] //array with endpoint names endpoints = [ "icinga2-master1.localdomain" ] //array with endpoint names
} }
object Zone "icinga2-client2.localdomain" { object Zone "icinga2-client1.localdomain" {
endpoints = [ "icinga2-client2.localdomain" ] endpoints = [ "icinga2-client1.localdomain" ]
parent = "master" //establish zone hierarchy parent = "master" //establish zone hierarchy
} }
@ -678,7 +678,7 @@ in `/etc/icinga2/icinga2.conf`.
// Commented out, not required on a client as command endpoint // Commented out, not required on a client as command endpoint
//include_recursive "conf.d" //include_recursive "conf.d"
Edit the `api` feature on the client `icinga2-client2.localdomain` in Edit the `api` feature on the client `icinga2-client1.localdomain` in
the `/etc/icinga2/features-enabled/api.conf` file and make sure to set the `/etc/icinga2/features-enabled/api.conf` file and make sure to set
`accept_commands` and `accept_config` to `true`: `accept_commands` and `accept_config` to `true`:
@ -695,8 +695,8 @@ on both nodes.
Example on CentOS 7: Example on CentOS 7:
[root@icinga2-client2.localdomain /]# icinga2 daemon -C [root@icinga2-client1.localdomain /]# icinga2 daemon -C
[root@icinga2-client2.localdomain /]# systemctl restart icinga2 [root@icinga2-client1.localdomain /]# systemctl restart icinga2
[root@icinga2-master1.localdomain /]# icinga2 daemon -C [root@icinga2-master1.localdomain /]# icinga2 daemon -C
[root@icinga2-master1.localdomain /]# systemctl restart icinga2 [root@icinga2-master1.localdomain /]# systemctl restart icinga2
@ -719,9 +719,9 @@ You can also add multiple hosts which execute checks against remote services/cli
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/master [root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/master
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim hosts.conf [root@icinga2-master1.localdomain /etc/icinga2/zones.d/master]# vim hosts.conf
object Host "icinga2-client2.localdomain" { object Host "icinga2-client1.localdomain" {
check_command = "hostalive" //check is executed on the master check_command = "hostalive" //check is executed on the master
address = "192.168.56.112" address = "192.168.56.111"
vars.client_endpoint = name //follows the convention that host name == endpoint name vars.client_endpoint = name //follows the convention that host name == endpoint name
} }
@ -761,8 +761,8 @@ The following steps will happen:
* Icinga 2 validates the configuration on `icinga2-master1.localdomain` and restarts. * Icinga 2 validates the configuration on `icinga2-master1.localdomain` and restarts.
* The `icinga2-master1.localdomain` node schedules and executes the checks. * The `icinga2-master1.localdomain` node schedules and executes the checks.
* The `icinga2-client2.localdomain` node receives the execute command event with additional command parameters. * The `icinga2-client1.localdomain` node receives the execute command event with additional command parameters.
* The `icinga2-client2.localdomain` node maps the command parameters to the local check command, executes the check locally, and sends back the check result message. * The `icinga2-client1.localdomain` node maps the command parameters to the local check command, executes the check locally, and sends back the check result message.
As you can see, no interaction from your side is required on the client itself, and it's not necessary to reload the Icinga 2 service on the client. As you can see, no interaction from your side is required on the client itself, and it's not necessary to reload the Icinga 2 service on the client.
@ -799,20 +799,20 @@ commands, you need to configure the `Zone` and `Endpoint` hierarchy
on all nodes. on all nodes.
* `icinga2-master1.localdomain` is the configuration master in this scenario. * `icinga2-master1.localdomain` is the configuration master in this scenario.
* `icinga2-client1.localdomain` acts as client which receives configuration from the master. * `icinga2-client2.localdomain` acts as client which receives configuration from the master. Checks are scheduled locally.
Include the endpoint and zone configuration on **both** nodes in the file `/etc/icinga2/zones.conf`. Include the endpoint and zone configuration on **both** nodes in the file `/etc/icinga2/zones.conf`.
The endpoint configuration could look like this: The endpoint configuration could look like this:
[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf [root@icinga2-client2.localdomain /]# vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" { object Endpoint "icinga2-master1.localdomain" {
host = "192.168.56.101" host = "192.168.56.101"
} }
object Endpoint "icinga2-client1.localdomain" { object Endpoint "icinga2-client2.localdomain" {
host = "192.168.56.111" host = "192.168.56.112"
} }
Next, you need to define two zones. There is no naming convention, best practice is to either use `master`, `satellite`/`client-fqdn` or to choose region names for example `Europe`, `USA` and `Asia`, though. Next, you need to define two zones. There is no naming convention, best practice is to either use `master`, `satellite`/`client-fqdn` or to choose region names for example `Europe`, `USA` and `Asia`, though.
@ -820,25 +820,25 @@ Next, you need to define two zones. There is no naming convention, best practice
**Note**: Each client requires its own zone and endpoint configuration. Best practice **Note**: Each client requires its own zone and endpoint configuration. Best practice
is to use the client's FQDN for all object names. is to use the client's FQDN for all object names.
The `master` zone is a parent of the `icinga2-client1.localdomain` zone: The `master` zone is a parent of the `icinga2-client2.localdomain` zone:
[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf [root@icinga2-client2.localdomain /]# vim /etc/icinga2/zones.conf
object Zone "master" { object Zone "master" {
endpoints = [ "icinga2-master1.localdomain" ] //array with endpoint names endpoints = [ "icinga2-master1.localdomain" ] //array with endpoint names
} }
object Zone "icinga2-client1.localdomain" { object Zone "icinga2-client2.localdomain" {
endpoints = [ "icinga2-client1.localdomain" ] endpoints = [ "icinga2-client2.localdomain" ]
parent = "master" //establish zone hierarchy parent = "master" //establish zone hierarchy
} }
Edit the `api` feature on the client `icinga2-client1.localdomain` in Edit the `api` feature on the client `icinga2-client2.localdomain` in
the `/etc/icinga2/features-enabled/api.conf` file and set the `/etc/icinga2/features-enabled/api.conf` file and set
`accept_config` to `true`. `accept_config` to `true`.
[root@icinga2-client1.localdomain /]# vim /etc/icinga2/features-enabled/api.conf [root@icinga2-client2.localdomain /]# vim /etc/icinga2/features-enabled/api.conf
object ApiListener "api" { object ApiListener "api" {
//... //...
@ -850,8 +850,8 @@ on both nodes.
Example on CentOS 7: Example on CentOS 7:
[root@icinga2-client1.localdomain /]# icinga2 daemon -C [root@icinga2-client2.localdomain /]# icinga2 daemon -C
[root@icinga2-client1.localdomain /]# systemctl restart icinga2 [root@icinga2-client2.localdomain /]# systemctl restart icinga2
[root@icinga2-master1.localdomain /]# icinga2 daemon -C [root@icinga2-master1.localdomain /]# icinga2 daemon -C
[root@icinga2-master1.localdomain /]# systemctl restart icinga2 [root@icinga2-master1.localdomain /]# systemctl restart icinga2
@ -867,7 +867,7 @@ Navigate to `/etc/icinga2/zones.d` on your master node
`icinga2-master1.localdomain` and create a new directory with the same `icinga2-master1.localdomain` and create a new directory with the same
name as your satellite/client zone name: name as your satellite/client zone name:
[root@icinga2-master1.localdomain /]# mkdir -p /etc/icinga2/zones.d/icinga2-client1.localdomain [root@icinga2-master1.localdomain /]# mkdir -p /etc/icinga2/zones.d/icinga2-client2.localdomain
Add the host and service objects you want to monitor. There is Add the host and service objects you want to monitor. There is
no limitation for files and directories -- best practice is to no limitation for files and directories -- best practice is to
@ -876,22 +876,22 @@ sort things by type.
By convention a master/satellite/client host object should use the same name as the endpoint object. By convention a master/satellite/client host object should use the same name as the endpoint object.
You can also add multiple hosts which execute checks against remote services/clients. You can also add multiple hosts which execute checks against remote services/clients.
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/icinga2-client1.localdomain [root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/icinga2-client2.localdomain
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/icinga2-client1.localdomain]# vim hosts.conf [root@icinga2-master1.localdomain /etc/icinga2/zones.d/icinga2-client2.localdomain]# vim hosts.conf
object Host "icinga2-client1.localdomain" { object Host "icinga2-client2.localdomain" {
check_command = "hostalive" check_command = "hostalive"
address = "192.168.56.111" address = "192.168.56.112"
zone = "master" //optional trick: sync the required host object to the client, but enforce the "master" zone to execute the check zone = "master" //optional trick: sync the required host object to the client, but enforce the "master" zone to execute the check
} }
Given that you are monitoring a Linux client we'll just add a local [disk](10-icinga-template-library.md#plugin-check-command-disk) Given that you are monitoring a Linux client we'll just add a local [disk](10-icinga-template-library.md#plugin-check-command-disk)
check. check.
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/icinga2-client1.localdomain]# vim services.conf [root@icinga2-master1.localdomain /etc/icinga2/zones.d/icinga2-client2.localdomain]# vim services.conf
object Service "disk" { object Service "disk" {
host_name = "icinga2-client1.localdomain" host_name = "icinga2-client2.localdomain"
check_command = "disk" check_command = "disk"
} }
@ -909,8 +909,8 @@ The following steps will happen:
* Icinga 2 validates the configuration on `icinga2-master1.localdomain`. * Icinga 2 validates the configuration on `icinga2-master1.localdomain`.
* Icinga 2 copies the configuration into its zone config store in `/var/lib/icinga2/api/zones`. * Icinga 2 copies the configuration into its zone config store in `/var/lib/icinga2/api/zones`.
* The `icinga2-master1.localdomain` node sends a config update event to all endpoints in the same or direct child zones. * The `icinga2-master1.localdomain` node sends a config update event to all endpoints in the same or direct child zones.
* The `icinga2-client1.localdomain` node accepts config and populates the local zone config store with the received config files. * The `icinga2-client2.localdomain` node accepts config and populates the local zone config store with the received config files.
* The `icinga2-client1.localdomain` node validates the configuration and automatically restarts. * The `icinga2-client2.localdomain` node validates the configuration and automatically restarts.
Again, there is no interaction required on the client Again, there is no interaction required on the client
itself. itself.
@ -964,21 +964,7 @@ This example shows all client services on the master node `icinga2-master1.local
[root@icinga2-master1.localdomain /]# icinga2 node list [root@icinga2-master1.localdomain /]# icinga2 node list
Warning: CLI command 'node list' is DEPRECATED! Please read the Changelog. Warning: CLI command 'node list' is DEPRECATED! Please read the Changelog.
Node 'icinga2-client1.localdomain' (last seen: Sun Aug 14 11:19:14 2016) Node 'icinga2-client3.localdomain' (last seen: Sun Aug 14 11:19:14 2016)
* Host 'icinga2-client1.localdomain'
* Service 'disk'
* Service 'disk /'
* Service 'http'
* Service 'icinga'
* Service 'load'
* Service 'ping4'
* Service 'ping6'
* Service 'procs'
* Service 'ssh'
* Service 'swap'
* Service 'users'
Node 'icinga2-client2.localdomain' (last seen: Sun Aug 14 11:19:14 2016)
* Host 'icinga2-client2.localdomain' * Host 'icinga2-client2.localdomain'
* Service 'disk' * Service 'disk'
* Service 'disk C:' * Service 'disk C:'
@ -1066,7 +1052,7 @@ configuration file.
Add a [global zone](6-distributed-monitoring.md#distributed-monitoring-global-zone-config-sync) Add a [global zone](6-distributed-monitoring.md#distributed-monitoring-global-zone-config-sync)
for syncing check commands later: for syncing check commands later:
[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf [root@icinga2-client3.localdomain /]# vim /etc/icinga2/zones.conf
object Zone "global-templates" { object Zone "global-templates" {
global = true global = true
@ -1077,7 +1063,7 @@ CheckCommand definitions which can be synced using the global zone
above. Therefore disable the inclusion of the `conf.d` directory above. Therefore disable the inclusion of the `conf.d` directory
in `/etc/icinga2/icinga2.conf`. in `/etc/icinga2/icinga2.conf`.
[root@icinga2-client1.localdomain /]# vim /etc/icinga2/icinga2.conf [root@icinga2-client3.localdomain /]# vim /etc/icinga2/icinga2.conf
// Commented out, not required on a client as command endpoint // Commented out, not required on a client as command endpoint
//include_recursive "conf.d" //include_recursive "conf.d"
@ -1086,7 +1072,7 @@ Edit the `api` feature on the client `icinga2-client2.localdomain` in
the `/etc/icinga2/features-enabled/api.conf` file and make sure to set the `/etc/icinga2/features-enabled/api.conf` file and make sure to set
`accept_commands` and `accept_config` to `true`: `accept_commands` and `accept_config` to `true`:
[root@icinga2-client1.localdomain /]# vim /etc/icinga2/features-enabled/api.conf [root@icinga2-client3.localdomain /]# vim /etc/icinga2/features-enabled/api.conf
object ApiListener "api" { object ApiListener "api" {
//... //...
@ -1095,12 +1081,12 @@ the `/etc/icinga2/features-enabled/api.conf` file and make sure to set
} }
Now it is time to validate the configuration and to restart the Icinga 2 daemon Now it is time to validate the configuration and to restart the Icinga 2 daemon
on the client host `icinga2-client1.localdomain`. on the client host `icinga2-client3.localdomain`.
Example on CentOS 7: Example on CentOS 7:
[root@icinga2-client1.localdomain /]# icinga2 daemon -C [root@icinga2-client3.localdomain /]# icinga2 daemon -C
[root@icinga2-client1.localdomain /]# systemctl restart icinga2 [root@icinga2-client3.localdomain /]# systemctl restart icinga2
**Steps on the configuration master node**: **Steps on the configuration master node**:
@ -1114,9 +1100,9 @@ The `repository.d` directory is organised as a tree of object type directories.
repository.d/ repository.d/
├── README ├── README
├── endpoints ├── endpoints
│   └── icinga2-client1.localdomain.conf │   └── icinga2-client3.localdomain.conf
├── hosts ├── hosts
│   ├── icinga2-client1.localdomain │   ├── icinga2-client3.localdomain
│   │   ├── disk\ C%3A.conf │   │   ├── disk\ C%3A.conf
│   │   ├── disk.conf │   │   ├── disk.conf
│   │   ├── icinga.conf │   │   ├── icinga.conf
@ -1126,9 +1112,9 @@ The `repository.d` directory is organised as a tree of object type directories.
│   │   ├── procs.conf │   │   ├── procs.conf
│   │   ├── swap.conf │   │   ├── swap.conf
│   │   └── users.conf │   │   └── users.conf
│   └── icinga2-client1.localdomain.conf │   └── icinga2-client3.localdomain.conf
└── zones └── zones
└── icinga2-client1.localdomain.conf └── icinga2-client3.localdomain.conf
The `endpoints` and `zones` directories contain the required connection The `endpoints` and `zones` directories contain the required connection
information for your client. Decide whether to add the configuration information for your client. Decide whether to add the configuration
@ -1136,7 +1122,7 @@ objects to your `zones.conf` file or keep them as is.
The `hosts` directory contains a `.conf` file for the host object The `hosts` directory contains a `.conf` file for the host object
and a directory with the same name as the host with service configuration and a directory with the same name as the host with service configuration
files, in this example `hosts/icinga2-client1.localdomain`. files, in this example `hosts/icinga2-client3.localdomain`.
The simplest migration path is to merge the Zone, Endpoint, Host and Service The simplest migration path is to merge the Zone, Endpoint, Host and Service
object configuration into one new file called `<FQDN>.conf`, for example object configuration into one new file called `<FQDN>.conf`, for example
@ -1145,21 +1131,21 @@ object configuration into one new file called `<FQDN>.conf`, for example
Therefore create a new file in your master's zone directory in `zones.d`. Therefore create a new file in your master's zone directory in `zones.d`.
In this example we assume that the zone is called `master`. In this example we assume that the zone is called `master`.
Use the information provided by the configuration files `/etc/icinga2/repository.d/zones/icinga2-client1.localdomain.conf` Use the information provided by the configuration files `/etc/icinga2/repository.d/zones/icinga2-client3.localdomain.conf`
and `/etc/icinga2/repository.d/endpoints/icinga2-client1.localdomain.conf`. and `/etc/icinga2/repository.d/endpoints/icinga2-client3.localdomain.conf`.
[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-client1.localdomain.conf [root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-client3.localdomain.conf
object Zone "icinga2-client2.localdomain" { object Zone "icinga2-client3.localdomain" {
endpoints = [ "icinga2-client2.localdomain" ] endpoints = [ "icinga2-client3.localdomain" ]
parent = "master" //defined in zones.conf parent = "master" //defined in zones.conf
} }
object Endpoint "icinga2-client2.localdomain" { object Endpoint "icinga2-client3.localdomain" {
//set the host attribute if the master should connect to the client endpoint //set the host attribute if the master should connect to the client endpoint
} }
Now fetch the Host object information located in the `/etc/icinga2/repository.d/hosts/icinga2-client1.localdomain.conf` Now fetch the Host object information located in the `/etc/icinga2/repository.d/hosts/icinga2-client3.localdomain.conf`
file and adopt it for your needs. One common disadvantage of the bottom up mode is that file and adopt it for your needs. One common disadvantage of the bottom up mode is that
the host object attributes are not synced from the client to the master. Log onto your client the host object attributes are not synced from the client to the master. Log onto your client
and manually copy the required attributes into a new host object. and manually copy the required attributes into a new host object.
@ -1172,9 +1158,9 @@ the command endpoint information. In case you need to learn more details please
the [top down command endpoint](6-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint) the [top down command endpoint](6-distributed-monitoring.md#distributed-monitoring-top-down-command-endpoint)
chapter. chapter.
[root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-client1.localdomain.conf [root@icinga2-master1.localdomain /]# vim /etc/icinga2/zones.d/master/icinga2-client3.localdomain.conf
object Host "icinga2-client1.localdomain.conf" { object Host "icinga2-client3.localdomain.conf" {
//check_command = "hostalive" //check_command = "hostalive"
check_command = "cluster-zone" check_command = "cluster-zone"
vars.cluster_zone = name //host name must be the same as the client's zone name vars.cluster_zone = name //host name must be the same as the client's zone name
@ -1184,8 +1170,8 @@ chapter.
} }
Extract the service objects from the configuration files in the Extract the service objects from the configuration files in the
`/etc/icinga2/repository.d/hosts/icinga2-client1.localdomain` directory `/etc/icinga2/repository.d/hosts/icinga2-client3.localdomain` directory
and add them into the `/etc/icinga2/zones.d/master/icinga2-client1.localdomain.conf` and add them into the `/etc/icinga2/zones.d/master/icinga2-client3.localdomain.conf`
file. file.
Best practice is to use a generic [service apply rule](3-monitoring-basics.md#using-apply) Best practice is to use a generic [service apply rule](3-monitoring-basics.md#using-apply)
@ -1421,6 +1407,9 @@ Add services using command endpoint checks:
Validate the configuration and restart Icinga 2 on the master node `icinga2-master1.localdomain`. Validate the configuration and restart Icinga 2 on the master node `icinga2-master1.localdomain`.
[root@icinga2-master1.localdomain /]# icinga2 daemon -C
[root@icinga2-master1.localdomain /]# systemctl restart icinga2
Open Icinga Web 2 and check the two newly created client hosts with two new services Open Icinga Web 2 and check the two newly created client hosts with two new services
-- one executed locally (`ping4`) and one using command endpoint (`disk`). -- one executed locally (`ping4`) and one using command endpoint (`disk`).
@ -1618,6 +1607,9 @@ Add services using command endpoint checks:
Validate the configuration and restart Icinga 2 on the master node `icinga2-master1.localdomain`. Validate the configuration and restart Icinga 2 on the master node `icinga2-master1.localdomain`.
[root@icinga2-master1.localdomain /]# icinga2 daemon -C
[root@icinga2-master1.localdomain /]# systemctl restart icinga2
Open Icinga Web 2 and check the two newly created client hosts with two new services Open Icinga Web 2 and check the two newly created client hosts with two new services
-- one executed locally (`ping4`) and one using command endpoint (`disk`). -- one executed locally (`ping4`) and one using command endpoint (`disk`).
@ -1738,7 +1730,7 @@ satellites where the connection information is needed as well.
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-client1.localdomain.conf [root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-client1.localdomain.conf
object Endpoint "icinga2-client1.localdomain" { object Endpoint "icinga2-client1.localdomain" {
host = "192.168.33.111" //the satellite actively tries to connect to the client host = "192.168.56.111" //the satellite actively tries to connect to the client
} }
object Zone "icinga2-client1.localdomain" { object Zone "icinga2-client1.localdomain" {
@ -1750,7 +1742,7 @@ satellites where the connection information is needed as well.
[root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-client2.localdomain.conf [root@icinga2-master1.localdomain /etc/icinga2/zones.d/satellite]# vim icinga2-client2.localdomain.conf
object Endpoint "icinga2-client2.localdomain" { object Endpoint "icinga2-client2.localdomain" {
host = "192.168.33.112" //the satellite actively tries to connect to the client host = "192.168.56.112" //the satellite actively tries to connect to the client
} }
object Zone "icinga2-client2.localdomain" { object Zone "icinga2-client2.localdomain" {
@ -1760,12 +1752,12 @@ satellites where the connection information is needed as well.
} }
The two client nodes do not necessarily need to know about each other, either. The only important thing The two client nodes do not necessarily need to know about each other, either. The only important thing
is that they know about the parent zone and their endpoint members (and optionally the global zone). is that they know about the parent zone (the satellite) and their endpoint members (and optionally the global zone).
If you specify the `host` attribute in the `icinga2-master1.localdomain` and `icinga2-master2.localdomain` If you specify the `host` attribute in the `icinga2-satellite1.localdomain` and `icinga2-satellite2.localdomain`
endpoint objects, the client will actively try to connect to the master node. Since we've specified the client endpoint objects, the client node will actively try to connect to the satellite node. Since we've specified the client
endpoint's attribute on the master node already, we don't want the clients to connect to the endpoint's attribute on the satellite node already, we don't want the client node to connect to the
master nodes. Choose one connection direction. satellite nodes. Choose one connection direction.
[root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf [root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
@ -1778,6 +1770,7 @@ master nodes. Choose one connection direction.
} }
object Endpoint "icinga2-client1.localdomain" { object Endpoint "icinga2-client1.localdomain" {
//that's us
} }
object Zone "satellite" { object Zone "satellite" {
@ -1806,6 +1799,7 @@ master nodes. Choose one connection direction.
} }
object Endpoint "icinga2-client2.localdomain" { object Endpoint "icinga2-client2.localdomain" {
//that's us
} }
object Zone "satellite" { object Zone "satellite" {
@ -1827,7 +1821,7 @@ Now it is time to define the two client hosts on the master, sync them to the sa
and apply service checks using the command endpoint execution method to them. and apply service checks using the command endpoint execution method to them.
Add the two client nodes as host objects to the `satellite` zone. Add the two client nodes as host objects to the `satellite` zone.
We've already created the directories in `zones.d`, the files for the We've already created the directories in `/etc/icinga2/zones.d` including the files for the
zone and endpoint configuration for the clients. zone and endpoint configuration for the clients.
[root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/satellite [root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/satellite
@ -1872,6 +1866,9 @@ Add services using command endpoint checks. Pin the apply rules to the `satellit
Validate the configuration and restart Icinga 2 on the master node `icinga2-master1.localdomain`. Validate the configuration and restart Icinga 2 on the master node `icinga2-master1.localdomain`.
[root@icinga2-master1.localdomain /]# icinga2 daemon -C
[root@icinga2-master1.localdomain /]# systemctl restart icinga2
Open Icinga Web 2 and check the two newly created client hosts with two new services Open Icinga Web 2 and check the two newly created client hosts with two new services
-- one executed locally (`ping4`) and one using command endpoint (`disk`). -- one executed locally (`ping4`) and one using command endpoint (`disk`).
@ -2315,7 +2312,7 @@ Configuration on the master node `icinga2-master1.localdomain`:
} }
object Endpoint "icinga2-client2.localdomain" { object Endpoint "icinga2-client2.localdomain" {
host = "192.168.33.112" //the master actively tries to connect to the client host = "192.168.56.112" //the master actively tries to connect to the client
log_duration = 0 log_duration = 0
} }