tyler.durden/icinga2
1
0
Fork 0
mirror of https://github.com/Icinga/icinga2.git synced 2025-04-07 20:25:08 +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
parent 4522522444
commit 8a02eab411
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

@ -1628,53 +1628,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.
#### 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
put into `/etc/icinga2/zones.d` only is included when configured
outside in `/etc/icinga2/zones.conf`.
The cluster config sync works in a such manner that any `/etc/icinga2/zones.d/` subdirectory is included only when it is
named after a known zone by the local `Endpoint`.
If you for example create a "Zone Inception" with defining the
`satellite` zone in `zones.d/master`, the config compiler does not
re-run and include this zone config recursively from `zones.d/satellite`.
If you for example add some configs in to `zones.d/satellite` and forgot to define the `satellite` zone
in `zones.d/master` or outside in `/etc/icinga2/zones.conf`, the config compiler will not include
this config from the `zones.d/satellite` zone directory.
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.
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`**
```
vim /etc/icinga2/zones.conf
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:
Each instance needs to know the `Zone` and `Endpoint` definitions for itself and all directly connected instances in order
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.
```
vim /etc/icinga2/zones.conf
@ -1682,24 +1655,41 @@ vim /etc/icinga2/zones.conf
object Endpoint "icinga2-master1.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" {
endpoints = [ "icinga2-master1.localdomain", "icinga2-master2.localdomain" ]
}
object Endpoint "icinga2-satellite1.localdomain" { ... }
object Endpoint "icinga2-satellite2.localdomain" { ... }
object Zone "satellite" {
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.
```
@ -1708,10 +1698,12 @@ vim /etc/icinga2/zones.d/satellite/satellite-hosts.conf
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:
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.
#### Director Changes