W czwartej części kursu przechodzimy na poziom całościowego zarządzania infrastrukturą teleinformatyczną. Poznaliśmy już protokół SNMP, budowę baz MIB oraz operacje konsolowe. W rzeczywistej sieci korporacyjnej liczącej setki przełączników i dziesiątki tysięcy portów ręczne odpytywanie urządzeń jest jednak niemożliwe.

W tym miejscu pojawia się system klasy NMS. Działa on jako nieustannie czuwający zarządca, który automatycznie odpytuje urządzenia, wykrywa ich połączenia topologiczne, zbiera statystyki wydajnościowe i alarmuje inżynierów w przypadku awarii.

Podczas tego modułu szczegółowo przeanalizujemy LibreNMS – jeden z najpopularniejszych otwartoźródłowych systemów NMS na świecie, oraz The Dude – unikalne, zorientowane na mapę narzędzie firmy MikroTik.

Wybór odpowiedniego systemu NMS to jedna z najważniejszych decyzji architektonicznych w dziale IT. Zły wybór prowadzi do frustracji administratorów, zalewania skrzynek pocztowych fałszywymi alertami (tzw. alert fatigue) lub braku widoczności kluczowych awarii.

W toku wykładu zestawimy ze sobą podejście 'bezobsługowe' (out-of-the-box), reprezentowane przez LibreNMS, z podejściem silnie wizualnym (The Dude) oraz podejściem opartym na agentach i szablonach (Zabbix).

Każdy student pozna nie tylko zalety opisywanych narzędzi, lecz także ich realne ograniczenia wydajnościowe, zapotrzebowanie na zasoby dyskowe (IOPS) oraz metody integracji z systemami ticketowymi i bazami inwentaryzacyjnymi.

Pojęcie systemu NMS często bywa mylone ze zwykłym serwerem wykresów (np. klasycznym MRTG) lub narzędziem do testowania dostępności przez ping. Prawdziwy system NMS klasy korporacyjnej musi realizować wszystkie pięć funkcji modelu FCAPS.

W warstwie awarii (Fault) NMS nie tylko wykrywa brak łączności, lecz także analizuje zależności. Jeśli awarii ulega router dystrybucyjny, NMS powinien wygenerować jeden alarm główny, a nie pięćdziesiąt fałszywych alarmów o braku łączności ze switchami dostępowymi znajdującymi się za nim (mechanizm Root Cause Analysis).

W warstwie rozliczeń (Accounting) nowoczesne systemy NMS dostarczają mechanizmów naliczania opłat tranzytowych, takich jak metoda 95. percentyla (95th percentile billing), odrzucająca 5% najwyższych próbek ruchu w miesiącu.

Rozłam społeczności Observium w 2013 roku był jednym z najbardziej znanych wydarzeń w świecie sieciowego oprogramowania Open Source. Autor pierwotnego projektu zdecydował o usunięciu części funkcji z wersji darmowej i wstrzymaniu publicznych aktualizacji. W odpowiedzi powstał LibreNMS, który postawił na pełną transparentność i rządy społeczności.

W ciągu dekady LibreNMS przekształcił się w potężną platformę korporacyjną. Kod źródłowy został zrefaktoryzowany z użyciem nowoczesnych wzorców projektowych i frameworka Laravel, wprowadzono pełne API REST, obsługę webhooków oraz zaawansowany silnik rozproszonego pollingu.

Dziś LibreNMS jest uznawany za de facto standard monitorowania urządzeń sieciowych w tysiącach instytucji akademickich, centrów danych, operatorów ISP oraz korporacji na całym świecie.

Siła LibreNMS tkwi w jego uniwersalności. Wiele systemów monitoringu skupia się wyłącznie na serwerach (jak Nagios) lub wymaga żmudnego pisania skryptów i szablonów dla każdego nowego modelu przełącznika (jak Zabbix). LibreNMS posiada gotowe bazy definicji, dzięki czemu dodanie nowego przełącznika Cisco Catalyst czy MikroTika CCR sprowadza się do wpisania adresu IP.

Wbudowany silnik wykrywania sąsiedztwa potrafi w pełni autonomicznie zrekonstruować całą topologię sieci szkieletowej. Jeśli wszystkie urządzenia mają włączony protokół LLDP (IEEE 802.1AB), LibreNMS połączy je na mapie i powiąże odpowiednie porty interfejsów transmisyjnych.

Dla operatorów ISP nieocenioną funkcją jest wbudowany moduł bilingowy. Pozwala on na definiowanie limitów transferu danych (np. 10 TB/miesiąc) lub progów przepustowości dla klientów kolokacyjnych, automatycznie generując raporty rozliczeniowe w formacie PDF.

Zrozumienie architektury LibreNMS jest kluczowe dla poprawnego administrowania systemem. Tradycyjne wdrożenie opierało się na zadaniach harmonogramu `cron`, które co 5 minut uruchamiały polecenie `poller.php`. Przy setkach urządzeń prowadziło to do nakładania się procesów (poller lag).

W nowoczesnym podejściu wprowadzono usługę `librenms-dispatcher` napisaną w Pythonie. Działa ona jako ciągły demon korzystający z kolejki Redis. Zadania odpytywania są natychmiast rozdzielane pomiędzy dostępne procesy robocze, co zapewnia idealną równomierność obciążenia serwera.

Równie istotny jest podział danych. Wszelkie informacje o nazwach, adresach IP, użytkownikach czy historii alarmów trafiają do bazy MariaDB. Z kolei miliony próbek transferu bitów i błędów portów zapisywane są bezpośrednio do plików bazy RRDtool (.rrd), co uniemożliwia rozrastanie się bazy relacyjnej do niezarządzalnych rozmiarów.

Najczęstszym błędem podczas wdrażania systemów NMS jest alokacja wirtualnego dysku na współdzielonej macierzy talerzowej HDD. Choć objętość danych może wydawać się niewielka (np. 100 GB), to specyfika RRDtool generuje ciągłe losowe operacje zapisu do tysięcy małych plików.

W sieci z 200 przełącznikami i 10 000 monitorowanych portów, każdy 5-minutowy cykl odpytywania generuje dziesiątki tysięcy operacji `rrd_update`. Tradycyjny dysk HDD o wydajności 150 IOPS ulega natychmiastowemu zablokowaniu (iowait 100%), doprowadzając do lawinowego opóźnienia całego monitoringu.

