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; Tares 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 tares 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 Tares 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