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

Merge pull request #5761 from Icinga/fix/docs-wrong-anchors 

Fix wrong anchors in the documentation
This commit is contained in:
Michael Friedrich 2017-11-15 11:23:00 +01:00 committed by GitHub
parent 6c2e98a6fd 77851c0a48
commit f2fbdd098e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/06-distributed-monitoring.md
View File

@ -258,7 +258,7 @@ that all nodes trust each other in a distributed monitoring environment.
This CA is generated during the [master setup](06-distributed-monitoring.md#distributed-monitoring-setup-master)
and should be the same on all master instances.
You can avoid signing and deploying certificates [manually](#06-distributed-monitoring.md#distributed-monitoring-advanced-hints-certificates)
You can avoid signing and deploying certificates [manually](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-certificates-manual)
by using built-in methods for auto-signing certificate signing requests (CSR):
* [CSR Auto-Signing](06-distributed-monitoring.md#distributed-monitoring-setup-csr-auto-signing) which uses a client ticket generated on the master as trust identifier.
@ -1575,7 +1575,7 @@ Specify the master node `icinga2-master2.localdomain` with the CA private key an
Port [5665]:
In case you cannot connect to the master node from your clients, you'll manually need
to [generate the SSL certificates](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-certificates)
to [generate the SSL certificates](06-distributed-monitoring.md#distributed-monitoring-advanced-hints-certificates-manual)
and modify the configuration accordingly.
We'll discuss the details of the required configuration below.

4
doc/08-advanced-topics.md
View File

@ -433,7 +433,7 @@ host or service is considered flapping until it drops below the low flapping thr
> Note: There is no distinctions between hard and soft states with flapping. All state changes count and notifications
> will be sent out regardless of the objects state.
### How it works <a id="how-it-works"></a>
### How it works <a id="check-flapping-how-it-works"></a>
Icinga 2 saves the last 20 state changes for every host and service. See the graphic below:
@ -450,7 +450,7 @@ considered flapping.
If the next seven check results then would not be state changes, the flapping percentage would fall below the lower threshold
of 25% and therefore the host or service would recover from flapping.
# Volatile Services <a id="volatile-services"></a>
## Volatile Services <a id="volatile-services"></a>
By default all services remain in a non-volatile state. When a problem
occurs, the `SOFT` state applies and once `max_check_attempts` attribute