Macierz RAID może wyglądać na sprawną, podczas gdy jeden z jej dysków po cichu się pogarsza. Może też ulec degradacji, mimo że pozostałe dyski nadal zgłaszają status SMART PASSED.
Dobre monitorowanie wymaga więc czegoś więcej niż jednej zielonej kontrolki stanu. Najlepsza konfiguracja serwera domowego monitoruje macierz, dyski fizyczne, odbudowy lub operacje scrub oraz alerty informujące o zmianach.
Monitorowanie RAID to coś więcej niż SMART
Stan RAID i stan dysków odpowiadają na różne pytania.
Monitor macierzy informuje, czy system pamięci masowej nadal ma oczekiwanych członków, czy utracono nadmiarowość oraz czy trwa odbudowa, ponowna synchronizacja, scrub lub operacja sprawdzania spójności.
Monitorowanie SMART zagląda pod macierz, analizując poszczególne dyski HDD, SSD i NVMe. Może ujawnić temperaturę, błędy nośnika, sektory oczekujące, sektory realokowane, wytrzymałość, wyniki autotestów i inne sygnały na poziomie urządzenia.
Monitorowanie RAID
|
+-- Stan macierzy
| Sprawny / Zdegradowany / Offline
|
+-- Stan dysków
| SMART / NVMe / Temperatura
|
+-- Odzyskiwanie
| Odbudowa / Ponowna synchronizacja / Scrub
|
+-- Historia
| Trendy / Błędy / Pojemność
|
+-- Alerty
E-mail / Push / Webhook / Czat
To rozróżnienie ma znaczenie, ponieważ sprawna macierz może zawierać pogarszający się dysk, a zdegradowana macierz może nadal zawierać kilka pojedynczych dysków, których stan SMART pozostaje prawidłowy.
Podstawowy model RAID omówiono bardziej szczegółowo w artykule jak działa RAID, ale monitorowanie zaczyna się od prostszej zasady: monitoruj zarówno macierz, jak i znajdujące się pod nią dyski.
Co właściwie powinno monitorować narzędzie do monitorowania RAID?
Przydatne narzędzie do monitorowania serwera domowego powinno obejmować tyle z tych warstw, ile wymaga jego rola:
| Warstwa | Ważne sygnały | Dlaczego to ma znaczenie |
|---|---|---|
| Stan macierzy | Sprawny, zdegradowany, offline, brakujący członek | Pokazuje, czy nadmiarowość nadal istnieje |
| Dyski fizyczne | SMART, temperatura, stan NVMe, zużycie | Może ujawnić pogarszający się stan dysku przed awarią macierzy |
| Odzyskiwanie | Odbudowa, ponowna synchronizacja, resilver, scrub, sprawdzanie spójności | Pokazuje, czy nadmiarowość jest przywracana lub weryfikowana |
| Błędy | Błędy wejścia/wyjścia, błędy sum kontrolnych, sektory niekorygowalne | Dostarcza dowodów na zmiany niezawodności pamięci masowej |
| Pojemność | Wykorzystanie puli, systemu plików i dysków | Zapobiega przekształceniu się wyczerpania miejsca w awarię |
| Historia | Temperatura, atrybuty SMART, trendy błędów | Pokazuje stopniowe pogarszanie się stanu zamiast jednego bieżącego obrazu |
| Alerty | E-mail, webhook, powiadomienia push, czat, eskalacja | Pulpit jest bezużyteczny, jeśli nikt nie otworzy go po wystąpieniu awarii |
Jak uszeregowaliśmy najlepsze narzędzia do monitorowania RAID
To nie jest ranking najładniejszych pulpitów. Poniższe narzędzia rozwiązują różne problemy w stosie monitorowania.
Oceniliśmy je na podstawie pięciu praktycznych pytań:
- Co faktycznie monitoruje? Stan macierzy, poszczególne dyski, pule ZFS, sprzętowy RAID czy cały serwer?
- Czy zachowuje historię? Powoli rosnąca liczba błędów jest często bardziej użyteczna niż jedna bieżąca wartość.
- Czy może wysyłać alerty bez ręcznego sprawdzania? Monitorowanie powinno proaktywnie sygnalizować problemy.
- Jak trudno jest je wdrożyć? Pojedynczy domowy serwer NAS nie powinien wymagać infrastruktury obserwowalności klasy enterprise, chyba że użytkownik tego chce.
- Czy uzupełnia natywne narzędzia RAID? Najlepsze konfiguracje zwykle łączą monitorowanie macierzy z warstwą monitorowania stanu dysków.
Kolejność liczbowa ma charakter redakcyjny, a nie stanowi syntetycznego wyniku testu porównawczego.
10 najlepszych narzędzi do monitorowania RAID dla domowych serwerów — przegląd
| Ranking | Narzędzie | Najlepsze zastosowanie | Stan macierzy | Stan dysku | Historia | Poziom trudności |
|---|---|---|---|---|---|---|
| 1 | Netdata | Jeden pulpit domowego serwera | Tak | Tak | Tak | Od niskiej do średniej |
| 2 | Scrutiny | Trendy stanu SMART | Nie | Doskonałe | Doskonałe | Niska |
| 3 | smartmontools | Podstawowe monitorowanie dysków | Nie | Doskonałe | Ograniczone bez dodatkowej warstwy | Niska |
| 4 | Monitor mdadm | Programowa macierz RAID w systemie Linux | Doskonałe | Nie | Zorientowane na zdarzenia | Niska |
| 5 | OpenZFS ZED | Zdarzenia puli ZFS | Doskonale sprawdza się w przypadku ZFS | Pośrednie | Zorientowane na zdarzenia | Od niskiej do średniej |
| 6 | Cockpit Storage | Przyjazny dla początkujących interfejs GUI systemu Linux | Tak | Tak | Ograniczona | Niska |
| 7 | Prometheus + Grafana | Długoterminowe niestandardowe metryki | Z eksporterami | Doskonałe | Doskonałe | Wysoka |
| 8 | Checkmk | Wiele domowych serwerów | Z kontrolami/wtyczkami | Tak | Tak | Średnia |
| 9 | StorCLI | Sprzętowy RAID LSI/Broadcom | Doskonałe | Doskonale sprawdza się w przypadku dysków kontrolera | Zorientowane na CLI | Średnia |
| 10 | Zabbix | Zaawansowane niestandardowe alerty | Z szablonami/skryptami | Tak | Doskonałe | Wysoka |
1. Netdata — najlepszy ogólny pulpit do monitorowania RAID
Netdata to najlepszy wybór ogólny, gdy chcesz mieć jedną warstwę monitorowania systemu pamięci masowej i pozostałej części domowego serwera.
Obecne kolektory pamięci masowej obejmują kilka architektur istotnych dla użytkowników RAID.
W przypadku programowej macierzy RAID w systemie Linux kolektor MD RAID odczytuje /proc/mdstat i śledzi urządzenia MD. W przypadku dysków fizycznych Netdata ma kolektor SMART oparty na narzędziu smartctl. Jego kolektor puli ZFS monitoruje stan i przestrzeń puli za pośrednictwem zpool, natomiast kolektor StoreCLI RAID może monitorować obsługiwane sprzętowe adaptery RAID, dyski fizyczne i baterie podtrzymujące.
Ta szeroka funkcjonalność daje Netdata przewagę nad wąsko ukierunkowanymi pulpitami SMART.
MD RAID
SMART
ZFS
Sprzętowa macierz RAID
Systemy plików
CPU
Pamięć RAM
Sieć
Kontenery
|
Netdata
|
Jeden pulpit
Pojedynczy agent Netdata może działać niezależnie i udostępniać lokalny pulpit na porcie 19999Łączność z chmurą jest opcjonalna dla samego agenta monitorującego, chociaż Netdata Cloud dodaje scentralizowane widoki i dodatkowe funkcje obsługi wielu węzłów.
Dzięki temu Netdata jest szczególnie przydatna na serwerze domowym, gdzie monitoring pamięci masowej powinien znajdować się obok informacji o obciążeniu systemu, presji na pamięć RAM, pojemności systemu plików, aktywności Dockera i wydajności sieci.
Najlepsze dla: użytkowników, którzy chcą mieć jeden pulpit obejmujący RAID oraz pozostałą część serwera.
Kompromis: Netdata ma szeroki zakres zastosowań, zamiast skupiać się obsesyjnie na dyskach. Scrutiny zapewnia czytelniejszy widok, gdy celem jest badanie atrybutów SMART i długoterminowego pogarszania się stanu fizycznych dysków.
2. Scrutiny — najlepsze narzędzie do wykrywania trendów kondycji dysków

