W skrócie: Zabbix 8.0 LTS to kolejna wersja z długoterminowym wsparciem (Long Term Support), będąca następcą Zabbix 6.0 LTS w cyklu LTS-owym, przy czym w międzyczasie ukazały się wersje standardowe 7.0 LTS oraz 7.4. Migracja jest wspierana bezpośrednio ze wszystkich wersji od Zabbix 2.0.x wzwzyż – nie trzeba przechodzić „skokowo” przez każdą wersję pośrednią. Najważniejsze warunki wstępne to: PHP ≥ 8.2.0, zaktualizowana baza danych (PostgreSQL, MySQL/MariaDB, TimescaleDB, Elasticsearch lub nowo wspierany ClickHouse) oraz pełny backup przed startem. Uwaga: w chwili publikacji tego artykułu (sierpień 2026) Zabbix 8.0 znajduje się jeszcze w fazie beta (najnowsza publiczna wersja to 8.0.0beta2) – poniższa procedura jest zgodna z oficjalną dokumentacją i zadziała identycznie po wydaniu finalnej wersji GA.
Bezpłatne warsztaty: Zbuduj 5 Agentów AISprawdź szczegóły:
Spis treści
- Status Zabbix 8.0 LTS na dzień publikacji
- Co nowego w Zabbix 8.0 LTS
- Zabbix 7.0 vs 7.4 vs 8.0 – porównanie
- Harmonogram wsparcia (kiedy musisz migrować)
- Wymagania przed migracją
- Checklista przygotowawcza
- Migracja krok po kroku – Zabbix Server / Proxy
- Migracja bazy danych – na co uważać
- Aktualizacja frontendu (PHP, Nginx/Apache)
- Migracja Zabbix Agent / Agent 2
- Migracja w Dockerze i Kubernetesie
- Zmiany, które mogą popsuć Twoją instalację
- Testowanie po migracji
- Najczęstsze błędy i troubleshooting
- FAQ – najczęściej zadawane pytania
- Podsumowanie
1. Status Zabbix 8.0 LTS na dzień publikacji
Zanim przejdziesz do migracji produkcyjnej, sprawdź aktualny status wydania. Zgodnie z oficjalnym harmonogramem Zabbix LLC:
- 8.0.0alpha1 – 30 października 2025
- 8.0.0alpha2 – luty 2026
- 8.0.0beta1 – 22 maja 2026
- 8.0.0beta2 – 9 lipca 2026 (najnowsza publiczna wersja na moment pisania tego poradnika)
- 8.0.0 GA (wersja stabilna LTS) – planowana, ale bez ogłoszonej ostatecznej daty na dzień publikacji artykułu
W oficjalnym rejestrze kontenerów Docker obraz 8.0 nosi wciąż tag alpine-trunk (gałąź developerska), podczas gdy 7.4 ma już tagi latest i alpine-latest. To sygnał jednoznaczny: 8.0 nie jest jeszcze wersją produkcyjną. Jeśli zarządzasz środowiskiem produkcyjnym, nie instaluj wersji beta na produkcji – użyj jej wyłącznie w środowisku testowym/homelab, aby przygotować się do właściwej migracji po premierze GA (General Availability -wersja oprogramowania staje się oficjalnie stabilna i gotowa do powszechnego użytku komercyjnego oraz produkcyjnego ). Ten poradnik został tak przygotowany, aby procedura pozostała aktualna również po wydaniu finalnej wersji stabilnej, ponieważ opiera się na oficjalnej dokumentacji, które zwykle nie zmieniają się istotnie między beta a GA.
2. Co nowego w Zabbix 8.0 LTS
Zabbix 8.0 LTS to – w przeciwieństwie do wielu wcześniejszych, bardziej „ewolucyjnych” wydań – zmiana o charakterze generacyjnym. Projekt wychodzi poza klasyczny monitoring infrastruktury (CPU, RAM, dysk, SNMP, JMX) w stronę pełnej obserwowalności (observability). Najważniejsze nowości:
- Integracja z OpenTelemetry – natywne zbieranie i wizualizacja danych typu traces (śledzenie żądań między usługami), obok tradycyjnych metryk.
- Nowy silnik przechowywania danych – zoptymalizowany pod duże wolumeny logów, śladów (traces) i danych szeregów czasowych, w tym oficjalne wsparcie dla ClickHouse jako backendu historii.
- Complex Event Processing (CEP) – nowy silnik korelacji zdarzeń, pozwalający analizować powiązania między wieloma problemami (np. jedna awaria sieci generująca setki alertów) zamiast oceniać każdy problem osobno.
- Monitoring sieci klasy NPMD – zbieranie i wizualizacja NetFlow, identyfikacja „top talkers”, nowy widget topologii sieci z automatycznym odkrywaniem urządzeń (zero-configuration discovery).
- Rozszerzone uprawnienia dla proxy i grup proxy – precyzyjna kontrola, jakie hosty i dane widzi dany proxy.
- Przesyłanie certyfikatów SSO bezpośrednio z panelu web – bez konieczności edycji plików systemowych.
- Zmodernizowany interfejs – walidacja formularzy, łatwiejszy import/eksport dashboardów, oficjalna aplikacja mobilna.
- Nowy typ danych JSON dla itemów – z limitem 128 MiB oraz ograniczeniami dotyczącymi triggerów operujących na tym typie.
- Wykres punktowy (scatter plot) jako nowy typ widgetu.
- Elastyczniejsze, konfigurowalne tabele w interfejsie oraz eksport/import dashboardów między instancjami.
Realny koszt migracji nie leży jednak w nowych funkcjach, tylko w wymaganiach dotyczących bazy danych i PHP oraz w usuniętych/zmienionych mechanizmach – o czym szczegółowo w dalszej części poradnika.
3. Zabbix 7.0 vs 7.4 vs 8.0 – porównanie
| Obszar | Zabbix 7.0 LTS | Zabbix 7.4 (standard) | Zabbix 8.0 LTS |
|---|---|---|---|
| Typ wsparcia | LTS (długoterminowe) | Standard (krótki cykl) | LTS (długoterminowe) |
| Premiera | Czerwiec 2024 | Q4 2025 | Planowana premiera GA po fazie beta (2026) |
| Licencja | AGPLv3 | AGPLv3 | AGPLv3 |
| Minimalna wersja PHP | 8.0.0 | 8.2.0 | 8.2.0 |
| Observability (OpenTelemetry) | Brak | Częściowe podstawy | Pełna integracja (traces, logi) |
| Silnik historii | Klasyczny + TimescaleDB/Elasticsearch | Standard API do time-series | + oficjalne wsparcie ClickHouse |
| Korelacja zdarzeń | Podstawowa | Podstawowa | Complex Event Processing (CEP) |
| Monitoring sieci (NetFlow, topologia) | Brak natywnego | Brak | Tak – nowy moduł NPMD |
| Aplikacja mobilna | Nieoficjalna/ograniczona | – | Oficjalna aplikacja mobilna |
| Uprawnienia proxy/grup proxy | Ograniczone | Ograniczone | Szczegółowe, granularne |
4. Harmonogram wsparcia (kiedy musisz migrować)
To najważniejsza sekcja przy planowaniu budżetu czasowego:
- Zabbix 7.0 LTS – pełne wsparcie do 30 czerwca 2027 r. Jeśli jesteś na 7.0, nie musisz się spieszyć – możesz poczekać, aż 8.0 dojrzeje (kilka wydań patch, np. 8.0.1-8.0.3), zanim zaplanujesz migrację produkcyjną.
- Zabbix 7.4 – to wydanie standardowe (nie-LTS), którego pełne wsparcie kończy się wraz z premierą 8.0, a wsparcie ograniczone (tylko krytyczne poprawki bezpieczeństwa) trwa do ok. Q4 2026. Jeśli używasz 7.4, zacznij planować migrację już teraz, nawet jeśli realną migrację wykonasz jesienią/zimą.
- Zabbix 8.0 LTS – po premierze GA pełne wsparcie ma obowiązywać do ok. Q3 2029, co czyni ją naturalnym celem migracji dla środowisk, które potrzebują stabilności na kilka lat.
Zasada praktyczna: administratorzy na 7.0 LTS mają komfort czasowy i mogą pozwolić 8.0 „dojrzeć”. Administratorzy na 7.4 powinni traktować migrację priorytetowo, ponieważ okno wsparcia jest znacznie krótsze.
5. Wymagania przed migracją
Wersja PHP
Zabbix 8.0 wymaga PHP w wersji minimum 8.2.0 (dla porównania: Zabbix 7.0 wymagał minimum PHP 8.0.0). Jeśli Twój serwer frontendu działa na starszym PHP (7.4, 8.0, 8.1), musisz go najpierw zaktualizować – w praktyce oznacza to często aktualizację całej dystrybucji systemowej lub dodanie zewnętrznego repozytorium PHP (np. dla Debian/Ubuntu, moduły dnf dla RHEL/Rocky/Alma).
Wersja bazy danych
Wymagania minimalne rosną z każdą dużą wersją. Przed migracją koniecznie zweryfikuj oficjalną stronę z wymaganiami : https://www.zabbix.com/documentation/8.0/pl/manual/installation/requirements dla wersji 8.0 w dokumentacji Zabbixa – w praktyce oznacza to zwykle:
- PostgreSQL – wymagana nowsza gałąź niż w 7.0/7.4; jeśli Twoja baza pochodzi „z dystrybucji” systemu operacyjnego, aktualizacja Zabbixa = w praktyce aktualizacja silnika PostgreSQL o dwie wersje wyżej, co samo w sobie jest osobnym projektem (dump/restore lub
pg_upgrade). - MySQL / MariaDB – analogicznie, przeskok np. z MySQL 8.0 na 8.4 niesie własny zestaw zmian i niekompatybilności, niezależnie od Zabbixa.
- TimescaleDB, Elasticsearch – nadal wspierane jako silniki historii, ale sprawdź macierz kompatybilności wersji.
- ClickHouse – nowość w 8.0 jako oficjalnie wspierany silnik dla dużych wolumenów danych historycznych/telemetrycznych.
Ważne ostrzeżenie dotyczące kodowania znaków: jeśli baza MySQL/MariaDB została utworzona z zestawem znaków utf8mb3 (starszy, częsty w instalacjach sprzed kilku lat), zdecydowanie zaleca się konwersję do utf8mb4 przed migracją – inaczej możesz napotkać błędy podczas patchowania schematu.
Kompatybilność integracji zewnętrznych
Po migracji niektóre integracje firm trzecich mogą przestać działać, jeśli nie są zgodne z nową wersją Zabbixa – dotyczy to zwłaszcza własnych skryptów korzystających z API, niestandardowych webhooków oraz starszych wtyczek (loadable modules) kompilowanych pod konkretną wersję API C.
6. Checklista przygotowawcza
Zanim wykonasz jakąkolwiek zmianę na produkcji, przejdź przez poniższą checklistę:
- [ ] Sprawdziłem oficjalne Upgrade notes dla docelowej wersji 8.0 (sekcja „Changes in 8.0”).
- [ ] Zweryfikowałem wersję PHP (≥ 8.2.0) na serwerze frontendu.
- [ ] Zweryfikowałem wersję i typ silnika bazy danych względem macierzy kompatybilności 8.0.
- [ ] Sprawdziłem zestaw znaków bazy (utf8mb4 dla MySQL/MariaDB).
- [ ] Wykonałem pełny backup bazy danych (dump) oraz plików konfiguracyjnych.
- [ ] Wykonałem backup binariów Zabbix server/proxy/agent oraz katalogu frontendu PHP.
- [ ] Przygotowałem środowisko testowe/staging o zbliżonej konfiguracji do produkcji.
- [ ] Przetestowałem pełną procedurę migracji na środowisku testowym i zmierzyłem czas trwania patcha bazy danych.
- [ ] Zidentyfikowałem własne skrypty/integracje korzystające z Zabbix API i sprawdziłem, czy używane metody nie zostały usunięte/zmienione w 8.0.
- [ ] Sprawdziłem, czy używam makr lub parametrów oznaczonych jako usunięte/przestarzałe w upgrade notes.
- [ ] Zaplanowałem okno serwisowe (maintenance window) i poinformowałem zespół/klientów.
- [ ] Przygotowałem plan rollback (patrz sekcja niżej).
7. Migracja krok po kroku – Zabbix Server / Proxy
Poniższa procedura odzwierciedla oficjalny, standardowy proces aktualizacji Zabbiksa i jest identyczna niezależnie od tego, czy migrujesz z 7.0, czy z 7.4 (Zabbix wspiera migrację bezpośrednią z dowolnej wersji od 2.0.x wzwyż – nie trzeba przechodzić przez wersje pośrednie).
Krok 1. Zaplanuj okno serwisowe i zatrzymaj zapis danych
# Zatrzymaj Zabbix server, aby żadne nowe dane nie trafiały do bazy
sudo systemctl stop zabbix-server
# Jeśli używasz proxy w architekturze rozproszonej, zatrzymaj też proxy
sudo systemctl stop zabbix-proxy
To krok krytyczny – nie pomijaj go. Zapis danych w trakcie migracji schematu bazy może doprowadzić do niespójności.
Krok 2. Wykonaj pełny backup
# PostgreSQL
pg_dump -U zabbix -Fc zabbix > /backup/zabbix_pre8_$(date +%F).dump
# MySQL / MariaDB
mysqldump --single-transaction -u zabbix -p zabbix > /backup/zabbix_pre8_$(date +%F).sql
# Backup plików konfiguracyjnych i binariów
sudo cp -a /etc/zabbix /backup/zabbix_etc_$(date +%F)
sudo cp -a /usr/share/zabbix /backup/zabbix_frontend_$(date +%F)
Krok 3. Zaktualizuj repozytorium pakietów Zabbix
# Debian/Ubuntu - przykład dla repozytorium 8.0
wget https://repo.zabbix.com/zabbix/8.0/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_8.0+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_8.0+ubuntu24.04_all.deb
sudo apt update
# RHEL/Rocky/AlmaLinux - przykład
sudo rpm -Uvh https://repo.zabbix.com/zabbix/8.0/release/rhel/9/noarch/zabbix-release-latest-8.0.el9.noarch.rpm
sudo dnf clean all
Dostosuj nazwę dystrybucji/wersji do swojego środowiska – zawsze sprawdzaj aktualny link do repozytorium na oficjalnej stronie pobierania Zabbixa, ponieważ adresy pakietów mogą się zmieniać między wydaniami.
Krok 4. Zainstaluj nowe pakiety
# Debian/Ubuntu
sudo apt install zabbix-server-pgsql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent2
# RHEL/Rocky/AlmaLinux
sudo dnf install zabbix-server-pgsql zabbix-web-pgsql zabbix-apache-conf zabbix-sql-scripts zabbix-agent2
Menedżer pakietów zapyta, czy chcesz zachować lokalne wersje plików konfiguracyjnych (zabbix_server.conf itd.) — zachowaj istniejące pliki, a następnie ręcznie porównaj je z nowymi szablonami pod kątem nowych, opcjonalnych parametrów opisanych w sekcji „What’s new”: https://www.zabbix.com/documentation/8.0/pl/manual/whatsnew
Krok 5. Przejrzyj plik konfiguracyjny pod kątem zmian
Otwórz zabbix_server.conf / zabbix_proxy.conf i porównaj z domyślnym plikiem .conf dostarczonym z nową wersją (zwykle *.conf.dpkg-dist lub *.rpmnew). Sprawdź sekcję upgrade notes: https://www.zabbix.com/documentation/8.0/en/manual/installation/upgrade#upgrade-notes pod kątem parametrów usuniętych lub przemianowanych.
Krok 6. Uruchom nowy Zabbix server i monitoruj log w czasie rzeczywistym
Zalecana praktyka: otwórz dwie równoległe sesje SSH – w jednej wykonuj kroki aktualizacji, w drugiej monitoruj log na żywo.
# Sesja 1 - monitorowanie logu
tail -f /var/log/zabbix/zabbix_server.log
# Sesja 2 - start usługi
sudo systemctl start zabbix-server
Zabbix server automatycznie wykryje starszą wersję schematu bazy i rozpocznie sekwencję patchy aktualizacyjnych. W logu zobaczysz aktualną oraz wymaganą wersję bazy (mandatory/optional), a także procentowy postęp migracji schematu. Po zakończeniu w logu pojawi się komunikat w stylu database upgrade fully completed.
Uwaga na czas trwania. W zależności od wielkości bazy (liczba hostów, itemów, historii) migracja schematu może potrwać od kilku minut do wielu godzin. Zawsze przetestuj czas trwania patcha na kopii produkcyjnej bazy w środowisku testowym.
Jeśli którykolwiek patch się nie powiedzie, Zabbix server nie uruchomi się – to zabezpieczenie przed pracą na częściowo zmigrowanym schemacie. W takim wypadku wracasz do planu awaryjnego (patrz niżej).
8. Migracja bazy danych – na co uważać
Migracja bazy danych to w praktyce najbardziej czasochłonny i ryzykowny element całej operacji, znacznie ważniejszy niż same nowe funkcje Zabbixa. Kluczowe punkty:
- Aktualizacja silnika bazy jest osobnym projektem od aktualizacji Zabbixa. Jeśli Twoja baza pochodzi z domyślnych repozytoriów dystrybucji (np. PostgreSQL dostarczony z Debianem/Ubuntu LTS), przeskok o dwie wersje PostgreSQL wymaga własnej, przetestowanej procedury (
pg_upgrade,pg_dumpall/pg_restorelub replikacja logiczna) — wykonaj ją przed aktualizacją Zabbixa. - Konwersja kodowania znaków. Dla MySQL/MariaDB skonwertuj bazę do
utf8mb4, jeśli wciąż używaszutf8mb3. - Rollback schematu nie jest automatyczny. Zabbix migruje schemat „do przodu” przy starcie nowej wersji serwera – powrót do poprzedniej wersji Zabbixa wymaga przywrócenia bazy z backupu, a nie tylko podmiany binarek. Zaplanuj to świadomie.
- Test wydajności patcha na dużych tabelach. Tabele historii (
history,history_uint,trendsitd.) w dużych instalacjach mogą liczyć dziesiątki milionów wierszy – czas trwania patcha bezpośrednio zależy od rozmiaru tych tabel oraz konfiguracji silnika bazy. - Parametr
AllowUnsupportedDBVersions. Jeśli baza nie spełnia nowych minimalnych wymagań, Zabbix server domyślnie odmówi startu. Istnieje opcja wymuszenia startu mimo niespełnionych wymagań w pliku konfiguracyjnym, ale jest to rozwiązanie tylko na czas testów – nie stosuj go na produkcji, ponieważ nie gwarantuje pełnej stabilności i wsparcia.
9. Aktualizacja frontendu (PHP, Nginx/Apache)
- Zaktualizuj PHP do wersji ≥ 8.2.0 (sprawdź też górny limit wspieranej wersji PHP dla 8.0 w dokumentacji, ponieważ Zabbix zwykle definiuje zarówno dolną, jak i górną granicę).
- Zainstaluj wymagane rozszerzenia PHP (m.in.
php-pgsql/php-mysqli,php-gd,php-bcmath,php-mbstring,php-xml,php-ldapjeśli używasz SAML/LDAP). - Zaktualizuj konfigurację Nginx/Apache pod kątem nowej wersji PHP-FPM (np. zmiana ścieżki do socketu
php8.2-fpm.sock). - Po restarcie usług wyczyść cache i ciasteczka przeglądarki dla adresu frontendu Zabbixa – to częsta przyczyna „dziwnych” błędów tuż po migracji (stare zasoby JS/CSS w cache przeglądarki).
- Zaloguj się do frontendu i sprawdź w Reports → System information, czy wersje serwera, frontendu i bazy danych są ze sobą zgodne.
10. Migracja Zabbix Agent / Agent 2
Aktualizacja agentów jest zwykle najmniej ryzykownym elementem całej migracji, ale warto zrobić ją metodycznie:
- Zaktualizuj repozytorium pakietów na hostach z agentem (analogicznie jak dla serwera).
- Zainstaluj nową wersję
zabbix-agent2(zalecana zamiast starszegozabbix-agent, jeśli jeszcze tego nie zrobiłeś). - Sprawdź plik
zabbix_agent2.confpod kątem nowych/usuniętych parametrów. - Uruchom ponownie usługę agenta i zweryfikuj w logu poprawne połączenie z serwerem/proxy.
- Aktualizację agentów możesz wdrażać stopniowo (rolling upgrade) – nowsze agenty pozostają kompatybilne wstecz z serwerem w rozsądnym zakresie wersji, ale unikaj długotrwałego trzymania znacznej rozbieżności wersji między serwerem a flotą agentów.
11. Migracja w Dockerze i Kubernetesie
Jeśli uruchamiasz Zabbix w kontenerach, migracja sprowadza się koncepcyjnie do zmiany tagu obrazu, ale baza danych nadal wymaga tej samej ostrożności, co w instalacji „klasycznej”:
# Przykład docker-compose — podmiana tagów obrazów
# zabbix-server, zabbix-web, zabbix-agent2: z 7.4-xxxx na 8.0-xxxx
docker compose pull
docker compose up -d
Praktyczne wskazówki:
- Zrób snapshot/backup wolumenu bazy danych przed
docker compose up -d– kontener bazy w wolumenie nie jest automatycznie wersjonowany. - Migracja schematu następuje automatycznie przy pierwszym starcie kontenera
zabbix-serverz nowym tagiem, dokładnie tak samo jak w instalacji pakietowej. - W Kubernetesie zaktualizuj obraz w Deploymencie/StatefulSet i przeprowadź migrację bazy przed skalowaniem nowych replik serwera, aby uniknąć sytuacji, w której stary i nowy schemat są odpytywane jednocześnie.
- Cofnięcie się do poprzedniego tagu obrazu jest trywialne technicznie, ale nie cofa zmian w schemacie bazy – realny rollback nadal wymaga przywrócenia bazy z backupu.
12. Zmiany, które mogą popsuć Twoją instalację
To sekcja, którą warto przeczytać najuważniej – dotyczy zmian, które nie są „nowymi funkcjami”, tylko usunięciami/ograniczeniami mogącymi zatrzymać istniejące konfiguracje:
- Usunięte lub zmienione makra – część starszych makr systemowych/kontekstowych mogła zostać usunięta lub zastąpiona nowymi odpowiednikami. Przejrzyj listę w oficjalnych upgrade notes (Punk 7 / Krok 4) i porównaj ją z makrami używanymi w Twoich szablonach, akcjach i skryptach.
- Preprocessing JavaScript w trybie tylko do odczytu (read-only) dla części kontekstów – jeśli Twoje itemy korzystają z niestandardowych skryptów preprocessingu modyfikujących określone struktury, zweryfikuj ich działanie na środowisku testowym.
- Zmiany dotyczące
UnsafeUserParameters– jeśli w konfiguracji agenta świadomie włączyłeś przekazywanie niebezpiecznych znaków doUserParameter, sprawdź, czy zachowanie tego mechanizmu nie uległo zaostrzeniu. - Ładowalny moduł (plugin) dla Ceph – jeśli monitorujesz klastry Ceph, sprawdź, czy korzystasz z nowego, dedykowanego mechanizmu ładowalnych wtyczek zamiast starszych, niestandardowych skryptów.
- Nowe/zmienione dostawcy historii (HistoryProviders) – jeśli korzystasz z Elasticsearch lub TimescaleDB jako backendu historii, sprawdź ograniczenia (np. limit rozmiaru danych typu JSON w Elasticsearch dla tablic).
- Usunięte metody API – jeśli masz własne integracje korzystające z Zabbix API (skrypty automatyzacji, systemy CMDB, narzędzia ITSM), sprawdź sekcję „API changes” w dokumentacji 8.0 i zaktualizuj wywołania korzystające z metod oznaczonych jako usunięte lub przestarzałe: https://www.zabbix.com/documentation/8.0/en/manual/api/changes
- MS Teams – zmiana typu integracji webhook. Starszy typ integracji oparty o mechanizm Office 365 Connector (Incoming Webhook) został wycofany przez Microsoft i przestał działać – istniejące konfiguracje powiadomień na MS Teams należy zmigrować na nowy typ mediów oparty o MS Teams Workflow webhook.
- Podniesione minimalne wersje baz danych/PHP (opisane wyżej) – najczęstsza pojedyncza przyczyna nieudanych migracji w praktyce.
13. Testowanie po migracji
Po zakończeniu migracji nie kończ pracy na samym uruchomieniu usług – zweryfikuj funkcjonalnie całe środowisko:
- Zaloguj się do interfejsu web i sprawdź Reports → System information – wersje serwera, frontendu, proxy i bazy powinny się zgadzać.
- Sprawdź, czy dane z monitorowanych hostów nadal spływają (Latest data, Dashboards).
- Zweryfikuj działanie triggerów i przetestuj wygenerowanie przykładowego problemu/alertu.
- Sprawdź integracje powiadomień (e-mail, Slack, MS Teams, PagerDuty, webhooki własne) – wyślij testowe powiadomienie z każdego kanału.
- Zweryfikuj działanie skryptów preprocessingu JavaScript na kluczowych itemach.
- Sprawdź uprawnienia użytkowników/grup oraz działanie SSO/SAML, jeśli jest wykorzystywane.
- Przetestuj własne integracje API (skrypty, systemy zewnętrzne).
- Monitoruj logi serwera/proxy przez pierwsze 24 – 48 godzin pod kątem błędów, które mogły nie ujawnić się od razu.
- Porównaj wydajność (czas przetwarzania kolejki itemów, opóźnienia) z wartościami sprzed migracji.
14. Plan awaryjny (rollback)
Rollback po migracji major wersji Zabbiksa nigdy nie jest operacją „za darmo” – zaplanuj go świadomie:
- Podmiana binariów/pakietów wstecz jest prosta, ale bezużyteczna bez cofnięcia schematu bazy – stary Zabbix server nie uruchomi się na już zmigrowanym (nowszym) schemacie.
- Jedyna pewna metoda rollbacku to przywrócenie bazy danych z backupu wykonanego przed migracją (patrz Krok 2) oraz przywrócenie starych binariów/konfiguracji.
- Zaplanuj realistyczne okno czasowe na ewentualny rollback – musi ono uwzględniać czas potrzebny na odtworzenie bazy (
pg_restore/import.sql), który przy dużych instalacjach bywa porównywalny z czasem samej migracji „do przodu”. - Rozważ wykonanie migracji najpierw na kopii lustrzanej środowiska produkcyjnego, a dopiero po pełnym sukcesie – na właściwej produkcji, z możliwie krótkim oknem przestoju.
15. FAQ – najczęściej zadawane pytania
Czy mogę migrować bezpośrednio z Zabbix 6.0 na 8.0, pomijając 7.0 i 7.4?
Tak. Zabbix wspiera bezpośrednią migrację do wersji 8.0.x ze wszystkich wersji od 2.0.x wzwyż – nie trzeba instalować wersji pośrednich. Warto jednak pamiętać, że im większy skok wersji, tym dłużej może trwać sekwencja patchy bazy danych wykonywanych automatycznie podczas pierwszego uruchomienia.
Czy migracja z 7.0 różni się od migracji z 7.4?
Sama procedura techniczna jest identyczna (backup → aktualizacja pakietów → start serwera → automatyczna migracja schematu). Różnica dotyczy głównie liczby patchy bazy danych wykonywanych „w tle” oraz zestawu zmian konfiguracyjnych do przejrzenia – z 7.4 zestaw zmian będzie mniejszy niż z 7.0, ponieważ część zmian wprowadzono już w 7.4.
Czy migracja bazy danych jest odwracalna?
Nie automatycznie. Schemat bazy jest migrowany „do przodu” przy starcie nowego serwera. Powrót do starszej wersji wymaga przywrócenia bazy z backupu wykonanego przed migracją.
Czy powinienem już teraz migrować produkcję na Zabbix 8.0?
Na dzień publikacji tego poradnika (sierpień 2026) Zabbix 8.0 jest w fazie beta i nie zaleca się wdrażania go na produkcji. Jeśli jesteś na 7.0 LTS (wsparcie do 30 czerwca 2027), możesz spokojnie poczekać na dojrzałą wersję GA i pierwsze wydania poprawkowe (np. 8.0.1 – 8.0.3). Jeśli jesteś na 7.4, zacznij planować i testować migrację już teraz, aby być gotowym zaraz po premierze GA, ponieważ okno wsparcia 7.4 jest znacznie krótsze.
Jaka jest minimalna wersja PHP dla Zabbix 8.0?
PHP 8.2.0 lub nowsze.
Czy ClickHouse zastępuje PostgreSQL/MySQL w Zabbix 8.0?
Nie. Główna baza konfiguracyjna Zabbiksa nadal opiera się na PostgreSQL/MySQL/MariaDB. ClickHouse to nowy, dodatkowy silnik zoptymalizowany pod przechowywanie dużych wolumenów danych historycznych i telemetrycznych (metryki, logi, traces), a nie zamiennik głównej bazy konfiguracyjnej.
Co się stanie, jeśli patch bazy danych nie powiedzie się w trakcie migracji?
Zabbix server odmówi startu i nie uruchomi się na częściowo zmigrowanym schemacie. W takiej sytuacji należy zdiagnozować przyczynę błędu w logu (najczęściej: brak miejsca na dysku, przerwane połączenie z bazą, konflikt wersji), a następnie przywrócić bazę z backupu i powtórzyć próbę po usunięciu przyczyny.
Czy agenci Zabbix (Agent 2) muszą być zaktualizowani jednocześnie z serwerem?
Nie muszą być zaktualizowane w tej samej sekundzie, ale nie zaleca się długotrwałego utrzymywania dużej rozbieżności wersji między serwerem a agentami. Praktyka rolling upgrade (stopniowa aktualizacja floty agentów po migracji serwera) jest bezpieczna i powszechnie stosowana.
16. Podsumowanie
Migracja na Zabbix 8.0 LTS – niezależnie, czy startujesz z 7.0, czy z 7.4 – to w warstwie technicznej ten sam, dobrze znany proces: backup → aktualizacja pakietów → start serwera → automatyczna migracja schematu bazy → weryfikacja frontendu i agentów. Prawdziwe ryzyko i czasochłonność tkwią jednak nie w nowych funkcjach observability, tylko w trzech konkretnych obszarach: podniesionych wymaganiach wobec PHP i silnika bazy danych, czasie trwania patcha na dużych tabelach historii oraz w zestawie usuniętych/zmienionych makr, metod API i integracji. Zaplanuj migrację metodycznie: przetestuj ją najpierw na kopii środowiska produkcyjnego, zmierz realny czas trwania patcha bazy, przygotuj pełny backup i jasny plan rollback, a dopiero potem wykonaj ją na produkcji w zaplanowanym oknie serwisowym. Jeśli aktualnie pracujesz na Zabbix 7.0 LTS, masz komfortowy zapas czasu do połowy 2027 roku – warto go wykorzystać, by pozwolić wersji 8.0 osiągnąć pełną dojrzałość po premierze GA.
Poradnik oparty na oficjalnej dokumentacji Zabbix (Requirements, Upgrade notes, What’s new in 8.0) oraz publicznych release notes wersji 8.0.0alpha1/beta1/beta2. Stan na 28 sierpnia 2026 r. – przed premierą GA. Zalecamy zweryfikowanie aktualnych upgrade notes bezpośrednio na stronie zabbix.com/documentation w momencie faktycznej migracji, ponieważ szczegóły mogą ulec zmianie do czasu wydania finalnej wersji stabilnej.
Bezpłatne warsztaty: Zbuduj 5 Agentów AI
Sprawdź szczegóły: