Monitoring e-commerce z Zabbix, Docker i Chrome - darmowe narzędzia, realne korzyści dla Twojego sklepu internetowego

Dlaczego tradycyjny monitoring sklepu internetowego już nie wystarcza

Każdy sklep internetowy, niezależnie od skali działania, mierzy się z pozornie „niewidocznymi” błędami, które bezpośrednio wpływają na sprzedaż. W praktyce e-commerce najczęściej doświadcza sytuacji takich jak:

Strona zwraca kod 200, ale koszyk nie działa.
Formularz zamówienia kończy się błędem, choć serwer raportuje pełną dostępność.
Nagle „wysypuje się” checkout, a zespół dowiaduje się o tym dopiero po skargach klientów.
Promocje nie wyświetlają się poprawnie, a ceny pobierają błędne wartości.
Strona działa wolno tylko pod obciążeniem, co monitoring uptime’owy ignoruje.
Brakuje pewnej odpowiedzi na proste pytanie: „Kiedy dokładnie sklep nie działał i ile nas to kosztowało?”

To problemy, których klasyczne systemy monitoringu nie potrafią wykryć, ponieważ koncentrują się na serwerze, a nie na tym, czy klient może zrobić zakupy.

Dlatego nowoczesne e-commerce potrzebują monitoringu syntetycznego, rozwiązania, które naśladuje prawdziwe działania użytkownika i sprawdza sklep dokładnie tak, jak robi to klient.

Dziś taki monitoring nie musi kosztować tysięcy złotych.

Można go wdrożyć w całości na darmowych narzędziach open-source, takich jak:

Zabbix
Docker
Chrome / Chromium
Selenium WebDriver

W połączeniu dają one funkcjonalność zbliżoną do Dynatrace Synthetic, Pingdom Transaction i NewRelic Browser tylko bez żadnych kosztów licencyjnych.

Czym jest monitoring syntetyczny?

Monitoring syntetyczny to metoda testowania działania sklepu internetowego poprzez symulację zachowania realnego użytkownika. System nie pyta serwera „czy żyjesz?”, tylko wykonuje konkretne kroki, tak jak robią to Twoi klienci:

wejście na stronę,
przeglądanie produktów,
dodanie do koszyka,
przejście do kasy,
logowanie do konta,
potwierdzenie zamówienia.

Dzięki temu monitoring pokazuje nie tylko, czy strona odpowiada, ale czy cały proces zakupowy działa poprawnie - od pierwszego kliknięcia aż po finalizację transakcji.

Różnica względem zwykłego monitoringu HTTP jest fundamentalna:

Zwykły monitoring sprawdza, czy działa serwer.
Monitoring syntetyczny sprawdza, czy sklep zarabia pieniądze.

To podejście skupia się na tym, co naprawdę widzi klient i co bezpośrednio wpływa na konwersję, sprzedaż i reputację sklepu.

monitoring ecommerce zabbix docker chrome1

Najczęstsze problemy e-commerce, które wykrywa monitoring syntetyczny

Wiele błędów krytycznych w sklepach internetowych nie pojawia się w logach, a mimo to blokuje możliwość dokonania zakupu. Monitoring syntetyczny wyłapuje je natychmiast, bo obserwuje stronę tak, jak widzi ją klient.

Najczęściej są to:

koszyk nie działa mimo kodu 200
checkout nie ładuje się przez błąd JS
płatności nie przechodzą
zniknięty przycisk „Kup teraz”
błędne ceny po integracji ERP
brak promocji na froncie
wolne ładowanie strony → spadek konwersji
niedziałające logowanie klientów
problemy z cache, sesjami, Redisem
awarie pojawiające się tylko pod obciążeniem

To problemy krytyczne, bo uderzają bezpośrednio w sprzedaż, a klasyczny monitoring ich nie widzi. Derwer może odpowiadać prawidłowo, podczas gdy użytkownik… nie może dokończyć zakupu.

Jak działa monitoring e-commerce oparty na Zabbix, Docker i Chrome? I dlaczego to obecnie najlepsze rozwiązanie?

Aby skutecznie monitorować sklep internetowy, potrzeba narzędzia, które nie tylko „sprawdza stronę”, ale potrafi zachować się jak klient – wejść na stronę, kliknąć przycisk, przejść przez checkout i zarejestrować każdy detal błędu.

