Kategoria: Blog

Brak miejsca na dysku to jedna z tych awarii, które rzadko wyglądają efektownie, ale potrafią zatrzymać pół systemu. Baza danych przestaje zapisywać dane, aplikacja zaczyna zwracać błędy, logi nie mają gdzie się dopisywać, a administrator widzi problem dopiero wtedy, gdy użytkownicy już dzwonią.

Zabbix nadaje się do tego bardzo dobrze, ale samo dodanie hosta do monitoringu nie zawsze wystarczy. Warto sprawdzić, czy monitorowane są właściwe partycje, czy alerty mają sensowne progi i czy nie pomijamy inode.

Problem

Na serwerach Linux zwykle patrzymy na zajętość partycji przez df -h:

df -h

Przykładowy problem widać od razu: partycja / ma 95%, aplikacja zapisuje pliki tymczasowe, a logi rosną dalej. Jeżeli monitoring wyśle alert dopiero przy 99%, może być już za późno na spokojną reakcję.

Druga rzecz to inode. Możesz mieć jeszcze wolne gigabajty, ale jeśli skończą się inode, system nadal nie utworzy nowych plików.

df -i

To często wychodzi przy dużej liczbie małych plików: cache, sesje, kolejki, pliki tymczasowe, stare logi albo źle sprzątane backupy.

Co Zabbix powinien sprawdzać

Na zwykłym serwerze Linux sensowne minimum to:

• zajętość partycji w procentach,
• wolne miejsce w bajtach,
• liczba wolnych inode,
• tempo przyrostu zajętości,
• czy ważne mountpointy są nadal zamontowane.

Sam procent nie zawsze wystarczy. 90% na partycji 20 GB oznacza coś innego niż 90% na macierzy 10 TB. Dlatego dobrze mieć progi procentowe i dodatkowo patrzeć na realną ilość wolnego miejsca.

Discovery partycji

W typowej konfiguracji Zabbix używa low-level discovery do wykrywania systemów plików. Dzięki temu nie trzeba ręcznie dodawać każdego mountpointu.

W praktyce po podpięciu template Linux sprawdź w Zabbixie, jakie file systemy zostały wykryte. Nie zakładaj, że monitoring objął dokładnie to, co trzeba.

Na serwerze pomocniczo sprawdzisz mountpointy tak:

df -hT

Warto porównać wynik z tym, co widzisz w Zabbixie. Szczególnie przy serwerach z dodatkowymi dyskami, udziałami sieciowymi, katalogami aplikacji albo osobnym /var.

Progi alertów

Najprostsze progi mogą wyglądać tak:

• warning przy 80% zajętości,
• high przy 90%,
• disaster przy 95% albo mniej, jeśli partycja jest mała.

To nie jest uniwersalna reguła. Dla małej partycji systemowej 90% może oznaczać kilkaset megabajtów wolnego miejsca. Dla dużej partycji danych może to być jeszcze spory zapas.

Dlatego przy ważniejszych serwerach warto mieć osobne podejście do:

• /,
• /var,
• /var/log,
• katalogów baz danych,
• katalogów backupu,
• partycji aplikacyjnych.

Nie zapomnij o inode

Alert na miejsce na dysku nie zastępuje alertu na inode. To osobna rzecz.

Na serwerze sprawdzisz to poleceniem:

df -i

Jeżeli użycie inode rośnie szybko, trzeba znaleźć katalogi z dużą liczbą plików. Pomocne może być takie podejście:

sudo find /var -xdev -type f | cut -d/ -f1-4 | sort | uniq -c | sort -nr | head

To nie jest komenda do bezmyślnego odpalania na każdym systemie w godzinach szczytu, ale przy diagnostyce potrafi szybko pokazać kierunek.

Mountpointy, które znikają

Osobny problem to mountpointy z NFS, SMB, iSCSI albo dodatkowych dysków. Jeżeli taki zasób się odmontuje, aplikacja może zacząć zapisywać dane w pustym katalogu lokalnym. Z zewnątrz wygląda to czasem jak normalna praca, dopóki nie zabraknie miejsca na partycji systemowej.

Warto monitorować nie tylko wolne miejsce, ale też fakt, czy dany mountpoint jest naprawdę zamontowany.

Na serwerze można to sprawdzić:

mountpoint /mnt/dane

W Zabbixie można to rozwiązać przez gotowe itemy z templatek albo własny user parameter, zależnie od środowiska.

Przykład własnego sprawdzenia

Jeżeli chcesz mieć proste sprawdzenie konkretnego katalogu, można przygotować user parameter. Przykład koncepcyjny:

UserParameter=custom.mountpoint.check[*],mountpoint -q "$1" && echo 1 || echo 0

Po zmianie konfiguracji agenta trzeba go zrestartować:

sudo systemctl restart zabbix-agent2

Potem test z serwera Zabbix:

zabbix_get -s ADRES_HOSTA -k custom.mountpoint.check[/mnt/dane]

