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.

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.