Strona główna
Slajd 1/35
Wdrożenie LibreNMS w kontenerach Docker – poradnik praktyczny
Cel slajdu: Przedstawienie kompletnej procedury instalacji, konfiguracji i uruchomienia produkcyjnego stosu LibreNMS w środowisku Docker Compose na systemie Linux.

Strona tytułowa i wprowadzenie do przewodnika

Niniejszy poradnik stanowi bezpośrednie rozwinięcie zagadnień teoretycznych i architektonicznych omówionych podczas wykładów z cyklu 'Monitorowanie sieci komputerowych'.

  • Cel praktyczny: Uruchomienie w pełni funkcjonalnego systemu NMS w architekturze mikroserwisowej z bazą MariaDB, buforem Redis, pollerem Dispatcher oraz odbiornikami Syslog i Traps
  • Środowisko bazowe: System Linux na wspieranej dystrybucji (Ubuntu Server 24.04 LTS lub 26.04 LTS, Debian 12 lub 13, Rocky/AlmaLinux), oficjalny silnik Docker Engine oraz wtyczka Docker Compose v2
  • Powiązanie z kursem: Ścisła integracja z koncepcjami modeli zarządzania FCAPS (Wykład 1), protokołem SNMP (Wykłady 2 i 3), architekturą NMS (Wykład 4), konteneryzacją (Wykład 5) oraz logowaniem (Wykład 6)
  • Podejście dydaktyczne: Instrukcja krok po kroku: od przygotowania systemu, przez konfigurację plików .env i compose.yml, po podłączenie urządzeń sieciowych
Oficjalny stos Docker LibreNMS: Zbiór wyspecjalizowanych kontenerów rozwijanych przez społeczność LibreNMS (repozytorium librenms/docker), realizujących zadania serwera WWW, harmonogramu odpytywania, bazy danych SQL oraz kolektorów zdarzeń w izolowanych przestrzeniach procesowych.
Wdrożenie LibreNMS w Dockerze Wdrożenie LibreNMS w kontenerach Docker Praktyczny przewodnik instalacji stosu na systemie Linux krok po kroku 🐳 Docker Compose Stos mikroserwisów 🌐 LibreNMS NMS Wersja produkcyjna 📚 Odniesienia Wykłady 1 do 6 Architektura i orkiestracja LibreNMS w środowisku Docker Compose
Slajd 2/35
Spis treści przewodnika i powiązania z wykładami
Cel slajdu: Mapa modułu wdrożeniowego: od przygotowania systemu Linux po testy odbioru pułapek i logów.

Plan kroków instalacyjnych i relacje z wykładami 1–6.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Spis treści przewodnika i powiązania z wykładami.

  • Moduł I: Przygotowanie środowiska (Slajdy 3–9): Wymagania sprzętowe, instalacja Dockera, uprawnienia PUID/PGID (Odniesienie do Wykładu 5)
  • Moduł II: Konfiguracja stosu kontenerów (Slajdy 10–19): Szczegółowa analiza plików .env, librenms.env oraz compose.yml (Odniesienie do Wykładów 4 i 5)
  • Moduł III: Uruchomienie i pierwsze logowanie (Slajdy 20–24): Start stosu, weryfikacja logów, kreator WWW, skrypt validate.php (Odniesienie do Wykładu 4)
  • Moduł IV: Integracja z siecią i urządzeniami (Slajdy 25–32): Zezwolenia UFW, konfiguracja agentów SNMP na Cisco/MikroTik/Linux, odbiór Syslog i Traps (Wykłady 2, 3 i 6)
  • Moduł V: Utrzymanie produkcyjne (Slajdy 33–35): Procedury backupu, aktualizacji stosu oraz rozwiązywanie problemów (Troubleshooting)
Zasada dydaktyczna: Każdy krok instalacyjny zawiera odniesienie do odpowiedniego fragmentu wykładu, wyjaśniając dlaczego dany parametr jest konfigurowany w określony sposób.
Spis treści przewodnika i powiązania z wykładami Spis treści przewodnika i powiązania z wykładami Etap instalacji • Procedura wdrożeniowa • Środowisko: Linux Docker Status: krok 2 / 35 Odniesienie do wykładów • Podstawa teoretyczna • Wykłady 1–6 (SNMP/NMS) Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Narzędzia: Docker Compose v2, MariaDB 10, Redis 7, LibreNMS Engine • Praktyka: pełna zgodność z architekturą zdefiniowaną w Wykładzie 4 i 5 Instalacja i orkiestracja LibreNMS w kontenerach
Slajd 3/35
Dlaczego konteneryzacja dla LibreNMS? (Odniesienie: Wykład 5)
Cel slajdu: Porównanie tradycyjnego wdrożenia bare-metal/VM ze stosem kontenerowym Docker Compose.

Zalety architektury kontenerowej w systemach monitorowania.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Dlaczego konteneryzacja dla LibreNMS? (Odniesienie: Wykład 5).

  • Izolacja mikroserwisów: Baza MariaDB, bufor Redis i silnik WWW działają w odrębnych przestrzeniach procesów z własnymi limitami pamięci
  • Powtarzalność wdrożenia (IaC): Środowisko opisane w jednym pliku compose.yml można w kilka minut sklonować na maszynę testową lub zapasową
  • Błyskawiczne aktualizacje: Aktualizacja LibreNMS lub MariaDB sprowadza się do pobrania nowego obrazu bez ryzyka uszkodzenia bibliotek systemu bazowego
  • Uproszczony backup: Trwałe dane odseparowane w katalogach ./db oraz ./librenms, co umożliwia natychmiastowe wykonanie kopii migawkowej
Przykład z Wykładu 5: Tradycyjna aktualizacja interpretera PHP na serwerze Ubuntu potrafi zepsuć zależności Composera w LibreNMS - obecnie minimalna wersja PHP to 8.4, a zalecana to 8.5. W Dockerze obraz librenms/librenms dostarcza przetestowane i wbudowane wszystkie wymagane moduły, więc aktualizacja sprowadza się do pobrania nowego obrazu.
Dlaczego konteneryzacja dla LibreNMS? (Odniesienie: Wykład 5) Dlaczego konteneryzacja dla LibreNMS? (Odniesienie: Wykład 5) Etap instalacji • Procedura wdrożeniowa • Środowisko: Linux Docker Status: krok 3 / 35 Odniesienie do wykładów • Podstawa teoretyczna • Wykłady 1–6 (SNMP/NMS) Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Narzędzia: Docker Compose v2, MariaDB 10, Redis 7, LibreNMS Engine • Praktyka: pełna zgodność z architekturą zdefiniowaną w Wykładzie 4 i 5 Instalacja i orkiestracja LibreNMS w kontenerach
Slajd 4/35
Wymagania systemowe i sprzętowe na serwerze Linux
Cel slajdu: Określenie parametrów sprzętowych serwera w zależności od skali monitorowanej infrastruktury.

