Warunki kanału - inteligentne filtrowanie powiadomień

Warunki kanału to wyrażenia, które decydują o tym, kiedy powiadomienia mają zostać wysłane. Ustawiając warunek na kanale, możesz filtrować powiadomienia na podstawie zawartości zmiennych lub nagłówków HTTP, dzięki czemu subskrybenci dostają wyłącznie istotne alerty. To kluczowe narzędzie, jeśli chcesz ograniczyć zmęczenie alertami i utrzymać wysoki stosunek sygnału do szumu w swoim systemie powiadomień.

Traktuj warunki jak strażnika powiadomień — sprawdzają przychodzące dane wyzwalacza i przepuszczają powiadomienie tylko wtedy, gdy spełnione są określone kryteria.

Jak działają warunki

Warunki to wyrażenia, których wynikiem jest true albo false. Gdy kanał zostaje wyzwolony:

• Jeśli warunki nie są ustawione (pole jest puste), powiadomienia trafiają do wszystkich subskrybentów.
• Jeśli warunki są ustawione, powiadomienia są wysyłane tylko wtedy, gdy wyrażenie da wynik true.

Zapisywanie warunków

Warunki zapisuje się jako wyrażenia bez nawiasów {{}}, których używa się w szablonach. Na przykład:

status == "active"

Ten warunek przepuści powiadomienie tylko wtedy, gdy zmienna status ma wartość „active”.

Typowe zastosowania

Oto kilka praktycznych przykładów użycia warunków:

Podstawowe sprawdzanie zmiennych

amount > 100

Powiadamiaj tylko wtedy, gdy zmienna „amount” jest większa niż 100.

message != ""

Powiadamiaj tylko wtedy, gdy zmienna „message” nie jest pusta.

isUrgent == true

Powiadamiaj tylko wtedy, gdy zmienna „isUrgent” ma wartość true.

Sprawdzanie nagłówków HTTP

Do nagłówków HTTP sięgniesz przez specjalną zmienną header:

header["x-webhook-source"] == "grafana"

Powiadamiaj tylko wtedy, gdy własny nagłówek źródła ma dokładnie wartość „grafana”.

header["content-type"] == "application/json"

Powiadamiaj tylko wtedy, gdy typ treści to JSON.

header["x-priority"] == "high"

Powiadamiaj tylko wtedy, gdy własny nagłówek priorytetu ma wartość „high”.

Złożone warunki

Wiele warunków możesz łączyć operatorami logicznymi:

(temperature > 30 || pressure > 100) && status == "monitoring"

Powiadamiaj tylko wtedy, gdy temperatura przekracza 30 lub ciśnienie przekracza 100, a status to „monitoring”.

environment == "production" && (errorLevel == "critical" || errorLevel == "high")

Powiadamiaj tylko o błędach krytycznych lub wysokiego poziomu w środowisku produkcyjnym.

Obsługiwane operatory

W wyrażeniach warunkowych obsługiwane są następujące operatory:

Zmienne dostępne w warunkach

Gdy kanał jest wyzwalany webhookiem, masz dostęp do:

1. Parametrów zapytania z adresu URL
2. Treści JSON z żądań POST
3. Nagłówków HTTP przez obiekt header

Przy wyzwalaczach e-mail dostępne są:

• from: adres e-mail nadawcy
• to: adres odbiorcy
• subject: temat wiadomości
• text: treść w postaci zwykłego tekstu
• html: treść HTML

Systemowe zmienne czasu (UTC)

Te zmienne tylko do odczytu są zawsze dostępne zarówno w warunkach, jak i w szablonach. Wszystkie wartości są wyliczane w strefie UTC.

Poniższe wartości są wstrzykiwane bezpośrednio (płasko) i można ich używać po nazwie:

• year: rok czterocyfrowy (liczba)
• month: numer miesiąca 1–12
• dayOfMonth: dzień miesiąca 1–31
• dayOfWeek: dzień tygodnia 0–6 (niedziela = 0)
• hour: godzina 0–23
• minute: minuta 0–59
• second: sekunda 0–59
• date: napis YYYY-MM-DD
• time: napis HH:mm:ss
• iso: bieżący czas jako napis ISO‑8601 (np. 2025-05-06T12:34:56.789Z)

Dodatkowe wartości są dostępne wyłącznie w przestrzeni nazw sys. (nie są wstrzykiwane pod płaskimi nazwami):

• sys.timezone: stały napis "UTC"
• sys.now: bieżący czas jako napis ISO‑8601 (ta sama wartość co iso)
• sys.epochMs: liczba milisekund od epoki uniksowej (liczba)
• sys.epochSeconds: liczba sekund od epoki uniksowej (liczba)
• sys.monthName: nazwa miesiąca January–December
• sys.dayOfWeekName: nazwa dnia Sunday–Saturday