Scrutiny to jeden z najbardziej użytecznych dodatków do domowego serwera NAS, ponieważ eliminuje kilka słabości surowego monitorowania SMART.
SMART udostępnia dużą liczbę atrybutów, ale nie każdy atrybut jest równie użyteczny. Progi producenta mogą być również na tyle zachowawcze, że dysk może wyglądać na „sprawny”, dopóki awaria nie będzie stosunkowo blisko.
Scrutiny łączy dane SMART z interfejsem Web UI, przechowywaniem historycznych trendów, śledzeniem temperatury oraz dodatkowymi progami opartymi na rzeczywistych danych o awariach dysków.
Umożliwia to zadawanie takich pytań jak:
Liczba sektorów oczekujących
Styczeń 0
Marzec 0
Czerwiec 2
Sierpień 8
Pojedynczy aktualny raport SMART informuje, że wartość wynosi osiem. Scrutiny pokazuje, że ten parametr zmierzał w niewłaściwym kierunku.
Obsługuje również konfigurowalne powiadomienia przez e-mail, webhooki, ntfy, Gotify, Slack, Discord, Telegram i inne usługi.
Obsługa kontrolerów RAID zależy od tego, czy smartctl można uzyskać dostęp do fizycznych dysków znajdujących się niżej w stosie. Z tego powodu Scrutiny opisuje przekazywanie urządzeń przez kontroler oraz mapowanie urządzeń w Dockerze.
Ważne ograniczenie jest równie jasne:
Scrutiny monitoruje dyski, a nie samą macierz RAID.
Macierz Linux MD nadal należy monitorować za pomocą mdadm lub innej warstwy świadomej struktury macierzy. Pula ZFS nadal powinna mieć monitoring właściwy dla ZFS.
Najlepsze dla: serwerów domowych z wieloma dyskami HDD lub SSD, w przypadku których istotne są historyczne trendy SMART i temperatury.
Kompromis: nie należy uznawać rzędu sprawnych dysków w Scrutiny za dowód, że macierz RAID jest sprawna.
Warstwa monitorowania kondycji dysków zależy również od samych dysków. Wybór odpowiednich dysków NAS ogranicza możliwe do uniknięcia problemy podczas odbudowy i ciągłej pracy 24/7.
3. smartmontools — najlepsza podstawa monitorowania dysków HDD, SSD i NVMe
smartmontools jest znacznie mniej efektowny wizualnie niż Scrutiny, ale ma bardziej fundamentalne znaczenie.
Projekt udostępnia dwa podstawowe narzędzia:
smartctl
|
Analizowanie i testowanie dysku
smartd
|
Nieprzerwane monitorowanie dysków
smartctl może analizować informacje SMART i dane dotyczące kondycji urządzeń ATA/SATA, SCSI/SAS oraz NVMe, a także uruchamiać autotesty dysków. smartd działa jako demon i nieprzerwanie sprawdza urządzenia pod kątem skonfigurowanych warunków kondycji.
Wiele narzędzi monitorowania wyższego poziomu ostatecznie korzysta z tych danych. Kolektor SMART w Netdata wymaga smartmontools, Scrutiny buduje warstwę kondycji dysków wokół danych smartctl, a eksportery smartctl dla Prometheusa korzystają z tego samego interfejsu.
Projekt nadal się rozwija. Bieżący dziennik zmian upstream wymienia smartmontools 8.0 jako następną, jeszcze niewydaną generację po wersji 7.5.
W przypadku lekkiego domowego serwera smartd może być wszystkim, czego potrzebujesz:
Dysk
|
SMART
|
smartd
|
Alert
Nie potrzebujesz koniecznie osobnej bazy danych, pulpitu nawigacyjnego i stosu metryk, aby dowiedzieć się, że dysk przekroczył istotny próg.
Najlepsze dla: użytkowników, którzy chcą lekkiej, dojrzałej podstawy do monitorowania stanu fizycznych dysków i automatycznych testów.
Kompromis: dane wyjściowe wiersza poleceń są mniej przystępne niż w Scrutiny lub Cockpit, a sam smartd nie zapewnia równie przejrzystej analizy historycznej.
4. Monitor mdadm — najlepszy natywny monitor programowego RAID-u w systemie Linux
Jeśli macierz jest macierzą Linux MD RAID, mdadm powinien pozostać częścią planu monitorowania, nawet jeśli zainstalowano Netdata lub inny pulpit nawigacyjny.
mdadm --monitor rozumie samą macierz.
Może zgłaszać takie zdarzenia jak:
- awaria urządzenia;
- zdegradowane macierze;
- aktywacja dysku zapasowego;
- zniknięcie urządzenia;
- rozpoczęcie odbudowy;
- postęp odbudowy;
- zakończenie odbudowy.
To uzupełnia lukę pozostawioną przez SMART:
smartd
|
Czy dyski działają prawidłowo?
mdadm --monitor
|
Czy macierz RAID działa prawidłowo?
W przypadku minimalnego domowego serwera z systemem Linux połączenie monitorowania mdadm z smartd tworzy zaskakująco wydajny system monitorowania bez konieczności dodawania rozbudowanego stosu webowego.
Najlepsze dla: serwerów Debian, Ubuntu i innych serwerów z systemem Linux opartych na macierzach MD RAID 1, 5, 6 lub 10.
Kompromis: mdadm koncentruje się na programowym RAID w systemie Linux, a nie na ZFS, sprzętowym RAID-zie czy graficznej analizie długoterminowej.
5. OpenZFS ZED — najlepsze natywne monitorowanie zdarzeń pul ZFS
Użytkownicy ZFS powinni monitorować ZFS jako ZFS, zamiast próbować mapować każde zdarzenie na tradycyjną terminologię RAID.
ZED, demon zdarzeń ZFS, monitoruje zdarzenia generowane przez moduł jądra ZFS i uruchamia skonfigurowane działania ZEDLET, gdy pojawią się pasujące klasy zdarzeń.
Zależność między elementami monitorowania wygląda następująco:
Jądro ZFS
|
zevents
|
ZED
|
Działania ZEDLET
|
Powiadomienia / automatyzacja
Dzięki temu ZED nadaje się do obsługi zdarzeń pul i urządzeń, które dotyczą samego ZFS, a nie zewnętrznego pulpitu nawigacyjnego dysków.
Kompletny stos ZFS dla domowego serwera może zatem obejmować:
ZED
|
Zdarzenia puli
smartd / Scrutiny
|
Kondycja dysków fizycznych
Netdata / Grafana
|
Pulpit nawigacyjny i historia
Najlepsze dla: użytkowników TrueNAS, OpenZFS lub ZFS w systemach Linux/BSD, którzy chcą natywnej obsługi zdarzeń dotyczących pul.
Kompromis: ZED to demon zdarzeń, a nie dopracowany, kompleksowy pulpit nawigacyjny. Jeśli ważna jest długoterminowa wizualizacja, połącz go z inną warstwą.
6. Cockpit Storage — najlepszy graficzny interfejs do monitorowania RAID dla początkujących użytkowników Linuksa

