Strona główna 1: Wprowadzenie 2: Protokół SNMP 3: SNMP w praktyce 4: Systemy NMS 5: Kontenery i wdrożenie 6: Logowanie i bezpieczeństwo
Slajd 1/55
Systemy NMS – LibreNMS i The Dude
Cel slajdu: Przedstawienie architektury, wdrożenia i funkcji współczesnych systemów zarządzania siecią na przykładzie platform LibreNMS oraz MikroTik The Dude.

Strona tytułowa i wprowadzenie do modułu

Systemy NMS (Network Management Systems) integrują odpytywanie telemetryczne, automatyczne wykrywanie topologii, magazynowanie metryk oraz silnik reguł alarmowych w jeden spójny portal operacyjny.

  • Cel modułu: Szczegółowa analiza dwóch odmiennych podejść: otwartoźródłowego, webowego LibreNMS oraz dedykowanego rozwiązaniom MikroTik systemu The Dude
  • Funkcjonalności kluczowe: Auto-discovery sąsiadów (CDP/LLDP), dynamiczne mapy Weathermap, korelacja zdarzeń i elastyczne reguły powiadomień
  • Architektura stosu: Bazy relacyjne MariaDB, magazyny szeregów czasowych RRDtool, silnik kolejkowy Redis i rozproszony polling
  • Alternatywy rynkowe: Konfrontacja z platformami Zabbix, Cacti, Nagios oraz nowoczesnym stosem Prometheus i Grafana
System NMS klasy Enterprise: Centralna platforma zapewniająca pełną widoczność stanu wielotysięcznej infrastruktury sieciowej w czasie rzeczywistym, redukująca czas wykrywania awarii (MTTD) z godzin do sekund.
Wprowadzenie do systemów NMS Systemy NMS – LibreNMS i The Dude LibreNMS • Open Source (GPLv3) • Autoodkrywanie CDP/LLDP • Wsparcie > 3000 modeli PHP, MariaDB, RRDtool The Dude • Ekosystem MikroTik • Dynamiczna mapa 2D • Klient desktop Win32 Serwer w RouterOS Ecosystem NMS • Zabbix & Prometheus • Oxidized & NetBox • Weathermap i Grafana Integracja i AIOps Cel modułu: Od pytań wiersza poleceń do orkiestracji wielotysięcznej infrastruktury • Poznamy architekturę systemów NMS i wzorzec zarządzania FCAPS (ISO/IEC 7498-4). • Wdrożymy i skonfigurujemy system LibreNMS z autoodkrywaniem topologii i regułami alertów. • Przeanalizujemy specyfikę The Dude oraz porównamy wiodące platformy na rynku teleinformatycznym.
Slajd 2/55
Spis treści prezentacji 4
Cel slajdu: Przedstawienie kompleksowego planu wykładu poświęconego architekturze, wdrożeniu i eksploatacji platform NMS w przedsiębiorstwach.

Plan prezentacji

Prezentacja została podzielona na pięć logicznych bloków tematycznych, prowadzących od teoretycznych podstaw modelu FCAPS do zaawansowanych wdrożeń wieloplatformowych.

  • Blok 1 (Slajdy 3-12): Czym jest NMS, model FCAPS, architektura i instalacja systemu LibreNMS, mechanizm autoodkrywania
  • Blok 2 (Slajdy 13-23): Wykresy RRD, zaawansowany silnik alarmów, mapy Weathermap, REST API, trapy, Syslog i backup Oxidized
  • Blok 3 (Slajdy 24-33): System MikroTik The Dude: instalacja w RouterOS, klient desktopowy, sondy, interaktywne mapy i ograniczenia
  • Blok 4 (Slajdy 34-43): Wielowymiarowa analiza porównawcza: LibreNMS vs The Dude vs Zabbix vs Nagios oraz nowoczesny stos Prometheus + Grafana
  • Blok 5 (Slajdy 44-55): Warsztaty laboratoryjne, diagnostyka validate.php, planowanie pojemności bazy, słownik pojęć i pytania kontrolne
Praktyka inżynierska: Opanowanie materiału tej części pozwala na samodzielne zaprojektowanie i wdrożenie kompletnego systemu monitoringu dla sieci kampusowej lub operatorskiej.
Plan prezentacji Plan prezentacji 4: Systemy NMS (55 slajdów) 1. Architektura NMS i LibreNMS • Model FCAPS, komponenty stosu • Wymagania, instalacja, GUI, autoodkrywanie 2. Telemetria i Alerty w LibreNMS • Wykresy RRD, silnik alarmów, reguły • Mapy Weathermap, REST API, trapy i Syslog 3. MikroTik The Dude • Geneza, serwer w RouterOS, klient Win32 • Sondy (probes), mapy, wykresy i integracja 4. Porównanie i Alternatywy • LibreNMS vs The Dude vs Zabbix vs Nagios • Drzewo decyzyjne wyboru, Prometheus + Grafana 5. Warsztat laboratoryjny, diagnostyka i podsumowanie • Integracja z Oxidized (kopie Git) i NetBox (IPAM) • Ćwiczenia praktyczne: dodawanie hostów, alerty, validate.php, planowanie pojemności • Słownik pojęć i pytania kontrolne przygotowujące do egzaminu
Slajd 3/55
Czym jest system NMS? – Architektura wielowarstwowa
Cel slajdu: Przedstawienie definicji systemu NMS w oparciu o standard ISO FCAPS oraz omówienie wielowarstwowej architektury przetwarzania danych.

Architektura i wprowadzenie do LibreNMS

Standard ISO/IEC 7498-4 definiuje ramy zarządzania siecią teleinformatyczną poprzez model FCAPS, obejmujący pięć kluczowych filarów operacyjnych.

  • Model FCAPS (ISO/IEC 7498-4): Fault (awarie), Configuration (konfiguracja), Accounting (rozliczenia/zasoby), Performance (wydajność), Security (bezpieczeństwo)
  • Warstwa akwizycji danych: Moduły pollerów odpytujące urządzenia przez SNMP, nasłuchujące pułapek (Traps), odbierające logi Syslog i telemetrię strumieniową
  • Dwuskładnikowa baza danych: Rozdział na bazę relacyjną (przechowującą metadane, topologię i użytkowników) oraz bazę szeregów czasowych RRDtool (przechowującą próbki metryk)
  • Silnik korelacji i powiadomień: Automatyczna analiza danych pod kątem anomalii, tłumienie szumu alarmowego (alert suppression) i powiadamianie dyżurnych inżynierów
Model FCAPS: Międzynarodowy standard zarządzania sieciami opracowany przez ISO i ITU-T, stanowiący fundament teoretyczny dla wszystkich komercyjnych i otwartoźródłowych systemów NMS.
Model FCAPS i architektura NMS Model FCAPS (ISO/IEC 7498-4) i warstwy systemu NMS F - Fault Zarządzanie awariami Detekcja, Trapy, Alerty, Syslog C - Config Zarządzanie konfiguracją Kopie backup, Git (Oxidized) A - Accounting Rozliczenia i zasoby Billing portów, 95th percentile P - Perform Zarządzanie wydajnością Wykresy RRD, Trendy, SLA S - Security Bezpieczeństwo dostępu RBAC, 2FA, LDAP, Audit log Warstwy funkcjonalne nowoczesnej platformy NMS • Warstwa akwizycji danych (Collector/Poller): Odpytywanie SNMP, odbiór Trapów, Syslog, gNMI, API REST. • Warstwa przetwarzania i składowania: Baza relacyjna (MariaDB/PostgreSQL) oraz szeregi czasowe (RRDtool/TSDB). • Warstwa logiki i reguł (Alerting Engine): Ciągła ewaluacja progów, korelacja zdarzeń i eskalacja incydentów. • Warstwa prezentacji (GUI & API): Pulpity nawigacyjne (Dashboards), dynamiczne mapy topologiczne, raporty i REST API.
Slajd 4/55
LibreNMS – Geneza, licencja i filozofia projektu
Cel slajdu: Przedstawienie historii powstania LibreNMS, zasad licencyjnych GPLv3 oraz fundamentalnej filozofii automatycznego wykrywania urządzeń.

Architektura i wprowadzenie do LibreNMS

LibreNMS powstał pod koniec 2013 roku jako niezależny fork ostatniej wersji Observium na licencji GPL. Według oficjalnej dokumentacji projektu powodem rozwidlenia nie była decyzja o płatnej subskrypcji, lecz różnica priorytetów i wartości między społecznością a zespołem Observium.

  • Geneza i niezależność: Projekt powołany przez grupę programistów dążących do stworzenia w pełni otwartego, bezkompromisowego systemu NMS na licencji GNU GPLv3
  • Filozofia 'Out-of-the-Box': Brak konieczności żmudnego tworzenia szablonów; system po podaniu adresu IP i SNMP automatycznie rozpoznaje model, interfejsy i sensory
  • Nowoczesny stos technologiczny: Ewolucja od prostych skryptów proceduralnych do zaawansowanego frameworka Laravel (PHP 8) z bazą MariaDB i kolejkami Redis
  • Wsparcie dla społeczności: Publiczne repozytorium GitHub z setkami kontrybutorów i oficjalną dokumentacją docs.librenms.org
Gwarancja wolnego oprogramowania: Licencja GNU General Public License v3 (GPLv3) gwarantuje, że LibreNMS na zawsze pozostanie darmowym i otwartym narzędziem, bez ukrytych opłat za liczbę monitorowanych portów czy moduły zaawansowane.
Geneza projektu LibreNMS Ewolucja i ekosystem projektu LibreNMS 2007: Observium • Projekt Adama Armstronga • Architektura auto-discovery • Zamknięcie edycji Pro Konflikt ze społecznością 2013: Fork LibreNMS • Całkowity Open Source • Licencja GNU GPLv3 • Zarządzanie na GitHubie Demokratyczna społeczność Współczesność: 2026+ • Framework Laravel (PHP 8) • Distributed Polling (Redis) • > 3000 modeli i setki OS Lider monitoringu SNMP Filozofia projektowa LibreNMS: Zero Configuration Monitoring • Autonomia odkrywania: Administrator podaje wyłącznie adres IP i Community String – reszta dzieje się sama. • Brak konieczności tworzenia szablonów: System sam dobiera pliki definicji YAML dla danego producenta sprzętu. • Otwarty ekosystem: Pełna baza kodu dostępna publicznie na GitHubie LibreNMS na licencji GPLv3. Projekt rozwija się dzięki wkładom setek administratorów sieci z całego świata.
Slajd 5/55
LibreNMS – Kluczowe funkcjonalności i możliwości
Cel slajdu: Przegląd wszechstronnych możliwości systemu LibreNMS w zakresie monitorowania, powiadamiania, raportowania i integracji zewnętrznych.

Architektura i wprowadzenie do LibreNMS

LibreNMS dostarcza kompleksowy zestaw narzędzi pokrywający wszystkie potrzeby operacyjne zespołów utrzymania sieci teleinformatycznych (NOC).

  • Uniwersalne wsparcie sprzętowe: Natywna obsługa ponad 3000 modeli urządzeń i setek systemów operacyjnych (Cisco, Juniper, MikroTik, HP, Arista, Linux, Windows, zasilacze, czujniki klimatyzacji)
  • Automatyczne odkrywanie sieci: Skanowanie protokołów warstwy L2 (CDP, LLDP, FDP) oraz L3 (BGP, OSPF, tablice ARP) z automatycznym rysowaniem map powiązań
  • Wielokanałowy system powiadomień: Wbudowana integracja z ponad 50 platformami powiadomień (E-mail, Slack, Microsoft Teams, Mattermost, Discord, Telegram, SMS, Webhooki)
  • Moduł bilingowy i Weathermap: Pomiar pasma z wyliczaniem 95. percentyla oraz integracja z graficznymi mapami nasycenia łączy Network Weathermap
Wsparcie dla urządzeń IoT i Datacenter: Poza typowym sprzętem sieciowym LibreNMS znakomicie radzi sobie z odpytywaniem listew zasilających PDU, zasilaczy UPS, serwerów przez IPMI/iLO/iDRAC oraz sensorów temperatury w szafach rackowych.
Funkcjonalności LibreNMS Przegląd kluczowych modułów funkcjonalnych LibreNMS Odkrywanie i Telemetria • CDP / LLDP / FDP • Wykrywanie tras BGP/OSPF • Sensory napięć, fan, temp Automatyczne indeksowanie Alerty i Notyfikacje • Elastyczny silnik reguł • Integracja z 50+ kanałami • Slack, Teams, Mail, SMS Zarządzanie incydentami Mapy i Billing • Dynamiczne mapy topologii • Plugin Network Weathermap • Rozliczenia portów (95th) Raportowanie SLA Dodatkowe możliwości integracyjne platformy • Centralizacja dzienników: Wbudowana obsługa Syslog oraz odbiornik pułapek snmptrapd. • Kopie konfiguracji (Oxidized): Automatyczny backup plików konfiguracyjnych urządzeń do repozytorium Git. • Autentykacja korporacyjna: Integracja z Active Directory, OpenLDAP, RADIUS oraz dwuskładnikowym uwierzytelnianiem 2FA. Zapewnia pełną zgodność z normami bezpieczeństwa teleinformatycznego ISO/IEC 27001.
Slajd 6/55
Architektura LibreNMS – Podział na komponenty
Cel slajdu: Przedstawienie wielokomponentowej architektury systemu LibreNMS, roli poszczególnych demonów oraz optymalizacji wąskich gardeł I/O.

Architektura i wprowadzenie do LibreNMS

LibreNMS nie jest monolitem, lecz przemyślanym ekosystemem współpracujących ze sobą usług systemowych Linuksa, zoptymalizowanych pod kątem wysokiej wydajności.

  • Warstwa Web & API: Serwer Nginx / Apache obsługujący żądania użytkowników przez PHP-FPM, oparty na strukturze frameworka Laravel
  • Silnik odpytujący (Poller & Discovery): Wieloprocesowy skrypt `poller-wrapper.py` lub nowoczesna usługa `librenms-dispatcher` zarządzająca wątkami
  • Dwupoziomowe składowanie danych: Baza MariaDB dla tabel relacyjnych (konfiguracje, stan portów, alerty) oraz pliki RRDtool dla próbek telemetrycznych
  • Demon buforujący RRDcached: Kluczowy komponent agregujący operacje zapisu do plików RRD w pamięci operacyjnej, redukujący zużycie dysków o ponad 80%
Wąskie gardło I/O: W systemach NMS głównym ograniczeniem wydajnościowym nie jest procesor, lecz operacje wejścia/wyjścia dysku (IOPS). Zastosowanie demona rrdcached jest bezwzględnym wymogiem w instalacjach powyżej 100 urządzeń.
Komponenty architektury LibreNMS Stos technologiczny i przepływ danych w LibreNMS Web & API • Nginx / Apache • PHP-FPM 8.x • Laravel Framework Port TCP 80/443 Silnik Poller • poller-wrapper.py • Dispatcher service • Kolejka Redis Cyklicznie co 5m/1m Magazyn Danych • MariaDB (Tabele) • RRDtool (.rrd pliki) • Bufor rrdcached Zapis na NVMe/SSD Zdarzenia Zewn. • snmptrapd (UDP 162) • syslog-ng (UDP 514) • Silnik alertów Reakcja w czasie rzecz. Separacja ról w nowoczesnej architekturze LibreNMS • Poller & Discovery: Skrypty w PHP i Pythonie odpytują agentów i aktualizują strukturę bazy. • RRDcached: Niezbędny demon buforujący operacje I/O w pamięci RAM przed zapisem plików RRD na dysk. • Dispatcher Service (Python): Zastępuje tradycyjny cron, dynamicznie przydzielając zadania przez Redis. Umożliwia horyzontalne skalowanie monitoringu do setek tysięcy portów sieciowych.
Slajd 7/55
Wymagania sprzętowe i programowe LibreNMS
Cel slajdu: Prawidłowe wyskalowanie zasobów serwera (CPU, RAM, Storage IOPS) pod kątem planowanej liczby urządzeń i portów sieciowych.

Architektura i wprowadzenie do LibreNMS

Prawidłowe oszacowanie zasobów sprzętowych serwera NMS jest warunkiem bezawaryjnej pracy i braku opóźnień w cyklach pomiarowych.

  • Skala mała (< 100 urządzeń): Wystarczająca jest pojedyncza maszyna wirtualna: 2-4 vCPU, 4-8 GB pamięci RAM, 50 GB dysku SSD (SATA/NVMe)
  • Skala średnia (100 - 500 urządzeń): Zapotrzebowanie rośnie do 8-16 vCPU, 16-32 GB RAM oraz dedykowanego dysku NVMe zdolnego obsłużyć kilka tysięcy IOPS
  • Skala duża (> 1000 urządzeń): Wymaga separacji ról na klastry: oddzielny serwer bazy MariaDB, dedykowany serwer Web UI oraz grupa rozproszonych węzłów pollerów
  • Środowisko programowe: Zalecane dystrybucje: Ubuntu 24.04 LTS / Debian 12, PHP ≥ 8.4 (zalecany 8.5), MariaDB 10.11+, Nginx, RRDtool oraz Python 3