Dlatego fundamentem sprzętowym każdego profesjonalnego NMS są nowoczesne nośniki SSD oparte na protokole NVMe, które bez trudu wytrzymują obciążenie rzędu setek tysięcy operacji IOPS przy minimalnych opóźnieniach zapisu.

Proces instalacji LibreNMS jest szczegółowo udokumentowany w oficjalnym podręczniku producenta. Standardowym katalogiem instalacyjnym w systemach Linux jest `/opt/librenms`. Wszelkie operacje serwisowe, aktualizacje kodu oraz migracje bazy danych powinny być wykonywane wyłącznie z poziomu dedykowanego użytkownika systemowego `librenms`, a nigdy z konta `root`.

Ważnym elementem jest konfiguracja uprawnień ACL (Access Control Lists). Ponieważ zarówno serwer WWW (użytkownik `www-data`), jak i silnik pollerowy (użytkownik `librenms`) muszą mieć prawo zapisu do katalogów `rrd/` oraz `storage/`, stosuje się mechanizm `setfacl` gwarantujący poprawne dziedziczenie uprawnień dla nowo tworzonych plików.

W kolejnym module (Prezentacja 5: Konteneryzacja) poznamy alternatywną, w pełni zautomatyzowaną metodę uruchamiania LibreNMS za pomocą narzędzia Docker Compose, która eliminuje konieczność ręcznej konfiguracji środowiska linuksowego.

Ergonomia interfejsu NMS bezpośrednio wpływa na czas reakcji zespołu wsparcia. W przeciwieństwie do archaicznych paneli MRTG czy Cacti, LibreNMS oferuje w pełni responsywny interfejs oparty na technologii Bootstrap, dostosowujący się do rozdzielczości ekranu od smartfona po ścianę wideo.

Wyszukiwarka globalna (klawisz skrótu `/`) pozwala na błyskawiczne odnalezienie dowolnego portu, adresu IP, adresu MAC czy nazwy urządzenia bez konieczności przeklikiwania się przez wielopoziomowe menu.

Widok `Routing` jest szczególnie ceniony przez inżynierów sieci rozległych: automatycznie grupuje wszystkie sesje BGP w organizacji, prezentując stan sąsiadów, czas trwania sesji oraz liczbę wymienianych prefiksów IPv4 i IPv6.

Proces instalacji LibreNMS został zaprojektowany z myślą o maksymalnej przejrzystości. Dedykowany instalator webowy (`/install`) przeprowadza administratora przez testy połączenia z bazą danych, konfigurację parametrów `.env` oraz utworzenie pierwszego konta administracyjnego.

Kluczowym elementem stabilności jest odpowiednie skonfigurowanie strefy czasowej w plikach `php.ini` zarówno dla interfejsu FPM, jak i CLI (`date.timezone = Europe/Warsaw`). Rozbieżność stref czasowych skutkuje błędnym oznaczaniem próbek w bazie RRD.

Więcej informacji oraz oficjalne przewodniki krok po kroku dla dystrybucji Ubuntu, Debian i RHEL znajdują się na stronie: docs.librenms.org/Installation/Install-LibreNMS/.

Skrypt `validate.php` to unikalna funkcja LibreNMS, wyróżniająca go na tle innych projektów Open Source. Zamiast zmuszać administratora do przeglądania wielomegabajtowych plików logów, skrypt wykonuje dziesiątki testów jednostkowych w czasie rzeczywistym.

W przypadku wykrycia nieaktualnego schematu bazy danych (np. po pobraniu nowej wersji przez `git pull`), skrypt wskazuje konieczność wykonania migracji frameworka Laravel za pomocą polecenia `lnms migrate`.

W środowiskach produkcyjnych dobrą praktyką jest włączenie weryfikacji skryptem validate do automatycznych testów CI/CD lub monitorowanie jego wyniku przez zewnętrzny czujnik.

W dużych organizacjach ręczne dodawanie urządzeń przez GUI odchodzi do przeszłości. Standardem jest wykorzystanie narzędzia wiersza poleceń `lnms` lub bezpośrednia integracja z systemem zarządzania adresacją IPAM (np. NetBox).

Narzędzie `lnms` to nowoczesny interfejs CLI wprowadzony w ostatnich wersjach LibreNMS, zbudowany w oparciu o komponenty Laravel Artisan. Pozwala on na zarządzanie urządzeniami, użytkownikami, regułami alertów oraz wykonywanie migracji bazy danych.

Warto podkreślić, że LibreNMS wspiera dodawanie urządzeń wyłącznie za pośrednictwem protokołu ICMP ping (opcja `Ping only`), co jest przydatne dla prostych urządzeń bez agenta SNMP (kamery IP, domofony, stacje robocze użytkowników).

Mechanizm auto-discovery w LibreNMS opiera się na cyklicznym skanowaniu tabel MIB powiązanych z protokołami wykrywania sąsiedztwa. Standardowy protokół LLDP (IEEE 802.1AB / LLDP-MIB) jest zaimplementowany w sprzęcie niemal wszystkich producentów, co umożliwia bezproblemową współpracę w środowisku mieszanym.

W momencie wykrycia nowego sąsiada w tablicy `lldpRemTable`, LibreNMS odczytuje jego adres zarządzający (Management Address), po czym sprawdza, czy adres ten mieści się w dopuszczalnych pulach zmiennej konfiguracyjnej `$config['nets']`.

Jeśli test zakończy się sukcesem, system podejmuje próbę odpytania nowego adresu za pomocą listy zaufanych społeczności SNMP. Po pomyślnej autoryzacji nowy węzeł jest automatycznie dołączany do bazy monitoringu, a między oboma przełącznikami tworzone jest łącze na mapie topologii.

W środowiskach laboratoryjnych i produkcyjnych zaleca się stosowanie CLI do dodawania urządzeń, gdyż pozwala to na łatwą automatyzację w skryptach powłoki Bash lub playbookach Ansible.

W momencie wywołania `lnms device:add` system najpierw wykonuje szybki test dostępności ICMP (fping). Jeśli urządzenie odpowiada, następuje próba odczytu gałęzi `sysObjectID.0` przez SNMP. Na tej podstawie LibreNMS rozpoznaje producenta i model (np. MikroTik RouterOS) i ładuje odpowiedni moduł definicji YAML.

Jeśli urządzenie nie odpowiada na ping (np. zapora sieciowa blokuje ICMP Echo), należy dodać parametr `--ping-fallback` lub zezwolić na pakiety ICMP z adresu IP serwera NMS.

