Jak projektować monitoring (use-case driven)” w Zabbix

Współczesne systemy IT generują ogromne ilości danych: metryki, logi, trace’y, alerty. Paradoksalnie, im więcej monitorujemy, tym trudniej odpowiedzieć na najważniejsze pytanie – czy system faktycznie działa tak, jak oczekują użytkownicy i biznes. Tradycyjne podejście, oparte na obserwowaniu infrastruktury i pojedynczych komponentów, coraz częściej okazuje się niewystarczające w świecie rozproszonych aplikacji, mikroserwisów i złożonych zależności.

W odpowiedzi na te wyzwania pojawia się podejście use-case driven, które odwraca sposób myślenia o monitoringu. Zamiast zaczynać od technicznych metryk, punktem wyjścia stają się konkretne scenariusze użytkownika i cele biznesowe. To one definiują, co należy mierzyć, kiedy reagować i jakie dane są naprawdę istotne. Monitoring przestaje być zbiorem przypadkowych wykresów, a zaczyna pełnić rolę systemu wspierającego decyzje operacyjne i biznesowe.

W artykule pokazano, jak projektować monitoring w oparciu o rzeczywiste use-case’y, jak łączyć perspektywę techniczną z biznesową oraz jak wykorzystać koncepcje takie jak SLO, SLA i error budget w praktyce. Szczególną uwagę poświęcono temu, co warto monitorować, a co świadomie pominąć, aby uniknąć szumu informacyjnego i skupić się na tym, co ma realną wartość.

 

 

1. Use-case jako fundament konfiguracji Zabbixa

1.1 Od hostów do scenariuszy

Standardowy model:

• host → item → trigger

Model use-case driven:

• use-case → sygnały → implementacja w Zabbix

---

1.2 Przykład: logowanie użytkownika

Use-case:

„Użytkownik może zalogować się w mniej niż 2 sekundy”

Jak odwzorować to w Zabbix:

Itemy:

• HTTP response time (web scenario)
• HTTP status code
• liczba błędów logowania (log monitoring)

Trigger:

• response time > 2s
• HTTP != 200
• spike błędów logowania

Web scenario (kluczowe w Zabbix):

• symulacja logowania użytkownika
• pełna ścieżka: login → redirect → dashboard

To jest serce podejścia use-case w Zabbix.

---

2. Web scenarios jako monitoring doświadczenia użytkownika

Jedna z najmocniejszych funkcji Zabbix to Web Scenarios.

2.1 Dlaczego są kluczowe

Zamiast monitorować komponenty:

• monitorujesz cały proces

Np.:

• logowanie
• checkout
• API flow

---

2.2 Co mierzyć w web scenarios

• czas odpowiedzi każdego kroku
• całkowity czas scenariusza
• poprawność odpowiedzi (regex)
• kody HTTP

---

2.3 Przykład: checkout

Kroki:

1. dodanie do koszyka
2. przejście do płatności
3. potwierdzenie

Trigger:

• którykolwiek krok failuje
• czas całkowity > X sekund

To jest monitoring biznesowy w praktyce.

---

3. Monitoring techniczny vs biznesowy w Zabbix

3.1 Monitoring techniczny (klasyczny)

• CPU load
• memory usage
• disk space
• network

Zabbix robi to świetnie:

• template’y
• auto-discovery
• agent

---

3.2 Monitoring biznesowy (często pomijany)

W Zabbix można go realizować przez:

• custom itemy (np. API)
• external checks
• trapper items
• calculated items

---

3.3 Przykłady metryk biznesowych

• liczba zamówień (API)
• liczba aktywnych użytkowników
• conversion rate (obliczany item)
• liczba błędnych transakcji

Dane trafiają do Zabbixa jak każda metryka.

---

3.4 Korelacja w praktyce

Scenariusz:

• spadek liczby zamówień
• brak alertów CPU

Zabbix:

• dashboard pokazuje oba wskaźniki
• trigger oparty o biznes (np. spadek o 30%)

dopiero wtedy monitoring ma sens biznesowy

2. Szybsze diagnozowanie problemów

Zamiast:

„CPU ma 90%”

Masz:

„Użytkownicy nie mogą złożyć zamówienia”

To zmienia sposób działania zespołu:

• mniej zgadywania,
• więcej kontekstu,
• krótszy MTTR (Mean Time To Repair).

---

3.5 Lepsza komunikacja z biznesem

Biznes nie rozumie:

• IOPS
• latency P99
• GC pauses

Biznes rozumie:

• „20% transakcji nie przechodzi”
• „czas ładowania przekroczył 3 sekundy”

---

3.6 Optymalizacja kosztów monitoringu

Logowanie wszystkiego = ogromne koszty (storage, ingest, analiza).

Podejście use-case driven pozwala:

• logować selektywnie,
• agregować dane,
• usuwać zbędne metryki.

---

Nowy twist: monitoring biznesowy vs techniczny

Monitoring techniczny

Dotyczy infrastruktury i komponentów:

• CPU, RAM, disk
• health checki
• dostępność usług

Odpowiada na pytanie: „czy system działa?”

---

3.7 Monitoring biznesowy

Dotyczy wartości dostarczanej użytkownikowi:

• liczba zamówień
• konwersja
• przychód
• liczba aktywnych użytkowników

Odpowiada na pytanie: „czy system działa dla biznesu?”

---

Kluczowa różnica

Monitoring techniczny	Monitoring biznesowy
system działa	użytkownik osiąga cel
metryki infrastruktury	metryki wartości
reaktywny	strategiczny

---

Dlaczego oba są potrzebne?

Monitoring techniczny:

• wykrywa przyczynę

Monitoring biznesowy:

• wykrywa problem

Najlepsze systemy łączą oba podejścia:
spadek sprzedaży → korelacja → błędy API → przeciążenie DB

---

4. SLA, SLO, SLI — hierarchia zobowiązań

Te trzy skróty są często mylone. Ich relacja jest prosta: SLI to to, co mierzysz. SLO to cel, do którego dążysz. SLA to kontrakt, który podpisujesz z klientem.

Termin	Co to jest?	Przykład	Adresat
SLI	Service Level Indicator — konkretna, mierzona metryka	% requestów z response <200ms z ostatnich 28 dni	Inżynierowie
SLO	Service Level Objective — wewnętrzny cel dla SLI	99.5% requestów powinno odpowiedzieć w <200ms	Zespół + management
SLA	Service Level Agreement — zewnętrzne zobowiązanie z konsekwencjami	Gwarantujemy 99.9% uptime, inaczej zwrot 10% opłaty	Klienci + legal

Kluczowa zasada: SLO powinno być bardziej restrykcyjne niż SLA. Jeśli zobowiązujesz się do 99.9% w SLA, twój wewnętrzny cel powinien wynosić 99.95% — żebyś miał zapas na naprawę zanim klient poczuje naruszenie umowy.

SLA, SLO i co z tego wynika dla monitoringu

SLO w Zabbix – jak to zrobić praktycznie

Definiowanie SLO

Przykład:

• 99.9% dostępności API

---

4.1 Implementacja

Zabbix nie ma natywnego SLO jak systemy SRE, ale można to zbudować:

Metody:

• calculated items
• SLA reporty
• agregacja danych historycznych

---

Availability jako SLI

Zabbix oferuje:

• availability per host
• availability per service

można to traktować jako SLI

---

4.2 Error budget – jak podejść

W praktyce:

• liczysz % downtime
• porównujesz do SLO
• alertujesz przy przekroczeniu progu

---

4.3 Projektowanie triggerów – mniej, ale lepiej

Zasada: trigger = akcja

Jeśli alert:

• nie wymaga reakcji
  usuń go

---

4.4 Typy triggerów w Zabbix

1. Threshold-based

• CPU > 90%

2. Trend-based

• wzrost błędów

3. Anomaly-like (manualne)

• deviation od średniej

---

Najlepsze praktyki

• używaj zależności triggerów (dependency)
• unikaj duplikatów
• agreguj alerty

---

5. Co monitorować w Zabbix (use-case driven)

5.1 Krytyczne ścieżki

• web scenarios
• API checks
• synthetic monitoring

---

5.2 Zależności

• DB (connection, query time)
• cache
• kolejki

---

5.3 Infrastruktura

• CPU, RAM → ale jako kontekst
• nie jako główny sygnał

---

5.4 Logi

Zabbix potrafi:

• analizować logi
• wykrywać błędy
• triggerować alerty

często niedoceniane

---

5.5 Czego nie robić w Zabbix

„Template everything”

• tysiące itemów
• brak kontekstu

---

5.6 Alert storm

• brak korelacji
• brak dependency

---

5.7 Monitoring bez dashboardów

Dane bez wizualizacji:
bezużyteczne

---

6. Dashboardy jako narzędzie decyzyjne

6.1 Dwa poziomy dashboardów

Operacyjny

• alerty
• status usług

Biznesowy

• metryki KPI
• trendy

---

6.2 Co powinien zawierać dobry dashboard

• status use-case (zielony/czerwony)
• SLO
• kluczowe metryki
• kontekst (np. DB latency)