Taką możliwość daje zestaw:

Zabbix (silnik monitoringu i automatyzacji),
Docker (izolowane, kontenerowe środowisko uruchomieniowe),
Chrome/Chromium (prawdziwa przeglądarka działająca headless),
Selenium WebDriver (steruje przeglądarką).

To rozwiązanie jest jednocześnie bardzo zaawansowane technicznie i w 100% darmowe, także do zastosowań komercyjnych.

Zabbix Browser Item: jak działa monitorowanie przeglądarkowe w e-commerce

W wersjach 6.4+, Zabbix wprowadził funkcję Browser Item, która umożliwia sterowanie prawdziwą przeglądarką przez Selenium WebDriver.

Co to oznacza?

Zabbix potrafi:

klikać przyciski,
wypełniać pola formularzy,
wykonywać pełne scenariusze zakupowe,
robić screenshoty błędów,
mierzyć Web Vitals i performance front-endu,
walidować treści, ceny i promocje,
wykrywać problemy w logowaniu, koszyku i checkout,
uruchamiać akcje naprawcze (autoremediacja),
wyliczać SLA dla procesów biznesowych, nie tylko serwera.

Czyli: Zabbix nie tylko wykrywa błędy, on potrafi je również naprawić. To poziom znany z drogich systemów typu Dynatrace Synthetic, ale uzyskany wyłącznie na open-source.

Docker w monitoringu syntetycznym - stabilne i izolowane środowisko dla Chrome Headless

Aby monitoring syntetyczny był wiarygodny, przeglądarka wykonująca testy musi działać stabilnie, powtarzalnie i w identycznych warunkach za każdym razem. Właśnie to gwarantuje Docker.

Chrome w trybie headless uruchamiamy w kontenerze:

docker run -d --name selenium_chrome -p 4444:4444 -p 7900:7900 \
--shm-size="2g" selenium/standalone-chrome:latest

Dlaczego Docker jest kluczowy w monitoringu syntetycznym?

testy działają identycznie w każdym środowisku
restart kontenera = czyste środowisko w 2 sekundy
testy nie obciążają bezpośrednio serwera Zabbix
możliwość skalowania (np. 10 równoległych Chrome dla różnych scenariuszy)
stała, przewidywalna konfiguracja
odporność na zmiany w systemie
idealne do dużych kampanii (Black Friday)

W praktyce: jedną komendą możemy uruchomić równolegle wiele testów koszyka, checkoutu, logowania, promocji i cen.

Selenium WebDriver: ręce i oczy Zabbixa w monitoringu syntetycznym

Selenium WebDriver sprawia, że Zabbix nie zgaduje, czy sklep działa, on wykonuje realne akcje w przeglądarce, dokładnie tak jak użytkownik. Zabbix wysyła do Chrome polecenia typu: znajdź element, kliknij, wpisz tekst, przejdź do kolejnej strony, pobierz wartość, zrób screenshot.

Przykładowy fragment skryptu pokazujący logowanie:

el = browser.findElement("xpath", "//input[@id='login']");
el.sendKeys(params.username);

el = browser.findElement("xpath", "//input[@id='password']");
el.sendKeys(params.password);

el = browser.findElement("xpath", "//button[@id='loginButton']");
el.click();

Co potrafi wykryć WebDriver

błędy JS blokujące checkout
niewidoczne elementy DOM
brak przycisku „Kup teraz”
błędne ceny
brak promocji
brak metod płatności
problemy z logowaniem
białe ekrany / CSS / layout
wolne ładowanie strony pod obciążeniem

Monitoring syntetyczny z WebDriverem to jak tester QA, który pracuje 24/7 zawsze tak samo i zawsze dokładnie.

Architektura rozwiązania SparkSome: Zabbix + Docker + Chrome

W SparkSome projektujemy monitoring e-commerce tak, aby zachowywał się jak realny klient, a jednocześnie był stabilny, skalowalny i odporny na przeciążenia.

Dzięki temu system nie tylko wykrywa awarie, on utrzymuje sprzedaż nawet w momentach największego ruchu.

Całość opiera się na trzech współpracujących warstwach uruchamianych w kontenerach Docker:

Zabbix Server → Chrome Headless → Selenium WebDriver

To nie jest przypadkowy zestaw technologii. Jest to rezultat setek godzin wdrożeń w środowiskach:

WooCommerce,
Magento 2,
PrestaShop,
Shopify (w tym Headless),
systemach customowych,
kampaniach wysokiego obciążenia (Black Friday, flash sale, dropy).

Każda warstwa pełni określoną funkcję, a razem tworzą kompletny system, który:

klika po sklepie jak użytkownik,
mierzy UX i Web Vitals,
analizuje backend,
wykrywa błędy w czasie rzeczywistym,
robi screenshoty,
automatycznie reaguje (self-healing),
raportuje realne SLA procesu zakupowego.

Poniżej opisujemy szczegółowo, jak działa każdy element.

1. Zabbix Server - centrum dowodzenia i analityki

To mózg całego rozwiązania. Zabbix, uruchamiany w lekkim i łatwo skalowalnym kontenerze Docker, odpowiada za:

planowanie scenariuszy syntetycznych (np. co 5 minut pełna ścieżka zakupowa),
analizowanie każdego kroku użytkownika,
zbieranie metryk Web Vitals,
alertowanie wieloma kanałami (SMS, Telegram, WhatsApp, e-mail),
wykonywanie automatycznych akcji naprawczych (self-healing),
wyliczanie SLA procesu zakupowego,
korelację danych UX z infrastrukturą (PHP-FPM, Redis, DB, API).

Najważniejsze: To Zabbix decyduje, kiedy sprzedaż jest zagrożona i kiedy trzeba reagować. Nie patrzymy na uptime serwera, patrzymy na to, czy klient jest w stanie kupić produkt.

2. Docker + Chrome Headless to izolowana i skalowalna warstwa testowa

Tu działa prawdziwa przeglądarka Chrome, która wykonuje kroki użytkownika w sposób stabilny i powtarzalny. Uruchamiamy ją w kontenerach Dockera, dzięki czemu:

środowisko testowe jest w pełni izolowane,
testy nie obciążają Zabbix Server,
można uruchomić wiele przeglądarek równolegle (Selenium Grid),
konfiguracja Chrome jest zawsze identyczna, niezależnie od serwera,
restart kontenera daje czyste środowisko w kilka sekund,
działa w każdym środowisku: Linux, VPS, chmura, K8s, bare metal.

W praktyce: Jedną komendą uruchamiamy 10–20 równoległych przeglądarek, a każda realizuje inny scenariusz: koszyk, checkout, logowanie, płatności, ceny, promocje.

To zapewnia pełną obserwowalność sklepu 24/7, nawet przy dużym ruchu.

3. Selenium WebDriver jako ręce i oczy Zabbixa

To warstwa, która sprawia, że Zabbix nie tylko „sprawdza stronę” on wykonuje realne akcje w przeglądarce tak jak prawdziwy użytkownik.

Przykład logowania:

el = browser.findElement("xpath", "//input[@id='login']");
el.sendKeys(params.username);

el = browser.findElement("xpath", "//input[@id='password']");
el.sendKeys(params.password);

el = browser.findElement("xpath", "//button[@id='loginButton']");
el.click();

WebDriver potrafi wykryć m.in.:

błędy JS blokujące checkout,
niewidoczne / znikające elementy DOM,
brak przycisku „Dodaj do koszyka” lub „Kup teraz”,
błędne ceny i promocje,
brak metod płatności,
problemy z logowaniem,
białe ekrany, błędy CSS,
spowolnienia pod obciążeniem,
niespójności między backendem a front-endem.

W praktyce: To jak automatyczny tester QA, który pracuje 24/7 z niezmienną precyzją.

Symulacja procesu zakupowego

Sercem monitoringu syntetycznego jest scenariusz użytkownika, który naśladuje pełen proces zakupowy:

wejście na stronę,
wybór produktu,
dodanie do koszyka,
przejście do checkoutu,
finalizacja transakcji.

Nie jest to „suche zapytanie HTTP”, tylko faktyczne działanie w przeglądarce. Przykład skryptu w Zabbix Browser:

browser.navigate("https://sklep.pl");
browser.collectPerfEntries("load");

// Dodanie do koszyka
el = browser.findElement("xpath", "//button[text()='Dodaj do koszyka']");
if (el === null) throw Error("Brak przycisku Dodaj do koszyka");
el.click();

