Ewolucja narzędzia do automatycznego wykrywania SNMP: od snmpwalk do gotowych szablonów Zabbix 7

Spis treści

1. Wprowadzenie: dlaczego SNMP wciąż sprawia problemy
2. Punkt wyjścia: klasyczny dramat inżyniera monitoringu
3. Czym jest snmp-scanner
4. Pierwszy etap: automatyczne wykrywanie interesujących OID-ów
5. Prawdziwy problem: nie wykrywanie, lecz kuracja danych
6. Dodawanie kontekstu: od surowych OID-ów do metryk monitoringowych
7. Wiedza domenowa: czego uczą istniejące systemy monitoringu
8. Wielka przebudowa: model wiedzy skoncentrowany na urządzeniu
9. Sześć lekcji z budowy narzędzia SNMP auto-discovery
10. Jak działa snmp-scanner dzisiaj – krok po kroku
11. Stan obecny i plany rozwoju
12. Najczęściej zadawane pytania (FAQ)
13. Podsumowanie

1. Wprowadzenie: dlaczego SNMP wciąż sprawia problemy

Protokół SNMP (Simple Network Management Protocol) istnieje od dekad i teoretycznie powinien czynić monitoring urządzeń sieciowych prostym zadaniem. W praktyce każdy, kto choć raz próbował zbudować szablon monitoringu dla nowego urządzenia – switcha, macierzy NAS, zasilacza UPS czy firewalla – wie, że rzeczywistość wygląda inaczej. Samo „odkrycie”, że urządzenie udostępnia dane przez SNMP, to dopiero początek drogi.

Ten artykuł to rozszerzone, praktyczne opracowanie historii powstania snmp-scanner – narzędzia napisanego w Node.js z interfejsem webowym, które automatyzuje proces przechodzenia od surowego zrzutu SNMP (tzw. walk) do gotowego, importowalnego szablonu Zabbix 7 opartego na mechanizmie walk-based LLD (Low-Level Discovery). Opisujemy nie tylko funkcjonalność narzędzia, ale przede wszystkim wnioski i błędy, które doprowadziły twórców do zmiany filozofii projektu – z „narzędzia do wykrywania OID-ów” na „narzędzie do kuracji wiedzy monitoringowej”.

2. Punkt wyjścia: klasyczny dramat inżyniera monitoringu

Scenariusz jest znany każdemu, kto zajmuje się monitoringiem infrastruktury IT. Do sieci trafia nowe urządzenie od producenta, którego jeszcze nie ma w bibliotece szablonów Zabbix. Standardowa procedura wygląda tak:

• Sprawdzasz listę gotowych szablonów Zabbix – brak dopasowania.
• Pobierasz pakiet MIB od producenta – zawiera setki, czasem tysiące definicji.
• Uruchamiasz snmpwalk na urządzeniu – wynik to tysiące linii surowego tekstu.
• Zaczyna się najtrudniejsza część: interpretacja tego, co faktycznie oznaczają te dane dla monitoringu.

Kluczowy problem nie polega na tym, że trudno ustalić, jakie OID-y istnieją – to zadanie stosunkowo proste i dobrze zautomatyzowane. Prawdziwym wyzwaniem jest decyzja, które z tych OID-ów zasługują na miejsce w produkcyjnym szablonie, a które wygenerują tylko szum, zduplikowane dane albo regułę discovery, która sama się zawiesi przez przeciążenie (timeout).

Twórcy narzędzia postawili sobie zadanie inne niż „zautomatyzować SNMP” – SNMP samo w sobie już dostarcza dane w nadmiarze. Celem było skrócenie drogi od pierwszego walk do użytecznego szablonu Zabbix, bez złudzenia, że automatyzacja może zastąpić inżynierski osąd.

3. Czym jest snmp-scanner

snmp-scanner to aplikacja Node.js z warstwą webową, która:

• wykonuje walk SNMP na urządzeniu (SNMPv2c/v3) lub importuje istniejący plik walk,
• analizuje strukturę OID-ów,
• dopasowuje wbudowaną bazę wiedzy o urządzeniach (device knowledge base),
• eksportuje gotowy szablon Zabbix 7 oparty na walk-based LLD.

Interfejs zakładki „Scan” pokazuje host, wersję SNMP oraz postęp walk w czasie rzeczywistym – dając pełną widoczność od pierwszej sekundy skanowania. To ważne założenie projektowe: narzędzie nigdy nie ukrywa surowych danych, nawet gdy automatycznie sugeruje wybór.

4. Pierwszy etap: automatyczne wykrywanie interesujących OID-ów

Naturalnym pierwszym pomysłem było zbudowanie narzędzia, które jednym kliknięciem automatyzuje wykrywanie OID-ów. Założenie było proste: jeśli program potrafi programowo wskazać „interesujące” obiekty, zaoszczędzi to godziny ręcznego przeszukiwania (grep) plików walk.

Wczesne wersje narzędzia skupiały się na czterech krokach:

1. Ustalenie numeru enterprise na podstawie sysObjectID.
2. Wykrycie producenta – na bazie identyfikatora enterprise, sysDescr oraz metadanych katalogowych.
3. Zebranie modułów MIB – parsowanie plików .mib producenta lub rozwiązywanie nazw przez snmptranslate.
4. Wybór kandydatów – skalary, kolumny tabel oraz korzenie tabel, które wyglądały na nadające się do monitorowania.

Na pierwszy rzut oka podejście działało lepiej, niż się spodziewano. Wykrywanie producenta dawało solidny punkt zaczepienia, import MIB uzupełniał symbole i etykiety, a analiza tabel oddzielała skalary od struktur indeksowanych. Po raz pierwszy wynik walk przestawał wyglądać jak ściana liczb.

Problem polegał jednak na tym, że rozwiązywano niewłaściwy problem główny.

5. Prawdziwy problem: nie wykrywanie, lecz kuracja (curation) danych

To zdanie stało się punktem zwrotnym całego projektu:

Znalezienie OID-ów jest łatwe. Trudność polega na ustaleniu, które z nich mają znaczenie.

Typowy walk enterprise na urządzeniu sieciowym lub storage’owym zwraca znacznie więcej danych, niż jakikolwiek rozsądny szablon powinien zawierać. Większość z nich mieści się w kategoriach, które wyglądają istotnie – dopóki nie spróbuje się je faktycznie wykorzystać operacyjnie:

• Obiekty konfiguracyjne – przydatne do inwentaryzacji, rzadko do alertowania.
• Liczniki diagnostyczne i debugowe – ciekawe w laboratorium, uciążliwe w produkcji.
• Liczniki bez znaczenia operacyjnego – rosną, ale nikt nie wie, co zrobić, gdy się zmieniają.
• Duplikaty – to samo zjawisko wystawione pod różnymi OID-ami lub w różnych strukturach tabel.
• Setki tabel – wiele z jednym wierszem, dziwnym indeksowaniem lub bez stabilnego klucza discovery.

Zespół przekonał się o tym boleśnie w praktyce. Wczesne eksporty generowały szablony z setkami elementów. Reguły discovery notorycznie osiągały timeout. Makra LLD nie odpowiadały kolumnom indeksu. Elementy miały technicznie poprawne OID-y, ale praktycznie bezużyteczne nazwy.

Narzędzie było dobre w wykrywaniu (discovery). Nie było jeszcze dobre w kuracji (curation) danych.

Ta różnica stała się główną zasadą projektową:

Pokaż pełny walk. Skuracjonuj wybór.

Katalog sugeruje – inżynier decyduje. Nic nie jest ukryte, ale nie wszystko jest wybierane automatycznie.

6. Dodawanie kontekstu: od surowych OID-ów do metryk monitoringowych

Skoro wykrywanie OID-ów było dopiero pierwszym krokiem, narzędzie musiało odpowiadać na trudniejsze pytania dotyczące każdego skanowanego kandydata:

W tym miejscu snmp-scanner przestał być zwykłą przeglądarką walk, a stał się czymś więcej.