Widok urządzenia w LibreNMS został zaprojektowany z myślą o maksymalnej szybkości rozwiązywania problemów (Troubleshooting). Zamiast przeszukiwać logi tekstowe, inżynier sieciowy w ciągu kilku sekund może zweryfikować, czy nagły wzrost opóźnień wynika z przeciążenia procesora routera, saturacji łącza transmisyjnego, czy restartu sesji BGP.

Szczególnie wartościowa jest karta parametrów optycznych DDM. Dla każdej wkładki SFP/SFP+ LibreNMS odczytuje moc lasera oraz temperaturę modułu, nanosząc na wykres poziomy alarmowe (Warning High/Low, Critical High/Low) pobrane bezpośrednio z pamięci EEPROM wkładki.

Współpraca z modułem Oxidized pozwala ponadto na natychmiastowe sprawdzenie, czy w ciągu ostatnich godzin ktoś nie zmodyfikował konfiguracji urządzenia, co stanowi jedną z najczęstszych przyczyn awarii w sieciach operatorskich.

Wykresy w LibreNMS to potężne narzędzie analityczne. Dzięki integracji z biblioteką RRDtool użytkownik może dynamicznie zmieniać przedziały czasowe: od ostatnich 6 godzin, przez 24 godziny, tydzień, miesiąc, aż po widok 2-letni.

Warto pamiętać o zjawisku spłaszczania szczytów (Peak Flattening) w bazach RRD. Na wykresie dobowym każda próbka reprezentuje dokładnie 5 minut, co pozwala dostrzec krótkie impulsy obciążenia. Na wykresie rocznym pojedynczy punkt reprezentuje średnią z całego dnia, co sprawia, że krótkie skoki ruchu ulegają wygładzeniu.

W LibreNMS dostępna jest funkcja `Port Graph Types`, która pozwala przełączyć widok ze standardowych bitów na sekundę na: pakiety na sekundę (pps), pakiety unicast vs multicast/broadcast (kluczowe przy wykrywaniu pętli STP) lub pakiety błędne (errors/discards).

Zarządzanie incydentami w dużych sieciach wymaga precyzyjnego filtrowania zdarzeń. Zły system alertowania bombarduje inżynierów setkami e-maili na godzinę, co sprawia, że rzeczywista krytyczna awaria zostaje przeoczona w szumie powiadomień.

W LibreNMS silnik alertów (`alerts.php`) uruchamiany jest co minutę. Porównuje on aktualne stany w bazie danych ze zdefiniowanymi regułami. Ważnym elementem jest obsługa zależności urządzeń (Device Dependencies) – jeśli awarii ulega przełącznik dystrybucyjny, system automatycznie wycisza alerty ze wszystkich przełączników dostępowych podłączonych za nim.

Dodatkowo funkcja potwierdzania alarmów (Acknowledge) pozwala inżynierowi dyżurnemu na oznaczenie incydentu jako 'w trakcie naprawy', co wstrzymuje eskalację i zapobiega budzeniu kolejnych osób z zespołu wsparcia.

Wdrożenie prezentowanej reguły stanowi kamień milowy w optymalizacji centrum monitoringu sieci. W typowym przełączniku dostępowym 48-portowym użytkownicy stale włączają i wyłączają swoje komputery. Gdyby każda zmiana stanu generowała alert, system NMS stałby się bezużyteczny.

Dzięki filtrowaniu po opisie `ifAlias` monitorowane są wyłącznie porty oznaczone jako newralgiczne łącza uplink lub serwery produkcyjne. Zmiany stanów na portach biurowych są nadal rejestrowane w historii zdarzeń, lecz nie wyzwalają alarmów krytycznych.

Podczas tworzenia reguł warto korzystać z wbudowanego przycisku testowania (Test Rule), który natychmiast wykonuje zapytanie SQL na aktualnej bazie i wyświetla listę portów, które w danej chwili spełniają zdefiniowane kryteria.

Testowanie reguł alertowych przy użyciu narzędzi generujących obciążenie syntetyczne (takich jak `stress-ng` dla CPU/RAM czy `iperf3` dla przepustowości interfejsów) stanowi podstawową dobrą praktykę inżynierską przed oddaniem systemu monitoringu do eksploatacji produkcyjnej.

W trakcie testu student obserwuje, jak w pierwszym 5-minutowym cyklu LibreNMS wykrywa przekroczenie progu, lecz status reguły pozostaje w stanie 'Soft Alert'. Dopiero potwierdzenie wysokiego obciążenia w drugim cyklu (po 10 minutach) zmienia stan na 'Hard Alert' i wyzwala właściwe powiadomienie.

Po zakończeniu działania procesu `stress-ng` kolejny cykl odpytania pollerem rejestruje spadek obciążenia CPU do kilku procent, co generuje powiadomienie 'Alert cleared' i przywraca zielony kolor urządzenia na mapach sieci.

Network Weathermap to jedno z najbardziej spektakularnych narzędzi wizualizacyjnych w świecie NMS. Pozwala na nałożenie schematu sieci na mapę geograficzną kraju lub rzut architektoniczny kampusu uniwersyteckiego.

Zasada działania opiera się na pliku konfiguracyjnym, w którym administrator definiuje węzły (Nodes) oraz łączące je linie (Links). Każde łącze powiązane jest ze ścieżką do odpowiedniego pliku bazy `.rrd`. Co 5 minut generator odczytuje najnowsze wartości ruchu i przelicza procent utylizacji pasma.

Dzięki temu dyżurny inżynier nie musi analizować setek wykresów liczbowych. Wystarczy rzut oka na telebim: czerwona linia natychmiast wskazuje, które łącze magistralne uległo zapchaniu i wymaga przełączenia ruchu na trasę zapasową.

Integracja pułapek SNMP w systemie LibreNMS stanowi doskonałe uzupełnienie standardowego pollingu. O ile odpytywanie okresowe świetnie sprawdza się w budowaniu wykresów trendów obciążenia, o tyle nie gwarantuje szybkiego czasu reakcji w przypadku nagłej awarii zasilania czy zerwania kabla.

Gdy do serwera NMS dotrze pułapka `linkDown`, demon `snmptrapd` dekoduje nagłówki i uruchamia skrypt parsujący. LibreNMS natychmiast odnajduje powiązany interfejs i aktualizuje jego stan operacyjny w bazie danych, nie czekając na kolejny 5-minutowy cykl odpytywania.

