Prezentacja numer siedem z cyklu Administracja Sieci Komputerowych poświęcona jest w całości zdalnemu monitoringowi infrastruktury sieciowej. Współczesne sieci komputerowe składają się z setek, a często tysięcy urządzeń - przełączników, routerów, zapór sieciowych, serwerów i urządzeń bezprzewodowych. Ręczne sprawdzanie stanu każdego z nich jest niemożliwe w skali produkcyjnej.

Protokół SNMP (Simple Network Management Protocol) stanowi fundament zbierania metryk z urządzeń sieciowych. Od swojej pierwszej wersji z 1988 roku przeszedł długą drogę ewolucji, oferując dziś mechanizmy szyfrowania i uwierzytelniania w wersji trzeciej.

Systemy klasy NMS (Network Management System) takie jak LibreNMS, Observium i Zabbix agregują dane zebrane przez SNMP, prezentują je w postaci wykresów i dashboardów oraz umożliwiają konfigurację alertów. Każde z tych narzędzi ma inne mocne strony i znajduje zastosowanie w różnych scenariuszach wdrożeniowych.

Celem warsztatu jest wykształcenie umiejętności samodzielnej konfiguracji monitoringu, interpretacji zebranych metryk oraz diagnozowania problemów z działaniem SNMP w środowisku produkcyjnym.

Podstawowym celem warsztatu jest zmiana sposobu myślenia o monitoringu - przejście od postawy reaktywnej, w której administrator reaguje na awarie, do postawy proaktywnej, w której awariom zapobiega się poprzez analizę trendów i wczesne ostrzeganie.

Monitoring proaktywny wymaga zrozumienia, jakie metryki są istotne dla różnych typów urządzeń, jak często należy je zbierać oraz jakie progi alarmowe ustawić, aby otrzymywać powiadomienia z odpowiednim wyprzedzeniem.

W ramach warsztatu uczestnicy poznają protokół SNMP od strony praktycznej - od konfiguracji agenta na urządzeniu, przez odpytywanie OID, aż po pełną integrację z systemem NMS. Szczególny nacisk położono na rozwiązywanie problemów, ponieważ w środowisku produkcyjnym to właśnie diagnostyka stanowi największe wyzwanie.

Po ukończeniu warsztatu uczestnik będzie potrafił samodzielnie wdrożyć monitorowanie sieci w małej i średniej organizacji, wykorzystując narzędzia open-source oraz komercyjne.

Prezentacja została podzielona na sześć bloków tematycznych, które prowadzą uczestnika od ogólnych koncepcji monitoringu, przez szczegóły protokołu SNMP, aż po praktyczne laboratorium i rozwiązywanie problemów.

Pierwsza część (slajdy 4-12) wprowadza pojęcie metryk i kategoryzuje je według rodzaju - temperatury, obroty wentylatorów, nasycenie łączy, obciążenie procesora, zużycie pamięci. Omówiony zostanie również proces Capacity Planning oparty na analizie trendów.

Druga część (slajdy 13-20) szczegółowo omawia architekturę SNMP, modele Polling i Trap oraz mechanizmy komunikacji między menedżerem a agentem. Wytłumaczona zostanie rola portów UDP 161 i 162.

Trzecia część (slajdy 21-30) koncentruje się na ewolucji bezpieczeństwa SNMP i strukturze bazy MIB. Omówione zostaną różnice między wersjami protokołu oraz sposoby zabezpieczania dostępu do urządzeń.

Czwarta część (slajdy 31-38) to przegląd systemów NMS z praktycznym porównaniem LibreNMS, Observium i Zabbix. Piąta część (slajdy 39-44) to laboratorium, a szósta (slajdy 45-50) - troubleshooting i ściąga z komendąmi.

Monitorowanie sieci nie jest luksusem, lecz koniecznością w każdej organizacji, w której czas przestoju przekłada się na straty finansowe lub utratę reputacji. W środowiskach produkcyjnych administrator nie ma fizycznego dostępu do każdego urządzenia, a liczba przełączników, routerów i serwerów uniemożliwia ręczną kontrolę.

Statystyki pokazują, że około 70% awarii sieci poprzedzonych jest długotrwałym procesem degradacji parametrów - rosnącym poziomem błędów na interfejsie, wzrostem temperatury w szafie, czy zwiększającym się opóźnieniem transmisji. Monitoring pozwala wychwycić te sygnały na wczesnym etapie.

Dane historyczne zebrane przez system monitorujący są bezcenne przy planowaniu rozbudowy infrastruktury. Decyzje o zakupie nowych przełączników, zwiększeniu przepustowości łączy czy dodaniu modułów do istniejących urządzeń powinny opierać się na twardych danych, a nie na domysłach.

Weryfikacja umów SLA (Service Level Agreement) z dostawcami usług telekomunikacyjnych wymaga niezależnego systemu pomiarowego, który rejestruje dostępność i parametry łącza przez cały okres obowiązywania umowy. Własny monitoring daje argumenty w negocjacjach z dostawcą.

Metryki monitorowane w sieci można podzielić na kilka kategorii, z których każda dostarcza informacji o innym aspekcie działania infrastruktury. Metryki środowiskowe są kluczowe dla zapewnienia ciągłości działania - przegrzewający się przełącznik L3 może ulec uszkodzeniu, co spowoduje rozległą awarię.

Metryki interfejsowe to najczęściej zbierana kategoria danych. obejmują one nie tylko bieżące obciążenie łącza w bitach na sekundę, ale także liczbę błędów CRC, kolizji, porzuconych ramek oraz pauz (flow control). Gwałtowny wzrost błędów CRC wskazuje zwykle na problem z okablowaniem lub uszkodzony transceiver SFP.

Metryki zasobów procesora i pamięci są szczególnie istotne w przypadku urządzeń warstwy rdzenia (Core), które przetwarzają ogromne ilości ruchu. Wzrost obciążenia CPU powyżej 80% przez dłuższy czas może skutkować opóźnieniami w przesyłaniu pakietów, a w skrajnych przypadkach utratą połączeń BGP.

Metryki protokołów routingu, takie jak liczba sąsiadów OSPF czy rozmiar tablicy routingu, pozwalają wykryć niestabilności sieci - na przykład flapping tras OSPF spowodowany niestabilnym łączem.

Temperatura jest jednym z najważniejszych parametrów środowiskowych monitorowanych w urządzeniach sieciowych. Przełączniki warstwy 3 wyposażone są w wiele czujników temperatury rozmieszczonych w kluczowych punktach - przy procesorze, przy układach ASIC odpowiedzialnych za przełączanie ramek, przy zasiłączach oraz przy portach SFP.

Wentylatory w przełącznikach najczęściej pracują w systemie redundantnym N+1 - jeden wentylator więcej niż jest wymagańe do chłodzenia. Obroty wirników mierzone w RPM (obrotach na minutę) są kluczowym wskaźnikiem zdrowia układu chłodzenia. Spadek RPM przy stałej temperaturze może oznaczać zatkany filtr lub zużycie łożyska.

Sezonowe zmiany temperatury w serwerowni mają bezpośredni wpływ na temperaturę wewnętrzna urządzeń. Analiza trendów rocznych pozwala przewidzieć okresy, w których ryzyko przegrzania jest największe i zaplanować odpowiednie działania prewencyjne.

Większość producentów (Cisco, Juniper, HP Aruba) definiuje dwa progi alarmowe: warning (ostrzeżenie) przy temperaturze około 50°C i critical (krytyczny) około 65-70°C. Po przekroczeniu progu krytycznego urządzenie automatycznie wyłącza porty lub cały system, aby zapobiec uszkodzeniu sprzętu.

Pomiar obciążenia łączy opiera się na odczycie liczników bajtów i pakietów na interfejsie, które są przechowywane w urządzeniu i udostępniane przez SNMP. System monitorujący (NMS) w każdym cyklu pollingu odczytuje bieżące wartości liczników, a następnie oblicza różnice między dwiema kolejnymi próbkami, dzieląc przez czas między pomiarami.

Standardem w branży jest interwał pomiarowy wynoszący 5 minut dla typowych metryk interfejsowych. Krótsze interwały (1 minutę) są stosowane dla krytycznych łączy, ale zwiększają obciążenie zarówno urządzenia (respondenta), jak i sieci oraz samego systemu NMS.

Kluczowe liczniki SNMP na interfejsie to ifInOctets (bajty odebrane), ifOutOctets (bajty wysłane), ifInErrors (błędy CRC/alignment), ifOutErrors (błędy nadawania) oraz ifInDiscards (ramki porzucone w kolejce). Gwałtowny wzrost błędów CRC wskazuje na problem fizyczny - uszkodzony kabel, niekompatybilny SFP lub zanieczyszczone złącze światłowodowe.

