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:

# /etc/alertmanager/alertmanager.yml

global:
  resolve_timeout: 5m
  smtp_smarthost: "smtp.example.com:587"
  smtp_from: "[email protected]"
  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: "[email protected]"
        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