Dzięki temu silnik alarmów zostaje wyzwolony w czasie poniżej jednej sekundy od fizycznego wystąpienia awarii na przełączniku, co drastycznie skraca czas reakcji dyżurnych administratorów.

Połączenie protokołu SNMP z protokołem Syslog stanowi idealną synergię monitoringu. SNMP dostarcza uporządkowanych, ustrukturyzowanych liczb (metryki pasma, temperatury, liczniki pakietów), podczas gdy Syslog przekazuje asynchroniczne komunikaty tekstowe generowane przez oprogramowanie urządzenia w chwili wystąpienia incydentu.

W przypadku awarii zasilania w serwerowni, zasilacz awaryjny UPS natychmiast wysyła komunikat Syslog `Power failure; running on battery`. Dzięki integracji z LibreNMS informacja ta nie tylko pojawia się w rejestrze, lecz natychmiast wyzwala powiadomienie na kanale dyżurnym inżynierów.

Szczegółowa konfiguracja integracji z demonem rsyslog opisana jest w oficjalnym przewodniku: docs.librenms.org/Extensions/Syslog/.

Nowoczesne podejście do inżynierii sieciowej (NetDevOps) zakłada, że żaden inżynier nie powinien ręcznie dodawać urządzeń do monitoringu ani ręcznie modyfikować progów alarmowych. Wszystkie te czynności powinny dziać się automatycznie w ramach pipeline'ów wdrożeniowych.

Dzięki API REST LibreNMS doskonale integruje się z ekosystemem automatyzacji. Skrypt wdrożeniowy w Ansible po skonfigurowaniu nowego przełącznika może wysłać pojedyncze żądanie HTTP POST do API LibreNMS, natychmiast wprowadzając urządzenie pod nadzór monitoringu.

Równie popularnym scenariuszem jest integracja z systemami Helpdesk. W momencie wystąpienia awarii skrypt pobiera z API listę portów w stanie DOWN, generuje sformatowany bilet w Jira lub ServiceNow i przypisuje zadanie dyżurnemu inżynierowi.

Bezpieczeństwo systemu NMS jest krytycznym elementem cyberbezpieczeństwa organizacji. Ponieważ platforma gromadzi informacje o wersjach systemów operacyjnych, topologii fizycznej i adresacji IP, jej przejęcie przez napastnika umożliwia dokładny rekonesans całej infrastruktury.

Wdrożenie uwierzytelniania dwuskładnikowego (2FA) jest standardem branżowym wymaganym m.in. przez dyrektywę NIS 2. LibreNMS natywnie wspiera algorytmy TOTP/HOTP (aplikacje Google Authenticator, FreeOTP), natomiast obsługa sprzętowych kluczy FIDO2/WebAuthn i YubiKey realizowana jest poprzez integrację z zewnętrznymi dostawcami tożsamości SSO (Keycloak, Authelia, SAML/OAuth).

Integracja z usługą Active Directory eliminuje problem 'martwych kont' po odejściu pracownika z firmy. W momencie zablokowania konta w domenie Windows dostęp do LibreNMS zostaje automatycznie odcięty w czasie rzeczywistym.

Projektując procedurę backupu LibreNMS, należy pamiętać o specyfice dwuskładnikowej bazy danych. Kopia samej bazy MariaDB pozwala na natychmiastowe odtworzenie listy urządzeń, użytkowników i reguł alertów, lecz bez katalogu `rrd/` utracone zostaną wszystkie wykresy historyczne.

Z kolei katalog `rrd/` może ważyć od kilkunastu do kilkuset gigabajtów. Kopiowanie go tradycyjnym poleceniem `tar` co noc jest nieefektywne. Zaleca się stosowanie narzędzi z obsługą deduplikacji blokowej (np. Restic) lub migawek na poziomie systemu plików (ZFS / Btrfs snapshots).

Skrypt `daily.sh` uruchamiany z crona o północy dba o to, by system posiadał zawsze najnowsze definicje urządzeń. Jeśli w organizacji obowiązuje rygorystyczna polityka zamrażania wersji, automatyczne aktualizacje można wyłączyć dyrektywą `$config['update'] = 0;`.

Architektura Distributed Poller to technologiczny szczyt możliwości skalowania LibreNMS. Pozwala ona na monitorowanie największych sieci korporacyjnych i operatorskich liczących setki tysięcy interfejsów transmisyjnych.

Kluczem do sukcesu jest usługa `librenms-dispatcher`. Działa ona w oparciu o architekturę Master-Worker z kolejką Redis. Zadania nie są przypisane na sztywno do wątków – każdy wolny proces roboczy na dowolnym serwerze w klastrze pobiera kolejne urządzenie do odpytania z kolejki (Job Queue).

Dzięki temu obciążenie rozkłada się idealnie równomiernie. Jeśli w klastrze zainstalujemy 4 serwery po 16 rdzeni każdy, otrzymujemy 64 równoległe procesy odpytujące, co skraca czas pełnego cyklu pomiarowego całej korporacji z minut do kilkunastu sekund.

Wypadki spowodowane błędami ludzkimi podczas ręcznej rekonfiguracji urządzeń odpowiadają za ponad 70% przestojów w sieciach korporacyjnych. Bez automatycznego systemu wersjonowania konfiguracji odnalezienie błędnej komendy wprowadzonej przez dyżurnego administratora może zająć wiele godzin.

Integracja LibreNMS z Oxidized całkowicie rozwiązuje ten problem. Zamiast ręcznego porównywania plików, inżynier otwiera kartę `Config` w LibreNMS i natychmiast widzi podświetlone na czerwono skasowane linie list kontroli dostępu (ACL) oraz na zielono błędnie dodane trasy statyczne.

Co więcej, Oxidized automatycznie filtruje wrażliwe dane: przed zapisaniem pliku do repozytorium Git usuwa lub zaciemnia hasła dostępu, klucze BGP MD5 oraz certyfikaty, zapewniając pełne bezpieczeństwo danych.

W świecie sieci bezprzewodowych (WISP) The Dude cieszy się statusem legendy. W latach 2006–2012 niemal każdy lokalny dostawca Internetu w Polsce i na świecie korzystał z The Dude zainstalowanego na stacji roboczej z systemem Windows do nadzorowania stacji bazowych i linków radiowych.