Nasycenie łącza wyrażane jest procentowo jako stosunek bieżącego obciążenia do przepustowości interfejsu (ifSpeed). łącza wykorzystane w ponad 80% przez większość dnia kwalifikują się do rozbudowy w ramach capacity planning.

Monitorowanie obciążenia procesora w urządzeniach sieciowych jest kluczowe, ponieważ przeciążony CPU może opóźniać przetwarzanie pakietów kontrolnych (OSPF Hello, BGP Keepalive), co prowadzi do utraty sąsiedztwa i destabilizacji całej sieci.

W przeciwieństwie do serwerów, gdzie CPU jest ładowany przez procesy użytkownika, w przełącznikach i routerach obciążenie CPU pochodzi głównie od procesów systemowych - obsługi SNMP, protokołów routingu, STP, zarządzania tablicą MAC oraz obsługi interfejsów zarządzania (SSH/HTTP).

Wykorzystanie pamięci DRAM jest równie ważne - urządzenie, któremu kończy się pamięć, może zacząć porzucać pakiety, tracić wpisy w tablicy routingu lub nie być w stanie utrzymać wszystkich sesji BGP. Trend wzrostu zużycia pamięci sugeruje potrzebę restartu urządzenia (leak memory) lub rozbudowy.

Różni producenci używają różnych OID do udostępniania statystyk CPU. Dla urządzeń Cisco najczęściej stosuje się OID z gałęzi CISCO-PROCESS-MIB (1.3.6.1.4.1.9.9.109), ale dla urządzeń innych producentów należy odczytać odpowiednią gałąź z HOST-RESOURCES-MIB (1.3.6.1.2.1.25) lub dedykowanych MIB producenta.

Przejście z modelu reaktywnego na proaktywny to fundamentalna zmiana w podejściu do zarządzania infrastrukturą IT. W modelu reaktywnym administrator dowiaduje się o problemie od użytkowników - zazwyczaj w momencie, gdy awaria już wystąpiła i wpływa na działalność biznesowa. To model kosztowny, stresujący i nieefektywny.

Model proaktywny opiera się na ciągłym zbieraniu metryk i analizie trendów. System monitorujący nie czeka na awarie, ale samodzielnie wykrywa niepokojące symptomy - rosnącą temperaturę, zwiększająca się liczbę błędów CRC, czy wydłużający się czas odpowiedzi ICMP.

Klasyczny Przykład: temperatura w przełączniku rośnie średnio o 2°C miesięcznie od początku lata. Przy progu krytycznym 65°C i bieżącej temperaturze 55°C administrator ma około 5 miesięcy na podjęcie działań - naprawę klimatyzacji, czyszczenie filtrów lub wymianę wentylatorów. Bez monitorowania trendu awaria nastąpiłaby nagle i zaskoczyła zespół.

Capacity planning to proces planowania zasobów na podstawie historycznych danych o obciążeniu. jeśli łącze wzrasta o 10% miesięcznie, administrator może przewidzieć, za ile miesięcy osiągnie 100% nasycenia i zamówić u dostawcy przepustowość z wyprzedzeniem.

Analiza trendów obciążenia to proces systematycznego badania historycznych danych pomiarowych w celu wykrycia wzorców i przewidywania przyszłych potrzeb. W praktyce inżynierskiej wykorzystuje się do tego dane z ostatnich 12-24 miesięcy, które pozwalają wyodrębnić trendy sezonowe oraz wzrostowe.

Dla każdego monitorowanego parametru (obciążenie łącza, temperatura, CPU) można wyznaczyć linie trendu za pomocą regresji liniowej. W LibreNMS i Zabbix funkcje prognozowania są wbudowane i automatycznie wyświetlają przewidywany moment osiągniecia progu krytycznego.

Analiza dobowa i tygodniowa jest równie ważna jak długoterminowa. Przykładowo łącze może być wykorzystane w 90% w godzinach pracy biura, ale tylko w 20% w nocy. Wymiarowanie powinno opierać się na percentylu 95 (95th percentile) - czyli wartości, która nie jest przekraczana przez 95% czasu pomiaru.

Capacity planning ma bezpośrednie przełożenie na finanse organizacji. Dział IT może przedstawić zarządowi prognozę: "przy obecnym tempie wzrostu za 9 miesięcy zabraknie przepustowości łącza internetowego". To pozwala zaplanować budżet i uniknac awaryjnych, drozszych zakupów w ostatniej chwili.

Umowy SLA (Service Level Agreement) z dostawcami usług telekomunikacyjnych są standardem w branży. Zazwyczaj gwarantują one dostępność łącza na poziomie 99.5%, 99.9% lub 99.99% w skali miesiąca. Aby zweryfikować, czy dostawcą wywiązuje się z umowy, potrzebny jest niezależny system pomiarowy.

System NMS monitoruje łącze z własnej perspektywy, wysyłając zapytania ICMP Echo (ping) lub SNMP do routera granicznego. Rejestruje on każda chwilę, w której łącze było niedostępne - czy to z powodu awarii dostawcy, czy konserwacji technicznej.

Opóźnienie (latency) mierzone jako RTT (Round Trip Time) oraz zmienność opóźnienia (jitter) są kluczowe dla aplikacji czasu rzeczywistego - VoIP, wideokonferencji i transmisji strumieniowej. Przekroczenie progów (np. latency > 50 ms, jitter > 10 ms) jest podstawą do reklamacji.

Automatyczne raporty miesięczne generowane przez system monitorujący stanowią twardy dowód w przypadku sporu z dostawcą. W środowisku produkcyjnym zaleca się przechowywanie danych pomiarowych przez cały okres obowiązywania umowy SLA, czyli zazwyczaj 12-24 miesiące.

Zbieranie metryk bez ich analizy to tylko magazynowanie danych. Prawdziwa wartość monitoringu ujawnia się dopiero wtedy, gdy dane są przetwarzane, wizualizowane i przekładane na konkretne działania - alerty, raporty, decyzję biznesowe. System NMS powinien odpowiadać na pytanie "co się zmieniło od wczoraj?"

Trendy są istotniejsze niż wartości chwilowe. Pojedynczy skok temperatury do 55°C może być anomalią, ale systematyczny wzrost o 1°C tygodniowo to wyraźny sygnał ostrzegawczy. Dlatego systemy monitorujące oferują funkcje progowania bazującego na odchyleniu od wartości średniej (baseline).

Ustalając progi alarmowe, należy zostawić margines bezpieczeństwa między wartością ostrzegawczą a krytyczną. jeśli urządzenie krytycznie reaguje przy 80% CPU, warning powinien być ustawiony przy 60%, a nie 75%. Da to zespółowi czas na reakcję przed eskalacją problemu.

Łączenie danych z monitoringu z historią incydentów (ticketing) pozwala na analizę korelacji - "czy awaria była poprzedzona wzrostem temperatury?" lub "czy restart urządzenia rozwiązał problem z pamięcią?". To wiedza niezbędna do doskonalenia procesów IT.

Simple Network Management Protocol (SNMP) to protokół warstwy aplikacji działający na UDP, zaprojektowany do zarządzania i monitorowania urządzeń sieciowych. Jego pierwsza specyfikacja pojawiła się w 1988 roku (RFC 1067) i od tego czasu stał się standardem de facto w monitorowaniu infrastruktury IT.

Architektura SNMP opiera się na dwóch głównych komponentach: menedżerze SNMP (Network Management Station - NMS) oraz agencie SNMP. Menedżer to system centralny (np. LibreNMS, Zabbix), który zbiera i agreguje dane. Agent to oprogramowanie działające na monitorowanym urządzeniu (przełączniku, routerze, serwerze), które udostępnia dane o jego stanie.

menedżer komunikuje się z agentem, wysyłając zapytania na port UDP 161. Agent odpowiada, zwracając zadane wartości. W przypadku asynchronicznych powiadomień (Trap) agent wysyła dane na port UDP 162 menedżera bez uprzedniego zapytania.

Wybór UDP jako protokołu transportowego nie jest przypadkowy - SNMP został zaprojektowany do pracy w sieciach, gdzie niezawodność połączenia nie jest gwarantowana. UDP jest lżejszy niż TCP, nie wymaga nawiązywania sesji i lepiej radzi sobie w warunkach przeciążenia sieci. W razie utraty pakietu menedżer po prostu ponawia zapytanie w następnym cyklu pollingu.

Model Polling to podstawowy mechanizm zbierania danych w SNMP. menedżer (NMS) wysyła zapytanie do agenta na UDP 161, a agent odpowiada danymi. menedżer decyduje, kiedy i jakie dane chce zebrać - to on kontroluje proces komunikacji. W praktyce co 5 minut NMS odpytuje każde urządzenie o zestaw zdefiniowanych OID.