Kluczowy parametr InnoDB: W konfiguracji MariaDB (/etc/mysql/mariadb.conf.d/50-server.cnf) należy ustawić innodb_buffer_pool_size na poziomie 50-70% całkowitej pamięci RAM serwera, co drastycznie przyspiesza zapytania SQL.
Wymagania sprzętowe LibreNMS Wymiary zasobów serwera NMS w zależności od skali Mała sieć (< 100 węzłów) • CPU: 2 - 4 vCPU • RAM: 4 - 8 GB • Dysk: 50 GB SSD Porty: do 2 500 Średnia (100 - 500 węzłów) • CPU: 8 - 16 vCPU • RAM: 16 - 32 GB • Storage: 200 GB NVMe Porty: do 15 000 Enterprise (> 1000 węzłów) • Klaster Distributed • Dedykowany MariaDB • Macierz All-Flash NVMe Porty: > 50 000 Wymagania systemowe i zależności programowe • System operacyjny: Ubuntu Server 22.04 / 24.04 LTS lub Debian 12 (Bookworm). • Wersja interpretera PHP: PHP ≥ 8.4 (zalecany 8.5) z rozszerzeniami: curl, gd, mbstring, mysql, snmp, xml, zip. • Baza danych SQL: MariaDB w wersji 10.5+ lub MySQL 8.0 skonfigurowana pod kątem dużych buforów InnoDB. Stosowanie klasycznych dysków talerzowych HDD jest kategorycznie odradzane ze względu na limity IOPS.
Slajd 8/55
Tradycyjna instalacja LibreNMS w systemie Linux
Cel slajdu: Przedstawienie standardowej ścieżki wdrożenia środowiska LibreNMS bezpośrednio na systemie operacyjnym Ubuntu/Debian.

Architektura i wprowadzenie do LibreNMS

Instalacja LibreNMS w środowisku fizycznym lub maszynie wirtualnej wymaga przygotowania stosu LEMP (Linux, Nginx, MariaDB, PHP) i prawidłowego skonfigurowania uprawnień systemowych.

  • Krok 1: Instalacja pakietów bazowych: Instalacja serwera WWW Nginx, interpretera PHP-FPM wraz z modułami, serwera bazy danych MariaDB, narzędzi snmp, fping i git
  • Krok 2: Utworzenie bazy danych: Konfiguracja bazy MySQL z kodowaniem `utf8mb4` i porównywaniem `utf8mb4_unicode_ci` oraz dedykowanego użytkownika
  • Krok 3: Klonowanie kodu i uprawnienia: Pobranie repozytorium do katalogu `/opt/librenms`, utworzenie konta systemowego `librenms` oraz pobranie bibliotek przez Composer
  • Krok 4: Konfiguracja Nginx i instalator WWW: Stworzenie wirtualnego hosta w `/etc/nginx/conf.d/librenms.conf` i dokończenie instalacji w kreatorze przeglądarkowym
Kreator Web Installer: Po wejściu pod adres http://IP-SERWERA/install kreator przeprowadza weryfikację uprawnień, łączy się z bazą danych, generuje klucz szyfrujący APP_KEY i tworzy konto administratora.
Procedura instalacji LibreNMS Procedura wdrożenia LibreNMS na systemie Ubuntu/Debian 1. Pakiety • apt install nginx • php8.2-fpm mariadb • rrdtool snmp git 2. Baza MariaDB • CREATE DATABASE • utf8mb4_unicode • GRANT ALL ON... 3. Pobranie Kodu • git clone librenms • useradd librenms • composer install 4. Web Installer • Wizard w WWW • Konto admina • ./validate.php # 1. Klonowanie repozytorium do katalogu /opt/librenms $ git clone https://github.com/librenms/librenms.git /opt/librenms # 2. Utworzenie użytkownika systemowego i nadanie uprawnień $ useradd librenms -d /opt/librenms -M -r -s /bin/bash $ chown -R librenms:librenms /opt/librenms && chmod 771 /opt/librenms # 3. Instalacja zależności PHP Composer i budowa bazy $ su - librenms -c "/opt/librenms/scripts/composer_wrapper.php install --no-dev" $ su - librenms -c "/opt/librenms/lnms migrate"
Slajd 9/55
Przegląd interfejsu graficznego LibreNMS
Cel slajdu: Zapoznanie z ergonomią, układem elementów oraz strukturą menu nowoczesnego interfejsu użytkownika LibreNMS.

Architektura i wprowadzenie do LibreNMS

Interfejs graficzny LibreNMS został zaprojektowany z myślą o inżynierach pracujących w centrach monitoringu (NOC), łącząc czytelność z natychmiastowym dostępem do metryk.

  • Personalizowane pulpity nawigacyjne: Możliwość tworzenia wielu dashboardów (ogólnych, dla zespołów serwerowych, dla łączy WAN) z widżetami w układzie siatki
  • Główne moduły menu nawigacyjnego: Menu `Devices` (podział na typy sprzętu), `Ports` (globalna wyszukiwarka interfejsów), `Alerts` (rejestr incydentów), `Routing` (BGP/OSPF)
  • Widżety czasu rzeczywistego: Licznik stanu urządzeń, lista 10 najbardziej obciążonych interfejsów (Top Interfaces), strumień zdarzeń (Eventlog) oraz podgląd mapy
  • Tryb nocny (Dark Mode): Natywne wsparcie dla ciemnego motywu interfejsu, preferowanego na wielomonitorowych ścianach wideo w centrach operacyjnych
Współdzielenie pulpitów: Dashboardy w LibreNMS mogą być publiczne (widoczne dla wszystkich), prywatne (dla konkretnego inżyniera) lub przypisane do określonych ról użytkowników w systemie.
Interfejs graficzny LibreNMS Układ pulpitu nawigacyjnego i menu LibreNMS LibreNMS Dashboard Devices Ports Alerts Routing Settings Alerts (3) Widżet: Device Status • Dostępne (UP): 142 • Awaria (DOWN): 2 • Wyciszone (Mute): 1 Widżet: Top Interfaces 1. core-r01 Gi0/0 (92%) 2. wan-isp1 eth1 (78%) 3. srv-nfs bond0 (64%) Widżet: Eventlog 14:22 sw02 linkDown Gi1/4 14:15 bgp peer established 14:00 backup oxidized OK Kluczowe sekcje menu administracyjnego • Devices: Pełna lista urządzeń z podziałem na role (Network, Wireless, Server, Storage, Power). • Ports: Wyszukiwarka portów według prędkości, błędów, utylizacji, opisów i stanów operacyjnych. • Routing: Wizualizacja sesji BGP, sąsiedztwa OSPF, tras statycznych i wirtualnych instancji VRF. Układ pulpitów nawigacyjnych jest w pełni konfigurowalny w technologii Drag-and-Drop.
Slajd 10/55
Dodawanie urządzeń do LibreNMS
Cel slajdu: Przedstawienie procedury wprowadzania węzłów sieciowych do monitoringu za pomocą interfejsu graficznego oraz wiersza poleceń CLI.

Architektura i wprowadzenie do LibreNMS

Wprowadzenie urządzenia do LibreNMS jest operacją błyskawiczną, wymagającą podania jedynie adresu IP oraz poświadczeń SNMP.

  • Dodawanie przez panel graficzny (GUI): Formularz w menu `Devices -> Add Device` z polami: nazwa hosta/IP, wersja SNMP (v1/v2c/v3), parametry społeczności lub użytkownika USM
  • Zarządzanie z wiersza poleceń (CLI lnms): Polecenie `/opt/librenms/lnms device:add` pozwalające na zautomatyzowane dodawanie hostów w skryptach powłoki lub playbookach Ansible
  • Proces autodetekcji systemu (OS Detection): W momencie dodania węzła system wykonuje zapytanie o `sysDescr.0` i automatycznie przypisuje odpowiedni profil producenta
  • Pierwszy cykl Discovery i Polling: Uruchomienie modułu odkrywania mapuje wszystkie porty fizyczne, sensory temperatur, dyski i tablice routingu
Wymuszenie ręcznego odkrywania: Podczas dodawania testowych węzłów nie trzeba czekać na harmonogram cron. Wywołanie lnms device:discover <id> -d (lub klasycznego ./discovery.php -h <id> -d) z flagą debugowania wyświetla pełny zrzut wszystkich zapytań SNMP i wykrytych modułów.
Dodawanie urządzeń do monitoringu Metody dodawania urządzeń: GUI oraz wiersz poleceń CLI Metoda 1: Panel WWW (GUI) • Menu: Devices -> Add Device • Pole: Hostname lub IP • Wybór protokołu: v1 / v2c / v3 • Community lub Auth/Priv credentials Metoda 2: Narzędzie CLI lnms • lnms device:add <hostname> • Flagi: -2 (v2c), -3 (v3), -c (comm) • Idealne do skryptów wdrożeniowych • Integracja z Ansible i provisioningiem # Dodanie przełącznika przez CLI z protokołem SNMPv3 (AuthPriv) $ /opt/librenms/lnms device:add sw-core01.lan \ -3 -u mon_user -a SHA-256 -A 'AuthHaslo123' -x AES -X 'PrivHaslo456' Added device sw-core01.lan (143) with SNMPv3 AuthPriv # Natychmiastowe wymuszenie pierwszego odkrywania: $ /opt/librenms/lnms device:discover 143 && /opt/librenms/lnms device:poll 143
Slajd 11/55
Mechanizm automatycznego wykrywania (Auto-discovery)
Cel slajdu: Zrozumienie działania algorytmów autoodkrywania urządzeń i relacji topologicznych w oparciu o protokoły sąsiedztwa i routing.

Architektura i wprowadzenie do LibreNMS

Jedną z największych zalet LibreNMS jest zdolność do samodzielnego 'przechodzenia' po strukturze sieci i dołączania nowo podłączonych urządzeń.

  • Odkrywanie L2 przez LLDP i CDP: Analiza tablic protokołów sąsiedztwa pozwala na natychmiastowe zidentyfikowanie nazwy i portu po drugiej stronie kabla krosowego
  • Odkrywanie przez protokoły routingu: Śledzenie relacji sąsiedztwa w protokołach BGP i OSPF umożliwia wykrywanie routerów brzegowych i szkieletowych
  • Narzędzie snmp-scan.py: Skrypt sondujący zadane zakresy podsieci IP za pomocą listy zdefiniowanych haseł Community String i dodający aktywne hosty
  • Kontrola zasięgu odkrywania: Konfiguracja zmiennej `$config['nets']`, która zapobiega przypadkowemu skanowaniu i dodawaniu obcych sieci operatorskich
Zabezpieczenie przed pętlą odkrywania: Jeśli router brzegowy ma skonfigurowaną sesję eBGP z zewnętrznym operatorem (np. Level3 / Lumen), brak ograniczenia podsieci spowodowałby próbę przeskanowania routerów w całym globalnym Internecie!
Mechanizmy Auto-discovery Protokoły i mechanizmy automatycznego odkrywania topologii 1. Warstwa L2 (Sąsiedzi) • LLDP (IEEE 802.1AB) • CDP (Cisco Discovery) • FDP (Foundry/Extreme) Wykrywanie połączeń port-port 2. Warstwa L3 (Routing) • Sąsiedzi BGP (RFC 1657) • Adjacency OSPF (RFC 1850) • Tablice ARP (ipNetToMedia) Rekursywne dodawanie węzłów 3. Skanowanie Podsieci • snmp-scan.py • Skanowanie pul IP (CIDR) • Lista haseł Community Automatyzacja wdrożeń Konfiguracja automatycznego odkrywania w config.php $config['autodiscovery']['xdp'] = true; # Włączenie odkrywania przez LLDP/CDP $config['autodiscovery']['ospf'] = true; # Odkrywanie routerów z bazy OSPF $config['autodiscovery']['bgp'] = true; # Odkrywanie routerów tranzytowych BGP $config['nets'][] = '192.168.100.0/24'; # Dozwolona podsieć dla autoodkrywania Zabezpieczenie przed niekontrolowanym rozrostem: dyrektywa $config['nets'] ogranicza skanowanie.
Slajd 12/55
Szczegółowy widok urządzenia w LibreNMS
Cel slajdu: Przegląd kart diagnostycznych widoku urządzenia (Device View) i zrozumienie sposobu prezentacji metryk sprzętowych i sieciowych.

Architektura i wprowadzenie do LibreNMS

Kliknięcie w dowolne urządzenie otwiera zintegrowany panel telemetryczny (Device View), gromadzący wszystkie aspekty pracy danego węzła.

  • Karta Overview: Podstawowa tożsamość węzła: nazwa hosta, numer seryjny, wersja oprogramowania układowego, czas pracy (Uptime) oraz lokalizacja
  • Karta Health (Sensory sprzętowe): Wizualizacja parametrów czujników: temperatury procesora i płyty, prędkości wentylatorów (RPM), napięcia zasilaczy oraz moc optyczna DDM
  • Karta Ports (Interfejsy): Tabela wszystkich portów fizycznych i logicznych z podziałem na statusy UP/DOWN, wykresy pasma, liczniki błędów CRC oraz pakiety porzucone (discards)
  • Karty protokołów (BGP, OSPF, STP): Dedykowane widoki dla protokołów routingu i przełączania, prezentujące stany sesji oraz historię zmian topologii Spanning Tree
Szybki audyt błędów CRC: W karcie Ports kolumny Errors i Discards pozwalają na natychmiastowe posortowanie portów. Pojawienie się błędów CRC w 99% przypadków wskazuje na uszkodzony kabel krosowy lub zabrudzone złącze światłowodowe.
Szczegółowy widok węzła Karty diagnostyczne węzła w panelu LibreNMS Overview Model, OS, Uptime Lokalizacja, IP Graphs Zbiorcze wykresy CPU, RAM, Pasmo Health Temperatury, Fan Napięcia, SFP DDM Ports Statusy UP/DOWN Pakiety, Błędy Routing Sesje BGP, OSPF Prefiksy trasy Szczegółowa analityka komponentów sprzętowych • Karta Spanning Tree (STP): Wykrywa rolę portu (Root, Designated, Alternate) i zmiany topologii (Topology Changes). • Karta Optyki DDM: Wizualizacja mocy nadawczej Tx i odbiorczej Rx w dBm z progami ostrzegawczymi producenta wkładek. • Karta Logs & Events: Zintegrowany rejestr zdarzeń systemowych, komunikatów Syslog i odebranych pułapek SNMP Traps. • Karta Config (Oxidized): Podgląd aktualnej konfiguracji urządzenia z kolorowym diffem zmian w czasie. Zapewnia inżynierowi NOC 100% informacji w jednym oknie przeglądarki bez konieczności logowania SSH.
Slajd 13/55
Generowanie i interpretacja wykresów wydajności
Cel slajdu: Opanowanie zasad interpretacji wykresów RRDtool, rozróżniania typów ruchu oraz analizy wskaźników statystycznych.

Telemetria i alerty w LibreNMS

Wykresy w LibreNMS bazują na silniku RRDtool, łącząc klasyczny standard kolorystyczny MRTG z zaawansowaną analizą statystyczną.

  • Standard kolorystyczny MRTG: Zielone wypełnienie dla ruchu wejściowego (Inbound) oraz niebieska linia dla ruchu wychodzącego (Outbound)
  • Tabela statystyk pod wykresem: Zestawienie wartości liczbowych: wartość bieżąca (Current), średnia (Average), maksymalna (Maximum) i minimalna (Minimum)
  • Konsolidacja danych w czasie: W miarę upływu czasu szczegółowe próbki 5-minutowe są automatycznie agregowane do średnich godzinnych i dobowych
  • Wykresy zbiorcze (Stacked & Aggregate): Możliwość sumowania pasma wielu portów w jeden zagregowany wykres (np. dla zagregowanych łączy LACP / Port-Channel)
Metoda 95. percentyla (Burstable Billing): Metoda rozliczania ruchu tranzytowego polegająca na posortowaniu próbek z całego miesiąca od najmniejszej do największej i odrzuceniu najwyższych 5% pomiarów. Klient płaci za pasmo określone przez 95. setną próbkę.
Anatomia wykresów RRD Anatomia wykresu wydajnościowego RRDtool w LibreNMS Port Gi1/0/1 - Uplink Do Operatora ISP (1 Gbps Full-Duplex) 95th Percentile: 820 Mbps Kanon wizualizacji i metryki statystyczne • Zielony obszar (Green Area): Ruch przychodzący (Inbound) mierzony w bitach na sekundę. • Niebieska linia (Blue Line): Ruch wychodzący (Outbound) mierzony w bitach na sekundę. • Linia 95. percentyla: Odrzuca 5% szczytów krótkotrwałych, wskazując realne zapotrzebowanie na pasmo. Pod wykresem prezentowane są wartości: Bieżąca (Cur), Średnia (Avg), Maksymalna (Max) i Minimalna (Min).
Slajd 14/55
Zaawansowany system alarmów (Alerting Engine)
Cel slajdu: Przedstawienie architektury silnika alarmów, mechanizmu reguł logicznych, szablonów oraz kanałów transportowych w LibreNMS.

Telemetria i alerty w LibreNMS

Silnik alarmów w LibreNMS pozwala na definiowanie precyzyjnych reguł logicznych opartych na dowolnych zmiennych zapisanych w relacyjnej bazie danych.

  • Architektura reguł logicznych: Definiowanie warunków w oparciu o tabele bazy danych (np. `ports.ifOperStatus = 'down' AND ports.ifAdminStatus = 'up'`)
  • Makra systemowe (%macros): Wbudowane skróty logiczne ułatwiające konfigurację (np. `%macros.device_down`, `%macros.port_down`, `%macros.packet_loss`)
  • Kanały transportowe (Transports): Możliwość powiązania reguły z dedykowanymi kanałami: webhooki do Slack/Teams, bramki SMS, serwery SMTP, integracja z PagerDuty
  • Szablony wiadomości (Templates): Pełna personalizacja treści powiadomień za pomocą silnika szablonów z dynamicznymi zmiennymi urządzenia i portu
