Prometheus Alertmanager integration

Prometheus Alertmanager receives the alerts a Prometheus server fires, deduplicates and groups them, and routes each group to the receivers its YAML configuration declares (email, PagerDuty, Slack, OpsGenie, generic webhooks and the rest). It is a separate process from Prometheus and answers on its own port, so it carries its own credential here. This integration covers the whole v2 HTTP API. Read the instance status: build version and revision, cluster gossip state with its peers, process uptime, and the configuration file currently loaded (Alertmanager renders every secret field in it as a placeholder, so no password or token is returned). List alerts with their labels, annotations, generator URL, fingerprint, start, end and update times, the receivers they resolve to, and a status saying whether each one is active, unprocessed, or suppressed and by which silence or inhibition rule. List the same alerts already grouped the way Alertmanager will notify on them, one group per label set with its receiver. Push alerts into the instance the way Prometheus itself does, which is how an agent raises or resolves an alert from a workflow. List the configured receivers. And manage silences, the mute rules that match alerts by label matchers over a time window: list them filtered by active, pending or expired state, read one by its id, create one, update an existing one by passing its id in the same call, and expire one early. Every listing route also accepts repeated matcher expressions such as alertname="MyAlert" to filter server-side. The host is part of the credential because every Alertmanager is its own deployment. Alertmanager has no user accounts: authenticate with the HTTP basic auth its own web configuration file enforces, or with a bearer token when the instance sits behind an authenticating proxy.