SNMP definiuje trzy operacje odczytu: Get (pobranie pojedynczej wartości OID), GetNext (pobranie kolejnego OID w drzewie - iteracja) oraz GetBulk (pobranie wielu kolejnych OID w jednym zapytaniu - zoptymalizowane dla dużych tabel).

Główną Zaletą modelu Polling jest pełna kontrola nad tym, co, kiedy i jak często jest zbierane. menedżer może dynamicznie zmieniać interwał dla różnych urządzeń - na przykład krytyczne routery rdzeniowe odpytuje co minutę, a przełączniki dostępowe co 10 minut.

Wadą modelu jest generowanie ruchu sieciowego nawet wtedy, gdy nic się nie dzieje. W przypadku monitorowania tysięcy urządzeń ruch związany z pollingiem może być znaczący. Ponadto każde zapytanie wymaga przetworzenia przez agenta, co obciąża CPU monitorowanego urządzenia - szczególnie odczuwalne na starszych przełącznikach.

Model Trap odwraca kierunek komunikacji - to agent inicjuje wysyłanie danych do menedżera, gdy wystąpi określone zdarzenie. Agent wysyła komunikat na port UDP 162 menedżera, bez oczekiwania na wcześniejsze zapytanie. Dzięki temu menedżer dowiaduje się o zdarzeniu niemal natychmiast po jego wystąpieniu.

Standard SNMPv1 definiuje sześć generycznych trapów: coldStart (urządzenie uruchomione po pełnym resecie), warmStart (restart bez utraty konfiguracji), linkDown (port przeszedł w stan down), linkUp (port wrócił do stanu up), authenticationFailure (nieudane uwierzytelnienie SNMP) oraz egpNeighborLoss (utrata sąsiada EGP). Producenci mogą definiować własne trapy specyficzne (enterprise-specific traps).

Zaletą modelu Trap jest szybkość reakcji - menedżer wie o zdarzeniu w ciągu milisekund od jego wystąpienia. Nie musi czekać na następny cykl pollingu, który może nastąpić dopiero za kilka minut. To kluczowe dla zdarzeń krytycznych, takich jak utrata łącza rdzeniowego.

Główną wada jest zawodność - ponieważ SNMP używa UDP, trap może zostać utracony bez żadnej informacji o tym dla nadawcy (fire-and-forget). Rozwiązaniem jest mechanizm Inform (SNMPv2c/v3), który wymaga potwierdzenia odbioru, ale generuje dodatkowy ruch. W praktyce stosuje się kombinacje trapów (do szybkiego wykrywania) i pollingu (do weryfikacji i uzupełnienia danych).

Wybór między modelem Pull (Polling) a Push (Trap) ma istotne konsekwencje dla architektury monitoringu. W praktyce produkcyjnej stosuje się oba modele jednocześnie, ponieważ uzupełniają się wzajemnie - polling zapewnia pełne dane historyczne, trapy zapewniają szybka reakcję na zdarzenia.

Model Pull daje menedżerowi pełną kontrolę nad procesem zbierania danych. może on dynamicznie dostosowywać interwał pollingu w zależności od pory dnia, obciążenia sieci lub priorytetu urządzenia. ponieważ menedżer zawsze może ponowić zapytanie, utrata pojedynczego pakietu nie powoduje utraty danych - zostaną one odebrane w następnym cyklu.

Model Push jest niezastąpiony w przypadkach, gdy czas reakcji ma krytyczne znaczenie. jeśli interfejs rdzeniowy przejdzie w stan down, administrator powinien dowiedzieć się o tym w ciągu sekund, a nie minut. Jednak ponieważ trapy są wysyłane bez potwierdzenia, system NMS powinien okresowo weryfikować stan urządzenia przez polling, aby wychwycić ewentualne utracone powiadomienia.

W nowoczesnych systemach monitorujących (Zabbix, LibreNMS) domyślna strategia jest polling dla ciaglego zbierania metryk, uzupełniony o odbiór trapów dla zdarzeń krytycznych. System koreluje dane z obu źródeł, tworząc spójny obraz stanu infrastruktury.

Management Information Base (MIB) to formalny opis wszystkich parametrów urządzenia, które są dostępne przez SNMP. MIB definiuje nie tylko nazwy i identyfikatory zmiennych, ale także ich typy (integer, string, counter, gauge), zakresy wartości, uprawnienia dostępu (read-only, read-write) oraz relacje między zmiennymi.

MIB jest napisany w języku ASN.1 (Abstract Syntax Notation One) - standardzie opisu danych używanym w telekomunikacji. Pliki MIB mają rozszerzenie .mib i są dostarczane przez producentów urządzeń wraz z dokumentacją techniczną. Bez odpowiedniego pliku MIB system NMS widzi tylko numery OID, a nie ich czytelne nazwy.

Istnieją standardowe MIB zdefiniowane w RFC, które są wspólne dla wszystkich urządzeń SNMP. Najważniejsze to: RFC 1213 (MIB-II) - podstawowe parametry interfejsów, systemu i protokołów IP; RFC 2863 (IF-MIB) - szczegółowe statystyki interfejsów; RFC 2819 (RMON-MIB) - zdalne monitorowanie; RFC 2790 (HOST-RESOURCES-MIB) - zasoby systemowe.

Producenci urządzeń definiują własne, rozszerzone MIB w gałęzi private.enterprises (1.3.6.1.4.1). Na przykład Cisco ma przypisany numer 9, co daje gałąź 1.3.6.1.4.1.9. Pod tą gałęzią znajdują się tysiące OID specyficznych dla urządzeń Cisco - parametry CPU, pamięci, temperatury, protokołów proprietary itp.

Object Identifier (OID) to unikalny numeryczny identyfikator każdej zmiennej w bazie MIB. OID tworzą hierarchiczna strukturę drzewiasta, gdzie każdy kolejny numer w ciągu oznacza zagłębienie się w kolejny poziom drzewa. Na przykład OID 1.3.6.1.2.1.1.3.0 odczytujemy: 1 (iso) → 3 (identified-organization) → 6 (DoD - Department of Defense) → 1 (internet) → 2 (mgmt) → 1 (mib-2) → 1 (system) → 3 (sysUpTime) → 0 (instancja skalarna).

Najważniejsze gałęzie drzewa OID to: 1.3.6.1.2.1 (mgmt/mib-2) - standardowe zmienne zdefiniowane w RFC; 1.3.6.1.4.1 (private.enterprises) - przestrzeń dla producentów; 1.3.6.1.6.1 (SNMPv2) - rozszerzenia SNMPv2; 1.3.6.1.3 (experimental) - zmienne eksperymentalne.

W gałęzi private.enterprises każdy producent ma przypisany unikalny numer. Cisco = 9, Juniper = 2636, Hewlett-Packard = 11, Microsoft = 311, Linux Foundation = 54321. Dzięki temu OID producentów nigdy się nie kolidują. Pod swoją gałęzią producent może zdefiniować dowolna strukturę MIB specyficzna dla swoich urządzeń.

Końcówka .0 w OID oznacza instancję skalarną - pojedynczą wartość, a nie wpis w tabeli. Na przykład sysUpTime.0 (1.3.6.1.2.1.1.3.0) zwraca pojedyncza liczbę - czas pracy systemu. Bez .0 odwołujemy się do definicji obiektu, a nie do konkretnej wartości.

Protokół SNMP definiuje zestaw operacji, które menedżer może wykonać na agencie. Najczęściej używana jest operacja Get, która pobiera wartość pojedynczego OID. Menedżer wysyła żądanie Get zawierające listę OID, a agent odpowiada komunikatem Response z wartościami lub błędem.

Operacja GetNext służy do iteracji po drzewie OID. Menedżer wysyła żądanie GetNext dla danego OID, a agent odpowiada wartością następnego OID w porządku leksykograficznym. Jest to szczególnie przydatne do odczytu tabel - menedżer iteruje, aż otrzyma OID spoza interesującego go zakresu.

GetBulk to optymalizacja wprowadzona w SNMPv2c, która pozwala pobrać wiele kolejnych OID w jednym zapytaniu. menedżer określa, ile wierszy tabeli chce pobrać (max-repetitions), a agent zwraca je w jednej odpowiedzi. GetBulk znacząco redukuje liczbę zapytań potrzebnych do odczytania całej tabeli interfejsów (IF-MIB).

Operacja Set umożliwia modyfikację parametrów urządzenia przez SNMP - na przykład wyŁączenie portu (ifAdminStatus), restart urządzenia lub zmianę konfiguracji. Ze względów bezpieczeństwa operacja Set jest rzadko używana w monitoringu i często blokowana przez firewall lub konfigurację ACL na urządzeniu.