// Przejście do checkoutu
el = browser.findElement("xpath", "//a[text()='Przejdź do kasy']");
if (el === null) throw Error("Checkout niedostępny");
el.click();

Co tu się dzieje technicznie i biznesowo?

browser.navigate(...) Chrome naprawdę otwiera stronę sklepu.
collectPerfEntries(...) zbierane są metryki wydajności i Web Vitals.
findElement(...) Zabbix szuka elementów kluczowych dla konwersji.
click() wykonuje kliknięcie identyczne jak klient.
throw Error(...) jeśli elementu nie ma → klient nie może kupić → alarm.

Dzięki temu monitoring nie sprawdza tylko, czy strona działa tylko sprawdza, czy działa proces sprzedaży.

Jeśli choć jeden krok nie działa poprawnie, wiemy od razu, że w danym momencie: klient nie jest w stanie zrealizować zamówienia. A to oznacza realną utratę przychodu.

Screenshoty to najważniejsze narzędzie diagnostyczne w e-commerce

Gdy test syntetyczny wykryje błąd, kluczowe jest nie tylko „czerwone światło”, ale odpowiedź na pytanie:

„Co dokładnie zobaczył klient w momencie problemu?”

To właśnie screenshot daje tę informację.

Najczęstsze sytuacje, które screenshot ujawnia:

brak elementu (np. nie pojawił się przycisk „Kup teraz”),
wyjątek JavaScript blokujący renderowanie strony,
biały ekran (white screen of death),
rozjechany layout po błędzie CSS,
niewidoczny lub błędny baner promocyjny,puste pole ceny, 0,00 zł, „NaN”,
częściowo załadowany checkout lub brak metod płatności.

W takich sytuacjach skrypt zapisuje zrzut ekranu:

result.error.screenshot = browser.getScreenshot();

Gdzie trafiają screenshoty?

do dashboardu Zabbixa (w historii incydentów),
do powiadomień alarmowych (e-mail, SMS, Telegram, WhatsApp),
do raportów SLA i post-mortem,
do analizy wdrożeń (np. po deploymencie nowej wersji).

Dlaczego screenshoty są kluczowe w diagnozie błędów e-commerce??

1. Oszczędzają godziny diagnozy

Developer lub administrator widzi od razu konkretny obraz błędu, więc nie musi próbować go odtwarzać ręcznie.

2. Eliminują nieporozumie nia

Marketing, e-commerce, IT - wszyscy widzą to samo, co klient. Nie ma „u mnie działa”.

3. Pokazują prawdziwy wpływ błędu na sprzedaż

Nie każdy błąd techniczny jest widoczny w metrykach - screenshot pokazuje, czy klient mógł kliknąć, zobaczyć, kupić.

4. Ułatwiają analizę regresji po wdrożeniach

Po deploymencie szybko widać, czy CSS, JS, integracje lub treści nie „rozsypały się”.

5. Są dowodem, także w raportach dla zarządu

Przydają się przy:

uzasadnianiu kosztów wdrożeń,
wyjaśnianiu spadków konwersji,
analizie incydentów podczas kampanii.

W praktyce screenshot = najszybsza diagnoza

W wielu incydentach screenshot jest najbardziej wiarygodnym i obiektywnym dowodem awarii. Często jedynym, który pokazuje faktyczne doświadczenie użytkownika.

Web Vitals w e-commerce – dlaczego szybkość ładowania decyduje o konwersji?

W e-commerce nie wystarczy, aby sklep „działał”. On musi działać szybko, przewidywalnie i stabilnie, bo nawet niewielkie opóźnienia w ładowaniu strony wpływają bezpośrednio na konwersję, porzucenia koszyka oraz skuteczność kampanii marketingowych.

Monitoring syntetyczny Zabbixa pozwala mierzyć kluczowe metryki wydajności front-endu, tzw. Web Vitals, dokładnie te same, które ocenia Google. Należą do nich:

Largest Contentful Paint (LCP) – moment, w którym pojawia się główny element strony (np. zdjęcie produktu).
First Input Delay (FID) – czas, po którym strona reaguje na pierwsze kliknięcie.
Time To Interactive (TTI) – kiedy strona staje się w pełni używalna i przestaje blokować interakcje.
DOMContentLoaded – czas zakończenia budowy struktury dokumentu przez przeglądarkę.
Czasy ładowania zasobów – CSS, JS, grafik, fontów oraz requestów API.

