Introduction to Prometheus Alerting

Data source-managed alerting splits the work between two systems. Understanding where the line falls explains most of the plugin’s behavior, including why some pages work when others are empty.

How it fits together

The ruler evaluates rules. Your Prometheus, Mimir, Cortex, or Loki instance runs each alerting rule on a schedule. When a rule’s expression returns results, the ruler produces one alert per result series.
The ruler sends alerts to Alertmanager. Alerts are pushed continuously for as long as they keep firing. The ruler doesn’t decide who gets notified. It only reports what’s firing.
Alertmanager decides what to do with them. It groups related alerts, walks the routing tree to pick a receiver, applies silences, inhibition rules, and time intervals, and then sends the notification.

Grafana isn’t in this path. The alert would fire and the notification would be delivered even with Grafana switched off. The plugin is a management and observation layer over systems that run on their own.

That’s also why the plugin needs two separate data sources, and why rule pages keep working when no Alertmanager is configured. Refer to Configure data sources.

What this plugin covers

The plugin manages data source-managed resources only: rules stored in a Prometheus-compatible ruler, and configuration stored in an external Alertmanager.

It doesn’t manage Grafana-managed alert rules, which Grafana evaluates itself and stores in its own database, or the built-in Grafana Alertmanager. Those have their own UI. Refer to Grafana Alerting.

Terminology

The plugin uses Alertmanager’s vocabulary rather than the Grafana equivalents, because that’s what the underlying configuration uses. If you’re coming from Grafana Alerting, these are the same concepts under different names: