Reguły filtrowania

Reguły filtrowania pozwalają przetwarzać i filtrować przychodzące zdarzenia webhook przed utworzeniem alertów. Zamiast otrzymywać każde pojedyncze zdarzenie z narzędzi monitorujących, definiujesz reguły, które decydują, które zdarzenia stają się alertami, które zostają odrzucone, a które są modyfikowane po drodze.

Dlaczego warto używać reguł filtrowania?

Narzędzia monitorujące generują dużo szumu. Typowa konfiguracja Prometheus + Alertmanager może generować setki zdarzeń na godzinę, a nie wszystkie zasługują na Twoją uwagę. Reguły filtrowania rozwiązują ten problem, dając Ci szczegółową kontrolę nad tym, co trafia do Twojego kanału alertów:

• Odrzucaj szumowe alerty -- Odrzucaj zdarzenia o niskiej ważności lub informacyjne, które zaśmiecają Twój dashboard
• Modyfikuj priorytet -- Automatycznie eskaluj krytyczne alerty do P1, aby natychmiast wywoływały powiadomienia push
• Dodawaj tagi -- Wzbogacaj alerty o tagi środowiska, zespołu lub usługi dla lepszej organizacji
• Kieruj zdarzenia -- Akceptuj tylko te zdarzenia, które mają znaczenie dla konkretnego tematu

Zacznij prosto

Nie potrzebujesz reguł filtrowania, aby rozpocząć pracę z webhookami. Domyślnie wszystkie przychodzące zdarzenia są akceptowane i konwertowane na alerty. Dodawaj reguły dopiero wtedy, gdy musisz zredukować szum lub dostosować zachowanie.

Kolejność ewaluacji reguł

Reguły są przetwarzane od góry do dołu w kolejności, w jakiej je zdefiniujesz. Wygrywa pierwsze dopasowanie -- gdy zdarzenie pasuje do reguły, stosowana jest akcja tej reguły i żadne kolejne reguły nie są ewaluowane.

Jeśli żadna reguła nie pasuje, zdarzenie jest domyślnie akceptowane (tworzony jest alert z oryginalnym payloadem).

Przychodzące zdarzenie
    |
    v
[ Reguła 1 ] -- pasuje? --> Zastosuj akcję (stop)
    |
    nie
    v
[ Reguła 2 ] -- pasuje? --> Zastosuj akcję (stop)
    |
    nie
    v
[ Reguła 3 ] -- pasuje? --> Zastosuj akcję (stop)
    |
    nie
    v
[ Domyślnie: Akceptuj ] --> Utwórz alert bez zmian

Wygrywa pierwsze dopasowanie

To ważne do zrozumienia. Jeśli masz szeroką regułę "odrzuć wszystkie info" powyżej konkretnej reguły "akceptuj info z produkcji", zdarzenia info z produkcji zostaną odrzucone zanim dotrą do drugiej reguły. Kolejność ma znaczenie.

Tworzenie reguł

Reguły filtrowania konfiguruje się per integracja webhook za pośrednictwem aplikacji webowej:

1. Przejdź do swojego tematu w dashboardzie
2. Otwórz Ustawienia > Integracje webhook
3. Kliknij na integrację webhook, którą chcesz skonfigurować
4. Przewiń do sekcji Reguły filtrowania
5. Kliknij Dodaj regułę

Możesz również zarządzać regułami programistycznie za pomocą Alert API.

Anatomia reguły

Każda reguła filtrowania składa się z nazwy, jednego lub więcej warunków i akcji.

Nazwa

Opisowy identyfikator reguły. Wybierz coś, co na pierwszy rzut oka wyjaśnia cel reguły.

Dobre przykłady:

• "Odrzuć alerty poziomu info"
• "Eskaluj krytyczne do P1"
• "Oznacz zdarzenia produkcyjne"
• "Odrzuć alerty testowe/syntetyczne"

Warunki

Warunki definiują kiedy reguła pasuje do przychodzącego zdarzenia. Każdy warunek ewaluuje pole w payloadzie webhooka.

Ścieżka pola

Ścieżka pola określa, którą część przychodzącego payloadu JSON ewaluować. Notacja kropkowa jest obsługiwana dla zagnieżdżonych pól.

Ścieżka pola	Co dopasowuje
severity	Pole severity najwyższego poziomu
labels.severity	Zagnieżdżone severity wewnątrz obiektu labels
labels.env	Etykieta środowiska
alertname	Nazwa alertu (powszechna w payloadach Alertmanagera)
status	Status alertu (firing, resolved)
labels.team	Etykieta zespołu
annotations.summary	Adnotacja podsumowania alertu

Struktura payloadu jest różna

Dostępne ścieżki pól zależą od typu webhooka. Payload Alertmanagera ma inne pola niż payload Grafany czy Datadoga. Użyj funkcji Testuj reguły, aby sprawdzić faktyczną strukturę Twojego payloadu.

Operatory

Operator	Opis	Przykład
equals	Dokładne dopasowanie (z uwzględnieniem wielkości liter)	severity equals critical
not_equals	Nie pasuje	status not_equals resolved
contains	Pole zawiera podciąg	alertname contains cpu
not_contains	Pole nie zawiera podciągu	alertname not_contains test
regex	Dopasowanie wyrażeniem regularnym	alertname regex ^disk.*full$
exists	Pole jest obecne w payloadzie	labels.env exists
not_exists	Pole nie jest obecne w payloadzie	labels.team not_exists

Wiele warunków (logika AND)

Gdy reguła ma wiele warunków, wszystkie warunki muszą pasować, aby reguła zadziałała. To jest logika AND.

{
  "conditions": [
    { "field": "severity", "operator": "equals", "value": "critical" },
    { "field": "labels.env", "operator": "equals", "value": "production" }
  ]
}

Ta reguła pasuje tylko do zdarzeń, gdzie severity to "critical" I środowisko to "production".

Logika OR

Jeśli potrzebujesz logiki OR (dopasowanie, jeśli dowolny warunek jest spełniony), utwórz osobne reguły dla każdego warunku. Ponieważ reguły są ewaluowane niezależnie w kolejności, wiele reguł efektywnie daje zachowanie OR.

Akcje

Akcja określa, co się dzieje, gdy wszystkie warunki pasują.

Akcja	Zachowanie
accept	Utwórz alert ze zdarzenia (bez modyfikacji)
drop	Odrzuć zdarzenie po cichu -- alert nie zostanie utworzony
modify	Zmień priorytet i/lub tagi alertu, a następnie go zaakceptuj

Modyfikacje (tylko akcja Modify)

Gdy akcja to modify, możesz zastosować jedną lub obie te zmiany przed utworzeniem alertu:

• Ustaw priorytet -- Nadpisz priorytet alertu (1-5). Na przykład wymuś P1 dla wszystkich pasujących zdarzeń.
• Dodaj tagi -- Dołącz dodatkowe tagi do alertu. Istniejące tagi z payloadu są zachowane.

{
  "action": "modify",
  "modifications": {
    "priority": 1,
    "add_tags": ["production", "escalated"]
  }
}

Przykłady

1. Odrzucanie alertów o niskiej ważności

Odrzucanie alertów informacyjnych, które nie wymagają uwagi.

Konfiguracja reguły:

Pole	Wartość
Nazwa	Odrzuć alerty poziomu info
Warunek	severity equals info
Akcja	drop

{
  "name": "Drop info-level alerts",
  "conditions": [
    { "field": "severity", "operator": "equals", "value": "info" }
  ],
  "action": "drop"
}

Rezultat: Każde zdarzenie webhook z "severity": "info" jest po cichu odrzucane.

2. Eskalacja alertów krytycznych do P1

Zapewnienie, że alerty krytyczne zawsze otrzymują najwyższy priorytet, wywołując natychmiastowe powiadomienia push.

Konfiguracja reguły:

Pole	Wartość
Nazwa	Eskaluj krytyczne do P1
Warunek	severity equals critical
Akcja	modify
Ustaw priorytet	1

{
  "name": "Escalate critical to P1",
  "conditions": [
    { "field": "severity", "operator": "equals", "value": "critical" }
  ],
  "action": "modify",
  "modifications": {
    "priority": 1
  }
}