Ochrona przed zmęczeniem alarmami (Alert Fatigue): Zastosowanie parametru Delay (np. 5 minut) zapobiega wysyłaniu powiadomień w przypadku krótkich, automatycznie restartujących się procesów lub chwilowego fluktuowania łącza.
Silnik alarmów LibreNMS Architektura silnika alarmów i przepływ powiadomień 1. Reguła Alertu • Logika SQL / ORM • Progi metryk • Filtry urządzeń Zdefiniowana reguła 2. Ewaluacja • alerts.php • Badanie próbek • Stan: ALERTING Weryfikacja opóźnień 3. Szablon • Alert Template • Tytuł incydentu • Link do panelu Formatowanie treści 4. Transport • Alert Transports • Slack / Teams • E-mail / Webhook Dostarczenie do NOC Zaawansowane mechanizmy kontroli szumu alarmowego • Makra alertowe (%macros.port_down): Gotowe zestawy warunków uwzględniające stan administracyjny. • Opóźnienie alertu (Delay): Wysyłka powiadomienia dopiero po trwaniu awarii przez określony czas (np. > 3 minuty). • Eskalacja (Interval): Ponawianie notyfikacji co zadany interwał czasu, jeśli awaria nie została potwierdzona (Ack). Zapewnia eliminację fałszywych alarmów wynikających z krótkotrwałych fluktuacji transmisyjnych.
Slajd 15/55
Konfiguracja reguły alarmowej krok po kroku
Cel slajdu: Przećwiczenie procedury tworzenia zaawansowanej reguły alarmowej filtrującej stany portów na podstawie ich opisów i priorytetu.

Telemetria i alerty w LibreNMS

Praktyczny przykład konfiguracji reguły alarmowej wykrywającej awarię kluczowych łączy magistralnych z wykluczeniem portów dostępowych użytkowników.

  • Analiza warunków logicznych: Połączenie warunków `ifOperStatus = down` ze statusem administracyjnym `ifAdminStatus = up` w celu ignorowania portów wyłączonych planowo
  • Filtracja po etykietach (ifAlias): Zastosowanie klauzuli `ports.ifAlias LIKE '%UPLINK%'` ogranicza alert wyłącznie do łączy szkieletowych, pomijając stacje robocze
  • Warunek aktywności węzła: Dodanie warunku `macros.device_up = 1` zapobiega generowaniu lawiny alertów portowych, gdy całe urządzenie ulegnie wyłączeniu
  • Przypisanie transportu powiadomień: Wybór docelowej grupy odbiorców w komunikatorze Slack/Mattermost oraz określenie czasu ponawiania powiadomień
Standaryzacja opisów portów: Warunkiem poprawnego działania inteligentnego alertowania jest dyscyplina w opisywaniu portów (ifAlias) na przełącznikach (np. prefiksy: UPLINK:, SRV:, CLIENT:).
Konfiguracja reguły krok po kroku Tworzenie reguły: Port DOWN na łączu magistralnym (Trunk) # 1. Definicja reguły w kreatorze Alert Rule Builder ports.ifOperStatus = "down" AND ports.ifAdminStatus = "up" AND ports.ifAlias LIKE "%UPLINK%" AND macros.device_up = 1 Wynik: Alert wyzwoli się TYLKO gdy port z opisem UPLINK padnie na żywym węźle Parametry wykonawcze reguły alarmowej • Severity (Priorytet): Określenie wagi incydentu: Critical (Czerwony), Warning (Żółty), Ok (Zielony). • Max alerts (Limit powtórzeń): Maksymalna liczba powiadomień (np. 3), aby zapobiec spamowaniu skrzynki. • Delay (Opóźnienie): 60 sekund – zabezpieczenie przed fałszywym alertem przy restarcie portu przez STP. • Transports: Przypisanie dedykowanego kanału Slack #noc-critical oraz powiadomienia e-mail. Zapewnia natychmiastową reakcję inżynierów wyłącznie na awarie infrastruktury krytycznej.
Slajd 16/55
Mapy sieci i integracja z Weathermap
Cel slajdu: Przedstawienie metod graficznej prezentacji topologii sieci oraz integracji z wtyczką Network Weathermap do wizualizacji obciążenia pasma.

Telemetria i alerty w LibreNMS

Wizualizacja topologii pozwala operatorom na błyskawiczne zrozumienie architektury połączeń oraz natychmiastowe zlokalizowanie nasyconych łączy transmisyjnych.

  • Automatyczna mapa topologii: Dynamiczny graf powiązań generowany na bieżąco z danych protokołów LLDP/CDP za pomocą biblioteki Vis.js
  • Wtyczka Network Weathermap: Kultowe rozszerzenie umożliwiające tworzenie statycznych podkładów geograficznych lub schematów blokowych z dynamicznymi łączami
  • Kolorowanie łączy nasyceniem: Przekształcenie procentowego obciążenia interfejsu na kolor linii (zielony dla małego ruchu, pomarańczowy >70%, czerwony >85%)
  • Ekrany NOC (Wallboard): Możliwość wyświetlenia mapy Weathermap w trybie pełnoekranowym na ścianach wideo w centrach operacji sieciowych
Wtyczka Weathermap: Oficjalne repozytorium wtyczki dla LibreNMS: github.com/librenms-plugins/Weathermap. Instalacja sprowadza się do sklonowania kodu do katalogu html/plugins/ i aktywacji w panelu.
Mapy sieci i Weathermap Wizualizacja topologii i nasycenia pasma na mapach sieci Automatyczna mapa L2 / L3 • Rysowana automatycznie z LLDP/CDP • Biblioteka wizualizacji Vis.js • Dynamiczny układ siatkowy Zawsze aktualna bez pracy ręcznej Wtyczka Network Weathermap • Ręcznie projektowany schemat WAN • Kolorowanie łączy obciążeniem % • Skala: zielony -> żółty -> czerwony Idealna na telebimy w NOC Skala kolorystyczna obciążenia łączy w Weathermap 0 - 25% 25 - 50% 50 - 70% 70 - 85% > 85% AWARIA • Grubość i kolor linii transmisyjnych aktualizują się w każdym cyklu pollerowym (co 5 minut). Pozwala operatorom NOC na identyfikację zatorów transmisyjnych w ułamku sekundy.
Slajd 17/55
Interfejs programistyczny API REST w LibreNMS
Cel slajdu: Przedstawienie możliwości integracyjnych platformy LibreNMS z wykorzystaniem protokołu HTTP i interfejsu API REST.

Telemetria i alerty w LibreNMS

LibreNMS udostępnia w pełni funkcjonalny interfejs API REST, pozwalający na programistyczne zarządzanie całą platformą.

  • Uwierzytelnianie tokenem: Dostęp do zasobów zabezpieczony nagłówkiem HTTP `X-Auth-Token`, generowanym w panelu użytkownika
  • Kompletny zestaw punktów końcowych (Endpoints): Zarządzanie urządzeniami (`/api/v0/devices`), portami (`/api/v0/ports`), alertami (`/api/v0/alerts`) oraz historią zdarzeń
  • Automatyzacja provisioningu: Automatyczne dodawanie i usuwanie maszyn wirtualnych oraz kontenerów z poziomu systemów orkiestracji (Ansible, Terraform, CI/CD)
  • Eksport danych do systemów analitycznych: Pobieranie surowych metryk i list urządzeń do zewnętrznych jezior danych (Data Lakes) lub baz CMDB
Pobranie wykresu w formacie PNG: Endpoint /api/v0/devices/:id/graphs/bits umożliwia wygenerowanie i pobranie wykresu w postaci binarnego pliku graficznego, gotowego do wklejenia do automatycznego raportu SLA.
API REST w LibreNMS Architektura programowalnego API REST w LibreNMS Metody HTTP • GET: Odczyt danych • POST: Dodawanie węzłów • PATCH: Zmiana parametrów • DELETE: Usuwanie Autoryzacja Tokenem • Nagłówek HTTP: X-Auth-Token: <key> • Generowanie w GUI Kontrola uprawnień Format JSON • {"status": "ok"} • Parsowanie w Python • Integracja z Ansible Standard Network DevOps # Pobranie listy urządzeń ze statusem błędu (DOWN) przez cURL $ curl -s -H 'X-Auth-Token: 3a9f1b2c4d5e...' \ https://nms.firma.pl/api/v0/devices?order=status%20desc # Odpowiedź w formacie JSON: {"status":"ok","devices":[{"device_id":12,"hostname":"sw-acc03.lan","status":false}]} # Dokumentacja oficjalna: https://docs.librenms.org/API/
Slajd 18/55
Obsługa pułapek SNMP Traps w LibreNMS
Cel slajdu: Przedstawienie architektury odbioru i parsowania pułapek SNMP w LibreNMS oraz korelacji zdarzeń asynchronicznych z bazą NMS.

Telemetria i alerty w LibreNMS

Domyślnie LibreNMS działa w modelu odpytywania cyklicznego. Włączenie modułu SNMP Traps pozwala na natychmiastową reakcję na zdarzenia awaryjne.

  • Architektura odbioru pułapek: Demon systemowy `snmptrapd` nasłuchuje na porcie UDP 162 i przekazuje odebrane pakiety do skryptu `/opt/librenms/snmptrap.php`
  • Identyfikacja nadawcy w bazie: Skrypt sprawdza adres IP nadawcy pułapki i automatycznie przypisuje zdarzenie do odpowiedniego urządzenia (`device_id`)
  • Zapis w dzienniku zdarzeń (Eventlog): Pakiety pułapek są parsowane, a ich zawartość (`VarBindList`) trafia w czytelnej formie do rejestru zdarzeń węzła
  • Wyzwalanie natychmiastowych alertów: Możliwość zdefiniowania reguły alarmowej reagującej na konkretny typ odebranego trapa (np. awaria zasilacza w przełączniku)
Optymalizacja traphandle: W przypadku sieci generującej tysiące pułapek na minutę, uruchamianie nowego procesu PHP dla każdej pułapki stanowi duże obciążenie. LibreNMS wspiera alternatywny demon nasłuchujący napisany w Pythonie.
Obsługa pułapek SNMP Integracja demona snmptrapd z bazą zdarzeń LibreNMS Urządzenie Sieciowe • Zdarzenie fizyczne L1 • linkDown / BGP flap • Nadanie pakietu Trap Port UDP 162 Demon snmptrapd • Nasłuch na UDP 162 • snmptrapd.conf • traphandle default Przekazanie do Pythona Skrypt snmptrap.php • Identyfikacja device_id • Parsowanie OID błędu • Zapis do tabeli eventlog Wyzwolenie alertu # Konfiguracja /etc/snmp/snmptrapd.conf dla LibreNMS authCommunity log,execute,net public traphandle default /opt/librenms/snmptrap.php # Weryfikacja w Web UI (Overview -> Eventlog) lub zapytaniem SQL: $ mariadb -u librenms -p librenms -e "SELECT datetime, message FROM eventlog ORDER BY event_id DESC LIMIT 1;" [Trap] IF-MIB::linkDown: ifIndex: 12, ifDescr: GigabitEthernet1/0/12 # Dokumentacja: https://docs.librenms.org/Extensions/SNMP-Trap-Handler/
Slajd 19/55
Centralizacja logów Syslog w LibreNMS
Cel slajdu: Przedstawienie architektury integracji strumieni dzienników zdarzeń Syslog z bazą relacyjną LibreNMS i regułami alertów.

Telemetria i alerty w LibreNMS

Zintegrowanie protokołu Syslog (RFC 5424) z systemem LibreNMS pozwala na gromadzenie komunikatów o zdarzeniach w jednym spójnym panelu operacyjnym.

  • Architektura odbioru Syslog: Demon `rsyslog` lub `syslog-ng` odbiera pakiety na porcie UDP/TCP 514 i wstrzykuje je bezpośrednio do tabeli `syslog` bazy MariaDB
  • Automatyczne mapowanie adresów: System dynamicznie wiąże adres IP nadawcy komunikatu z odpowiednim urządzeniem `device_id` zarejestrowanym w NMS
  • Korelacja z widokiem urządzenia: Dzienniki zdarzeń są widoczne bezpośrednio w dedykowanej karcie `Syslog` danego przełącznika lub routera
  • Alertowanie na podstawie wzorców Regex: Możliwość zdefiniowania reguły alarmowej wyzwalanej pojawieniem się określonej frazy (np. błąd zasilania, atak SYN flood, awaria modułu BGP)
Czyszczenie starych logów: Tabela syslog potrafi rozrastać się o miliony rekordów tygodniowo. W pliku config.php parametr $config['syslog_purge'] = 30; automatycznie usuwa wpisy starsze niż 30 dni podczas nocnego cyklu porządkowego.
Centralizacja logów Syslog Integracja strumienia Syslog z bazą zdarzeń LibreNMS Źródła Zdarzeń • Przełączniki, routery • Zapory ogniowe, serwery • Protokół RFC 5424 Port UDP/TCP 514 Kolektor Syslog • rsyslog / syslog-ng • Buforowanie w RAM • Skrypt syslog.php Filtracja strumieniowa Baza i Alerty NMS • Tabela syslog w SQL • Dopasowanie regex • Wyzwalanie powiadomień Widok w karcie węzła # Fragment konfiguracji rsyslog dla LibreNMS (/etc/rsyslog.d/30-librenms.conf) $template librenms,"INSERT INTO syslog (device_id, facility, priority, level, tag, timestamp, program, msg) \ VALUES ((SELECT device_id FROM devices WHERE hostname='%fromhost-ip%' LIMIT 1), \ '%syslogfacility%', '%syslogpriority%', '%syslogseverity%', '%syslogtag%', \ '%timereported:::date-mysql%', '%programname%', '%msg%') \ ON DUPLICATE KEY UPDATE msg='%msg%';" *.* :ommysql:127.0.0.1,librenms,librenms_user,haslo;librenms
Slajd 20/55
Zarządzanie użytkownikami i uprawnieniami (RBAC)
Cel slajdu: Przedstawienie modelu ról RBAC, mechanizmów integracji z korporacyjnymi katalogami LDAP oraz wymogów bezpieczeństwa 2FA.

Administracja i bezpieczeństwo LibreNMS

W środowiskach korporacyjnych serwer NMS zawiera poufne dane topologiczne. Niezbędna jest ścisła kontrola dostępu w oparciu o role i uwierzytelnianie wieloskładnikowe.

  • Hierarchia ról (RBAC): Trzy podstawowe poziomy: Administrator (pełne uprawnienia), Global Read (odczyt całej sieci) oraz Normal User (dostęp ograniczony do przypisanych urządzeń)
  • Integracja z Active Directory / LDAP: Możliwość centralnego logowania za pomocą poświadczeń domenowych z automatycznym mapowaniem grup bezpieczeństwa na role w NMS
  • Uwierzytelnianie dwuskładnikowe 2FA: Natywna obsługa algorytmu TOTP (RFC 6238) zabezpieczająca logowanie kodem czasowym z aplikacji mobilnej
  • Audytowalność działań (Audit Log): Śledzenie aktywności użytkowników: historia logowań, modyfikacje reguł alarmowych oraz operacje wymuszenia odkrywania
Dostęp dla klientów zewnętrznych: Rola Normal User w połączeniu z przypisaniem pojedynczego portu pozwala na udostępnienie klientowi kolokacyjnemu wglądu w wykresy jego własnego łącza bez ryzyka podejrzenia pozostałej infrastruktury.
Model uprawnień RBAC i 2FA Model uprawnień RBAC, integracja z LDAP i uwierzytelnianie 2FA Role w systemie (RBAC) • Administrator (Pełny) • Global Read (Wszyscy) • Normal User (Wybrane) Ograniczenie do grup węzłów Autentykacja SSO • Active Directory (LDAP) • RADIUS / OpenID • Mapowanie grup AD Brak lokalnych haseł Dwuetapowe 2FA • Standard TOTP (RFC 6238) • Google Authenticator • FIDO2/YubiKey przez SSO Ochrona przed przejęciem Zarządzanie dostępem wielodziałowym (Multi-Tenancy) • Dział Serwerów: Dostęp ograniczony wyłącznie do grupy urządzeń z etykietą Server. • Dział Bezpieczeństwa (SOC): Uprawnienia odczytu do zapór ogniowych i dzienników zdarzeń Syslog. • Dziennik Audytowy (Authlog): Rejestracja każdego logowania, adresu IP oraz wykonanych zmian konfiguracyjnych. Zapewnia pełną zgodność z wytycznymi ochrony danych osobowych (RODO) i normą ISO/IEC 27001.
Slajd 21/55
Konsolidacja i backup systemu LibreNMS
Cel slajdu: Opracowanie procedur tworzenia kopii zapasowych bazy danych i plików RRD oraz zarządzanie automatycznymi aktualizacjami.

Administracja i bezpieczeństwo LibreNMS

Utrata serwera NMS oznacza utratę historii telemetrycznej i konfiguracji alertów. Prawidłowy plan odzyskiwania po awarii (DRP) wymaga zabezpieczenia dwóch odrębnych zasobów.

  • Kopia bazy danych MariaDB: Wykonanie zrzutu `mysqldump` z flagą `--single-transaction`, gwarantującą spójność transakcyjną bez blokowania tabel podczas pracy
  • Archiwizacja plików baz RRDtool: Kopia katalogu `/opt/librenms/rrd` z wykorzystaniem narzędzi deduplikujących (np. Restic, BorgBackup) lub synchronizacji `rsync`
  • Zabezpieczenie pliku .env i klucza APP_KEY: Plik `.env` zawiera unikalny klucz szyfrujący; jego utrata uniemożliwia odszyfrowanie haseł urządzeń w bazie!
  • Automatyczny harmonogram daily.sh: Wbudowany mechanizm aktualizacji pobierający nowe wersje z GitHuba, wykonujący migracje schematu bazy i czyszczący stare logi
Klucz APP_KEY: W pliku /opt/librenms/.env znajduje się klucz APP_KEY. Służy on do szyfrowania haseł SNMPv3 i poświadczeń API w bazie danych. Kopia tego pliku musi być bezwzględnie przechowywana w bezpiecznym sejfie haseł.
Backup i aktualizacje LibreNMS Strategia tworzenia kopii zapasowych i aktualizacji LibreNMS 1. Kopia Bazy SQL • mysqldump librenms • Kompresja gzip / zstd • Harmonogram nocny Rozmiar: 100 MB - 2 GB 2. Kopia Plików RRD • Katalog /opt/librenms/rrd • Restic / BorgBackup • Synchronizacja rsync Deduplikacja danych 3. Aktualizacje daily.sh • Automatyczny git pull • Migracje schematu bazy • Czyszczenie logów Ciągły cykl wydań # 1. Spójny zrzut bazy danych MariaDB z kompresją $ mysqldump -u librenms -p --single-transaction librenms | gzip > /backup/librenms_$(date +%F).sql.gz # 2. Archiwizacja kluczy szyfrujących i konfiguracji środowiska $ tar -czf /backup/librenms_config_$(date +%F).tar.gz /opt/librenms/.env /opt/librenms/config.php # 3. Weryfikacja spójności po nocnej aktualizacji: $ su - librenms -c "/opt/librenms/validate.php"
Slajd 22/55
Optymalizacja wydajności: Distributed Polling
Cel slajdu: Przedstawienie architektury rozproszonego pollingu z użyciem kolejki Redis dla sieci o wielotysięcznej skali.

Administracja i bezpieczeństwo LibreNMS

Gdy liczba monitorowanych portów przekracza 20 000, pojedynczy serwer nie jest w stanie ukończyć odpytywania w zadanym oknie 5 minut. Rozwiązaniem jest klaster Distributed Poller.

  • Architektura klastrowa: Centralna baza MariaDB oraz szybka pamięciowa kolejka zadań Redis zarządzająca harmonogramem odpytywania
  • Grupy pollerów (Poller Groups): Możliwość przypisania konkretnych urządzeń do wybranych pollerów (np. poller lokalny w odległym oddziale monitorujący sieć za zaporą NAT)
  • Współdzielony magazyn RRD (rrdcached over TCP): Węzły robocze przesyłają aktualizacje pomiarów przez sieć do centralnego demona `rrdcached` lub zasobu NFS
  • Wysoka dostępność (High Availability): W przypadku awarii jednego z pollerów pozostałe węzły automatycznie przejmują jego zadania z kolejki Redis
Monitoring oddziałów za NAT: Zastosowanie Poller Groups eliminuje konieczność zestawiania skomplikowanych tuneli VPN lub przekierowywania portów UDP 161. Wystarczy postawić małą maszynę z pollerem w oddziale, która łączy się wychodząco do bazy centralnej.
Rozproszony poller LibreNMS Skalowanie horyzontalne: Architektura Distributed Poller Centralna Baza & Web • Serwer MariaDB Cluster • Kolejka Redis Sentinel • Zasób NFS / Gluster (RRD) Węzeł Poller 01 Lokalizacja: DC Warszawa Grupa: Poller Group 1 Odpytuje 500 switchy Dispatcher Python Węzeł Poller 02 Lokalizacja: DC Kraków Grupa: Poller Group 2 Odpytuje 500 switchy Dispatcher Python Węzeł Poller 03 Oddział Chmura AWS Grupa: Poller Group 3 Serwery w chmurze Dispatcher Python Skalowanie niemal liniowe: dołożenie nowego węzła pollerowego podwaja przepustowość zapytań SNMP.
Slajd 23/55
Kopie konfiguracji urządzeń – integracja z Oxidized
Cel slajdu: Przedstawienie zasad integracji LibreNMS z narzędziem Oxidized w celu automatycznego wersjonowania konfiguracji w repozytorium Git.

Administracja i bezpieczeństwo LibreNMS

Zarządzanie konfiguracją (Configuration Management) stanowi kluczowy filar modelu FCAPS. Oxidized automatyzuje pobieranie i wersjonowanie plików konfiguracyjnych.

  • Rola narzędzia Oxidized: Współczesny, napisany w języku Ruby następca klasycznego narzędzia RANCID; loguje się przez SSH i pobiera bieżący stan konfiguracji
  • Dynamiczny inwentarz z LibreNMS: Oxidized odpytuje API LibreNMS (`/api/v0/oxidized`), automatycznie pobierając listę wszystkich aktywnych przełączników i routerów
  • Wersjonowanie w systemie Git: Każda zmiana w konfiguracji jest automatycznie zapisywana jako nowy commit w lokalnym lub zdalnym repozytorium Git
  • Podgląd różnic (Diff) w panelu WWW: W karcie urządzenia w LibreNMS pojawia się zakładka `Config`, prezentująca kolorowe porównanie zmian z poprzednią wersją
Wyzwalanie natychmiastowego backupu: Gdy administrator zapisze konfigurację na Cisco (copy run start), urządzenie wysyła komunikat Syslog %SYS-5-CONFIG_I. Reguła Syslog lub alert w LibreNMS wywołuje wówczas endpoint REST API Oxidized (POST /node/next/NAZWA_WEZLA), kolejkując natychmiastowe pobranie konfiguracji w kilka sekund!
Kopie konfiguracji z Oxidized Automatyczny backup konfiguracji w Git dzięki Oxidized 1. LibreNMS (Źródło) • API: /api/v0/oxidized • Lista IP, modeli i OS • Grupy urządzeń Dynamiczny inwentarz 2. Demon Oxidized • Logowanie przez SSH/Telnet • Pobranie show running • Ukrywanie haseł secret Silnik w języku Ruby 3. Repozytorium Git • Commit po każdej zmianie • Kolorowy Diff zmian • Widok w panelu LibreNMS Pełna historia wersji Korzyści operacyjne integracji LibreNMS + Oxidized • Wyzwalanie zdarzeniowe (Event-driven backup): Log Syslog %SYS-5-CONFIG_I wyzwala REST API Oxidized (/node/next). • Wizualny Diff: Administrator widzi na czerwono usunięte linie i na zielono dodane komendy. • Brak duplikacji inwentarza: Oxidized nie posiada własnej listy urządzeń – pobiera ją dynamicznie z LibreNMS. Zapewnia realizację wymagań audytowych w zakresie zarządzania zmianą (Change Management).
Slajd 24/55
MikroTik The Dude – Wprowadzenie i geneza
Cel slajdu: Przedstawienie historii, specyfiki architektonicznej oraz roli systemu The Dude w ekosystemie urządzeń MikroTik.

System MikroTik The Dude

The Dude to wyspecjalizowany, darmowy system zarządzania siecią stworzony przez łotewską firmę MikroTik, zorientowany wokół interaktywnej mapy graficznej.

  • Geneza projektu (2006 r.): Początkowo samodzielna aplikacja na system Windows, stworzona jako bezpłatne wsparcie dla małych i średnich operatorów radiowych WISP
  • Architektura klient-serwer: Rozdział na serwer działający jako pakiet w systemie RouterOS oraz lekki pulpitowy program kliencki Win32
  • Podejście zorientowane na mapę (Map-Centric): W przeciwieństwie do tabelarycznych paneli WWW, głównym punktem pracy w The Dude jest dwuwymiarowa, wektorowa mapa sieci
  • Brak opłat licencyjnych: Pełna funkcjonalność dostępna bezpłatnie dla każdego posiadacza sprzętu MikroTik z licencją RouterOS Level 4+
Pochodzenie nazwy: Nazwa The Dude została zainspirowana kultową postacią "Kolesia" z filmu braci Coen Big Lebowski, co odzwierciedlało luźny, społecznościowy charakter wczesnych narzędzi firmy MikroTik.
Wprowadzenie do The Dude Geneza i ewolucja platformy MikroTik The Dude 2006: Początki (v3/v4) • Samodzielna aplikacja Win32 • Serwer i klient na PC • Darmowe narzędzie MikroTik Rewolucja dla małych ISP 2016: Pakiet RouterOS (v6) • Przeniesienie serwera do ROS • Pakiet dude.npk • Dedykowany sprzęt CCR/x86 Stabilność architektury Współczesność: RouterOS v7 • Wbudowany pakiet Dude • Wsparcie architektury ARM64 • Baza SQLite na dysku NVMe Specjalistyczne zastosowania Filozofia systemu The Dude: Wizualny monitoring topologii • Zorientowanie na mapę (Map-Centric): Interfejs stanowi jedną wielką, interaktywną tablicę połączeń. • Darmowa licencja: Brak jakichkolwiek opłat licencyjnych, wbudowane narzędzie w system RouterOS. • Ekosystem WISP: Niezastąpione narzędzie dla bezprzewodowych dostawców Internetu (Wireless ISP). Oficjalna dokumentacja: wiki.mikrotik.com/wiki/Manual:The_Dude_v7.
Slajd 25/55
Kluczowe możliwości systemu The Dude
Cel slajdu: Szczegółowy przegląd funkcji The Dude: tworzenie map graficznych, konfiguracja sond pomiarowych i integracja z RouterOS.

System MikroTik The Dude

The Dude łączy funkcje systemu monitoringu dostępności, kolektora metryk SNMP oraz narzędzia do orkiestracji urządzeń MikroTik.

  • Dynamiczna mapa sieci: Układ węzłów z automatycznym lub ręcznym rozmieszczeniem; kolorowanie ikon (zielony = OK, pomarańczowy = ostrzeżenie, czerwony = awaria)
  • Elastyczny system sond (Probes): Weryfikacja obecności usług w warstwach L3-L7: ICMP Ping, zapytania DNS, serwery WWW, bazy SQL oraz zaawansowane OID SNMP
  • Natywna integracja z Winbox: Możliwość otwarcia sesji konfiguracyjnej Winbox lub konsoli Terminala bezpośrednio z menu kontekstowego urządzenia na mapie
  • Agregacja łączy i wskaźniki na mapie: Wyświetlanie aktualnego transferu danych w bitach na sekundę oraz nasycenia procentowego bezpośrednio na liniach łączących węzły
Szybki interwał próbkowania: Podczas gdy LibreNMS standardowo odpytuje metryki co 5 minut, The Dude pozwala na badanie sond dostępności (Ping/HTTP) z częstotliwością co 10 sekund, reagując na awarie niemal natychmiast.
Możliwości The Dude Główne funkcje i mechanizmy operacyjne The Dude Interaktywna Mapa • Układ Drag & Drop • Zmiana kolorów węzłów • Etykiety z ruchem bps Zielony -> Żółty -> Czerwony Sondy (Probes) • Ping, DNS, HTTP, TCP • Własne zapytania SNMP • Formuły matematyczne Weryfikacja usług L3-L7 Integracja Winbox • Kliknij i otwórz Winbox • Masowe aktualizacje ROS • Dostęp przez tunel Dude Zarządzanie urządzeniami Specyfika sondowania i reakcji w The Dude • Wielousługowość na węzeł: Do jednego urządzenia można przypisać wiele sond (np. Ping + HTTP + BGP). • Stan częściowej awarii (Partially Down): Gdy padnie HTTP, ale działa Ping, węzeł staje się pomarańczowy. • Szybkie interwały: Możliwość odpytywania krytycznych parametrów co 5-10 sekund bez narzutu webowego. Zapewnia intuicyjną kontrolę nad stanem fizycznym i logicznym sieci.
Slajd 26/55
Instalacja serwera The Dude na MikroTik RouterOS
Cel slajdu: Przedstawienie procedury instalacji pakietu serwerowego The Dude na platformie RouterOS ze szczególnym uwzględnieniem ochrony nośników pamięci.

System MikroTik The Dude

Serwer The Dude działa jako moduł wbudowany w system operacyjny MikroTik RouterOS na wybranych architekturach procesorów.

  • Wymagania sprzętowe platformy: Wspierane architektury: x86/CHR, ARM, ARM64, mmips oraz TILE (seria CCR); brak wsparcia dla słabych procesorów MIPSBE
  • Instalacja pakietu dude.npk: Pobranie archiwum 'Extra packages' ze strony MikroTik, wgranie pliku `dude.npk` do pamięci routera i restart urządzenia
  • Lokalizacja bazy danych (data-directory): Kluczowa konfiguracja dyrektywy `data-directory` wskazującej na zewnętrzny nośnik USB, kartę microSD lub dysk SSD
  • Ochrona pamięci wbudowanej NAND: Zapisywanie bazy SQLite The Dude na wbudowanej pamięci Flash urządzenia prowadzi do jej przedwczesnego zużycia w ciągu kilku miesięcy!
Zużycie pamięci Flash NAND: Ciągły zapis próbek i zdarzeń do bazy SQLite generuje miliony cykli zapisu. Instalacja serwera The Dude na wbudowanej pamięci NAND routera powoduje jej bezpowrotne uszkodzenie i utratę gwarancji! Niezbędny jest dysk zewnętrzny.
Wdrożenie serwera The Dude Wdrożenie serwera The Dude w systemie RouterOS 1. Platforma sprzętowa • MikroTik CCR (ARM64/TILE) • Cloud Hosted Router (CHR) • Wykluczone: MIPSBE Zalecane RAM > 1 GB 2. Pakiet dude.npk • Pobranie ze strony mikrotik • Wgranie do Files w ROS • Restart /system reboot Automatyczna instalacja 3. Aktywacja i Storage • /dude set enabled=yes • data-directory na dysk USB • Port TCP 8291 (jak Winbox) Ochrona pamięci Flash NAND # Konfiguracja serwera The Dude z poziomu terminala RouterOS [admin@MikroTik-CCR] > /disk print # Weryfikacja podłączonego dysku SSD Flags: B - block-device; M - mounted 0 BM disk1 usb-drive-3.0 120GiB # Wskazanie ścieżki bazy na dysk zewnętrzny i uruchomienie serwera: [admin@MikroTik-CCR] > /dude set data-directory=disk1/dude-data enabled=yes [admin@MikroTik-CCR] > /dude print # Status: enabled: yes, status: running
Slajd 27/55
Klient The Dude – Aplikacja desktopowa Windows
Cel slajdu: Przedstawienie architektury klienta The Dude, ergonomii pracy w dedykowanej aplikacji okienkowej oraz metod uruchamiania w systemach Linux.

System MikroTik The Dude

Podczas gdy większość współczesnych systemów NMS korzysta z przeglądarki WWW, The Dude opiera się na natywnej aplikacji desktopowej Win32.

  • Ergonomia aplikacji desktopowej: Błyskawiczne skalowanie mapy kółkiem myszy (Zoom), przesuwanie widoku bez przeładowywania stron i obsługa wielu okien jednoczesnych
  • Połączenie z serwerem (Port TCP 8291): Klient łączy się z serwerem RouterOS przez szyfrowany protokół binarny, minimalizując zużycie pasma sieciowego
  • Uruchamianie w środowisku Linux (Wine): Aplikacja Win32 doskonale współpracuje z warstwą zgodności Wine w systemach Ubuntu, Debian i Fedora, nie wykazując żadnych błędów
  • Tryb pracy Local vs Remote: Możliwość połączenia ze zdalnym serwerem RouterOS CHR lub uruchomienia klienta w trybie lokalnego nasłuchu na stacji PC
Stabilność pod Wine: Doświadczeni administratorzy systemów Linux uznają The Dude za jedną z najlepiej działających aplikacji windowsowych pod emulatorem Wine. Działa stabilnie przez miesiące bez wycieków pamięci.
Klient desktopowy The Dude Aplikacja kliencka The Dude Win32 i uruchamianie w Linux (Wine) Natywny Klient Win32 • Ekstremalna szybkość • Płynny zoom i pan mapy • Brak narzutu przeglądarki Plik: dude-install.exe Emulacja Wine (Linux) • wine dude.exe • 100% stabilności • Działa na Debian/Ubuntu Stacje robocze NOC Protokół Zarządzania • Port TCP 8291 (jak Winbox) • Szyfrowanie sesji TLS • Tryb Local lub Remote Bezpieczna transmisja # Uruchomienie klienta The Dude na stacji z systemem Linux przez Wine $ sudo apt-get install wine-stable $ wine ~/.wine/drive_c/Program\ Files/Dude/dude.exe & # Parametry połączenia w oknie Connect: Server: 192.168.88.1:8291 | User: admin | Pass: ******** | Mode: Secure # Klient pobiera dane w binarnym protokole MikroTik, zapewniając zero opóźnień.
Slajd 28/55
Projektowanie interaktywnej mapy sieci w The Dude
Cel slajdu: Przedstawienie procedury budowy wielopoziomowej mapy topologicznej w The Dude, personalizacji etykiet i wizualizacji parametrów łączy.

System MikroTik The Dude

Projektowanie mapy w The Dude przypomina tworzenie schematu w programie CAD, oferując pełną swobodę w aranżacji graficznej infrastruktury.

  • Import podkładów graficznych: Możliwość wgrania planów budynków, map pięter, schematów szaf RACK lub map geograficznych w formacie PNG/JPG
  • Dynamiczne etykiety węzłów: Wzbogacanie opisu urządzenia o zmienne systemowe: `[Device.Name]`, `[Device.Uptime]` oraz funkcję `oid()` odpytującą dowolne MIB
  • Wizualizacja łączy transmisyjnych: Przypisywanie łączom konkretnych interfejsów sieciowych; The Dude na bieżąco wyświetla ruch i zmienia grubość linii
  • Hierarchia map podrzędnych (Submaps): Możliwość tworzenia podmap (np. ikona 'Oddział Poznań' otwierająca osobną szczegółową mapę przełączników w tym mieście)
Wizualizacja linków radiowych: Na liniach łączących punkty dostępowe Wi-Fi w The Dude można wyświetlać siłę sygnału RSSI w dBm oraz jakość połączenia CCQ, co czyni go niezastąpionym w sieciach bezprzewodowych.
Projektowanie mapy w The Dude Tworzenie i personalizacja mapy topologicznej w The Dude 1. Podkład Graficzny • Rzuty budynków (PNG/JPG) • Mapy OpenStreetMap • Wymiary w skali Warstwy tła (Layers) 2. Węzły (Devices) • Ikony routerów, switchy • Etykieta: [Device.Name] • Etykieta: [Device.ServicesDown] Dynamiczny tekst 3. Łącza (Links) • Typ: Ethernet / Radio • Kolorowanie nasyceniem • Etykieta: [Interface.InBitRate] Bieżący ruch na żywo Zaawansowane formatowanie etykiet węzła w The Dude [Device.Name] ([Device.FirstAddress]) Uptime: [Device.Uptime] CPU: [oid("1.3.6.1.4.1.9.9.109.1.1.1.1.5.1")]% | Temp: [oid("1.3.6.1.4.1.14988.1.1.3.11.0")]C Awaria: [Device.ServicesDown] z [Device.ServicesCount] usług Funkcja oid() pozwala na wstrzyknięcie dowolnej wartości SNMP bezpośrednio do etykiety na mapie.
Slajd 29/55
Sondy usługowe (Probes) w The Dude
Cel slajdu: Zrozumienie mechanizmu sondowania usług (Probes), badania kodów błędów oraz programowania autorskich sond SNMP w The Dude.