Wraz z premierą systemu RouterOS v6.34 MikroTik podjął kluczową decyzję o przepisaniu serwera The Dude. Porzucono serwer Windows na rzecz natywnego pakietu działającego bezpośrednio na procesorach TILE w routerach CCR (Cloud Core Router) oraz maszynach wirtualnych CHR (Cloud Hosted Router).

Mimo upływu lat The Dude pozostaje unikalnym narzędziem na rynku. Żaden inny darmowy system NMS nie oferuje tak responsywnej, dynamicznie odświeżanej mapy topologicznej obsługiwanej bezpośrednio z poziomu aplikacji okienkowej.

Wielką zaletą The Dude jest natychmiastowa czytelność. Podczas gdy w systemach webowych administrator musi przełączać się między wieloma tabelami, w The Dude wystarczy rzut oka na mapę. Jeśli węzeł zmieni kolor z zielonego na czerwony, natychmiast wiadomo, który element sieci uległ awarii.

Co więcej, The Dude genialnie rozwiązuje problem wizualizacji łączy transmisyjnych. Każda linia na mapie reprezentuje fizyczny lub logiczny interfejs sieciowy. Na linii wyświetlana jest etykieta z bieżącym transferem, a przekroczenie progu (np. 80% pasma) powoduje zmianę koloru samej linii na żółty lub czerwony.

Dla administratorów zarządzających setkami urządzeń MikroTik unikalną zaletą jest funkcja `Upgrade`. The Dude potrafi w tle pobrać nowe pakiety RouterOS i w zaplanowanym oknie nocnym zaktualizować oprogramowanie na wszystkich routerach w sieci za pomocą jednego kliknięcia.

Najbardziej zalecaną platformą do uruchomienia serwera The Dude jest Cloud Hosted Router (CHR). Jest to specjalna wersja systemu RouterOS przeznaczona dla środowisk wirtualnych (KVM, VMware ESXi, Proxmox, Hyper-V).

Dzięki wdrożeniu na wirtualizatorze CHR serwer The Dude otrzymuje do dyspozycji gigabajty pamięci RAM, szybkie wirtualne dyski SSD oraz gigabitowe łącza sieciowe, co pozwala na stabilne monitorowanie setek urządzeń bez obciążania fizycznych routerów brzegowych.

W przypadku instalacji na fizycznym routerze CCR (Cloud Core Router) konieczne jest podłączenie szybkiego nośnika USB 3.0 lub dysku M.2 PCIe (w nowszych modelach CCR2004/CCR2116) i sformatowanie go w systemie plików ext4 przed aktywacją usługi poleceniem `/dude set enabled=yes`.

MikroTik Cloud Hosted Router (CHR) to specjalna edycja systemu RouterOS przeznaczona do pracy w środowiskach wirtualnych. Posiada 64-bitowe sterowniki VirtIO dla dysków i kart sieciowych, co czyni go idealną i wysoce stabilną platformą dla serwera The Dude.

W laboratorium studenci konfigurują maszynę wirtualną z dwoma dyskami: dysk systemowy o pojemności 1 GB oraz dedykowany dysk na bazy danych i logi o pojemności 10 GB. Dzięki temu baza danych SQLite posiada pełną izolację.

Po włączeniu serwera komendą `/dude set enabled=yes` router otwiera wewnętrzne gniazdo nasłuchowe. Klient okienkowy komunikuje się za pośrednictwem bezpiecznego binarnego protokołu MikroTik, pobierając geometrię mapy i statusy sond.

W dobie dominacji aplikacji internetowych podejście MikroTika z dedykowanym klientem okienkowym może wydawać się przestarzałe, jednak w praktyce operacyjnej ma ogromne zalety. Praca z mapą liczącą 500 węzłów w przeglądarce internetowej często powoduje spadki płynności i duże obciążenie pamięci RAM.

Natywny klient Win32 renderuje grafikę wektorową bezpośrednio z wykorzystaniem bibliotek graficznych systemu operacyjnego, zapewniając idealną płynność 60 klatek na sekundę nawet przy dynamicznym przybliżaniu i oddalaniu rozległych obszarów sieci.

W centrach operacyjnych sieci (NOC) stacje monitoringu bardzo często mają uruchomionego klienta The Dude na pełnym ekranie na dedykowanym monitorze, co zapewnia stały podgląd infrastruktury bez ryzyka przypadkowego zamknięcia karty w przeglądarce.

W przeciwieństwie do LibreNMS, gdzie mapa generowana jest automatycznie na podstawie algorytmu fizycznego (co przy 200 urządzeniach tworzy trudną do odczytania 'pajęczynę'), The Dude stawia na ręczne, precyzyjne rozplanowanie przestrzenne.

Inżynier może stworzyć strukturę wielopoziomową. Na mapie głównej widoczny jest ogólny zarys szkieletu kraju. Kliknięcie dwukrotne w ikonę węzła regionalnego przenosi operatora na mapę konkretnego data center, a stamtąd do widoku poszczególnych szaf serwerowych.

W etykietach węzłów można stosować zaawansowane wyrażenia warunkowe w języku skryptowym The Dude. Możliwe jest np. automatyczne ukrywanie informacji o temperaturze procesora, dopóki nie przekroczy ona progu 60°C, co ogranicza szum informacyjny na ekranie.

Mechanizm sond w The Dude wyróżnia się wyjątkową elastycznością. Do każdego urządzenia można przypisać dowolną liczbę sond (np. dla serwera WWW: sonda `ping`, sonda `tcp_80` oraz sonda `snmp_cpu_load`).

Stan urządzenia na mapie jest wypadkową stanów wszystkich przypisanych do niego sond. Jeśli wszystkie sondy działają poprawnie, węzeł ma kolor zielony. Jeśli choć jedna sonda ulegnie awarii, węzeł staje się pomarańczowy, a najechanie kursorem natychmiast wyświetla dymek z informacją: `http: connection refused`.

W przypadku awarii sondy krytycznej (np. całkowity brak odpowiedzi na ping) węzeł zmienia kolor na czerwony, a The Dude automatycznie wstrzymuje odpytywanie pozostałych sond na tym urządzeniu, oszczędzając zasoby procesora i sieci.

Połączenie systemu monitoringu z silnikiem skryptowym systemu RouterOS tworzy zalążek tzw. sieci autonomicznej (Self-Healing Network). W tradycyjnym modelu inżynier po odebraniu alertu musi zalogować się na przełącznik i ręcznie zrestartować port zasilający.