Analiza OID-ów klasyfikuje skalary względem tabel i próbkuje dane wierszy. Receptury tabelaryczne obsługują znane struktury, takie jak IF-MIB czy ENTITY-MIB, gdzie generyczne parsowanie zawodzi.

Polityki elementów (item policies) stosują globalne reguły dotyczące typów, jednostek i preprocessingu. Logika makr LLD wyprowadza {#SNMPINDEX} oraz opcjonalne makra wyświetlania na podstawie kolumn INDEX oraz pól name/descr.

Nie mniej istotne okazały się kontrole „eligibility” walk. Tabela z 4000 wierszy i 12 wybranymi kolumnami nie jest po prostu „wykrywalna” – może być zbyt duża, by bezpiecznie ją zwalkować. Narzędzie szacuje teraz liczbę varbindów, stosuje limity i informuje w interfejsie o pominiętych tabelach jeszcze przed eksportem.

Dla Zabbixa twórcy zdecydowali się na wczesnym etapie na walk-based discovery. W Zabbix 7 oznacza to zależne reguły discovery zasilane łańcuchem preprocessingu z jednego master walk SNMP, zamiast mnożenia osobnych elementów SNMP dla każdej kolumny.

Ten wybór oznacza wyższą złożoność podczas tworzenia szablonu, ale w zamian daje efektywność i spójność w czasie działania – pod warunkiem, że wybrane zostaną właściwe tabele i kolumny.

7. Wiedza domenowa: czego uczą istniejące systemy monitoringu

Surowe pliki MIB mówią, co producent zdefiniował. Nie mówią, co operatorzy faktycznie monitorują.

Dlatego zespół poszukał wiedzy gdzie indziej – nie w sensie zależności uruchomieniowych, ale jako źródła wiedzy domenowej.

Oficjalne i społecznościowe szablony Zabbix stały się głównym źródłem wzbogacania danych. Na etapie developmentu parsowany jest YAML szablonów, a metadane łączone są według OID w pakiety urządzeń (device bundles): klucze elementów, kroki preprocessingu, prototypy triggerów, mapy wartości. Nic nie jest pobierane z Zabbixa w czasie skanowania – wiedza jest wersjonowana w repozytorium git i dostarczana razem z narzędziem.

Na bazie ogólnodostępnych informacji od innych producentów zbudowano również własny model wykrywania systemu operacyjnego – rozbudowaną, sprawdzoną w boju mapę prefiksów sysObjectID, wzorców sysDescr oraz odcisków palców (fingerprintów) urządzeń, pełniącą funkcję warstwy podpowiedzi dla dopasowania katalogowego. To odpowiednik zdania: „tysiące wdrożeń już sklasyfikowało ten kształt urządzenia”.

Ta sama zasada dotyczy historycznego zasilania danymi z profili innych narzędzi monitoringowych: pochodzenie danych i zgodność między źródłami liczą się bardziej niż jakiekolwiek pojedyncze drzewo producenta.

Kluczowy wniosek brzmi: istniejące projekty monitoringowe to baza wiedzy o tym, co ludzie już uznali za warte obserwowania.

Import MIB odpowiada na pytanie „co istnieje”. Szablony monitoringowe odpowiadają na pytanie „czego ludzie faktycznie używają”.

Aktualny priorytet zasilania danymi wygląda następująco:

1. Szablony Zabbix → kuracja + klucze + triggery
2. Walki SNMP → dowód, że powiązanie działa na danym urządzeniu
3. Katalog OID → tożsamość (symbol, etykieta, moduł MIB)
4. Parsowanie MIB → wyłącznie kandydaci! Nigdy nie są automatycznie rekomendowani samodzielnie!

8. Wielka przebudowa: model wiedzy skoncentrowany na urządzeniu

Kolejne wąskie gardło miało charakter semantyczny, nie techniczny.

To samo znaczenie monitoringowe – np. wykorzystanie CPU, stan dysków SMART, ruch na interfejsie – pojawiało się pod różnymi OID-ami w zależności od producenta, szablonu i modułu MIB.

Istniały równoległe struktury: presety integracyjne, katalogi OID, profile monitoringowe, kategorie sugestii oraz scoring kluczowany po OID. Brakowało wspólnej tożsamości dla pojęcia „co dokładnie jest mierzone”.

Odpowiedzią stała się migracja w kierunku modelu wiedzy skoncentrowanego na urządzeniu (device-centric):

• Metryka to znaczenie monitoringowe (np. cpu_utilization, disk_smart, if_in_octets).
• Wiązanie (binding) to sposób, w jaki dana metryka pojawia się na konkretnym produkcie.
• Tożsamość OID pozostaje globalna, a pliki urządzeń jedynie się do niej odwołują.

Scoring został celowo podzielony na trzy warstwy:

Zasada nadrzędna: wynik dopasowania urządzenia i ranga metryki nigdy nie mogą się zlewać. Wybór właściwego modelu switcha Cisco to zupełnie inny problem niż ranking, które metryki powinny znaleźć się w szablonie.

Zespół skonsolidował także około 830 przestarzałych presetów integracyjnych w enterprise’owe pakiety urządzeń (device bundles) – natywne, kuratorowane pakiety tam, gdzie to możliwe, a skonsolidowane szkice tam, gdzie jeszcze nie – zachowując przy tym wsteczną kompatybilność dzięki warstwie wirtualnego adaptera.

9. Sześć lekcji z budowy narzędzia SNMP auto-discovery

Lekcja 1: Większość danych SNMP nie jest przydatna do monitoringu

Pełny walk to kompletna inwentaryzacja tego, co udostępnia agent. Dobry szablon to podzbiór wybrany pod kątem operacyjności. Mylenie tych dwóch pojęć prowadzi do szablonów z 500 elementami, których nikt nie utrzymuje.

Lekcja 2: Klasyfikacja urządzenia liczy się bardziej niż wykrywanie OID-ów

Wiedza, że mamy do czynienia z urządzeniem QNAP QTS 5, switchem Cisco IOS-XE czy macierzą NetApp FAS, zawęża zbiór kandydatów skuteczniej niż jakakolwiek ogólna heurystyka „interesującego OID-u”. Reguły dopasowania oparte na sysObjectID, sysDescr i identyfikatorze enterprise przewyższają samo dopasowywanie wzorców symboli.

Lekcja 3: Tabele są często cenniejsze niż obiekty skalarowe

Skalary dają nazwę hosta i czas działania (uptime). Tabele dają interfejsy, dyski, czujniki, wentylatory i zasilacze – struktury, dla których w ogóle wymyślono LLD. Wykrywanie korzeni tabel, obsługa indeksów i receptury walk zasłużyły na więcej uwagi inżynierskiej niż samo dobieranie skalarów.

Lekcja 4: Generowanie wszystkiego tworzy szablony nie do użycia

Pierwszą metryką sukcesu była liczba elementów. Użyteczną metryką jest liczba elementów możliwa do utrzymania. Wprowadzono politykę bezpiecznego automatycznego wyboru: twarde limity liczby automatycznie wybieranych elementów, szkice z MIB nigdy niewybierane automatycznie oraz uczenie progresywne dopiero po powtarzalnym wyborze użytkownika.

Lekcja 5: Dobre filtrowanie jest ważniejsze niż dobre wykrywanie

Wykrywanie mówi, co istnieje. Filtrowanie mówi, co należy do produkcji. Globalne listy wykluczeń, sugestie zależne od klasy urządzenia, poziomy wartości monitoringowej oraz limity rozmiaru walk to nie dodatki – to sedno produktu.

Lekcja 6: Istniejące projekty monitoringowe zawierają cenną wiedzę domenową

MIB-y są niezbędne. Szablony są nacechowane opinią (opinionated). Połączenie mądrości szablonów, dowodu z walk oraz tożsamości z MIB pokonuje jakiekolwiek pojedyncze źródło z osobna.

10. Jak działa snmp-scanner dzisiaj – krok po kroku

Aktualny przepływ pracy wygląda następująco:

1. Skanowanie urządzenia (SNMPv2c/v3) lub import istniejącego pliku walk.
2. Analiza struktury OID – skalary, tabele, próbki wierszy.
3. Dopasowanie pakietu urządzenia z katalogu (ok. 830 pozycji urządzeń, stopniowo konsolidowanych w natywne pakiety).
4. Wstępny wybór metryk poprzez trzy warstwy: uniwersalne domyślne ustawienia, preset urządzenia oraz sugestie heurystyczne.
5. Edycja profilu discovery w interfejsie – przełączanie wyboru, dostosowywanie makr, przegląd limitów walk.
6. Eksport szablonu Zabbix 7 w formacie YAML i import przez API.

Kluczowe właściwości narzędzia

• Pełny walk, skuracjonowany wybór – nic nie jest ukryte.
• Wiedza w formacie JSON w repozytorium git – brak bazy danych w czasie działania, brak pobierania na żywo z zewnętrznych repozytoriów.
• Walk-based LLD dla Zabbix 7.
• Import MIB dla tożsamości OID; szkice MIB-do-urządzenia dla pakietów kandydatów, weryfikowane przez kuratora przed promocją.
• Uczenie kluczowane metryką – powtarzalne wybory użytkownika wpływają na ranking w czasie działania, nie na repozytorium git, dopóki maintainer ich nie zatwierdzi.
• Fixtury regresyjne – zmiany w pipeline testowane na zanonimizowanych walkach (NetApp, Palo Alto, Cisco i inne) bez potrzeby aktywnego SNMP.

Narzędzie obsługuje dwie grupy odbiorców jednocześnie: inżynierów, którzy chcą eksplorować i debugować walk, oraz inżynierów, którzy chcą szybciej wdrożyć szablon dla znanej klasy urządzenia.

11. Stan obecny i plany rozwoju

Projekt przeszedł fazę „znajdź OID-y” i znajduje się głęboko w fazie „zarządzaj automatyzacją” (governance).

Bieżące prace koncentrują się na kontrolowanym automatycznym wyborze: pierwsze skanowanie respektuje wyłącznie kuratorowane w git wiązania default_selected; kolejne skanowania mogą stosować „miękki” automatyczny wybór, gdy uczenie społecznościowe i wynik efektywny przekroczą progi – zawsze w ramach limitów bezpiecznych dla szablonu. Szkice pochodzące z MIB pozostają w zakresie kandydatów, dopóki człowiek ich nie zatwierdzi.

Katalog jest w trakcie migracji: przestarzały JSON integracyjny jest wycofywany na rzecz kanonicznych pakietów devices/*.json, z zachowaniem syntezy dla wstecznej kompatybilności. Dane katalogu OID są dzielone (shardowane) pod kątem skalowalności. Wykrywanie systemu operacyjnego i wzbogacanie danymi Zabbix funkcjonują obok natywnych pakietów dla producentów w pełni „przewalkowanych” i skuratorowanych, takich jak Cisco, QNAP, NetApp, Palo Alto, Eaton czy F5.

Twórcy są uczciwi co do granic automatyzacji: nie zastępuje ona osądu przy projektowaniu szablonu. Kompresuje żmudny środek procesu – parsowanie walk, nazewnictwo, wykrywanie tabel, dopasowywanie presetów i wstępną strukturę elementów.

Plany na przyszłość

• Lepsze generowanie triggerów – łączenie większej liczby semantyk prototypów triggerów ze źródłowych szablonów Zabbix; rozwinięcie eksportu triggerów na poziomie skalarów i tabel poza domyślne wzorce typu uptime.
• Inteligentniejsza klasyfikacja metryk – rozszerzenie rejestru metryk i taksonomii cech (CPU, pamięć, zdrowie dysków, interfejsy, zasilacze itd.); wyprowadzanie poziomów bezpośrednio z monitoring_value zamiast równoległych systemów scoringu; formalizacja cyklu życia wiązania: kandydat → sprawdzony (known_good) → rekomendowany → zablokowany.
• Rekomendacje monitoringowe wspomagane AI – sztuczna inteligencja ma pełnić funkcję akceleratora rankingu i przeglądu, a nie autonomicznego autora szablonów. Twarde ograniczenia – rozmiar walk, sensowność triggerów, klasa urządzenia, wykrywanie duplikatów – pozostają strukturalne. AI może pomóc klasyfikować niejednoznaczne symbole lub proponować mapowania metryk do przeglądu przez kuratora, ale nie powinno omijać drabiny dowodowej: walk → szablon → rekomendacja.
• Dopracowanie operacyjne – limity walk dla poszczególnych typów tabel (interfejsy vs routing vs ARP), wsparcie dla pułapek/powiadomień SNMP (SNMP trap) oraz wyraźniejsza ścieżka „promuj ten wybór ze skanu do katalogu” w interfejsie.

12. Najczęściej zadawane pytania (FAQ)

Czym różni się SNMP discovery od SNMP auto-discovery z kuracją?

Klasyczne SNMP discovery ogranicza się do wykrycia, jakie OID-y istnieją na urządzeniu. Auto-discovery z kuracją idzie o krok dalej: ocenia, które z wykrytych OID-ów mają realną wartość monitoringową, eliminuje duplikaty i szum, a dopiero potem generuje szablon.

Czym jest walk-based LLD w Zabbix 7?

To wzorzec, w którym pojedynczy master walk SNMP zasila – poprzez łańcuch preprocessingu – zależne reguły discovery, zamiast tworzyć osobny element SNMP dla każdej kolumny tabeli. Rozwiązanie zwiększa złożoność podczas budowy szablonu, ale poprawia wydajność i spójność w czasie działania.

Dlaczego szablon z setkami elementów jest problemem?

Ponieważ zwiększa ryzyko timeoutów reguł discovery, generuje niespójne makra LLD i tworzy szablon, którego w praktyce nikt nie jest w stanie utrzymać. Liczba elementów nie jest miarą jakości – miarą jest liczba elementów możliwych do utrzymania.

Jaką rolę odgrywa sztuczna inteligencja w tym procesie?

Zgodnie z planami rozwoju narzędzia, AI ma działać jako akcelerator rankingu i przeglądu – pomagać klasyfikować niejednoznaczne symbole i proponować mapowania metryk do zatwierdzenia przez człowieka. Nie ma zastępować inżynierskiego osądu ani autonomicznie tworzyć szablonów.

Czy narzędzie pobiera dane z Zabbixa w czasie skanowania?

Nie. Cała wiedza domenowa – w tym metadane z szablonów Zabbix – jest wersjonowana w repozytorium git i dostarczana razem z narzędziem. W czasie skanowania nie następuje żadne pobieranie na żywo z zewnętrznych repozytoriów.

13. Podsumowanie

SNMP auto-discovery brzmi jak problem wyszukiwania. W praktyce jest to problem kuracji, owinięty w problem klasyfikacji, owinięty w problem ergonomii szablonu.

Twórcy zaczęli od próby znalezienia interesujących OID-ów. Projekt zaczął przynosić realną wartość dopiero wtedy, gdy zespół uznał, że „interesujące” nie oznacza „nadające się do monitorowania”, i zbudował system respektujący jednocześnie kompletność walk oraz dyscyplinę szablonu.

Jeśli patrzysz na świeży wynik snmpwalk i brakujący szablon Zabbix, nie oznacza to porażki w obsłudze SNMP – to dokładnie ten moment, w którym najbardziej liczy się wiedza domenowa.

SNMP auto-discovery to nie problem wykrywania. To problem kuracji, zbudowany na klasyfikacji i wiedzy domenowej.

Artykuł opracowany na podstawie oryginalnego wpisu Patrika Uytterhoevena na blogu Zabbix, pt. „The Evolution of an SNMP Auto-Discovery Tool” (blog.zabbix.com). Jeśli potrzebujesz wsparcia przy migracji do Zabbix 7 lub wdrażaniu najlepszych praktyk monitoringu SNMP, warto skontaktować się z certyfikowanym partnerem Zabbix Premium Partner.