System MikroTik The Dude

Sonda (Probe) to podstawowa jednostka monitoringu w The Dude, weryfikująca poprawność działania konkretnej usługi lub parametru sprzętowego.

  • Standardowe sondy sieciowe: ICMP ping (z pomiarem RTT i strat pakietów), arp-ping (do badania urządzeń w tej samej podsieci ignorujących ping) oraz DNS
  • Sondy aplikacyjne (L7): Weryfikacja odpowiedzi serwerów HTTP/HTTPS (oczekiwany kod 200 OK lub konkretna fraza HTML) oraz testy nawiązywania sesji TCP
  • Autorskie sondy SNMP: Możliwość zdefiniowania własnej sondy odpytującej dowolny numer OID z baz MIB z warunkiem logicznym oceniającym poprawność
  • Formatowanie komunikatów błędów: Definiowanie dynamicznego tekstu błędu (Error String) wyświetlanego na dymku podpowiedzi nad ikoną węzła na mapie
Sonda arp-ping: Wiele nowoczesnych zapór sieciowych i stacji Windows domyślnie blokuje zapytania ICMP Echo Request. Sonda arp-ping bada odpowiedź warstwy łącza danych (L2), potwierdzając fizyczną obecność urządzenia w sieci.
Sondy pomiarowe w The Dude Typy sond diagnostycznych i tworzenie własnych sond SNMP Sondy Sieciowe • ping: RTT i packet loss • arp-ping: Obejście ACL • dns: Rozwiązywanie nazw Warstwy L2 i L3 Sondy Usługowe L7 • http / https: Kod 200 OK • tcp-service: Port connect • pop3, smtp, ssh, telnet Dostępność demonów Sondy SNMP (Custom) • Typ: SNMP • Odczyt OID węzła • Warunek logiczny błędu Własne parametry MIB # Przykład definicji własnej sondy SNMP: Temperatura procesora > 70 C Name: Sonda_CPU_Temp_Alert Type: SNMP | SNMP OID: 1.3.6.1.4.1.14988.1.1.3.11.0 OID Type: Integer | Function: compare Error condition: oid("1.3.6.1.4.1.14988.1.1.3.11.0") > 70 Error text: "Przegrzanie procesora routera! Temperatura: " . oid(...) . " C" # W momencie przekroczenia 70 C sonda zmienia stan na DOWN i wyzwala alert.
Slajd 30/55
System powiadomień i powiązań w The Dude
Cel slajdu: Przedstawienie wielokanałowego systemu alarmowania w The Dude oraz integracji z autonomicznymi skryptami RouterOS.

System MikroTik The Dude

The Dude posiada wbudowany podsystem powiadomień (Notifications), pozwalający na informowanie administratorów oraz wyzwalanie automatycznych procedur naprawczych.

  • Lokalne alerty w dyspozytorni: Wyświetlanie okien wyskakujących (Pop-up), odtwarzanie plików dźwiękowych WAV na głośnikach w NOC oraz mruganie paska zadań
  • Powiadomienia zdalne (E-mail i SMS): Wysyłka sformatowanych wiadomości pocztowych oraz obsługa komend SMS wysyłanych przez podłączony do routera modem LTE
  • Wykonywanie skryptów RouterOS: Unikalna możliwość uruchomienia lokalnego skryptu w systemie RouterOS w momencie przejścia sondy w stan DOWN
  • Automatyczna samonaprawa (Self-Healing): Automatyczny 'twardy' restart zasilania PoE dla zawieszonego punktu dostępowego Wi-Fi lub kamery IP bez udziału człowieka
Automatyzacja PoE: Skrypt restartujący zasilanie PoE w przypadku braku odpowiedzi na ping rozwiązuje ponad 85% problemów z zawieszonym sprzętem brzegowym w sieciach operatorskich.
System powiadomień w The Dude Wielokanałowe powiadomienia i automatyzacja reakcji w The Dude Dyspozytornia NOC • Popup w aplikacji Win32 • Dźwięk alarmu (WAV/BEEP) • Mruganie ikony na mapie Reakcja natychmiastowa Powiadomienia Zdalne • Poczta E-mail (SMTP) • Bramka SMS (modem LTE) • Telegram bot przez URL Dostępność 24/7 Autonomiczna Akcja • Skrypt w RouterOS • Restart portu PoE • Przełączenie trasy BGP Samonaprawa (Self-Healing) # Przykład akcji RouterOS wyzwalanej w chwili awarii kamery IP: /system script add name=Restart_PoE_Kamera source={ :log error "Kamera IP nie odpowiada! Restart zasilania PoE na ether5..."; /interface ethernet poe set ether5 poe-out=off; :delay 5s; /interface ethernet poe set ether5 poe-out=auto-on; }
Slajd 31/55
Natywna integracja The Dude z ekosystemem MikroTik
Cel slajdu: Przedstawienie zaawansowanych funkcji orkiestracji urządzeń RouterOS bezpośrednio z poziomu panelu The Dude.

System MikroTik The Dude

The Dude nie jest wyłącznie pasywnym systemem NMS – stanowi zintegrowaną platformę zarządzania całą flotą urządzeń MikroTik.

  • Uruchamianie Winbox jednym kliknięciem: Możliwość natychmiastowego otwarcia programu konfiguracyjnego Winbox z automatycznym przekazaniem poświadczeń i adresu IP
  • Masowe aktualizacje RouterOS (Mass Upgrade): Moduł umożliwiający jednoczesne pobranie i wdrożenie nowych wersji oprogramowania na setkach routerów i przełączników
  • Automatyczny harmonogram kopii zapasowych: Pobieranie plików `.backup` (zrzut binarny) oraz `.rsc` (skrypt tekstowy) i składowanie ich w centralnym magazynie
  • Tunelowanie przez serwer Dude: Możliwość łączenia się z urządzeniami znajdującymi się w prywatnych podsieciach za pośrednictwem bezpiecznego tunelu serwera Dude
Kopia eksportu tekstowego: Kopia binarna .backup może być przywrócona tylko na identycznym modelu urządzenia. Dlatego zawsze należy pobierać również eksport tekstowy /export file=backup.rsc, który można wdrożyć na dowolnym innym sprzęcie.
Integracja z ekosystemem MikroTik Synergia z ekosystemem RouterOS: Winbox, Upgrade i Backupy 1-Click Winbox • Klik prawym na węzeł • Opcja: Winbox • Automatyczne logowanie Natychmiastowy dostęp Masowy Upgrade • Menu: RouterOS Upgrade • Pobranie wersji z WWW • Wgranie do 50 hostów Jednoczesny restart Centralny Backup • Pliki binarne .backup • Skrypty tekstowe .rsc • Harmonogram cykliczny Bezpieczeństwo danych Zarządzanie siecią MikroTik bez wpisywania haseł • Tunelowanie Dude (Dude Relay): Dostęp do urządzeń z prywatną adresacją za pośrednictwem serwera Dude. • Weryfikacja licencji i firmware: Automatyczna kontrola wersji RouterBOOT (BIOS) na płytach RouterBOARD. • Szybki Terminal: Bezpośrednie otwarcie bezpiecznej konsoli SSH/Mac-Telnet z poziomu mapy. Sprawia, że The Dude jest nie tylko monitorem, lecz głównym centrum zarządzania siecią MikroTik.
Slajd 32/55
Wykresy i zbieranie metryk w The Dude
Cel slajdu: Przedstawienie architektury bazy danych SQLite, mechanizmów rysowania wykresów oraz procedur konserwacji bazy w The Dude.

System MikroTik The Dude

The Dude gromadzi dane telemetryczne we wbudowanej bazie SQLite, generując wektorowe wykresy wydajności bezpośrednio w oknie klienta.

  • Format składowania SQLite: Cała konfiguracja map, lista urządzeń oraz historia próbek przechowywana jest w pojedynczym pliku bazodanowym `dude.db`
  • Wykresy czasu rzeczywistego: Prezentacja przepustowości łączy, czasów odpowiedzi ICMP Ping oraz procentowej dostępności usług w horyzontach czasowych
  • Polityka retencji danych: Automatyczna agregacja szczegółowych próbek (z 10 sekund do średnich godzinnych i dobowych) w celu optymalizacji rozmiaru bazy
  • Konserwacja bazy (vacuum-db): Polecenie `/dude vacuum-db` wykonujące defragmentację bazy SQLite i odzyskujące wolną przestrzeń dyskową
Eksport bazy do formatu XML: Funkcja /dude export umożliwia wyeksportowanie całej struktury map i urządzeń do czytelnego pliku XML, co pozwala na automatyczną migrację pomiędzy serwerami.
Wykresy i baza SQLite w The Dude Magazyn bazy danych SQLite i generowanie wykresów w The Dude Baza SQLite • Pojedynczy plik dude.db • Brak zewnętrznego SQL • Bardzo mały narzut Lokalizacja na dysku SSD Typy Wykresów • Ruch sieciowy (bps) • Czas odpowiedzi Ping RTT • Dostępność usługi (%) Wartości min/avg/max Retencja Danych • Próbki 10-sekundowe • Agregacja godzinna • Retencja do 1 roku Automatyczne czyszczenie Zarządzanie bazą danych The Dude z poziomu terminala [admin@MikroTik] > /dude export-db file=backup_dude.db # Eksport bazy danych [admin@MikroTik] > /dude import-db file=backup_dude.db # Odtworzenie bazy [admin@MikroTik] > /dude vacuum-db # Kompresja i defragmentacja SQLite Polecenie vacuum-db odzyskuje przestrzeń dyskową po usunięciu nieużywanych urządzeń.
Slajd 33/55
Ograniczenia i status projektu The Dude
Cel slajdu: Krytyczna ocena słabych stron i barier skalowalności systemu The Dude w zestawieniu ze współczesnymi wymogami Enterprise.

System MikroTik The Dude

Mimo ogromnych zalet wizualnych, The Dude posiada istotne ograniczenia technologiczne wynikające z jego monolitycznej historii.

  • Brak nowoczesnego interfejsu Web GUI: Dostępny interfejs przeglądarkowy jest przestarzały i pozbawiony większości funkcji; pełna praca wymaga klienta desktopowego Win32
  • Ograniczenia bazy SQLite (Brak rozproszenia): Format SQLite blokuje bazę przy jednoczesnych zapisach, co uniemożliwia budowę klastrów rozproszonych i monitorowanie powyżej 1000 węzłów
  • Słabe wsparcie dla urządzeń innych marek: O ile sprzęt MikroTik jest obsługiwany perfekcyjnie, o tyle dla przełączników Cisco, Juniper czy HP konieczne jest ręczne definiowanie sond MIB
  • Status projektu w firmie MikroTik: The Dude jest traktowany jako darmowy dodatek do RouterOS; rozwój nowych funkcji jest bardzo powolny, a platforma nie posiada API REST
Blokada skalowania SQLite: W sieciach powyżej 500 urządzeń baza SQLite w The Dude zaczyna cierpieć na zatory transakcyjne, co objawia się zamrażaniem interfejsu graficznego i gubieniem próbek pomiarowych.
Ograniczenia The Dude Ograniczenia architektoniczne i współczesny status The Dude Brak Web GUI • Archaiczny web interfejs • Brak responsywności • Uzależnienie od Win32 Problem na macOS/mobilnych Limit Skalowalności • Baza SQLite blokuje zapis • Pojedynczy proces serwera • Spowolnienia przy >500 hostach Brak distributed pollingu Status Projektu • Charakter poboczny (Legacy) • Rzadkie aktualizacje funkcji • Brak oficjalnego API REST Brak integracji NetDevOps Diagnoza inżynierska: Kiedy The Dude, a kiedy LibreNMS? • Zastosowanie The Dude: Małe i średnie sieci oparte w 80%+ na sprzęcie MikroTik, gdzie priorytetem jest mapa 2D. • Ograniczenie The Dude: W dużych sieciach kampusowych z tysiącami portów i sprzętem Cisco/HP The Dude nie ma szans. • Rekomendacja Enterprise: Wdrożenie LibreNMS jako systemu centralnego i ewentualne użycie The Dude jako mapy pomocniczej. Zrozumienie tych limitów chroni firmę przed kosztownymi błędami wdrożeniowymi.
Slajd 34/55
Porównanie bezpośrednie: LibreNMS vs The Dude
Cel slajdu: Zestawienie analityczne cech, wydajności i przeznaczenia systemów LibreNMS i The Dude w ujęciu macierzy wielokryterialnej.

Porównanie i alternatywy na rynku NMS

Wybór między LibreNMS a The Dude to klasyczny dylemat inżynierski: uniwersalna platforma korporacyjna kontra wyspecjalizowane narzędzie producenta.

  • Architektura i Dostępność: LibreNMS: uniwersalny interfejs webowy dostępny na dowolnym urządzeniu vs The Dude: aplikacja Win32 wymagająca Wine na Linuksie
  • Zdolność do skalowania: LibreNMS radzi sobie z setkami tysięcy portów dzięki klastrom Redis i MariaDB; The Dude napotyka barierę wydajności bazy SQLite przy kilkuset węzłach
  • Wsparcie dla środowisk mieszanych: LibreNMS natywnie wspiera >3500 producentów sprzętu bez konfiguracji; The Dude wymaga ręcznego definiowania sond SNMP dla urządzeń firm trzecich
  • Ergonomia prezentacji topologii: The Dude oferuje bezkonkurencyjną, interaktywną mapę sieci z płynnym zoomem, podczas gdy w LibreNMS wymaga to wtyczki Weathermap
Model Koegzystencji: W wielu firmach oba systemy działają równolegle: LibreNMS zbiera długoterminowe metryki, wysyła alerty i zarządza backupami, a The Dude wisi na ekranie dyspozytorskim jako dynamiczna mapa stanu łączy.
Porównanie LibreNMS vs The Dude Macierz porównawcza: LibreNMS vs MikroTik The Dude Kryterium porównawcze LibreNMS MikroTik The Dude Model licencyjny Open Source (GNU GPLv3) Freeware (Wymaga RouterOS) Interfejs użytkownika Web HTML5 / Responsive / API Aplikacja desktop Win32 (Wine) Skalowalność > 100 000 portów (Distributed) Do 500 węzłów (Single SQLite) Heterogeniczność > 3500 producentów (Auto MIB) Głównie MikroTik (SNMP manual) Wizualizacja mapy Automatyczna Vis.js / Weathermap Wektorowa Drag-and-Drop (Genialna) Zarządzanie urządzeniem Kopie Git (Oxidized) 1-Click Winbox, Mass Upgrade ROS Interfejs API / DevOps Pełne REST API JSON / Tokeny Brak publicznego API REST Wniosek: LibreNMS wygrywa w skali i uniwersalności, The Dude w ergonomii mapy dla sieci MikroTik.
Slajd 35/55
Porównanie: LibreNMS vs Zabbix
Cel slajdu: Analiza różnic filozoficznych i architektonicznych pomiędzy podejściem wyspecjalizowanym w SNMP a uniwersalnym systemem agentowym Zabbix.

Porównanie i alternatywy na rynku NMS

Zarówno LibreNMS, jak i Zabbix należą do czołówki otwartoźródłowych systemów monitoringu, jednak reprezentują diametralnie różne podejścia do konfiguracji.

  • Podejście Zero-Config (LibreNMS): System stworzony z myślą o sieciowcach; po wykryciu urządzenia sam wie, jakie OID odpytać, jak narysować wykres i jakie alerty ustawić
  • Podejście modułowe i szablony (Zabbix): Uniwersalny silnik oparty na szablonach (Templates) i regułach niskopoziomowego wykrywania (LLD), wymagający ręcznego dopasowywania metryk
  • Architektura agentowa: Zabbix oferuje potężnego agenta programowego instalowanego na systemach operacyjnych (Linux/Windows), co umożliwia głęboki monitoring procesów i baz danych
  • Silnik bazy danych: LibreNMS rozdziela dane na MariaDB i pliki RRDtool; Zabbix składuje wszystkie surowe próbki w relacyjnej bazie SQL (często z rozszerzeniem TimescaleDB)
Kiedy wybrać Zabbixa? Jeśli 80% Twojej infrastruktury to serwery wirtualne, kontenery Kubernetes, bazy danych PostgreSQL i aplikacje webowe, a przełączniki sieciowe stanowią margines – Zabbix jest lepszym wyborem.
LibreNMS vs Zabbix Dwa paradygmaty: LibreNMS (Zero-Config) vs Zabbix (Szablony i Agenty) LibreNMS: Paradygmat Sieciowy • Cel główny: Przełączniki, routery, SNMP • Wdrożenie: Natychmiastowe (Auto-discovery) • Szablony: Zbędne (wbudowane bazy YAML) • Baza danych: MariaDB + RRDtool Zaleta: Działa od razu bez nakładu pracy Zabbix: Paradygmat Uniwersalny • Cel główny: Serwery, aplikacje, bazy danych • Wdrożenie: Instalacja agentów Zabbix Agent • Szablony: Konieczne (szablony i reguły LLD) • Baza danych: PostgreSQL / TimescaleDB Wada: Ogromna pracochłonność wstępna Porównanie kosztu wdrożenia (TCO) dla 200 przełączników • LibreNMS: Wprowadzenie puli IP -> 30 minut pracy -> Pełne wykresy portów, STP, BGP i mapy. • Zabbix: Dobór szablonów, strojenie reguł LLD, walka z makrami -> Kilka dni lub tygodni pracy inżyniera. • Wniosek: Do sieci LAN/WAN bezkonkurencyjny jest LibreNMS; do serwerów i baz danych – Zabbix. Wiele korporacji integruje oba systemy w spójny ekosystem telemetryczny.
Slajd 36/55
Porównanie: LibreNMS vs Nagios / Icinga
Cel slajdu: Przedstawienie ewolucji systemów monitoringu od klasycznej architektury wtyczek procesowych Nagiosa do nowoczesnych silników telemetrycznych.

