Rozpoczęcie pracy z alertami

Ten przewodnik przeprowadzi Cię przez włączenie trybu alertow na temacie, wysłanie pierwszego alertu i zarządzanie cyklem życia alertów z poziomu pulpitu.

Wymagania wstępne

Zanim zaczniesz, upewnij się, że posiadasz:

• Konto Notifer (zarejestruj się na app.notifer.io)
• Co najmniej jeden utworzony temat (zobacz Tworzenie tematów)
• Klucz API lub token uwierzytelniający do dostępu programistycznego (zobacz Klucze API)

Nowy w Notifer?

Jeśli nie korzystałeś wcześniej z Notifer, zacznij od przewodnika Szybki start, aby utworzyć konto i pierwszy temat, a następnie wróć tutaj, aby włączyć alerty.

Krok 1: Włącz tryb alertow na temacie

Tryb alertow jest włączany per temat. Możesz go włączyć na istniejącym temacie lub podczas tworzenia nowego.

Przez aplikację webową (zalecane)

1. Zaloguj się na app.notifer.io
2. Przejdź do tematu, którego chcesz używać do alertów (lub utwórz nowy)
3. Kliknij ikonę Ustawienia (koło zębate) na stronie tematu
4. Znajdź sekcję Tryb alertow
5. Przełącz Włącz tryb alertow na włączony
6. Kliknij Zapisz

Po włączeniu temat będzie wyświetlał znacznik alertu na pulpicie i przełączy się na widok zorientowany na alerty, pokazujący aktywne, potwierdzone i rozwiązane alerty.

Przez aplikację mobilną

1. Otwórz aplikację Notifer na urządzeniu iOS lub Android
2. Przejdź do tematu
3. Dotknij Ustawienia (ikona koła zębatego) w prawym górnym rogu
4. Przewiń do Tryb alertow i włącz go
5. Dotknij Zapisz

Przez API

curl -X PATCH https://app.notifer.io/api/topics/my-alerts \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"alert_mode": true}'

Wybierz dedykowany temat

Zalecamy utworzenie dedykowanego tematu dla alertów (np. infra-alerts, monitoring, prod-incidents) zamiast mieszania alertów i zwykłych wiadomości na tym samym temacie. Utrzymuje to porządek na pulpicie i ułatwia konfigurację ustawień powiadomień.

Krok 2: Wyślij swój pierwszy alert

Mając włączony tryb alertow na temacie, wyślij alert dodając nagłówek X-Alert-Key do żądania publikacji. Klucz alertu informuje Notifer, że ta wiadomość ma być traktowana jako alert i umożliwia deduplikację.

curl -d "CPU usage above 90% on prod-web-01" \
  -H "X-Alert-Key: cpu-high" \
  -H "X-Priority: 2" \
  -H "X-Tags: server,production" \
  https://app.notifer.io/my-alerts

Powinieneś otrzymać odpowiedź potwierdzającą utworzenie alertu:

{
  "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "topic": "my-alerts",
  "message": "CPU usage above 90% on prod-web-01",
  "priority": 2,
  "tags": ["server", "production"],
  "alert": {
    "alert_key": "cpu-high",
    "status": "open",
    "occurrences": 1,
    "first_seen": "2026-02-14T10:00:00Z",
    "last_seen": "2026-02-14T10:00:00Z"
  }
}

Teraz wyślij ten sam klucz alertu ponownie, aby zobaczyć deduplikację w działaniu:

curl -d "CPU usage at 95% on prod-web-01 - still elevated" \
  -H "X-Alert-Key: cpu-high" \
  -H "X-Priority: 2" \
  -H "X-Tags: server,production" \
  https://app.notifer.io/my-alerts

Tym razem, zamiast tworzyć nowy alert, istniejący zostaje zaktualizowany:

{
  "id": "f9e8d7c6-b5a4-3210-fedc-ba0987654321",
  "topic": "my-alerts",
  "message": "CPU usage at 95% on prod-web-01 - still elevated",
  "priority": 2,
  "tags": ["server", "production"],
  "alert": {
    "alert_key": "cpu-high",
    "status": "open",
    "occurrences": 2,
    "first_seen": "2026-02-14T10:00:00Z",
    "last_seen": "2026-02-14T10:01:00Z"
  }
}

Zauważ, że licznik wystąpień wzrósł do 2, a last_seen został zaktualizowany, ale nie wysłano nowego powiadomienia push. Twój zespół widzi jeden alert, nie dwa.

Wymagane uwierzytelnianie

Powyższe przykłady pomijają nagłówki uwierzytelniania dla zwięzłości. W praktyce musisz dołączyć jeden z: Authorization: Bearer YOUR_TOKEN lub X-API-Key: noti_your_key (dla publicznych tematów), albo X-Topic-Token: tk_your_token (dla prywatnych tematów). Zobacz Uwierzytelnianie, aby uzyskać szczegóły.

Krok 3: Przeglądaj alerty na pulpicie

Pulpit webowy

1. Przejdź do app.notifer.io
2. Przejdź do tematu z włączonym trybem alertow
3. Strona tematu wyświetla teraz Widok alertów zamiast zwykłej listy wiadomości

Widok alertów wyświetla:

• Aktywne alerty -- otwarte alerty wymagające uwagi (sortowane według priorytetu, następnie według najnowszego wystąpienia)
• Potwierdzone alerty -- alerty, nad którymi ktoś aktywnie pracuje
• Rozwiązane alerty -- ostatnio rozwiązane alerty (ostatnie 24 godziny)

Każda karta alertu pokazuje:

• Klucz alertu i najnowszą wiadomość
• Poziom priorytetu ze wskaźnikiem kolorowym
• Licznik wystąpień i znaczniki czasu (pierwsze wystąpienie / ostatnie wystąpienie)
• Aktualny znacznik statusu
• Tagi

Aplikacja mobilna

Aplikacja mobilna pokazuje ten sam widok zorientowany na alerty, gdy temat ma włączony tryb alertow:

1. Otwórz temat w aplikacji mobilnej Notifer
2. Alerty są pogrupowane według statusu: Aktywne, Potwierdzone, Rozwiązane
3. Dotknij alertu, aby zobaczyć jego pełną oś czasu i historię wystąpień
4. Użyj gestów przesunięcia do szybkich akcji (potwierdzenie, rozwiązanie)

Krok 4: Potwierdzaj i rozwiązuj alerty

Przez pulpit (webowy i mobilny)

Potwierdzanie alertu:

1. Znajdź otwarty alert na pulpicie
2. Kliknij przycisk Potwierdź (ikona znacznika)
3. Alert przenosi się do sekcji "Potwierdzone" z żółtym wskaźnikiem
4. Twój zespół widzi, kto go potwierdził i kiedy

Rozwiązywanie alertu:

1. Znajdź alert (otwarty lub potwierdzony)
2. Kliknij przycisk Rozwiąż (ikona haczyka)
3. Alert przenosi się do sekcji "Rozwiązane" z zielonym wskaźnikiem
4. Powiadomienie o rozwiązaniu jest wysyłane do subskrybentów

Przez API

Potwierdzanie alertu:

curl -X POST https://app.notifer.io/api/topics/my-alerts/alerts/cpu-high/acknowledge \
  -H "Authorization: Bearer YOUR_TOKEN"

Rozwiązywanie alertu:

curl -X POST https://app.notifer.io/api/topics/my-alerts/alerts/cpu-high/resolve \
  -H "Authorization: Bearer YOUR_TOKEN"

Automatyczne rozwiązanie przez publikację ze statusem resolved:

curl -d "CPU usage back to normal at 35%" \
  -H "X-API-Key: noti_your_key_here" \
  -H "X-Alert-Key: cpu-high" \
  -H "X-Alert-Status: resolved" \
  https://app.notifer.io/my-alerts

Ta metoda jest szczególnie przydatna w automatycznych skryptach naprawczych, które wykrywają powrót warunku do normy.