---

6.3 Automatyzacja i skalowanie

Template’y

• standaryzacja
• reuse

---

6.4 Low-Level Discovery (LLD)

• automatyczne wykrywanie:
  • dysków
  • interfejsów
  • usług

---

6.5 Integracje

Zabbix może integrować się z:

• systemami ticketowymi
• Slack / email
• webhookami

6.6 NIE monitoruj:

1. Wszystkiego „na wszelki wypadek”

To prowadzi do:

• chaosu,
• wysokich kosztów,
• braku sygnału.

---

2. Metryk bez kontekstu

Np.:

• „CPU 80%” → i co z tego?

Bez powiązania z use-case:
bezużyteczne

---

3. Nieużywanych dashboardów

Jeśli nikt na to nie patrzy:

• usuń albo uprość

---

4. Alertów bez akcji

Każdy alert powinien mieć:

• właściciela,
• runbook,
• jasno określoną reakcję.

---

7. Dobre praktyki projektowania monitoringu

1. Monitoring jako kod

• dashboardy w repozytorium,
• alerty wersjonowane,
• review jak w kodzie.

---

2. Korelacja danych

• metryki + logi + trace’y
• jeden kontekst incydentu

Tu świetnie sprawdza się OpenTelemetry jako standard zbierania danych.

---

3. Iteracyjne podejście

Monitoring to nie projekt jednorazowy:

• zmienia się system,
• zmienia się biznes,
• zmieniają się use-case’y.

---

4. Runbooki do alertów

Alert bez instrukcji = strata czasu.

Każdy alert powinien mieć:

• opis problemu,
• możliwe przyczyny,
• kroki diagnostyczne,
• działania naprawcze.

---

5. Testowanie monitoringu

• symuluj awarie,
• sprawdzaj alerty,
• upewnij się, że działają.

---

Podsumowanie

Podejście use-case driven w monitoringu to przejście z poziomu „mierzymy wszystko” do „mierzymy to, co ma znaczenie”. Kluczowe jest powiązanie technicznych sygnałów z realnym doświadczeniem użytkownika i celami biznesowymi.

Największą wartość daje połączenie monitoringu technicznego i biznesowego, opartego o dobrze zdefiniowane SLO i kontrolę error budżetu. W praktyce oznacza to mniej alertów, szybsze diagnozy i realny wpływ na jakość usług – zamiast jedynie obserwowania infrastruktury.

Monitoring należy projektować od strony scenariuszy biznesowych (use-case’ów), a nie od listy narzędzi czy metryk. Każdy scenariusz powinien mieć jasno określony cel, mierzalny wynik oraz próg akceptowalności, a dopiero na tej podstawie dobiera się odpowiednie sygnały: metryki, logi i trace’y.

Dla każdego use-case’u definiuje się konkretne wskaźniki (np. czas odpowiedzi, poziom błędów, zależności systemowe), często korzystając z modelu Golden Signals (latency, traffic, errors, saturation), które pełnią rolę narzędzia wspierającego analizę, a nie celu samego w sobie.

Podejście to odwraca klasyczny model monitoringu – zamiast skupiać się na parametrach infrastruktury (CPU, RAM, uptime), koncentruje się na doświadczeniu użytkownika i wpływie na biznes. Dzięki temu możliwe jest ograniczenie liczby nieistotnych alertów, szybsze diagnozowanie problemów oraz lepsza komunikacja z biznesem. Dodatkowo pozwala zoptymalizować koszty poprzez selektywne zbieranie danych.

Rozróżnia się monitoring techniczny (czy system działa) oraz biznesowy (czy dostarcza wartość użytkownikowi). Oba podejścia są komplementarne – pierwszy pomaga znaleźć przyczynę problemu, drugi wykrywa jego realny wpływ.

Kluczową rolę odgrywają pojęcia SLA, SLO i SLI, gdzie SLO stanowi fundament monitoringu, a jego uzupełnieniem jest kontrola tzw. error budgetu. Monitoring powinien skupiać się na krytycznych ścieżkach użytkownika, zależnościach systemowych, wskaźnikach SLO oraz anomaliach, unikając zbierania nadmiarowych danych i metryk bez kontekstu.

Dobre praktyki obejmują traktowanie monitoringu jako kodu, korelację danych z różnych źródeł, podejście iteracyjne, tworzenie runbooków do alertów oraz regularne testowanie systemu monitoringu.

Całość prowadzi do bardziej efektywnego systemu, w którym mierzone są tylko istotne aspekty działania usług, co przekłada się na mniejszy szum alertów, szybsze reakcje i realny wpływ na jakość działania systemów.