Porównanie i alternatywy na rynku NMS

Nagios stworzony w 1999 roku przez Ethana Galstada zdefiniował pojęcie monitoringu IT, jednak jego architektura nie radzi sobie ze współczesną skalą sieci.

  • Architektura procesowa (Fork/Exec): Nagios weryfikuje każdy parametr uruchamiając zewnętrzny proces powłoki (`check_ping`, `check_snmp`), co przy tysiącach portów drastycznie przeciąża procesor serwera
  • Ręczna konfiguracja plikowa: Każdy host, serwis i grupa w Nagiosie wymaga ręcznej edycji plików tekstowych `.cfg`, co całkowicie wyklucza automatyzację w dynamicznych środowiskach
  • Brak natywnych wykresów wydajności: Nagios monitoruje wyłącznie stany dyskretne (OK, WARNING, CRITICAL, UNKNOWN); generowanie wykresów wymagało zewnętrznych dodatków (np. PNP4Nagios)
  • Nowoczesny paradygmat LibreNMS: Natywna wielowątkowa obsługa zapytań SNMP GETBULK, zintegrowane bazy RRDtool i automatyczne odkrywanie zależności topologicznych
Dziedzictwo Nagiosa: Mimo archaicznej architektury kody wyjścia wtyczek Nagiosa (0 = OK, 1 = WARNING, 2 = CRITICAL, 3 = UNKNOWN) stały się niepisanym standardem inżynierskim stosowanym do dziś w setkach narzędzi telemetrycznych.
LibreNMS vs Nagios Ewolucja architektury: Klasyczny Nagios a nowoczesny LibreNMS Nagios / Icinga 1.x (1999 r.) • Architektura: Ciągły fork procesów w powłoce • Wtyczki: check_ping, check_snmp (skrypty) • Konfiguracja: Tysiące plików tekstowych .cfg • Wykresy: Brak natywnych (dodatki PNP4Nagios) Wada: Ogromny narzut CPU i brak autoodkrywania LibreNMS (Współczesny NMS) • Architektura: Natywne wątki i bufor RRDcached • Pobieranie: Zoptymalizowane GETBULK • Konfiguracja: Pełna baza SQL + GUI + API • Wykresy: Wbudowane, dynamiczne RRDtool Zaleta: Wysoka skalowalność i automatyzacja Dlaczego architektura fork/exec Nagiosa nie sprawdza się w sieciach? • Aby sprawdzić 1 000 portów, Nagios musi uruchomić 1 000 procesów systemowych check_snmp. • LibreNMS pobiera 1 000 portów za pomocą kilkudziesięciu pakietów GETBULK w jednym wątku. • Nagios był prekursorem, lecz współczesna inżynieria sieciowa wymaga zoptymalizowanej akwizycji danych. Zrozumienie tej ewolucji wyjaśnia, dlaczego tradycyjne skrypty wtyczek zostały zastąpione przez platformy NMS.
Slajd 37/55
Drzewo decyzyjne – Dobór systemu NMS do środowiska
Cel slajdu: Wyrobienie umiejętności inżynierskiej analizy potrzeb organizacji i wyboru optymalnego narzędzia NMS na podstawie kryteriów technicznych, skali i profilu infrastruktury.

Porównanie i architektura systemów

Dobór oprogramowania klasy NMS nie może opierać się na subiektywnych preferencjach, lecz na precyzyjnym audycie architektury sieci, kompetencji personelu oraz budżetu operacyjnego (TCO).

  • Kryterium heterogeniczności: Dla sieci wieloproducentowych (Cisco, HP, Juniper, Linux) optymalnym wyborem jest LibreNMS z uwagi na wbudowane mapowania OID
  • Jednolity ekosystem dostawcy: Dla operatorów WISP opartych w całości na MikroTik RouterOS bezkonkurencyjny pod kątem ergonomii pozostaje bezpłatny The Dude
  • Złożona telemetria systemowa: W środowiskach, gdzie monitoring sieci przeplata się z głęboką analityką systemów operacyjnych i baz danych, prym wiedzie Zabbix
  • Środowiska Cloud-Native: Dla klastrów kontenerowych Kubernetes i nowoczesnych aplikacji rozproszonych standardem de facto jest Prometheus z Grafaną
Całkowity koszt posiadania (TCO): Wybór systemu bezpłatnego (Open Source) wiąże się z koniecznością inwestycji w kompetencje zespołu inżynierskiego (Linux, PHP, bazy danych). Rozwiązania komercyjne (np. PRTG) wymagają opłat licencyjnych, lecz minimalizują czas wdrożenia.
Drzewo decyzyjne wyboru NMS Inżynierskie drzewo decyzyjne wyboru systemu NMS Start: Profil infrastruktury 100% MikroTik RouterOS ISP radiowy / mały LAN Heterogeniczny LAN/WAN Cisco, HP, Linux, serwery Cloud-Native / Aplikacje Kubernetes, mikroserwisy The Dude Zero kosztów licencji, natywna integracja Winbox LibreNMS Automatyczne OID, LLDP/BGP, zero-config Zabbix Agenty OS, skrypty, złożona telemetria IT Prometheus + Grafana, PromQL Kryterium budżetowe i operacyjne (TCO): Brak dedykowanego inżyniera NOC i potrzeba gwarancji SLA? Rozważ komercyjny PRTG Network Monitor.
Slajd 38/55
Przegląd alternatywnych systemów NMS na rynku
Cel slajdu: Przedstawienie wiodących komercyjnych i otwartoźródłowych alternatyw dla LibreNMS oraz omówienie roli analizatorów przepływów w architekturze monitoringu.

Porównanie i rynek systemów NMS

Rynek systemów zarządzania siecią oferuje szeroką gamę rozwiązań różniących się architekturą silnika, wymaganiami systemowymi oraz modelem biznesowym.

  • PRTG Network Monitor: Komercyjny standard na platformę Windows; model licencji oparty na liczbie sensorów; bardzo szybkie wdrożenie out-of-the-box
  • Checkmk (dawniej OMD): Wysoce zoptymalizowany rdzeń w C++ (Micro Core) i moduły w Pythonie; minimalne obciążenie serwera przy tysiącach usług
  • Observium Community: Pierwowzór LibreNMS; elegancki interfejs PHP, lecz wersja bezpłatna posiada ograniczenia aktualizacji i alertów
  • Analiza przepływów L7 z ntopng: Uzupełnienie SNMP o telemetrię strumieni NetFlow/IPFIX; pozwala na identyfikację aplikacji i użytkowników nasycających łącze
Synergia SNMP i NetFlow: SNMP informuje inżyniera, ŻE łącze jest nasycone w 100%. NetFlow (np. poprzez ntopng) informuje go, KTO i CZYM je nasycił (np. konkretny adres IP pobierający backup protokołem rsync).
Przegląd systemów na rynku Przegląd wiodących systemów NMS na rynku IT PRTG Network Monitor Paessler GmbH. Architektura Windows. Model licencjonowania na sensory (100 free, płatne >100). Checkmk (dawniej OMD) Oparty na rdzeniu Micro Core (C++) i Python. Błyskawiczne odpytywanie agentowe i SNMP, edycja Raw i Enterprise. Observium Community Projekt macierzysty LibreNMS. PHP/MySQL. Wersja Community z rzadkimi aktualizacjami, wersja Pro płatna. OpenNMS Horizon / Meridian Architektura enterprise w języku Java. Wysoka skalowalność dla milionów metryk, duży narzut pamięciowy. ntopng – Monitorowanie przepływów L7 (NetFlow / sFlow / IPFIX) Podczas gdy NMS bada stan interfejsów (ile bitów/s), ntopng bada treść ruchu (kto, z kim, jaki protokół L7). Współpraca: NMS wykrywa nasycenie łącza (100% WAN) -> ntopng identyfikuje hosta generującego ruch. Działa w czasie rzeczywistym z technologią nDPI (Deep Packet Inspection).
Slajd 39/55
Nowoczesna telemetria – Prometheus i Grafana
Cel slajdu: Zrozumienie paradygmatu telemetrii time-series (TSDB), języka PromQL oraz separacji gromadzenia danych od ich wizualizacji.

Nowoczesne trendy telemetryczne

W nowoczesnych środowiskach IT klasyczne systemy oparte na RRDtool są coraz częściej uzupełniane przez dedykowane bazy szeregów czasowych (TSDB), na czele ze stosem Prometheus i Grafana.

  • Model danych szeregów czasowych (TSDB): Metryki identyfikowane przez nazwę oraz zestaw dynamicznych etykiet klucz-wartość (labels); brak sztywnych relacyjnych schematów tabel
  • Architektura Pull (Scrape): Prometheus cyklicznie odpytuje punkty końcowe HTTP eksporterów, pobierając dane w ustandaryzowanym formacie tekstowym OpenMetrics
  • Język analityczny PromQL: Potężne funkcje wektorowe (np. `rate()`, `histogram_quantile()`, `deriv()`), które automatycznie kompensują reset liczników i Counter Wrap
  • Warstwa prezentacji w Grafanie: Całkowite odseparowanie gromadzenia danych od ich wizualizacji; budowa dynamicznych, estetycznych dashboardów operatorskich dla NOC
Model metryki w Prometheus: Format nazwa_metryki{etykieta="wartość", ...} znacznik_czasu wartość_float64. Na przykład: ifHCInOctets{instance="192.168.1.1", ifDescr="GigabitEthernet0/1"} 104857600.
Architektura Prometheus i Grafana Nowoczesna telemetria: Prometheus TSDB + Grafana Eksportery Metryk snmp_exporter:9116 node_exporter:9100 blackbox_exp:9115 HTTP Scrape Prometheus Server Baza TSDB (Szeregi czasowe) • Metryka + etykiety (labels) • Silnik zapytań PromQL • Serwis Discovery (DNS, K8s) • Alertmanager (routing alertów) Port API: :9090 PromQL Grafana Dashboard • Panele Time Series • Wskaźniki Stat i Gauges • Dynamiczne zmienne • Mapy sieciowe i stany • Wizualizacje NOC Port Web: :3000 # Przykładowe zapytanie PromQL obliczające ruch wejściowy w Mb/s na porcie ether1: rate(ifHCInOctets{ifName="ether1", job="snmp"}[5m]) * 8 / 1000000 # rate() automatycznie obsługuje przepełnienia liczników 64-bitowych (Counter Wrap). Model TSDB przechowuje dane w formacie: metryka{etykieta1="wartość", ...} znacznik_czasu wartość
Slajd 40/55
SNMP Exporter – Integracja protokołu SNMP z Prometheusem
Cel slajdu: Zrozumienie zasady działania narzędzia snmp_exporter, procesu kompilacji MIB za pomocą generatora oraz konfiguracji skrobania metryk sieciowych.

Nowoczesne trendy telemetryczne

Prometheus ze swojej natury komunikuje się wyłącznie protokołem HTTP. Do odpytywania urządzeń SNMP służy oficjalne narzędzie pośredniczące snmp_exporter.

  • Rola pośrednika proxy (Scrape Target): Prometheus wykonuje zapytanie HTTP GET do eksportera, wskazując docelowy adres IP urządzenia w parametrze `target=192.168.1.1`
  • Narzędzie generator i plik snmp.yml: Przetwarzanie plików MIB w locie byłoby zbyt wolne, dlatego dedykowany `generator` kompiluje definicje OID do statycznego pliku konfiguracyjnego
  • Mapowanie tabel MIB na etykiety: Wiersze tabel SNMP (np. `ifTable`) są automatycznie zamieniane na serie z etykietami `ifName`, `ifDescr` oraz `ifIndex`
  • Wsparcie dla SNMP v2c oraz v3: Eksporter obsługuje profile bezpieczeństwa v3 (AuthPriv) z szyfrowaniem AES oraz SHA bez utraty wydajności
Optymalizacja generator.yml: W pliku konfiguracyjnym generatora należy precyzyjnie wskazać wyłącznie potrzebne OID (np. liczniki 64-bitowe ifHCInOctets zamiast 32-bitowych). Zapobiega to pobieraniu zbędnych danych i przeciążaniu procesora routera.
Działanie demona snmp_exporter snmp_exporter: Tłumaczenie SNMP na metryki OpenMetrics 1. Generator (Etap budowy) • Pliki MIB (IF-MIB, etc.) • generator.yml (OID, moduły) $ ./generator generate Wynik: plik snmp.yml 2. Demon snmp_exporter :9116 • Wczytuje snmp.yml • Obsługuje HTTP GET /snmp • Parametr: ?target=192.168.1.1 • Wykonuje GETBULK UDP 161 3. Router / Przełącznik Adres: 192.168.1.1 SNMP Agent (v2c/v3) Odpowiada na OID # Konfiguracja zadania w prometheus.yml: - job_name: 'snmp' static_configs: [{ targets: ['192.168.1.1', '192.168.1.2'] }] metrics_path: /snmp; params: { module: [if_mib] } relabel_configs: [ ... target -> param, replacement: 127.0.0.1:9116 ] # Odpowiedź OpenMetrics: ifHCInOctets{ifDescr="eth0",ifIndex="1"} 41920391209 # Prometeusz nie odpytuje bezpośrednio SNMP – robi to snmp_exporter na żądanie scrape.
Slajd 41/55
Projektowanie paneli operatorskich w Grafana
Cel slajdu: Opanowanie inżynierskich zasad ergonomicznego projektowania pulpitów sieciowych dla centrów zarządzania siecią (NOC).

Nowoczesne trendy telemetryczne

Pulpit operatorski (dashboard) nie może być przypadkowym zbiorem kolorowych wykresów. Prawidłowo zaprojektowany panel pozwala dyżurnemu inżynierowi ocenić kondycję sieci w ciągu 5 sekund.

  • Zasada hierarchii wizualnej: Kluczowe wskaźniki syntetyczne (Stat KPI) na samej górze, wykresy dynamiki (Time Series) pośrodku, tabele zdarzeń na dole
  • Rygor semantyczny barw: Czerwień i jaskrawy pomarańcz zarezerwowane wyłącznie dla stanów awaryjnych; normalna praca w kolorach stonowanych (błękit, zgaszona zieleń)
  • Zmienne dynamiczne (Dashboard Variables): Definiowanie zmiennych `$Device` i `$Interface` w nagłówku; jeden szablon panelu obsługuje całą sieć korporacyjną
  • Optymalizacja przedziałów czasowych: Dobór interwałów odpytywania (Step) zapobiegający przeciążeniu przeglądarki przy wyświetlaniu wykresów z wielu miesięcy
Zasada 5 sekund w NOC: Dyżurny inżynier patrzący na ścianę monitorów (video wall) w centrum operacji sieciowych musi w ciągu 5 sekund zorientować się, czy infrastruktura działa poprawnie, a jeśli nie – która strefa uległa awarii.
Projektowanie pulpitów Grafana Ergonomia pulpitów operatorskich NOC w Grafana Dashboard: Główny Rdzeń Kampusu | Zmienne: [Lokalizacja: Budynek A] [Urządzenie: rtr-core-01] [Interfejs: Gi0/0/1] STATUS WĘZŁA ONLINE RUCH WAN IN 842 Mb/s RUCH WAN OUT 315 Mb/s ALERTY KRYTYCZNE 0 Profil pasma w czasie (Time Series: bit/s) Próg 90% (900 Mb/s) Zasady projektowania pulpitów NOC (Zasada 5 sekund): 1. Od ogółu do szczegółu (KPI u góry, wykresy pośrodku). 2. Czerwony zarezerwowany wyłącznie dla awarii krytycznych. 3. Wykorzystuj zmienne dynamiczne (Dashboard Variables), aby nie mnożyć identycznych paneli dla każdego portu.
Slajd 42/55
Integracja NMS z systemami obsługi zgłoszeń ITSM
Cel slajdu: Zrozumienie automatyzacji zarządzania incydentami w procesach ITIL v4 poprzez integrację NMS z systemami Jira Service Management, GLPI i ServiceNow.

Integracja z ekosystemem IT

W dojrzałych organizacjach incydent wykryty przez NMS nie może kończyć się na wysłaniu maila. Powinien automatycznie inicjować sformalizowany proces Incident Management w systemie ITSM.

  • Zgodność z procesem ITIL v4: Błyskawiczna rejestracja incydentu, automatyczne przypisanie priorytetu (P1-P4) i rozpoczęcie naliczania czasu SLA
  • Mechanizm Webhooków i REST API: NMS wysyła ustrukturyzowany pakiet JSON metodą HTTP POST natychmiast po potwierdzeniu trwania awarii przez zadaną liczbę cykli
  • Deduplikacja i wzbogacenie danych: Warstwa middleware zapobiega tworzeniu setek zgłoszeń dla tej samej usterki i uzupełnia zgłoszenie o dane z bazy CMDB
  • Pętla zwrotna Auto-recovery: Ustąpienie awarii (komunikat RECOVERY z NMS) automatycznie zmienia status powiązanego zgłoszenia w ITSM na 'Rozwiązany'
