Sprawdź szczegóły:

W tym artykule pokażę, w jaki sposób skonfigurowałem monitoring udziałów sieciowych w Zabbixie. Celem było sprawdzanie, kiedy ostatnio zmieniły się pliki znajdujące się na zamontowanych zasobach sieciowych.

Dlaczego tak?

Największą zaletą takiego rozwiązania jest prostota. Nie trzeba instalować dodatkowych agentów na urządzeniu NAS ani integrować się bezpośrednio z systemem plików po stronie serwera. Wystarczy zamontować zasób sieciowy, uruchomić prosty skrypt i przekazać wynik do Zabbixa.
W tej konfiguracji nie monitorujemy zajętości dysku ani liczby plików. Monitorujemy czas ostatniej zmiany pliku w katalogu.Jest to szczególnie przydatne przy katalogach backupowych.

Taki monitoring może być bardzo przydatny na przykład wtedy, gdy na zasobie sieciowym znajdują się backupy, eksporty danych, pliki synchronizowane z innych systemów albo katalogi robocze, których aktywność chcemy kontrolować.

W moim przypadku monitorowane są dwa katalogi sieciowe:

/mnt/proxmox_root
/mnt/proxmox_root2

Zabbix będzie pobierał informację o najnowszej modyfikacji pliku w tych katalogach. Na tej podstawie można później zbudować trigger, który poinformuje nas, że backup lub zapis danych nie pojawił się od określonego czasu.

Założenie konfiguracji

Całość składa się z kilku etapów:

utworzenie lokalnych katalogów montowania,
dodanie usług systemd, które montują zasoby CIFS/SMB,
przygotowanie skryptów sprawdzających datę ostatniej modyfikacji pliku,
dodanie własnych parametrów do agenta Zabbixa,
utworzenie itemów w Zabbixie,
utworzenie triggerów alarmujących o braku nowych danych.

Dzięki temu Zabbix nie musi bezpośrednio „rozumieć” struktury udziału sieciowego. Wystarczy, że agent uruchomi lokalny skrypt i zwróci wartość liczbową.

Stworzenie katalogów

Na początku tworzymy katalogi, do których będą montowane udziały sieciowe.

mkdir -p /mnt/proxmox_root
mkdir -p /mnt/proxmox_root2

Opcja -p powoduje, że katalog zostanie utworzony tylko wtedy, gdy jeszcze nie istnieje. Jeżeli katalog już istnieje, polecenie nie zwróci błędu.

Te katalogi będą lokalnymi punktami montowania dla udziałów CIFS/SMB.

Dodanie nowych serwisów systemd

Kolejnym krokiem jest utworzenie usług systemd, które będą odpowiadały za montowanie udziałów sieciowych.

Pierwszy plik usługi:

nano /etc/systemd/system/mount-proxmox.service

Zawartość:

[Unit]
Description=Mount Proxmox CIFS share
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/mount -t cifs //192.168.1.7/Public/proxmox_root /mnt/proxmox_root -o username=admin,password=<HASLO_DO_UDZIALU_SMB>
ExecStop=/bin/umount /mnt/proxmox_root

[Install]
WantedBy=multi-user.target

Ta usługa montuje udział:

//192.168.1.7/Public/proxmox_root

do lokalnego katalogu:

/mnt/proxmox_root

Ważne elementy konfiguracji:

After=network-online.target oznacza, że usługa powinna uruchomić się dopiero po dostępności sieci.

Wants=network-online.target informuje systemd, że ta usługa zależy od poprawnego uruchomienia sieci.

Type=oneshot oznacza, że usługa wykonuje jedną akcję i kończy proces.

RemainAfterExit=yes sprawia, że systemd traktuje usługę jako aktywną nawet po zakończeniu polecenia mount.

ExecStart wykonuje montowanie udziału CIFS.

ExecStop odmontowuje udział przy zatrzymaniu usługi.

Drugi plik usługi:

nano /etc/systemd/system/mount-proxmox2.service

Zawartość:

[Unit]
Description=Mount Proxmox CIFS share
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/mount -t cifs //192.168.1.7/Public/proxmox_root2 /mnt/proxmox_root2 -o username=admin,password=<HASLO_DO_UDZIALU_SMB>
ExecStop=/bin/umount /mnt/proxmox_root2

[Install]
WantedBy=multi-user.target

Druga usługa działa analogicznie, ale montuje inny udział sieciowy:

//192.168.1.7/Public/proxmox_root2

do katalogu:

/mnt/proxmox_root2

Uwaga bezpieczeństwa dotycząca hasła

W konfiguracji hasło znajduje się bezpośrednio w pliku usługi systemd.

Dokładnie ten moment:

<HASLO_DO_UDZIALU_SMB>

W środowisku produkcyjnym lepszą praktyką jest trzymanie danych dostępowych w osobnym pliku credentials z ograniczonymi uprawnieniami, ale w tym wpisie zostawiam tak, by nie komplikować głównego tematu. Jeżeli chcesz bym omówił szerzej temat zabezpieczania credentials to daj znać w komentarzu.

Włączenie usług

Po utworzeniu plików usług trzeba przeładować konfigurację systemd, włączyć usługi przy starcie systemu i uruchomić je ręcznie.

Włączenie usług

Po utworzeniu plików usług trzeba przeładować konfigurację systemd, włączyć usługi przy starcie systemu i uruchomić je ręcznie.

systemctl daemon-reload
systemctl enable mount-proxmox.service
systemctl enable mount-proxmox2.service
systemctl start mount-proxmox.service
systemctl start mount-proxmox2.service

systemctl daemon-reload informuje systemd, że pojawiły się nowe lub zmienione pliki usług.

systemctl enable dodaje usługę do autostartu, dzięki czemu montowanie zostanie wykonane po restarcie systemu.

systemctl start uruchamia usługę od razu, bez potrzeby restartowania serwera.

Po tym etapie udziały sieciowe powinny być widoczne w systemie jako lokalne katalogi.

Skrypty sprawdzające ostatnią zmianę plików

Następnie przygotowałem dwa skrypty. Każdy z nich sprawdza jeden katalog i zwraca timestamp najnowszej modyfikacji pliku.

Zabbix będzie później uruchamiał te skrypty przez agenta.

Pierwszy skrypt

Tworzymy plik:

nano /usr/local/bin/proxmox_root_last_change.sh

Zawartość:

# !/bin/bash

DIR="/mnt/proxmox_root"

if [ ! -d "$DIR" ]; then
  echo 0
  exit 1
fi

# Najnowsza modyfikacja w sekundach od 1970 (float)
latest_ts=$(find "$DIR" -type f -printf '%T@\n' 2>/dev/null | sort -n | tail -1)

# Jeśli katalog pusty lub błąd
if [ -z "$latest_ts" ]; then
  echo 0
else
  echo "$latest_ts"
fi

Ten skrypt wykonuje kilka prostych operacji.

Najpierw zmienna DIR wskazuje katalog, który ma być sprawdzany:

DIR="/mnt/proxmox_root"

Następnie skrypt sprawdza, czy katalog istnieje:

if [ ! -d "$DIR" ]; then
  echo 0
  exit 1
fi

Jeżeli katalog nie istnieje, skrypt zwraca 0 i kończy działanie z kodem błędu. Dzięki temu Zabbix dostanie informację, że nie udało się odczytać poprawnej wartości.

Najważniejsza część skryptu to polecenie:

latest_ts=$(find "$DIR" -type f -printf '%T@\n' 2>/dev/null | sort -n | tail -1)

Co ono robi?

find "$DIR" -type f szuka plików w podanym katalogu.

-printf '%T@\n' wypisuje czas ostatniej modyfikacji każdego pliku w formacie timestamp.

2>/dev/null ukrywa błędy, na przykład związane z brakiem dostępu do niektórych plików.

sort -n sortuje wyniki liczbowo.

tail -1 wybiera ostatni wynik, czyli najnowszą datę modyfikacji.

Jeżeli katalog jest pusty albo nie uda się znaleźć żadnych plików, skrypt zwraca 0.

Drugi skrypt

Drugi skrypt działa tak samo, ale sprawdza drugi katalog.

Tworzymy plik:

nano /usr/local/bin/proxmox_root_last_change2.sh

Zawartość:

# !/bin/bash

DIR="/mnt/proxmox_root2"

if [ ! -d "$DIR" ]; then
  echo 0
  exit 1
fi

# Najnowsza modyfikacja w sekundach od 1970 (float)
latest_ts=$(find "$DIR" -type f -printf '%T@\n' 2>/dev/null | sort -n | tail -1)

# Jeśli katalog pusty lub błąd
if [ -z "$latest_ts" ]; then
  echo 0
else
  echo "$latest_ts"
fi

Różnica jest tylko jedna: tutaj zmienna DIR wskazuje na katalog:

DIR="/mnt/proxmox_root2"

Dzięki temu można osobno monitorować dwa różne zasoby sieciowe.

Nadanie uprawnień do skryptów

Po utworzeniu skryptów trzeba nadać im prawa wykonywania.

chmod +x /usr/local/bin/proxmox_root_last_change.sh
chmod +x /usr/local/bin/proxmox_root_last_change2.sh

Bez tego Zabbix Agent może nie być w stanie uruchomić tych plików jako komend.

