Przejdź do głównej zawartości

Integracje webhook

Integracje webhook pozwalają otrzymywać alerty z zewnętrznych narzędzi monitoringu bezpośrednio do Notifer. Zamiast ręcznie publikować alerty przez HTTP, Twój stos monitoringu wysyła zdarzenia na URL webhook Notifer, a Notifer automatycznie tworzy, aktualizuje i rozwiązuje alerty na podstawie przychodzących danych.

Jak to działa​

Przepływ integracji jest prosty:

Monitoring Tool           Notifer                      Your Team
     |                      |                              |
     |--- HTTP POST ------->|                              |
     |  (webhook payload)   |                              |
     |                      |-- Parse payload              |
     |                      |-- Extract alert_key          |
     |                      |-- Determine status           |
     |                      |-- Create/update alert        |
     |                      |                              |
     |                      |-- Push notification -------->|
     |                      |-- SSE/WebSocket update ----->|
     |                      |-- Dashboard updated -------->|

Każde narzędzie monitoringu wysyła webhooki w swoim własnym formacie. Notifer zawiera wbudowane parsery dla popularnych narzędzi, które automatycznie wyodrębniają klucz alertu, status, poziom ważności, etykiety i opis z przychodzących danych. Dla nieobsługiwanych narzędzi, generyczna integracja webhook pozwala skonfigurować własne mapowania pól.

Obsługiwane integracje​

IntegracjaFormat danychAutomatyczne rozwiązywanieMapowanie ważności
AlertmanagerPrometheus Alertmanager JSONTak (przez status resolved)critical->P1, warning->P2, info->P4
GrafanaGrafana Alerting JSONTak (przez stan ok/resolved)Mapowane z etykiet ważności Grafana
DatadogDatadog Webhook JSONTak (przez przejście Recovered)critical->P1, error->P2, warning->P3, info->P4
ZabbixZabbix Webhook JSONTak (przez status RESOLVED)disaster->P1, high->P2, average->P3, warning->P4, info->P5
Uptime KumaUptime Kuma JSONTak (przez status up)down->P1, degraded->P2
DynatraceDynatrace Problem JSONTak (przez stan RESOLVED)CRITICAL->P1, ERROR->P2, WARNING->P3
GenerycznyWłasny JSONKonfigurowalneKonfigurowalne mapowanie pól

Konfiguracja integracji​

Krok 1: Włącz tryb alertow​

Najpierw upewnij się, że tryb alertow jest włączony na docelowym temacie. Zobacz Rozpoczęcie pracy z alertami, aby uzyskać instrukcje.

Krok 2: Dodaj integrację​

  1. Zaloguj się na app.notifer.io
  2. Przejdź do tematu z włączonym trybem alertow
  3. Kliknij Ustawienia (ikona koła zębatego)
  4. Przewiń do sekcji Tryb alertow
  5. Kliknij Dodaj integrację
  6. Wybierz swoje narzędzie monitoringu z listy
  7. Skopiuj wygenerowany URL webhook

URL webhook ma następujący format:

https://app.notifer.io/api/topics/{topic}/webhooks/ingest/{type}/{token}

Gdzie:

  • {topic} -- Nazwa Twojego tematu
  • {type} -- Typ integracji (np. alertmanager, grafana, datadog, zabbix, uptime-kuma, dynatrace, generic)
  • {token} -- Unikalny token bezpieczeństwa wygenerowany dla tej integracji
Jeden URL na integrację

Każda integracja otrzymuje własny unikalny URL z odrębnym tokenem. Możesz dodać wiele integracji do tego samego tematu (np. Alertmanager + Uptime Kuma) i każda będzie miała własny URL.

Krok 3: Skonfiguruj narzędzie monitoringu​

Postępuj zgodnie z instrukcjami dla konkretnego narzędzia poniżej, aby skierować swoje narzędzie monitoringu na URL webhook.

Alertmanager​

Prometheus Alertmanager jest najpopularniejszym komponentem alertowania w ekosystemie Prometheus. Notifer natywnie parsuje dane webhook Alertmanagera, mapując nazwy alertów i etykiety na klucze alertów.

Konfiguracja​

Dodaj Notifer jako odbiornik webhook w pliku alertmanager.yml:

receivers:
  - name: 'notifer'
    webhook_configs:
      - url: 'https://app.notifer.io/api/topics/{topic}/webhooks/ingest/alertmanager/{token}'
        send_resolved: true

Następnie przekieruj alerty do odbiornika Notifer:

route:
  receiver: 'default'
  routes:
    # Send all critical alerts to Notifer
    - match:
        severity: critical
      receiver: 'notifer'
      continue: true

    # Send all warning alerts to Notifer
    - match:
        severity: warning
      receiver: 'notifer'
      continue: true

    # Or send everything to Notifer
    - receiver: 'notifer'
      continue: true

Jak Notifer mapuje dane Alertmanagera​

Pole AlertmanageraPole NotiferPrzykład
alerts[].labels.alertname + kluczowe etykietyalert_keyHighCPU-prod-web-01
alerts[].annotations.description lub summaryTreść wiadomości"CPU usage above 90%"
alerts[].labels.severityPriorytetcritical -> P1
alerts[].statusStatus alertufiring -> open, resolved -> resolved
alerts[].labelsTagiWszystkie pary klucz-wartość etykiet

Pełny przykład: Prometheus + Alertmanager + Notifer​

Reguła alertowania Prometheus:

# prometheus/alert_rules.yml
groups:
  - name: infrastructure
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 5m
        labels:
          severity: critical
          team: infrastructure
        annotations:
          summary: "High CPU usage on {{ $labels.instance }}"
          description: "CPU usage is {{ $value | printf \"%.1f\" }}% on {{ $labels.instance }}"

      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 15
        for: 10m
        labels:
          severity: warning
          team: infrastructure
        annotations:
          summary: "Low disk space on {{ $labels.instance }}"
          description: "Disk space is {{ $value | printf \"%.1f\" }}% free on {{ $labels.instance }}:{{ $labels.mountpoint }}"

Konfiguracja Alertmanagera:

# alertmanager.yml
global:
  resolve_timeout: 5m

route:
  receiver: 'default'
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - receiver: 'notifer-infra'
      match:
        team: infrastructure

receivers:
  - name: 'default'
    webhook_configs: []

  - name: 'notifer-infra'
    webhook_configs:
      - url: 'https://app.notifer.io/api/topics/infra-alerts/webhooks/ingest/alertmanager/wh_abc123def456'
        send_resolved: true

Gdy alert HighCPUUsage się uruchomi, Notifer tworzy alert z:

  • Klucz alertu: HighCPUUsage-prod-web-01:9100 (alertname + instance)
  • Wiadomość: "CPU usage is 94.2% on prod-web-01:9100"
  • Priorytet: P1 (zmapowany z severity: critical)
  • Tagi: severity:critical, team:infrastructure, instance:prod-web-01:9100

Gdy Alertmanager wyśle powiadomienie o rozwiązaniu, alert jest automatycznie rozwiązywany w Notifer.

send_resolved jest ważne

Zawsze ustawiaj send_resolved: true w konfiguracji webhook Alertmanagera. Pozwala to Notifer automatycznie rozwiązywać alerty, gdy warunek się normalizuje, utrzymując pulpit w aktualnym stanie bez ręcznego porządkowania.

Grafana​

Grafana Alerting może wysyłać powiadomienia webhook, gdy reguły alertów się uruchomią. Notifer parsuje dane alertów Grafana i mapuje je na alerty.

Konfiguracja​

  1. W Grafanie przejdź do Alerting -> Contact points
  2. Kliknij Add contact point
  3. Ustaw nazwę (np. "Notifer")
  4. Wybierz Webhook jako typ integracji
  5. Wklej URL webhook Notifer: 
    https://app.notifer.io/api/topics/{topic}/webhooks/ingest/grafana/{token}
  6. Ustaw metodę HTTP na POST
  7. Pozostaw pozostałe ustawienia domyślne
  8. Kliknij Save contact point
  9. Przejdź do Notification policies i dodaj trasę, która używa punktu kontaktowego Notifer

Jak Notifer mapuje dane Grafana​

Pole GrafanaPole NotiferPrzykład
alerts[].labels.alertnamealert_keyHighMemoryUsage
alerts[].annotations.descriptionTreść wiadomości"Memory at 95%"
alerts[].labels.severity lub priorytet regułyPriorytetMapowane z etykiet
statusStatus alertufiring -> open, resolved -> resolved
alerts[].labelsTagiWszystkie etykiety jako tagi

Przykład reguły alertowania Grafana​

Podczas tworzenia reguł alertów w Grafanie dodaj etykietę severity, aby kontrolować mapowanie priorytetu w Notifer:

Labels:
  severity = critical
  service = api-gateway

Annotations:
  summary = API Gateway error rate above threshold
  description = Error rate is {{ $values.error_rate }}% (threshold: 5%)

Datadog​

Datadog obsługuje niestandardowe integracje webhook, które mogą przekazywać alerty monitorów do zewnętrznych usług.

Konfiguracja​

  1. W Datadog przejdź do Integrations -> Integrations tab
  2. Wyszukaj Webhooks i kliknij Configure
  3. Kliknij New Webhook
  4. Wypełnij szczegóły:
    • Name: notifer
    • URL: https://app.notifer.io/api/topics/{topic}/webhooks/ingest/datadog/{token}
    • Payload: Pozostaw domyślne (Datadog wysyła swój standardowy JSON)
    • Custom Headers: Nie wymagane
  5. Kliknij Save

Następnie dodaj @webhook-notifer do wiadomości powiadomień monitora, aby kierować alerty do Notifer:

{{#is_alert}}
Server {{host.name}} CPU is critically high: {{value}}%
@webhook-notifer
{{/is_alert}}

{{#is_recovery}}
Server {{host.name}} CPU has recovered: {{value}}%
@webhook-notifer
{{/is_recovery}}

Jak Notifer mapuje dane Datadog​

Pole DatadogPole NotiferPrzykład
alert_id + hostnamealert_key12345678-web-01
bodyTreść wiadomości"CPU is critically high: 95%"
alert_transitionStatus alertuTriggered -> open, Recovered -> resolved
priorityPriorytetcritical -> P1, error -> P2, warning -> P3
tagsTagiTagi Datadog mapowane bezpośrednio

Zabbix​

Zabbix obsługuje typy mediów webhook do wysyłania powiadomień do systemów zewnętrznych.

Konfiguracja​

  1. W Zabbix przejdź do Administration -> Media types
  2. Kliknij Create media type
  3. Wypełnij szczegóły:
    • Name: Notifer
    • Type: Webhook
    • Parameters: Dodaj następujące:
      • url: https://app.notifer.io/api/topics/{topic}/webhooks/ingest/zabbix/{token}
      • subject: {ALERT.SUBJECT}
      • message: {ALERT.MESSAGE}
      • event_id: {EVENT.ID}
      • host: {HOST.NAME}
      • severity: {EVENT.SEVERITY}
      • status: {EVENT.STATUS}
      • trigger_name: {TRIGGER.NAME}
  4. W polu Script dodaj skrypt webhook wysyłający żądanie HTTP POST na URL:
var params = JSON.parse(value);
var req = new HttpRequest();
req.addHeader('Content-Type: application/json');
var payload = JSON.stringify({
    event_id: params.event_id,
    host: params.host,
    severity: params.severity,
    status: params.status,
    trigger_name: params.trigger_name,
    subject: params.subject,
    message: params.message
});
var resp = req.post(params.url, payload);
return resp;
  1. Kliknij Add, aby zapisać
  2. Przypisz typ mediów Notifer do użytkowników lub akcji, które mają przekazywać alerty

Jak Notifer mapuje dane Zabbix​

Pole ZabbixPole NotiferPrzykład
trigger_name + hostalert_keyHigh-CPU-load-web-server-01
messageTreść wiadomości"CPU load is 12.5 on web-server-01"
severityPriorytetDisaster -> P1, High -> P2, Average -> P3
statusStatus alertuPROBLEM -> open, RESOLVED -> resolved

Uptime Kuma​

Uptime Kuma to samoobsługowe narzędzie monitoringu, które może wysyłać powiadomienia webhook, gdy monitory wykryją przejście w stan up lub down.

Konfiguracja​

  1. W Uptime Kuma przejdź do Settings -> Notifications
  2. Kliknij Setup Notification
  3. Wybierz Webhook jako typ powiadomienia
  4. Wypełnij szczegóły:
    • Friendly Name: Notifer
    • Post URL: https://app.notifer.io/api/topics/{topic}/webhooks/ingest/uptime-kuma/{token}
    • Request Body: Domyślne (JSON)
  5. Kliknij Save
  6. Zastosuj powiadomienie do swoich monitorów

Alternatywnie możesz skonfigurować powiadomienia per monitor:

  1. Edytuj monitor
  2. Przewiń do Notifications
  3. Wybierz powiadomienie webhook Notifer
  4. Zapisz

Jak Notifer mapuje dane Uptime Kuma​

Pole Uptime KumaPole NotiferPrzykład
monitor.namealert_keyapi-health-check
msgTreść wiadomości"api-health-check is DOWN"
heartbeat.statusStatus alertu0 (down) -> open, 1 (up) -> resolved
Status downPriorytetDown -> P1, Degraded -> P2
monitor.tagsTagiTagi monitora mapowane bezpośrednio

Dynatrace​

Dynatrace może wysyłać powiadomienia o problemach do endpointów webhook.

Konfiguracja​

  1. W Dynatrace przejdź do Settings -> Integration -> Problem notifications
  2. Kliknij Set up notifications -> Custom integration
  3. Wypełnij szczegóły:
    • Display name: Notifer
    • Webhook URL: https://app.notifer.io/api/topics/{topic}/webhooks/ingest/dynatrace/{token}
    • Accept any SSL certificate: Wyłączone (zalecane)
  4. Dostosuj dane lub pozostaw domyślne
  5. Kliknij Save

Jak Notifer mapuje dane Dynatrace​

Pole DynatracePole NotiferPrzykład
ProblemID + ProblemTitlealert_keyP-12345-CPU-saturation
ProblemDetailsTextTreść wiadomości"CPU saturation detected on host-01"
StateStatus alertuOPEN -> open, RESOLVED -> resolved
ProblemSeverityPriorytetCRITICAL -> P1, ERROR -> P2, WARNING -> P3
TagsTagiTagi encji Dynatrace

Generyczny webhook​

Dla narzędzi monitoringu nie wymienionych powyżej lub dla niestandardowych integracji, użyj generycznego typu webhook. Generyczna integracja akceptuje dowolne dane JSON i pozwala skonfigurować sposób mapowania pól na właściwości alertów Notifer.

Konfiguracja​

Podczas dodawania generycznej integracji możesz skonfigurować mapowania pól w ustawieniach tematu:

  1. Kliknij Dodaj integrację -> Generyczny
  2. Skopiuj URL webhook
  3. Kliknij Konfiguruj mapowania, aby ustawić wyodrębnianie pól

Domyślne zachowanie​

Domyślnie generyczny webhook oczekuje treści JSON z następującymi polami:

{
  "alert_key": "my-alert-identifier",
  "message": "Description of the alert",
  "status": "open",
  "priority": 2,
  "tags": ["tag1", "tag2"],
  "source": "my-monitoring-tool",
  "title": "Optional alert title"
}

Niestandardowe mapowania pól​

Jeśli Twoje narzędzie wysyła inną strukturę JSON, skonfiguruj niestandardowe ścieżki pól używając notacji kropkowej:

Pole NotiferDomyślna ścieżkaPrzykład niestandardowy
Klucz alertualert_keydata.check.id
Wiadomośćmessagedata.event.description
Statusstatusdata.event.state
Priorytetprioritydata.severity_level
Tagitagsdata.labels
Źródłosourcedata.monitor_name

Na przykład, jeśli Twoje narzędzie wysyła:

{
  "data": {
    "check": {
      "id": "http-check-api",
      "name": "API Health Check"
    },
    "event": {
      "state": "critical",
      "description": "API endpoint returned 503"
    },
    "labels": ["api", "production"]
  }
}

Skonfigurujesz mapowania jako:

  • Ścieżka klucza alertu: data.check.id
  • Ścieżka wiadomości: data.event.description
  • Ścieżka statusu: data.event.state
  • Ścieżka tagów: data.labels

Mapowanie wartości statusów​

Dla generycznej integracji skonfiguruj, które wartości w danych odpowiadają stanom open i resolved:

StatusDomyślne wartościPrzykład niestandardowy
Otwartyopen, firing, triggered, problem, critical, error, warningalert, down, fail
Rozwiązanyresolved, ok, recovery, recovered, upclear, normal, pass

Wysyłanie generycznego webhook​

curl -X POST \
  "https://app.notifer.io/api/topics/my-alerts/webhooks/ingest/generic/wh_abc123" \
  -H "Content-Type: application/json" \
  -d '{
    "alert_key": "custom-check-001",
    "message": "Custom monitoring check failed: connection timeout",
    "status": "open",
    "priority": 2,
    "tags": ["custom", "network"],
    "source": "custom-monitor",
    "title": "Connection Timeout"
  }'
X-Alert-Key jako rozwiązanie awaryjne

Jeśli dane nie zawierają pola alert_key (lub skonfigurowana ścieżka pola nie jest rozpoznawana), możesz dołączyć nagłówek HTTP X-Alert-Key jako rozwiązanie awaryjne. Nagłówek ma pierwszeństwo przed polem w treści żądania.

Format URL webhook​

Wszystkie URL-e webhook podążają za tym wzorcem:

https://app.notifer.io/api/topics/{topic}/webhooks/ingest/{type}/{token}
SegmentOpisPrzykład
{topic}Nazwa tematu, w którym będą tworzone alertyinfra-alerts
{type}Identyfikator typu integracjialertmanager, grafana, datadog, zabbix, uptime-kuma, dynatrace, generic
{token}Unikalny token bezpieczeństwa (generowany automatycznie)wh_a1b2c3d4e5f6g7h8

Token uwierzytelnia żądanie webhook. Każdy POST na ten URL z prawidłowym tokenem jest akceptowany bez dodatkowego uwierzytelniania. Jest to standard dla integracji webhook, gdzie narzędzie monitoringu nie może wysyłać niestandardowych nagłówków uwierzytelniania.

Tylko HTTPS

URL-e webhook obsługują wyłącznie HTTPS. Żądania HTTP są odrzucane. Zapewnia to, że token webhook nigdy nie jest przesyłany jawnym tekstem.

Rotacja tokenów​

Ze względów bezpieczeństwa powinieneś okresowo rotować tokeny webhook, szczególnie jeśli podejrzewasz, że token został skompromitowany.

Rotacja tokena​

  1. Przejdź do Ustawienia tematu -> Tryb alertow -> Integracje
  2. Znajdź integrację, którą chcesz zrotować
  3. Kliknij przycisk Rotuj token (ikona odświeżania)
  4. Nowy token jest generowany natychmiast
  5. Skopiuj nowy URL webhook -- stary token przestaje działać natychmiast
  6. Zaktualizuj URL w konfiguracji narzędzia monitoringu
Rotacja bez przestoju nie jest obsługiwana

Podczas rotacji tokena stary token jest natychmiast unieważniany. Zaplanuj krótkie okno serwisowe lub zaakceptuj, że alerty z narzędzia monitoringu będą nieudane do czasu aktualizacji URL-a. W większości konfiguracji trwa to mniej niż minutę.

Kiedy rotować​

  • Regularnie: Co 90 dni jako najlepsza praktyka
  • Po zmianach w zespole: Gdy ktoś z dostępem do tokena odchodzi z zespołu
  • Po incydencie bezpieczeństwa: Jeśli podejrzewasz nieautoryzowany dostęp
  • Po przypadkowym ujawnieniu: Jeśli URL został zacommitowany do publicznego repozytorium lub udostępniony w niezabezpieczonym kanale

Monitorowanie zdarzeń webhook​

Notifer śledzi aktywność webhook dla każdej integracji, abyś mógł zweryfikować, że zdarzenia są odbierane i przetwarzane prawidłowo.

Statystyki webhook​

Przeglądaj statystyki webhook w Ustawienia -> Tryb alertow -> Integracje -> kliknij integrację:

MetrykaOpis
Łącznie otrzymaneCałkowita liczba otrzymanych żądań webhook
ZaakceptowaneŻądania, które zostały pomyślnie sparsowane i utworzyły/zaktualizowały alerty
OdrzuconeŻądania, które zostały odrzucone (nieprawidłowe dane, błędy parsowania)
Ostatnio otrzymaneZnacznik czasu ostatniego żądania webhook
Ostatni błądSzczegóły ostatniego błędu przetwarzania (jeśli wystąpił)

Dziennik zdarzeń webhook​

Każda integracja prowadzi dziennik ostatnich zdarzeń webhook (ostatnie 100 zdarzeń). Jest to przydatne do debugowania problemów z integracją:

  1. Przejdź do Ustawienia -> Tryb alertow -> Integracje
  2. Kliknij nazwę integracji
  3. Przewiń do Ostatnie zdarzenia
  4. Każdy wpis pokazuje: znacznik czasu, status (zaakceptowane/odrzucone), wyodrębniony klucz alertu oraz szczegóły błędów

Rozwiązywanie problemów​

Webhooki nie są odbierane​

Sprawdź URL webhook:

  • Zweryfikuj, że URL jest prawidłowy -- skopiuj go ponownie z pulpitu Notifer
  • Upewnij się, że nazwa tematu w URL-u odpowiada Twojemu faktycznemu tematowi
  • Potwierdź, że typ integracji jest prawidłowy (np. alertmanager, a nie grafana)

Sprawdź narzędzie monitoringu:

  • Poszukaj logów błędów w narzędziu monitoringu wskazujących na nieudane żądania HTTP
  • Zweryfikuj, że narzędzie może się połączyć z app.notifer.io na porcie 443 (HTTPS)
  • Sprawdź, czy zapora sieciowa lub proxy nie blokuje żądań wychodzących

Przetestuj webhook ręcznie:

# Test with a simple curl (use your actual URL)
curl -v -X POST \
  "https://app.notifer.io/api/topics/my-alerts/webhooks/ingest/generic/wh_your_token" \
  -H "Content-Type: application/json" \
  -d '{"alert_key": "test", "message": "Webhook test", "status": "open"}'

Jeśli otrzymasz 200 OK, URL webhook działa. Jeśli otrzymasz 401 lub 403, token może być nieprawidłowy.

Webhooki odbierane, ale alerty nie tworzone​

Sprawdź dziennik zdarzeń:

  • Przejdź do dziennika zdarzeń integracji i poszukaj wpisów "odrzucone"
  • Częste przyczyny: nieprawidłowy JSON, brakujące wymagane pola, nieparsowalny format danych

Zweryfikuj, że tryb alertow jest włączony:

  • Integracje webhook wymagają aktywnego trybu alertow na temacie
  • Przejdź do ustawień tematu i potwierdź, że przełącznik trybu alertow jest włączony

Sprawdź mapowania pól (generyczna integracja):

  • Jeśli używasz typu generycznego, zweryfikuj poprawność mapowań ścieżek pól
  • Użyj dziennika zdarzeń, aby zobaczyć, jakie pola Notifer wyodrębnił z danych

Alerty tworzone, ale brak powiadomień​

Sprawdź deduplikację:

  • Jeśli ten sam klucz alertu był już otwarty, nowe wystąpienia są deduplikowane (brak nowego powiadomienia)
  • Jest to oczekiwane zachowanie -- sprawdź licznik wystąpień na pulpicie

Sprawdź ustawienia powiadomień:

  • Zweryfikuj swoje ustawienia powiadomień mobilnych (próg priorytetu, filtr tagów)
  • Alert zmapowany do P3 nie wyzwoli powiadomienia push, jeśli Twój próg jest ustawiony na P2

Sprawdź subskrypcję:

  • Upewnij się, że jesteś subskrybentem tematu w aplikacji webowej lub mobilnej

Nieprawidłowe mapowanie priorytetu lub statusu​

Sprawdź typ integracji:

  • Upewnij się, że używasz prawidłowego typu integracji w URL-u
  • Użycie generic dla danych Alertmanagera (lub odwrotnie) spowoduje nieprawidłowe mapowanie pól

Sprawdź etykiety ważności:

  • Dla Alertmanagera i Grafana mapowanie priorytetu zależy od etykiety severity
  • Upewnij się, że Twoje reguły alertowania zawierają etykietę severity z wartościami takimi jak critical, warning lub info

Przykład z życia: konfiguracja wielu narzędzi​

Typowa konfiguracja produkcyjna wykorzystuje wiele narzędzi monitoringu zasilających jeden temat Notifer:

Prometheus/Alertmanager ──┐
                          │
Grafana Alerting ─────────┼──> infra-alerts topic ──> Team notifications
                          │
Uptime Kuma ──────────────┤
                          │
Custom health checks ─────┘

Każde narzędzie otrzymuje własną integrację i URL webhook:

NarzędzieTyp integracjiURL webhook
Alertmanageralertmanagerhttps://app.notifer.io/api/topics/infra-alerts/webhooks/ingest/alertmanager/wh_token1
Grafanagrafanahttps://app.notifer.io/api/topics/infra-alerts/webhooks/ingest/grafana/wh_token2
Uptime Kumauptime-kumahttps://app.notifer.io/api/topics/infra-alerts/webhooks/ingest/uptime-kuma/wh_token3
Własne skryptygenerichttps://app.notifer.io/api/topics/infra-alerts/webhooks/ingest/generic/wh_token4

Wszystkie alerty pojawiają się na ujednoliconym pulpicie niezależnie od źródła. Pole X-Alert-Source (automatycznie wypełniane na podstawie typu integracji) pozwala filtrować według pochodzenia, gdy jest to potrzebne.

Osobne tematy dla osobnych zespołów

Jeśli różne zespoły obsługują różne typy alertów, używaj osobnych tematów z własnymi integracjami. Na przykład: infra-alerts dla zespołu platformy, app-alerts dla programistów aplikacji i security-alerts dla zespołu bezpieczeństwa. Każdy zespół konfiguruje własne preferencje powiadomień.

Następne kroki​