Infrastruktura działa. Wszystkie serwery zielone. Bazy odpowiadają. A mimo to o 09:14 rano dział obsługi klienta odbiera telefon: Nie mogę się zalogować do aplikacji. Twój monitoring nie widział nic. Ale użytkownik widział wszystko.

Infrastruktura działa, ale nie u użytkownika

To jeden z najbardziej frustrujących scenariuszy w środowisku produkcyjnym: metryki zielone, alerty milczą, dashboardy bez ostrzeżeń, a tymczasem użytkownicy nie mogą wykonać przelewu, zalogować się do portalu klienta albo złożyć zamówienia.

Incydent, który opisujemy poniżej, jest zanonimizowaną kompilacją sytuacji z rzeczywistych środowisk enterprise. Jego mechanizm jest jednak typowy i powtarzalny.

Anatomia niewidzialnego incydentu

Środowisko: aplikacja webowa w sektorze finansowym. Infrastruktura: 1200 hostów, monitoring Zabbix, Grafana jako warstwa wizualizacji. Sytuacja: o godzinie 09:00 wdrożono zmianę w module autentykacji. Zmiana przeszła bez alertów — serwery aplikacyjne działają, bazy danych również, load balancer przetwarza requesty.

O 09:14 pierwsze zgłoszenie od klienta. O 09:22 kolejne trzy. O 09:31 eskalacja do managera. Łączny czas niewidocznej degradacji: 31 minut. Czas naprawy od zgłoszenia: dodatkowe 47 minut.

Co zawiodło? Warstwa pośrednia między infrastrukturą a użytkownikiem. Formularz logowania zwracał HTTP 200, ale z komunikatem błędu wewnątrz odpowiedzi. Zabbix sprawdzał dostępność endpointu. Nie sprawdzał, czy login faktycznie działa.

Kluczowa lekcja: HTTP 200 nie znaczy “działa”. Znaczy “serwer odpowiedzial”. To zasadnicza różnica, która kosztuje dziesiątki tysięcy złotych za każdą godzinę przestoju w środowiskach mission-critical.

Czym jest monitoring syntetyczny?

Monitoring syntetyczny to symulowanie zachowania użytkownika w sposób kontrolowany i powtarzalny, zanim rzeczywisty użytkownik trafi na problem. W odróżnieniu od zwykłego monitoringu infrastruktury, który mierzy zasoby (CPU, pamięć, dostępność portów), monitoring syntetyczny odpowiada na pytanie: czy moja aplikacja działa poprawnie z perspektywy użytkownika?

Trzy filary monitoringu syntetycznego

• Symulowane transakcje — skrypty odwzorowujące realne przepływy użytkownika: logowanie, wyszukiwanie, dodanie do koszyka, finalizacja zamówienia, wysłanie formularza. Każdy krok jest weryfikowany — nie tylko dostępność, ale poprawność odpowiedzi.
• Checkery HTTP/HTTPS — cykliczne weryfikacje endpointów z walidacją kodu odpowiedzi, czasu odpowiedzi i zawartości. Najprostsze, ale już wykrywają błędy certyfikatów, przekierowania, timeouty i niedostępność.
• Testy ścieżek użytkownika (web scenario) — wieloetapowe scenariusze testujące kompletny flow biznesowy: od otwarcia strony przez wypełnienie formularza po potwierdzenie operacji.

Monitoring syntetyczny działa niezależnie od ruchu produkcyjnego. Odpala się co minutę, co 5 minut, co godzinę. Nie czeka na użytkownika, ale sam sprawdza, czy droga jest przejezdna.

Czym monitoring syntetyczny różni się od RUM?

Real User Monitoring (RUM) zbiera dane od rzeczywistych użytkowników. Jest nieoceniony, ale ze swej natury reaktywny — żeby zebrać dane, musi się najpierw coś zdarzyć.

Monitoring syntetyczny jest proaktywny: wykrywa degradację w środku nocy, przy zerowym ruchu, zanim ktokolwiek trafi na problem.

Optymalnie — oba podejścia działają razem i uzupełniają się nawzajem.

Co można testować syntetycznie — scenariusze enterprise

Monitoring syntetyczny nie jest zarezerwowany dla e-commerce. W środowiskach enterprise obejmuje krytyczne przepływy biznesowe, których awaria bezpośrednio wpływa na SLA i obsługę klienta.

Logowanie i autentykacja