Wymiarowanie zasobów serwera (sizing) pod instalację LibreNMS.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Wymagania systemowe i sprzętowe na serwerze Linux.

  • Środowisko laboratoryjne (do 50 urządzeń): 2 rdzenie vCPU, 4 GB pamięci RAM, 30 GB przestrzeni dyskowej (SSD zalecane)
  • Środowisko produkcyjne średniej wielkości (do 300 urządzeń): 4 rdzenie vCPU, 8 GB pamięci RAM, 100 GB przestrzeni dyskowej SSD NVMe
  • Rekomendowana dystrybucja Linux: Ubuntu Server 24.04 LTS lub 26.04 LTS, Debian 12 (Bookworm) lub 13 (Trixie), Rocky Linux / AlmaLinux 8, 9 lub 10. Ubuntu 22.04 nie jest już wspierane
  • Wymagane wersje komponentów: PHP 8.4 (minimum) lub 8.5 (zalecane), MariaDB 10.5 lub nowsza, Net-SNMP 5.7 lub nowszy, RRDtool 1.4 lub nowszy, Python 3.4 lub nowszy
  • Wymagania jądra (Kernel): Wsparcie dla cgroups v2, modułów sieciowych iptables/nftables oraz systemu plików overlay2
Uwaga dotycząca I/O dysku: Zgodnie z Wykładem 1 i 4, bazy RRDtool wykonują tysiące małych operacji zapisu (co 5 minut dla każdego interfejsu). Zwykłe dyski HDD nie poradzą sobie z kolejką I/O; bezwzględnie zaleca się pamięci SSD/NVMe.
Wymagania systemowe i sprzętowe na serwerze Linux Wymagania systemowe i sprzętowe na serwerze Linux Etap instalacji • Procedura wdrożeniowa • Środowisko: Linux Docker Status: krok 4 / 35 Odniesienie do wykładów • Podstawa teoretyczna • Wykłady 1–6 (SNMP/NMS) Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Narzędzia: Docker Compose v2, MariaDB 10, Redis 7, LibreNMS Engine • Praktyka: pełna zgodność z architekturą zdefiniowaną w Wykładzie 4 i 5 Instalacja i orkiestracja LibreNMS w kontenerach
Slajd 5/35
Architektura oficjalnego stosu kontenerów LibreNMS
Cel slajdu: Szczegółowy przegląd mikroserwisów wchodzących w skład oficjalnego repozytorium librenms/docker.

Siedem współpracujących kontenerów stosu LibreNMS.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Architektura oficjalnego stosu kontenerów LibreNMS.

  • db (MariaDB 10): Relacyjna baza danych przechowująca inwentaryzację hostów, użytkowników, historię alarmów i konfigurację
  • redis (Redis 7.2): Pamięć podręczna w RAM służąca jako broker kolejek zadań dla demonów odpytujących (Dispatcher)
  • librenms (Web UI): Interfejs graficzny użytkownika (Nginx + PHP-FPM, warstwa PHP Laravel 12, Bootstrap i Leaflet dla map), dostępny domyślnie na porcie 8000
  • dispatcher (Sidecar Poller): Demon w tle zarządzający wielowątkowym odpytywaniem SNMP w regularnych interwałach (Wykład 4)
  • syslogng (Sidecar Syslog): Kolektor logów sieciowych nasłuchujący na porcie 514 UDP/TCP (Wykład 6)
  • snmptrapd (Sidecar Trap): Odbiornik asynchronicznych pułapek SNMP nasłuchujący na porcie 162 UDP (Wykłady 2 i 3)
  • msmtpd (Poczta SMTP): Lekki przekaźnik pocztowy wysyłający powiadomienia e-mail o awariach do administratorów
Koncepcja Sidecar (kontener pomocniczy): Wzorzec architektoniczny, w którym ten sam obraz kontenera (librenms/librenms:latest) uruchamiany jest z różnymi flagami środowiskowymi (SIDECAR_DISPATCHER=1, SIDECAR_SYSLOGNG=1), realizując dedykowaną rolę systemową.
Architektura oficjalnego stosu kontenerów LibreNMS Architektura oficjalnego stosu kontenerów LibreNMS Etap instalacji • Procedura wdrożeniowa • Środowisko: Linux Docker Status: krok 5 / 35 Odniesienie do wykładów • Podstawa teoretyczna • Wykłady 1–6 (SNMP/NMS) Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Narzędzia: Docker Compose v2, MariaDB 10, Redis 7, LibreNMS Engine • Praktyka: pełna zgodność z architekturą zdefiniowaną w Wykładzie 4 i 5 Instalacja i orkiestracja LibreNMS w kontenerach
Slajd 6/35
Krok 1 – Przygotowanie systemu bazowego Linux
Cel slajdu: Konfiguracja repozytoriów, aktualizacja systemu i instalacja niezbędnych narzędzi pomocniczych.

Przygotowanie środowiska systemu operacyjnego.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 1 – Przygotowanie systemu bazowego Linux.

  • Aktualizacja pakietów: Wykonanie poleceń: sudo apt update && sudo apt upgrade -y
  • Narzędzia diagnostyczne: Instalacja pakietów: curl, wget, git, htop, net-tools, unzip, ca-certificates
  • Sprawdzenie wolnej przestrzeni: Weryfikacja partycji dyskowych poleceniem df -h (min. 20 GB na /opt lub /var)
  • Sprawdzenie strefy czasowej: Ustawienie poprawnej strefy: sudo timedatectl set-timezone Europe/Warsaw
Polecenia terminala:
sudo apt update && sudo apt install -y curl wget git htop net-tools unzip ca-certificates gnupg lsb-release
Krok 1 – Przygotowanie systemu bazowego Linux Krok 1 – Przygotowanie systemu bazowego Linux Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 6 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 7/35
Krok 2 – Instalacja silnika Docker Engine i Docker Compose
Cel slajdu: Instalacja oficjalnego środowiska uruchomieniowego kontenerów z oficjalnego repozytorium Docker.

Instalacja środowiska kontenerowego (Docker Engine).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 2 – Instalacja silnika Docker Engine i Docker Compose.

  • Dodanie klucza GPG: Pobranie oficjalnego klucza kryptograficznego Docker do katalogu /etc/apt/keyrings/
  • Dodanie repozytorium: Dodanie oficjalnego źródła apt dla bieżącej wersji dystrybucji (np. Ubuntu noble/jammy)
  • Instalacja pakietów: Instalacja: docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin, docker-compose-plugin
  • Weryfikacja wersji: Sprawdzenie poleceniami: docker --version oraz docker compose version (wymagany Compose v2)
Odniesienie do Wykładu 5: Używamy nowoczesnej wtyczki Docker Compose v2 (wywoływanej jako docker compose ze spacją), a nie przestarzałego skryptu Pythona v1 (docker-compose z myślnikiem).
Krok 2 – Instalacja silnika Docker Engine i Docker Compose Krok 2 – Instalacja silnika Docker Engine i Docker Compose Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 7 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 8/35
Krok 3 – Konfiguracja uprawnień użytkownika i zmiennych PUID/PGID
Cel slajdu: Zapewnienie uprawnień do zarządzania kontenerami bez użycia konta root oraz mapowanie identyfikatorów UID/GID.

Bezpieczeństwo uprawnień i integracja z systemem plików.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 3 – Konfiguracja uprawnień użytkownika i zmiennych PUID/PGID.

  • Dodanie do grupy docker: Polecenie: sudo usermod -aG docker $USER (wymaga przelogowania)
  • Odczyt identyfikatorów: Sprawdzenie identyfikatora użytkownika poleceniem: id -u (zwykle 1000) oraz id -g (1000)
  • Znaczenie PUID i PGID: Kontenery LibreNMS uruchamiają procesy z tymi uprawnieniami, aby nie tworzyć plików należących do roota
  • Bezpieczeństwo wolumenów: Zapobieganie problemom z uprawnieniami (Permission Denied) przy zapisie baz RRD i logów