Problem Alert Fatigue: Przeciążenie inżynierów tysiącami nieistotnych powiadomień mailowych prowadzi do ignorowania alarmów krytycznych. Integracja z ITSM i filtrowanie progowe gwarantują, że inżynier otrzymuje wyłącznie zgłoszenia wymagające interwencji.
Integracja NMS z ITSM Automatyzacja incydentów: NMS <-> System ITSM (ITIL v4) LibreNMS / NMS • BGP session DOWN • Warunek spełniony >3m • Trigger Webhook Wysyłka JSON HTTP POST POST JSON Korelacja & Filtr • Deduplikacja zdarzeń • Wzbogacenie o dane CMDB • Wyznaczenie priorytetu P1 Mapowanie pól ticketu REST API System ITSM Jira / GLPI / ServiceNow • Nowe zgłoszenie: INC-4029 • Przypisanie do dyżurnego L2 • Start zegara SLA (MTTR) Auto-resolve po Recovery # Przykładowy ładunek Webhook wysyłany z LibreNMS do API GLPI / Jira: { "incident": { "title": "BGP Peer Down: 198.51.100.1", "device": "rtr-border-01", "severity": "CRITICAL", "priority": "P1", "location": "DC-Warszawa-1", "timestamp": "2026-09-29T10:15:30Z", "rule": "BGP Session State != established" } } # Zamknięcie alertu w LibreNMS wysyła zdarzenie RECOVERY, które automatycznie zamyka ticket. # Zapobiega to "alert fatigue" (zmęczeniu alarmami) i zduplikowanym zgłoszeniom.
Slajd 43/55
Źródło prawdy o sieci – Integracja z NetBox
Cel slajdu: Zrozumienie koncepcji Source of Truth (SoT) i mechanizmów automatycznej synchronizacji inwentarza sieciowego między NetBox a systemem NMS.

Integracja z ekosystemem IT

W nowoczesnej inżynierii sieciowej ręczne dodawanie urządzeń do NMS jest uznawane za błąd architektoniczny. Prawidłowym podejściem jest automatyczna synchronizacja z centralnym źródłem prawdy (NetBox).

  • Koncepcja Source of Truth (SoT): NetBox definiuje stan zamierzony sieci (jak powinna wyglądać: IP, VLANy, urządzenia, okablowanie szaf DCIM)
  • Stan faktyczny w NMS (Observed State): LibreNMS bada stan rzeczywisty w danej sekundzie; synchronizacja wykrywa rozbieżności między projektem a stanem faktycznym
  • Automatyzacja cyklu życia urządzenia: Wpisanie nowego przełącznika do NetBoxa i nadanie mu tagu `monitored` automatycznie rejestruje go w NMS poprzez webhook
  • Detekcja Shadow IT: Urządzenia wykryte w podsieciach przez autoodkrywanie LibreNMS, które nie figurują w NetBoksie, są natychmiast oznaczane jako nieautoryzowane
Intent-Based Networking: Podejście, w którym inżynier definiuje wyłącznie intencję biznesową i projektową w centralnej bazie SoT, a systemy orkiestracji i monitoringu automatycznie dopasowują konfigurację urządzeń i reguły telemetryczne.
Integracja NetBox z NMS Źródło prawdy o sieci (Source of Truth): NetBox + NMS NetBox (DCIM / IPAM) Stan Zamierzony (Intent) • Inwentarz szaf rackowych • Pula adresów IP i prefiksy • Tagi: [monitored: snmp_v3] Webhook on-device-create Sync API Sync Engine • Python / netbox2librenms • Sprawdzenie tagów • Wykrywanie niezgodności • Dodawanie / usuwanie lnms device:add LibreNMS Stan Faktyczny (Observed) • Aktywne odpytywanie • Status portów i OID • Alerty o awariach Zbieżność stanu: 100% # Koncepcja Intent-Based Networking: Stan zamierzony vs stan obserwowany • Jeśli urządzenie jest w LibreNMS, a NIE MA go w NetBox -> "Shadow IT" (nieautoryzowany sprzęt w sieci). • Jeśli urządzenie jest w NetBox z tagiem 'Active', a LibreNMS zgłasza DOWN -> Rzeczywista awaria sprzętu. • Skrypt cykliczny synchronizuje adresację IP, grupy urządzeń i profile SNMP automatycznie z NetBoksa. Dokumentacja API NetBox: https://netboxlabs.com/docs/netbox/
Slajd 44/55
Laboratorium: Wdrożenie i pierwsze kroki w LibreNMS
Cel slajdu: Praktyczne przećwiczenie procedury instalacyjnej LibreNMS w systemie Linux, konfiguracja zależności bazodanowych oraz aktywacja zadań harmonogramu cron.

Warsztaty laboratoryjne

Wdrożenie systemu LibreNMS wymaga precyzyjnego skonfigurowania stosu LEMP (Linux, Nginx, MariaDB, PHP) oraz nadania odpowiednich uprawnień dla dedykowanego użytkownika systemowego.

  • Przygotowanie środowiska bazowego: Instalacja serwera WWW Nginx, interpretera PHP ≥ 8.4 (zalecany 8.5) z modułami oraz pakietów narzędziowych `fping`, `rrdtool` i `snmp`
  • Konfiguracja relacyjnej bazy danych: Utworzenie bazy danych MariaDB z kodowaniem `utf8mb4` oraz użytkownika o dedykowanych uprawnieniach
  • Klonowanie repozytorium i Composer: Pobranie oficjalnego kodu źródłowego z Git do katalogu `/opt/librenms` oraz instalacja zależności PHP menedżerem Composer
  • Harmonogram cykli cron: Aktywacja pliku harmonogramu `/etc/cron.d/librenms` odpowiedzialnego za uruchamianie wątków pollerów co 300 sekund
Uprawnienia katalogów: Błędne uprawnienia do katalogów /opt/librenms/rrd i /opt/librenms/storage są najczęstszą przyczyną braku generowania wykresów. Należy upewnić się, że właścicielem jest użytkownik librenms, a grupa WWW ma prawa odczytu i zapisu.
Procedura instalacji LibreNMS Laboratorium 1: Procedura instalacji LibreNMS Krok 1: Wymagania OS • Ubuntu 24.04 LTS • Nginx, PHP 8.4, MariaDB • RRDtool, fping, git, snmp Użytkownik systemowy 'librenms' Krok 2: Klonowanie i Baza • git clone do /opt/librenms • Utworzenie bazy UTF8MB4 • Uprawnienia do RRD i logów lnms migrate (migracje Laravel) Krok 3: Kreator Web & Cron • Przejście http://IP_SERWERA/install • Konto admina • Konfiguracja .env Skopiowanie librenms.cron # Sekwencja komend instalacyjnych w środowisku laboratoryjnym Linux: $ sudo apt update && sudo apt install -y nginx mariadb-server php8.4-fpm php8.4-snmp fping $ sudo useradd librenms -d /opt/librenms -M -r -s /bin/bash $ sudo git clone https://github.com/librenms/librenms.git /opt/librenms $ sudo chown -R librenms:librenms /opt/librenms && sudo chmod 771 /opt/librenms $ sudo -u librenms ./scripts/composer_wrapper.php install --no-dev $ sudo cp /opt/librenms/dist/librenms.cron /etc/cron.d/librenms # Po zakończeniu przejdź do przeglądarki pod adresem IP serwera, aby ukończyć instalację.
Slajd 45/55
Laboratorium: Dodanie węzłów sieciowych do monitoringu
Cel slajdu: Nabycie praktycznych umiejętności dodawania routera MikroTik i serwera Linux do LibreNMS drogą interfejsu CLI oraz weryfikacji pierwszego odpytania.

Warsztaty laboratoryjne

Podłączenie urządzeń do monitoringu wymaga skoordynowanej konfiguracji po stronie agenta sieciowego (RouterOS, Linux snmpd) oraz poprawnego wywołania rejestracji w LibreNMS.

  • Konfiguracja agenta na routerze MikroTik: Utworzenie wspólnoty SNMP v2c z restrykcją źródłowego adresu IP (`addresses=192.168.10.10/32`) w systemie RouterOS
  • Konfiguracja bezpiecznego agenta na serwerze Linux: Utworzenie użytkownika SNMP v3 w trybie AuthPriv z uwierzytelnianiem SHA i szyfrowaniem AES w pliku `/etc/snmp/snmpd.conf`
  • Rejestracja urządzeń w konsoli CLI: Wykorzystanie polecenia `lnms device:add` do natychmiastowej rejestracji bez konieczności przechodzenia przez formularze webowe
  • Inicjalne odpytanie i autoodkrywanie: Ręczne uruchomienie `lnms device:discover ID` oraz `lnms device:poll ID` (lub tradycyjnych wrapperów `./discovery.php` i `./poller.php`) w celu natychmiastowego wygenerowania wykresów
Opcje polecenia lnms device:add: Przełącznik -2 wymusza SNMP v2c, -c definiuje community string, a przełącznik -3 definiuje wersję v3 z parametrami użytkownika (-u), hasła uwierzytelniania (-A) i szyfrowania (-X).
Rejestracja urządzeń w LibreNMS Laboratorium 2: Rejestracja węzłów sieciowych w LibreNMS Router MikroTik CHR IP: 192.168.10.1 Protokół: SNMP v2c Community: LabNetSec Port: UDP 161 Serwer LibreNMS IP: 192.168.10.10 lnms device:add snmpwalk test fping check Serwer Linux Debian IP: 192.168.10.20 Protokół: SNMP v3 (AuthPriv) User: secadmin / SHA+AES Port: UDP 161 # 1. Konfiguracja agenta na MikroTik RouterOS (CLI): [admin@MikroTik] > /snmp community add name=LabNetSec addresses=192.168.10.10/32 [admin@MikroTik] > /snmp set enabled=yes contact="NOC" location="Lab-Rack-1" # 2. Dodanie routera MikroTik do LibreNMS z poziomu konsoli serwera NMS: $ lnms device:add -2 -c LabNetSec 192.168.10.1 # 3. Dodanie serwera Linux z bezpiecznym SNMP v3 (AuthPriv SHA + AES): $ lnms device:add -3 -u secadmin -a SHA -A HasloAuth123 -x AES -X HasloPriv123 192.168.10.20 # Wynik: LibreNMS wykonuje pierwszy fping, pobiera sysObjectID i uruchamia discovery.
Slajd 46/55
Laboratorium: Budowa alertu i test obciążeniowy
Cel slajdu: Praktyczne zdefiniowanie reguły alertowej w LibreNMS dla obciążenia CPU oraz wywołanie kontrolowanego incydentu za pomocą narzędzia stress-ng.

Warsztaty laboratoryjne

Prawidłowa konfiguracja systemu monitoringu wymaga przetestowania pętli alertowej w warunkach kontrolowanego przeciążenia komponentów infrastruktury.

  • Definicja logiczna reguły alertowej: Konfiguracja w kreatorze reguły badającej tabelę `processors`: `processors.processor_usage > 85` ze statusem Critical
  • Tłumienie fałszywych alarmów (Max checks): Ustawienie parametru opóźnienia na 2 cykle zapobiega wyzwalaniu alertu przy chwilowych skokach wywołanych przez zadania cron
  • Sztuczne obciążenie procesora: Uruchomienie narzędzia `stress-ng` obciążającego wszystkie rdzenie procesora maszyny testowej na poziomie 95% przez 10 minut
  • Weryfikacja procesu eskalacji i wygaszania: Obserwacja zmiany stanu urządzenia na czerwony w panelu WWW oraz weryfikacja automatycznego zamknięcia incydentu (Recovery)
Testowanie reguł bez czekania: Uruchomienie skryptu ./alerts.php -d z poziomu powłoki serwera LibreNMS wypisuje pełne zapytania SQL generowane przez silnik alertów oraz natychmiast ewaluuje wszystkie reguły w trybie debugowania.
Budowa alertu i test stress-ng Laboratorium 3: Definicja reguły alertowej i test obciążeniowy 1. Reguła w LibreNMS Tabela: processors Warunek: processor_usage > 85 Max checks: 2 (opóźnienie) Severity: Critical 2. Test stress-ng Węzeł Linux 192.168.10.20 Sztuczne obciążenie 100% Czas trwania: 600 sekund Generacja OID CPU 100% 3. Efekt w NMS Stan: ALERTING (Czerwony) Wpis w Eventlogu Wysłanie Webhook / Mail Auto-recovery po teście # 1. Wywołanie sztucznego obciążenia CPU na testowanym serwerze Linux: $ sudo apt-get install stress-ng $ stress-ng --cpu $(nproc) --cpu-load 95 --timeout 600s & # 2. Ręczne wywołanie odpytania pollerem w LibreNMS (przyspieszenie testu): $ ./poller.php -h 192.168.10.20 -m processors # 3. Sprawdzenie statusu alertu w konsoli CLI: $ ./alerts.php -d # Wynik w logu: Alert 'Wysokie obciążenie CPU' fired for device 192.168.10.20 (usage: 95%)
Slajd 47/55
Laboratorium: Instalacja The Dude na Cloud Hosted Router
Cel slajdu: Praktyczna instalacja pakietu The Dude na maszynie wirtualnej MikroTik CHR, podłączenie dedykowanego dysku na bazę SQLite i zestawienie sesji z klientem okienkowym.

Warsztaty laboratoryjne

W środowiskach wirtualnych (Proxmox, VMware, KVM) najwygodniejszą metodą uruchomienia The Dude jest wykorzystanie wirtualnego obrazu MikroTik Cloud Hosted Router (CHR).

  • Dobór i wgranie pakietu NPK: Pobranie pakietu `dude-7.x-x86_64.npk` zgodnego z architekturą procesora i wersją RouterOS oraz wgranie do pamięci routera
  • Instalacja po restarcie: Restart RouterOS komendą `/system reboot` inicjuje automatyczną dekompresję i instalację pakietu serwerowego
  • Konfiguracja dedykowanego dysku: Formatowanie drugiego wirtualnego dysku systemem ext4 i wskazanie go w dyrektywie `data-directory`
  • Podłączenie aplikacji okienkowej: Zestawienie sesji z programem `dude.exe` przez port TCP 8291 z uwierzytelnieniem kontem administracyjnym RouterOS
Ochrona pamięci systemowej RouterOS: Bezwzględnie unikaj zapisywania bazy The Dude w domyślnym katalogu pamięci głównej routera. Ciągły zapis danych telemetrycznych prowadzi do wyczerpania przestrzeni dyskowej i zablokowania całego systemu operacyjnego.
Instalacja The Dude na CHR Laboratorium 4: Wdrożenie The Dude na MikroTik CHR 1. Wgranie NPK • Pobranie dude-7.x.npk • Wgranie do Files przez Winbox • /system reboot Pakiet zainstalowany 2. Aktywacja w CLI • /dude set enabled=yes • data-directory=dude-disk • Utworzenie bazy dude.db Serwer aktywny: status ok 3. Klient Win32 / Wine • Uruchomienie dude.exe • Server: IP maszyny CHR • Port 8291 (RouterOS) Załadowanie mapy sieci # Konfiguracja w wirtualnym routerze MikroTik Cloud Hosted Router (CHR): [admin@CHR] > /disk print Flags: B - BLOCK-DEVICE; M - MOUNTED # NAME: disk2 MODEL: QEMU HARDDISK SIZE: 10GiB # Sformatowanie dedykowanego dysku na bazę SQLite i włączenie usługi: [admin@CHR] > /disk format-drive disk2 file-system=ext4 [admin@CHR] > /dude set enabled=yes data-directory=disk2/dude-data [admin@CHR] > /dude print # enabled: yes | data-directory: disk2/dude-data | status: running
Slajd 48/55
Laboratorium: Definiowanie sondy SNMP w The Dude
Cel slajdu: Praktyczne utworzenie niestandardowej sondy badającej temperaturę procesora urządzenia MikroTik z użyciem języka funkcji i wyrażeń The Dude.

Warsztaty laboratoryjne

Największą zaletą The Dude w porównaniu z prostymi monitorami ICMP jest możliwość definiowania zaawansowanych sond funkcyjnych badających dowolne gałęzie MIB.

  • Struktura sond funkcyjnych (Function): Rozdział logiki na warunek dostępności (`Available`), kryterium błędu (`Error`) oraz wartość pomiarową (`Value`)
  • Pobieranie OID funkcją oid(): Użycie wbudowanej funkcji `oid("...")` do odpytania gałęzi MIB MikroTik MIKROTIK-MIB::mtxrHLCpuTemperature
  • Skalowanie arytmetyczne: Przeliczenie surowej liczby całkowitej zwracanej przez agenta (np. wartość 445) na rzeczywiste stopnie Celsjusza (44,5 °C)
  • Logika alarmowania w polu Error: Zastosowanie instrukcji warunkowej `if()` zwracającej pusty tekst przy braku błędu lub treść komunikatu przy przekroczeniu progu
Składnia pola Error w The Dude: Konstrukcja if(warunek, "Komunikat błędu", "") to fundament logiki alarmowej The Dude. Zwrócenie ciągu niepustego natychmiast zmienia stan sondy na DOWN i zabarwia element mapy na czerwono.
Sonda funkcyjna SNMP w The Dude Laboratorium 5: Budowa funkcyjnej sondy SNMP w The Dude The Dude - Probe Properties [Sonda: Mikrotik_CPU_Temp] Type: Function Available: oid("1.3.6.1.4.1.14988.1.1.3.11.0") > 0 Error: if(oid("1.3.6.1.4.1.14988.1.1.3.11.0")/10 > 70, "Przegrzanie CPU!", "") Value: oid("1.3.6.1.4.1.14988.1.1.3.11.0") / 10 Unit: °C Rate: None # Wizualizacja na ikonie urządzenia na mapie The Dude: RB4011-Core-Router Ping: 0.8 ms | Up: 42d 15h CPU Temp: 44.5 °C • Funkcja oid() pobiera surową wartość OID z agenta urządzenia. • Dzielenie przez 10 wynika z reprezentacji MikroTik (np. 445 = 44.5 °C). • Jeśli funkcja Error zwróci pusty ciąg "", sonda ma status OK (zielona). • Jeśli temperatura przekroczy 70 °C, urządzenie zmieni kolor na czerwony.
Slajd 49/55
Diagnostyka i utrzymanie LibreNMS – Skrypt validate.php
Cel slajdu: Nauczenie diagnozowania problemów integralności systemu LibreNMS za pomocą wbudowanego narzędzia walidacyjnego oraz interpretacji komunikatów diagnostycznych.

