Fix wrong anchors in the documentation

refs #5732

diff --git a/doc/06-distributed-monitoring.md b/doc/06-distributed-monitoring.md
index 63cc15230c47f10d73b4f8ef5b791745d500e96f..b90f0aae04dc3db0b87dcbea3fbee6a829698aaa 100644 (file)
--- a/doc/06-distributed-monitoring.md
+++ b/doc/06-distributed-monitoring.md
@@ -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.

diff --git a/doc/08-advanced-topics.md b/doc/08-advanced-topics.md
index a5060ba7eae9bee4da17f418a6082b38b9713c67..0b130a0efdd586badec8d9e1f3418f5325b2495c 100644 (file)
--- a/doc/08-advanced-topics.md
+++ b/doc/08-advanced-topics.md
@@ -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