Dodanie parametrów do agenta Zabbix

Teraz trzeba poinformować agenta Zabbix, że ma udostępniać nowe własne parametry.

Wchodzimy w edycję konfiguracji agenta:

nano /etc/zabbix/zabbix_agentd.conf

I dodajemy:

UserParameter=backup_ostatniazmiana,/usr/local/bin/proxmox_root_last_change.sh
UserParameter=backup_ostatniazmiana2,/usr/local/bin/proxmox_root_last_change2.sh

UserParameter pozwala dodać własny klucz monitorujący do Zabbix Agenta.

Pierwszy parametr:

UserParameter=backup_ostatniazmiana,/usr/local/bin/proxmox_root_last_change.sh

tworzy klucz:

backup_ostatniazmiana

który uruchamia skrypt:

/usr/local/bin/proxmox_root_last_change.sh

Drugi parametr:

UserParameter=backup_ostatniazmiana2,/usr/local/bin/proxmox_root_last_change2.sh

tworzy analogiczny klucz dla drugiego katalogu.

Po zmianie konfiguracji agenta warto zrestartować usługę Zabbixa:

systemctl restart zabbix-agent

Jeżeli używasz Zabbix Agent 2, usługa może nazywać się inaczej:

systemctl restart zabbix-agent2

Dodanie itemów w Zabbixie

Po stronie panelu Zabbixa trzeba dodać itemy, które będą korzystały z utworzonych wcześniej kluczy.

Dodajemy takie itemy:

W praktyce tworzymy dwa itemy:

backup_ostatniazmiana
backup_ostatniazmiana2

Każdy item powinien odpytwać agenta Zabbix na monitorowanym hoście i pobierać wartość zwracaną przez odpowiedni skrypt.

Wartością zwracaną przez skrypt jest timestamp ostatniej modyfikacji pliku. Jest to liczba, którą później można porównać z aktualnym czasem.

Dzięki temu Zabbix może sprawdzić, ile czasu minęło od ostatniej zmiany w monitorowanym katalogu.

Dodanie triggerów

Po utworzeniu itemów można dodać triggery.

Dodajemy takie triggery jak niżej. Oczywiście, opis zmieniasz według własnego uznania. Możesz też zmienić przedział czasowy, po którym wywoływany jest trigger.

Trigger powinien sprawdzać, czy od ostatniej zmiany w katalogu minęło zbyt dużo czasu.

Przykładowo: jeżeli w katalogu z backupami pliki powinny pojawiać się codziennie, trigger może zgłaszać problem, gdy ostatnia modyfikacja jest starsza niż 24 godziny.

Dzięki temu Zabbix może wykryć sytuację, w której:

backup przestał się wykonywać,
udział sieciowy nie został poprawnie zamontowany,
dane nie są już aktualizowane,
skrypt nie znajduje żadnych plików,
katalog jest niedostępny.

To bardzo prosta metoda monitorowania, ale w praktyce może szybko wykryć poważny problem.

Co dokładnie monitorujemy?

W tej konfiguracji nie monitorujemy zajętości dysku ani liczby plików. Monitorujemy czas ostatniej zmiany pliku w katalogu.

Jest to szczególnie przydatne przy katalogach backupowych.

Jeżeli backup działa poprawnie, w katalogu powinny regularnie pojawiać się nowe lub zmodyfikowane pliki. Jeżeli przez długi czas nic się nie zmienia, może to oznaczać problem.

Zabbix dostaje więc nie informację typu „backup się udał”, ale bardzo praktyczny sygnał:

Czy w katalogu backupowym pojawiła się jakakolwiek świeża aktywność?

W wielu środowiskach to wystarczy, żeby wykryć awarię szybciej niż użytkownicy.

Podsumowanie

W tej konfiguracji udało się połączyć kilka prostych mechanizmów Linuksa i Zabbixa:

montowanie udziałów CIFS/SMB przez systemd,
lokalne punkty montowania w /mnt,
skrypty Bash sprawdzające ostatnią modyfikację plików,
własne parametry UserParameter w agencie Zabbix,
itemy pobierające dane,
triggery alarmujące o braku świeżych zmian.

Największą zaletą takiego rozwiązania jest prostota. Nie trzeba instalować dodatkowych agentów na urządzeniu NAS ani integrować się bezpośrednio z systemem plików po stronie serwera. Wystarczy zamontować zasób sieciowy, uruchomić prosty skrypt i przekazać wynik do Zabbixa.

To dobre rozwiązanie do monitorowania backupów, eksportów danych i katalogów, w których regularnie powinny pojawiać się nowe pliki.

Sprawdź szczegóły:

https://asdevops.pl/1