From 77851c0a48c1a85b4d855e12fdf3691d79f32708 Mon Sep 17 00:00:00 2001 From: Michael Friedrich Date: Wed, 15 Nov 2017 11:10:52 +0100 Subject: [PATCH] Fix wrong anchors in the documentation refs #5732 --- doc/06-distributed-monitoring.md | 4 ++-- doc/08-advanced-topics.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/06-distributed-monitoring.md b/doc/06-distributed-monitoring.md index 63cc15230..b90f0aae0 100644 --- 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 a5060ba7e..0b130a0ef 100644 --- 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 +### How it works 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 +## Volatile Services By default all services remain in a non-volatile state. When a problem occurs, the `SOFT` state applies and once `max_check_attempts` attribute