To jednak dopiero początek. Zabbix może zbierać również bardziej szczegółowe dane z przeglądarki, dzięki czemu diagnoza staje się precyzyjna i jednoznaczna:

Czas pełnego załadowania strony (load event / navigation.load_finished) – ile ms mija od wejścia na stronę do jej pełnego załadowania.
DOM Content Loaded Time (dom_content_loaded_time) – jak szybko przeglądarka zbudowała DOM, co wpływa na odczucie „szybkości”.
Resource Fetch Time – ile trwało pobranie poszczególnych zasobów (JS, CSS, grafik, fontów, API).
First Paint / First Contentful Paint (FP/FCP) – kiedy użytkownik zaczyna „coś widzieć”, nawet jeśli strona jeszcze nie działa w pełni.

monitoring ecommerce zabbix docker chrome2

Dlaczego Web Vitals są tak ważne dla sprzedaży?

Każda 1 sekunda opóźnienia może obniżyć konwersję nawet o kilkanaście procent.
Dzięki Web Vitals i dodatkowym metrykom performance widzisz dokładnie:

która wtyczka, skrypt lub integracja spowalnia sklep,
po której zmianie front-endu pogorszył się UX,
czy wersja mobilna nie ładuje się wolniej niż desktop,
czy kampania (np. Black Friday) nie obciąża strony ciężkimi grafikami lub skryptami,
czy problem wynika z front-endu, backendu, czy infrastruktury.

Dzięki temu decyzje o optymalizacji nie są oparte na opiniach („klienci mówią, że muli”), ale na konkretnych danych wpływających na realne przychody.

Monitoring syntetyczny zamienia wydajność sklepu w twardą, mierzalną metrykę biznesową, a nie wrażenie użytkownika.

Walidacja treści (Content Validation) - techniczne działanie i realne zastosowania

Monitoring syntetyczny nie ogranicza się do klikania jak użytkownik. W SparkSome wykorzystujemy go także jako mechanizm automatycznej walidacji treści (Content Validation), który działa na poziomie DOM i pozwala wykrywać błędy niewidoczne dla backendu.

Technicznie wygląda to tak:

skrypt otwiera stronę w Chrome Headless,
pobiera treści z konkretnych elementów (CSS/XPath),
porównuje wartości z oczekiwanym wzorcem,
rzuca wyjątek, jeśli dane są nieprawidłowe,
Zabbix zapisuje błąd i robi screenshot.

Przykład skryptu kontrolującego ceny:

el = browser.findElement("css", ".price");
price = el.getText();
if (price === "0,00 zł" || price === "" || price === "NaN") {
    throw Error("Wykryto błędną cenę produktu");
}

Co możemy wykryć technicznie?

błędne ceny wynikające z problemów integracyjnych (ERP ↔ sklep),
brak promocji spowodowany błędem kampanii, cache lub CDN,
niewyrenderowane banery przez JS/CSS,
rozbieżności danych między backendem a front-endem,
nieprawidłową dostępność produktu (np. produkt wyprzedany, ale nadal „dostępny”),
niepoprawne renderowanie etykiet promocyjnych, które zależą od logiki front-endowej.

Standardowy monitoring potwierdza jedynie, że serwer działa i zwrócił prawidłową odpowiedź (kod 200). Nie pokazuje jednak, czy strona wyświetla się poprawnie, a klient może faktycznie zrobić zakupy - to wykrywa dopiero monitoring syntetyczny.

Dlaczego Content Validation jest tak opłacalne?

Bo łączy techniczną precyzję ze skutkami biznesowymi:

chroni przed sprzedażą po błędnej cenie,
gwarantuje, że kampanie promocyjne są widoczne,
dba o spójność komunikacji marketingowej,
monitoruje integralność danych między ERP / PIM / systemami cenowymi a front-endem,
zapobiega poważnym wpadkom (np. „darmowy produkt przez pomyłkę”).

To pełny, automatyczny audit front-endu - 24/7, bez udziału człowieka.

Monitorowanie logowania klientów - techniczna kontrola funkcji premium

W SparkSome testujemy logowanie nie jako „czy endpoint /login działa”, ale jako pełny przepływ użytkownika:

przejście na stronę logowania,
wypełnienie pól formularza,
kliknięcie „Zaloguj”,
weryfikacja elementów DOM w panelu użytkownika.

Skrypt wykorzystuje bezpieczne makra Zabbixa:

el = browser.findElement("xpath", "//input[@id='login']");
el.sendKeys(params.username);

el = browser.findElement("xpath", "//input[@id='password']");
el.sendKeys(params.password);

Następnie sprawdza, czy pojawiło się np.:

imię użytkownika,
liczba punktów,
lista zamówień.

Jeśli elementu nie ma w DOM → logowanie jest niesprawne.

Techniczne i biznesowe zastosowania

test poprawności logowania,
walidacja, czy po zalogowaniu działają koszyk i ceny,
testy kont premium / VIP / B2B,
testy uprawnień (czy użytkownik widzi to, co powinien).

Z biznesowej perspektywy: chronisz doświadczenie swoich najcenniejszych klientów – powracających i lojalnych.

SLA procesu zakupowego – techniczne spojrzenie na realną dostępność sprzedaży

Zamiast liczyć uptime serwera (mało znaczący KPI), liczymy dostępność procesu zakupowego.

Jest różnica pomiędzy:

„Serwer działa 99,9% czasu.”
„Koszyk, checkout i płatności działały 99,8% czasu.”

Zabbix umożliwia:

tworzenie usług biznesowych (IT Services),
powiązanie ich z testami syntetycznymi (koszyk, płatności, logowanie),
agregowanie błędów i czasów niedostępności,
generowanie raportów SLA dla zarządu.

W praktyce:

mierzysz realny czas, w którym sklep mógł przyjmować zamówienia,
masz twarde dane, które można pokazać CFO/CEO,
widzisz, które elementy ścieżki zakupowej psują SLA.

To KPI, które ma bezpośrednie przełożenie na przychód.

Self-Healing – techniczna automatyzacja, która skraca awarie do sekund

Każdy monitoring powie, że jest problem ale tylko dobry potrafi go naprawić. W SparkSome konfigurujemy w Zabbix automatyczne akcje naprawcze:

restart Redis (gdy osiągnie limit połączeń),
flush PHP cache/opcache (gdy stare dane powodują błąd),
restart PHP-FPM (gdy procesy się zawieszą),
przełączenie aplikacji na inną instancję,
odświeżenie cache aplikacji,
uruchomienie nowej instancji w Docker/K8s.

W efekcie:

wiele awarii kończy się w 10–20 sekund,
zanim człowiek odczyta alert - system już działa,
MTTR spada do absolutnego minimum,
użytkownicy często nie widzą awarii w ogóle.

Self-Healing zmienia monitoring w: aktywny system utrzymania sprzedaży, a nie tylko bierny sygnalizator problemów.

Case study: Automatyczna naprawa awarii podczas dropu sprzedażowego (Magento 2)

Kontekst: duży sklep, wysoka konkurencja, gigantyczny ruch

Klient: duży sklep w branży gaming/electronics - działał na Magento 2 i obsługiwał:

12 000 aktywnych produktów,
500 000 odwiedzin miesięcznie,

Drop miał formę flash sale - limitowana pula 300 sztuk bardzo oczekiwanego produktu.

O 12:00 przycisk „Kup teraz” miał się pojawić co spowodowało szturm użytkowników. W takich momentach sekundy decydują o wyniku finansowym.

Sytuacja problemowa: ogromny skok ruchu i błąd 503 Już o 11:59:45 na stronę napływała fala użytkowników próbujących odświeżać kartę produktu.

W momencie startu:

ruch skoczył o 900–1000%,
kolejki Redis zaczęły się zapychać,
PHP-FPM osiągnął maksymalną liczbę workerów,
baza Magento zaczęła zwracać wolne zapytania.

O 12:00:03 syntetyczny test Zabbixa próbował dodać produkt do koszyka (co robi co 60 sekund). Nie udało się → sklep zwrócił HTTP 503. To oznacza jedno: klienci właśnie zaczęli widzieć awarie.

Natychmiastowa reakcja SparkSome

Dzięki temu, że wcześniej wdrożyliśmy self-healing w Zabbix, system wykonał automatyczną reakcję:

W ciągu 15 sekund Zabbix wykonał:

analizę wykorzystania PHP-FPM → przeciążone workery,
restart pooli PHP-FPM,
czyszczenie opcache,
czyszczenie cache Magento (bin/magento cache:flush),
restart Redis,
synchronizację usług backendowych.