Wynik 1 oznacza, że mountpoint jest zamontowany. Wynik 0 powinien uruchomić alert.

Co sprawdzić po dodaniu alertów

Po ustawieniu monitoringu dysku warto zrobić prosty przegląd:

• czy Zabbix widzi wszystkie ważne partycje,
• czy ignoruje pseudo-systemy plików, których nie chcesz alertować,
• czy progi mają sens dla rozmiaru partycji,
• czy jest alert na inode,
• czy mountpointy krytyczne są monitorowane,
• czy alert trafia do właściwej osoby,
• czy wiadomo, co zrobić po takim alercie.

Sam alert „disk space is low” jest mało pomocny, jeśli nikt nie wie, który katalog rośnie i co można bezpiecznie usunąć.

Typowe przyczyny zapełnienia dysku

Najczęściej winne są:

• logi bez rotacji,
• backupy robione lokalnie bez sprzątania,
• cache aplikacji,
• pliki tymczasowe,
• stare obrazy Dockera,
• duże dumpy baz danych zostawione po migracji,
• aplikacja zapisująca dane w złym katalogu po awarii mountpointu.

Przy Dockerze warto sprawdzić:

docker system df

Ale czyszczenie Dockera rób świadomie. Komendy typu prune potrafią usunąć więcej, niż ktoś zakładał.

Na co uważać

• Nie ustawiaj progów tak wysoko, że alert przychodzi dopiero w momencie awarii.
• Nie ignoruj inode, szczególnie na serwerach z dużą liczbą małych plików.
• Nie monitoruj wszystkiego jednym progiem bez patrzenia na rozmiar partycji.
• Nie traktuj lokalnego backupu jako bezpiecznej kopii, jeśli zapełnia produkcyjny serwer.
• Nie kasuj plików w ciemno tylko dlatego, że są duże.

Podsumowanie

Monitoring dysku w Zabbixie powinien dawać czas na reakcję, a nie tylko potwierdzać awarię. Dobrze ustawiony monitoring sprawdza zajętość partycji, wolne miejsce, inode i ważne mountpointy.

Najważniejsze jest dobranie progów do konkretnego serwera. Inaczej monitoruje się mały VPS, inaczej serwer plików, a jeszcze inaczej host z bazą danych. Zabbix daje narzędzia, ale sensowne alerty trzeba dopasować do środowiska.

Zabbix Agent 2 to dobry wybór, jeśli chcesz monitorować serwer Ubuntu i mieć więcej możliwości niż przy klasycznym agencie. Samo zainstalowanie paczki to jednak dopiero początek. Trzeba jeszcze ustawić adres serwera Zabbix, nazwę hosta, firewall i sprawdzić, czy agent naprawdę odpowiada.

Ten wpis pokazuje praktyczną ścieżkę instalacji i pierwszej diagnostyki. Bez rozbudowanej teorii, raczej lista rzeczy, które administrator zwykle musi zrobić na świeżym serwerze.

Dla kogo jest ten wpis

Dla administratora, który ma serwer Ubuntu i chce dodać go do monitoringu Zabbix. Zakładam, że serwer Zabbix już istnieje, a my konfigurujemy tylko monitorowaną maszynę.

Nie zakładam konkretnej wersji Ubuntu ani Zabbixa, bo repozytoria i nazwy paczek mogą się różnić zależnie od wersji. Tego nie mogę potwierdzić na podstawie dostępnych danych. Przed wdrożeniem sprawdź aktualną dokumentację Zabbix dla swojej wersji.

Co warto przygotować przed instalacją

Przed wejściem na serwer przygotuj trzy informacje:

• adres IP albo DNS serwera Zabbix,
• nazwę hosta, która ma być widoczna w Zabbixie,
• informację, czy agent ma działać pasywnie, aktywnie, czy w obu trybach.

W małym środowisku często wystarcza tryb pasywny, gdzie serwer Zabbix odpytuje agenta. Przy większej liczbie hostów albo problemach z NAT-em przydaje się tryb aktywny.

Instalacja Zabbix Agent 2

Najpierw zaktualizuj listę pakietów:

sudo apt update

Jeśli repozytorium Zabbixa jest już dodane, instalacja agenta zwykle sprowadza się do:

sudo apt install zabbix-agent2

Jeżeli paczka nie jest dostępna, trzeba dodać oficjalne repozytorium Zabbix dobrane do wersji systemu i wersji Zabbixa. Nie warto zgadywać adresu paczki z pamięci, bo wersje zmieniają się w czasie.

Podstawowa konfiguracja

Główny plik konfiguracyjny agenta znajduje się zwykle tutaj:

/etc/zabbix/zabbix_agent2.conf

Edytujemy go:

sudo nano /etc/zabbix/zabbix_agent2.conf

Najważniejsze parametry do sprawdzenia:

Server=ADRES_SERWERA_ZABBIX
ServerActive=ADRES_SERWERA_ZABBIX
Hostname=NAZWA_HOSTA