• Weryfikacja formularza logowania — czy zwraca prawidłową odpowiedź, nie tylko HTTP 200
• Testowanie SSO/SAML/OAuth — czy redirect i callback działają poprawnie
• Sprawdzenie czasu autentykacji — degradacja >3s często sygnalizuje problemy z LDAP lub bazą sesji

Formularze i operacje biznesowe

• Wysłanie formularza z walidacją odpowiedzi — czy dane są przyjmowane i potwierdzane
• Wieloetapowe procesy (np. wniosek kredytowy, rejestracja konta) — test każdego kroku
• Operacje krytyczne: przelew, zamówienie, rezerwacja — z weryfikacją finalnego statusu

API i integracje

• Endpointy REST/SOAP — weryfikacja kodu, treści i czasu odpowiedzi
• Integracje z systemami zewnętrznymi (systemy płatności, rejestry) — synthetic probe przez pełną ścieżkę
• Health checki mikroserwisów — szczególnie ważne w architekturach Kubernetes

Ścieżki krytyczne w różnych sektorach

• Banki: logowanie do bankowości elektronicznej, inicjacja przelewu, sprawdzenie salda
• Telco: portal klienta, sprawdzenie faktury, zmiana usługi, zgłoszenie reklamacji
• Retail enterprise: wyszukiwanie produktu, dodanie do koszyka, przejście do kasy
• Utilities: logowanie do portalu, odczyt licznika, złożenie wniosku

Zasada: jeśli awaria danego przepływu powoduje eskalację do zarządu lub naruszenie SLA — ten przepływ powinien być pokryty testami syntetycznymi.

Monitoring syntetyczny w Zabbix — co oferuje w wersji 7.0

Zabbix 7.0 LTS (czerwiec 2024) to przełom w obszarze monitoringu syntetycznego. Wprowadza dwa uzupełniające się mechanizmy — klasyczne Web Scenarios i nowy typ elementu Browser — które razem pokrywają znacznie szersze spektrum scenariuszy niż poprzednie wersje.

HTTP/HTTPS Web Scenarios — sprawdzona warstwa podstawowa

Web Scenarios pozostają w 7.0 i nadają się do monitorowania prostych przepływów HTTP:

• Weryfikacja kodu HTTP i wymaganego ciągu znaków w odpowiedzi
• Obsługa sesji, cookies i nagłówków — np. logowanie przez POST
• Pomiar czasu odpowiedzi każdego kroku z progami alertowania
• Śledzenie certyfikatów SSL i daty ich wygaśnięcia

Zabbix 7.0 rozszerza monitoring syntetyczny o symulowanie realnych interakcji użytkownika z użyciem prawdziwej przeglądarki, testowanie dostępności, wydajności i statusów transakcji, a także obsługę Selenium WebDriver dla syntetycznego monitoringu sieciowego. 

Browser Item — nowy typ elementu z pełną obsługą przeglądarki

To najważniejsza nowość 7.0 w obszarze monitoringu syntetycznego. Browser Item zbiera dane przez uruchamianie niestandardowego kodu JavaScript i pobieranie danych przez HTTP/HTTPS — i może symulować takie akcje jak klikanie przycisków, wpisywanie tekstu, nawigację po stronach oraz inne interakcje użytkownika z witrynami i aplikacjami webowymi.

Co to oznacza w praktyce:

• Pełna obsługa JavaScript — Browser Item uruchamia prawdziwą przeglądarkę (Chrome przez Selenium WebDriver), więc aplikacje SPA (React, Angular, Vue) są monitorowane tak, jak widzi je użytkownik
• Screenshoty w momencie błędu — Browser Item jest jedyną metodą w Zabbix, która może przechwytywać wizualne zrzuty ekranu, co jest nieocenione przy diagnozowaniu problemów 
• Skrypty wieloetapowe w JavaScript — logowanie, wypełnianie formularzy, nawigacja po chronionych stronach — wszystko opisane kodem JS z pełnym dostępem do DOM
• Gotowy template „Website by Browser" — template zawiera elementy dla statystyk nawigacji i zasobów strony, aktualny screenshot witryny, wyzwalacze dla wolnych czasów ładowania i niedostępności oraz dashboard z wynikami

Co zapowiada Zabbix 8.0 (oczekiwany Q2 2026)?

Warto dodać akapit sygnalizujący kierunek — szczególnie dla czytelnika, który planuje architekturę na kolejne 2–3 lata:

• Zabbix 8.0 LTS ma ambicję skonsolidowania metryk, logów i traces w jednej platformie — z pełną integracją OpenTelemetry, zaawansowanym silnikiem przetwarzania zdarzeń (Complex Event Processing), nowym silnikiem storage zoptymalizowanym pod duże wolumeny danych strumieniowych i logów, oraz analizą logów w czasie rzeczywistym z korelacją z telemetrią.  To oznacza, że część funkcji, które dziś wymagają Elastic Stack jako osobnej warstwy, będzie dostępna natywnie w Zabbix.
• Zabbix 8.0 ma zbierać, przetwarzać i korelować metryki, logi i traces w jednym miejscu.  Dla architektury observability opisanej w artykule to istotna informacja: w perspektywie najbliższych 12–18 miesięcy granica między „Zabbix jako monitoring infrastruktury" a „Zabbix jako platforma observability" będzie się zacierać.

Pełna architektura observability: jeden widok, zero założeń

Monitoring syntetyczny to nie osobna wyspa — to jeden element spójnej architektury observability. W środowisku enterprise prawdziwa widoczność operacyjna wymaga korelacji danych z czterech warstw jednocześnie.

Warstwa 1: Monitoring syntetyczny — co widzi użytkownik

Zabbix Web Scenarios + Elastic Synthetic Monitoring. Ciągłe testy ścieżek użytkownika, co 1–5 minut, z wielu lokalizacji, z pełną walidacją funkcjonalną. Pierwsza linia detekcji: sygnalizuje, że coś nie działa z perspektywy end-user, zanim pojawią się zgłoszenia.

Warstwa 2: Elastic APM — co dzieje się po kliknięciu

Gdy monitoring syntetyczny wykryje degradację, Elastic APM pokazuje co i dlaczego: distributed tracing od requestu przez mikroserwisy do bazy danych, czas wykonania każdej transakcji, które zapytanie SQL spowalnia aplikację, który serwis upstream nie odpowiada w normie. APM dostarcza kontekst do szybkiego RCA (Root Cause Analysis).

Warstwa 3: Zabbix — infrastruktura

Metryki hostów, sieci, baz danych, wirtualizacji, Kubernetes. Zabbix widzi wszystko, co dzieje się pod warstwą aplikacji: saturację CPU, I/O wait, problemy z dyskami, przepustowość sieci. Gdy APM pokazuje wolne zapytania do bazy, Zabbix natychmiast odpowiada, czy problem leży w zasobach, czy w samej logice aplikacji.

Warstwa 4: Grafana — jeden widok, korelacja danych

Grafana jako centralna warstwa wizualizacji i alertowania. Datasource: Zabbix, Elasticsearch (APM + logi), Prometheus, bazy danych. Jeden dashboard pokazuje równocześnie: wyniki testów syntetycznych, metryki APM, dane infrastrukturalne z pełną korelacją czasową.

Praktyczny scenariusz: alert syntetyczny o degradacji formularza logowania o 09:14 → Grafana dashboard koreluje go z skokiem response time w APM → APM trace pokazuje 8-sekundowe zapytanie do bazy sesji → Zabbix potwierdza I/O wait na serwerze bazy danych → zespół ma pełny obraz RCA w 3 minuty, nie w 3 godziny.

Architektura observability — warstwy i odpowiedzialności

Podsumowanie

Monitoring syntetyczny to nie gadżet. To podstawowe zabezpieczenie każdej aplikacji krytycznej, równie ważne jak backup i plan ciągłości działania. Różnica między: infrastruktura działa a: użytkownik działa — kosztuje — w reputacji, SLA i realnych pieniądzach.

Zabbix dostarcza solidne narzędzia do podstawowego monitoringu syntetycznego — bez dodatkowych licencji, z pełną integracją w istniejący ekosystem. Dla złożonych aplikacji, SPA, wielolokalizacyjnego monitoringu i głębokiej analityki zachowania użytkownika — uzupełnienie o Elastic APM i Elastic Synthetic Monitoring daje pełny obraz.

Grafana jako warstwa korelacji zamknęła to, co wcześniej wymagało przełączania między czterema różnymi dashboardami. Jeden widok, jeden kontekst, jedna decyzja.

Efekt: z 31 minut niewidocznej degradacji i 47 minut naprawy do alertu w ciągu 90 sekund i RCA w 3 minuty. To jest różnica między monitoringiem reaktywnym a prawdziwą observability.

Chcesz wiedzieć, co widzi Twój użytkownik, zanim on to zgłosi? Porozmawiajmy!