Rezultat: Zdarzenia krytyczne stają się alertami P1, które są wysyłane na urządzenia mobilne z pilnym dźwiękiem powiadomienia.

3. Dodawanie tagów środowiska

Automatyczne tagowanie alertów z produkcji tagiem production dla łatwego filtrowania.

Konfiguracja reguły:

Pole	Wartość
Nazwa	Oznacz alerty produkcyjne
Warunek	labels.env equals production
Akcja	modify
Dodaj tagi	production

{
  "name": "Tag production alerts",
  "conditions": [
    { "field": "labels.env", "operator": "equals", "value": "production" }
  ],
  "action": "modify",
  "modifications": {
    "add_tags": ["production"]
  }
}

Rezultat: Alerty produkcyjne otrzymują dołączony tag production, co ułatwia ich filtrowanie w dashboardzie i aplikacji mobilnej.

4. Odrzucanie alertów testowych i syntetycznych

Zapobieganie tworzeniu szumu w kanale alertów przez alerty testowe lub z monitoringu syntetycznego.

Konfiguracja reguły:

Pole	Wartość
Nazwa	Odrzuć alerty testowe
Warunek	alertname contains test
Akcja	drop

{
  "name": "Drop test alerts",
  "conditions": [
    { "field": "alertname", "operator": "contains", "value": "test" }
  ],
  "action": "drop"
}

Rezultat: Każde zdarzenie, którego alertname zawiera "test" (np. TestAlert, synthetic-test-ping), jest odrzucane.

5. Kombinacja: Eskalacja krytycznych z produkcji, odrzucanie info ze stagingu

Realistyczna konfiguracja z wieloma regułami dla współdzielonego tematu monitorowania:

Reguła 1 -- Odrzuć info ze stagingu:

{
  "name": "Drop staging info",
  "conditions": [
    { "field": "labels.env", "operator": "equals", "value": "staging" },
    { "field": "severity", "operator": "equals", "value": "info" }
  ],
  "action": "drop"
}

Reguła 2 -- Eskaluj krytyczne z produkcji:

{
  "name": "Escalate production critical",
  "conditions": [
    { "field": "labels.env", "operator": "equals", "value": "production" },
    { "field": "severity", "operator": "equals", "value": "critical" }
  ],
  "action": "modify",
  "modifications": {
    "priority": 1,
    "add_tags": ["production", "critical"]
  }
}

Reguła 3 -- Oznacz wszystkie zdarzenia produkcyjne:

{
  "name": "Tag production",
  "conditions": [
    { "field": "labels.env", "operator": "equals", "value": "production" }
  ],
  "action": "modify",
  "modifications": {
    "add_tags": ["production"]
  }
}

Dzięki tym trzem regułom w tej kolejności, info ze stagingu jest najpierw odrzucane, następnie krytyczne zdarzenia produkcyjne są eskalowane, a pozostałe zdarzenia produkcyjne otrzymują tag.

Testowanie reguł z przykładowymi payloadami

Przed wdrożeniem reguł na produkcję przetestuj je na przykładowych payloadach, aby sprawdzić, czy zachowują się zgodnie z oczekiwaniami.

Za pomocą aplikacji webowej

1. Otwórz ustawienia integracji webhook
2. Przewiń do Reguły filtrowania
3. Kliknij Testuj reguły
4. Wklej przykładowy payload JSON do edytora
5. Kliknij Uruchom test

Wynik testu pokazuje:

• Która reguła pasowała (lub "Brak dopasowania -- domyślna akceptacja")
• Jaka akcja zostałaby podjęta
• Podgląd wynikowego alertu (z zastosowanymi modyfikacjami)

Za pomocą API

curl -X POST https://app.notifer.io/api/topics/my-alerts/webhooks/{webhook_id}/rules/test \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "payload": {
      "alertname": "HighCPU",
      "severity": "critical",
      "labels": {
        "env": "production",
        "instance": "web-01"
      },
      "annotations": {
        "summary": "CPU usage above 95% for 5 minutes"
      }
    }
  }'

Odpowiedź:

{
  "matched_rule": {
    "id": "uuid",
    "name": "Escalate critical to P1",
    "order": 2
  },
  "action": "modify",
  "result": {
    "would_create_alert": true,
    "priority": 1,
    "tags": ["production", "critical"],
    "title": "HighCPU",
    "message": "CPU usage above 95% for 5 minutes"
  }
}

Testuj regularnie

Za każdym razem, gdy dodajesz lub zmieniasz kolejność reguł, uruchom testy z reprezentatywnymi payloadami z każdego z Twoich narzędzi monitorujących. Pozwoli to wychwycić błędy w kolejności przed wpływem na alerty produkcyjne.

Kolejność i zmiana kolejności reguł

Ponieważ wygrywa pierwsza pasująca reguła, kolejność reguł jest kluczowa.

Zmiana kolejności w aplikacji webowej

• Przeciągnij i upuść: Kliknij i przytrzymaj uchwyt po lewej stronie reguły, a następnie przeciągnij ją na nową pozycję
• Przyciski góra/dół: Użyj przycisków strzałek na każdej regule, aby przesunąć ją o jedną pozycję w górę lub w dół

Zmiana kolejności przez API

curl -X PUT https://app.notifer.io/api/topics/my-alerts/webhooks/{webhook_id}/rules/reorder \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rule_ids": [
      "rule-uuid-3",
      "rule-uuid-1",
      "rule-uuid-2"
    ]
  }'

Tablica rule_ids definiuje nową kolejność. Pierwszy identyfikator w tablicy staje się pozycją 1.

Najlepsze praktyki

Umieszczaj reguły odrzucania na początku

Reguły odrzucania na szczycie listy to najbardziej efektywny wzorzec. Zdarzenia, które powinny być odrzucone, są wychwytywane wcześnie, zanim zostaną ewaluowane względem bardziej szczegółowych reguł.

1. Odrzuć alerty testowe        <-- szeroki filtr, wychwytuje szum wcześnie
2. Odrzuć poziomu info          <-- kolejny szeroki filtr
3. Eskaluj krytyczne do P1      <-- konkretna modyfikacja
4. Oznacz zdarzenia produkcyjne  <-- szeroka modyfikacja (catch-all)

Używaj szczegółowych warunków

Preferuj konkretne ścieżki pól i dokładne dopasowania zamiast szerokich wzorców:

# Konkretne i przewidywalne
severity equals critical

# Zbyt szerokie -- może pasować do niezamierzonych zdarzeń
annotations.summary contains error

Testuj przed wdrożeniem

Zawsze testuj nowe reguły z przykładowymi payloadami, które reprezentują Twoje rzeczywiste dane monitorujące. Zwróć szczególną uwagę na:

• Zdarzenia, które powinny być odrzucone -- sprawdź, czy faktycznie pasują do reguły odrzucania
• Zdarzenia, które powinny być eskalowane -- potwierdź, że priorytet jest ustawiony poprawnie
• Przypadki brzegowe -- zdarzenia, które mogą pasować do wielu reguł

Monitoruj liczniki dopasowań

Każda reguła śledzi, ile razy została dopasowana. Przeglądaj te liczniki okresowo:

• Reguła z zerową liczbą dopasowań może mieć warunki, które są zbyt szczegółowe lub nigdy nie występują
• Reguła z niespodziewanie dużą liczbą dopasowań może być zbyt szeroka i wychwytywać zdarzenia, które zamierzałeś przepuścić
• Nagła zmiana w licznikach dopasowań może wskazywać na zmianę w formacie payloadu Twojego narzędzia monitorującego

Utrzymuj reguły w rozsądnej liczbie

Jeśli masz więcej niż 10 reguł na jednym webhooku, rozważ:

• Rozdzielenie alertów na wiele tematów z osobnymi webhookami
• Dostosowanie reguł alertów w narzędziu monitorującym, aby zredukować szum u źródła
• Użycie bardziej szczegółowych warunków do konsolidacji powiązanych reguł

Następne kroki

• Dokumentacja Alert API -- Zarządzaj regułami filtrowania programistycznie
• Priorytet wiadomości -- Poznaj poziomy priorytetów P1-P5
• Tagi -- Dowiedz się o filtrowaniu opartym na tagach