Tryb alertow - przegląd

Tryb alertow przekształca tematy Notifer z prostych kanałów powiadomień w pełnoprawne punkty końcowe do zarządzania incydentami. Zamiast traktować każdą wiadomość jako samodzielne powiadomienie, tryb alertow grupuje powiązane zdarzenia według unikalnego klucza, śledzi ich cykl życia i redukuje szum informacyjny dzięki inteligentnej deduplikacji.

Czym jest tryb alertow?

Zwykłe wiadomości Notifer działają w modelu "wyślij i zapomnij": publikujesz wiadomość, subskrybenci ją otrzymują i to koniec historii. Tryb alertow dodaje stan do Twoich wiadomości. Gdy wysyłasz alert z określonym kluczem, Notifer śledzi, czy ten alert jest otwarty, potwierdzony czy rozwiązany. Kolejne wiadomości z tym samym kluczem aktualizują istniejący alert zamiast tworzyć nowe powiadomienie.

Zwykłe wiadomości są idealne do jednorazowych powiadomień, takich jak zakończenie wdrożenia, rejestracja użytkownika czy raporty dzienne. Alerty są przeznaczone do trwających sytuacji wymagających śledzenia aż do rozwiązania, takich jak awarie serwerów, wysokie użycie CPU czy nieudane kontrole stanu.

Kiedy używać trybu alertow

Jeśli Twój zespół musi wiedzieć "czy ten problem nadal występuje?" lub "czy ktoś się tym zajął?" -- potrzebujesz trybu alertow. Jeśli powiadomienie jest wyłącznie informacyjne i nie wymaga dalszych działań, zwykłe wiadomości będą lepszym wyborem.

Cykl życia alertu

Każdy alert przechodzi przez wyraźny trójstanowy cykl życia:

                    New alert received
                          |
                          v
                   +-----------+
                   |           |
                   |   OPEN    | <--- Same alert_key received
                   |           |      (occurrence count increases)
                   +-----+-----+
                         |
              Team member acknowledges
                         |
                         v
                +----------------+
                |                |
                | ACKNOWLEDGED   |
                |                |
                +-------+--------+
                        |
             Issue fixed / auto-resolved
                        |
                        v
                  +-----------+
                  |           |
                  | RESOLVED  |
                  |           |
                  +-----+-----+
                        |
              Same alert_key fires again
                        |
                        v
                   +-----------+
                   |           |
                   |   OPEN    |  (auto-reopen)
                   |           |
                   +-----------+

Opis stanów

Stan	Znaczenie	Powiadomienia	Wskaźnik na pulpicie
Otwarty (Open)	Aktywny problem wymagający uwagi	Pełne powiadomienia (push, SSE, WebSocket)	Czerwony wskaźnik
Potwierdzony (Acknowledged)	Ktoś bada problem	Wstrzymane dla tego klucza alertu (do rozwiązania lub ponownego otwarcia)	Żółty wskaźnik
Rozwiązany (Resolved)	Problem został naprawiony	Jednorazowe powiadomienie o rozwiązaniu	Zielony wskaźnik

Przejścia między stanami

• Otwarty -> Potwierdzony: Członek zespołu klika "Potwierdź" na pulpicie lub wywołuje endpoint API potwierdzenia.
• Otwarty -> Rozwiązany: Alert jest rozwiązywany ręcznie lub przez wywołanie API z nagłówkiem X-Alert-Status: resolved.
• Potwierdzony -> Rozwiązany: Badający członek zespołu oznacza problem jako naprawiony.
• Potwierdzony -> Otwarty (ponowne otwarcie): Nowe wystąpienie pojawia się dla tego samego klucza alertu w stanie potwierdzonym, ponownie wyzwalając powiadomienia.
• Rozwiązany -> Otwarty (ponowne otwarcie): Ten sam alert pojawia się ponownie po rozwiązaniu, rozpoczynając nowy cykl incydentu.

Kluczowe pojęcia

Klucz alertu (deduplikacja)