Zabbix natychmiast wysłał:

alert Telegram do zespołu SparkSome,
e-mail do kierownika IT,
screenshot błędu 503.

Administratorzy dowiedzieli się o problemie dopiero wtedy, gdy system już był naprawiony.

Efekt: sprzedaż uratowana, system ustabilizowany

O 12:01:

dodawanie do koszyka wróciło do normy,
kolejki Magento się odblokowały,
Redis zaczął działać stabilnie,
obciążenie PHP-FPM spadło do bezpiecznego poziomu.

Flash sale zakończył się pełnym sukcesem: wszystkie 300 produktów zostało sprzedanych.

Zabbix wykonał raport SLA:

proces zakupowy dostępny 98% czasu w trakcie godziny akcji,
jedyny incydent trwał ok. 60 sekund,
problem został automatycznie rozwiązany, zanim eskalował.

Case Study: Black Friday w sklepie WooCommerce: wczesne wykrycie przeciążenia i zapobieżenie awarii

Profil klienta

Średniej wielkości sklep internetowy B2C oparty na WooCommerce, oferujący ponad 2 500 produktów. W okresach promocyjnych miesięczny ruch przekracza 150 000 odwiedzin, a Black Friday generuje nawet 300–400% wzrostu jednoczesnych użytkowników.

W poprzednich latach sklep miał problemy:

wolne działanie przy większym ruchu,
błędy 504 Gateway Timeout,
krótkie okresy niedostępności,
utratę sprzedaży w szczycie kampanii.

Black Friday to dla tego klienta najważniejszy dzień sprzedażowy roku. Każda minuta awarii może oznaczać dziesiątki tysięcy złotych strat.

Cel wdrożenia monitoringu SparkSome

Klient chciał:

wykryć problemy zanim pojawią się w szczycie ruchu,
monitorować kluczową ścieżkę zakupową,
otrzymywać alerty w czasie rzeczywistym,
mieć pewność, że w Black Friday sklep działa jak należy.

Dlatego wdrożyliśmy pełny zestaw:

Monitoring syntetyczny Zabbix + Chrome Headless,
Pomiar Web Vitals,
Monitoring serwerów, bazy, cache, PHP,
Alerty: Telegram dla zespołu IT, SMS dla właściciela sklepu,
Dashboard „Black Friday Live”.

Co dokładnie monitorowaliśmy?

Co 5 minut Zabbix uruchamiał scenariusz, który:

otwierał stronę główną,
przechodził do strony produktu,
dodawał produkt do koszyka,
przechodził do checkoutu,
mierzył Web Vitals,
zbierał czasy odpowiedzi backendu.

Równolegle monitorowaliśmy:

obciążenie serwera (CPU, RAM, I/O),
czas generowania strony PHP,
czas odpowiedzi MySQL,
obciążenie cache (Redis, Object Cache),
liczbę połączeń i błędów 5xx.

Moment krytyczny (7:15 rano, dzień Black Friday)

Promocja ruszała o 8:00. O 7:15 monitoring syntetyczny wykonał kolejną próbę przejścia scenariusza.

I wykrył:

wzrost czasu ładowania strony produktu z 1,5 s → 4,2 s,
przeciążenie CPU do prawie 90%,
pierwsze sporadyczne błędy timeout przy dodawaniu do koszyka,
spadek wydajności MySQL (kolejki zapytań).

Co ważne sklep nadal działał, a zwykły monitoring HTTP pokazywał status „zielony”. Jednak monitoring syntetyczny pokazał prawdę: klient zaczyna odczuwać spowolnienie i może niedługo przestać finalizować zamówienia.

Zabbix natychmiast:

wysłał alert Telegram do zespołu technicznego,
wysłał SMS do właściciela sklepu,
zapisał Web Vitals i czasy serwerowe,
udokumentował problem na dashboardzie.

Reakcja zespołu SparkSome

Jeszcze przed rozpoczęciem kampanii wykonaliśmy:

Skalowanie zasobów

uruchomienie dodatkowej instancji webowej,
zwiększenie mocy serwera aplikacyjnego,
zwiększenie zasobów bazy MySQL,
optymalizacja cache + restart usług.

Czas całej operacji: około 20 minut. Sklep był gotowy na czas - dokładnie o 7:40.