Server określa, kto może odpytywać agenta pasywnie. ServerActive jest używany przy checkach aktywnych. Hostname powinien zgadzać się z nazwą hosta dodaną w panelu Zabbix, jeśli nie korzystasz z autorejestracji.

Restart i sprawdzenie usługi

Po zmianie konfiguracji restartujemy usługę:

sudo systemctl restart zabbix-agent2

Sprawdzamy status:

sudo systemctl status zabbix-agent2

Warto też od razu zobaczyć logi:

sudo journalctl -u zabbix-agent2 -n 50 --no-pager

Jeżeli agent nie startuje, log zwykle powie więcej niż sam status usługi.

Firewall na monitorowanym serwerze

Jeżeli używasz UFW i agent ma działać pasywnie, trzeba dopuścić połączenia z serwera Zabbix do portu agenta. Domyślnie jest to port 10050/tcp.

sudo ufw allow from ADRES_SERWERA_ZABBIX to any port 10050 proto tcp

Potem sprawdź reguły:

sudo ufw status numbered

Nie otwieraj portu dla całego internetu, jeśli nie musisz. Agent powinien być dostępny tylko z serwera monitoringu albo z konkretnej sieci administracyjnej.

Test połączenia z serwera Zabbix

Najprościej sprawdzić odpytywanie z poziomu serwera Zabbix, używając zabbix_get. Przykład:

zabbix_get -s ADRES_MONITOROWANEGO_SERWERA -k agent.ping

Poprawna odpowiedź dla agent.ping to zwykle:

1

Można też sprawdzić nazwę hosta:

zabbix_get -s ADRES_MONITOROWANEGO_SERWERA -k agent.hostname

Jeśli nie ma odpowiedzi, sprawdź po kolei: firewall, adres w parametrze Server, routing, DNS i logi agenta.

Dodanie hosta w panelu Zabbix

W panelu Zabbix dodaj nowego hosta i ustaw:

• nazwę hosta zgodną z konfiguracją agenta,
• grupę hostów,
• interfejs agenta z adresem IP albo DNS,
• template dla Linuxa.

Po zapisaniu hosta trzeba chwilę poczekać. Jeśli wszystko jest poprawnie ustawione, dostępność agenta powinna zmienić się na zieloną.

Najczęstsze problemy

Agent działa, ale Zabbix go nie widzi

Sprawdź firewall na monitorowanym serwerze i po drodze. Sprawdź też, czy w Server= jest właściwy adres serwera Zabbix.

W panelu jest zła nazwa hosta

Porównaj Hostname= w konfiguracji agenta z nazwą hosta w Zabbixie. Przy checkach aktywnych ta zgodność ma duże znaczenie.

Po zmianie konfiguracji nic się nie zmieniło

Sprawdź, czy usługa została zrestartowana:

sudo systemctl restart zabbix-agent2

Potem sprawdź log:

sudo journalctl -u zabbix-agent2 -n 100 --no-pager

Port jest otwarty dla wszystkich

To nie jest dobra praktyka. Ogranicz dostęp do portu agenta tylko do serwera Zabbix.

Co warto monitorować na start

Po dodaniu hosta nie trzeba od razu budować skomplikowanych dashboardów. Na początek wystarczy:

• dostępność agenta,
• CPU load,
• zużycie RAM,
• miejsce na dysku,
• inode,
• status ważnych usług,
• restarty systemu,
• czas działania serwera.

Najbardziej praktyczne alerty to zwykle te, które dają czas na reakcję: kończące się miejsce na dysku, niedostępna usługa albo serwer, który nagle przestał odpowiadać.

Przykład z praktyki

Typowy błąd przy wdrożeniu monitoringu wygląda tak: agent jest zainstalowany, usługa działa, ale w Zabbixie host jest niedostępny. Administrator sprawdza status usługi i wygląda dobrze, więc problem wydaje się dziwny.

Najczęściej winne są trzy rzeczy: firewall, zły adres w Server= albo inna nazwa hosta w konfiguracji niż w panelu. Dlatego warto testować po kolei: usługa, log, port, zabbix_get, panel.

Na co uważać

• Nie otwieraj portu 10050 dla całego internetu.
• Nie zakładaj, że zielona ikonka w panelu oznacza kompletny monitoring.
• Nie ignoruj logów agenta, bo często pokazują dokładny powód problemu.
• Nie mieszaj przypadkowych wersji repozytorium Zabbix i systemu.
• Nie dodawaj alertów, których nikt nie będzie obsługiwał.

Podsumowanie

Zabbix Agent 2 na Ubuntu Server można uruchomić szybko, ale warto zrobić to porządnie. Najważniejsze rzeczy to poprawny adres serwera Zabbix, zgodna nazwa hosta, ograniczony firewall i test połączenia z serwera monitoringu.

Dopiero potem ma sens dopracowywanie templatek, triggerów i dashboardów. Monitoring zaczyna działać naprawdę wtedy, gdy alert trafia do właściwej osoby i wiadomo, co z nim zrobić.