PUID i PGID: Zmienne środowiskowe przekazywane do kontenera informujące go, z jakim identyfikatorem użytkownika i grupy na hoście mają być tworzone pliki na zamontowanych wolumenach dyskowych.
Krok 3 – Konfiguracja uprawnień użytkownika i zmiennych PUID/PGID Krok 3 – Konfiguracja uprawnień użytkownika i zmiennych PUID/PGID Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 8 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 9/35
Krok 4 – Struktura katalogów projektu i uprawnienia do wolumenów
Cel slajdu: Utworzenie dedykowanej lokalizacji dla projektu LibreNMS oraz podkatalogów na trwałe dane.

Organizacja przestrzeni dyskowej pod wolumeny Dockera.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 4 – Struktura katalogów projektu i uprawnienia do wolumenów.

  • Katalog główny projektu: Utworzenie lokalizacji: sudo mkdir -p /opt/librenms-docker && cd /opt/librenms-docker
  • Podkatalog bazy danych: Utworzenie katalogu: sudo mkdir -p /opt/librenms-docker/db (dla plików bazy MariaDB)
  • Podkatalog aplikacji: Utworzenie katalogu: sudo mkdir -p /opt/librenms-docker/librenms (dla plików RRD, konfiguracji i logów)
  • Nadanie uprawnień: Polecenie: sudo chown -R $(id -u):$(id -g) /opt/librenms-docker
Struktura na dysku:
/opt/librenms-docker/
├── compose.yml
├── .env
├── librenms.env
├── msmtpd.env
├── db/
└── librenms/
Krok 4 – Struktura katalogów projektu i uprawnienia do wolumenów Krok 4 – Struktura katalogów projektu i uprawnienia do wolumenów Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 9 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 10/35
Krok 5 – Pobranie oficjalnego repozytorium GitHub
Cel slajdu: Klonowanie repozytorium librenms/docker i przejście do katalogu z oficjalnym szablonem Compose.

Pobranie szablonów wdrożeniowych z oficjalnego źródła.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 5 – Pobranie oficjalnego repozytorium GitHub.

  • Sklonowanie repozytorium: Polecenie: git clone https://github.com/librenms/docker.git repo-docker
  • Skopiowanie szablonu: Polecenie: cp -a repo-docker/examples/compose/. /opt/librenms-docker/ - kropka na końcu ścieżki źródłowej jest konieczna, aby skopiować również pliki ukryte
  • Weryfikacja zawartości: Sprawdzenie obecności plików: ls -a /opt/librenms-docker/ - powinny być compose.yml, .env, librenms.env oraz msmtpd.env
  • Usunięcie tymczasowego repozytorium: Usunięcie zbędnego katalogu źródłowego: rm -rf repo-docker