Cockpit to jeden z najłatwiejszych sposobów dodania przeglądarkowego interfejsu administracyjnego do zwykłego serwera z Linuksem.
Aplikacja Pamięć masowa obsługuje dyski lokalne, partycje, RAID, szyfrowanie, NFS, iSCSI i inne typowe operacje związane z pamięcią masową.
Cockpit dodał również informacje o kondycji urządzeń SMART do strony Pamięć masowa, w tym możliwość uruchamiania autotestów dysków z poziomu przeglądarki.
Dzięki temu jest dobrym rozwiązaniem dla początkujących na serwer, który poza tym wygląda tak:
Ubuntu / Debian / Fedora
|
Cockpit
|
Przeglądarkowy interfejs pamięci masowej
|
RAID + SMART + punkty montowania
Jest szczególnie przydatny, gdy użytkownik chce zarządzać pamięcią masową, a nie tworzyć dedykowany stos obserwowalności.
Najlepsze dla: początkujących użytkowników Linuksa, którzy chcą mieć informacje o stanie macierzy RAID i dysków w przejrzystym interfejsie do zarządzania serwerem.
Kompromis: Cockpit lepiej sprawdza się w wyświetlaniu i zarządzaniu bieżącym stanem serwera niż w przechowywaniu szczegółowej historii SMART z wielu miesięcy.
7. Prometheus + smartctl_exporter + Grafana — najlepsze rozwiązanie do długoterminowych metryk
Gdy monitorowanie samo w sobie staje się hobby, stos Prometheus zapewnia znacznie większą kontrolę niż pulpit nawigacyjny NAS przeznaczony do konkretnego celu.
Oficjalny smartctl_exporter konwertuje statystyki smartctl na metryki Prometheus. Wymaga smartmontools w wersji 7.0 lub nowszej, ponieważ korzysta z danych wyjściowych JSON programu smartctl.
Architektura jest modułowa:
Eksportery SMART / RAID / ZFS
|
Prometheus
|
Grafana
|
Panele i alerty
Dodatkowe eksportery lub metryki węzłów mogą dodać:
- pojemność systemu plików;
- operacje wejścia-wyjścia dysku;
- pule ZFS;
- stan macierzy MD RAID;
- temperatura;
- obciążenie serwera;
- metryki zasilacza UPS;
- aktywność sieciowa.
To najlepsza opcja, gdy chcesz odpowiadać na pytania dotyczące historii, a nie tylko sprawdzać bieżący stan.
Na przykład:
- Czy temperatura dysków wzrosła podczas ostatniej odbudowy macierzy RAID?
- Kiedy po raz pierwszy pojawiły się niekorygowalne błędy?
- Czy opóźnienia pamięci masowej zmieniły się po dodaniu kolejnego dysku?
- Jak szybko wzrosło wykorzystanie puli w ciągu ostatniego roku?
Alerty Grafany mogą również oceniać reguły oparte na Prometheusie i kierować powiadomienia, gdy warunki zostaną spełnione.
Najlepsze zastosowanie: entuzjaści, którzy chcą korzystać z długoterminowych metryk, niestandardowych pulpitów, korelacji i elastycznych alertów.
Kompromis: Prometheus + eksportery + Grafana wymagają znacznie większej konfiguracji niż Scrutiny lub Netdata. W przypadku jednego prostego domowego NAS-a ta złożoność może przynieść niewielkie praktyczne korzyści.
8. Checkmk — najlepszy wybór do monitorowania wielu serwerów domowych
Checkmk staje się bardziej atrakcyjny, gdy domowe laboratorium obejmuje więcej niż jedną maszynę.
Zamiast myśleć wyłącznie o NAS-ie, możesz mieć:
NAS
Serwer kopii zapasowych
Host Proxmox
Mini PC
Router
UPS
Przełącznik
|
Checkmk
Agent Checkmk dla systemu Linux obsługuje monitorowanie sprzętu za pomocą wtyczek, w tym wartości SMART z nowoczesnych dysków HDD i SSD.
Dokumentacja wyraźnie uwzględnia również dyski ukryte za obsługiwanymi kontrolerami RAID. W zależności od kontrolera narzędzia takie jak smartmontools, tw_clilub narzędzia MegaRAID mogą być wymagane, zanim Checkmk uzyska dostęp do informacji o urządzeniach bazowych.
Jeszcze większą zaletą jest scentralizowane zarządzanie: wiele hostów, stany usług, reguły alertów, wykresy, inwentaryzacja, pojemność i monitorowanie systemu mogą znajdować się w jednym interfejsie.
Najlepsze zastosowanie: domowe laboratoria, w których stan pamięci masowej trzeba monitorować razem z kilkoma serwerami Linux i urządzeniami infrastruktury.
Kompromis: Checkmk jest zbędnym obciążeniem w przypadku pojedynczego NAS-a, jeśli Netdata lub natywne monitorowanie systemu operacyjnego już obejmuje najważniejsze sygnały awarii.
9. StorCLI — najlepszy wybór dla sprzętowego RAID LSI i Broadcom
Sprzętowy RAID wymaga innego podejścia do monitorowania, ponieważ system operacyjny może widzieć jeden dysk wirtualny, podczas gdy kontroler zarządza kilkoma fizycznymi dyskami znajdującymi się pod nim.
System operacyjny
|
Dysk wirtualny
|
Kontroler RAID
|
+-----+-----+-----+
Dysk 1 Dysk 2 Dysk 3
StorCLI to narzędzie firmy Broadcom do zarządzania z poziomu wiersza poleceń obsługiwanymi kontrolerami RAID LSI/Broadcom.
Może sprawdzać stan kontrolera, dyski wirtualne, dyski fizyczne, operacje odbudowy, informacje o obudowie, pamięć podręczną oraz obsługiwane komponenty baterii lub zasilania awaryjnego.
Status sprzętowego RAID może obejmować takie stany jak:
- Optymalny;
- Częściowo zdegradowany;
- Zdegradowany;
- Niedostępny.
Widoczność na poziomie kontrolera jest niezbędna, ponieważ ogólne narzędzia SMART mogą nie wykrywać automatycznie dysków należących do macierzy za pośrednictwem każdego kontrolera RAID.
Przydatne połączenie narzędzi do monitorowania to:
RAID Broadcom / LSI
|
StorCLI
|
Netdata
|
Pulpit nawigacyjny + alerty
Kolektor StoreCLI w Netdata może pobierać informacje o kontrolerze i umieszczać je obok pozostałych metryk serwera.
Najlepsze dla: serwerów domowych korzystających z obsługiwanych sprzętowych kontrolerów Broadcom, LSI lub MegaRAID.
Kompromis: StorCLI to narzędzie administracyjne specyficzne dla kontrolera, a nie uniwersalny pulpit nawigacyjny serwera domowego.
10. Zabbix — najlepszy do zaawansowanego alarmowania RAID i automatyzacji
Zabbix to najbardziej ukierunkowana na infrastrukturę opcja na tej liście.
Obecne szablony Agent 2 zawierają oficjalne monitorowanie SMART, a stan macierzy i kontrolera można dodać za pomocą obsługiwanych integracji, niestandardowych elementów, skryptów lub szablonów odpowiednich dla danego środowiska.
Większe wdrożenie Zabbiksa może łączyć:
SMART
RAID
ZFS
System plików
UPS
Temperatura
Sieć
Usługi
|
Zabbix
|
Historia
Wyzwalacze
Powiadomienia
Eskalacja
Siłą tego rozwiązania nie jest dedykowany ekran RAID. Jest nią możliwość dokładnego zdefiniowania, co oznacza awarię i co powinno nastąpić później.
Na przykład jedno ostrzeżenie może zostać skierowane do zwykłego kanału powiadomień, podczas gdy zdegradowana macierz lub niedostępny dysk wirtualny uruchomi pilniejszą eskalację.
Najlepsze dla: zaawansowanych użytkowników, którzy już korzystają z Zabbiksa lub chcą tworzyć szczegółowe reguły alertów i automatyzacji dla wielu systemów.
Kompromis: konfiguracja jest skomplikowana. Instalowanie Zabbiksa wyłącznie do monitorowania dwóch dysków w jednym domowym NAS-ie jest zwykle niepotrzebne.
Z którego narzędzia do monitorowania RAID naprawdę należy korzystać?
| Jeśli chcesz... | Zacznij od | Dlaczego |
|---|---|---|
| Jeden pulpit nawigacyjny dla serwera domowego | Netdata | Obsługuje MD RAID, SMART, ZFS, sprzętowy RAID i metryki systemowe |
| Szczegółowa historia stanu dysku | Scrutiny | Monitorowanie trendów SMART, temperatury, progów i powiadomień |
| Lekkie monitorowanie dysków | smartmontools | Dojrzałe narzędzia wiersza poleceń bez rozbudowanego stosu monitorowania |
| Zdarzenia programowego RAID-u w systemie Linux | Monitor mdadm | Rozpoznaje awarie, odbudowy i stany zdegradowania macierzy MD |
| Zdarzenia puli ZFS | OpenZFS ZED | Natywny demon zdarzeń dla ZFS |
| Prosty graficzny interfejs użytkownika pamięci masowej w systemie Linux | Cockpit | Zarządzanie RAID-em i stanem SMART w przeglądarce |
| Niestandardowe pulpity nawigacyjne z długoterminową historią | Prometheus + Grafana | Elastyczne metryki, historia, korelacja i alerty |
| Kilka serwerów domowych | Checkmk | Centralizuje monitorowanie hostów, usług, dysków i infrastruktury |
| Sprzętowy RAID LSI/Broadcom | StorCLI | Bezpośrednio odczytuje stan kontrolera, dysków wirtualnych i dysków fizycznych |
| Złożona automatyzacja alertów | Zabbix | Elastyczne reguły wyzwalania, szablony, historia i eskalacja |
Stan RAID-u a stan SMART: to nie to samo
To rozróżnienie jest ważniejsze niż wybór większości narzędzi w rankingu.
| Sygnał | Co to mówi | Czego to nie mówi |
|---|---|---|
| RAID: sprawny | Macierz ma obecnie wymaganą liczbę członów | Każdy dysk pozostanie sprawny |
| RAID: zdegradowany | Utracono nadmiarowość lub oczekiwaną przynależność | Dokładna fizyczna przyczyna w każdym przypadku |
| SMART: ZALICZONE | Dysk nie przekroczył stanu awarii SMART | Że każdy atrybut jest idealny |
| Sektory oczekujące | Sektory oczekują na pomyślne ponowne odczytanie lub ponowne przypisanie | Pełny stan macierzy RAID |
| Sektory ponownie przypisane | Dysk ponownie przypisał nieużywalne sektory | Czy macierz nadal ma nadmiarowość |
| Temperatura | Bieżące lub historyczne warunki termiczne | Czy system plików jest spójny |
| Postęp odbudowy | Jak daleko poszło przywracanie nadmiarowości | Czy stare kopie zapasowe można odzyskać |
| Błędy sum kontrolnych ZFS | ZFS wykrył problemy z integralnością | Każdy rodzaj podstawowej awarii mechanicznej |
Przydatny przykład:
mdadm:
Macierz sprawna
Scrutiny:
Dysk 3
Bieżący sektor oczekujący = 0 → 2 → 8
Macierz jeszcze nie uległa awarii, ale historia fizycznego dysku daje powód do sprawdzenia.
Może się też zdarzyć odwrotna sytuacja:
mdadm:
Zdegradowana macierz
smartctl:
Dysk 1: ZALICZONE
Dysk 2: ZALICZONE
Dysk 3: ZALICZONE
Brakujący człon mógł zniknąć z powodu okablowania, zasilania, problemów z kontrolerem, wykrywania urządzenia lub innej usterki, która nie jest sygnalizowana przez próg awarii SMART.
Monitorowanie mdadm, ZFS i sprzętowego RAID-u
Właściwe narzędzie do monitorowania zależy częściowo od tego, gdzie znajduje się logika RAID.
| Architektura pamięci masowej | Monitor natywny | Przydatna druga warstwa |
|---|---|---|
| Linux MD RAID | mdadm | Scrutiny / Netdata |
| OpenZFS | ZED / zpool | Scrutiny / Netdata / Grafana |
| Sprzętowy RAID LSI/Broadcom | StorCLI | Netdata / Checkmk |
| RAID urządzenia NAS | Wbudowane monitorowanie systemu NAS | Narzędzie SMART/historii, jeśli jest obsługiwane |
Dlatego układ pamięci masowej wpływa na architekturę monitorowania. Programowy RAID, ZFS i sprzętowy RAID udostępniają różne stany za pośrednictwem różnych warstw sterowania.
Scrutiny czy Netdata: co należy zainstalować?
Współpracują lepiej, niż gdyby działały przeciwko sobie.
| Obszar | Scrutiny | Netdata |
|---|---|---|
| Główny obszar | Stan dysków fizycznych | Monitorowanie całego serwera |
| Historia SMART | Doskonałe | Dostępne jako metryki |
| Trendy temperatury | Doskonałe | Tak |
| Stan macierzy MD RAID | Nie | Tak |
| Stan puli ZFS | Nie | Tak |
| Sprzętowa macierz RAID | Zależne od obsługi przekazywania danych SMART | Kolektor StoreCLI |
| CPU / RAM / sieć | Nie | Tak |
| Główna rola | Specjalistyczne narzędzie do dysków | Pulpit nawigacyjny serwera |
Proste połączenie dla domowego serwera wygląda więc następująco:
Netdata
|
Stan macierzy i serwera
Scrutiny
|
Trendy dotyczące dysków fizycznych
Jeśli chcesz używać tylko jednej aplikacji, Netdata obejmuje więcej warstw.
Jeśli system operacyjny NAS-a już dobrze monitoruje stan macierzy, Scrutiny może dostarczyć więcej nowych informacji, ponieważ zapewnia lepszy historyczny wgląd w stan dysków fizycznych.
Czy do domowego serwera NAS potrzebujesz Prometheusa i Grafany?
Zwykle nie.
Jeśli jedynym wymaganiem jest:
Powiadom mnie, gdy macierz RAID jest w stanie degradacji
Powiadom mnie, gdy dysk ulega awarii
wbudowane alerty macierzy wraz z smartd, Scrutiny lub Netdata mogą rozwiązać ten problem przy znacznie mniejszej infrastrukturze.
Prometheus i Grafana zaczynają mieć sens, gdy zależy Ci na:
- historia obejmująca miesiące lub lata;
- wiele serwerów;
- niestandardowe pulpity nawigacyjne;
- korelowanie temperatury z operacjami wejścia/wyjścia;
- śledzenie wzrostu zajętości pamięci masowej;
- łączenie danych RAID ze statystykami UPS, sieci, Dockera i hosta;
- niestandardowe reguły alertów PromQL.
Niewłaściwym powodem instalowania Grafany jest samo to, że pulpit nawigacyjny wygląda efektownie.
Właściwym powodem jest to, że masz pytania wymagające historii w ujęciu czasowym.
Jakie alerty RAID należy skonfigurować?
Monitorowanie staje się przydatne dopiero wtedy, gdy coś może dotrzeć do Ciebie bez konieczności wcześniejszego otwierania pulpitu nawigacyjnego.
Alerty macierzy
- macierz jest w stanie degradacji;
- macierz jest niedostępna;
- brakuje nieoczekiwanie członka macierzy;
- aktywowano dysk zapasowy;
- rozpoczęła się odbudowa lub ponowna synchronizacja;
- odbudowa nie powiodła się;
- odbudowa została ukończona.
Alerty dysków fizycznych
- ogólny stan SMART wskazuje awarię;
- liczba bieżących oczekujących sektorów wzrasta;
- liczba niekorygowalnych błędów offline wzrasta;
- liczba realokowanych sektorów znacząco wzrasta;
- krytyczne ostrzeżenie NVMe;
- wytrzymałość lub zużycie dysku SSD zbliża się do poziomu wymagającego wymiany;
- temperatura dysku utrzymuje się poza oczekiwanym zakresem.
Alerty ZFS
- pula jest w stanie degradacji;
- awaria urządzenia;
- liczba błędów sum kontrolnych rośnie;
- scrub wykrył błędy;
- rozpoczęło się odtwarzanie danych lub zakończyło się niepowodzeniem;
- pojemność puli zbliża się do wybranego progu.
Alerty sprzętowej macierzy RAID
- dysk fizyczny uległ awarii;
- dysk wirtualny jest w stanie degradacji;
- dysk wirtualny jest niedostępny;
- odbudowa zatrzymała się lub nie powiodła;
- awaria pamięci podręcznej kontrolera lub baterii podtrzymującej.
Nie należy bezkrytycznie kopiować dokładnych temperatur ani progów SMART z innego serwera. Różne modele dysków udostępniają różne atrybuty i mają różne zakresy pracy.
Ważniejsza jest sama zasada:
Pulpit nawigacyjny, którego nigdy nie otwierasz, nie jest monitorowaniem.
Test SMART a scrub i odbudowa: trzy różne zadania
Te operacje są często ze sobą mylone, ale sprawdzają różne rzeczy.
Autotest SMART
Test SMART jest wykonywany przez pojedyncze urządzenie pamięci masowej.
Jeden dysk
|
Test SMART
|
Wynik na poziomie urządzenia
Długi test SMART może przeskanować większą część powierzchni dysku niż test krótki, ale nie weryfikuje parzystości macierzy RAID ani kopii danych ZFS w całym systemie pamięci masowej.
RAID Rebuild or Resync
Odbudowa lub ponowna synchronizacja RAID
Odbudowa przywraca nadmiarowość po awarii lub wymianie członka macierzy.
|
Zdegradowany RAID
|
Dysk zastępczy
|
Odbudowa / ponowna synchronizacja
Nadmiarowość przywrócona
Jest to operacja odzyskiwania, a nie test stanu dysku.
Scrub ZFS lub kontrola spójności RAID
Odpowiada ono na inne pytanie:
> Czy przechowywane dane nadal odpowiadają informacjom o integralności i nadmiarowości, których oczekuje system pamięci masowej?Dlatego monitorowanie powinno ujawniać wszystkie trzy elementy, gdy architektura pamięci masowej je obsługuje.
Włącz natywne alerty NAS przed zainstalowaniem kolejnego panelu
Dedykowany system operacyjny NAS może już zapewniać pierwszą potrzebną warstwę monitorowania.
Na przykład bieżące zarządzanie pamięcią masową w ZimaOS pokazuje stan macierzy, kondycję dysków, dostępną pojemność oraz prędkości odczytu/zapisu w sekcji Ustawienia > Pamięć masowa. Awaria jednego z członków macierzy RAID zmienia jej stan na zdegradowany, a procedura odzyskiwania prowadzi użytkownika przez odbudowę po wymianie dysku.
ZimaOS udostępnia również informacje o postępie długotrwałych operacji RAID i kontroli parzystości oraz szczegółowe informacje o stanie dysków w interfejsie pamięci masowej.
Praktyczna kolejność powinna być zatem następująca:
1. Włącz natywne alerty NAS
|
2. Potwierdź wykrywanie zdegradowanej macierzy
|
3. Dodaj historię fizycznych dysków
|
4. Dodaj rozbudowany stos obserwowalności tylko wtedy, gdy jest przydatny
TrueNAS, Unraid, Synology, QNAP i inne platformy NAS również zapewniają natywne funkcje monitorowania stanu pamięci masowej, które należy skonfigurować przed dodaniem drugiego systemu monitorowania.
Dodatkowa warstwa powinna odpowiadać na pytanie, na które natywny interfejs użytkownika nie odpowiada wystarczająco dobrze.
Monitorowanie RAID nie zastępuje kopii zapasowej
Nawet idealny alert może poinformować o awarii dysku w ciągu kilku sekund.
Nie może przywrócić wczorajszej wersji usuniętego folderu.
Nie może odzyskać plików zaszyfrowanych już przez ransomware.
Nie może odtworzyć serwera NAS po kradzieży, pożarze ani katastrofalnej awarii kontrolera.
Dlatego RAID nie jest kopią zapasową.
RAID
|
Dostępność po awarii części dysków
Monitorowanie
|
Szybkie wykrywanie problemów
Kopia zapasowa
|
Odzyskiwanie utraconych lub uszkodzonych danych
Wszystkie trzy rozwiązania dotyczą różnych aspektów problemu niezawodności.
Monitorowanie staje się szczególnie ważne podczas odbudowy, ponieważ pozostałe dyski mogą być stale obciążone, gdy poziom nadmiarowości jest obniżony. Nieoczekiwana utrata zasilania w tym okresie wiąże się z dodatkowym ryzykiem, dlatego ochrona UPS podczas operacji na pamięci masowej ma niezależne znaczenie względem monitorowania stanu dysków.
Zalecane stosy narzędzi do monitorowania RAID
Prosty serwer Linux z macierzą RAID
mdadm --monitor
+
smartd
To lekka opcja.
mdadm monitoruje macierz Linux. smartd monitoruje dyski. Żadne z tych narzędzi nie wymaga rozbudowanej platformy internetowej.
Prosty domowy NAS
Natywne monitorowanie NAS
+
Scrutiny
Interfejs NAS obsługuje stan macierzy i odbudowę, a Scrutiny dodaje historię stanu dysków oraz powiadomienia.
Ogólny serwer domowy Linux
Netdata
+
Scrutiny
Netdata zapewnia monitorowanie macierzy i całego serwera. Scrutiny zapewnia bardziej szczegółową historię fizycznych dysków.
Serwer domowy ZFS
ZED
+
Scrutiny
+
Netdata
ZED obsługuje natywne zdarzenia ZFS, Scrutiny śledzi trendy dotyczące dysków, a Netdata zapewnia szerszy pulpit monitorowania systemu.
Zaawansowane laboratorium domowe
smartctl_exporter
Eksportery MD / ZFS
node_exporter
|
Prometheus
|
Grafana
|
Alerty
Jest to odpowiednie rozwiązanie, gdy historia metryk i wiele serwerów są na tyle istotne, że uzasadniają utrzymywanie pełnego stosu obserwowalności.
Serwer ze sprzętową macierzą RAID
StorCLI
|
Netdata / Checkmk
|
Alerty + pulpit nawigacyjny
Narzędzie kontrolera pozostaje źródłem prawdy dla warstwy sprzętowej macierzy RAID, a platforma monitorująca sprawia, że jej stan jest widoczny i pozwala na podjęcie działań.
Ostateczny werdykt
Netdata to najlepsze ogólne narzędzie do monitorowania macierzy RAID dla większości serwerów domowych, ponieważ może obsługiwać różne architektury pamięci masowej, jednocześnie monitorując sam host.
Scrutiny to najlepsze narzędzie uzupełniające, gdy istotna jest historia poszczególnych dysków. Jest szczególnie przydatne do wykrywania powolnych zmian atrybutów SMART, zanim sama macierz przejdzie w stan zdegradowany.
smartmontools nadal stanowi podstawową warstwę monitorowania stanu dysków, a mdadm Monitor wciąż jest jedną z najprostszych odpowiedzi dla programowej macierzy RAID w systemie Linux.
OpenZFS ZED powinien pozostać częścią natywnej dla ZFS strategii monitorowania, zamiast próbować zastępować zdarzenia puli ogólnymi danymi SMART.
Cockpit to najłatwiejsza opcja graficzna dla zwykłego serwera Linux, natomiast Prometheus i Grafana mają więcej sensu, gdy długoterminowe metryki stają się rzeczywistym wymaganiem.
Checkmk i Zabbix zyskują na wartości wraz ze wzrostem liczby monitorowanych systemów, a StorCLI jest niezbędne, gdy logika RAID znajduje się w obsługiwanym sprzętowym kontrolerze LSI/Broadcom.
Najbardziej niezawodna strategia dla serwera domowego jest więc warstwowa:
Stan macierzy
+
Stan dysku
+
Stan odzyskiwania
+
Alerty
+
Historia
Macierz RAID zwykle ulega awarii etapami, dlatego monitoring również powinien być warstwowy.
Najczęściej zadawane pytania
Jakie jest najlepsze narzędzie do monitorowania macierzy RAID na serwerze domowym?
Netdata to jedna z najlepszych ogólnych opcji, ponieważ może monitorować macierz Linux MD RAID, urządzenia SMART, pule ZFS, obsługiwane sprzętowe macierze RAID oraz resztę serwera z jednego interfejsu. Scrutiny jest lepszym narzędziem specjalistycznym, gdy priorytetem jest szczegółowa historia SMART fizycznych dysków.
Czy Scrutiny jest narzędziem do monitorowania macierzy RAID?
Scrutiny monitoruje fizyczne dyski znajdujące się pod macierzą RAID za pomocą danych SMART. Nie zastępuje monitorowania na poziomie macierzy, takiego jak mdadm w przypadku macierzy Linux MD RAID, ZED w przypadku zdarzeń ZFS ani StorCLI w przypadku obsługiwanych sprzętowych kontrolerów RAID.
Czy SMART może wyświetlać PASSED, gdy dysk ulega awarii?
SMART PASSED oznacza, że dysk nie przekroczył ogólnego warunku awarii SMART urządzenia. Poszczególne atrybuty mogą jednak zmieniać się w niepokojący sposób, zanim stan zmieni się na failed. Monitorowanie historyczne jest przydatne, ponieważ uwidacznia te trendy.
Jaki jest najlepszy sposób monitorowania macierzy mdadm RAID?
Użyj trybu monitorowania mdadm do obsługi zdarzeń macierzy i połącz go z smartmontools lub Scrutiny do monitorowania stanu fizycznych dysków. Netdata może zapewnić dodatkową graficzną warstwę monitorowania macierzy MD RAID i serwera.
Jaki jest najlepszy sposób monitorowania puli ZFS?
Użyj natywnych narzędzi ZFS, takich jak ZED i zpool, do monitorowania zdarzeń i stanu puli. Dodaj smartmontools lub Scrutiny do monitorowania stanu pojedynczych dysków oraz Netdata, Prometheus lub Grafanę, gdy potrzebna jest wizualizacja danych historycznych.
Czy monitorowanie RAID wykrywa awarię dysku twardego przed jej wystąpieniem?
Samo monitorowanie macierzy może nie wystarczyć. Narzędzia oparte na SMART mogą ujawnić zmiany atrybutów stanu dysku, zanim macierz utraci członka, choć żaden system monitorowania nie jest w stanie niezawodnie przewidzieć każdej awarii dysku.
Czy używać Netdata czy Scrutiny?
Użyj Netdata, jeśli chcesz mieć jeden pulpit obejmujący cały serwer, w tym RAID, pamięć masową, CPU, RAM, sieć i usługi. Użyj Scrutiny, jeśli priorytetem są szczegółowe trendy SMART i historia stanu dysków. Uruchomienie obu narzędzi może być przydatne, ponieważ obejmują różne warstwy.
Czy do monitorowania RAID potrzebuję Grafany?
Nie. Grafana jest przydatna do długoterminowych metryk, niestandardowych pulpitów, monitorowania wielu systemów i korelowania danych. Prosty domowy NAS można często odpowiednio monitorować za pomocą wbudowanych alertów oraz smartmontools, Scrutiny lub Netdata.
Jakie alerty powinien wysyłać serwer RAID?
Co najmniej skonfiguruj alerty dotyczące macierzy w stanie obniżonej sprawności lub offline, brakujących członków, nieudanych odbudów, błędów stanu SMART, istotnych zmian atrybutów SMART, wysokiej temperatury dysków, błędów ZFS oraz usterek sprzętowego kontrolera RAID lub pamięci podręcznej, jeśli ma to zastosowanie.
Czy scrub macierzy RAID to to samo co test SMART?
Nie. Test SMART działa na pojedynczym dysku. Scrub lub kontrola spójności weryfikuje dane i nadmiarowość na poziomie systemu pamięci masowej. Odbudowa przywraca nadmiarowość po awarii lub wymianie dysku.
Czy monitorowanie RAID zastępuje kopię zapasową?
Nie. Monitorowanie pomaga szybko wykrywać awarie, a RAID może utrzymać dostępność po niektórych awariach dysków. Żadne z nich nie przywraca usuniętych, zaszyfrowanych, uszkodzonych ani wcześniej zmienionych plików. Nadal potrzebna jest osobna kopia zapasowa.
Czy należy monitorować dyski SSD i NVMe w macierzy RAID?
Tak. Dyski SSD i NVMe udostępniają informacje o stanie, takie jak krytyczne ostrzeżenia, temperatura, błędy nośnika oraz wytrzymałość lub zużycie. Dokładne atrybuty różnią się od danych SMART dysków HDD, dlatego narzędzie monitorujące musi obsługiwać odpowiedni typ urządzenia.
Porównania produktów
Więcej do przeczytania

Czy Home Assistant może zastąpić openHAB do sterowania wszystkimi urządzeniami w domu?
Home Assistant może zastąpić openHAB dopiero wtedy, gdy każde kluczowe urządzenie i każda automatyzacja przejdą równoległy test migracji i wycofania zmian.

Mini-PC vs serwer jednopłytkowy vs NAS do Home Assistanta
Wybierz SBC do małego, energooszczędnego urządzenia, mini-PC zapewniający elastyczny zapas mocy albo NAS tylko wtedy, gdy operacje na współdzielonym hoście są już dojrzałe.

Jak wybrać między dedykowanym serwerem Home Assistant a współdzielonym hostem aplikacji
Wybierz hosting dedykowany, aby uprościć izolację awarii; wybierz hosting współdzielony, gdy izolacja, okna konserwacyjne i odzyskiwanie danych są sprawdzone.