W The Dude proces ten można w pełni zautomatyzować. Jeśli kamera monitoringu lub stacja bazowa Wi-Fi przestaje odpowiadać na zapytania przez 3 kolejne cykle pomiarowe, The Dude wykonuje powiązaną notyfikację typu `Execute on Server`.

Skrypt wyłącza zasilanie PoE na danym interfejsie na 5 sekund, po czym załącza je ponownie. Jeśli po restarcie urządzenie wstanie i zacznie odpowiadać na sondę, incydent zostaje automatycznie zamknięty z wpisem w dzienniku zdarzeń, bez konieczności interwencji dyżurnego administratora w środku nocy.

W odróżnieniu od prostych sond badających jedynie stan portów TCP, sondy funkcyjne The Dude pozwalają na pisanie miniprogramów telemetrycznych. Język wyrażeń The Dude wspiera operatory arytmetyczne, logiczne oraz funkcje agregujące.

W laboratorium studenci badają OID `1.3.6.1.4.1.14988.1.1.3.11.0`. Urządzenia MikroTik raportują temperaturę procesora w dziesiątych częściach stopnia Celsjusza, aby uniknąć konieczności przesyłania liczb zmiennoprzecinkowych w SNMP. Dzielenie przez 10 w polu 'Value' i przypisanie jednostki '°C' zapewnia czytelną prezentację na wykresach.

Po przypisaniu nowo utworzonej sondy do urządzenia, na mapie The Dude pod etykietą routera pojawia się dynamiczny wskaźnik temperatury aktualizowany co zadany interwał odpytywania.

Dla administratorów sieci opartych na sprzęcie MikroTik The Dude oferuje poziom integracji nieosiągalny dla żadnego innego systemu monitoringu. Zamiast otwierać osobno Winboxa i szukać routera na liście adresów IP, inżynier klika dwukrotnie w ikonę na mapie i od razu znajduje się w menu konfiguracyjnym.

W przypadku wykrycia podatności bezpieczeństwa w starszych wersjach RouterOS funkcja `RouterOS Upgrade` pozwala na zaktualizowanie całej sieci kampusowej w kilkanaście minut. The Dude sam dobiera odpowiednią architekturę pakietu (ARM, MIPS, TILE, x86) dla każdego urządzenia.

Funkcja tunelowania (Dude Relay) jest z kolei nieoceniona w rozległych sieciach operatorskich, eliminując konieczność nadawania publicznych adresów IP interfejsom zarządzającym przełączników wewnątrz sieci.

W przeciwieństwie do LibreNMS, który wykorzystuje tandem MariaDB + RRDtool, The Dude postawił na maksymalną prostotę architektoniczną i format SQLite. Zaletą takiego rozwiązania jest brak konieczności instalowania i konfigurowania zewnętrznego serwera bazodanowego.

Wykresy w The Dude generowane są dynamicznie w oknie aplikacji klienckiej. Użytkownik może zaznaczyć myszą dowolny fragment wykresu, aby go powiększyć (Zoom-in), co pozwala na precyzyjną analizę anomalii trwających kilkadziesiąt sekund.

Należy jednak pamiętać o regularnej defragmentacji bazy. Po usunięciu dużej liczby urządzeń plik `dude.db` nie zmniejsza się automatycznie. Wywołanie komendy `/dude vacuum-db` przebudowuje strukturę tabel, redukując rozmiar pliku i przyspieszając operacje zapisu.

W analizie inżynierskiej kluczowy jest obiektywizm. The Dude był rewolucyjnym narzędziem 15 lat temu, jednak rozwój branży teleinformatycznej poszedł w stronę systemów webowych, otwartych interfejsów API REST oraz automatyzacji w językach Python i Ansible.

Brak natywnego klienta dla systemów macOS oraz brak nowoczesnego interfejsu HTML5 stanowi barierę dla wielu organizacji, w których administratorzy pracują na laptopach Apple lub stacjach roboczych z Linuksem.

Dlatego w dojrzałych środowiskach telekomunikacyjnych The Dude bywa stosowany jako narzędzie pomocnicze dla techników radiowych w terenie, podczas gdy cała orkiestracja sieci, rozliczenia SLA, zbieranie logów i alertowanie powierzane jest systemom klasy LibreNMS lub Zabbix.

Bezpośrednie porównanie obu systemów jasno pokazuje, że powstały one z myślą o innych odbiorcach. The Dude został stworzony przez inżynierów radiowych dla operatorów bezprzewodowych. Jego celem była prosta, wizualna kontrola linków i łatwy dostęp do konfiguracji urządzeń MikroTik.

Z kolei LibreNMS został zaprojektowany z myślą o nowoczesnych centrach danych i heterogenicznych sieciach kampusowych, w których pracują przełączniki Cisco, macierze NetApp, serwery z Linuksem oraz zasilacze APC.

Dla studenta kluczowa jest umiejętność doboru właściwego narzędzia do skali projektu. W małej firmie wdrożenie klastra LibreNMS z Redisem może być przerostem formy nad treścią, podczas gdy próba monitorowania kampusu uniwersyteckiego za pomocą The Dude zakończy się zablokowaniem bazy SQLite.

Debata 'LibreNMS czy Zabbix' to jeden z najczęstszych sporów na forach administratorów sieci. Prawda jest taka, że oba systemy znakomicie się uzupełniają, ponieważ wyrosły z innych potrzeb.

Zabbix jest bezkonkurencyjny w monitorowaniu systemów operacyjnych i aplikacji biznesowych. Jego agent potrafi wykonywać lokalne skrypty, śledzić zużycie pamięci przez konkretne procesy czy analizować logi w czasie rzeczywistym. Jednak skonfigurowanie w Zabbixie monitoringu 40 przełączników Cisco z automatycznym wykrywaniem VLAN i topologii STP bywa drogą przez mękę.

LibreNMS robi to wszystko od ręki w ułamku sekundy. Dlatego w nowoczesnych firmach technologicznych bardzo częstym modelem jest podział: zespół Network Operations korzysta z LibreNMS, a zespół DevOps/Sysadmin monitoruje klastry serwerowe za pomocą Zabbixa.

W historii informatyki Nagios odegrał kolosalną rolę, będąc przez ponad dekadę niekwestionowanym królem monitoringu. Jednak w świecie sieci teleinformatycznych jego architektura oparta na nieustannym tworzeniu nowych procesów systemowych (`fork()` / `exec()`) stała się wąskim gardłem.

