Fix client names in distributed monitoring docs

fixes #4996

diff --git a/doc/6-distributed-monitoring.md b/doc/6-distributed-monitoring.md
index 7e5fee9a2bc577d96f0cabc19a545742aac00e49..5920b930cd317a04ab4293562f80a5b085643e64 100644 (file)
--- a/doc/6-distributed-monitoring.md
+++ b/doc/6-distributed-monitoring.md
@@ -624,7 +624,7 @@ commands, you need to configure the `Zone` and `Endpoint` hierarchy
 on all nodes.
 
 * `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`.
 
@@ -636,8 +636,8 @@ The endpoint configuration could look like this, for example:
       host = "192.168.56.101"
     }
 
-    object Endpoint "icinga2-client2.localdomain" {
-      host = "192.168.56.112"
+    object Endpoint "icinga2-client1.localdomain" {
+      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.
@@ -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
 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
 
@@ -653,8 +653,8 @@ The `master` zone is a parent of the `icinga2-client2.localdomain` zone:
       endpoints = [ "icinga2-master1.localdomain" ] //array with endpoint names
     }
 
-    object Zone "icinga2-client2.localdomain" {
-      endpoints = [ "icinga2-client2.localdomain" ]
+    object Zone "icinga2-client1.localdomain" {
+      endpoints = [ "icinga2-client1.localdomain" ]
 
       parent = "master" //establish zone hierarchy
     }
@@ -678,7 +678,7 @@ in `/etc/icinga2/icinga2.conf`.
     // Commented out, not required on a client as command endpoint
     //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
 `accept_commands` and `accept_config` to `true`:
 
@@ -695,8 +695,8 @@ on both nodes.
 
 Example on CentOS 7:
 
-    [root@icinga2-client2.localdomain /]# icinga2 daemon -C
-    [root@icinga2-client2.localdomain /]# systemctl restart icinga2
+    [root@icinga2-client1.localdomain /]# icinga2 daemon -C
+    [root@icinga2-client1.localdomain /]# systemctl restart icinga2
 
     [root@icinga2-master1.localdomain /]# icinga2 daemon -C
     [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 /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
-      address = "192.168.56.112"
+      address = "192.168.56.111"
 
       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.
 * 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-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 receives the execute command event with additional command parameters.
+* 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.
 
@@ -799,20 +799,20 @@ commands, you need to configure the `Zone` and `Endpoint` hierarchy
 on all nodes.
 
 * `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`.
 
 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" {
       host = "192.168.56.101"
     }
 
-    object Endpoint "icinga2-client1.localdomain" {
-      host = "192.168.56.111"
+    object Endpoint "icinga2-client2.localdomain" {
+      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.
@@ -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
 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" {
       endpoints = [ "icinga2-master1.localdomain" ] //array with endpoint names
     }
 
-    object Zone "icinga2-client1.localdomain" {
-      endpoints = [ "icinga2-client1.localdomain" ]
+    object Zone "icinga2-client2.localdomain" {
+      endpoints = [ "icinga2-client2.localdomain" ]
 
       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
 `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" {
        //...
@@ -850,8 +850,8 @@ on both nodes.
 
 Example on CentOS 7:
 
-    [root@icinga2-client1.localdomain /]# icinga2 daemon -C
-    [root@icinga2-client1.localdomain /]# systemctl restart icinga2
+    [root@icinga2-client2.localdomain /]# icinga2 daemon -C
+    [root@icinga2-client2.localdomain /]# systemctl restart icinga2
 
     [root@icinga2-master1.localdomain /]# icinga2 daemon -C
     [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
 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
 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.
 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 /etc/icinga2/zones.d/icinga2-client1.localdomain]# vim hosts.conf
+    [root@icinga2-master1.localdomain /]# cd /etc/icinga2/zones.d/icinga2-client2.localdomain
+    [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"
-      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
     }
 
 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.
 
-    [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" {
-      host_name = "icinga2-client1.localdomain"
+      host_name = "icinga2-client2.localdomain"
 
       check_command = "disk"
     }
@@ -909,8 +909,8 @@ The following steps will happen:
 * 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`.
 * 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-client1.localdomain` node validates the configuration and automatically restarts.
+* The `icinga2-client2.localdomain` node accepts config and populates the local zone config store with the received config files.
+* The `icinga2-client2.localdomain` node validates the configuration and automatically restarts.
 
 Again, there is no interaction required on the client
 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
     Warning: CLI command 'node list' is DEPRECATED! Please read the Changelog.
 
-    Node 'icinga2-client1.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)
+    Node 'icinga2-client3.localdomain' (last seen: Sun Aug 14 11:19:14 2016)
         * Host 'icinga2-client2.localdomain'
             * Service 'disk'
             * Service 'disk C:'
@@ -1066,7 +1052,7 @@ configuration file.
 Add a [global zone](6-distributed-monitoring.md#distributed-monitoring-global-zone-config-sync)
 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" {
       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
 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
     //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
 `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" {
        //...
@@ -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
-on the client host `icinga2-client1.localdomain`.
+on the client host `icinga2-client3.localdomain`.
 
 Example on CentOS 7:
 
-    [root@icinga2-client1.localdomain /]# icinga2 daemon -C
-    [root@icinga2-client1.localdomain /]# systemctl restart icinga2
+    [root@icinga2-client3.localdomain /]# icinga2 daemon -C
+    [root@icinga2-client3.localdomain /]# systemctl restart icinga2
 
 
 **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/
     ├── README
     ├── endpoints
-    │   └── icinga2-client1.localdomain.conf
+    │   └── icinga2-client3.localdomain.conf
     ├── hosts
-    │   ├── icinga2-client1.localdomain
+    │   ├── icinga2-client3.localdomain
     │   │   ├── disk\ C%3A.conf
     │   │   ├── disk.conf
     │   │   ├── icinga.conf
@@ -1126,9 +1112,9 @@ The `repository.d` directory is organised as a tree of object type directories.
     │   │   ├── procs.conf
     │   │   ├── swap.conf
     │   │   └── users.conf
-    │   └── icinga2-client1.localdomain.conf
+    │   └── icinga2-client3.localdomain.conf
     └── zones
-        └── icinga2-client1.localdomain.conf
+        └── icinga2-client3.localdomain.conf
 
 The `endpoints` and `zones` directories contain the required connection
 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
 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
 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`.
 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`
-and `/etc/icinga2/repository.d/endpoints/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-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" {
-      endpoints = [ "icinga2-client2.localdomain" ]
+    object Zone "icinga2-client3.localdomain" {
+      endpoints = [ "icinga2-client3.localdomain" ]
       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
     }
 
-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
 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.
@@ -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)
 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 = "cluster-zone"
       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
-`/etc/icinga2/repository.d/hosts/icinga2-client1.localdomain` directory
-and add them into the `/etc/icinga2/zones.d/master/icinga2-client1.localdomain.conf`
+`/etc/icinga2/repository.d/hosts/icinga2-client3.localdomain` directory
+and add them into the `/etc/icinga2/zones.d/master/icinga2-client3.localdomain.conf`
 file.
 
 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`.
 
+    [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
 -- 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`.
 
+    [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
 -- 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
 
     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" {
@@ -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
 
     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" {
@@ -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
-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`
-endpoint objects, the client will actively try to connect to the master 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
-master nodes. Choose one connection direction.
+If you specify the `host` attribute in the `icinga2-satellite1.localdomain` and `icinga2-satellite2.localdomain`
+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 satellite node already, we don't want the client node to connect to the
+satellite nodes. Choose one connection direction.
 
     [root@icinga2-client1.localdomain /]# vim /etc/icinga2/zones.conf
 
@@ -1778,6 +1770,7 @@ master nodes. Choose one connection direction.
     }
 
     object Endpoint "icinga2-client1.localdomain" {
+      //that's us
     }
 
     object Zone "satellite" {
@@ -1806,6 +1799,7 @@ master nodes. Choose one connection direction.
     }
 
     object Endpoint "icinga2-client2.localdomain" {
+      //that's us
     }
 
     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.
 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.
 
     [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`.
 
+    [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
 -- 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" {
-      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
     }