Autor: [Tomasz Nowosielski](/autorzy/tomasz-nowosielski) Redaktor naczelny, analityk hostingu · Zweryfikowano Kwiecień 2026

1.  [Strona główna](/) ›
2.  [Baza wiedzy](/baza-wiedzy/) ›
3.  Prometheus Alertmanager — konfiguracja

# Prometheus Alertmanager — konfiguracja reguł alertów i routingu

Opublikowano: 10 kwietnia 2026 · Kategoria: VPS

Prometheus zbiera metryki i wykrywa anomalie — ale samo wykrycie to za mało. Alertmanager zamienia surowe zdarzenia FIRING/RESOLVED w inteligentne powiadomienia: grupuje, wycisza, routuje do właściwych zespołów i kanałów. Oto kompletny przewodnik po konfiguracji od pierwszych reguł po klaster HA.

## Alert rules w Prometheus — plik YAML

Reguły alertów definiujesz w plikach `.yml` wskazanych w `prometheus.yml`. Każda reguła to wyrażenie PromQL — gdy zwróci wyniki, alert staje się PENDING, a po `for` sekundach — FIRING:

\# /etc/prometheus/rules/alerts.yml

groups:
  - name: node\_alerts
    interval: 60s   # jak często oceniać reguły (domyślnie global interval)
    rules:

      # Alert gdy CPU > 85% przez 5 minut
      - alert: HighCpuUsage
        expr: 100 - (avg by(instance) (rate(node\_cpu\_seconds\_total{mode="idle"}\[5m\])) \* 100) > 85
        for: 5m
        labels:
          severity: warning
          team: ops
        annotations:
          summary: "Wysokie użycie CPU na {{ $labels.instance }}"
          description: "CPU: {{ $value | printf \\"%.1f\\" }}% przez ostatnie 5 minut."
          runbook\_url: "https://wiki.example.com/runbooks/high-cpu"

      # Alert gdy RAM < 10%
      - alert: LowMemory
        expr: node\_memory\_MemAvailable\_bytes / node\_memory\_MemTotal\_bytes \* 100 < 10
        for: 2m
        labels:
          severity: critical
          team: ops
        annotations:
          summary: "Mało wolnej pamięci na {{ $labels.instance }}"
          description: "Wolna pamięć: {{ $value | printf \\"%.1f\\" }}%"

      # Alert gdy instancja jest niedostępna
      - alert: InstanceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Instancja {{ $labels.instance }} jest niedostępna"

Zarejestruj plik reguł w `prometheus.yml`:

rule\_files:
  - "/etc/prometheus/rules/\*.yml"

alerting:
  alertmanagers:
    - static\_configs:
        - targets: \["localhost:9093"\]

## alertmanager.yml — struktura konfiguracji

Plik konfiguracyjny Alertmanagera składa się z czterech kluczowych sekcji:

Sekcja

Odpowiedzialność

`global`

Globalne domyślne (SMTP, Slack URL, timeout resolve)

`route`

Drzewo routingu — dokąd trafią alerty

`receivers`

Kanały powiadomień (email, Slack, PagerDuty...)

`inhibit_rules`

Reguły wyciszania symptomów przez przyczynę

\# /etc/alertmanager/alertmanager.yml

global:
  resolve\_timeout: 5m
  smtp\_smarthost: "smtp.example.com:587"
  smtp\_from: "alertmanager@example.com"
  smtp\_auth\_username: "user"
  smtp\_auth\_password: "secret"
  slack\_api\_url: "https://hooks.slack.com/services/T00/B00/xxx"

route:
  receiver: "default"
  group\_by: \["alertname", "job"\]
  group\_wait: 30s
  group\_interval: 5m
  repeat\_interval: 4h

  routes:
    # Alerty krytyczne → PagerDuty z krótkim group\_wait
    - match:
        severity: critical
      receiver: pagerduty-team
      group\_wait: 10s
      repeat\_interval: 1h
      continue: false

    # Alerty zespołu baz danych
    - match\_re:
        alertname: "^(MySQL|PostgreSQL|Redis).\*"
      receiver: team-database
      group\_by: \["alertname", "instance"\]

receivers:
  - name: "default"
    email\_configs:
      - to: "ops-team@example.com"
        send\_resolved: true

  - name: pagerduty-team
    pagerduty\_configs:
      - routing\_key: "PAGERDUTY\_INTEGRATION\_KEY"
        description: "{{ .CommonAnnotations.summary }}"
        severity: "{{ .CommonLabels.severity }}"

  - name: team-database
    slack\_configs:
      - channel: "#db-alerts"
        title: "{{ .CommonAnnotations.summary }}"
        text: "{{ range .Alerts }}{{ .Annotations.description }}\\n{{ end }}"
        send\_resolved: true

## Receivers — Slack, email i PagerDuty

Alertmanager obsługuje wiele kanałów. Poniżej praktyczne konfiguracje dla najpopularniejszych:

\# Slack — bogaty format wiadomości
receivers:
  - name: slack-ops
    slack\_configs:
      - api\_url: "https://hooks.slack.com/services/..."
        channel: "#ops-alerts"
        icon\_emoji: ":rotating\_light:"
        color: '{{ if eq .Status "firing" }}danger{{ else }}good{{ end }}'
        title: '{{ .Status | toUpper }} {{ .CommonAnnotations.summary }}'
        text: |
          {{ range .Alerts }}
          \*Alert:\* {{ .Annotations.summary }}
          \*Opis:\* {{ .Annotations.description }}
          \*Severity:\* {{ .Labels.severity }}
          \*Runbook:\* {{ .Annotations.runbook\_url }}
          {{ end }}
        send\_resolved: true

# Webhook (np. custom endpoint, Teams, Discord)
  - name: webhook-custom
    webhook\_configs:
      - url: "https://your-endpoint.example.com/webhook"
        send\_resolved: true
        http\_config:
          bearer\_token: "secret-token"

## Silences — wyciszanie alertów

Silence to tymczasowe wyciszenie alertów pasujących do matchers. Używaj podczas planowanych prac serwisowych. Najwygodniej przez `amtool`:

\# Wycisz wszystkie alerty z instance=web-01 na 2 godziny
amtool silence add \\
  --alertmanager.url=http://localhost:9093 \\
  --duration=2h \\
  --author="jan.kowalski" \\
  --comment="Planowana aktualizacja kernela" \\
  instance="web-01"

# Lista aktywnych silences
amtool silence query --alertmanager.url=http://localhost:9093

# Wygaś silence przez ID
amtool silence expire --alertmanager.url=http://localhost:9093 <silence-id>

## Inhibition rules

Inhibition automatycznie wycisza alerty "symptomów" gdy aktywny jest alert "przyczyny". Przykład: gdy serwer jest niedostępny, nie chcemy dostawać alertów o HTTP 5xx i wysokim czasie odpowiedzi z tego samego hosta:

inhibit\_rules:
  # InstanceDown wycisza wszystkie alerty z tego samego instance
  - source\_match:
      alertname: InstanceDown
    target\_match\_re:
      alertname: ".+"
    equal: \["instance"\]

  # Alert critical wycisza alerty warning z tego samego job
  - source\_match:
      severity: critical
    target\_match:
      severity: warning
    equal: \["alertname", "job"\]

## Alertmanager HA — klaster 3 węzłów

Uruchom trzy instancje Alertmanager (np. am1, am2, am3) — każda z flagami `--cluster.peer` wskazującymi na pozostałe:

\# am1 (10.0.0.1)
alertmanager \\
  --config.file=/etc/alertmanager/alertmanager.yml \\
  --storage.path=/var/lib/alertmanager \\
  --cluster.listen-address=0.0.0.0:9094 \\
  --cluster.peer=10.0.0.2:9094 \\
  --cluster.peer=10.0.0.3:9094 \\
  --web.listen-address=0.0.0.0:9093

# am2 (10.0.0.2) — analogicznie, peer do am1 i am3
# am3 (10.0.0.3) — analogicznie, peer do am1 i am2

W `prometheus.yml` wskaż WSZYSTKIE instancje — Prometheus wysyła alerty do każdej, a Alertmanager deduplikuje przez gossip:

alerting:
  alertmanagers:
    - static\_configs:
        - targets:
            - "10.0.0.1:9093"
            - "10.0.0.2:9093"
            - "10.0.0.3:9093"

## Integracja z Grafana OnCall