Nagłówki alertów - dokumentacja

Podczas publikowania wiadomości do tematu z włączonym trybem alertow, następujące nagłówki HTTP kontrolują zachowanie alertów:

Nagłówek	Wymagany	Wartości	Opis
X-Alert-Key	Tak	Dowolny ciąg znaków (maks. 128 znaków)	Unikalny identyfikator do deduplikacji. Wiadomości z tym samym kluczem są grupowane w jeden alert.
X-Alert-Status	Nie	open, resolved	Jawne ustawienie statusu alertu. Domyślnie open. Użyj resolved, aby automatycznie rozwiązać alert.
X-Alert-Source	Nie	Dowolny ciąg znaków (maks. 64 znaki)	Identyfikuje źródło alertu (np. prometheus, grafana, custom-script). Wyświetlane na osi czasu alertu.

Te nagłówki współpracują ze standardowymi nagłówkami Notifer:

Nagłówek	Wymagany	Opis
X-Priority	Nie	Poziom priorytetu 1-5 (1=krytyczny, 5=informacyjny). Domyślnie: 3.
X-Title	Nie	Tytuł wiadomości wyświetlany w powiadomieniach.
X-Tags	Nie	Tagi rozdzielone przecinkami do filtrowania.

Wymagania klucza alertu

Nagłówek X-Alert-Key jest wymagany dla tematów z włączonym trybem alertow. Jeśli opublikujesz wiadomość do tematu z trybem alertow bez X-Alert-Key, wiadomość zostanie odrzucona z błędem 400 Bad Request. Zapewnia to prawidłowe śledzenie wszystkich wiadomości w tematach alertowych.

Wysyłanie alertów programistycznie

Python

import requests

NOTIFER_URL = "https://app.notifer.io"
API_KEY = "noti_your_api_key_here"
TOPIC = "infra-alerts"

def send_alert(alert_key: str, message: str, priority: int = 3,
               tags: list[str] = None, status: str = "open",
               source: str = None):
    """Send an alert to Notifer."""
    headers = {
        "X-API-Key": API_KEY,
        "X-Alert-Key": alert_key,
        "X-Alert-Status": status,
        "X-Priority": str(priority),
    }
    if tags:
        headers["X-Tags"] = ",".join(tags)
    if source:
        headers["X-Alert-Source"] = source

    response = requests.post(
        f"{NOTIFER_URL}/{TOPIC}",
        data=message,
        headers=headers,
    )
    response.raise_for_status()
    return response.json()


# Send an alert
send_alert(
    alert_key="disk-space-low",
    message="Disk usage at 92% on /data volume",
    priority=2,
    tags=["disk", "storage", "production"],
    source="disk-monitor",
)

# Resolve an alert when condition clears
send_alert(
    alert_key="disk-space-low",
    message="Disk usage back to 60% after cleanup",
    status="resolved",
    source="disk-monitor",
)

JavaScript / Node.js

const NOTIFER_URL = "https://app.notifer.io";
const API_KEY = "noti_your_api_key_here";
const TOPIC = "infra-alerts";

async function sendAlert({
  alertKey,
  message,
  priority = 3,
  tags = [],
  status = "open",
  source = null,
}) {
  const headers = {
    "X-API-Key": API_KEY,
    "X-Alert-Key": alertKey,
    "X-Alert-Status": status,
    "X-Priority": String(priority),
  };

  if (tags.length > 0) {
    headers["X-Tags"] = tags.join(",");
  }
  if (source) {
    headers["X-Alert-Source"] = source;
  }

  const response = await fetch(`${NOTIFER_URL}/${TOPIC}`, {
    method: "POST",
    headers,
    body: message,
  });

  if (!response.ok) {
    throw new Error(`Alert failed: ${response.status} ${response.statusText}`);
  }

  return response.json();
}

// Send an alert
await sendAlert({
  alertKey: "api-latency-high",
  message: "API p95 latency at 2.3s (threshold: 500ms)",
  priority: 2,
  tags: ["api", "latency", "performance"],
  source: "latency-monitor",
});

