W systemach Linux monitorowanie przestrzeni dyskowej wygląda nieco inaczej niż w środowisku Windows. Wynika to przede wszystkim z architektury systemu plików, która opiera się na wielu punktach montowania (mount points). Każdy z nich może znajdować się na osobnej partycji, wolumenie LVM lub nawet zdalnym zasobie.
To powoduje, że administratorzy muszą monitorować nie jeden „dysk C”, ale często kilkanaście różnych filesystemów o różnym znaczeniu dla działania systemu.
Uwaga: poniższy materiał jest fragmentem powstającej książki o monitoringu infrastruktury IT i Zabbixie. Jeżeli chcesz otrzymać powiadomienie, gdy książka zostanie wydana, możesz zapisać się tutaj:
https://asdevops.pl/ksiazka
Bezpłatne szkolenie: Zbuduj 5 agentów AI w n8n!
Weź udział w intensywnym, praktycznym szkoleniu i naucz się tworzyć automatyzacje oraz agentów AI komunikujących się przez komunikator. W programie m.in.: RAG Chatbot, Voice Agent, Wirtualna Rada Nadzorcza, Asystentka głosowa i Claude Code Admin.
Zapisy do 23 kwietnia, 23:59
Fragment książki – rozdział 9.2.5
9.2.5 Zajętość Filesystemów
Monitorowanie wykorzystania przestrzeni dyskowej w systemach Linux jest bardziej złożone niż w środowisku Windows. Wynika to z faktu, że w Linuxie system plików jest zorganizowany w postaci wielu punktów montowania (mount points), które mogą znajdować się na osobnych partycjach lub wolumenach.
Typowy serwer Linux może posiadać wiele filesystemów, np.:
/
/home
/opt
/opt/dms/HOSTNAME/data
/opt/oracle/HOSTNAME/oracledb
/opt/oracleDBserver/oracledb
/tmp
/usr
/var
Każdy z nich może mieć inną wielkość oraz inne znaczenie dla działania systemu lub aplikacji. Z tego powodu nie zawsze konieczne jest monitorowanie wszystkich wolumenów w identyczny sposób.
W podstawowym szablonie monitoringu ogranicza się liczbę monitorowanych filesystemów do tych najważniejszych i najczęściej spotykanych, takich jak:
/
/home
/opt
/tmp
/usr
/var
Jeżeli na serwerze występują dodatkowe wolumeny (np. dedykowane dla baz danych lub aplikacji), dla takich lokalizacji dodawane są dodatkowe elementy monitorujące (itemy). W sytuacji gdy dany filesystem nie istnieje na monitorowanym serwerze, odpowiednie elementy są wyłączane, aby nie generować niepotrzebnych zapytań do agenta oraz nie zwiększać obciążenia bazy danych Zabbixa.
W praktyce konfiguracja ta jest często automatyzowana przy użyciu mechanizmu Low Level Discovery (LLD), który pozwala automatycznie wykrywać punkty montowania i tworzyć dla nich odpowiednie elementy monitorujące.
Elementy monitorujące przestrzeń dyskową
W Zabbixie do monitorowania filesystemów wykorzystuje się klucz:
vfs.fs.size
Pozwala on pobierać różne informacje dotyczące wykorzystania przestrzeni dyskowej. Przykładowe elementy dla partycji głównej wyglądają następująco:
vfs.fs.size[/,free]
vfs.fs.size[/,pfree]
vfs.fs.size[/,pused]
vfs.fs.size[/,total]
vfs.fs.size[/,used]
Analogiczne elementy można zdefiniować dla innych punktów montowania, np.:
vfs.fs.size[/home,free]
vfs.fs.size[/home,pfree]
vfs.fs.size[/home,pused]
vfs.fs.size[/home,total]
vfs.fs.size[/home,used]
lub dla wolumenów aplikacyjnych, np.:
vfs.fs.size[/opt/oracle/HOSTNAME/oracledb,pfree]
vfs.fs.size[/opt/dms/HOSTNAME/data,pfree]
vfs.fs.size[/opt/oracleDBserver/oracledb,pfree]
Warto zauważyć, że nie zawsze konieczne jest zbieranie wszystkich możliwych metryk dla każdego filesystemu. W wielu przypadkach wystarczające jest monitorowanie procentu wolnej przestrzeni, który najczęściej wykorzystywany jest do budowy reguł alarmowych.
Najważniejsze parametry monitorowania
Nie zawsze pod każdy ITEM należy podłączyć czujkę. Możemy to zrobić tylko wtedy, kiedy dany volumen ma duże znaczenie.Ewentualnie, jeżeli ze względu na przeprowadzane co jakiś czas analiz i szacowania wykorzystania wolumenów w przyszłości.
Wykorzystane w składni polecenia tłumaczy poniższa tabela.
| pfree | Procent wolnej przestrzeni dyskowej |
| pused | Procent użytej przestrzeni dyskowej |
| total | Całkowita dostępna przestrzeń partycji |
Tabela 33: Parametry czujek dyskowych. Źródło: opracowanie własne
Na podstawie tych danych można budować reguły alarmowe informujące o zbliżającym się zapełnieniu dysku.
Przykładowe reguły alarmowe
W przedstawionej konfiguracji zastosowano dwustopniowe alarmowanie. Pierwszy próg ostrzega o zbliżającym się braku miejsca, natomiast drugi sygnalizuje stan krytyczny.
Przykładowe wyrażenia triggerów:
{HOSTNAME:vfs.fs.size[/,pfree].last()}<10
{HOSTNAME:vfs.fs.size[/,pfree].last()}<5
Podobne reguły można zastosować dla innych filesystemów:
{HOSTNAME:vfs.fs.size[/home,pfree].last()}<10
{HOSTNAME:vfs.fs.size[/home,pfree].last()}<5
{HOSTNAME:vfs.fs.size[/opt,pfree].last()}<10
{HOSTNAME:vfs.fs.size[/opt,pfree].last()}<5
{HOSTNAME:vfs.fs.size[/var,pfree].last()}<10
{HOSTNAME:vfs.fs.size[/var,pfree].last()}<5
Dla wolumenów aplikacyjnych, takich jak przestrzeń baz danych lub systemów DMS, również można zdefiniować osobne progi alarmowe, np.:
{HOSTNAME:vfs.fs.size[/opt/dms/HOSTNAME/data,pfree].last()}<10
{HOSTNAME:vfs.fs.size[/opt/dms/HOSTNAME/data,pfree].last()}<5
Dzięki takiej konfiguracji administrator otrzymuje wczesne ostrzeżenie o rosnącym wykorzystaniu przestrzeni dyskowej i może odpowiednio wcześnie podjąć działania zapobiegawcze, zanim dojdzie do zatrzymania usług lub problemów z działaniem systemu.
Ten artykuł jest fragmentem powstającej książki o monitoringu infrastruktury w Zabbixie.
Jeżeli chcesz otrzymać informację, gdy książka zostanie wydana, możesz zapisać się tutaj:
Na liście powiadomień pojawią się również informacje o nowych rozdziałach, materiałach technicznych oraz dodatkowych przykładach konfiguracji używanych w środowiskach produkcyjnych.
Bezpłatne szkolenie: Zbuduj 5 agentów AI w n8n!
Weź udział w intensywnym, praktycznym szkoleniu i naucz się tworzyć automatyzacje oraz agentów AI komunikujących się przez komunikator. W programie m.in.: RAG Chatbot, Voice Agent, Wirtualna Rada Nadzorcza, Asystentka głosowa i Claude Code Admin.
Zapisy do 23 kwietnia, 23:59