Opublikowane w przez Tomasz

Monitoring dysku w Zabbixie: miejsce, inode i mountpointy

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.

☕ Postaw mi kawę