Jak monitorować i backupować Zabbixa – zabezpiecz swój monitoring przed awarią

Monitoring to nieodłączny element każdej stabilnej infrastruktury IT. Ale co jeśli to właśnie system monitoringu zawiedzie? Brak działania Zabbixa może oznaczać, że dowiesz się o awarii… z telefonu od klienta. W tym artykule pokażemy krok po kroku, jak zadbać o niezawodność samego Zabbixa – przez odpowiednie monitorowanie jego komponentów i dobrze zaplanowane backupy.

Co może pójść nie tak z Zabbixem?

Zabbix to rozbudowany system składający się z serwera, bazy danych, frontendów, agentów i proxy. Każdy z tych komponentów może stać się źródłem awarii. Oto najczęstsze problemy, z jakimi możesz się spotkać:

Przepełniony dysk

Jeśli serwer Zabbixa nie ma wolnego miejsca, baza danych przestanie przyjmować dane – a to z kolei zatrzyma cały monitoring. Co gorsza, takie sytuacje często pojawiają się znienacka – np. po dużej awarii, która generuje setki tysięcy eventów.

Porada: Ustaw alert, jeśli wolne miejsce na dysku /var/lib/mysql lub /var/lib/postgresql spadnie poniżej 10%.

Padła baza danych

Zabbix w ogromnym stopniu polega na bazie – jeśli baza przestaje działać (np. z powodu błędu IO, crasha, przeciążenia), tracisz dostęp do danych historycznych, triggerów i powiadomień.

Przykład: Zabbix przestaje wysyłać alerty, bo trigger nie może porównać aktualnego stanu z wartością historyczną.

Wyczerpane zasoby systemowe

Jeśli na serwerze brakuje CPU, RAM-u lub są problemy z IO, Zabbix zaczyna się „zapychać”: agenty nie są obsługiwane, dane zbierane są z opóźnieniem, a użytkownicy widzą timeouty w GUI.

Porada: Monitoruj load average, zużycie RAM oraz liczbę procesów zabbix_server – zrób trigger, jeśli obciążenie przekracza ilość CPU × 1.5.

Brak komunikacji z proxy

Brak danych z oddziałów? Może być winna awaria proxy, VPN lub problem z DNS. Czasem wystarczy restart proxy – ale musisz się o tym dowiedzieć.

Przykład: Brak danych z 10 sklepów przez 3 godziny – nikt tego nie zauważył, bo dashboard główny świecił się na zielono.

Błąd operatora

Człowiek to najsłabsze ogniwo – przypadkowe usunięcie szablonu, triggera, zakładki „Actions” czy całej grupy hostów może sparaliżować monitoring.

Porada: Włącz audyt logów i regularnie eksportuj konfigurację (np. przez API lub Zabbix CLI).

 

 

 

 

 

 

Jak monitorować samego Zabbixa?

Najlepszym sposobem na ochronę monitoringu jest… monitorowanie samego monitoringu. Oto, jak zbudować metryki „zdrowia” Zabbixa:

zabbix[stats]

Dzięki tym metrykom możesz zobaczyć:

• długość kolejek history i trends
• czas przetwarzania danych
• liczbę zadań oczekujących

Przykład: Jeśli kolejka przetwarzania itemów trapper przekracza 1000 przez 5 minut, coś jest nie tak z odbieraniem danych z proxy.

Ping do bazy danych

W zależności od użytej bazy użyj:

• pgsql.ping lub mysql.ping
• pgsql.pingsec do pomiaru opóźnień

Porada: Jeśli pingsec przekracza 1 sekundę, może to oznaczać przeciążenie lub brak indeksów w bazie.

Stan systemu

Monitoruj klasyczne metryki systemowe:

• vfs.fs.size[/,pfree] – wolne miejsce
• system.cpu.util[,system] – obciążenie CPU
• vm.memory.size[available] – dostępna pamięć RAM

Czy frontend Zabbixa działa?

Użyj prostego checka HTTP (np. curl lub web.page.get) z innego hosta:

web.page.get[zabbix.local,80,/zabbix.php]

Proxy: zabbix.proxy.lastaccess

Bardzo ważna metryka – mówi, kiedy ostatni raz proxy połączyło się z serwerem. Ustaw trigger na brak kontaktu przez 5 minut.