// Auto-resolve when latency returns to normal
await sendAlert({
  alertKey: "api-latency-high",
  message: "API p95 latency back to 120ms",
  status: "resolved",
  source: "latency-monitor",
});

Przykład automatycznego rozwiązywania

Częstym wzorcem jest wysyłanie przez skrypt monitorujący wiadomości o rozwiązaniu, gdy warunek się normalizuje. Utrzymuje to pulpit alertów w czystości bez ręcznej interwencji.

#!/bin/bash
# check_disk.sh - Run via cron every 5 minutes

THRESHOLD=85
USAGE=$(df -h /data | awk 'NR==2 {print $5}' | sed 's/%//')
TOPIC="infra-alerts"
API_KEY="noti_your_api_key_here"

if [ "$USAGE" -gt "$THRESHOLD" ]; then
  # Condition is bad -- send or update alert
  curl -s -d "Disk usage at ${USAGE}% on /data (threshold: ${THRESHOLD}%)" \
    -H "X-API-Key: $API_KEY" \
    -H "X-Alert-Key: disk-space-data" \
    -H "X-Alert-Status: open" \
    -H "X-Alert-Source: check_disk" \
    -H "X-Priority: 2" \
    -H "X-Tags: disk,storage" \
    "https://app.notifer.io/$TOPIC"
else
  # Condition is OK -- resolve any existing alert
  curl -s -d "Disk usage at ${USAGE}% on /data - back to normal" \
    -H "X-API-Key: $API_KEY" \
    -H "X-Alert-Key: disk-space-data" \
    -H "X-Alert-Status: resolved" \
    -H "X-Alert-Source: check_disk" \
    -H "X-Priority: 4" \
    -H "X-Tags: disk,storage" \
    "https://app.notifer.io/$TOPIC"
fi

Idempotentne rozwiązywanie

Wysłanie X-Alert-Status: resolved dla alertu, który jest już rozwiązany (lub nie istnieje) jest operacją bez skutku. Nie musisz śledzić stanu w swoich skryptach monitorujących -- wystarczy wysyłać odpowiedni status przy każdym sprawdzeniu.

Najlepsze praktyki

1. Używaj znaczących kluczy alertów

Klucz alertu powinien identyfikować zarówno co jest nie tak, jak i gdzie. Pozwala to mieć wiele odrębnych alertów dla tego samego typu problemu na różnych zasobach.

Dobre klucze alertów:

cpu-high-prod-web-01          # CPU issue on a specific server
disk-space-/var/log            # Disk issue on a specific mount point
healthcheck-payment-service    # Health check for a specific service
ssl-expiry-api.example.com     # SSL cert for a specific domain

Złe klucze alertów:

alert                          # Too generic -- everything deduplicates together
error                          # Not specific enough
1                              # Meaningless

2. Ustaw odpowiednie poziomy priorytetów

Priorytet alertu powinien odzwierciedlać pilność wymaganej reakcji:

Priorytet	Kiedy używać	Przykład
P1 (Krytyczny)	Produkcja niedostępna, ryzyko utraty danych	Baza danych nieosiągalna, awaria systemu płatności
P2 (Wysoki)	Pogorszona usługa, wymaga szybkiego działania	Wysokie CPU/pamięć, nieudane backupy, wysoki wskaźnik błędów
P3 (Średni)	Wymaga uwagi, nie jest pilne	Certyfikat wygasa za 7 dni, dysk na 70%
P4 (Niski)	Alert informacyjny	Przypomnienie o zaplanowanej konserwacji, drobne odchylenia konfiguracji
P5 (Informacja)	Tylko do wiadomości	Udane przywrócenie, okresowy raport stanu

3. Projektuj z myślą o deduplikacji

Pomyśl o cyklu życia warunków alertów:

• Alerty progowe (CPU > 90%): Użyj stałego klucza jak cpu-high-{serwer}. Każde sprawdzenie przekraczające próg dodaje wystąpienie. Wyślij rozwiązanie, gdy wartość spadnie poniżej progu.
• Alerty binarne (usługa działa/nie działa): Użyj klucza jak healthcheck-{usługa}. Wyślij open przy awarii, resolved przy przywróceniu.
• Alerty zdarzeniowe (awaria pipeline): Użyj klucza zawierającego identyfikator pipeline jak pipeline-{nazwa}-{branch}. Rozwiąż przy udanym uruchomieniu.

4. Zawsze dołączaj źródło

Nagłówek X-Alert-Source pomaga Twojemu zespołowi prześledzić skąd pochodzi alert, szczególnie gdy wiele systemów monitoringu zasilają ten sam temat:

-H "X-Alert-Source: prometheus"    # From Prometheus/Alertmanager
-H "X-Alert-Source: grafana"       # From Grafana alerts
-H "X-Alert-Source: check_disk"    # From a custom script
-H "X-Alert-Source: ci-pipeline"   # From CI/CD

5. Łącz tagi do filtrowania

Używaj spójnych tagów w swoich alertach, aby członkowie zespołu mogli skutecznie filtrować:

# Environment tags
-H "X-Tags: production"
-H "X-Tags: staging"

# Category tags
-H "X-Tags: cpu,server,infrastructure"
-H "X-Tags: api,latency,performance"
-H "X-Tags: database,connection,backend"

Członkowie zespołu mogą następnie skonfigurować filtry powiadomień mobilnych, aby otrzymywać powiadomienia push tylko dla określonych kombinacji tagów (np. tylko production + priorytet P1-P2).

Przykład z życia: kompletna konfiguracja monitoringu

Oto kompletna konfiguracja do monitorowania aplikacji webowej z alertami:

#!/bin/bash
# monitor.sh - Comprehensive monitoring script
# Run via cron: */2 * * * * /opt/scripts/monitor.sh

API_KEY="noti_your_api_key_here"
TOPIC="prod-alerts"
BASE_URL="https://app.notifer.io/$TOPIC"
SOURCE="monitor-script"

# Function to send alert
send_alert() {
  local key="$1" msg="$2" priority="$3" tags="$4" status="${5:-open}"
  curl -s -o /dev/null \
    -d "$msg" \
    -H "X-API-Key: $API_KEY" \
    -H "X-Alert-Key: $key" \
    -H "X-Alert-Status: $status" \
    -H "X-Alert-Source: $SOURCE" \
    -H "X-Priority: $priority" \
    -H "X-Tags: $tags" \
    "$BASE_URL"
}

# Check 1: HTTP health check
if ! curl -sf https://myapp.com/health > /dev/null 2>&1; then
  send_alert "healthcheck-myapp" "Health check failed for myapp.com" "1" "health,critical"
else
  send_alert "healthcheck-myapp" "Health check OK for myapp.com" "5" "health" "resolved"
fi

# Check 2: Disk space
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$DISK_USAGE" -gt 85 ]; then
  send_alert "disk-root" "Root disk at ${DISK_USAGE}%" "2" "disk,storage"
else
  send_alert "disk-root" "Root disk at ${DISK_USAGE}% - OK" "5" "disk,storage" "resolved"
fi

# Check 3: Memory usage
MEM_USAGE=$(free | awk '/^Mem:/ {printf("%.0f", $3/$2 * 100)}')
if [ "$MEM_USAGE" -gt 90 ]; then
  send_alert "memory-high" "Memory at ${MEM_USAGE}%" "2" "memory,server"
else
  send_alert "memory-high" "Memory at ${MEM_USAGE}% - OK" "5" "memory,server" "resolved"
fi

Następne kroki

• Tryb alertow - przegląd -- Poznaj pełny cykl życia alertów i kluczowe pojęcia
• Integracje webhook -- Połącz Alertmanager, Grafana, Datadog i inne
• Dokumentacja API -- Kompletne endpointy API alertów
• Poziomy priorytetów -- Konfiguruj progi priorytetów dla powiadomień alertów
• Klucze API -- Skonfiguruj uwierzytelnianie dla skryptów monitorujących