Prometheus connector

The Prometheus connector spans two related self-hosted services under one connector: the Prometheus server HTTP API for PromQL reads, and the Alertmanager HTTP API v2 for the actionable alert lifecycle. Prometheus has no incident object of its own, so a workflow's incident lifecycle is Alertmanager silences plus alert-state reads.

You can use this connector in Agent Builder and Workflows.

Use the connector's PromQL actions to check a live metric or a trend over time, and its Alertmanager actions to read what is firing and mute expected noise — for example, during a deploy or maintenance window — without opening the Prometheus or Alertmanager UI or hand-writing API calls. Alertmanager's core lifecycle primitive is the silence: mute a set of alerts matching label matchers for a time window, then let it expire (or expire it early) to allow those alerts to fire again.

Prometheus and Alertmanager are self-hosted, so the target instance(s) must be network-reachable from Kibana.

You can create connectors in Stack Management > Connectors.

Prometheus connectors have the following configuration properties:

Alertmanager URL

The base URL of the Alertmanager instance, for example https://alertmanager.example.com. This host must be permitted by the xpack.actions.allowedHosts setting.

Prometheus server URL (optional)

The base URL of the Prometheus server associated with this Alertmanager, for example https://prometheus.example.com. Required for the queryPrometheus, queryRangePrometheus, listPrometheusAlerts, listPrometheusRules, listPrometheusTargets, getPrometheusSeries, and listPrometheusLabelValues actions — leave empty if you don't need any of these. Reuses the credential configured in the following section. This host must also be permitted by xpack.actions.allowedHosts when set.

Username and password

Username

The username configured for HTTP basic authentication on the Alertmanager instance — either the basic_auth_users setting in Alertmanager's own --web.config.file, or an account on a reverse proxy placed in front of it.

Password

The password for that account.

Bearer token

Bearer token

A bearer token accepted by a reverse proxy or gateway placed in front of Alertmanager and Prometheus. Neither Alertmanager nor Prometheus has built-in bearer token support, so this option only applies if such a proxy is in place.

You can test connectors when you create or edit the connector in Kibana. The test calls the Alertmanager status API (GET /api/v2/status) to verify connectivity and credentials.

The Prometheus connector has the following actions:

listAlerts

List current alerts. Optional filters: active, silenced, inhibited, unprocessed (booleans, all default to true), filter (an array of label matcher expressions, for example alertname="HighCPU" or severity=~"critical|warning"), and receiver (a regular expression matching receiver names).

listSilences

List silences (pending, active, and expired). Optional filter, an array of label matcher expressions, same format as listAlerts.

getSilence

Get a single silence by silenceId, returning its matchers, time window, and state.

createSilence

Create a silence to mute alerts matching label matchers for a time window. Requires matchers (an array of { name, value, isRegex?, isEqual? } objects — all must match for an alert to be silenced), startsAt and endsAt (RFC3339 timestamps), createdBy, and comment. Returns the new silence ID.

expireSilence

Expire a silence by silenceId so the alerts it was muting can fire again immediately, instead of waiting for its endsAt.

listAlertGroups

List alerts grouped by their routing labels — useful for reasoning about a correlated incident rather than individual alerts. Optional filters: active, silenced, inhibited, muted (booleans), filter (label matcher expressions), and receiver (a regex).

createAlerts

Push one or more synthetic alerts (alerts, each with labels, optional annotations, startsAt, endsAt, and generatorURL) into Alertmanager. The alerts follow normal routing and notification, letting a workflow raise its own alert.

getStatus

Read the Alertmanager instance status: version, uptime, cluster peers, and the currently loaded configuration.

These actions require the optional Prometheus server URL to be configured.

queryPrometheus

Run a PromQL instant query (query, optional time) against the configured Prometheus server and return the current value(s).

queryRangePrometheus

Run a PromQL range query (query, start, end, step) and return a series of samples — useful for a trend check or a before-and-after comparison.

listPrometheusAlerts

List firing and pending alerts as seen directly by the Prometheus server, before they reach Alertmanager.

listPrometheusRules

List the alerting and recording rules currently loaded by the Prometheus server, including each alerting rule's currently active alerts. Optional filters: type (alert or record), ruleName, and ruleGroup.

listPrometheusTargets

List scrape targets with their up/down health and last scrape error. Optional state filter (active, dropped, or any).

getPrometheusSeries

Find time series matching one or more series selector expressions (match), optionally restricted to a time range (start, end), without returning sample values.

listPrometheusLabelValues

List the known values of a label (label), optionally restricted by series selector expressions (match) and a time range (start, end).

Use the Action configuration settings to customize connector networking, such as proxies, certificates, or TLS settings. Make sure the Alertmanager URL (and the Prometheus server URL, if configured) are permitted by xpack.actions.allowedHosts.

Alertmanager does not have built-in user accounts by default — authentication is configured at the web-server layer:

1. On the Alertmanager host, define one or more users under basic_auth_users in the file passed to --web.config.file (passwords are bcrypt-hashed; see the HTTPS and authentication docs), or configure basic authentication (or bearer token validation, via a reverse proxy) on a reverse proxy placed in front of Alertmanager.
2. Restart (or reload the web config of) Alertmanager so the new credentials take effect.
3. Enter the Alertmanager URL and that username/password (or bearer token) when configuring the connector in Kibana.
4. If you also want the Prometheus server actions, enter the associated Prometheus server's URL — it reuses the same credential.