Monitoring stron i aplikacji webowych w Zabbiksie

przeqpiciel — Thu, 23 Jul 2026 00:00:00 +0000

Trzecia część serii o Zabbiksie (poprzednie: wprowadzenie i własne szablony). Do tej pory pytaliśmy Zabbiksa “czy hosta znaczy działa” — CPU, dysk, konkretna usługa. Tym razem zapytamy inaczej: “czy strona faktycznie się ładuje tak, jak powinna, z perspektywy kogoś, kto wpisuje adres w przeglądarce”.

Od zwykłego itemu HTTP agent (który po prostu odpytuje URL) różni to jedna rzecz: Web scenario może mieć wiele kroków, wykonywanych po kolei, z zachowaniem ciasteczek między nimi. Dzięki temu da się nim zasymulować nie tylko “czy strona odpowiada”, ale też prosty przepływ użytkownika — np. wejście na stronę logowania, wysłanie formularza, sprawdzenie, czy trafiłeś na stronę po zalogowaniu.

Tworzenie scenariusza

Data collection → Hosts, wybierz hosta (albo dedykowanego, czysto “logicznego” hosta reprezentującego stronę — tak zwykle jest wygodniej niż wieszać to pod hostem serwera), zakładka Web → Create web scenario.

Na poziomie scenariusza ustawiasz m.in.:

Name — nazwa, po której będziesz go rozpoznawać w triggerach,
Update interval — jak często Zabbix ma odpalać cały scenariusz,
Agent — jaki User-Agent ma być wysyłany (przydatne, jeśli backend różnicuje odpowiedź po nagłówku).

Pierwszy krok scenariusza

Zakładka Steps → Add:

Name: Strona główna
URL: https://przyklad.local/
Required status codes: 200
Required string: (opcjonalnie) fragment tekstu, który musi wystąpić w odpowiedzi, np. </html> albo coś specyficznego dla Twojej strony — jeśli serwer zwróci 200, ale wygeneruje pustą stronę błędu, kod HTTP tego nie wychwyci, a required string tak,
Timeout: 5s.

Jeśli chcesz zasymulować logowanie, dodaj drugi krok wskazujący na endpoint formularza, z wypełnionymi polami POST w sekcji Post fields (np. username=demo&password=demo) i kolejnym Required string sprawdzającym coś, co pojawia się tylko po zalogowaniu.

⚠️

Nie trzymaj w konfiguracji Zabbiksa prawdziwych, produkcyjnych danych logowania — załóż osobne, ograniczone konto testowe wyłącznie do monitoringu.

Co Zabbix mierzy sam z siebie

Po zapisaniu scenariusza, bez dodatkowej konfiguracji, w Monitoring → Latest data zaczną się pojawiać m.in.:

czas odpowiedzi każdego kroku,
kod odpowiedzi HTTP każdego kroku,
prędkość pobierania,
liczba kroku, na którym scenariusz ostatnio zawiódł (0 = wszystko OK).

Te dane są też dostępne jako klucze itemów, których możesz użyć bezpośrednio w wyrażeniach triggerów — nie musisz ręcznie dodawać dla nich osobnych itemów.

Trigger na porażkę scenariusza

Data collection → Hosts → Triggers (dla hosta, pod którym wisi scenariusz) → Create trigger:

Name: Scenariusz "{ITEM.VALUE}" zawiódł
Severity: High
Expression:

last(/Host/web.test.fail[Strona główna])>0

web.test.fail[<nazwa scenariusza>] zwraca numer kroku, na którym scenariusz się wysypał — 0, gdy wszystko przeszło. Jeśli zależy Ci konkretnie na czasie odpowiedzi, a nie samym sukcesie/porażce, dorzuć drugi trigger na konkretny krok:

avg(/Host/web.test.time[Strona główna,Strona główna],5m)>2

Ten drugi trigger zaalarmuje, gdy średni czas odpowiedzi z ostatnich 5 minut przekroczy 2 sekundy — czyli zanim strona całkiem przestanie działać, ale gdy już zauważalnie zwalnia.

Podsumowanie

Web scenario to w praktyce syntetyczny monitoring — Zabbix sam, regularnie, odgrywa rolę użytkownika i mówi Ci, zanim dowiesz się tego od kogoś innego, że coś na stronie przestało działać. W kolejnej części serii podepniemy powiadomienia pod coś innego niż e-mail — webhooki, m.in. w kierunku komunikatorów.