From b39859bdfec267f968be4b82c0b6c84bf06c85c7 Mon Sep 17 00:00:00 2001
From: gotjosh <josue@grafana.com>
Date: Mon, 15 Nov 2021 16:15:59 +0000
Subject: [PATCH] Alerting: HA documentation formatting fixes (#41682)
* Alerting: HA documentation formatting fixes
* don't change that line
---
docs/sources/administration/set-up-for-high-availability.md | 2 +-
docs/sources/alerting/unified-alerting/high-availability.md | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/sources/administration/set-up-for-high-availability.md b/docs/sources/administration/set-up-for-high-availability.md
index 21167f8860b..818986df7c8 100644
--- a/docs/sources/administration/set-up-for-high-availability.md
+++ b/docs/sources/administration/set-up-for-high-availability.md
@@ -26,7 +26,7 @@ Grafana will now persist all long term data in the database. How to configure th
Grafana 8 Alerts provides a new highly-available model under the hood. It preserves the previous semantics by executing all alerts on every server and notifications are sent only once per alert. There is no support for load distribution between servers at this time.
-For configuration, [follow the guide]({{ relref "../alerting/unified-alerting/high-availability.md" >}}).
+For configuration, [follow the guide]({{< relref "../alerting/unified-alerting/high-availability.md" >}}).
**Legacy dashboard alerts**
diff --git a/docs/sources/alerting/unified-alerting/high-availability.md b/docs/sources/alerting/unified-alerting/high-availability.md
index d79498d2f9a..242de6f32fa 100644
--- a/docs/sources/alerting/unified-alerting/high-availability.md
+++ b/docs/sources/alerting/unified-alerting/high-availability.md
@@ -9,7 +9,7 @@ weight = 450
The Grafana alerting system has two main components: a `Scheduler` and an internal `Alertmanager`. The `Scheduler` is responsible for the evaluation of your [alert rules]({{< relref "./fundamentals/evaluate-grafana-alerts.md" >}}) while the internal Alertmanager takes care of the **routing** and **grouping**.
-When it comes to running Grafana alerting in high availability the operational mode of the scheduler is unaffected such that all alerts continue be evaluated in each Grafana instance. Rather the operational change happens in the Alertmanager which \*deduplicates\*\* alert notifications across Grafana instances.
+When it comes to running Grafana alerting in high availability the operational mode of the scheduler is unaffected such that all alerts continue be evaluated in each Grafana instance. Rather the operational change happens in the Alertmanager which **deduplicates** alert notifications across Grafana instances.
```
.─────.
@@ -45,7 +45,7 @@ These two states are persisted in the database periodically and when Grafana is
To enable high availability support you need to add at least 1 Grafana instance to the [`[ha_peer]` configuration option]({{<relref"../../administration/configuration.md#unified_alerting">}}) within the `[unified_alerting]` section:
1. In your custom configuration file ($WORKING_DIR/conf/custom.ini), go to the `[unified_alerting]` section.
-2. Set `[ha_peers]` to the set of hosts for each grafana instance in the cluster (using a format of host:port) e.g. `ha_peers=10.0.0.5:9094,10.0.0.6:9094,10.0.0.7:9094`
+2. Set `[ha_peers]` to the number of hosts for each grafana instance in the cluster (using a format of host:port) e.g. `ha_peers=10.0.0.5:9094,10.0.0.6:9094,10.0.0.7:9094`
3. Gossiping of notifications and silences uses both TCP and UDP port 9094. Each Grafana instance will need to be able to accept incoming connections on these ports.
4. Set `[ha_listen_address]` to the instance IP address using a format of host:port (or the [Pod's](https://kubernetes.io/docs/concepts/workloads/pods/) IP in the case of using Kubernetes) by default it is set to listen to all interfaces (`0.0.0.0`).