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
commit f2fbdd098e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 4 additions and 4 deletions

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) 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. 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): 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. * [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]: Port [5665]:
In case you cannot connect to the master node from your clients, you'll manually need 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. and modify the configuration accordingly.
We'll discuss the details of the required configuration below. We'll discuss the details of the required configuration below.

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 > 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. > 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: 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 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. 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 By default all services remain in a non-volatile state. When a problem
occurs, the `SOFT` state applies and once `max_check_attempts` attribute occurs, the `SOFT` state applies and once `max_check_attempts` attribute