Pułapka powłoki: Polecenie cp repo-docker/examples/compose/* . nie skopiuje pliku .env, ponieważ wzorzec * nie obejmuje plików ukrytych. Bez pliku .env stos nie wystartuje, bo kontenery nie dostaną hasła do bazy. Dlatego używamy cp -a repo-docker/examples/compose/. . (kropka na końcu).
Krok 5 – Pobranie oficjalnego repozytorium GitHub Krok 5 – Pobranie oficjalnego repozytorium GitHub Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 10 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 11/35
Krok 6 – Konfiguracja pliku .env (hasła i strefa czasowa)
Cel slajdu: Dostosowanie globalnych zmiennych środowiskowych stosu kontenerów do wymogów bezpieczeństwa.

Edycja pliku środowiskowego .env.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 6 – Konfiguracja pliku .env (hasła i strefa czasowa).

  • Strefa czasowa (TZ): Ustawienie parametru: TZ=Europe/Warsaw (kluczowe dla wykresów RRD i logów)
  • Identyfikatory użytkownika: Ustawienie PUID=1000 oraz PGID=1000 zgodnie z wynikiem polecenia id
  • Nazwa bazy danych: Parametr: MYSQL_DATABASE=librenms
  • Użytkownik i hasło bazy: Parametry: MYSQL_USER=librenms oraz silne hasło MYSQL_PASSWORD=TajneHasloBazy123!
Plik .env: Standardowy mechanizm Dockera służący do wstrzykiwania zmiennych konfiguracyjnych do pliku compose.yml. Plik ten nigdy nie powinien trafiać do publicznego repozytorium kodu.
Krok 6 – Konfiguracja pliku .env (hasła i strefa czasowa) Krok 6 – Konfiguracja pliku .env (hasła i strefa czasowa) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 11 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 12/35
Krok 7 – Konfiguracja pliku librenms.env (PHP, Redis i opcje)
Cel slajdu: Dostosowanie parametrów środowiska uruchomieniowego aplikacji LibreNMS i limitów pamięci.

Edycja parametrów aplikacji w pliku librenms.env.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 7 – Konfiguracja pliku librenms.env (PHP, Redis i opcje).

  • Limit pamięci PHP (MEMORY_LIMIT): Zwiększenie limitu do: MEMORY_LIMIT=512M (dla dużych tabel interfejsów)
  • Sterowniki sesji i cache: Parametry: CACHE_DRIVER=redis oraz SESSION_DRIVER=redis (wykorzystanie brokera Redis)
  • Domyślna społeczność SNMP: Parametr: LIBRENMS_SNMP_COMMUNITY=mojanazwa (używana przy auto-discovery)
  • Moduł Weathermap: Włączenie mapy pogodowej sieci: LIBRENMS_WEATHERMAP=true (opcjonalnie, Wykład 4)
Optymalizacja z Wykładu 4: Zwiększenie limitu pamięci PHP zapobiega awariom procesu poller.php podczas odpytywania przełączników 48-portowych z rozbudowanymi tablicami ARP i MAC (IF-MIB).
Krok 7 – Konfiguracja pliku librenms.env (PHP, Redis i opcje) Krok 7 – Konfiguracja pliku librenms.env (PHP, Redis i opcje) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 12 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 13/35
Krok 8 – Analiza compose.yml: Usługa bazy danych MariaDB
Cel slajdu: Szczegółowa interpretacja dyrektyw konfiguracyjnych kontenera bazy danych MariaDB 10.

Optymalizacja bazy danych MySQL/MariaDB dla NMS.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 8 – Analiza compose.yml: Usługa bazy danych MariaDB.

  • Obraz bazowy: image: mariadb:10 (stabilna gałąź rekomendowana przez twórców LibreNMS)
  • Parametr innodb-file-per-table=1: Każda tabela w osobnym pliku .ibd, co ułatwia zarządzanie i zwalnianie miejsca na dysku
  • Kodowanie znaków: Dyrektywy: character-set-server=utf8mb4 oraz collation-server=utf8mb4_unicode_ci
  • Trwały wolumen: Montowanie: ./db:/var/lib/mysql (pliki bazodanowe zachowywane na hoście)
Zgodność z Wykładem 4 i 5: Kodowanie utf8mb4 jest bezwzględnym wymogiem LibreNMS do poprawnego zapisywania opisów portów (ifAlias) i komunikatów Syslog zawierających polskie znaki diakrytyczne.
Krok 8 – Analiza compose.yml: Usługa bazy danych MariaDB Krok 8 – Analiza compose.yml: Usługa bazy danych MariaDB Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 13 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 14/35
Krok 9 – Analiza compose.yml: Broker zadań i cache Redis
Cel slajdu: Wyjaśnienie roli kontenera Redis w koordynacji procesów asynchronicznych i pollerów.

Rola pamięci podręcznej Redis w architekturze NMS.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 9 – Analiza compose.yml: Broker zadań i cache Redis.

  • Obraz bazowy: image: redis:7.2-alpine (wariant Alpine jest lekki, ale nie jest mikroobrazem: po rozpakowaniu zajmuje ok. 57 MB na dysku, a warstwa ściągana z rejestru ma ok. 16 MB)
  • Zadanie brokera kolejek: Rozdzielanie zadań odpytywania urządzeń pomiędzy procesy robocze Dispatchera
  • Buforowanie metadanych: Przechowywanie bieżących stanów blokad urządzeń, aby dwa pollery nie odpytywały tego samego hosta
  • Brak konieczności persystencji: Redis działa wyłącznie w pamięci RAM; w razie restartu kolejka jest natychmiast odbudowywana
Redis w NMS: Szybki magazyn struktur danych w pamięci operacyjnej (in-memory key-value store), pełniący rolę koordynatora rozproszonego pollingu (Distributed Polling) omówionego w Wykładzie 4.
Krok 9 – Analiza compose.yml: Broker zadań i cache Redis Krok 9 – Analiza compose.yml: Broker zadań i cache Redis Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 14 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 15/35
Krok 10 – Analiza compose.yml: Główna aplikacja LibreNMS (Web UI)
Cel slajdu: Konfiguracja kontenera serwera aplikacji webowej Nginx i PHP-FPM.

Kontener interfejsu graficznego i centrum zarządzania.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 10 – Analiza compose.yml: Główna aplikacja LibreNMS (Web UI).

  • Obraz bazowy: image: librenms/librenms:latest (oficjalny obraz zintegrowany ze stosem)
  • Wymagane uprawnienia jądra (cap_add): Flagi NET_ADMIN oraz NET_RAW (niezbędne do wysyłania pakietów ICMP Ping z poziomu kontenera!)
  • Mapowanie portów: Port hosta 8000 przekierowany na port 8000 kontenera (interfejs HTTP Nginx)
  • Trwały wolumen /data: Montowanie: ./librenms:/data (obejmuje katalogi rrd/, storage/, config/)
Uwaga inżynierska na uprawnienie NET_RAW: Bez flagi cap_add NET_RAW kontener nie ma prawa tworzyć gniazd raw socket, co uniemożliwiłoby działanie polecenia fping sprawdzającego dostępność urządzeń (Wykład 1).
Krok 10 – Analiza compose.yml: Główna aplikacja LibreNMS (Web UI) Krok 10 – Analiza compose.yml: Główna aplikacja LibreNMS (Web UI) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 15 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 16/35
Krok 11 – Analiza compose.yml: Sidecar Dispatcher (Poller)
Cel slajdu: Konfiguracja dedykowanego kontenera odpowiedzialnego za cykliczne odpytywanie SNMP.

Wielowątkowy silnik odpytujący SNMP w tle.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 11 – Analiza compose.yml: Sidecar Dispatcher (Poller).

  • Flaga aktywacyjna: Zmienna środowiskowa: SIDECAR_DISPATCHER=1 informuje obraz o uruchomieniu demona w tle
  • Identyfikator węzła: Zmienna: DISPATCHER_NODE_ID=dispatcher1 (umożliwia identyfikację instancji w klastrze)
  • Współdzielenie wolumenu: Identyczne montowanie ./librenms:/data (dostęp do tych samych plików RRD co Web UI)
  • Brak wystawionych portów: Dispatcher nie nasłuchuje na żadnym porcie zewnętrznym; sam inicjuje połączenia wychodzące UDP 161
Zasada działania z Wykładu 3: To właśnie kontener Dispatcher wysyła pakiety SNMP GetRequest i GetBulk do urządzeń sieciowych na port UDP 161, a następnie aktualizuje pliki RRD i tabele bazy danych.
Krok 11 – Analiza compose.yml: Sidecar Dispatcher (Poller) Krok 11 – Analiza compose.yml: Sidecar Dispatcher (Poller) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 16 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 17/35
Krok 12 – Analiza compose.yml: Sidecar Syslog-ng (Kolektor logów)
Cel slajdu: Uruchomienie dedykowanego demona zbierającego komunikaty zdarzeń z urządzeń sieciowych.

Centralny kolektor logów sieciowych zgodny z RFC 3164 i RFC 5424.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 12 – Analiza compose.yml: Sidecar Syslog-ng (Kolektor logów).

  • Flaga aktywacyjna: Zmienna środowiskowa: `SIDECAR_SYSLOGNG=1` (uruchamia demona syslog-ng wewnątrz kontenera)
  • Wystawione porty sieciowe: Port 514 UDP oraz port 514 TCP przekierowane bezpośrednio z interfejsu serwera Linux
  • Obowiązkowa aktywacja w LibreNMS (`syslog.yaml`): Samo uruchomienie kontenera nie aktywuje modułu w Web UI; konieczne jest utworzenie pliku `./librenms/config.d/syslog.yaml` z wpisem `enable_syslog: true` (lub wykonanie `docker compose exec librenms lnms config:set enable_syslog true`)
  • Integracja z bazą danych: Demon syslog-ng przekazuje linie rozdzielone separatorem `||` do skryptu `/opt/librenms/syslog.php`, który zapisuje je w tabeli `syslog` bazy MariaDB
Obowiązkowy krok konfiguracji (K20): Zgodnie z oficjalną dokumentacją kontenera LibreNMS, funkcja Syslog w interfejsie WWW wymaga jawnego włączenia w konfiguracji YAML (`enable_syslog: true`). Bez tego pliku menu Overview → Syslog pozostaje nieaktywne!
Krok 12 – Analiza compose.yml: Sidecar Syslog-ng (Kolektor logów) Krok 12 – Analiza compose.yml: Sidecar Syslog-ng (Kolektor logów) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 17 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 18/35
Krok 13 – Analiza compose.yml: Sidecar Snmptrapd (Odbiór pułapek)
Cel slajdu: Konfiguracja odbiornika asynchronicznych komunikatów SNMP Traps.

Obsługa natychmiastowych powiadomień o awariach w sieci.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 13 – Analiza compose.yml: Sidecar Snmptrapd (Odbiór pułapek).

  • Flaga aktywacyjna: Zmienna środowiskowa: SIDECAR_SNMPTRAPD=1
  • Wystawiony port sieciowy: Port 162 UDP oraz 162 TCP przekierowane z hosta do kontenera
  • Zasada działania: Odbiór niepotwierdzanych pułapek SNMP Traps (v1/v2c) oraz powiadomień InformRequest (v2c/v3)
  • Przekazywanie do NMS: Zapis zdarzeń do bazy LibreNMS i natychmiastowe wyzwalanie reguł alertów (Wykład 3)
SNMP Trap w Dockerze: Asynchroniczny kanał powiadamiania (Push). Gdy w switchu nastąpi awaria zasilacza lub port przejdzie w stan DOWN, pakiet na port 162 UDP natychmiast informuje system NMS bez czekania na 5-minutowy cykl odpytywania.
Krok 13 – Analiza compose.yml: Sidecar Snmptrapd (Odbiór pułapek) Krok 13 – Analiza compose.yml: Sidecar Snmptrapd (Odbiór pułapek) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 18 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 19/35
Krok 14 – Analiza compose.yml: Usługa poczty msmtpd i uprawnienia
Cel slajdu: Konfiguracja wysyłki powiadomień e-mail oraz nadanie uprawnień do katalogów dyskowych.

Powiadomienia e-mail i ostateczne przygotowanie uprawnień.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 14 – Analiza compose.yml: Usługa poczty msmtpd i uprawnienia.

  • Kontener msmtpd: Lekki klient SMTP (obraz crazymax/msmtpd), przekazujący pocztę wychodzącą do zewnętrznego serwera pocztowego
  • Plik msmtpd.env: Konfiguracja serwera pocztowego: SMTP_HOST, SMTP_PORT, SMTP_TLS, SMTP_STARTTLS, SMTP_TLS_CHECKCERT, SMTP_AUTH, SMTP_USER, SMTP_PASSWORD, SMTP_FROM (tak dokładnie nazywają się zmienne w oficjalnym pliku przykładowym)
  • Nadanie uprawnień do wolumenów: Wykonanie na serwerze: sudo chown -R 1000:1000 /opt/librenms-docker/librenms
  • Uprawnienia do bazy MariaDB: Katalog ./db zostanie automatycznie skonfigurowany przez kontener bazy podczas pierwszego startu
Dobry przykład z Wykładu 1: Prawidłowo skonfigurowany relay pocztowy msmtpd gwarantuje, że inżynier dyżurny w centrum NOC otrzyma powiadomienie na telefon w ciągu kilkunastu sekund od wykrycia awarii portu WAN.
Krok 14 – Analiza compose.yml: Usługa poczty msmtpd i uprawnienia Krok 14 – Analiza compose.yml: Usługa poczty msmtpd i uprawnienia Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 19 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 20/35
Krok 15 – Uruchomienie stosu poleceniem docker compose up -d
Cel slajdu: Inicjalizacja wszystkich mikroserwisów w trybie odłączonym (detached mode).

Start całego ekosystemu monitorowania jednym poleceniem.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 15 – Uruchomienie stosu poleceniem docker compose up -d.

  • Polecenie uruchomienia: W katalogu projektu: docker compose up -d
  • Pobieranie obrazów: Docker pobiera obrazy: mariadb:10, redis:7.2-alpine, crazymax/msmtpd, librenms/librenms:latest
  • Tworzenie sieci wewnętrznej: Automatyczne utworzenie izolowanej sieci mostkowej (bridge network) o nazwie librenms_default
  • Tworzenie kontenerów: Uruchomienie w zdefiniowanej kolejności: db -> redis -> msmtpd -> librenms -> sidecars
Czas pierwszego startu: Przy pierwszym uruchomieniu kontener MariaDB inicjalizuje bazę danych, a kontener LibreNMS wykonuje migracje schematu SQL (tworzenie kilkudziesięciu tabel). Może to potrwać od 1 do 3 minut.
Krok 15 – Uruchomienie stosu poleceniem docker compose up -d Krok 15 – Uruchomienie stosu poleceniem docker compose up -d Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 20 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 21/35
Krok 16 – Weryfikacja stanu kontenerów (ps i logs)
Cel slajdu: Nadzór nad procesem startu stosu, kontrola statusu procesów i odczyt logów diagnostycznych.

Kontrola poprawności uruchomienia mikroserwisów.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 16 – Weryfikacja stanu kontenerów (ps i logs).

  • Sprawdzenie statusu kontenerów: Polecenie: docker compose ps -a (wszystkie 7 kontenerów powinno mieć stan 'Up')
  • Podgląd logów bazy danych: Polecenie: docker compose logs -f db (oczekiwanie na komunikat: 'ready for connections')
  • Podgląd logów aplikacji: Polecenie: docker compose logs -f librenms (weryfikacja zakończenia migracji bazy danych)
  • Wykrywanie restartów: Jeśli którykolwiek kontener ma status 'Restarting', logi natychmiast wskażą przyczynę (np. błąd hasła bazy)
Prawidłowy wynik docker compose ps -a:
librenms_db          Up
librenms_redis            Up
librenms                 Up (port 0.0.0.0:8000->8000/tcp)
librenms_dispatcher  Up
librenms_msmtpd      Up (healthy)
librenms_syslogng  Up (porty 514/tcp, 514/udp)
librenms_snmptrapd  Up (porty 162/tcp, 162/udp)
Krok 16 – Weryfikacja stanu kontenerów (ps i logs) Krok 16 – Weryfikacja stanu kontenerów (ps i logs) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 21 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 22/35
Krok 17 – Pierwsze logowanie do interfejsu Web UI
Cel slajdu: Otwarcie panelu administracyjnego w przeglądarce i przejście wstępnej weryfikacji.

Dostęp do panelu administracyjnego przez przeglądarkę WWW.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 17 – Pierwsze logowanie do interfejsu Web UI.

  • Adres dostępowy: Otwórz w przeglądarce: http://<adres_ip_serwera>:8000 – podaj adres IP lub nazwę DNS swojego serwera Docker
  • Tworzenie konta administratora: W instalacji kontenerowej migracje bazy danych wykonują się automatycznie. Przy pierwszym wejściu w Web UI system wykrywa brak użytkowników i wyświetla formularz tworzenia konta pierwszego administratora (można je także utworzyć z CLI: docker compose exec librenms lnms user:add)
  • Weryfikacja bazy i usług: Po zalogowaniu w sekcji Poller i w menu Alerts widać, czy dispatcher działa i czy baza odpowiada
  • Narzędzia diagnostyczne: Sprawdzenie poprawności instalacji skryptem validate.php (omówione w kolejnym kroku)
Panel LibreNMS: Interfejs graficzny zbudowany w Bootstrapie, wyświetlający wykresy z plików RRD (RRDtool) oraz mapy topologii na silniku Leaflet i danych OpenStreetMap (Wykład 4).
Krok 17 – Pierwsze logowanie do interfejsu Web UI Krok 17 – Pierwsze logowanie do interfejsu Web UI Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 22 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 23/35
Krok 18 – Tworzenie konta administratora i diagnostyka validate.php
Cel slajdu: Rejestracja pierwszego użytkownika administracyjnego oraz uruchomienie wewnętrznego walidatora.

Ustanowienie poświadczeń administracyjnych i test spójności.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 18 – Tworzenie konta administratora i diagnostyka validate.php.

  • Konto administratora przez GUI: Podanie nazwy użytkownika (np. admin), silnego hasła oraz adresu e-mail
  • Konto administratora przez CLI: Polecenie: docker compose exec librenms lnms user:add -p <Silne_Haslo> -r admin -e admin@firma.pl admin. Przetestowane: Successfully added user: admin
  • Uruchomienie skryptu walidacji: Kluczowe polecenie: docker compose exec --user librenms librenms php validate.php
  • Interpretacja wyniku: W stosie kontenerowym dwa komunikaty FAIL (No python wrapper pollers found oraz Scheduler is not running) są prawidłowe: zadania obsługuje Dispatcher, a nie cron i skrypty python
Skrypt validate.php (Wykład 4): Oficjalne narzędzie audytowe LibreNMS weryfikujące spójność schematu bazy danych, uprawnienia katalogów RRD, wersję Pythona dla pollera i konfigurację sieci.
Krok 18 – Tworzenie konta administratora i diagnostyka validate.php Krok 18 – Tworzenie konta administratora i diagnostyka validate.php Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 23 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 24/35
Krok 19 – Konfiguracja sieci hosta i zapory ogniowej UFW
Cel slajdu: Zapewnienie bezpiecznego dostępu do portów NMS z zachowaniem reguł obrony wielowarstwowej.

Reguły zapory sieciowej na serwerze Linux (Odniesienie: Wykład 6).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 19 – Konfiguracja sieci hosta i zapory ogniowej UFW.

  • Dostęp do panelu WWW: Port 8000 TCP udostępniany dla administratorów
  • Odbiór logów Syslog: Port 514 UDP/TCP dla urządzeń sieciowych
  • Odbiór pułapek SNMP Traps: Port 162 UDP dla asynchronicznych zdarzeń
  • Ważne: Docker omija standardowy UFW! Docker dodaje reguły DNAT do iptables w łańcuchu `DOCKER`, które przetwarzane są PRZED regułami `ufw-user-input`. Standardowe `ufw allow` nie filtruje portów kontenerów
  • Właściwe zabezpieczenie (Defense in Depth): Należy powiązać porty w `compose.yml` z konkretnym adresem IP (np. `127.0.0.1:8000:8000` za reverse proxy) lub zdefiniować reguły w łańcuchu `DOCKER-USER` w iptables
Zasada Defense in Depth a Docker: Standardowy UFW nie blokuje ruchu do portów opublikowanych przez Dockera! Aby ograniczyć dostęp do portu 8000, 514 i 162 wyłącznie do podsieci zarządzającej (Management VLAN), przypisz porty w compose.yml do konkretnego IP interfejsu administracyjnego lub zastosuj reguły w łańcuchu DOCKER-USER.
Krok 19 – Konfiguracja sieci hosta i zapory ogniowej UFW Krok 19 – Konfiguracja sieci hosta i zapory ogniowej UFW Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 24 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 25/35
Krok 20 – Przygotowanie urządzeń: Agent snmpd na Linux
Cel slajdu: Konfiguracja agenta SNMP w monitorowanym serwerze Linux pod kątem odpytywania z Dockera.

Uruchomienie agenta SNMP na hoście docelowym (Odniesienie: Wykład 2).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 20 – Przygotowanie urządzeń: Agent snmpd na Linux.

  • Instalacja agenta: Polecenie na monitorowanym serwerze: sudo apt install -y snmpd
  • Edycja pliku /etc/snmp/snmpd.conf: Dodanie wiersza: rocommunity mojanazwa <IP_serwera_Docker>/32 - wstaw faktyczny adres IP swojego serwera, np. 192.168.1.10
  • Identyfikacja systemu: Wprowadzenie: syslocation Serwerownia A oraz syscontact admin@firma.pl
  • Restart demona: Polecenie: sudo systemctl restart snmpd && sudo systemctl enable snmpd
Test komunikacji z wnętrza kontenera:
docker compose exec librenms snmpwalk -v2c -c mojanazwa 192.168.1.50 system
Powinno zwrócić sysDescr, sysUpTime i sysName zgodnie z Wykładem 2 i 3.
Krok 20 – Przygotowanie urządzeń: Agent snmpd na Linux Krok 20 – Przygotowanie urządzeń: Agent snmpd na Linux Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 25 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 26/35
Krok 21 – Przygotowanie urządzeń: MikroTik RouterOS
Cel slajdu: Włączenie obsługi SNMP na routerze MikroTik w celu monitorowania łączy, CPU i temperatur.

Konfiguracja agenta SNMP w systemie RouterOS (Odniesienie: Wykład 2).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 21 – Przygotowanie urządzeń: MikroTik RouterOS.

  • Włączenie usługi SNMP: Komenda RouterOS: /snmp set enabled=yes contact="admin@firma.pl" location="Szafa RACK 1"
  • Utworzenie bezpiecznej społeczności: Komenda: /snmp community add name=mojanazwa addresses=<IP_serwera_Docker>/32 read-access=yes - wstaw faktyczny adres IP serwera, np. 192.168.1.10/32
  • Wyłączenie domyślnej społeczności public: Komenda: /snmp community disable [find name=public]
  • Konfiguracja pułapek (Traps): Komenda: /snmp set trap-community=mojanazwa trap-version=2 trap-target=<IP_serwera_Docker>
Zalecenie z Wykładu 2: Zawsze wyłączaj domyślną społeczność "public". Pozostawienie jej włączonej umożliwia każdemu użytkownikowi sieci LAN odczyt konfiguracji i tablic routingu routera.
Krok 21 – Przygotowanie urządzeń: MikroTik RouterOS Krok 21 – Przygotowanie urządzeń: MikroTik RouterOS Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 26 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 27/35
Krok 22 – Dodanie pierwszego urządzenia przez Web UI
Cel slajdu: Praktyczna procedura rejestracji węzła sieciowego w panelu LibreNMS.

Rejestracja urządzenia w systemie NMS (Odniesienie: Wykład 4).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 22 – Dodanie pierwszego urządzenia przez Web UI.

  • Nawigacja w panelu: Wybierz menu: Devices -> Add Host (w starszych wersjach przycisk nazywał się Add Device)
  • Wprowadzenie adresu: Pole Hostname: wpisz adres IP urządzenia (np. 192.168.1.1)
  • Wybór protokołu i wersji: Pole SNMP: włączone, SNMP Version: v2c (lub v3)
  • Poświadczenia dostępowe: Pole Community: wpisz skonfigurowaną wcześniej społeczność (mojanazwa)
  • Zapis i autodetekcja: Kliknij przycisk 'Add Host' - LibreNMS natychmiast wyśle testowy pakiet GetRequest
Proces Auto-Discovery (Wykład 4): W momencie dodania hosta LibreNMS odczytuje obiekt sysObjectID, automatycznie rozpoznaje model sprzętu (logo MikroTik/Cisco/Linux) i ładuje odpowiednie szablony sensorów.
Krok 22 – Dodanie pierwszego urządzenia przez Web UI Krok 22 – Dodanie pierwszego urządzenia przez Web UI Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 27 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 28/35
Krok 23 – Dodawanie urządzeń przez wiersz poleceń CLI (lnms)
Cel slajdu: Automatyzacja rejestracji urządzeń z poziomu konsoli serwera za pomocą narzędzia lnms.

Masowe dodawanie urządzeń za pomocą poleceń CLI.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 23 – Dodawanie urządzeń przez wiersz poleceń CLI (lnms).

  • Narzędzie lnms w kontenerze: Oficjalny interfejs CLI LibreNMS dostępny w kontenerze librenms
  • Składnia polecenia: docker compose exec librenms lnms device:add --v2c -c mojanazwa 192.168.1.1 (przetestowane: Added device 192.168.1.1 (3))
  • Masowe dodawanie skryptem Bash: Jedno wywołanie kontenera z pętlą wewnątrz, patrz przykład obok - szybsze niż docker compose exec w pętli
  • Wymuszenie natychmiastowego discovery: Polecenie: docker compose exec librenms lnms device:discover 192.168.1.1. Argumentem jest spec urządzenia: device_id, nazwa hosta, maszka *, odd, even lub all
  • Raport z urządzeń: Polecenie: docker compose exec librenms lnms report:devices -i (nie istnieje pod komendą device:list - sprawdź listę komend poleceniem lnms list)
Skrypt automatyzacji z Wykładu 3 i 5:
docker compose exec librenms bash -c 'for ip in 10.0.0.{1..10}; do
  lnms device:add --v2c -c mojanazwa $ip
done'
Uwaga: ostatni znak to cudzysłów, nie myślnik. Cała pętla wykonuje się w jednym kontenerze.
Krok 23 – Dodawanie urządzeń przez wiersz poleceń CLI (lnms) Krok 23 – Dodawanie urządzeń przez wiersz poleceń CLI (lnms) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 28 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 29/35
Krok 24 – Weryfikacja zbierania danych SNMP (wykresy RRD)
Cel slajdu: Kontrola pierwszego cyklu odpytywania i weryfikacja poprawności generowania wykresów.

Ocena poprawności pracy pollera i bazy RRDtool (Odniesienie: Wykład 1 i 3).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 24 – Weryfikacja zbierania danych SNMP (wykresy RRD).

  • Ręczne uruchomienie odpytywania: Polecenie testowe: docker compose exec librenms lnms device:poll 192.168.1.1
  • Analiza wyjścia pollera: Sprawdzenie czasu wykonania (np. Polled in 1.45s) oraz liczby odpytanych modułów MIB
  • Weryfikacja w przeglądarce: Przejdź do zakładki: Devices -> All Devices -> Wybierz urządzenie -> Graphs
  • Wykresy portów sieciowych: Weryfikacja pojawienia się wykresów ruchu Inbound/Outbound na interfejsach
Matematyka liczników (Wykład 3): Pierwszy punkt na wykresie pojawi się dopiero po drugim cyklu pollingu (po 5 minutach), ponieważ NMS musi obliczyć różnicę liczników (Delta Octets) podzieloną przez czas!
Krok 24 – Weryfikacja zbierania danych SNMP (wykresy RRD) Krok 24 – Weryfikacja zbierania danych SNMP (wykresy RRD) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 29 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 30/35
Krok 25 – Przetestowanie odbioru logów Syslog
Cel slajdu: Weryfikacja przepływu komunikatów ze zdalnych urządzeń do kontenera syslog-ng i interfejsu WWW.

Test integracji protokołu Syslog (Odniesienie: Wykład 6).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 25 – Przetestowanie odbioru logów Syslog.

  • Wymóg wstępny (aktywacja Syslog w LibreNMS): Upewnij się, że w pliku ./librenms/config.d/syslog.yaml ustawiono enable_syslog: true (lub wykonano docker compose exec librenms lnms config:set enable_syslog true). Bez tej opcji menu Overview → Syslog nie pojawi się w interfejsie WWW!
  • Wysłanie testowego logu z Linuksa: Polecenie: logger --rfc3164 -n <IP_serwera_Docker> -P 514 -p local0.warning -t AWARIA "Awaria zasilania w węźle A". Flaga --rfc3164 jest istotna - patrz ramka poniżej
  • Wysłanie testowego logu z MikroTik: Komenda RouterOS: /log warning "Testowy komunikat awarii dla LibreNMS" (router musi mieć skonfigurowaną akcję remote kierującą na port 514)
  • Podgląd w panelu LibreNMS: Przejdź do menu: Overview -> Syslog lub karty konkretnego urządzenia w zakładce Logs
  • Filtrowanie zdarzeń: Wyszukiwanie po poziomie ważności (Severity: Warning/Error) oraz treści komunikatu
Aktywacja i format RFC 3164 (Wykład 6): Po pierwsze, pamiętaj o aktywacji modułu przez syslog.yaml. Po drugie, domyślne polecenie logger na nowszym Ubuntu wysyła format RFC 5424, podczas gdy kontener syslog-ng LibreNMS oczekuje formatu RFC 3164. Zastosowanie logger --rfc3164 gwarantuje, że pole programu (np. AWARIA) zostanie poprawnie wyodrębnione, a w komunikacie znajdzie się sama treść.
Krok 25 – Przetestowanie odbioru logów Syslog Krok 25 – Przetestowanie odbioru logów Syslog Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 30 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 31/35
Krok 26 – Przetestowanie odbioru pułapek SNMP Traps
Cel slajdu: Symulacja zdarzenia krytycznego i weryfikacja odbioru pułapki przez kontener snmptrapd.

Testowanie asynchronicznego kanału alarmowego (Odniesienie: Wykład 3).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 26 – Przetestowanie odbioru pułapek SNMP Traps.

  • Wysłanie pułapki testowej: Polecenie: snmptrap -v2c -c mojanazwa 127.0.0.1:162 '' 1.3.6.1.6.3.1.1.5.3 '' s "Test pułapki z kontenera". Uwaga: snmptrap musi być uruchomiony na serwerze, w sposób umożliwiający wysłanie pakietu na port 162
  • Symulacja na przełączniku: Fizyczne odłączenie kabla sieciowego od portu switcha (wyzwolenie pułapki linkDown)
  • Weryfikacja w logach kontenera: Polecenie: docker compose logs -f snmptrapd (odczyt odebranego pakietu trap)
  • Podgląd w zdarzeniach LibreNMS: Przejście do zakładki: Overview -> Events (tabela eventlog). W LibreNMS 26.x nie istnieje osobna tabela traps - zdarzenia trafiają do tabeli eventlog
Pułapka linkDown (Wykład 3): Standardowa pułapka SNMP zdefiniowana w MIB-2, opisana w RFC 1157 oraz rozwinięta w RFC 1215 (RFC 3416 definiuje jednostki PDU SNMPv2, a nie zestaw pułapek). Wysyłana jest w ułamku sekundy po utracie sygnału nośnego (carrier detect) na porcie fizycznym.
Krok 26 – Przetestowanie odbioru pułapek SNMP Traps Krok 26 – Przetestowanie odbioru pułapek SNMP Traps Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 31 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 32/35
Krok 27 – Skalowanie wydajności: powielanie pollerów Dispatcher
Cel slajdu: Horyzontalne skalowanie mocy obliczeniowej stosu kontenerów w dużych sieciach.

Skalowanie horyzontalne architektury NMS (Odniesienie: Wykład 4 i 5).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 27 – Skalowanie wydajności: powielanie pollerów Dispatcher.

  • Wąskie gardło pojedynczego pollera: Przy około 1000 urządzeń i większej liczbie interfejsów pojedynczy kontener nie zdąży odpytać wszystkich węzłów w 300 sekund
  • Wymagana edycja compose.yml: Przed skalowaniem trzeba usunąć z definicji usługi dispatcher dwie linie: container_name: librenms_dispatcher oraz hostname: librenms-dispatcher. Dopóki są obecne, polecenie --scale kończy się błędem. Zmienna DISPATCHER_NODE_ID też musi zniknąć, bo skrypt startowy podstawia wtedy identyfikator z pliku .env każdego węzła
  • Skalowanie za pomocą Docker Compose: Wykonanie polecenia: docker compose up -d --scale dispatcher=3
  • Koordynacja przez Redis: Broker Redis automatycznie rozdziela pakiety zadań pomiędzy trzy niezależne kontenery Dispatcher, każdy z własnym identyfikatorem węzła
  • Monitoring wydajności pollingu: Weryfikacja w Web UI: menu Settings -> Poller -> Poller (podgląd obciążenia węzłów roboczych)
Skalowalność z Wykładu 5: Dzięki temu, że wolumen ./librenms jest współdzielony, a stan zadań koordynuje Redis, możemy w kilka sekund potroić przepustowość odpytywania bez restartowania bazy i serwera WWW. Warunkiem jest wcześniejsze usunięcie z compose.yml wartości container_name, hostname i DISPATCHER_NODE_ID, bo inaczej Docker nie pozwoli utworzyć instancji o powtarzającej się nazwie, a wszystkie węzły przyjmą ten sam identyfikator. Test na stosie: po usunięciu tych trzech wpisów polecenie --scale uruchomiło trzy kontenery o nazwach librenms-dispatcher-1, -2 i -3.
Krok 27 – Skalowanie wydajności: powielanie pollerów Dispatcher Krok 27 – Skalowanie wydajności: powielanie pollerów Dispatcher Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 32 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 33/35
Krok 28 – Procedura tworzenia kopii zapasowej (Backup)
Cel slajdu: Kompletna strategia zabezpieczania danych telemetrycznych i konfiguracji systemu NMS.

Procedura Disaster Recovery dla stosu LibreNMS (Odniesienie: Wykład 5).

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 28 – Procedura tworzenia kopii zapasowej (Backup).

  • Kopia bazy danych MariaDB: Zrzut SQL z kontenera: docker compose exec -T db mysqldump -u librenms -p"$MYSQL_PASSWORD" librenms | gzip > backup_db.sql.gz
  • Kopia wykresów i konfiguracji: Archiwizacja katalogu danych: tar czf backup_librenms_data.tar.gz ./librenms
  • Kopia plików konfiguracyjnych: Archiwizacja plików: tar czf backup_config.tar.gz compose.yml .env librenms.env (tar zapisuje pliki ukryte, jeśli podamy je jawnie)
  • Skrypt automatyzacji w Cron: Cykliczne wykonywanie kopii o godzinie 02:00 w nocy i transfer na zdalny serwer (rsync/S3)
Skrypt szybkiego backupu:
set -a; . ./.env; set +a
docker compose exec -T db mysqldump -u librenms -p"$MYSQL_PASSWORD" librenms | gzip > /backup/librenms_$(date +%F).sql.gz
tar czf /backup/rrd_$(date +%F).tar.gz /opt/librenms-docker/librenms/rrd
Uwaga: flaga -T jest konieczna, aby Docker nie rezerwował terminala; bez hasła podanego bezpośrednio po -p mysqldump zapyta o nie interaktywnie i zablokuje skrypt cron.
Krok 28 – Procedura tworzenia kopii zapasowej (Backup) Krok 28 – Procedura tworzenia kopii zapasowej (Backup) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 33 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 34/35
Krok 29 – Aktualizacja stosu i rozwiązywanie problemów (Troubleshooting)
Cel slajdu: Procedura bezpiecznej aktualizacji kontenerów oraz drzewo decyzyjne w przypadku awarii.

Utrzymanie i diagnozowanie problemów w środowisku Docker.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Krok 29 – Aktualizacja stosu i rozwiązywanie problemów (Troubleshooting).

  • Procedura aktualizacji: Krok 1: docker compose pull && Krok 2: docker compose up -d (kontener aplikacji automatycznie wykonuje migracje schematu bazy)
  • Problem 1: Błąd 'Permission denied' w logach: Rozwiązanie: wykonanie sudo chown -R 1000:1000 /opt/librenms-docker/librenms
  • Problem 2: Brak wykresów (RRD nan): Rozwiązanie: test snmpwalk z kontenera, weryfikacja czy agent odpowiada w czasie timeoutu
  • Problem 3: Kontener wciąż się restartuje: Rozwiązanie: inspekcja docker compose logs <nazwa_usługi> celem lokalizacji błędu SQL
  • Problem 4: Pułapki nie docierają do serwera: Rozwiązanie: sprawdź, czy urządzenie wysyła pakiety na adres osiągalny z Twojej sieci (NAT i zapora mogą blokować UDP 162), oraz czy społeczność pułapek zgadza się z trap-community na urządzeniu
Rollback w Dockerze (Wykład 5): Tag obrazu jest zapisany wprost w compose.yml (image: librenms/librenms:latest) i dotyczy wszystkich czterech kontenerów z tego obrazu: aplikacji WWW, dispatchera, syslog-ng i snmptrapd. Przed aktualizacją warto zmienić :latest na konkretny, przetestowany tag, np. :24.10.0 - wtedy powrót do poprzedniej wersji sprowadza się do edycji jednej linii i polecenia docker compose up -d.
Krok 29 – Aktualizacja stosu i rozwiązywanie problemów (Troubleshooting) Krok 29 – Aktualizacja stosu i rozwiązywanie problemów (Troubleshooting) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 34 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
Slajd 35/35
Podsumowanie wdrożenia i produkcyjna lista kontrolna (Checklist)
Cel slajdu: Syntetyczne podsumowanie zrealizowanych kroków oraz lista kontrolna przed oddaniem systemu do eksploatacji.

Podsumowanie wdrożenia i oddanie systemu do eksploatacji w centrum NOC.

W tym module skupiamy się na praktycznym wdrożeniu zagadnienia: Podsumowanie wdrożenia i produkcyjna lista kontrolna (Checklist).

  • Architektura stosu: Uruchomiono 7 współpracujących mikroserwisów w izolowanej sieci Docker
  • Zabezpieczenie sieci: Porty 8000, 514 i 162 ograniczone do podsieci zarządzania (pamiętając o powiązaniu portów w Compose lub regułach `DOCKER-USER`, gdyż Docker omija standardowy UFW)
  • Obsługa protokołów: Zintegrowano odpytywanie SNMPv2c/v3, odbiór logów Syslog (z aktywnym `syslog.yaml` i formatem RFC 3164) oraz pułapek SNMP Traps
  • Niezawodność i audyt: Wdrożono automatyczny backup bazy, klucza `APP_KEY`, konfiguracji `config.d` i wolumenów RRD oraz zweryfikowano spójność skryptem validate.php
Cel wdrożeniowy: Po zrealizowaniu niniejszego przewodnika uruchomiony zostaje kompletny system monitorowania sieci, gotowy do nadzorowania infrastruktury. Przed przekazaniem go do eksploatacji należy przejść checklistę bezpieczeństwa i sprawdzić dostępność usług wyłącznie z autoryzowanych adresów.
Podsumowanie wdrożenia i produkcyjna lista kontrolna (Checklist) Podsumowanie wdrożenia i produkcyjna lista kontrolna (Checklist) Krok wdrożeniowy • Procedura instalacyjna • Docker Compose Linux Status: krok 35 / 35 Odniesienie do kursu • Wykłady NMS (1 do 6) • Architektura i protokoły Zgodność: standardy IETF Kontekst techniczny i konfiguracja • Środowisko: mikroserwisy Docker (Web, MariaDB, Redis, Dispatcher, Syslog, Traps) • Zastosowanie: bezpieczne, powtarzalne i wysoce dostępne monitorowanie sieci Architektura mikroserwisów LibreNMS
← Poprzednia prezentacja Następna prezentacja →