Automatyczne alerty, gdy monitoring nie działa

Sam Zabbix może informować o swoim własnym niedziałaniu. Wystarczy dobrze przemyślana logika:

Triggery typu „no data”

Używaj wyrażeń typu:

nodata(/Zabbix proxy/zabbix.proxy.lastaccess,300s)=1

Dzięki temu Zabbix podniesie alarm, jeśli przez 5 minut nie otrzyma danych.

Eskalacje poważnych awarii

Jeśli trigger pokazuje, że baza nie odpowiada przez 5 minut, możesz:

• wysłać SMS
• uruchomić skrypt restartujący bazę
• przekazać alert do innego systemu (np. Prometheus Alertmanager, PagerDuty)

Porada: Niektóre firmy używają drugiego, minimalistycznego systemu monitoringu (np. pingdom, uptimerobot), który… monitoruje Zabbixa.

Backup Zabbixa – co, jak i kiedy?

Twój Zabbix jest tak dobry, jak ostatni backup. I tak bezpieczny, jak jego test przywrócenia.

Co backupować:

• Baza danych – pełny dump codziennie (kompresowany).
• /etc/zabbix/ – konfiguracje serwera, agenta, proxy.
• Skrypty i pluginy – np. alerty mailowe, Slack, customowe itemy.
• Frontend (opcjonalnie) – jeśli modyfikowano pliki GUI.

Harmonogram:

Czynność	Częstotliwość	Uwagi
Backup bazy	Codziennie o 2:00	Trzymać 7 dni
Backup /etc/zabbix	Co tydzień + przy zmianach
Test przywracania	Raz na kwartał	Ręcznie lub skrypt

Przykładowe skrypty backupu

Oto przykład prostego skryptu backupu PostgreSQL + konfiguracji:

#!/bin/bash
set -e

BACKUP_DIR="/var/backups/zabbix/$(date +%F)"
mkdir -p "$BACKUP_DIR"

# Backup bazy danych
PGPASSWORD="twojehaslo" pg_dump -U zabbix -F c zabbix > "$BACKUP_DIR/zabbix_db.dump"

# Backup konfiguracji
tar -czf "$BACKUP_DIR/etc_zabbix.tar.gz" /etc/zabbix

# Backup skryptów
tar -czf "$BACKUP_DIR/scripts.tar.gz" /usr/lib/zabbix/alertscripts

# Opcjonalnie: przesyłanie na S3
# aws s3 cp "$BACKUP_DIR" s3://twoj-bucket/zabbix --recursive

Disaster Recovery – co gdy Zabbix padnie?

Awaria już się wydarzyła. Co teraz?

Zabbix Offline Playbook

Przygotuj dokument zawierający:

• Listę hostów do przywrócenia
• Nazwy i lokalizacje backupów
• Kolejność uruchamiania komponentów
• Dostęp do haseł, kluczy

Procedura przywracania:

1. Rozpakuj konfigurację do /etc/zabbix
2. Przywróć bazę danych:

pg_restore -U zabbix -d zabbix /ścieżka/zabbix_db.dump

Sprawdź i uruchom usługę:

systemctl start zabbix-server

Zewnętrzne wsparcie – monitorowanie Zabbixa za pomocą Uptime Kuma

Zabbix świetnie radzi sobie z monitorowaniem infrastruktury od środka, ale czasami warto dodać dodatkową warstwę: zewnętrzne narzędzie, które sprawdzi, czy Zabbix działa również „z zewnątrz”. Do tego świetnie nadaje się Uptime Kuma – prosty, lekki system do monitoringu dostępności usług, który możesz postawić dosłownie w kilka minut.

Uptime Kuma działa podobnie do Pingdoma – co X sekund odpytuje podany adres HTTP, TCP, ICMP lub gniazdo WebSocket i sprawdza, czy wszystko działa. Ma elegancki webowy interfejs, wspiera powiadomienia (m.in. Telegram, Discord, e-mail, Webhooki), loguje czasy odpowiedzi i daje szybki podgląd na awarie.

Co monitorować w Zabbixie z pomocą Uptime Kuma?

Uptime Kuma świetnie nadaje się do monitorowania dostępności kluczowych usług Zabbixa z poziomu użytkownika. Co warto dodać jako „monitory”:

• Dostępność GUI Zabbixa: sprawdzaj URL, np. https://monitoring.twojafirma.pl/zabbix.php. Jeśli GUI nie działa, coś jest nie tak z serwerem WWW, frontendem lub bazą danych.
• API Zabbixa: dodaj żądanie POST do /api_jsonrpc.php, aby upewnić się, że backend odpowiada – np. z tokenem lub nawet zapytaniem testowym.
• Zabbix Proxy (zewnętrzne): jeśli masz proxy w oddziałach, możesz dodać ping lub port TCP (np. 10051) do testów z zewnętrznego Uptime Kuma.

Przykład: Uptime Kuma wykrywa, że GUI Zabbixa nie odpowiada od 3 minut – i wysyła powiadomienie na Slacka. Dzięki temu wiesz o awarii, nawet jeśli… to Zabbix miał ją wykryć.

Uptime Kuma + Zabbix = wzajemne wsparcie

Co najlepsze, Zabbix i Uptime Kuma mogą się nawzajem monitorować – i wzmacniać bezpieczeństwo Twojego środowiska. Oto jak możesz połączyć oba narzędzia:

• Zabbix monitoruje Uptime Kumę: przez web.page.get, sprawdza, czy dashboard Kuma działa. Można też monitorować procesy Node.js, bazę SQLite lub Dockera.
• Uptime Kuma monitoruje Zabbixa: testuje dostępność GUI i API, niezależnie od tego, co dzieje się z serwerem, bazą czy DNS-em.
• Alertowanie krzyżowe: jeśli Zabbix padnie – Kuma da znać. Jeśli Kuma zniknie – Zabbix podniesie alarm. Taki tandem pozwala złapać większość problemów infrastrukturalnych.

Porada: Zainstaluj Uptime Kumę na oddzielnym VPS, najlepiej w innym datacenter – wtedy masz pewność, że nawet przy całkowitym padzie głównej infrastruktury wciąż będziesz otrzymywać alerty.

Krok1: Instalacja Uptime Kuma (Docker)

Najprostszy sposób: kontener Docker. Uptime Kuma instaluje się w minutę:

docker volume create uptime-kuma
docker run -d \
  --restart=always \
  --name uptime-kuma \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  louislam/uptime-kuma:1

Po chwili będzie dostępna pod http://adres-serwera:3001. Przy pierwszym uruchomieniu ustawiasz hasło administratora.

Krok 2: Dodanie monitoringu Zabbixa

Zaloguj się do interfejsu Uptime Kuma i dodaj monitor:

Monitor GUI Zabbixa

• Typ: HTTP(S)
• Nazwa: Zabbix Frontend
• Adres URL: https://monitoring.twojafirma.pl/zabbix.php
• Metoda: GET
• Interwał: np. 60 sekund
• Retry: 3x
• Powiadomienia: Slack, Telegram, Discord, mail – jak wolisz

Monitor API Zabbixa

• Typ: HTTP(S) – POST
• Nazwa: Zabbix API
• URL: https://monitoring.twojafirma.pl/api_jsonrpc.php

Body (JSON):

{
  "jsonrpc": "2.0",
  "method": "apiinfo.version",
  "params": {},
  "id": 1
}

Nagłówki

{
  "Content-Type": "application/json"
}

Jeśli wszystko działa, odpowiedź API powinna zawierać wersję Zabbixa – np. 6.4.10.

Podsumowanie

Zabbix to serce Twojego systemu monitoringu – dlatego warto zadbać o jego niezawodność tak samo, jak o resztę infrastruktury. Regularne monitorowanie komponentów Zabbixa (kolejek, bazy danych, proxy, zasobów systemowych) pozwala wcześnie wykryć problemy, zanim doprowadzą do awarii. Dobrze zaplanowane backupy bazy danych i konfiguracji – z testami przywracania – są fundamentem skutecznego disaster recovery. Warto też wykorzystać zewnętrzne narzędzia, takie jak Uptime Kuma, by monitorować Zabbixa od strony użytkownika, np. przez sprawdzanie GUI i API. Dzięki połączeniu automatyzacji, redundancji i proaktywnego podejścia, Twój monitoring może sam się… monitorować.