Prometheus alerts — `prometheus_alerts`

Polls Prometheus’s own /api/v1/alerts — the alerts its alerting rules have already fired. One event per active alert, keyed by a label, plus a resolved event when it clears. No Alertmanager and no PromQL: Prometheus decides what’s an alert; NavFlow correlates it and can dispatch it to an agent.

State is tracked across polls, so each alert fires once (re-emitting only on a state change) and emits a resolved event when it disappears — not one copy every tick.

Supports discovery: given a url, it lists the configured alerting rules and the severities present.

Prerequisites: a reachable Prometheus server with alerting rules configured.

Set up

Agent

Ask a connected agent:

Use navflow to ingest the firing alerts from the Prometheus at localhost:9090.

The agent calls discover_source (lists the configured rules and the severities present), then create_source.

Console

Sources → Add source → Prometheus alerts. Enter the url (+ any auth) and Discover — it lists the configured alerting rules and their severities. Optionally filter by severity (blank = all) and toggle include pending. It proposes the always-present labels (severity, state); add per-alert labels like namespace / service from the Fields view once alerts have been ingested.

YAML / API


- name: alerts
  connector: prometheus_alerts
  poll: 30s
  config:
    url: http://localhost:9090
    severities: critical,warning   # blank = all
    labels:
      - { name: severity, field: labels.severity, primary: true }
      - { name: state, field: state }

Or POST /api/sources with the same object.

Each alert becomes an event with event_type = the alert name, text = its summary, and its labels as NavFlow labels plus a synthetic state (firing / pending / resolved).

Configuration

field	type	description
`url`*	string	Prometheus base URL, e.g. `http://localhost:9090`
`bearer_token`	string · secret	optional `Authorization: Bearer` token (managed Prometheus / auth proxy)
`username`	string	optional HTTP basic-auth username
`password`	string · secret	optional HTTP basic-auth password / API token, paired with `username`
`severities`	string	comma-separated severities to ingest (blank = all), e.g. `critical,warning`
`include_pending`	bool	also ingest alerts still `pending` (waiting out their `for:` duration)

Discover only proposes the labels guaranteed to be present (severity, state) — an alert’s dynamic labels (namespace, service, …) only exist while it’s firing. Add those from the Fields view once real alerts have been ingested.

Verify

Open the source: Recent events shows one event per active alert (and resolved events as they clear); Fields shows the labels the alerts carry, so you can promote namespace / service to correlate on.

Prometheus alerts — prometheus_alerts