alert_key to podstawowe pojęcie trybu alertow. Jest to ciąg znaków zdefiniowany przez Ciebie, który jednoznacznie identyfikuje określony warunek alertu. Gdy wiele wiadomości przychodzi z tym samym alert_key, Notifer grupuje je w jeden alert zamiast tworzyć osobne powiadomienia dla każdej z nich.

# Both of these update the SAME alert:
curl -d "CPU at 92%" -H "X-Alert-Key: cpu-high" https://app.notifer.io/monitoring
curl -d "CPU at 97%" -H "X-Alert-Key: cpu-high" https://app.notifer.io/monitoring

Wybieraj klucze alertów, które są znaczące i konkretne. Dobre przykłady:

Klucz alertu	Scenariusz
cpu-high-prod-web-01	Alert CPU dla konkretnego serwera
disk-space-/data	Alert miejsca na dysku dla konkretnego punktu montowania
healthcheck-api-gateway	Nieudana kontrola stanu dla usługi
cert-expiry-example.com	Wygasający certyfikat SSL dla domeny
backup-failed-postgres	Nieudany backup bazy danych

Konwencja nazewnictwa

Używaj małych liter z myślnikami. Dołącz typ kontroli i identyfikator zasobu, aby Twój zespół od razu wiedział, czego dotyczy problem: {kontrola}-{zasób}.

Licznik wystąpień

Za każdym razem, gdy wiadomość przychodzi z tym samym alert_key, podczas gdy alert jest nadal otwarty, Notifer zwiększa licznik wystąpień zamiast wysyłać nowe powiadomienie. To właśnie sprawia, że tryb alertow jest potężny w scenariuszach monitoringu, gdzie ten sam warunek jest wykrywany wielokrotnie.

Na przykład, zadanie cron sprawdzające CPU co minutę może wygenerować 60 alertów na godzinę podczas skoku obciążenia. Bez trybu alertow Twój zespół otrzymuje 60 osobnych powiadomień. Z trybem alertow otrzymują jeden alert pokazujący "60 wystąpień" wraz z najnowszą treścią wiadomości.

Licznik wystąpień jest widoczny na pulpicie i dołączony w odpowiedziach API:

{
  "alert_key": "cpu-high-prod-web-01",
  "status": "open",
  "occurrences": 42,
  "first_seen": "2026-02-14T08:15:00Z",
  "last_seen": "2026-02-14T08:56:00Z",
  "message": "CPU at 98% for 5 minutes"
}

Automatyczne ponowne otwarcie

Gdy alert został potwierdzony lub rozwiązany, nowe wystąpienie tego samego alert_key automatycznie ponownie otworzy alert. Zapewnia to, że powtarzające się problemy nigdy nie zostaną cicho zignorowane.

Automatyczne ponowne otwarcie działa następująco:

• Potwierdzony alert otrzymuje nowe wystąpienie: Alert przechodzi z powrotem do stanu Otwarty. Zespół jest ponownie powiadamiany, ponieważ problem mógł się pogorszyć lub zmienić.
• Rozwiązany alert otrzymuje nowe wystąpienie: Alert przechodzi z powrotem do stanu Otwarty. Oznacza to, że problem powrócił i wymaga ponownej uwagi.

Automatyczne ponowne otwarcie jest zawsze włączone i nie można go wyłączyć. Jest to celowe rozwiązanie -- jeśli warunek pojawia się ponownie, Twój zespół powinien o tym wiedzieć niezależnie od wcześniejszych potwierdzeń.

Przypadki użycia

Monitoring infrastruktury (Prometheus / Grafana)

Połącz Prometheus Alertmanager lub reguły alertowania Grafana z Notifer przez webhook. Alerty z Twojego stosu monitoringu są automatycznie mapowane na alerty Notifer z odpowiednią deduplikacją i śledzeniem cyklu życia.

Prometheus -> Alertmanager -> Notifer webhook -> Alert created
                                              -> Push notification
                                              -> Dashboard updated

Typowe scenariusze:

• Wysokie użycie CPU / pamięci / dysku
• Nieudane kontrole stanu usług
• Restarty podów w Kubernetes
• Wyczerpanie puli połączeń do bazy danych

DevOps i CI/CD

Śledź nieudane wdrożenia, awarie kompilacji i problemy z provisioningiem infrastruktury jako alerty zamiast jednorazowych wiadomości. Gdy pipeline zawiedzie i ponownie zawiedzie przy kolejnej próbie, widzisz jeden alert z wieloma wystąpieniami zamiast zalewu osobnych powiadomień.

# CI pipeline failure alert
curl -d "Pipeline #1234 failed at stage: deploy" \
  -H "X-Alert-Key: pipeline-main-deploy" \
  -H "X-Priority: 2" \
  -H "X-Tags: ci,pipeline,failure" \
  https://app.notifer.io/ci-alerts

Zarządzanie incydentami

Użyj trybu alertow jako fundamentu procesu reagowania na incydenty:

1. Monitoring wykrywa problem i tworzy alert (Otwarty).
2. Dyżurny inżynier otrzymuje powiadomienie push i potwierdza je.
3. Inżynier bada i naprawia problem.
4. Inżynier rozwiązuje alert (lub wysyła X-Alert-Status: resolved ze skryptu naprawczego).
5. Pełna oś czasu (wystąpienia, znaczniki czasowe, wiadomości) jest zachowana na potrzeby analiz post-mortem.

IoT i monitoring urządzeń

Śledź alerty czujników z urządzeń IoT. Czujniki temperatury, wilgotności lub ruchu mogą publikować do Notifer z kluczami alertów powiązanymi z identyfikatorem urządzenia:

curl -d "Temperature 42°C exceeds threshold 38°C" \
  -H "X-Alert-Key: temp-sensor-warehouse-b" \
  -H "X-Priority: 2" \
  -H "X-Tags: iot,temperature,warehouse" \
  https://app.notifer.io/iot-alerts

Jeśli czujnik nadal raportuje wysokie temperatury, licznik wystąpień rośnie bez zalewania kanałów powiadomień.

Pulpit alertów

Gdy tryb alertow jest włączony na temacie, pulpit przełącza się ze standardowej chronologicznej listy wiadomości na widok zorientowany na alerty. Ten widok jest zaprojektowany do szybkiej oceny sytuacji.

Układ pulpitu

Pulpit alertów organizuje alerty w trzech sekcjach:

Aktywne alerty (Otwarte)

• Sortowane według priorytetu (P1 na początku), następnie według najnowszego wystąpienia
• Każda karta pokazuje: klucz alertu, najnowszą wiadomość, znacznik priorytetu, licznik wystąpień, znaczniki czasu pierwszego/ostatniego wystąpienia oraz tagi
• Czerwony wskaźnik statusu

W trakcie (Potwierdzone)

• Pokazuje, kto potwierdził alert i kiedy
• Sortowane według czasu potwierdzenia (najnowsze na początku)
• Żółty wskaźnik statusu

Ostatnio rozwiązane

• Alerty rozwiązane w ciągu ostatnich 24 godzin
• Pokazuje czas rozwiązania i kto je rozwiązał
• Zielony wskaźnik statusu
• Starsze rozwiązane alerty są dostępne w historii alertów

Oś czasu alertu

Kliknij dowolny alert, aby rozwinąć jego pełną oś czasu. Oś czasu pokazuje każde zdarzenie w kolejności chronologicznej:

• Utworzenie alertu (z pierwszą treścią wiadomości)
• Każde kolejne wystąpienie (z zaktualizowaną treścią wiadomości)
• Zdarzenia potwierdzenia (kto i kiedy)
• Zdarzenia rozwiązania (kto, kiedy i wiadomość rozwiązania)
• Zdarzenia ponownego otwarcia (jeśli alert został ponownie otwarty po rozwiązaniu)

Ta oś czasu jest przechowywana bezterminowo i może być wykorzystana do przeglądów po incydentach.

Filtrowanie i wyszukiwanie

Pulpit alertów obsługuje filtrowanie według:

• Status: Pokazuj tylko otwarte, potwierdzone lub rozwiązane alerty
• Priorytet: Filtruj według zakresu priorytetów (np. tylko P1-P2)
• Tagi: Filtruj według jednego lub więcej tagów
• Zakres czasowy: Pokazuj alerty z określonego okna czasowego
• Wyszukiwanie: Pełnotekstowe wyszukiwanie po kluczach alertów i treści wiadomości

Zachowanie powiadomień

Tryb alertow zmienia sposób dostarczania powiadomień w porównaniu do zwykłych wiadomości. Zrozumienie tego zachowania pomoże Ci skutecznie skonfigurować ustawienia powiadomień.

Kiedy powiadomienia są wysyłane

Zdarzenie	Powiadomienie push	SSE / WebSocket	Aktualizacja pulpitu
Nowy alert (pierwsze wystąpienie)	Tak	Tak	Tak
Kolejne wystąpienie (ten sam klucz, nadal otwarty)	Nie (zdeduplikowane)	Tak (aktualizacja licznika)	Tak
Alert potwierdzony	Nie	Tak	Tak
Alert rozwiązany	Tak (informacja o rozwiązaniu)	Tak	Tak
Alert ponownie otwarty (nowe wystąpienie po rozwiązaniu)	Tak	Tak	Tak

Deduplikacja w szczegółach

Najważniejsza różnica behawioralna to deduplikacja. Gdy ten sam alert_key pojawia się wielokrotnie, podczas gdy alert jest nadal otwarty:

• Powiadomienia push: Tylko pierwsze wystąpienie wyzwala push. Kolejne wystąpienia są ciche na urządzeniach mobilnych.
• SSE i WebSocket: Wszystkie wystąpienia są strumieniowane do połączonych klientów. Aplikacje webowe i mobilne aktualizują licznik wystąpień i treść wiadomości w czasie rzeczywistym.
• Pulpit: Karta alertu aktualizuje się najnowszą treścią wiadomości, zwiększonym licznikiem wystąpień i zaktualizowanym znacznikiem czasu last_seen.

Oznacza to, że Twoje skrypty monitorujące mogą uruchamiać się tak często, jak to potrzebne, bez obawy o przeciążenie zespołu powiadomieniami. Pulpit zawsze pokazuje najnowszy stan, a powiadomienia push pozostają zarządzalne.

Powiadomienia o rozwiązaniu

Gdy alert jest rozwiązywany (ręcznie lub przez X-Alert-Status: resolved), wysyłane jest jedno powiadomienie push do subskrybentów informujące, że problem został usunięty. Pomaga to zespołowi wiedzieć, że aktywna sytuacja została obsłużona.

Czym alerty różnią się od zwykłych powiadomień

Funkcja	Zwykłe wiadomości	Tryb alertow
Deduplikacja	Brak -- każda wiadomość jest osobna	Wiadomości z tym samym alert_key są grupowane
Śledzenie stanu	Brak stanu	Otwarty, Potwierdzony, Rozwiązany
Potwierdzanie	Niedostępne	Członkowie zespołu mogą potwierdzać alerty
Licznik wystąpień	Niedostępny	Zlicza powtórne wystąpienia
Automatyczne ponowne otwarcie	Niedostępne	Rozwiązane alerty otwierają się ponownie przy nowym wystąpieniu
Zachowanie powiadomień	Każda wiadomość wyzwala powiadomienie	Zdeduplikowane -- tylko zmiany stanu wyzwalają powiadomienia
Widok pulpitu	Chronologiczna lista wiadomości	Karty alertów ze statusem, wystąpieniami i osią czasu
Integracje webhook	Niedostępne	Alertmanager, Grafana, Datadog i inne
Śledzenie rozwiązań	Niedostępne	Śledzenie kiedy i kto rozwiązał każdy alert

Korzyści

Redukcja zmęczenia powiadomieniami