SNMP pozostaje najszerzej wspieranym protokołem monitorującym w urządzeniach sieciowych. Praktycznie każdy przełącznik, router, zapora sieciowa i punkt dostępowy Wi-Fi obsługuje SNMP. To uniwersalny język, którym system monitorujący może rozmawiać z każdym urządzeniem, niezależnie od producenta i modelu.

Alternatywne protokoły monitorujące pełnią inne funkcje. IPMI (Intelligent Platform Management Interface) służy do monitorowania sprzętu serwerów - temperatury, napięcia, stanu wentylatorów - ale nie jest wspierany przez urządzenia sieciowe. Syslog zbiera logi zdarzeń, ale nie nadaje się do ciaglego zbierania metryk liczbowych.

NetFlow i sFlow dostarczają informacji o przepływach - kto, z kim, ile danych przesłał - ale nie zastępują SNMP w monitorowaniu stanu interfejsów i zasobów systemowych. W nowoczesnych środowiskach systemy NMS łącza dane z wielu źródeł: SNMP dla metryk urządzeń, API REST dla usług chmurowych, gRPC dla telemetrii strumieniowej.

Mimo pojawienia się nowszych technologii, SNMP nie traci na znaczeniu. Powodem jest powszechność wsparcia - producenci nadal dostarczają MIB i implementuja SNMP nawet w najprostszych urządzeniach. Dla inżyniera sieciowego znajomość SNMP to podstawowa umiejętność, która pozostanie przydatna przez wiele lat.

SNMP w wersji 1, opublikowany w 1990 roku jako RFC 1157, był pierwszą standardową implementacją protokołu do zarządzania sieciami. Jego twórcy kładli nacisk na prostotę i niskie zużycie zasobów, co z perspektywy czasu okazało się poważnym błędem z punktu widzenia bezpieczeństwa.

Mechanizm uwierzytelniania w SNMPv1 opiera się na Community String - jawnym hasle przesyłanym w każdym pakiecie SNMP. Istnieją dwa domyślne poziomy community: "public" (dostęp tylko do odczytu) i "private" (dostęp do odczytu i zapisu). W praktyce wielu administratorów nigdy nie zmienia tych domyślnych wartości.

Community String jest przesyłany w czystym tekscie w nagłówku pakietu SNMP, co oznacza, że każdy, kto ma dostęp do sieci (np. przez Wireshark), może go przechwycić i odczytać. Ponadto brak mechanizmu szyfrowania sprawia, że cała komunikacja SNMP jest widoczna dla osób postronnych.

Brak integralnosci danych oznacza, że atakujący typu man-in-the-middle może modyfikowac pakiety SNMP w locie, na przykład podmieniając wartości OID lub odpowiedzi agenta. SNMPv1 nie ma żadnego mechanizmu wykrywania takich modyfikacji. Z tych powodów SNMPv1 jest uznawany za protokół niebezpieczny i powinien być stosowany wyłącznie w sieciach izolowanych.

SNMPv2c, opublikowany w 1996 roku, był próba ulepszenia protokołu bez zmiany modelu bezpieczeństwa. Litera "c" w nazwie oznacza "community-based" - zachowano mechanizm Community String z SNMPv1, ale znacząco rozszerzono funkcjonalność protokołu.

Najważniejszą innowacją SNMPv2c jest wprowadzenie operacji GetBulk, która pozwala pobrać wiele kolejnych OID w jednym żądaniu. W SNMPv1 odczytanie całej tabeli interfejsów wymagało serii osobnych zapytań GetNext. GetBulk redukuje te liczbę do jednego zapytania, co znacząco przyspiesza proces zbierania danych.

Wprowadzono również typ Counter64 dla bardzo dużych liczników (powyżej 32 bitów), które są potrzebne przy monitorowaniu szybkich łączy (10 Gbps i więcej). Counter64 pozwala na przechowywanie wartości do 2^64, co eliminuje problem zawijania się liczników na szybkich interfejsach.

Inform to rozszerzenie mechanizmu Trap - w przypadku Inform agent wysyła powiadomienie i oczekuje na potwierdzenie odbioru (Response). jeśli potwierdzenie nie nadejdzie w określonym czasie, agent ponawia wysyłanie. To rozwiązuje problem utraty trapów, ale generuje dodatkowy ruch sieciowy i obciążenie agenta.

SNMPv3, zdefiniowany w RFC 3410-3418 z 2002 roku, stanowi kompleksowe rozwiązanie problemów bezpieczeństwa wcześniejszych wersji protokołu. Wprowadzą mechanizmy uwierzytelniania, szyfrowania i kontroli dostępu, które czynia go odpowiednim do stosowania w sieciach produkcyjnych.

USM (User-based Security Model) zastepuje Community String modelami użytkowników z hasłami. każdy użytkownik SNMPv3 ma nazwę (securityName), hasło uwierzytelniające (authPassphrase) i opcjonalnie hasło szyfrujące (privPassphrase). Hasła nie są przesyłane przez siec - używane są lokalnie do generowania kluczy.

VACM (View-based Access Control Model) umożliwia precyzyjne określenie, które OID może odczytywac dany użytkownik. można na przykład utworzyc widok "interfejsy" obejmujący gałąź IF-MIB (1.3.6.1.2.1.2) i przypisac go użytkownikowi "monitor", a widok "konfiguracja" dla użytkownika "admin".

SNMPv3 definiuje trzy poziomy bezpieczeństwa (security levels): noAuthNoPriv (brak uwierzytelniania i szyfrowania - odpowiednik v2c), authNoPriv (uwierzytelnianie hasłem SHA/MD5, ale dane przesyłane jawnie) oraz authPriv (uwierzytelnianie i szyfrowanie AES/DES - najwyższy poziom). Dla środowisk produkcyjnych zaleca się poziom authPriv.

User-based Security Model (USM) to fundament bezpieczeństwa w SNMPv3. USM definiuje, w jaki sposób agenci i menedżerowie uwierzytelniaja się wzajemnie oraz jak chroniona jest poufnosc i integralnosc przesyłanych danych. W odróżnieniu od zwyklych haseł przesyłanych w czystym tekscie, USM używa kluczy kryptograficznych.

Proces uwierzytelniania w USM opiera się na wspólnie dzielonym hasle (authPassphrase), z którego lokalnie generowany jest klucz uwierzytelniający. Klucz ten jest używany do obliczenia HMAC (Hash-based Message Authentication Code) doczanego do każdego pakietu SNMP. Odbiorca weryfikuje HMAC, aby potwierdzic autentycznosc nadawcy i integralnosc danych.

Szyfrowanie w USM chroni zawartosc pakietów SNMP przed odczytaniem przez niepowolane osoby. dostępne algorytmy to DES (56-bitowy, uwazany za slaby) oraz AES w wariantach 128, 192 i 256 bitów. W środowiskach produkcyjnych zaleca się stosowanie AES-128 jako minimum, a najlepiej AES-256.

Engine ID to unikalny identyfikator silnika SNMP na każdym urządzeniu. Jest on używany do generowania kluczy specyficznych dla danego urządzenia - to samo hasło authPassphrase daje różne klucze na różnych urządzeniach. Engine ID zapobiega atakom typu replay, ponieważ każdy pakiet jest związany z konkretnym urządzeniem i ramka czasowa.

View-based Access Control Model (VACM) to mechanizm kontroli dostępu w SNMPv3, który umożliwia precyzyjne zarządzanie tym, które OID może odczytywac lub modyfikowac dany użytkownik. VACM jest odpowiednikiem list kontroli dostępu (ACL) w systemach plików, ale dla drzewa OID.

W VACM definiuje się grupy użytkowników (security groups), a każdej grupie przypisuje się jeden lub więcej widoków (MIB views). Widok to poddrzewo OID zdefiniowane przez rodzine OID i maske bitowa. Na przykład widok "system" obejmuje OID 1.3.6.1.2.1.1.*, a widok "interfejsy" - 1.3.6.1.2.1.2.*.

Dla każdej grupy określa się trzy typy widoków: readView (OID dostępne do odczytu), writeView (OID dostępne do modyfikacji przez Set) oraz notifyView (OID, których zmiana generuje Trap). Typowym podejściem jest utworzenie grupy "monitoring" z readView obejmującym standardowe MIB i wybrane gałęzie producenta.

VACM działa na przeciwciu trzech wymiarów: grupy (kim jest użytkownik), poziomu bezpieczeństwa (noAuthNoPriv/authNoPriv/authPriv) oraz widoku (do jakich OID ma dostęp). Dzięki temu można na przykład zezwolic użytkownikowi "monitor" na odczyt przez authPriv, ale zablokowac dostęp przy noAuthNoPriv.

Konfiguracja SNMPv3 na urządzeniach Cisco IOS wymaga kilku kroków: utworzenia użytkownika, grupy, widoku oraz opcjonalnie listy ACL ograniczającej dostęp. W przykładzie tworzymy użytkownika "MONITOR" z hasłem uwierzytelniającym SHA "hasło123" i kluczem szyfrującym AES-128 "hasło456".

Grupa "GRP-MONITOR" jest skonfigurowana z poziomem bezpieczeństwa "priv" (authPriv), co oznacza, że użytkownicy tej grupy muszą przejść uwierzytelnianie SHA i komunikacja musi być szyfrowana AES. Bez spełnienia obu warunków dostęp do OID jest blokowany.

Widok "V-MONITOR" definiuje, które gałęzie drzewa OID są dostępne. W przykładzie uwzględniliśmy gałęzie standardowe system (1.3.6.1.2.1.1) i interfejsy (1.3.6.1.2.1.2) oraz gałąź Cisco private (1.3.6.1.4.1.9.9) zawierająca parametry CPU, temperatury i pamięci.

Lista ACL 10 ogranicza dostęp SNMP tylko do adresu IP serwera NMS (192.168.1.100). To dodatkowa warstwa bezpieczeństwa - nawet jeśli ktoś przechwyci hasła, nie będzie mógł odpytywać urządzenia spoza dozwolonego adresu źródłowego. W środowisku produkcyjnym zaleca się łączenie SNMPv3 z ACL na poziomie interfejsu i firewalla.

Konfiguracja agenta SNMP (snmpd) na systemie Linux wymaga edycji pliku /etc/snmp/snmpd.conf. Dla SNMPv3 kluczowym narzędziem jest net-snmp-create-v3-user, które generuje wpis createUser z odpowiednimi kluczami pochodnymi od haseł. Hasła są przechowywane lokalnie w formie zahaszowanej.

Dyrektywa createUser przyjmuje nazwę użytkownika, typ uwierzytelniania (SHA/MD5), hasło uwierzytelniające, typ szyfrowania (AES/DES) i hasło szyfrujące. Po utworzeniu użytkownika, snmpd automatycznie generuje klucze i zapisuje je w pliku /var/lib/snmp/snmpd.conf (lokalizacja zależna od dystrybucji).

Dyrektywa rouser (read-only user) definiuje użytkownika z dostępem tylko do odczytu, a rwuser (read-write user) z dostępem do odczytu i zapisu. Parametr authpriv oznacza, że użytkownik musi korzystać z poziomu authPriv (uwierzytelnianie + szyfrowanie).

domyślnie snmpd nasłuchuje tylko na interfejsie lokalnym (127.0.0.1). Aby umożliwić zdalne zapytania, należy zmienić dyrektywę agentAddress na udp:161 (wszystkie interfejsy) lub konkretny adres IP, np. agentAddress udp:192.168.1.10:161. Po zmianie konfiguracji należy zrestartować usługę: systemctl restart snmpd.

Konfiguracja SNMPv2c jest znacznie prostsza niż SNMPv3, ale kosztem bezpieczeństwa. W pliku snmpd.conf wystarczy dodać dyrektywę rocommunity z nazwa community string i opcjonalnym ograniczeniem adresów źródłowych. Przykład: rocommunity public 192.168.1.0/24 zezwala na odczyt z sieci 192.168.1.0/24.

Community string "public" jest domyślnym hasłem odczytu w większości urządzeń sieciowych. W środowisku laboratoryjnym to wygodne rozwiązanie, ale w produkcji należy zawsze zmienić community na unikalna, trudna do odgadnięcia wartość i ograniczyć dostęp ACL.

Dyrektywy sysLocation, sysContact i sysName wypełniaja informacje systemowe dostępne przez OID 1.3.6.1.2.1.1.* (system group). Te metadane pomagają zidentyfikować urządzenie w systemie NMS - nazwa, lokalizacja fizyczna i kontakt do administratora.

W SNMPv2c można również zdefiniować community read-write (rwcommunity), które umożliwia modyfikację parametrów urządzenia przez SNMP Set. W środowisku produkcyjnym należy unikac community read-write lub zabezpieczyć je restrykcyjną ACL dopuszczającą tylko adres IP systemu zarządzającego.

Ograniczanie dostępu do SNMP to podstawowa zasada bezpieczeństwa, która powinna być stosowana niezależnie od wersji protokołu. Nawet SNMPv3 z authPriv nie chroni przed atakami DoS na agenta, jeśli każdy w sieci może wysyłac zapytania. Dlatego niezbędne jest warstwowe zabezpieczeńie dostępu.

Listy ACL na urządzeniach sieciowych to pierwsza linia obrony. Na przełączniku Cisco konfigurujemy ACL zezwalającą tylko na adres IP serwera NMS: access-list 10 permit 192.168.200.10, a następnie wiazemy ja z konfiguracja SNMP: snmp-server community public RO 10. Wszystkie zapytania z innych adresów są odrzucane.

Firewall powinien blokowac ruch na portach UDP 161 i 162 z sieci zewnętrznych (Internet). W praktyce oznacza to reguły deny na interfejsach WAN dla ruchu do tych portów. W sieci korporacyjnej ruch SNMP powinien być ograniczony do wydzielonej sieci zarządzania (management VLAN/OOB).

Segmentacja sieci zarządzania (Out-of-Band Management) to najlepsza praktyka - serwery NMS i interfejsy zarządzania urządzeń znajdują się w dedykowanej sieci VLAN, odizolowanej od ruchu użytkowników. W tej sieci SNMP może działać nawet w wersji v2c, ponieważ dostęp do niej jest fizycznie i logicznie ograniczony.

Porównanie wersji SNMP pokazuje dramatyczne różnice w poziomie bezpieczeństwa między wersjami. SNMPv1 i v2c nie oferują żadnej ochrony kryptograficznej - Community String jest przesyłany jawnie, dane nie są szyfrowane, a integralnosc nie jest weryfikowana. Oznacza to, że każdy, kto ma dostęp do sieci, może przechwycić hasła i odczytać dane monitorowane.

SNMPv3 całkowicie zmienia ten obraz. Uwierzytelnianie SHA-1 lub MD5 zapobiega podszywaniu się pod menedżera lub agenta. Szyfrowanie AES chroni poufnosc przesyłanych danych - nawet jeśli pakiet zostanie przechwycony, jego zawartosc pozostaje tajna. Integralnosc HMAC gwarantuje, że dane nie zostały zmodyfikowane w tranzycie.

VACM w SNMPv3 umożliwia precyzyjna kontrolę dostępu do drzewa OID. Administrator może zdefiniować, które grupy OID może odczytywac każdy użytkownik, co jest szczególnie przydatne w środowiskach wielodostępnych, gdzie różne zespóły monitoruja różne aspekty infrastruktury.

Rekomendącja dla środowisk produkcyjnych jest jednoznaczna: stosuj SNMPv3 z poziomem authPriv, algorytmem SHA dla uwierzytelniania i AES-128 (lub wyższym) dla szyfrowania. SNMPv2c dopuszczalny jest wyłącznie w izolowanych sieciach zarządzania (OOB), do których dostęp jest fizycznie i logicznie ograniczony.

Ekosystem systemów NMS (Network Management Systems) jest bogaty i zróżnicowany. Wybór odpowiedniego narzędzia zależy od wielu czynników: wielkości infrastruktury, budżetu, wymagańych funkcji, preferowanego modelu licencjonowania oraz kompetencji zespołu administracyjnego.

LibreNMS to rozwidlenie (fork) projektu Observium, który stał się komercyjny. LibreNMS jest w pelni open-source i rozwijany przez społeczność. Jego największa Zaletą jest zaawansowane auto-discovery - po dodaniu sieci IP system sam wykrywa urządzenia, określa ich typ i zaczyna zbierać odpowiednie metryki.

Observium oferuje podobne funkcje co LibreNMS, ale w wersji płatnej (Professional) daje dostęp do bardziej zaawansowanych funkcji, takich jak alerty czy dostęp API. Wersja Community jest ograniczona i nie otrzymuje aktualizacji. Observium jest szczególnie popularny w środowiskach operatorskich i dużych enterprise.

Zabbix to najbardziej uniwersalne narzędzie z tej grupy. Monitoruje nie tylko urządzenia sieciowe przez SNMP, ale także serwery przez dedykowanego agenta (Zabbix Agent), aplikacje przez HTTP/TCP, a nawet usługi chmurowe przez API. Zabbix jest bardziej złożony w konfiguracji, ale oferuje największe możliwości dostosowania.

LibreNMS to zaawansowany system NMS o otwartym kodzie źródłowym, który wyrósł z projektu Observium. Jego główna cecha wyróżniajaca jest zaawansowane auto-discovery - po dodaniu jednej sieci IP (np. 192.168.1.0/24) LibreNMS skanuje wszystkie adresy i automatycznie wykrywa urządzenia obsługujące SNMP.

Auto-discovery nie ogranicza się do ICMP ping. LibreNMS analizuje odpowiedzi SNMP, odczytuje tablice ARP z już znanych urządzeń, nasłuchuje ramek CDP (Cisco Discovery Protocol) i LLDP (Link Layer Discovery Protocol), a także przegląda tablice routingu OSPF i BGP. Dzięki temu wykrywa nie tylko urządzenia, ale także topologię sieci.

System wspiera tysiące modeli urządzeń Dzięki rozbudowanemu systemowi definicji (OS definition). Dla każdego systemu operacyjnego (Cisco IOS, Juniper JunOS, Linux, MikroTik RouterOS itd.) zdefiniowany jest zestaw OID do zebrania oraz sposób interpretacji danych. Nowe definicje są regularnie dodawane przez społeczność.

Dane w LibreNMS są przechowywane w bazie RRD (Round Robin Database), która przechowuje zagregowane wartości (średnia, minimum, maksimum) dla zadanego interwału. domyślnie dane są zbierane co 5 minut, co pozwala przechowywać ponad 2 lata historii przy rozważnym użyciu miejsca na dysku.

Instalacja LibreNMS na serwerze Linux jest stosunkowo prosta Dzięki oficjalnemu skryptowi instalacyjnemu. Skrypt automatycznie instaluje wszystkie zależności - serwer WWW (Nginx lub Apache), baze danych (MariaDB/MySQL), PHP z wymagańymi rozszerzeniami oraz narzędzia SNMP.

Zalecanym systemem operacyjnym jest Ubuntu 22.04 LTS lub Debian 12, ponieważ dla tych dystrybucji skrypty instalacyjne są najlepiej przetestowane. Minimalne wymagańia sprzetowe to 4 vCPU i 6 GB RAM dla monitorowania do 500 urządzeń, ale dla komfortowej pracy zaleca się 8 GB RAM.

Proces instalacji obejmuje: aktualizacje systemu, instalację zależności (PHP 8.1+, MariaDB 10.5+, Nginx), utworzenie bazy danych dla LibreNMS, sklonowanie repozytorium z GitHub, konfigurację użytkownika systemowego (librenms), ustawienie crontab dla pollerów i daily maintenance.

