tyler.durden/icinga2
1
0
Fork 0
mirror of https://github.com/Icinga/icinga2.git synced 2025-07-23 21:55:03 +02:00
Code Issues Packages Projects Releases Wiki Activity

Doc: Enhance Zones in Zones troubleshooting

Browse Source
This commit is contained in:
Yonas Habteab 2022-02-24 12:16:14 +01:00 committed by Alexander A. Klimov
parent 54663332e5
commit f903e3aa12
1 changed files with 42 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
doc/15-troubleshooting.md
View File

@ -1682,53 +1682,26 @@ In order to solve this problem, remove the mentioned files from `zones.d` and us
of syncing plugin binaries to your satellites and agents. of syncing plugin binaries to your satellites and agents.
#### Zones in Zones doesn't work <a id="troubleshooting-cluster-config-zones-in-zones"></a> #### Zones in Zones <a id="troubleshooting-cluster-config-zones-in-zones"></a>
The cluster config sync works in the way that configuration The cluster config sync works in a such manner that any `/etc/icinga2/zones.d/` subdirectory is included only when it is
put into `/etc/icinga2/zones.d` only is included when configured named after a known zone by the local `Endpoint`.
outside in `/etc/icinga2/zones.conf`.
If you for example create a "Zone Inception" with defining the If you for example add some configs in to `zones.d/satellite` and forgot to define the `satellite` zone
`satellite` zone in `zones.d/master`, the config compiler does not in `zones.d/master` or outside in `/etc/icinga2/zones.conf`, the config compiler will not include
re-run and include this zone config recursively from `zones.d/satellite`. this config from the `zones.d/satellite` zone directory.
Since v2.11, the config compiler is only including directories where a Since v2.11, the config compiler is only including directories where a
zone has been configured. Otherwise it would include renamed old zones, zone has been configured. Otherwise, it would include renamed old zones,
broken zones, etc. and those long-lasting bugs have been now fixed. broken zones, etc. and those long-lasting bugs have been now fixed.
A more concrete example: Masters and Satellites still need to know the Zone hierarchy outside of `zones.d` synced configuration. Here are some working examples:
**Doesn't work** **Example: Everything in `zones.conf`**
``` Each instance needs to know the `Zone` and `Endpoint` definitions for itself and all directly connected instances in order
vim /etc/icinga2/zones.conf to successfully establish a connection with each other. This can be achieved by placing all `Endpoint` and `Zone` definitions
of all Icinga 2 instances known by the local endpoint in this single file.
object Zone "master" {
endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
}
```
```
vim /etc/icinga2/zones.d/master/satellite-zones.conf
object Zone "satellite" {
endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite1.localdomain" ]
}
```
```
vim /etc/icinga2/zones.d/satellite/satellite-hosts.conf
object Host "agent" { ... }
```
The `agent` host object will never reach the satellite, since the master does not have
the `satellite` zone configured outside of zones.d.
**Works**
Each instance needs to know this, and know about the endpoints first:
``` ```
vim /etc/icinga2/zones.conf vim /etc/icinga2/zones.conf
@ -1736,24 +1709,41 @@ vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.localdomain" { ... } object Endpoint "icinga2-master1.localdomain" { ... }
object Endpoint "icinga2-master2.localdomain" { ... } object Endpoint "icinga2-master2.localdomain" { ... }
object Endpoint "icinga2-satellite1.localdomain" { ... }
object Endpoint "icinga2-satellite2.localdomain" { ... }
```
Then the zone hierarchy as trust and also config sync inclusion is required.
```
vim /etc/icinga2/zones.conf
object Zone "master" { object Zone "master" {
endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ] endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
} }
object Endpoint "icinga2-satellite1.localdomain" { ... }
object Endpoint "icinga2-satellite2.localdomain" { ... }
object Zone "satellite" { object Zone "satellite" {
endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite1.localdomain" ] endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite1.localdomain" ]
parent = "master"
} }
``` ```
**Example: Child zones in `zones.d/`**
An additional option that Icinga 2 offers is the possibility to outsource all *child* `Endpoint` definitions of the
local Icinga 2 instance to the `zones.d/` directory. As an example, we can place the satellite `Zone` and `Endpoint` definition
from the above example into `zones.d/` underneath a directory named exactly like the local endpoint `Zone` name, which
in our case is `master`.
```
mkdir /etc/icinga2/zones.d/master
vim /etc/icinga2/zones.d/master/satellite.conf
object Endpoint "icinga2-satellite1.localdomain" { ... }
object Endpoint "icinga2-satellite2.localdomain" { ... }
object Zone "satellite" {
endpoints = [ "icinga2-satellite1.localdomain", "icinga2-satellite1.localdomain" ]
parent = "master"
}
...
```
Once done, you can start deploying actual monitoring objects into the satellite zone. Once done, you can start deploying actual monitoring objects into the satellite zone.
``` ```
@ -1762,10 +1752,12 @@ vim /etc/icinga2/zones.d/satellite/satellite-hosts.conf
object Host "agent" { ... } object Host "agent" { ... }
``` ```
That's also explained and described in the [documentation](06-distributed-monitoring.md#distributed-monitoring-scenarios-master-satellite-agents). Keep in mind that the `agent` host object will never reach the satellite, when the master does not have the
`satellite` zone configured either in `zones.d/master` nor outside the `zones.d` directory. That's also explained and
described in the [documentation](06-distributed-monitoring.md#distributed-monitoring-scenarios-master-satellite-agents).
The thing you can do: For `command_endpoint` agents like inside the Director: The thing you can do: For `command_endpoint` agents like inside the Director:
Host -> Agent -> yes, there is no config sync for this zone in place. Therefore Host -> Agent -> yes, there is no config sync for this zone in place. Therefore,
it is valid to just sync their zones via the config sync. it is valid to just sync their zones via the config sync.
#### Director Changes #### Director Changes