---
title: Warunki kanału - inteligentne filtrowanie powiadomień
sidebarTitle: Warunki
description: "Filtruj powiadomienia Echobell wyrażeniami warunkowymi: operatory, reguły czasowe i dobre praktyki ograniczające zmęczenie alertami."
---

# Warunki kanału

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”.

<Callout type="info">Wszystkie nazwy nagłówków są pisane małymi literami.</Callout>

### 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:

| Operator                  | Opis                     | Przykład                                    |
| ------------------------- | ------------------------ | ------------------------------------------- |
| `==`                      | Równe                    | `status == "active"`                        |
| `!=`                      | Różne od                 | `status != "inactive"`                      |
| `!`                       | Logiczne NIE             | `!isCompleted`                              |
| `<`                       | Mniejsze niż             | `count < 10`                                |
| `>`                       | Większe niż              | `price > 99.99`                             |
| `<=`                      | Mniejsze lub równe       | `battery <= 20`                             |
| `>=`                      | Większe lub równe        | `confidence >= 0.95`                        |
| `&&`                      | Logiczne I               | `isAdmin && isActive`                       |
| <code>&#124;&#124;</code> | Logiczne LUB             | <code>isError &#124;&#124; isWarning</code> |

## 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](/docs/template) 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](/docs/template).

## 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](/docs/template)** — formatuj treść powiadomień przy użyciu zmiennych
- **[Integracja przez webhooki](/docs/webhook)** — przekazuj zmienne w żądaniach HTTP
- **[Wyzwalacze e-mail](/docs/email-trigger)** — zmienne dostępne przy wyzwalaczach e-mail
- **[Pierwsze kroki](/docs)** — skonfiguruj swój pierwszy kanał z warunkiem

## Kolejne kroki

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

- **[Twórz inteligentne alerty monitoringu](/docs/developer/grafana)** — filtruj alerty z infrastruktury
- **[Skonfiguruj powiadomienia CI/CD](/docs/developer/github)** — alertuj tylko o ważnych zdarzeniach w buildach
- **[Ustaw alerty zależne od czasu](/blog/time-window-notifications-using-utc-conditions)** — filtrowanie według godzin pracy
- **[Poznaj wszystkie funkcje](/docs/features)** — 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.