Przestrzeń nazw sys. odzwierciedla też każdą płaską wartość (np. sys.year, sys.hour).

Przykłady:

// Dni robocze w godzinach 09:00–17:00 UTC
hour >= 9 && hour < 17 && dayOfWeek >= 1 && dayOfWeek <= 5

// Tylko weekendy
dayOfWeek == 0 || dayOfWeek == 6

// Pierwszy dzień miesiąca o pełnej godzinie
dayOfMonth == 1 && minute == 0

Dobre praktyki

Zacznij od prostych warunków

Zacznij od podstaw i dokładaj złożoności w miarę potrzeb:

Etap 1: zacznij od pojedynczych warunków

temperature > 30

Etap 2: dodaj operatory logiczne

temperature > 30 && location == "server-room"

Etap 3: dodaj zagnieżdżoną logikę

(temperature > 30 || humidity > 80) && location == "server-room" && status == "monitoring"

Testuj dokładnie

Sprawdź swoje warunki na różnych danych wejściowych, aby mieć pewność, że działają zgodnie z oczekiwaniami:

1. Testuj na typowych wartościach — sprawdź, czy warunki działają w spodziewanych scenariuszach
2. Testuj przypadki graniczne — co dzieje się dokładnie na progu?
3. Testuj brakujące zmienne — jak warunek radzi sobie z brakiem danych?
4. Testuj nieoczekiwane typy — co, jeśli liczba przyjdzie jako napis?
5. Korzystaj z testowych webhooków — wysyłaj testowe wyzwolenia z różnymi kombinacjami danych

Dokumentuj swoje warunki

Dopisz wyjaśnienia w polu notatki kanału, aby opisać złożone warunki:

Notatka kanału:
Warunek: (cpu > 80 && memory > 90) || diskSpace < 10

Ten warunek wywołuje alerty, gdy:
- CPU przekracza 80% I JEDNOCZEŚNIE pamięć przekracza 90%
- LUB gdy wolne miejsce na dysku spada poniżej 10 GB

Dzięki temu członkowie zespołu zrozumieją logikę alertów bez rozbierania wyrażenia na części.

Uwzględnij przypadki graniczne

Przewidź brakujące zmienne i nieoczekiwane wartości:

• Brakujące zmienne: niezdefiniowane zmienne dają wartość pustą/fałsz — zadbaj, aby Twoja logika to uwzględniała
• Porównania liczbowe: <, >, <= i >= konwertują oba operandy przez Number(), więc porównują liczbowo, a nie leksykalnie. "100" > "20" daje true (100 > 20), a nie wynik porządku leksykalnego.
• Wartości nieliczbowe: jeśli któraś strona porównania <, >, <= lub >= nie jest liczbą, Number() zwraca NaN, a porównanie zawsze daje false.
• Równość a porównanie: == i != korzystają z równości nieścisłej (więc count == "5" pasuje do liczby 5), natomiast operatory porządku zawsze porównują liczbowo.
• Wielkość liter ma znaczenie: status == "Active" to co innego niż status == "active"

Zapobiegaj lawinom alertów

Używaj warunków, aby nie dostawać serii powiadomień o przejściowych problemach:

errorCount > 5    # A nie po prostu errorCount > 0
cpuUsage > 90     # A nie cpuUsage > 50
failureRate > 0.1 # A nie po prostu hasFailures

Dobierz progi tak, aby ograniczyć szum, ale nie przegapić zdarzeń krytycznych.

Filtruj według godzin pracy

Połącz wagę alertu z warunkami czasowymi:

severity == "critical" || (severity == "high" && hour >= 9 && hour < 17)

Alerty krytyczne przychodzą wtedy przez całą dobę, a alerty wysokiego priorytetu tylko w godzinach pracy.

Wykorzystaj sprawdzanie nagłówków

Weryfikuj źródła webhooków, aby odciąć spam i nieautoryzowane wyzwolenia:

header["x-webhook-source"] == "grafana" || header["x-webhook-source"] == "prometheus"

To dodatkowa warstwa bezpieczeństwa oparta na sprawdzeniu pochodzenia żądania.

Przykłady z życia

Monitoring serwerów — alerty progresywne

# Alertuj tylko przy trwale wysokim CPU, nie przy chwilowych skokach
cpu > 80 && duration >= 300

E-commerce — zamówienia o wysokiej wartości

# Powiadamiaj tylko o zamówieniach powyżej 500 $ lub oznaczonych jako podejrzane
orderAmount > 500 || isFraudSuspected == true

Programowanie — krytyczne błędy buildów