Bez deduplikacji niestabilna usługa może generować setki powiadomień na godzinę. Tryb alertow łączy je w jeden alert z licznikiem wystąpień, więc Twój zespół widzi jedno powiadomienie zamiast być przytłoczonym.

Śledzenie incydentów

Każdy alert utrzymuje pełną oś czasu: kiedy po raz pierwszy się pojawił, ile razy wystąpił, kiedy został potwierdzony i kiedy został rozwiązany. Ta historia jest nieoceniona przy przeglądach po incydentach i raportowaniu SLA.

Integracja z narzędziami monitoringu

Tryb alertow mówi tym samym językiem co Twój istniejący stos monitoringu. Integracje webhook z Alertmanager, Grafana, Datadog, Zabbix i innymi pozwalają kierować wszystkie alerty na jeden pulpit bez znaczącej zmiany konfiguracji monitoringu.

Jasne przypisanie odpowiedzialności

Krok potwierdzenia sprawia, że cały zespół widzi, że ktoś pracuje nad problemem. Koniec z dublowaniem wysiłków diagnostycznych i sytuacjami "myślałem, że Ty się tym zajmujesz".

Automatyczne wykrywanie naprawy

Wysyłając X-Alert-Status: resolved ze skryptów naprawczych lub webhooków narzędzi monitoringu, alerty są automatycznie zamykane, gdy problem zostanie naprawiony. Nie wymaga to ręcznego porządkowania.

Współpraca z istniejącymi procesami

Tryb alertow nie wymaga zmiany sposobu publikowania wiadomości. Wystarczy dodać nagłówek X-Alert-Key do istniejących wywołań publikowania. Jeśli masz już skrypty wysyłające powiadomienia przez Notifer, włączenie trybu alertow i dodanie jednego nagłówka daje Ci deduplikację, śledzenie stanu i potwierdzanie bez jakichkolwiek innych zmian w procesie.

Zacznij od małego

Nie musisz włączać trybu alertow na wszystkich tematach naraz. Zacznij od jednego tematu o dużej objętości, gdzie zmęczenie powiadomieniami stanowi problem (np. temat monitoringu infrastruktury), i rozszerzaj stopniowo, gdy Twój zespół oswoi się z procesem alertów.

Przykład z życia: pełny cykl alertu

Oto kompletny przykład pokazujący, jak tryb alertow działa w praktyce:

# 1. Monitoring script detects high CPU
curl -d "CPU usage at 92% on prod-web-01" \
  -H "X-Alert-Key: cpu-high-prod-web-01" \
  -H "X-Priority: 2" \
  -H "X-Tags: cpu,production,web" \
  https://app.notifer.io/infra-alerts
# -> Alert created (OPEN), push notification sent

# 2. CPU stays high -- same alert fires again 1 minute later
curl -d "CPU usage at 95% on prod-web-01" \
  -H "X-Alert-Key: cpu-high-prod-web-01" \
  -H "X-Priority: 2" \
  https://app.notifer.io/infra-alerts
# -> Occurrence count: 2, NO new notification (deduplicated)

# 3. Engineer acknowledges via dashboard or API
# -> Alert state: ACKNOWLEDGED, team sees yellow indicator

# 4. CPU normalizes -- recovery script sends resolution
curl -d "CPU usage normalized at 45% on prod-web-01" \
  -H "X-Alert-Key: cpu-high-prod-web-01" \
  -H "X-Alert-Status: resolved" \
  https://app.notifer.io/infra-alerts
# -> Alert state: RESOLVED, resolution notification sent

# 5. If CPU spikes again later, the alert auto-reopens

Następne kroki

• Rozpoczęcie pracy z alertami -- Włącz tryb alertow i wyślij swój pierwszy alert
• Integracje webhook -- Połącz Alertmanager, Grafana, Datadog i inne
• Dokumentacja API -- Pełne endpointy API alertów
• Poziomy priorytetów -- Ustaw odpowiedni priorytet dla swoich alertów
• Tagi -- Organizuj alerty za pomocą tagów do filtrowania