Grafana OnCall (dawniej Amixr) odbiera alerty z Alertmanagera przez webhook i zarządza harmonogramem dyżurów (on-call schedules), eskalacjami i integracją z Slack/Teams/telefon. Konfiguracja jest prosta — skopiuj Webhook URL z Grafana OnCall i dodaj jako receiver:

receivers:
  - name: grafana-oncall
    webhook\_configs:
      - url: "https://oncall.grafana.com/integrations/v1/alertmanager/TOKEN/"
        send\_resolved: true

## Najczęstsze pytania

Czym różni się alert rule w Prometheus od Alertmanagera? +

Prometheus ocenia reguły alertów (alert rules) i generuje zdarzenia FIRING/RESOLVED. Alertmanager odbiera te zdarzenia i decyduje: komu wysłać (routing), kiedy wysłać (grupowanie, throttling), jakim kanałem (receiver: Slack, email, PagerDuty). Prometheus "wykrywa" problem, Alertmanager "zarządza" powiadomieniem. Rozdzielenie jest celowe — jeden Alertmanager może obsługiwać wiele instancji Prometheus.

Jak działa grupowanie alertów w Alertmanagerze? +

group\_by w route grupuje alerty o tych samych labelach w jedno powiadomienie. Np. group\_by: \[alertname, job\] sprawi, że wszystkie alerty "InstanceDown" z job="api" trafią do jednej wiadomości zamiast osobnych. group\_wait (domyślnie 30s) to czas oczekiwania na dodatkowe alerty przed pierwszym wysyłką. group\_interval (5m) to minimalny czas między ponownymi powiadomieniami dla tej samej grupy.

Czym są inhibition rules i kiedy ich używać? +

Inhibition wycisza alerty "symptomów" gdy aktywny jest alert "przyczyny". Przykład: gdy alert NodeDown jest FIRING, wycisz wszystkie alerty z tym samym instance (bo np. HTTP 5xx na tym węźle to oczywisty skutek). Inhibition definiuje się przez source\_match (co wycisza) i target\_match (co jest wyciszane) — obie muszą mieć wspólny label (equal). Pozwala zmniejszyć szum i skupić się na root cause.

Jak skonfigurować Alertmanager w trybie HA (klastrowanie)? +

Uruchom minimum 3 instancje Alertmanager z flagą --cluster.peer wskazującą na pozostałe. Instancje automatycznie synchronizują stan (silences, notifications) przez gossip protocol (mesh). Prometheus wysyła alerty do KAŻDEJ instancji (lista w alerting.alertmanagers). Alertmanager deduplikuje powiadomienia przez cluster — każdy alert jest wysyłany dokładnie raz. Używaj portu 9094 (domyślny cluster port).

Jak przetestować konfigurację alertmanager.yml przed restartem? +

Użyj amtool check-config alertmanager.yml — waliduje składnię bez restartu. Do testowania routingu: amtool config routes test --config.file=alertmanager.yml --verify.receivers=team-ops alertname=InstanceDown severity=critical. Możesz też wysłać testowy alert przez API: curl -XPOST http://localhost:9093/api/v2/alerts z JSON payload.

## Sprawdź oferty pasujące do tego scenariusza

Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.

Contabo

VPS z dużym RAM — idealny dla pełnego stacku Prometheus + Alertmanager + Grafana

VPS Monitoring

[Aktywuj rabat →](/out/contabo)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/contabo)

Mikrus

Tani VPS do testowania alertingu w środowisku deweloperskim

Dev VPS

[Aktywuj rabat →](/out/mikrus)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/mikrus)

home.pl

Serwery VPS z SLA — idealne do monitorowania infrastruktury produkcyjnej

Produkcja

[Aktywuj rabat →](/out/home-pl)

#Reklama · link partnerski

[Zobacz kod rabatowy →](/kody-rabatowe/home-pl)

## Powiązane strony

-   [Prometheus + Grafana — monitoring VPS](/baza-wiedzy/monitoring-grafana-prometheus)
-   [Grafana Unified Alerting — reguły i contact points](/baza-wiedzy/grafana-alerting-unified)
-   [Thanos — długoterminowe przechowywanie metryk](/baza-wiedzy/thanos-prometheus-long-term)
-   [Wszystkie artykuły](/baza-wiedzy/)