Diagnostyka i utrzymanie systemów NMS

Podstawowym narzędziem diagnostycznym każdego administratora LibreNMS jest skrypt validate.php, który kompleksowo weryfikuje spójność całego stosu technologicznego.

  • Rola skryptu validate.php: Kompleksowa weryfikacja bazy danych MariaDB, uprawnień plików, wersji PHP, stref czasowych i modułów systemowych
  • Poziomy powiadomień: Trzystopniowa klasyfikacja stanu: `[OK]` (stan poprawny), `[WARN]` (ostrzeżenie niekrytyczne) oraz `[FAIL]` (błąd uniemożliwiający pracę)
  • Rozpoznawanie typowych awarii: Identyfikacja rozbieżności schematu bazy po aktualizacji kodu z Git oraz problemów z demonem poller-wrapper
  • Wbudowane instrukcje naprawcze: Dla każdego wykrytego błędu skrypt generuje dokładne polecenie powłoki bash lub komendę naprawczą do skopiowania
Pierwszy krok rozwiązywania problemów: Zanim zadasz pytanie na forum społeczności lub zgłosisz błąd w repozytorium GitHub, uruchom su - librenms -c "./validate.php". W ponad 90% przypadków skrypt natychmiast wskaże przyczynę problemu.
Diagnostyka skryptem validate.php Diagnostyka integralności systemu: Skrypt validate.php $ ./validate.php ==================================== Component | Version LibreNMS | 24.9.0-38-g9fa8120 DB Schema | 2024_08_01_000000_add_syslog_index (298) PHP | 8.3.6 (cli) Python | 3.12.3 Database | MariaDB 10.11.8-MariaDB-0ubuntu0.24.04.1 RRDtool | 1.7.2 ==================================== [OK] Database connection successful [OK] Database Schema is current [WARN] Your install is out of date, last update: Mon, 23 Sep 2026 [FAIL] Some folders have incorrect file permissions Fix: chown -R librenms:librenms /opt/librenms && chmod 771 /opt/librenms
Slajd 50/55
Projektowanie odpornego wdrożenia systemu NMS
Cel slajdu: Poznanie inżynierskich zasad projektowania odpornej infrastruktury monitoringu z wykorzystaniem sieci Out-Of-Band oraz mechanizmów nadzoru serwera NMS.

Projektowanie odpornego wdrożenia NMS

Podstawowym paradoksem monitoringu jest ryzyko utraty widoczności sieci dokładnie w momencie wystąpienia najcięższej awarii. Zapobiega temu separacja płaszczyzn zarządzania.

  • Zarządzanie Out-Of-Band (OOB): Fizyczne odseparowanie płaszczyzny zarządzania (Management Plane) od sieci produkcyjnej (Data Plane) za pomocą dedykowanych portów mgmt0
  • Niezależny kanał eskalacji (Out-of-Path): Wyposażenie serwera NMS w modem LTE/5G lub bramkę SMS; gwarancja wysłania powiadomienia o awarii łącza światłowodowego
  • Zasada 'Kto monitoruje monitora?': Mechanizm Dead Man's Switch: serwer NMS cyklicznie raportuje swoją żywotność do chmury; brak sygnału wyzwala natychmiastowy alarm
  • Separacja zasilania i redundancja: Podłączenie serwerów NMS do niezależnych linii zasilania gwarantowanego (UPS A/B) oraz agregatu prądotwórczego
Management Plane Protection: Zgodnie z wytycznymi bezpieczeństwa sieciowego (m.in. RFC 3411), ruch telemetryczny SNMP i sesje SSH administratorów nigdy nie powinny mieszać się z ogólnodostępnym ruchem użytkowników.
Projektowanie sieci OOB dla NMS Projektowanie odpornego NMS: Sieć Out-Of-Band (OOB) Sieć Produkcyjna (Data Plane) • Ruch użytkowników, serwerów • Tranzyt WAN / Internet Awaria: Pętla STP lub odcięcie WAN! Zarządzanie In-Band zostaje zablokowane Brak dostępu do urządzeń drogą tradycyjną Fizyczna Sieć OOB Management • Porty dedykowane (mgmt0 / ether1) • Osobne switche OOB, niezależne zasilanie Serwer NMS podłączony bezpośrednio do OOB • Zapasowe łącze LTE/5G do powiadomień SMS Działa nawet przy całkowitym padzie sieci LAN # Architektura niezawodności: "Kto monitoruje monitora?" 1. Zewnętrzny Heartbeat (Dead Man's Switch): NMS wysyła co 60s sygnał do chmury. Brak sygnału przez 3 minuty wyzwala alarm SMS do inżyniera z zewnętrznego serwera. 2. Niezależny kanał powiadomień: Modem GSM/LTE wpięty bezpośrednio do serwera NMS. Awaria routera brzegowego nie blokuje wysyłki alertu SMS o awarii łącza WAN. Standard RFC 3411: Bezpieczna separacja płaszczyzny zarządzania (Management Plane Protection).
Slajd 51/55
Planowanie pojemności serwera NMS (Hardware Sizing)
Cel slajdu: Nabycie umiejętności inżynierskiej kalkulacji zasobów CPU, RAM, IOPS i przestrzeni dyskowej na potrzeby systemów NMS w małej, średniej i dużej skali.

Projektowanie odpornego wdrożenia NMS

Prawidłowy dobór parametrów serwera NMS decyduje o stabilności zbierania metryk. Głównym czynnikiem limitującym skalowalność nie jest procesor, lecz wydajność operacji wejścia-wyjścia dysku (IOPS).

  • Zjawisko losowego zapisu dyskowego: W silnikach RRDtool każdy monitorowany interfejs posiada własny plik binarnego archiwum; 20 tysięcy portów oznacza modyfikację 20 tysięcy plików co 5 minut
  • Kluczowa rola demona rrdcached: Buforowanie operacji zapisu w pamięci operacyjnej RAM i sekwencyjny zrzut na dysk redukuje operacje wejścia-wyjścia IOPS nawet o 85%
  • Dyski SSD NVMe jako standard: Klasyczne dyski magnetyczne HDD ulegają natychmiastowej saturacji przy losowym zapisie; dla NMS standardem są nośniki SSD/NVMe
  • Kryteria podziału klastrowego: Przekroczenie progu 500 urządzeń lub 15 tysięcy portów wymaga wydzielenia bazy MariaDB na dedykowaną maszynę oraz wdrożenia Distributed Pollers
Kalkulacja przestrzeni RRD: Domyślny plik interfejsu port-id.rrd w LibreNMS zajmuje około 380 KB. Dla sieci z 20 000 monitorowanych interfejsów same archiwa RRD wymagają około 8 GB przestrzeni dyskowej o bardzo wysokim zapotrzebowaniu na losowy IOPS.
Planowanie zasobów serwera NMS Planowanie pojemności serwera NMS (Hardware Sizing) Skala wdrożenia vCPU / RAM Dysk / Wymagany IOPS Architektura NMS < 100 urządzeń (ok. 2 000 portów) 4 vCPU / 8 GB RAM 100 GB SSD (SATA) ~200 IOPS Pojedyncza maszyna VM 100 - 500 urządzeń (ok. 12 000 portów) 8 vCPU / 16 GB RAM 250 GB NVMe ~1 500 IOPS Standalone + Redis cache > 1 000 urządzeń (> 30 000 portów) 16+ vCPU / 32+ GB NVMe RAID10 > 5 000 IOPS Distributed Polling (Klaster) # Główne wąskie gardło NMS: Losowy zapis do bazy RRDtool (Random Write IOPS) • Każdy port przełącznika to osobny plik .rrd na dysku aktualizowany co 300 sekund. • 500 urządzeń x 48 portów = 24 000 plików RRD modyfikowanych w oknie 5 minut. • Rozwiązanie: Użycie demona rrdcached (buforowanie zapisu w RAM) i dysków NVMe. Tradycyjne dyski HDD (talerzowe 7.2k RPM) nie nadają się do systemów NMS > 50 urządzeń.
Slajd 52/55
Ewolucja w stronę AIOps i sterowania zdarzeniowego
Cel slajdu: Zrozumienie współczesnych trendów rozwojowych NMS: algorytmów korelacji przyczynowo-skutkowej oraz automatyzacji w pętli zamkniętej (Closed-loop Automation).

Nowoczesne trendy telemetryczne

Współczesna telemetria sieciowa ewoluuje od pasywnego powiadamiania inżyniera w stronę zautomatyzowanych pętli samonaprawczych (Closed-loop Self-healing Networks).

  • Analiza pierwotnej przyczyny (Root-Cause): Silniki AIOps analizują graf topologii sieci i korelują tysiące wtórnych zdarzeń, wskazując pojedyncze uszkodzone łącze
  • Automatyzacja sterowana zdarzeniami (EDA): Integracja webhooków NMS z narzędziem Event-Driven Ansible; wywołanie dedykowanego playbooka zaradczego bez udziału człowieka
  • Pętla samonaprawcza (Closed-Loop): System automatycznie izoluje degradujące łącze (np. zwiększając metrykę OSPF/BGP), po czym weryfikuje ustąpienie strat pakietów
  • Bezpieczeństwo i mechanizmy Circuit Breaker: Ścisłe limity automatycznych interwencji zapobiegające kaskadowym wyłączeniom sprawnych węzłów przy błędach telemetrii
Closed-Loop Automation: Paradygmat automatyzacji, w którym system monitorujący nie tylko wykrywa awarię, lecz samodzielnie podejmuje akcję korygującą i natychmiast sprawdza jej skuteczność w kolejnej próbce telemetrycznej.
Pętla Closed-loop Automation Ewolucja w stronę AIOps i automatyzacji samonaprawczej 1. Telemetria • gNMI / SNMP • Wykrycie anomalii • CRC errors rosną Ciągły strumień 2. Silnik AIOps • Korelacja zdarzeń • Analiza Root-Cause • Odrzucenie szumu Wniosek: Wadliwy SFP 3. Event-Driven • EDA (Ansible Rulebook) • Wywołanie akcji • BGP cost increase Przekierowanie ruchu 4. Weryfikacja • Spadek strat • Zamknięcie • Zero strat SLA Pętla zamknięta: Automatyczna weryfikacja skuteczności naprawy (Closed-Loop) # Przejście od tradycyjnego monitoringu do sieci autonomicznych: • Tradycyjny NMS: Generuje 50 powiadomień SMS o awarii portów i czeka na reakcję człowieka. • AIOps + Event-Driven Automation: Identyfikuje pierwotną przyczynę (Root-Cause) w 5 sekund, automatycznie izoluje uszkodzone łącze w BGP/OSPF i informuje inżyniera o wykonanej akcji.
Slajd 53/55
Słownik kluczowych pojęć
Cel slajdu: Usystematyzowanie terminologii technicznej z zakresu systemów NMS, protokołów, architektury oraz narzędzi omówionych w prezentacji.

Podsumowanie modułu

Poniższy słownik gromadzi i precyzyjnie definiuje 10 najważniejszych pojęć inżynierskich niezbędnych do projektowania i eksploatacji nowoczesnych systemów monitoringu.

  • NMS oraz Model FCAPS: Zintegrowana platforma zarządzająca realizująca 5 standardowych filarów ISO: błędy, konfigurację, rozliczenia, wydajność i bezpieczeństwo
  • LibreNMS i The Dude: Dwa wiodące paradygmaty: autonomiczny, webowy NMS z autoodkrywaniem vs wysoce wizualny, lekki monitor ściśle zintegrowany z RouterOS
  • Distributed Polling i Oxidized: Architektura skalowania horyzontalnego z kolejką Redis oraz wersjonowanie konfiguracji urządzeń w repozytorium Git
  • Source of Truth i Sieć OOB: Stan zamierzony sieci definiowany w NetBox oraz fizycznie wydzielona infrastruktura zarządzająca gwarantująca łączność w trakcie awarii
Precyzja terminologiczna: Różnica między pojęciami "NMS" a "Monitoring" polega na tym, że NMS nie tylko pasywnie obserwuje metryki, lecz zarządza konfiguracją urządzeń, wykrywa topologię oraz inicjuje akcje zaradcze.
Słownik pojęć NMS Słownik kluczowych pojęć modułu NMS NMS (Network Management System) Zintegrowana platforma sprzętowo-programowa do nadzoru sieci. Model FCAPS Standard ISO: Fault, Configuration, Accounting, Perf., Security. LibreNMS Autonomiczny NMS Open Source oparty na PHP, Laravel i RRDtool. The Dude System monitoringu MikroTik zintegrowany z RouterOS i mapą graficzną. Distributed Polling Rozproszona architektura odpytywania koordynowana kolejką Redis. Oxidized Automatyczny kolektor kopii zapasowych konfiguracji sieciowych w Git. snmp_exporter Mostek tłumaczący protokół SNMP na metryki OpenMetrics Prometheusa. NetBox System DCIM/IPAM pełniący rolę 'Źródła Prawdy' (Source of Truth). Out-Of-Band (OOB) Fizycznie odseparowana sieć dedykowana wyłącznie do zarządzania infrastrukturą. validate.php Wbudowane narzędzie diagnostyczne weryfikujące spójność stosu LibreNMS.
Slajd 54/55
Pytania kontrolne i powtórzenie materiału
Cel slajdu: Weryfikacja stopnia przyswojenia wiedzy o architekturze LibreNMS, The Dude, telemetrii time-series oraz skalowaniu systemów monitoringu.

Podsumowanie modułu

Poniższy zestaw pytań problemowych pozwala na samodzielną weryfikację opanowania zagadnień projektowych i eksploatacyjnych omówionych w prezentacji.

  • Pytanie 1: Wąskie gardło I/O: Dlaczego silnik RRDtool generuje wysokie zapotrzebowanie na losowy zapis i jak rrdcached eliminuje ten problem?
  • Pytanie 2: Skalowanie horyzontalne: W jaki sposób kolejka Redis i Distributed Pollery pozwalają monitorować dziesiątki tysięcy portów w oknie 300 sekund?
  • Pytanie 3: Intent vs Reality: Czym różni się rola NetBoksa jako Source of Truth od roli systemu LibreNMS w architekturze korporacyjnej?
  • Pytanie 4: Niezawodność eskalacji: Dlaczego powiadomienia o awariach krytycznych muszą wychodzić dedykowanym kanałem Out-of-Path (modem LTE)?
Odpowiedź wzorcowa do pytania 1: Każdy interfejs to niezależny plik RRD. Aktualizacja 10 000 portów to 10 000 losowych operacji zapisu co 5 minut. Rrdcached buforuje dane w RAM i wykonuje zapisy sekwencyjne dużymi blokami, redukując IOPS o 85%.
Pytania kontrolne z systemów NMS Pytania kontrolne i powtórzenie materiału 1 Dlaczego LibreNMS wymaga bufora rrdcached w instalacjach powyżej 200 urządzeń? Wskazówka: Zjawisko losowego zapisu dyskowego (Random Write IOPS) w plikach RRD. 2 W jaki sposób architektura Distributed Poller zapobiega opóźnieniom pollowania (poller lag)? Wskazówka: Kolejkowanie zadań w Redis i horyzontalny podział odpytywania na grupy węzłów. 3 Czym różni się podejście Intent-Based (NetBox) od stanu obserwowanego w LibreNMS? Wskazówka: Stan zamierzony (projektowy) a stan rzeczywisty wykryty w danym momencie na portach. 4 Dlaczego sieć Out-Of-Band jest krytyczna dla pewności powiadamiania o awariach? Wskazówka: Fizyczna separacja płaszczyzny sterowania od awarii łączy produkcyjnych (pętle, odcięcie WAN).
Slajd 55/55
Źródła, literatura i dokumentacja techniczna
Cel slajdu: Wskazanie rzetelnych materiałów źródłowych, oficjalnej dokumentacji projektowej oraz standardów inżynierskich dla dalszego pogłębiania wiedzy z zakresu systemów NMS.

Podsumowanie modułu

Dalsze rozwijanie kompetencji w dziedzinie monitoringu sieci wymaga regularnego korzystania z oficjalnej dokumentacji oprogramowania oraz standardów IETF.

  • Dokumentacja LibreNMS i The Dude: Oficjalne podręczniki instalacji, konfiguracji Distributed Polling, reguł alertowych oraz manual MikroTik
  • Standardy inżynierskie IETF RFC: RFC 3411 (architektura SNMP v3) oraz RFC 5424 (standaryzacja dzienników zdarzeń Syslog)
  • Procesy zarządzania ITIL v4: Dobre praktyki zarządzania incydentami i monitorowaniem zdarzeń w infrastrukturach korporacyjnych
  • Nowoczesna telemetria i automatyzacja: Repozytoria Prometheus snmp_exporter, dokumentacja NetBox oraz biblioteki automatyzacji Oxidized
Oficjalne źródła wiedzy: Korzystaj wyłącznie ze zweryfikowanych repozytoriów i oficjalnych portali dokumentacji technicznej dostawców oprogramowania.
Źródła i literatura NMS Źródła, literatura i dokumentacja techniczna Oficjalna dokumentacja LibreNMS i The Dude • LibreNMS Documentation: https://docs.librenms.org/ • MikroTik The Dude v7 Manual: https://wiki.mikrotik.com/wiki/Manual:The_Dude_v7 Standardy IETF RFC i organizacja procesów ITIL • RFC 3411: An Architecture for Describing SNMP Management Frameworks • RFC 5424: The Syslog Protocol | ITIL v4: Incident and Monitoring Management Nowoczesna telemetria, automatyzacja i Source of Truth • Prometheus & SNMP Exporter: https://github.com/prometheus/snmp_exporter • NetBox DCIM/IPAM Documentation: https://netboxlabs.com/docs/netbox/ Materiały laboratoryjne i skrypty wdrożeniowe dostępne w repozytorium uczelnianym.
← Poprzednia prezentacja Następna prezentacja →