Gdy przełącznik sieciowy posiada 48 portów, a administrator chce monitorować stan, transfer wejściowy, transfer wyjściowy, błędy i pakiety porzucone, Nagios musiałby wykonać 240 osobnych wywołań skryptów co 5 minut dla każdego pojedynczego urządzenia. Przy 100 przełącznikach daje to 24 000 procesów, co dławiło nawet najmocniejsze serwery.

LibreNMS rozwiązuje ten problem fundamentalnie inaczej: pojedynczy proces pollerowy łączy się z przełącznikiem i za pomocą operacji SNMP GETBULK pobiera całą tablicę interfejsów w kilku pakietach UDP, redukując narzut procesora o ponad 95%.

PRTG Network Monitor to rozwiązanie wybierane głównie przez instytucje, w których infrastruktura serwerowa opiera się na systemach Windows Server, a zespół IT nie posiada zaawansowanych kompetencji administracyjnych w systemie Linux. Paessler oferuje gotowe sensory dla wirtualizatorów, baz danych i urządzeń sieciowych.

Checkmk wyróżnia się unikalną architekturą: zamiast tradycyjnego modelu 'jedno zapytanie per usługa', agent Checkmk pobiera całościowy zrzut parametrów hosta w pojedynczym połączeniu TCP, a rdzeń w C++ błyskawicznie parsuje metryki w pamięci operacyjnej.

Włączenie modułu ntopng w architekturę NOC zamyka lukę w widoczności ruchu sieciowego. Urządzenia sieciowe (Cisco, MikroTik RouterOS) konfiguruje się tak, aby eksportowały próbkowane pakiety do demona ntopng, który klasyfikuje je za pomocą biblioteki Deep Packet Inspection (nDPI).

Inżynier projektujący system monitoringu musi przede wszystkim określić dominujący profil infrastruktury. Próba monitorowania rozbudowanej farmy mikrousług za pomocą The Dude zakończy się porażką, podobnie jak wdrożenie ciężkiego klastra Zabbixa z ręczną konfiguracją szablonów w sieci liczącej setki różnorodnych przełączników dostępowych.

W przedsiębiorstwach o profilu mieszanym bardzo często stosuje się architekturę hybrydową: LibreNMS odpowiada za całościowy nadzór nad warstwą fizyczną i łączami L2/L3 (switche, routery, łącza światłowodowe), podczas gdy Zabbix lub Prometheus nadzorują systemy operacyjne serwerów i usługi aplikacyjne.

Kluczowym aspektem jest również dynamika zmian topologii. W sieciach, gdzie urządzenia i porty pojawiają się oraz znikają codziennie, silnik autoodkrywania LibreNMS oparty na protokołach LLDP i CDP oszczędza setki roboczogodzin w skali roku.

W przeciwieństwie do LibreNMS, który jest monolityczną aplikacją zarządzającą odpytywaniem, bazą danych i interfejsem użytkownika, ekosystem Cloud Native opiera się na komponentach wyspecjalizowanych. Prometheus odpowiada wyłącznie za akwizycję, przechowywanie w TSDB i ocenę reguł alarmowych (Alertmanager), a Grafana za wizualizację.

Wielowymiarowy model etykiet (labels) pozwala na zadawanie pytań analitycznych, które w tradycyjnych bazach wymagałyby złożonych zapytań SQL ze złączeniami JOIN. Na przykład polecenie `sum by (datacenter) (rate(ifHCInOctets[5m]))` sumuje natychmiast ruch wejściowy we wszystkich routerach z podziałem na centra danych.

Dzięki otwartym interfejsom API, Grafana potrafi w jednym widoku połączyć dane telemetryczne SNMP pobrane z Prometheusa, statusy zgłoszeń awarii z Jira, zdarzenia z Elasticsearch oraz wykresy z bazy LibreNMS.

W architekturze Prometheusa urządzenie sieciowe nie instaluje żadnego agenta. Eksporter działa jako demon na osobnym serwerze Linux lub w kontenerze Docker. Gdy nadejdzie czas skrobania, eksporter wysyła szybkie pakiety SNMP GETBULK na port UDP 161 urządzenia, odbiera odpowiedzi, konwertuje typy ASN.1 na liczby zmiennoprzecinkowe i zwraca je Prometheusowi.

Mechanizm `relabel_configs` w konfiguracji Prometheusa jest kluczowy: pozwala inżynierowi zdefiniować listę monitorowanych switchy w jednym miejscu, a Prometheus automatycznie przekierowuje zapytania do demona `snmp_exporter:9116` z parametrem docelowym.

Więcej szczegółów oraz gotowe pliki generatora można znaleźć w oficjalnym repozytorium projektu: github.com/prometheus/snmp_exporter.

Projektując dashboard dla zespołu NOC należy unikać pokusy umieszczania wszystkich dostępnych metryk na jednym ekranie. Przeładowanie informacyjne (cognitive overload) drastycznie wydłuża czas reakcji na rzeczywisty incydent.

Wykresy typu Time Series w Grafanie powinny posiadać jasno zdefiniowane linie progowe (Thresholds). Zamiast zmuszać operatora do kalkulowania w pamięci, linia przerywana na poziomie 90% przepustowości łącza jednoznacznie sygnalizuje ryzyko degradacji jakości usług (QoS).

Więcej technik zaawansowanego projektowania paneli dostępnych jest w dokumentacji: grafana.com/docs/grafana/latest/dashboards/.

Zgodnie z metodyką ITIL v4, proces zarządzania incydentami (Incident Management) ma na celu jak najszybsze przywrócenie normalnego działania usługi teleinformatycznej. Ręczne przepisywanie alertów z monitoringu do systemu ticketowego jest niedopuszczalną stratą cennego czasu (MTTR).

LibreNMS posiada bogatą bibliotekę wbudowanych transportów alertowych (m.in. Slack, Microsoft Teams, Discord, Telegram, PagerDuty, Opsgenie czy E-mail). Integracja z zaawansowanymi platformami ITSM takimi jak ServiceNow, Jira Service Management czy GLPI realizowana jest za pośrednictwem elastycznego mechanizmu webhooków (Generic Webhook) i zapytań REST API przekazujących ustrukturyzowane obiekty JSON.

Więcej o standardach zarządzania usługami IT można przeczytać na oficjalnej stronie biblioteki ITIL: axelos.com/certifications/itil-service-management.