Black Friday: skala ruchu

W szczycie:

ponad 800 jednoczesnych klientów,
ruch o 400% większy niż zwykle,
wysokie tempo dodawania produktów do koszyka,
intensywne kampanie płatne + mailing.

Wynik: ZERO awarii, rekordowa sprzedaż

Dzięki wczesnej reakcji:

brak błędów 504,
brak spowolnień w szczycie,
checkout działał stabilnie,
średni czas ładowania stron pozostał w normie,
kampania zakończyła się rekordowym wynikiem sprzedaży.

Monitoring wykrył problem 45 minut przed pikiem ruchu, co pozwoliło uniknąć sytuacji, która w poprzednich latach skutkowała:

awariami,
porzuconymi koszykami,
utratą przychodów.

Co zyskał klient?

stabilny Black Friday bez przestojów,
pewność działania wszystkich krytycznych funkcji,
wyższe przychody dzięki płynnemu checkoutowi,
pełny raport SLA procesu zakupowego,
gotowy dashboard pod kolejne kampanie,
spokój - monitoring pilnował wszystkiego automatycznie.

Dlaczego to case jest tak ważne?

Bo pokazuje kluczową przewagę monitoringu syntetycznego: Zwykły monitoring mówi „serwer działa”. Monitoring syntetyczny mówi „klient może kupić lub nie”.

I to jest klucz podczas największych akcji sprzedażowych roku.

Monitoring jako usługa (SparkSome Zabbix-as-a-Service)

Nie każdy sklep internetowy ma zasoby, aby samodzielnie utrzymywać zaawansowaną infrastrukturę monitoringu. Dlatego w SparkSome oferujemy gotowe rozwiązanie w modelu SaaS – Zabbix-as-a-Service.

Jak działa monitoring Zabbix-as-a-Service w praktyce?

W modelu Zabbix-as-a-Service całe środowisko monitoringu znajduje się po stronie SparkSome.

Klient otrzymuje działający system „od ręki”, bez instalacji, serwerów, DevOpsów i konfiguracji.

W praktyce oznacza to:

brak serwerów i instalacji po stronie klienta - całą infrastrukturę utrzymuje SparkSome,
gotową, w pełni skonfigurowaną instancję Zabbix zoptymalizowaną pod e-commerce,
dashboardy pokazujące zdrowie sklepu, ścieżkę zakupową, Web Vitals i błędy,
scenariusze testów syntetycznych (koszyk, checkout, logowanie, ceny, promocje),
alerty w czasie rzeczywistym (SMS, Telegram, WhatsApp, e-mail),
ciągłą administrację, optymalizację i pełne utrzymanie systemu,
wsparcie 24/7, również podczas kampanii i wysokich obciążeń,
automatyczne naprawy (self-healing) wykonywane przez SparkSome w razie awarii.

To najszybszy sposób, aby e-commerce korzystał z monitoringu klasy enterprise bez kosztów zespołu IT, bez serwerów, bez licencji i bez ryzyka złej konfiguracji.

Zabbix + Docker + Chrome = stabilna sprzedaż w e-commerce

W nowoczesnym e-commerce monitoring nie powinien pytać: „Czy serwer działa?”
Tylko: „Czy klient może zrobić zakupy tu i teraz?”

Połączenie Zabbix + Docker + Chrome daje dokładnie tę odpowiedź.

System monitoruje w czasie rzeczywistym:

dodawanie do koszyka,
checkout i płatności,
logowanie i funkcje premium,
ceny i promocje,
Web Vitals i szybkość działania,
integracje ERP,
automatyczne naprawy infrastruktury (self-healing).

To monitoring, który chroni nie tylko infrastrukturę, ale również sprzedaż, konwersję i doświadczenie klienta.

Chcesz wdrożyć taki monitoring w swoim sklepie?

W SparkSome dostarczymy kompletny system, bez angażowania Twojego IT:

Zabbix + Docker + Chrome (pełna konfiguracja),
scenariusze ścieżki zakupowej (koszyk, checkout, płatności),
screenshoty błędów i analiza UX,
alerty SMS / Telegram / WhatsApp,
automatyczne naprawy (self-healing),
dashboardy i raporty SLA dla zarządu.

Napisz do nas, a my przygotujemy darmową analizę Twojego sklepu e-commerce.