082cfbdb06
* Initial commit * Moved files, ad fixed broken relrefs. * Fixed other broken relrefs * More changes. * Fixing broken relrefs * More changes. * Fixed last of the broken links * More re-org. * Added aliases and some weight adjustments * More aliases. * Fix fundamentals topic. * Fixed remaining metadata issues * Ran prettier
1.6 KiB
+++ title = " Alerting high availability" description = "High availability" keywords = ["grafana", "alerting", "tutorials", "ha", "high availability"] aliases = ["/docs/grafana/latest/alerting/unified-alerting/high-availability/"]
weight = 450 +++
About alerting high availability
The Grafana alerting system has two main components: a Scheduler and an internal Alertmanager. The Scheduler evaluates your [alert rules]({{< relref "../fundamentals/evaluate-grafana-alerts.md" >}}), while the internal Alertmanager manages routing and grouping.
When running Grafana alerting in high availability, the operational mode of the scheduler remains unaffected, and each Grafana instance evaluates all alerts. The operational change happens in the Alertmanager when it deduplicates alert notifications across Grafana instances.
{{< figure src="/static/img/docs/alerting/unified/high-availability-ua.png" class="docs-image--no-shadow" max-width= "750px" caption="High availability" >}}
The coordination between Grafana instances happens via a Gossip protocol. Alerts are not gossiped between instances and each scheduler delivers the same volume of alerts to each Alertmanager.
The two types of messages gossiped between Grafana instances are:
- Notification logs: Who (which instance) notified what (which alert).
- Silences: If an alert should fire or not.
The notification logs and silences are persisted in the database periodically and during a graceful Grafana shut down.
For configuration instructions, refer to [enable alerting high availability]({{< relref "./enable-alerting-ha.md" >}}).