W klasycznym modelu administrator po zainstalowaniu nowego switcha logował się do NMS i ręcznie wpisywał adres IP oraz community SNMP. W dużych sieciach prowadziło to do bałaganu: urządzenia wycofane ze szaf nadal figurowały w monitoringu jako 'DOWN', a nowe przełączniki nie były monitorowane przez tygodnie.

Integracja NetBox z LibreNMS za pomocą skryptów synchronizacyjnych (np. `netbox2librenms` napisanego w języku Python) całkowicie eliminuje ten problem. Skrypt odpytuje REST API NetBoksa, pobiera listę urządzeń o statusie 'Active' i rejestruje je w LibreNMS komendą `lnms device:add`.

Więcej informacji o modelu danych i integracji z platformą NetBox znajduje się pod adresem: netboxlabs.com/docs/netbox/.

Zarządzanie typu In-Band (gdzie pakiety SNMP współdzielą te same łącza fizyczne co ruch użytkowników) zawodzi w najgorszych momentach. Gdy w sieci wystąpi sztorm rozgłoszeniowy wywołany pętlą STP, procesory przełączników osiągają 100% obciążenia i odrzucają pakiety SNMP, a serwer NMS traci łączność.

W profesjonalnych centrach danych każdy przełącznik i router posiada dedykowany fizyczny interfejs zarządzający (np. port `mgmt0`), wpięty do osobnej, dedykowanej infrastruktury przełączników OOB. Serwer NMS podłączony bezpośrednio do sieci OOB widzi urządzenia nawet przy całkowitym zablokowaniu portów produkcyjnych.

Podobnie kluczowa jest kwestia wysyłki powiadomień. Jeśli serwer NMS próbuje wysłać e-mail przez łącze firmowe, które właśnie uległo fizycznemu zerwaniu przez koparkę, alarm nigdy nie dotrze do administratora. Bezpośredni modem GSM/LTE rozwiązuje ten problem całkowicie.

Najczęstszym błędem popełnianym przez początkujących administratorów jest instalowanie systemu NMS na wirtualnej maszynie współdzielącej wolną macierz dyskową HDD ze środowiskiem biurowym. W rezultacie po dodaniu kilkudziesięciu przełączników czas cyklu odpytywania przekracza 300 sekund (poller overrun), a wykresy stają się poszarpane i niekompletne.

Wdrożenie demona `rrdcached` jest bezwzględnym wymogiem wydajnościowym. Agreguje on operacje modyfikacji plików RRD w pamięci RAM i dokonuje zapisu blokowego, drastycznie zmniejszając obciążenie kontrolera dyskowego.

Dla instalacji klasy korporacyjnej (>1000 urządzeń) zaleca się dedykowany serwer MariaDB z dużą pamięcią podręczną `innodb_buffer_pool_size` (odpowiadającą co najmniej 70% dostępnego RAM) oraz optymalizację parametrów jądra Linux w pliku `/etc/sysctl.conf` (np. zwiększenie limitu otwartych plików `fs.file-max`).

W klasycznym modelu pracy NOC inżynier dyżurny po otrzymaniu powiadomienia o błędach CRC na porcie logował się na przełącznik, analizował sąsiednie węzły i ręcznie wyłączał interfejs. Cały proces trwał od kilkunastu minut do kilku godzin, generując wymierne straty biznesowe.

W architekturze AIOps połączonej z Event-Driven Ansible sygnał z NMS natychmiast uruchamia regułę decyzyjną (Rulebook). Jeśli liczba błędów CRC przekracza 500 pakietów na minutę, skrypt automatycznie zwiększa koszt metryki OSPF dla tego łącza, co powoduje bezstratne przepięcie ruchu na łącze zapasowe w ułamku sekundy.

Kluczowym warunkiem bezpieczeństwa tego typu rozwiązań jest wdrożenie mechanizmów 'Circuit Breakers'. Jeśli automatyzacja w ciągu 10 minut dokona trzech przełączeń tras, dalsze akcje samonaprawcze są blokowane, a kontrola przekazywana dyżurnemu inżynierowi.

Opanowanie pojęć takich jak Source of Truth, Distributed Polling czy architektura OOB stanowi warunek konieczny do podejmowania właściwych decyzji projektowych w pracy inżyniera sieciowego.

Warto zwrócić uwagę na ewolucję pojęciową: tradycyjny monitoring oparty na odpytywaniu SNMP w interwałach 5-minutowych ustępuje miejsca telemetrii strumieniowej (Streaming Telemetry), w której urządzenia same wysyłają ustrukturyzowane powiadomienia w momencie wystąpienia anomalii.

W kolejnych modułach pojęcia te będą stanowiły punkt wyjścia do wdrożeń kontenerowych oraz zabezpieczania i centralizacji dzienników zdarzeń.

Odpowiedź na pytanie 2: Pojedynczy serwer posiada ograniczoną liczbę wątków i gniazd sieciowych. Gdy czasy oczekiwania na pakiety SNMP (timeout) kumulują się, cykl odpytywania przekracza 300 sekund. W architekturze Distributed Poller serwer centralny wrzuca identyfikatory urządzeń do kolejki Redis, skąd rozproszone maszyny pobierają zadania równolegle.

Odpowiedź na pytanie 3: NetBox definiuje stan zamierzony (projektowy: jakie urządzenia POWINNY być w szafach, jakie mieć IP i konfigurację). LibreNMS bada stan faktyczny (jak urządzenia RZECZYWIŚCIE działają). Wykrycie urządzenia w LibreNMS, którego brak w NetBoksie, natychmiast ujawnia nieautoryzowany sprzęt (Shadow IT).

Odpowiedź na pytanie 4: W przypadku fizycznego zerwania światłowodu tranzytowego lub sztormu pakietów w sieci LAN, serwer NMS tracący łączność z siecią produkcyjną nie jest w stanie wysłać e-maila przez łącze firmowe. Własny sprzętowy modem LTE z kartą SIM gwarantuje natychmiastowe wysłanie alertu SMS do dyżurnego inżyniera.

Podręcznik LibreNMS Documentation zawiera wyczerpujące opisy modułów wykrywania, integracji z rsyslog, konfiguracji klastrów Redis oraz pełną specyfikację interfejsu REST API.

Więcej o konfiguracji serwera i klienta The Dude można znaleźć w oficjalnym portalu MikroTik: MikroTik The Dude v7 Manual.

Dla zainteresowanych paradygmatem Intent-Based Networking i integracją z centralną bazą inwentarzową lekturą obowiązkową jest dokumentacja: NetBox Documentation.