# Alertuj tylko o błędach na gałęzi głównej lub nieudanych wdrożeniach
(branch == "main" || branch == "master") && status == "failed"

IoT — monitoring środowiska

# Skrajne temperatury poza dopuszczalnym zakresem
temperature < 15 || temperature > 28

Bezpieczeństwo — nieudane próby logowania

# Wiele nieudanych logowań z tego samego IP w krótkim czasie
failedAttempts >= 3 && timeSinceFirst < 300

CI/CD — śledzenie wdrożeń

# Powiadamiaj tylko o wdrożeniach na produkcji lub błędach na stagingu
(environment == "production") || (environment == "staging" && status == "failed")

Trading — alerty cenowe

# Istotne ruchy ceny powyżej progu
(priceChange > 5 || priceChange < -5) && volume > 1000000

Wsparcie — przekroczenia SLA

# Zgłoszenia zbliżające się do SLA lub już je przekraczające
ticketAge > slaThreshold || priority == "urgent"

Typowe wzorce warunków

Alertowanie oparte na progach

value > threshold
percentage >= 90
count < minimumRequired

Filtrowanie według statusu

status == "error" || status == "critical"
state != "healthy"
isActive == true

Filtrowanie po oknie czasowym

# Tylko godziny pracy (9:00–17:00 UTC, od poniedziałku do piątku)
hour >= 9 && hour < 17 && dayOfWeek >= 1 && dayOfWeek <= 5

# Tylko poza godzinami pracy
hour < 9 || hour >= 17 || dayOfWeek == 0 || dayOfWeek == 6

# Weekendowe okna serwisowe
(dayOfWeek == 0 || dayOfWeek == 6) && hour >= 2 && hour < 6

Warunki wieloczynnikowe

# Połącz wiele kryteriów
severity == "high" && environment == "production" && region == "us-east-1"

# Albo krytyczne, albo produkcja z wysoką wagą
severity == "critical" || (severity == "high" && environment == "production")

Dopasowywanie tekstu

# Dopasowanie dokładne (nie ma operatora „zawiera”)
status == "error"
errorType == "database"

# Porównanie tekstów
environment == "production"
username != "test-user"

Łączenie warunków z szablonami

Warunki i szablony współpracują ze sobą, tworząc inteligentne, kontekstowe powiadomienia:

Warunek (filtruje, które wyzwolenia wysyłają powiadomienia):

temperature > 30 || humidity > 80

Szablon (formatuje treść powiadomienia):

Title: Alert środowiskowy: {{location}}
Body: Temperatura: {{temperature}}°C, wilgotność: {{humidity}}%

Taki podział pozwala Ci:

1. Filtrować niechciane powiadomienia warunkami
2. Formatować ważne powiadomienia szablonami
3. Dopasowywać treść powiadomienia do wagi zdarzenia

Więcej o składni i możliwościach szablonów.

Diagnozowanie warunków

Jeśli warunki nie działają zgodnie z oczekiwaniami:

1. Uprość warunek — testuj po jednym porównaniu naraz
2. Sprawdź nazwy zmiennych — muszą zgadzać się dokładnie (wielkość liter ma znaczenie)
3. Zweryfikuj typy danych — użyj testowych webhooków, aby potwierdzić typy zmiennych
4. Przetestuj logikę boolowską — rozbij złożone warunki na mniejsze części
5. Przypomnij sobie kolejność operatorów — używaj nawiasów, aby wyrazić intencję jednoznacznie
6. Poszukaj literówek — header["content-type"], a nie header["Content-Type"]

Powiązana dokumentacja

• Przewodnik po szablonach — formatuj treść powiadomień przy użyciu zmiennych
• Integracja przez webhooki — przekazuj zmienne w żądaniach HTTP
• Wyzwalacze e-mail — zmienne dostępne przy wyzwalaczach e-mail
• Pierwsze kroki — skonfiguruj swój pierwszy kanał z warunkiem

Kolejne kroki

Skoro wiesz już, jak działają warunki:

• Twórz inteligentne alerty monitoringu — filtruj alerty z infrastruktury
• Skonfiguruj powiadomienia CI/CD — alertuj tylko o ważnych zdarzeniach w buildach
• Ustaw alerty zależne od czasu — filtrowanie według godzin pracy
• Poznaj wszystkie funkcje — sprawdź, co jeszcze potrafi Echobell

---

Umiejętnie stosowane warunki pozwalają ograniczyć szum powiadomień i zadbać o to, aby subskrybenci dostawali wyłącznie alerty, które są dla nich istotne i wymagają działania. Zacznij od prostych warunków i stopniowo buduj bardziej wyrafinowaną logikę filtrowania, w miarę jak rosną Twoje potrzeby.