Po instalacji należy przejść do interfejsu webowego (http://librenms.local/install.php), który przeprowadzi przez konfigurację - podanie danych logowania do bazy, ustawienie czasu strefy, utworzenie konta administratora. następnie system jest gotowy do dodawania urządzeń.

Dodawanie urządzenia do LibreNMS jest proste i można je wykonać zarówno przez interfejs webowy, jak i CLI. W interfejsie webowym wybieramy Devices > Add Device, podajemy adres IP lub nazwę DNS, community string (lub dane SNMPv3) oraz wersje protokołu. LibreNMS automatycznie wykrywa typ urządzenia.

Po dodaniu urządzenia LibreNMS uruchamia proces discovery, który określa system operacyjny urządzenia, wersje IOS, dostępne moduły (SFP, zasilacze, wentylatory) oraz interfejsy. Proces ten może potrwać od kilku sekund do kilku minut, w zależności od złożoności urządzenia.

Następnie poller (uruchamiany przez cron co 5 minut) zaczyna zbierać dane: obciążenie interfejsów, temperaturę, obciążenie CPU, zużycie pamięci, dostępność (ping). Po pierwszym cyklu pollingu dane są dostępne na wykresach w interfejsie webowym.

Interfejs webowy LibreNMS oferuje bogaty zestaw widoków: Dashboard z globalnym podsumowaniem, lista urządzeń z statusem, szczegółowe widok urządzenia z zakładkami (Overview, Graphs, Ports, Sensors, Alerts) oraz zaawansowane wykresy porównawcze. Wykresy można eksportować do PNG i CSV.

Observium to jeden z najstarszych i najbardziej dojrzalych systemów NMS, którego początki sięgaja 2006 roku. Projekt rozwijal się dynamicznie do momentu, gdy twórca (Adam Armstrong) podjął decyzję o komercjalizacji - od wersji 17.x Observium Professional jest płatny, a wersja Community nie otrzymuje już aktualizacji.

Observium wyróżnia się głębokim wsparciem dla urządzeń sieciowych. Podczas gdy uniwersalne systemy jak Zabbix traktuja przełącznik jako "urządzenie z interfejsami", Observium rozumie wewnętrzna architekturę - wie, co to modul SFP, czujnik temperatury, wentylator, zasiłącz redundantny, transceiver.

Wersja Professional oferuje zaawansowane alerty (warunki logiczne, flapping detection, reguły eskalacji), API REST dla integracji z systemami zewnętrznymi, szczegółowe wykresy BGP peering, wsparcie dla IPv6 oraz system plug-in do monitorowania aplikacji.

Observium jest często wybierany przez operatorów telekomunikacyjnych i duze działy IT, które potrzebuja niezawodnego systemu monitorującego zorientowanego na siec. W porównaniu z darmowym LibreNMS, Observium Professional oferuje lepsza dokumentację, wsparcie techniczne i stabilniejsze wydania.

Zabbix to najbardziej uniwersalny system monitorujący spośród omawianych. Jego architektura opiera się na centralnym serwerze Zabbix, który może współpracować z wieloma proxy (dla środowisk rozproszonych geograficznie) oraz agentami instalowanymi na monitorowanych hostach.

W przeciwieństwie do LibreNMS i Observium, które są zorientowane głównie na SNMP, Zabbix został zaprojektowany jako uniwersalna platforma monitorujaca. Jego native agent (Zabbix Agent) instaluje się na serwerze Linux/Windows i zbiera szczegółowe metryki systemowe - obciążenie CPU, zużycie pamięci, miejsce na dysku, procesy, usługi.

Zabbix oferuje również bezagentowe monitorowanie przez SNMP (tak jak LibreNMS), IPMI (dla sprzętu serwerów), JMX (dla aplikacji Java) oraz proste testy TCP/HTTP (dla usług sieciowych). Dzięki temu jeden system może monitorowac cała infrastrukturę - od przełączników, przez serwery, po aplikacje.

Elastyczność Zabbixa jest jego największa Zaletą, ale także wada - konfiguracja jest bardziej zlozona niż w LibreNMS. każda metryke (Item) trzeba zdefiniować ręcznie lub zaimportować z szablonu (Template). Szablony są dostępne dla tysięcy urządzeń i aplikacji w społecznośći Zabbix (Zabbix Share).

Model danych w Zabbix opiera się na trzech podstawowych koncepcjach: Items (metryki), Triggers (progi alarmowe) i Actions (reakcję). Item to definicja pojedynczej metryki - co zbieramy (np. obciążenie CPU), skad (agent Zabbix, SNMP, IPMI), jak często (interwał) i jak przechowywać (historia, trend).

Trigger to wyrażenie logiczne, które na podstawie wartości Items generuje zdarzenia. Przykład: {Template:system.cpu.load.avg(5m)}>0.8 oznacza "jeśli średnie obciążenie CPU z ostatnich 5 minut przekracza 80%, wygeneruj zdarzenie PROBLEM". Trigger może mieć wiele poziomów (Warning, Average, High, Disaster) z róznymi progami.

Action definiuje automatyczna reakcję na zdarzenie wygenerowane przez Trigger. Typowe akcje to: wysłanie powiadomienia e-mail, SMS przez bramkę, webhook do Slack/Teams, uruchomienie skryptu na serwerze (np. restart usługi). Akcja może mieć warunki (send tylko w godzinach pracy) i eskalacje.

eskalacją to sekwencja działań, która uruchamia się, jeśli problem nie zostanie rozwiązańy w określonym czasie. Przykład: 0-15 minut - e-mail do admina, 15-30 minut - e-mail do przełożonego, powyżej 30 minut - SMS do kierownika zmiany. Zabbix automatycznie zamyka eskalacje po rozwiązańiu problemu.

Wybór odpowiedniego systemu NMS zależy przede wszystkim od charakteru monitorowanej infrastruktury i wymagań dotyczacych alertów oraz raportowania. Dla zespółów sieciowych, które potrzebuja szybkiego wglądu w stan urządzeń sieciowych, LibreNMS lub Observium będą najlepszym wyborem Dzięki automatycznemu wykrywaniu urządzeń i gotowym integracjom.

Dla organizacji, które chca monitorowac zarówno siec, jak i serwery, aplikacje oraz usługi w jednym systemie, Zabbix oferuje największa Elastyczność. możliwość definiowania własnych szablonów i zaawansowanych regul alertów sprawia, że Zabbix sprawdza się w złożonych środowiskach.

Dla małych firm (do 50 urządzeń) najlepszym wyborem będzie LibreNMS - jest darmowy, latwy w instalacji i nie wymaga dużych zasobów sprzętowych. W średnich organizacjach (50-500 urządzeń) Zabbix lub LibreNMS sprawdza się równie dobrze, w zależności od preferencji zespołu.

W dużych organizacjach (powyżej 1000 urządzeń) i u operatorów telekomunikacyjnych często wybiera się Observium Professional że względu na stabilność, wsparcie techniczne i dojrzałość produktu. często stosuje się również podejście hybrydowe: LibreNMS do monitoringu sieci + Zabbix do serwerów i aplikacji.

Laboratorium rozpoczyna się od instalacji agenta SNMP (snmpd) na serwerze Linux. W dystrybucjach opartych na Debianie/Ubuntu pakiet snmpd jest dostępny w standardowych repozytoriach. Instalujemy również pakiet snmp (narzędzia klienckie) oraz snmp-mibs-downloader (standardowe MIB).

Po instalacji usługa snmpd uruchamia się automatycznie. Domyślna konfiguracja w Ubuntu nasłuchuje tylko na localhost (127.0.0.1) z community "public" w trybie read-only. Jest to bezpieczne domyślne ustawienie - wymaga świadomej zmiany, aby udostępnić SNMP w sieci.

Pakiet snmp-mibs-downloader pobiera i instaluje standardowe pliki MIB z IETF (RFC). Dzięki temu narzędzia takie jak snmpwalk będą wyświetlac czytelne nazwy OID zamiast surowych numerów. Po instalacji MIB należy odkomentować linie "mibs" w pliku /etc/snmp/snmp.conf.

Test lokalny za pomocą snmpget dla OID sysUpTime (1.3.6.1.2.1.1.3.0) powinien zwrócić czas pracy systemu w setnych sekundy. jeśli polecenie zwraca błąd, należy sprawdzić, czy usługa snmpd jest uruchomiona i czy nie ma błędu w konfiguracji.

Konfiguracja SNMPv2c w laboratorium polega na edycji pliku /etc/snmp/snmpd.conf. kluczową dyrektywą jest rocommunity, która definiuje community string "public" dla odczytu. Dodanie sieci 192.168.1.0/24 ogranicza dostęp tylko do zapytań pochodzących z tej sieci - to podstawowa warstwa bezpieczeństwa.

Dyrektywy sysLocation, sysContact i sysName wypełniaja metadane systemowe. W środowisku produkcyjnym te informacje pomagają szybko zidentyfikować urządzenie - gdzie się znajduje, kto jest odpowiedzialny, jaka jest nazwa hosta. W laboratorium służą do nauki konfiguracji.

Zmiana agentAddress z domyślnego udp:127.0.0.1:161 na udp:161 powoduje, że snmpd nasłuchuje na wszystkich interfejsach sieciowych. Bez tej zmiany zdalne zapytania SNMP nie będą działać. W środowisku produkcyjnym zaleca się podanie konkretnego adresu IP interfejsu zarządzania.

Po zapisaniu pliku i restarcie usługi (systemctl restart snmpd) należy sprawdzić logi systemowe (journalctl -u snmpd), czy nie ma błędów konfiguracji. następnie można przystąpić do testów zdalnych z innego hosta w sieci.

snmpwalk to podstawowe narzędzie do odpytywania drzewa OID agenta SNMP. Działa na zasadzie iteracyjnego wywoływania GetNext, aż do osiągniecia konca gałęzi. snmpwalk jest najczęściej używanym narzędziem do eksploracji dostępnych OID na urządzeniu i weryfikacji, czy agent działa poprawnie.

Podstawowa Składnia: snmpwalk -v2c -c public 192.168.1.10 1.3.6.1.2.1.1. Flaga -v2c określa wersje protokołu (v2c), -c public podaje community string, następnie adres IP agenta i OID gałęzi do odczytania. snmpwalk zwróci wszystkie OID i wartości w tej gałęzi.

Odczyt gałęzi 1.3.6.1.2.1.1 (system group) zwraca informacje o systemie: sysDescr (opis urządzenia), sysObjectID (identyfikator producenta), sysUpTime (czas pracy), sysContact, sysName, sysLocation. To pierwszy test, który powinien wykonać administrator po skonfigurowaniu SNMP.

Odczyt gałęzi 1.3.6.1.2.1.2 (IF-MIB) zwraca szczegółową tabele interfejsów: ifIndex (indeks), ifDescr (opis), ifType (typ), ifMtu, ifSpeed (przepustowość), ifAdminStatus (administracyjny stan), ifOperStatus (operacyjny stan) oraz liczniki ifInOctets, ifOutOctets.

snmpget służy do pobrania wartości pojedynczego OID lub kilku OID w jednym zapytaniu. W przeciwieństwie do snmpwalk, które iteruje po całej gałęzi, snmpget zadaje konkretne OID i natychmiast otrzymuje odpowiedź. To narzędzie jest używane do szybkiego sprawdzania konkretnych metryk.

Przykładowo: snmpget -v2c -c public 192.168.1.10 1.3.6.1.2.1.1.3.0 zwróci czas pracy urządzenia (sysUpTime) w setnych sekundy. jeśli urządzenie działa od 3 dni, wynik wyniesie około 25920000 (3 * 24 * 3600 * 100). Jest to szybki test dostępności i poprawności konfiguracji SNMP.

można również pobrać wiele OID w jednym wywołaniu snmpget, co jest efektywniejsze niż osobne zapytania. Na Przykład: snmpget -v2c -c public 192.168.1.10 .1.3.6.1.2.1.1.3.0 .1.3.6.1.2.1.1.5.0 zwróci jednocześnie sysUpTime i sysName w jednym cyklu komunikacji.

snmpstatus to wygodne narzędzie do szybkiego sprawdzenia, czy agent odpowiada. Wykonuje on kilka podstawowych zapytań: o sysUpTime, liczbę interfejsów (ifNumber) oraz adres IP interfejsów. Wynik jest prezentowany w czytelnej formie. jeśli snmpstatus zwraca błąd, agent nie jest dostępny lub konfiguracja jest niepoprawna.

Po skonfigurowaniu agenta SNMP na serwerze Linux (lub przełączniku) można dodać urządzenie do LibreNMS. Proces jest identyczny niezależnie od typu urządzenia - LibreNMS sam wykrywa, czy to przełącznik Cisco, serwer Linux, czy router MikroTik.

Dodanie przez CLI: z katalogu instalacyjnego LibreNMS (domyślnie /opt/librenms) uruchamiamy skrypt addhost.php z parametrami: adres IP, community string i wersja SNMP. Skrypt natychmiast dodaje urządzenie do bazy i uruchamia proces discovery.

Dodanie przez Web UI: wybieramy Devices > Add Device, wypełniamy formularz - hostname (adres IP lub DNS), community, wersja SNMP (v1, v2c, v3). Po kliknieciu Submit LibreNMS uruchamia discovery. W przypadku SNMPv3 należy podac dodatkowo nazwę użytkownika, poziomy uwierzytelniania i szyfrowania oraz hasła.

Po dodaniu urządzenia należy odczekać jeden cykl pollingu (domyślnie 5 minut), aby dane pojawiły się na wykresach. można przyspieszyć ten proces, uruchamiając ręcznie poller dla konkretnego hosta: ./poller.php -h 192.168.1.10. Flaga -r wymuszą rediscovery, -f force - ignoruje błędy.

Po dodaniu urządzenia i pierwszym cyklu pollingu dane są dostępne w interfejsie webowym LibreNMS. Zakladka Overview wyświetla ogólne informacje o urządzeniu: adres IP, typ urządzenia (wykryty automatycznie), wersje systemu operacyjnego, czas pracy (uptime), lokalizację oraz kontakt.

Zakladka Graphs to centrum analizy danych. LibreNMS automatycznie generuje wykresy dla: obciążenia CPU (w procentach), ruchu na interfejsach (bps), temperatury wewnętrznej (°C), zużycia pamięci, obciążenia łącza w percentylu 95. Wykresy można przeglądać w skali: 1 godzina, 6 godzin, 24 godziny, 7 dni, 30 dni, 1 rok.

Zakladka Ports wyświetla liste wszystkich interfejsów urządzenia z informacja o statusie administracyjnym (up/down) i operacyjnym (up/down), obciążeniu w bps oraz liczbie błędów. Interfejsy z błądami są podświetlane na czerwono, co ułatwia szybka identyfikację problemów.

Dashboard to konfigurowalny panel, na który można dodać dowolne wykresy z różnych urządzeń. Typowy dashboard inżyniera sieciowego zawiera: ogólny status wszystkich urządzeń (global summary), wykres obciążenia łącza internetowego, temperaturę w serwerowni, liste ostatnich alertów oraz mape sieci.

Brak odpowiedzi agenta SNMP to najczęstszy problem podczas wdrażania monitoringu. Procedura diagnostyczna zaczyna się od sprawdzenia, czy usługa snmpd w ogóle działa na monitorowanym urządzeniu. Polecenie systemctl status snmpd pokaże, czy usługa jest aktywna, czy wystąpily błędy przy starcie.

Test lokalny na agencie (snmpwalk -v2c -c public 127.0.0.1) pozwala określić, czy problem leży po stronie agenta, czy po stronie sieci. jeśli zapytanie lokalne działa, problem jest w firewalu lub routingu. jeśli nie działa - problem w konfiguracji snmpd.conf.

Firewall to częsta przyczyna problemów. W systemach Linux należy sprawdzić reguły iptables/nftables lub firewall-cmd (firewalld). Port UDP 161 musi być otwarty dla ruchu przychodzacego z adresu NMS. Regula: iptables -A INPUT -p udp --dport 161 -s 192.168.1.100 -j ACCEPT.

Polecenie netstat -tulpn | grep 161 pokazuje, czy proces snmpd nasłuchuje na porcie 161 i na jakich interfejsach. jeśli snmpd nasłuchuje tylko na 127.0.0.1:161, zapytania zdalne nie będą działać. Należy wtedy zmienić agentAddress w snmpd.conf na udp:161 (wszystkie interfejsy).

Drugi najczęstszy problem to błędny community string lub zbyt restrykcyjną ACL. jeśli test z poprawnym adresem IP i portem działa lokalnie, ale nie zdalnie, należy sprawdzić, czy używany community string jest zgodny z konfiguracja agenta.

W systemie Linux konfiguracja rocommunity w pliku /etc/snmp/snmpd.conf definiuje dozwolone community i opcjonalnie sieci źródleme. jeśli linia brzmi "rocommunity public 127.0.0.1", to tylko zapytania z localhost są akceptowane. Należy rozszerzyc na "rocommunity public 192.168.1.0/24".

Na urządzeniach Cisco konfigurację SNMP sprawdzamy komendą "show snmp community". wyświetli ona liste community stringów z przypisanymi ACL. jeśli ACL jest zbyt restrykcyjna, zapytania z serwera NMS będą odrzucane. Sprawdzamy też "show access-lists".

Logi agenta SNMP są niezbędne do diagnostyki. W systemie Linux: journalctl -u snmpd pokaże komunikaty o błądach uwierzytelniania (authenticationFailure). Na Cisco: "debug snmp packets" włącza szczegółowy podgląd pakietów SNMP - ale należy używać ostrożnie w produkcji, bo obciąża CPU.

błędy w konfiguracji snmpd.conf mogą powodowac różne objawy - od całkowitego braku odpowiedzi, przez puste wartości OID, po komunikaty "No Such Instance". Podstawowa metoda diagnostyczna jest uruchomienie snmpd w trybie pierwszoplanowym z opcjami -f -Lo, który wyświetla logi bezpośrednio na konsoli.

Częstym błędem jest brak dyrektywy rocommunity w pliku snmpd.conf. Bez niej agent nie akceptuje żadnych zapytań SNMP. Inny błąd to agentAddress ustawiony domyślnie na 127.0.0.1, co uniemozliwia zapytania zdalne. W przypadku SNMPv3 błędna Składnia createUser powoduje, że użytkownik nie zostanie utworzony.

Komunikat "No Such Instance" pojawia się, gdy agent SNMP działa, ale nie posiada zadanej wartości OID. Przyczyna może być: brak zainstalowanego MIB producenta, nieobsługiwana funkcja na danym modelu urządzenia, lub zły indeks w tabeli. Na przykład ifInOctets.999 nie istnieje, jeśli urządzenie ma tylko 24 porty.

W przypadku SNMPv3 z VACM, pusty widok (view) przypisany do grupy spowoduje, że użytkownik będzie mógł się uwierzytelnic, ale nie zobaczy żadnych OID (puste odpowiedzi). Należy wtedy sprawdzić definicje view i przypisanie do grupy komendą "snmp-server group / rouser".

Problemy z MIB (Management Information Base) są częste w praktyce inżynierskiej. Gdy snmpwalk zwraca linie w formacie ".1.3.6.1.2.1.1.1.0 = STRING: ..." zamiast czytelnej nazwy "sysDescr.0", oznacza to, że system NMS nie ma zainstalowanego odpowiedniego pliku MIB.

Standardowe MIB z IETF są dostarczane w pakiecie snmp-mibs-downloader. Po jego instalacji należy odkomentować lub dodać linie "mibs +ALL" w pliku /etc/snmp/snmp.conf (uwaga: to plik konfiguracyjny narzędzi klienckich, nie snmpd). W przypadku MIB producentów, trzeba ręcznie pobrać pliki .mib z ich stron internetowych.

Puste wartości OID (No Such Object/No Such Instance) pojawiaja się, gdy urządzenie nie obsługuje danego OID. Typowa sytuacja: próba odczytu temperatury przez OID Cisco (1.3.6.1.4.1.9.9.109) na urządzeniu innego producenta, lub odczyt OID z wyższej wersji IOS na starszym modelu przełącznika.

Aby zdiagnozować problem z brakującymi wartościami, należy najpierw sprawdzić, jakie gałęzie OID są dostępne: snmpwalk -v2c -c public 192.168.1.10 1.3.6.1.2.1. (standardowe) i 1.3.6.1.4.1. (producenta). jeśli dana gałąź nie istnieje, agent zwróci koniec widocznego drzewa (End of MIB).

Cheat Sheet to zbior najważniejszych komend, które każdy inżynier sieciowy powinien znać i mieć pod ręką podczas pracy z SNMP. Uwzględniono zarówno komendy konfiguracji agenta na Linux, jak i narzędzia klienckie do odpytywania oraz najważniejsze OID standardowe.

W konfiguracji agenta kluczowe jest: instalacja pakietu (snmpd), konfiguracja rocommunity z ograniczeniem ACL (rocommunity public 192.168.1.0/24), zmiana agentAddress na udp:161 dla dostępu zdalnego oraz restart usługi. Warto też odkomentować linie "mibs +ALL" w /etc/snmp/snmp.conf dla czytelnych nazw OID.

Narzędzia klienckie: snmpwalk (iteracja po drzewie - najczęściej używane), snmpget (pojedynczy OID - do monitoringu), snmpstatus (szybki test - odpowiednik ping dla SNMP), snmpbulkwalk (optymalizacja - używa GetBulk z SNMPv2c). Dla SNMPv3 należy pamiętać o parametrach: -u user, -a auth_protocol, -A auth_pass, -x priv_protocol, -X priv_pass.

Najważniejsze OID: sysUpTime (dostępność), ifInOctets/ifOutOctets (obciążenie łącza), hrProcessorLoad (CPU Linux), sysName (identyfikacja). Do monitorowania temperatury i wentylatorów na urządzeniach Cisco służą OID z gałęzi CISCO-ENVMON-MIB (1.3.6.1.4.1.9.9.13).

Dzisiejszy warsztat poprowadził nas przez cały proces monitorowania sieci - od zrozumienia, dlaczego monitoring jest ważny, przez szczegóły protokołu SNMP i jego bezpieczeństwa, aż po praktyczną konfigurację narzędzi NMS i rozwiązywanie problemów. To wiedza niezbędna każdemu inżynierowi sieciowemu.

Protokół SNMP, mimo swojego wieku, pozostaje fundamentem monitoringu IT. Znajomość SNMP jest wymagana na każdym stanowisku związanym z administracją sieci - od helpdesku, przez inżyniera sieci, po architekta infrastruktury. Bez SNMP nie ma mowy o proaktywnym zarządzaniu.

Systemy NMS takie jak LibreNMS (open-source) i Observium (komercyjny) automatyzują proces zbierania i wizualizacji danych SNMP. Zabbix oferuje jeszcze większe możliwości, ale kosztem złożoności konfiguracji. Wybór narzędzia zależy od skali infrastruktury, budżetu i kompetencji zespołu.

Pamiętaj o kluczowych zasadach: stosuj SNMPv3 w produkcji, ograniczaj dostęp ACL i firewallem, monitoruj trendy a nie pojedyncze wartości, dokumentuj historię awarii i planuj Capacity Planning. Zachęcam do dalszego zgłębiania tematu z wykorzystaniem materialów dodatkowych wymienionych na slajdzie.