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
Konteneryzacja i orkiestracja systemów NMS
Cel slajdu: Przedstawienie paradygmatu konteneryzacji w inżynierii monitoringu sieci oraz korzyści z wdrożenia wielokontenerowego stosu NMS z wykorzystaniem Docker i Docker Compose.

Wprowadzenie do konteneryzacji NMS

Współczesna inżynieria sieciowa odchodzi od tradycyjnych, monolitycznych instalacji na rzecz kontenerów, co eliminuje konflikty bibliotek, gwarantuje powtarzalność środowisk i umożliwia wdrożenie podejścia Infrastructure as Code (IaC).

  • Izolacja i powtarzalność: Uruchamianie komponentów NMS w dedykowanych kontenerach ze ściśle zdefiniowanymi wersjami PHP, bibliotek SNMP i bazy MariaDB
  • Orkiestracja za pomocą Docker Compose: Deklaratywny opis całej architektury sieciowej w jednym pliku konfiguracyjnym YAML
  • Separacja stanu od logiki (Stateless Containers): Oddzielenie ulotnych kontenerów wykonawczych od trwałych wolumenów bazodanowych i plików RRD
  • Skalowalność horyzontalna pollerów: Możliwość natychmiastowego zwielokrotnienia kontenerów odpytujących (dispatcher) przy rozroście infrastruktury
Infrastruktura jako kod (Infrastructure as Code - IaC): Metodologia zarządzania infrastrukturą IT, w której topologia serwerów, konfiguracja usług, sieci i pamięci masowej jest opisana w plikach tekstowych (np. docker-compose.yml), podlegających wersjonowaniu w systemie Git.
Konteneryzacja systemów NMS Konteneryzacja i orkiestracja systemów NMS Docker Engine • Izolacja procesów • Przestrzenie nazw (namespaces) • Limity zasobów cgroups Współdzielone jądro Linux Docker Compose • Stos mikroserwisów • Plik docker-compose.yml • Izolowane sieci mostkowe Zarządzanie deklaratywne Stos LibreNMS • Kontener Web / API • Baza MariaDB + Redis • Poller Dispatcher Sidecars: trap & syslog Cel modułu: Od instalacji monolitycznych do infrastruktury jako kod (IaC) • Wdrożenie kompletnego, odpornego na awarie systemu NMS z wykorzystaniem oficjalnych obrazów OCI. • Separacja danych trwałych (wolumeny RRD i bazy SQL) od bezstanowych kontenerów obliczeniowych. • Automatyzacja skalowania horyzontalnego pollerów i bezprzestojowych aktualizacji oprogramowania.
Slajd 2/55
Spis treści prezentacji 5
Cel slajdu: Przedstawienie struktury tematycznej modułu poświęconego konteneryzacji systemów NMS, orkiestracji wielousługowej oraz procedurom utrzymania produkcyjnego.

Wprowadzenie do konteneryzacji NMS

Prezentacja została ustrukturyzowana w cztery logiczne bloki tematyczne, prowadzące studenta od fundamentów mechanizmów jądra Linux po zaawansowane laboratoria wdrożeniowe.

  • Część 1: Architektura Docker i stos LibreNMS: Mechanizmy cgroups i namespaces, pliki docker-compose.yml, bazy MariaDB/Redis, konfiguracja .env
  • Część 2: Skalowanie, usługi i bezpieczeństwo: Horyzontalne skalowanie pollerów, odbiór Syslog i trapów SNMP, sieci Docker Bridge, ochrona sekretów
  • Część 3: Wdrożenie produkcyjne i sizing: Kalkulacja zasobów serwera, VLANy zarządzające, integracja ze sprzętem Cisco i MikroTik
  • Część 4: Laboratoria, telemetria i AIOps: Prometheus i Grafana w kontenerach, 6 ćwiczeń warsztatowych, słownik pojęć i weryfikacja wiedzy
Metodyka pracy laboratoryjnej: Zaleca się równoległe uruchomienie maszyny wirtualnej z systemem Linux Ubuntu 24.04 LTS lub Debian 12 w celu natychmiastowego testowania prezentowanych komend w wierszu poleceń.
Plan prezentacji 5 Plan prezentacji 5: Konteneryzacja NMS (55 slajdów) 1. Fundamenty Docker i Stos LibreNMS • Wirtualizacja vs kontenery (cgroups/ns) • Docker Compose, YAML, MariaDB, Redis, .env 2. Skalowanie, Sieci i Bezpieczeństwo • Dispatcher, Syslog-ng, SNMP Traps, Oxidized • Docker Networks, bridge vs host, rootless, sekrety 3. Wdrożenie Produkcyjne i Sizing • Podman, Kubernetes, sizing serwera • Management VLAN, konfiguracja MikroTik/Cisco 4. Laboratoria i Nowoczesne Trendy • Prometheus + Grafana w Compose, NetBox • 6 ćwiczeń praktycznych krok po kroku Struktura dydaktyczna modułu: Od teorii przestrzeni nazw jądra Linux, przez konfigurację Compose i bezpieczeństwo, aż po praktyczne laboratoria wdrożeniowe, disaster recovery, słownik i pytania kontrolne.
Slajd 3/55
Dlaczego kontenery w monitorowaniu sieci?
Cel slajdu: Zrozumienie inżynierskich i operacyjnych przyczyn zastąpienia instalacji monolitycznych architekturą kontenerową w systemach zarządzania siecią.

Wprowadzenie do konteneryzacji NMS

Systemy NMS to złożone aplikacje wielokomponentowe. Tradycyjna instalacja na poziomie systemu operacyjnego wiąże się ze znacznym ryzykiem awarii podczas aktualizacji pakietów.

  • Rozwiązanie problemu zależności (Dependency Hell): Każdy mikroserwis (Nginx, PHP-FPM, MariaDB, Redis) posiada własne, odizolowane środowisko wykonawcze
  • Niezmienność środowiska (Immutable Infrastructure): Obraz kontenera jest identyczny w środowisku testowym inżyniera i na serwerze produkcyjnym w serwerowni
  • Błyskawiczne procedury Disaster Recovery: Odtworzenie całego systemu NMS po awarii sprzętowej serwera wymaga jedynie skopiowania konfiguracji i wolumenów danych
  • Prostota aktualizacji i natychmiastowy rollback: Aktualizacja polega na pobraniu nowego obrazu; powrót do wersji stabilnej to zmiana jednej linii tekstu w konfiguracji
Zasada pojedynczej odpowiedzialności (Single Responsibility): Każdy kontener w architekturze powinien realizować dokładnie jeden proces systemowy (jeden kontener dla serwera WWW, jeden dla bazy danych, osobny dla brokera wiadomości).
Dlaczego kontenery w NMS Zalety konteneryzacji systemów NMS Instalacja Monolityczna • Konflikty wersji PHP i bazy • Zanieczyszczenie systemu OS • Trudny, ryzykowny rollback • Ręczna konfiguracja cron/daemons Konteneryzacja Docker • Izolacja każdego procesu • Niezmienne obrazy (Immutable) • Rollback w 5 sekund • Proste skalowanie horyzontalne Efekt Biznesowy • Czas wdrożenia: < 5 min • Zero przestojów przy update • Łatwa replikacja w DR • Zgodność z metodyką CI/CD # Porównanie procedury aktualizacji oprogramowania: • Monolit: apt-get dist-upgrade -> ryzyko uszkodzenia zależności PHP/bazy -> awaria monitoringu na godziny. • Docker: docker compose pull && docker compose up -d -> nowy kontener wstaje w 10 sekund z zachowaniem danych. • W razie wykrycia błędu: zmiana tagu w pliku compose i natychmiastowy powrót do poprzedniej wersji. Brak konieczności ręcznego debugowania pakietów systemowych na serwerze produkcyjnym.
Slajd 4/55
Wirtualizacja (VM) a konteneryzacja (Docker)
Cel slajdu: Przedstawienie różnic architektonicznych między pełną wirtualizacją sprzętową a konteneryzacją na poziomie jądra systemu operacyjnego.

Wprowadzenie do konteneryzacji NMS

Zrozumienie przewagi Dockera nad tradycyjnymi maszynami wirtualnymi wymaga analizy sposobu interakcji procesów aplikacji ze sprzętem i jądrem systemu Linux.

  • Architektura maszyn wirtualnych (Hypervisor): Każda maszyna wirtualna uruchamia kompletny system operacyjny (Guest OS) z własnym jądrem, co generuje olbrzymi narzut RAM i CPU
  • Architektura kontenerowa (Docker Engine): Wszystkie kontenery współdzielą jedno jądro systemu hosta (Host Kernel); aplikacja to odizolowany proces w przestrzeni użytkownika
  • Mechanizm izolacji: Namespaces: Przestrzenie nazw jądra Linux izolują procesy (`pid`), sieć (`net`), użytkowników (`user`) oraz punkty montowania dysków (`mnt`)
  • Mechanizm limitowania: Control Groups (cgroups): Grupy kontrolne jądra przydzielają i twardo egzekwują limity zużycia rdzeni CPU, pamięci RAM oraz operacji wejścia-wyjścia dysku
Narzut wydajnościowy (Overhead): Kontenery nie emulują sprzętu ani nie uruchamiają wirtualnego BIOS-u. Kod maszynowy aplikacji kontenerowej wykonuje się bezpośrednio na fizycznym procesorze z zerowym narzutem obliczeniowym.
Wirtualizacja vs Konteneryzacja Architektura: Wirtualizacja sprzętowa (VM) vs Konteneryzacja Maszyny Wirtualne (KVM / ESXi) App 1 (NMS) Guest OS (Ubuntu) App 2 (DB) Guest OS (Debian) Hypervisor (Typu 1 lub 2) System Host / Jądro Sprzęt Fizyczny (CPU, RAM, Dysk) Kontenery Docker Engine Kontener NMS Web Tylko binaria i libs Kontener MariaDB Tylko binaria i libs Docker Engine (cgroups + namespaces) Wspólne Jądro Linux (Host Kernel) Sprzęt Fizyczny (CPU, RAM, Dysk) Porównanie parametrów technicznych: • Narzut pamięciowy: VM marnuje 1-2 GB RAM na każdy Guest OS; Kontener zużywa 0 MB dodatkowego RAM. • Czas startu: Maszyna wirtualna = 30-90 sekund; Kontener Docker = < 1 sekunda (zwykły proces systemowy). • Wydajność I/O dysku i sieci: W kontenerze brak emulacji urządzeń wirtualnych – natywna szybkość jądra.
Slajd 5/55
Podstawowe pojęcia technologii Docker
Cel slajdu: Opanowanie kluczowej terminologii ekosystemu kontenerowego: obrazów, kontenerów, rejestrów, wolumenów oraz wirtualnych sieci mostkowych.

Fundamenty technologii Docker

Środowisko Docker opiera się na precyzyjnym podziale ról pomiędzy statycznymi szablonami aplikacji (obrazami) a ich działającymi instancjami (kontenerami).

  • Obraz kontenera (Docker Image): Niezmienny, wielowarstwowy pakiet tylko do odczytu, zawierający kod aplikacji, biblioteki systemowe, pliki konfiguracyjne i zmienne środowiskowe
  • Kontener (Container): Działająca, odizolowana instancja obrazu z cienką warstwą zapisu (Read-Write Layer), posiadająca własne ID, procesy i wirtualny adres IP
  • Rejestr obrazów (Docker Registry): Centralny serwer dystrybucji obrazów (np. publiczny Docker Hub lub prywatny GitHub Packages / Harbor)
  • Wolumeny i sieci (Volumes & Networks): Komponenty infrastrukturalne zapewniające odpowiednio trwałość danych po zniszczeniu kontenera oraz komunikację TCP/UDP
Warstwowy system plików (UnionFS): Jeśli 5 kontenerów korzysta z tego samego obrazu bazowego Alpine Linux, obraz ten jest przechowywany na dysku tylko raz. Każdy kontener dopisuje jedynie swoje unikalne zmiany w pamięci i warstwie tymczasowej.
Pojęcia technologii Docker Elementy składowe ekosystemu Docker 1. Obraz (Image) • Tylko do odczytu (Read-Only) • Szablon z binariami i libs • Warstwy (OverlayFS) np. librenms/librenms:latest 2. Kontener (Container) • Działająca instancja obrazu • Warstwa zapisu (Read-Write) • Posiada własne IP i procesy Ulotny stan (ephemeral) 3. Rejestr (Registry) • Docker Hub / GitHub GHCR • Magazyn gotowych obrazów • Wersjonowanie tagami docker pull / push # Trwałość danych i komunikacja (Persistence & Networking): • Wolumen (Volume): Zarządzany przez Dockera obszar na dysku hosta (/var/lib/docker/volumes). Gwarantuje, że skasowanie kontenera NIE usuwa bazy danych ani plików metryk RRD. • Sieć kontenerowa (Network): Wirtualny przełącznik programowy (bridge) łączący mikroserwisy. Wbudowany serwer DNS Dockera pozwala na odwoływanie się po nazwach usług (np. 'mysql', 'redis'). Specyfikacja OCI (Open Container Initiative) definiuje otwarty standard formatu obrazów.
Slajd 6/55
Instalacja silnika Docker na serwerze Linux
Cel slajdu: Przedstawienie prawidłowej procedury instalacji środowiska Docker Engine oraz wtyczki Docker Compose v2 z oficjalnych repozytoriów producenta.

Fundamenty technologii Docker

Dla zapewnienia stabilności i wsparcia dla najnowszych funkcji formatu Compose v2 należy unikać przestarzałych pakietów dystrybucyjnych i korzystać z oficjalnego repozytorium Docker Inc.

  • Usunięcie pakietów legacy: Odinstalowanie przestarzałych pakietów `docker.io` oraz skryptu Pythona `docker-compose` v1
  • Bezpieczeństwo repozytorium GPG: Weryfikacja podpisów cyfrowych pakietów za pomocą klucza `/etc/apt/keyrings/docker.asc`
  • Nowoczesna wtyczka Compose v2: Zastąpienie starego polecenia `docker-compose` natywną wtyczką kompilowaną w języku Go: `docker compose`
  • Zarządzanie uprawnieniami grupy docker: Dodanie konta administratora do grupy systemowej `docker` w celu eliminacji konieczności prefiksu `sudo`
Uprawnienia grupy docker a bezpieczeństwo: Członkostwo w grupie docker jest równoważne z uprawnieniami roota w systemie, ponieważ pozwala na zamontowanie głównego systemu plików / w kontenerze. Dostęp do grupy powinien być ściśle kontrolowany.
Instalacja Docker Engine Instalacja Docker Engine i Compose na Ubuntu 24.04 LTS # 1. Usunięcie nieoficjalnych pakietów dystrybucyjnych: $ sudo apt-get remove -y docker.io docker-doc docker-compose podman-docker # 2. Dodanie oficjalnego klucza GPG i repozytorium Docker: $ sudo install -m 0755 -d /etc/apt/keyrings $ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc $ echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \ https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 3. Instalacja silnika Docker, containerd i wtyczki Compose: $ sudo apt-get update && sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # 4. Nadanie uprawnień użytkownikowi bez konieczności używania sudo: $ sudo usermod -aG docker $USER && newgrp docker $ docker compose version # Docker Compose version v2.29.2 (współczesna zintegrowana wtyczka CLI)
Slajd 7/55
Podstawowe polecenia wiersza poleceń Docker CLI
Cel slajdu: Nabycie praktycznych umiejętności operowania kontenerami i obrazami za pomocą wiersza poleceń Dockera.

Fundamenty technologii Docker

Biegłe operowanie interfejsem CLI Dockera jest niezbędne do inspekcji, diagnostyki i ręcznego testowania komponentów systemu monitoringu.

  • Pobieranie i uruchamianie (`pull`, `run`): Flagi `-d` (uruchomienie w tle jako demon) oraz `-p host:container` (mapowanie portu TCP/UDP)
  • Nadzór stanu i inspekcja (`ps`, `inspect`): Identyfikacja kontenerów po nazwie lub unikalnym hashu SHA, odczyt adresacji IP i statusu procesu
  • Śledzenie dzienników zdarzeń (`logs`): Parametr `-f` (follow) działający analogicznie do polecenia `tail -f`, kluczowy przy diagnozowaniu błędów startu NMS
  • Interaktywna powłoka (`exec`): Przełączniki `-it` pozwalają na wejście do wnętrza kontenera i bezpośrednie wykonanie skryptów administracyjnych PHP
Przydatna komenda: docker stats: Polecenie docker stats działa jak uniksowy top dla kontenerów, wyświetlając w czasie rzeczywistym procentowe zużycie procesora, pamięć RAM oraz wolumen danych przesłanych przez interfejsy sieciowe.
Polecenia Docker CLI Podstawowe polecenia wiersza poleceń Docker CLI # 1. Pobieranie obrazu z rejestru Docker Hub: $ docker pull librenms/librenms:latest # 2. Uruchomienie kontenera w tle (-d) z mapowaniem portu (-p): $ docker run -d --name test-nms -p 8000:8000 librenms/librenms:latest # 3. Wyświetlenie listy aktywnych kontenerów: $ docker ps # (użyj -a, aby zobaczyć również zatrzymane) # 4. Podgląd logów aplikacji w czasie rzeczywistym (-f): $ docker logs -f --tail=50 test-nms # 5. Wykonanie polecenia wewnątrz działającego kontenera (-it): $ docker exec -it test-nms lnms --version # 6. Monitorowanie zużycia zasobów (CPU, RAM, Sieć I/O): $ docker stats --no-stream # 7. Zatrzymanie i usunięcie kontenera: $ docker stop test-nms && docker rm test-nms
Slajd 8/55
Docker Compose – orkiestracja wielokontenerowa
Cel slajdu: Zrozumienie zasady działania narzędzia Docker Compose jako deklaratywnego silnika orkiestracji wielousługowych systemów monitoringu.

Docker Compose w środowisku NMS

Próba ręcznego zarządzania kilkoma kontenerami za pomocą poleceń `docker run` szybko prowadzi do chaosu konfiguracyjnego. Docker Compose automatyzuje ten proces za pomocą deklaratywnego pliku YAML.

  • Deklaratywny model architektury: Zamiast sekwencji poleceń powłoki inżynier definiuje stan docelowy infrastruktury w pliku `docker-compose.yml`
  • Jednolity cykl życia aplikacji: Pojedyncza komenda `docker compose up -d` tworzy wirtualną sieć, alokuje wolumeny i uruchamia wszystkie usługi w poprawnej kolejności
  • Zarządzanie zależnościami (`depends_on`): Możliwość wskazania, że kontener aplikacji webowej nie może wystartować przed pełnym zainicjalizowaniem bazy MariaDB
  • Separacja środowiskowa: Każdy projekt w Compose otrzymuje własną odizolowaną przestrzeń nazw sieciowych i nazw wolumenów opartą na nazwie katalogu
Orkiestracja (Orchestration): Zautomatyzowany proces konfigurowania, koordynowania i zarządzania współpracą wielu powiązanych ze sobą kontenerów tworzących jedną spójną aplikację.
Docker Compose w NMS Orkiestracja mikroserwisów za pomocą Docker Compose docker-compose.yml • Deklaratywny plik YAML • Definicje 5+ mikroserwisów • Zależności depends_on • Wspólne sieci i wolumeny Wersjonowany w Git up -d Uruchomiony Stos NMS (Spójna Sieć Bridge) librenms Port :8000 db (MariaDB) Baza danych redis Kolejka zadań dispatcher (Poller) Odpytywanie SNMP snmptrapd / syslog Odbiór zdarzeń UDP # Podstawowe komendy zarządzania całym stosem aplikacji: $ docker compose up -d # Uruchamia wszystkie kontenery w tle zgodnie z zależnościami $ docker compose ps # Wyświetla stan i kody wyjścia wszystkich mikrousług stosu $ docker compose restart app # Restartuje wyłącznie kontener aplikacji webowej $ docker compose down # Zatrzymuje i usuwa kontenery, zachowując wolumeny z danymi Koniec z ręcznym uruchamianiem dziesiątek komend docker run z długimi flagami.
Slajd 9/55
Składnia i struktura pliku compose.yml (docker-compose.yml)
Cel slajdu: Szczegółowa analiza składni języka YAML oraz kluczowych dyrektyw konfiguracyjnych pliku Compose dla środowisk sieciowych.

Docker Compose w środowisku NMS

Plik `compose.yml` (lub tradycyjnie `docker-compose.yml`) jest fundamentem wdrożenia kontenerowego. Jego składnia opiera się na hierarchicznych wcięciach spacjami i precyzyjnych słowach kluczowych.

  • Sekcja `services`: Definicja poszczególnych kontenerów mikroserwisów, ich obrazów bazowych oraz nazw kontenerów
  • Polityka restartu (`restart: always`): Instrukcja wymuszająca automatyczne podniesienie kontenera w przypadku awarii procesu lub restartu serwera fizycznego
  • Mapowanie portów i wolumenów: Składnia `host:kontener` dla portów sieciowych (`8000:8000`) oraz trwałych wolumenów dyskowych
  • Zmienne środowiskowe i zależności: Dyrektywy `environment` przekazujące parametry oraz `depends_on` definiujące kolejność startu
Rygor formatowania YAML: Pliki YAML nie tolerują znaków tabulacji (TAB). Wszystkie wcięcia muszą być wykonane za pomocą spacji (najczęściej 2 spacje na poziom zagłębienia). Użycie tabulacji spowoduje natychmiastowy błąd parsowania.
Struktura docker-compose.yml Anatomia pliku konfiguracyjnego docker-compose.yml # Główny szkielet specyfikacji Compose (Compose File Specification): services: librenms: image: librenms/librenms:latest container_name: librenms_app restart: always ports: [ "8000:8000" ] volumes: [ "nms_rrd:/opt/librenms/rrd", "nms_data:/data" ] environment: [ "DB_HOST=db", "DB_NAME=librenms" ] depends_on: [ db, redis ] volumes: # Definicja trwałych wolumenów danych nms_rrd: { driver: local } nms_data: { driver: local } networks: # Definicja izolowanej podsieci mostkowej nms_net: { driver: bridge, ipam: { config: [{ subnet: 172.28.0.0/16 }] } }
Slajd 10/55
Oficjalny stos LibreNMS Docker – przegląd architektury
Cel slajdu: Przedstawienie architektury mikroserwisów oficjalnego stosu kontenerowego LibreNMS oraz podziału zadań pomiędzy wyspecjalizowane kontenery.

Stos technologiczny LibreNMS Docker

Twórcy LibreNMS utrzymują oficjalne repozytorium obrazów kontenerowych librenms/docker, implementujące wzorzec architektury rozproszonej (Microservices & Sidecars).

  • Kontener główny (`librenms`): Odpowiada za serwer WWW (Nginx), logikę biznesową w PHP-FPM, interfejs API oraz wykonywanie migracji schematu bazy danych
  • Kontener bazy relacyjnej (`db`): Oficjalny obraz MariaDB zoptymalizowany pod kątem kodowania UTF8MB4 i wysokiej liczby operacji transakcyjnych
  • Kontener pamięci podręcznej (`redis`): Służy jako szybki broker wiadomości w pamięci RAM do kolejkowania zadań pollowania i autoodkrywania
  • Kontenery pomocnicze (Sidecars): Dedykowane kontenery `dispatcher` (odpytywanie SNMP), `snmptrapd` (odbiór pułapek) oraz `syslog-ng` (centralizacja logów)
Wzorzec Sidecar (Wózek boczny): Wzorzec architektoniczny, w którym funkcje pomocnicze (np. zbieranie logów, odbiór trapów) są wydzielone do osobnych kontenerów działających obok głównej aplikacji i współdzielących z nią zasoby.
Stos kontenerowy LibreNMS Architektura oficjalnego stosu LibreNMS w kontenerach librenms (Główna Aplikacja) • Nginx + PHP-FPM 8.3 • Web GUI, REST API, Crons Port :8000 -> Host db (MariaDB 10.11) • Tabela urządzeń, alertów • Kodowanie utf8mb4 Wolumen: db_data redis (Broker Zadań) • Pamięć podręczna RAM • Kolejki odpytywania Blokada wyścigów (Lock) dispatcher (Poller) Pobiera zadania z Redis Wielowątkowe SNMP snmptrapd (Trapy) Nasłuch UDP 162 Zapis do eventlog syslog-ng (Dziennik) Nasłuch UDP/TCP 514 Centralizacja logów Oficjalne repozytorium projektu: https://github.com/librenms/docker Architektura Sidecar: Kontenery zadaniowe (dispatcher, snmptrapd) współdzielą wolumen /opt/librenms/rrd z kontenerem aplikacji webowej przez montowanie 'volumes_from'.
Slajd 11/55
Konfiguracja usługi bazy danych: MariaDB w kontenerze
Cel slajdu: Przedstawienie inżynierskiej konfiguracji kontenera MariaDB dla LibreNMS z uwzględnieniem kodowania znaków, optymalizacji silnika InnoDB oraz bezpieczeństwa sieciowego.

Stos technologiczny LibreNMS Docker

Baza relacyjna przechowuje inwentarz urządzeń, konfigurację reguł alertowych, użytkowników oraz logi zdarzeń. Jej konfiguracja wymaga spełnienia ścisłych wymagań projektowych.

  • Dobór wersji silnika (MariaDB 10.11 LTS): Stosowanie oficjalnych wydań o długoterminowym wsparciu technicznym gwarantuje stabilność schematu bazy
  • Kodowanie znaków UTF8MB4: Wymóg flag `--character-set-server=utf8mb4` oraz `--collation-server=utf8mb4_unicode_ci` dla pełnej obsługi znaków międzynarodowych
  • Optymalizacja InnoDB: Flaga `--innodb-file-per-table=1` zapobiega rozrastaniu się jednego pliku ibdata1 i ułatwia późniejsze odzyskiwanie przestrzeni dyskowej
  • Izolacja sieciowa bazy: Port TCP 3306 nie powinien być mapowany na adres publiczny serwera; baza ma być dostępna wyłącznie dla kontenerów w sieci wewnętrznej
Trwałość danych bazy: Ścieżka /var/lib/mysql wewnątrz kontenera MUSI być zmapowana do trwałego wolumenu zewnętrznego (np. ./db_data). Usunięcie kontenera bez wolumenu powoduje bezpowrotną utratę całej konfiguracji sieci i użytkowników!
Konfiguracja MariaDB w Compose Konfiguracja kontenera bazy danych MariaDB # Fragment compose.yml dla usługi bazy danych: db: image: mariadb:10.11 container_name: librenms_db restart: always environment: - MARIADB_RANDOM_ROOT_PASSWORD=yes - MARIADB_USER=${MYSQL_USER:-librenms} - MARIADB_PASSWORD=${MYSQL_PASSWORD} - MARIADB_DATABASE=${MYSQL_DATABASE:-librenms} volumes: [ "./db_data:/var/lib/mysql" ] command: - "mysqld" - "--innodb-file-per-table=1" - "--character-set-server=utf8mb4" - "--collation-server=utf8mb4_unicode_ci" healthcheck: test: ["CMD", "healthcheck.sh", "--connect"] # Healthcheck jest wymagany przez 'service_healthy' w kontenerze librenms.
Slajd 12/55
Konfiguracja głównego kontenera: LibreNMS Web
Cel slajdu: Przedstawienie struktury konfiguracyjnej głównego kontenera LibreNMS, montowania wolumenów aplikacyjnych oraz sterowania stanem gotowości usług zależnych.

Stos technologiczny LibreNMS Docker

Kontener `librenms` stanowi serce aplikacji webowej. Odpowiada za serwowanie interfejsu graficznego dla operatorów, realizację zapytań REST API oraz orkiestrację crona.

  • Wystawienie portu webowego (`ports: 8000:8000`): Dostęp do panelu administracyjnego pod adresem IP serwera z możliwością wdrożenia przed nim Nginx Reverse Proxy z SSL
  • Separacja zmiennych (`env_file`): Wczytywanie poświadczeń i opcji systemowych z dedykowanego pliku `.env`, chronionego uprawnieniami systemowymi
  • Montowanie katalogu danych `/data`: Przechowywanie unikalnych kluczy szyfrujących frameworka Laravel (`APP_KEY`), wtyczek oraz logów systemowych
  • Zaawansowane warunki gotowości (`service_healthy`): Kontener czeka z uruchomieniem do momentu, aż baza MariaDB przejdzie test spójności (Healthcheck)
Klucz aplikacji APP_KEY: W katalogu /data generowany jest unikalny klucz APP_KEY. Służy on do szyfrowania haseł użytkowników SNMP v3 w bazie danych. Jeśli katalog ten zostanie utracony, odszyfrowanie poświadczeń urządzeń będzie niemożliwe.
Konfiguracja LibreNMS Web Konfiguracja kontenera aplikacji LibreNMS Web UI # Konfiguracja głównej usługi w docker-compose.yml: librenms: image: librenms/librenms:latest container_name: librenms hostname: librenms ports: [ "8000:8000" ] env_file: [ "./librenms.env" ] volumes: - "./librenms_data:/data" - "./rrd_data:/opt/librenms/rrd" depends_on: db: { condition: service_healthy } redis: { condition: service_started } restart: always # Kontener posiada wbudowany serwer Nginx nasłuchujący na porcie 8000.
Slajd 13/55
Konfiguracja usług wspierających: Redis i RRDcached
Cel slajdu: Zrozumienie roli brokera Redis oraz demona RRDcached w optymalizacji wydajności i skalowalności skonteneryzowanego systemu NMS.

Stos technologiczny LibreNMS Docker

Podstawowymi barierami wydajnościowymi w systemach monitoringu są: narzut kolejkowania zadań w relacyjnej bazie SQL oraz losowy zapis tysięcy plików metryk na dysku.

  • Rola bazy in-memory Redis: Przechowywanie dynamicznych kolejek pollerów w RAM; eliminuje obciążanie bazy MariaDB milionami zapytań o status kolejki
  • Blokady wielowątkowe (Distributed Locks): Zapobieganie sytuacji, w której dwa różne wątki pollerów odpytują równocześnie to samo urządzenie sieciowe
  • Demon buforujący RRDcached: Zbiera modyfikacje próbek w pamięci operacyjnej i zrzuca je na dysk w zoptymalizowanych blokach co zadany czas (np. 1800 s)
  • Ochrona nośników pamięci masowej: Drastyczne ograniczenie zużycia komórek pamięci dysków SSD/NVMe (TBW) w środowiskach z dziesiątkami tysięcy portów
Parametry WRITE_TIMEOUT i WRITE_JITTER: WRITE_TIMEOUT=1800 określa, jak długo RRDcached może buforować zapis w pamięci RAM. WRITE_JITTER=1800 losowo rozprasza zapis w czasie, zapobiegając jednoczesnemu zamrożeniu dysku (I/O Spike).
Redis i RRDcached w Compose Architektura pamięci podręcznej: Redis i RRDcached Usługa Redis (In-Memory Broker) • Przechowywanie kolejek zadań pollerów • Blokady wielowątkowe (Distributed Locks) • Ekstremalnie niski czas dostępu (RAM) Brak zapisu na dysk: ultra-wydajność Port wewnętrzny: :6379 Usługa RRDcached (Bufor I/O) • Agregacja wpisów metryk w pamięci RAM • Zapis sekwencyjny dużymi partiami (Flush) • Redukcja operacji losowych IOPS o 85% Ochrona nośników SSD przed zużyciem Gniazdo UNIX lub TCP :42217 # Konfiguracja rrdcached w pliku docker-compose.yml: rrdcached: image: librenms/rrdcached:latest environment: [ "WRITE_TIMEOUT=1800", "WRITE_JITTER=1800", "WRITE_THREADS=4" ] volumes: [ "./rrd_data:/data/db" ] # Bufor przetrzymuje dane w RAM do 30 minut, eliminując lawinowy zapis dyskowy.
Slajd 14/55
Zarządzanie zmiennymi środowiskowymi: plik .env
Cel slajdu: Opanowanie metodyki bezpiecznej konfiguracji stosu kontenerowego poprzez separację kodu od zmiennych środowiskowych w pliku .env.

Stos technologiczny LibreNMS Docker

Zgodnie z metodologią The Twelve-Factor App, cała zmienna konfiguracja wdrożeniowa (hasła, strefy czasowe, limity pamięci) powinna być przechowywana w zmiennych środowiskowych, a nie wewnątrz kodu aplikacji.

  • Separacja poświadczeń od kodu: Plik `docker-compose.yml` zawiera wyłącznie definicje architektury, a hasła i loginy są wczytywane z pliku `.env`
  • Standaryzacja strefy czasowej (`TZ=Europe/Warsaw`): Kluczowy parametr gwarantujący idealną synchronizację czasu między zdarzeniami w bazie a wykresami
  • Mapowanie uprawnień dyskowych (`PUID/PGID`): Ujednolicenie identyfikatorów UID/GID użytkownika w kontenerze z użytkownikiem hosta eliminuje błędy `Permission Denied`
  • Dostrajanie parametrów interpretera PHP: Dynamiczne zwiększanie limitów `MEMORY_LIMIT` oraz `MAX_INPUT_VARS` bez konieczności edycji plików `php.ini`
Ochrona pliku .env: Plik .env musi zostać bezwzględnie dopisany do pliku .gitignore przed wykonaniem pierwszego commita w systemie Git. Wyciek pliku do publicznego repozytorium oznacza ujawnienie haseł do bazy danych!
Zmienne w pliku .env Konfiguracja środowiskowa w pliku .env (The 12-Factor App) # Przykładowy plik konfiguracyjny .env (uprawnienia chmod 600): TZ=Europe/Warsaw # Precyzyjna strefa czasowa dla wykresów i logów PUID=1000 # Identyfikator UID użytkownika hosta dla plików RRD PGID=1000 # Identyfikator GID grupy hosta dla plików RRD # Konfiguracja dostępu do bazy MariaDB: MYSQL_DATABASE=librenms MYSQL_USER=librenms MYSQL_PASSWORD=SilneHasloBazy123! # Ustawienia optymalizacyjne LibreNMS: MEMORY_LIMIT=2048M # Limit pamięci RAM dla procesu PHP MAX_INPUT_VARS=10000 # Wymagane dla edycji dużych reguł alertowych CACHE_DRIVER=redis # Użycie kontenera Redis jako backendu cache SESSION_DRIVER=redis # Bezpieczne sesje użytkowników w Redis LIBRENMS_WEATHERMAP=true # Automatyczna aktywacja wtyczki Weathermap # Plik .env NIGDY nie może zostać wypchnięty do publicznego repozytorium Git!
Slajd 15/55
Uruchomienie stosu LibreNMS krok po kroku
Cel slajdu: Przećwiczenie pełnej procedury wdrożeniowej stosu LibreNMS za pomocą Docker Compose od pobrania plików po pierwsze logowanie.

Procedura wdrożeniowa

Prawidłowa sekwencja wdrożenia gwarantuje bezbłędną inicjalizację bazy danych oraz automatyczne utworzenie niezbędnych wolumenów i uprawnień systemowych.

  • Pobranie szablonu wdrożeniowego: Klonowanie oficjalnego repozytorium GitHub oraz przejście do katalogu z przykładami Compose
  • Personalizacja parametrów bezpieczeństwa: Uzupełnienie pliku `.env` silnymi hasłami oraz dostosowanie lokalnej strefy czasowej
  • Start orkiestracji (`docker compose up -d`): Automatyczne pobranie warstw obrazów OCI, utworzenie sieci `bridge` i start kontenerów w tle
  • Śledzenie logów inicjalizacyjnych: Monitorowanie pierwszego uruchomienia skryptu migracji tabel bazy danych (`lnms migrate`) w kontenerze aplikacji
Czas pierwszego uruchomienia: Pierwszy start może zająć od 1 do 3 minut, ponieważ aplikacja musi utworzyć ponad 200 tabel w pustej bazie MariaDB. Kolejne restarty trwają już poniżej 10 sekund.
Uruchomienie stosu krok po kroku Procedura uruchomienia stosu LibreNMS krok po kroku Krok 1: Przygotowanie • Pobranie repozytorium • Skopiowanie szablonu .env • Wygenerowanie haseł chmod 600 .env Krok 2: Uruchomienie • docker compose up -d • Pobranie warstw OCI • Inicjalizacja MariaDB Migracje tabel Laravel Krok 3: Weryfikacja • docker compose ps • http://IP_SERWERA:8000 • Pierwsze logowanie validate.php w kontenerze # Sekwencja komend powłoki Bash do uruchomienia stosu produkcyjnego: $ git clone https://github.com/librenms/docker.git /opt/librenms-docker $ cd /opt/librenms-docker/examples/compose && cp librenms.env .env $ nano .env # Ustawienie MYSQL_PASSWORD, TZ=Europe/Warsaw, PUID/PGID $ docker compose up -d # Monitorowanie inicjalnych migracji schematu bazy danych: $ docker compose logs -f librenms # Gdy pojawi się komunikat "Nginx started", system jest gotowy do pracy pod portem 8000.
Slajd 16/55
Weryfikacja działania i diagnostyka kontenerów
Cel slajdu: Opanowanie metod inspekcji stanu mikrousług, weryfikacji kodów wyjścia oraz diagnozowania spójności systemu LibreNMS za pomocą polecenia validate.php w kontenerze.

Procedura wdrożeniowa

Wdrożenie kontenerowe wymaga regularnej weryfikacji stanu zdrowia (Health Status) usług oraz integralności bazy danych i pollerów.

  • Inspekcja stanu mikrousług (`docker compose ps`): Sprawdzenie statusu `Up (healthy)` potwierdzającego poprawność działania pętli diagnostycznych
  • Analiza logów selektywnych (`logs --tail`): Filtrowanie komunikatów o błędach dla konkretnej usługi bez konieczności przeszukiwania logów całego systemu
  • Uruchomienie skryptu validate.php przez exec: Wykonanie wbudowanego audytora spójności LibreNMS wewnątrz środowiska kontenerowego
  • Weryfikacja komunikacji międzykontenerowej: Testowanie rozwiązywania nazw DNS i dostępności gniazd sieciowych pomiędzy kontenerami `librenms`, `db` i `redis`
Szybki restart pojedynczej usługi: Jeśli zmodyfikowano konfigurację bez konieczności przebudowy całego stosu, polecenie docker compose restart librenms restartuje wyłącznie wybrany kontener w ułamku sekundy.
Diagnostyka stanu kontenerów Diagnostyka i weryfikacja stanu kontenerów NMS $ docker compose ps NAME IMAGE COMMAND SERVICE STATUS PORTS librenms_app librenms/librenms:latest "/init" librenms Up 2 hours (healthy) 0.0.0.0:8000->8000/tcp librenms_db mariadb:10.11 "docker-entrypoint.s…" db Up 2 hours (healthy) 3306/tcp librenms_redis redis:7.2-alpine "docker-entrypoint.s…" redis Up 2 hours 6379/tcp librenms_dispatcher librenms/librenms:latest "/init" dispatcher Up 2 hours 8000/tcp # Uruchomienie narzędzia walidacyjnego wewnątrz kontenera aplikacji: $ docker compose exec librenms validate.php ==================================== [OK] Database connection successful [OK] Database Schema is current [OK] MySQl Engine is optimal (InnoDB) [OK] Active Poller Wrapper is running [OK] RRDTool is available and configured ====================================
Slajd 17/55
Wolumeny Docker i trwałość danych (Persistence)
Cel slajdu: Zrozumienie mechanizmów persystencji danych w kontenerach oraz różnic architektonicznych między wolumenami nazwanymi a montowaniem katalogów hosta.

Zarządzanie danymi i persystencja

Domyślnie wszystkie pliki tworzone wewnątrz kontenera są zapisywane w ulotnej warstwie zapisu (Writable Layer) i znikają w momencie jego usunięcia. Trwałość danych wymaga wdrożenia mechanizmu wolumenów.

  • Zasada bezstanowości kontenera: Kontenery obliczeniowe mogą być niszczone i odtwarzane w dowolnym momencie bez wpływu na integralność monitoringu
  • Wolumeny nazwane (Named Volumes): Zasoby dyskowe alokowane w ścieżce `/var/lib/docker/volumes/`, zarządzane poleceniami `docker volume ls/inspect`
  • Montowanie bezpośrednie (Bind Mounts): Wskazanie konkretnego katalogu na dysku hosta (np. `./rrd_data`), ułatwiające bezpośredni backup skryptami zewnętrznymi
  • Katalogi krytyczne LibreNMS: Bezwzględny wymóg persystencji dla trzech zasobów: `/var/lib/mysql`, `/opt/librenms/rrd` oraz `/data`
Kopiowanie przy zapisie (Copy-on-Write - CoW): Technologia systemu plików obrazu Dockera. Warstwy bazowe są niemodyfikowalne; próba modyfikacji pliku powoduje jego skopiowanie do cienkiej warstwy kontenera, co spowalnia operacje zapisu I/O w porównaniu z wolumenem.
Wolumeny Docker w NMS Architektura pamięci trwałej: Docker Volumes vs Bind Mounts Montowanie katalogów (Bind Mounts) • Składnia: ./rrd_data:/opt/librenms/rrd • Bezpośredni katalog na hoście • Łatwy dostęp z poziomu skryptów bash • Wymaga ręcznej kontroli PUID/PGID Wygodne w laboratoriach i małych NMS Wolumeny nazwane (Named Volumes) • Składnia: nms_rrd:/opt/librenms/rrd • W pełni zarządzane przez Docker Engine • Wyższa wydajność I/O na macOS/Windows • Automatyczne uprawnienia i izolacja Standard produkcyjny Enterprise # Trzy krytyczne obszary danych w systemie LibreNMS: 1. Baza danych SQL (/var/lib/mysql): Inwentarz węzłów, użytkownicy, historia zdarzeń eventlog. 2. Baza metryk RRD (/opt/librenms/rrd): Pliki szeregów czasowych z wykresami ruchu i obciążenia. 3. Katalog stanu aplikacji (/data): Unikalny klucz APP_KEY, certyfikaty SSL, definicje wtyczek. Brak zamontowania któregokolwiek z tych zasobów spowoduje utratę danych przy aktualizacji obrazu.
Slajd 18/55
Procedura aktualizacji stosu LibreNMS
Cel slajdu: Przedstawienie standardowej inżynierskiej procedury aktualizacji skonteneryzowanego systemu NMS z minimalizacją czasu przestoju oraz czyszczeniem nieużywanych warstw obrazów.

Zarządzanie danymi i persystencja

W odróżnieniu od skomplikowanych aktualizacji dystrybucji systemowych, aktualizacja stosu Docker Compose sprowadza się do pobrania nowych warstw i błyskawicznej wymiany kontenerów.

  • Pobieranie obrazów w tle (`pull`): Nowe wersje obrazów są pobierane z rejestru podczas normalnej pracy systemu monitoringu bez zakłócania zbierania danych
  • Rekreacja kontenerów (`up -d`): Docker Compose porównuje sumy kontrolne SHA obrazów i restartuje wyłącznie te kontenery, dla których dostępna jest nowsza wersja
  • Automatyczne migracje bazy danych: Skrypt startowy kontenera LibreNMS natychmiast po uruchomieniu aplikuje nowe tabele i indeksy w bazie MariaDB
  • Czyszczenie starych warstw (`image prune`): Usunięcie osieroconych obrazów (dangling images) pozwala odzyskać cenne gigabajty przestrzeni na dyskach SSD
Procedura natychmiastowego wycofania (Rollback): Jeśli po aktualizacji wykryto błąd oprogramowania, wystarczy w pliku docker-compose.yml zmienić tag obrazu z latest na wersję poprzednią (np. 24.8.0) i ponownie wywołać docker compose up -d.
Aktualizacja stosu NMS Procedura bezpiecznej aktualizacji stosu kontenerowego 1. Pobranie obrazów • docker compose pull • Pobranie nowych warstw • Działające usługi aktywne! Zero przestoju w NMS 2. Rekreacja usług • docker compose up -d • Zatrzymanie starej wersji • Start z nowego obrazu Przełączenie: < 5 sekund 3. Porządki • docker image prune • Usunięcie starych warstw • Odzyskanie miejsca Czysty dysk SSD # Kompletna sekwencja aktualizacji produkcyjnego stosu LibreNMS: $ cd /opt/librenms-docker/examples/compose $ docker compose pull # Pobiera nowe obrazy bez zatrzymywania systemu $ docker compose up -d # Automatycznie restartuje TYLKO te kontenery, które mają nowszy obraz # Weryfikacja wykonania migracji w nowej wersji: $ docker compose exec librenms lnms migrate --status # Usunięcie starych, nieużywanych obrazów (zwolnienie przestrzeni dyskowej): $ docker image prune -f
Slajd 19/55
Skalowanie horyzontalne pollerów: Kontenery Dispatcher
Cel slajdu: Zrozumienie mechanizmu rozpraszania obciążenia SNMP na wiele kontenerów dispatcher za pośrednictwem kolejki Redis i polecenia scale w Docker Compose.

Skalowanie i usługi pomocnicze

W miarę rozrostu sieci pojedynczy proces odpytujący nie jest w stanie obsłużyć wszystkich urządzeń w 5-minutowym oknie czasowym. Architektura kontenerowa pozwala na bezwysiłkowe skalowanie horyzontalne.

  • Architektura kolejki zadań w Redis: Zadania odpytania poszczególnych urządzeń trafiają do kolejki w pamięci RAM, skąd są asynchronicznie pobierane przez wolne procesy robocze
  • Elastyczne skalowanie poleceniem `--scale`: Usługa `dispatcher` bazuje na oficjalnym obrazie `librenms/librenms:latest` ze zmienną `SIDECAR_DISPATCHER=1`. Aby skalować ją poleceniem `docker compose up -d --scale dispatcher=4`, definicja usługi w `compose.yml` nie może zawierać sztywnego parametru `container_name`
  • Eliminacja opóźnień (Poller Lag): Zrównoleglenie operacji SNMP UDP redukuje czas trwania cyklu pomiarowego z setek sekund do kilkudziesięciu
  • Współdzielenie wolumenu bazy RRD: Każdy kontener roboczy montuje ten sam wolumen pamięci trwałej lub komunikuje się z centralną usługą RRDcached
Kiedy skalować dispatchery? Jeśli parametr Poller Duration przekracza 240 s (przy oknie 300 s), należy zwiększyć liczbę kontenerów dispatcher. Pamiętaj: flaga --scale zadziała tylko wtedy, gdy usługa nie definiuje stałego container_name.
Skalowanie kontenerów Dispatcher Skalowanie horyzontalne pollerów: Kontenery Dispatcher Kolejka Redis • Zadania pollowania • Lista device_id Blokady wyścigów Port :6379 (RAM) dispatcher_1 (Worker) Wątki: 16 | UDP 161 dispatcher_2 (Worker) Wątki: 16 | UDP 161 dispatcher_3 (Worker) Wątki: 16 | UDP 161 Sieć Korporacyjna • Przełączniki L2/L3 • Routery brzegowe • Punkty dostępowe Wi-Fi Zrównoleglone zapytania # Skalowanie liczby procesów roboczych jedną komendą w Compose: $ docker compose up -d --scale dispatcher=4 System natychmiast powołuje 4 odrębne kontenery pollerów, dzieląc pulę 20 000 OID. Czas trwania cyklu odpytywania spada z 420 s (opóźnienie) do 45 s bez modyfikacji bazy. Współdzielony wolumen nms_rrd montowany jest równolegle we wszystkich instancjach.
Slajd 20/55
Procedury operacyjne w kontenerze – Narzędzie lnms CLI
Cel slajdu: Nabycie praktycznych umiejętności wykonywania zadań administracyjnych i diagnostycznych wewnątrz kontenera aplikacji za pomocą wbudowanego narzędzia lnms CLI.

Skalowanie i usługi pomocnicze

Administratorzy systemów kontenerowych nie muszą ograniczać się do interfejsu graficznego. Narzędzie `lnms` pozwala na pełne zarządzanie systemem drogą wiersza poleceń.

  • Struktura polecenia `docker compose exec`: Bezpieczne przekazanie polecenia do działającego kontenera aplikacji bez konieczności otwierania portów SSH
  • Automatyzacja dodawania węzłów (`device:add`): Możliwość integracji polecenia ze skryptami powłoki na serwerze hosta lub zadaniami Ansible
  • Zarządzanie kontami użytkowników (`user:add`): Błyskawiczne odzyskiwanie dostępu do systemu lub tworzenie kont administracyjnych w trybie offline
  • Diagnostyka niskopoziomowa w powłoce: Możliwość wejścia do wnętrza kontenera (`exec -it`) i bezpośredniego testowania pakietów SNMP narzędziem `snmpwalk`
Alias powłoki dla wygody: W pliku ~/.bashrc na serwerze hosta warto dodać alias: alias dlnms="docker compose -f /opt/librenms-docker/examples/compose/docker-compose.yml exec librenms lnms", co pozwala wywoływać komendy bezpośrednio jako dlnms device:poll ID.
Narzędzie lnms w kontenerze Procedury operacyjne w kontenerze – Narzędzie lnms CLI # 1. Dodanie urządzenia do monitoringu przez CLI kontenera: $ docker compose exec librenms lnms device:add -2 -c LabCommunity 192.168.10.1 # 2. Ręczne wywołanie procesu odkrywania dla wybranego węzła: $ docker compose exec librenms lnms device:poll 192.168.10.1 -vv # 3. Zmiana parametrów konfiguracyjnych w bazie z poziomu CLI: $ docker compose exec librenms lnms config:set alert.default_mail noc@uczelnia.pl # 4. Sprawdzenie stanu migracji schematu relacyjnego bazy: $ docker compose exec librenms lnms migrate --status # 5. Utworzenie nowego konta administratora z wiersza poleceń: $ docker compose exec librenms lnms user:add admin_noc --role admin -p TajneHaslo123 # 6. Wejście do interaktywnej powłoki bash kontenera aplikacji: $ docker compose exec -it librenms bash bash-5.1# snmpwalk -v2c -c LabCommunity 192.168.10.1 sysUpTime.0 # Narzędzia sieciowe fping, snmpwalk, curl są preinstalowane w oficjalnym obrazie.
Slajd 21/55
Centralizacja logów Syslog w kontenerze (syslog-ng)
Cel slajdu: Przedstawienie architektury odbioru strumieni dziennika zdarzeń Syslog za pomocą dedykowanego kontenera syslog-ng oraz mapowania portu sieciowego hosta.

Skalowanie i usługi pomocnicze

W architekturze kontenerowej odbiór logów sieciowych Syslog (RFC 5424) jest realizowany przez wyspecjalizowany kontener pomocniczy `syslog-ng`.

  • Wystawienie portu standardowego (`514:514/udp`): Przełączniki i routery w sieci przesyłają pakiety dziennika bezpośrednio na adres IP serwera fizycznego
  • Izolacja procesu parsowania: Nawet nagły sztorm logów (np. 10 000 wpisów/s przy awarii pętli STP) nie zakłóca pracy interfejsu webowego LibreNMS
  • Automatyczna korelacja z bazą urządzeń: Demon parsuje adres IP nadawcy i natychmiast przypisuje logi do właściwego rekordu `device_id`
  • Wyzwalanie alertów w czasie rzeczywistym: Możliwość zdefiniowania reguł alertowych reagujących na wzorce wyrażeń regularnych w treści logu
Wydajność zapisu Syslog: W sieciach powyżej 200 urządzeń tabela syslog rośnie w tempie milionów rekordów dziennie. W pliku .env należy ustawić parametr retencji, np. $config['syslog_purge'] = 14;, aby baza nie wyczerpała pamięci dyskowej.
Mikroserwis syslog-ng Centralizacja logów Syslog w mikroserwisie syslog-ng Źródła Syslog • Przełączniki Cisco • Routery MikroTik • Serwery Linux Port UDP / TCP 514 syslog-ng (Sidecar) • Nasłuch na porcie 514 • Parsowanie RFC 5424 • Buforowanie w RAM Wstrzykiwanie do bazy Tabela syslog • device_id powiązane • Priorytet i severity • Widok w GUI NMS Alerty Regex w NMS # Konfiguracja mikroserwisu syslog-ng w compose.yml: syslog-ng: image: librenms/librenms:latest container_name: librenms_syslogng ports: [ "514:514/udp", "514:514/tcp" ] environment: [ "SIDECAR_SYSLOGNG=1" ] # Oficjalny obraz uruchamia demona syslog-ng dzięki zmiennej SIDECAR_SYSLOGNG=1.
Slajd 22/55
Odbiór pułapek SNMP Traps w kontenerze (snmptrapd)
Cel slajdu: Przedstawienie metodyki asynchronicznego odbioru zdarzeń SNMP Trap z wykorzystaniem kontenera sidecar, współdzielenia wolumenów oraz mapowania portu UDP 162.

Skalowanie i usługi pomocnicze

Domyślny model odpytywania cyklicznego wykrywa awarię z opóźnieniem do 5 minut. Włączenie mikroserwisu snmptrapd redukuje czas reakcji do ułamka sekundy.

  • Port sieciowy UDP 162: Wystawienie portu nasłuchu pułapek SNMP na interfejsie hosta umożliwia routerom natychmiastowe zgłaszanie awarii
  • Tryb Sidecar (`SIDECAR_SNMPTRAPD=1`): Ten sam oficjalny obraz `librenms/librenms:latest` działa w trybie dedykowanego demona odbiorczego pułapek dzięki zmiennej `SIDECAR_SNMPTRAPD=1`
  • Izolacja wątków: Demon snmptrapd odbiera pakiety, tłumaczy OID-y przez MIB-y i wywołuje skrypt parsowania bez obciążania interfejsu WWW
  • Natychmiastowe wyzwalanie reguł alertowych: Zdarzenie zarejestrowane z pułapki natychmiast ewaluuje reguły alarmowe i wysyła powiadomienia Webhook/SMS
SNMP Trap vs SNMP Poll: Polling to odpytywanie synchroniczne inicjowane przez serwer NMS (np. co 300 s). Trap to asynchroniczny alert wysyłany przez urządzenie sieciowe natychmiast w chwili wystąpienia incydentu (np. fizyczne odłączenie kabla linkDown).
Mikroserwis snmptrapd Asynchroniczny odbiór pułapek SNMP w kontenerze snmptrapd Awaria w Sieci • linkDown / BGP peer • Zasilacz UPS padł Pakiet SNMP Trap Port UDP 162 snmptrapd (Sidecar) • Nasłuch na UDP :162 • Weryfikacja Community • Tłumaczenie OID przez MIB skrypt snmptrap.php Reakcja Systemu • Wpis w eventlog • Natychmiastowy alert • Brak czekania 5 min! Czas reakcji: < 1 s # Konfiguracja kontenera snmptrapd w pliku compose.yml: snmptrapd: image: librenms/librenms:latest environment: [ "SIDECAR_SNMPTRAPD=1" ] ports: [ "162:162/udp" ] depends_on: { db: { condition: service_healthy } } # Obraz librenms uruchamia demona snmptrapd dzięki zmiennej SIDECAR_SNMPTRAPD=1.
Slajd 23/55
Kopie konfiguracji sieci – Kontener Oxidized
Cel slajdu: Przedstawienie integracji mikroserwisu Oxidized ze stosem LibreNMS w celu automatycznego pobierania, wersjonowania w Git i wizualizacji zmian konfiguracji urządzeń.

Skalowanie i usługi pomocnicze

Zarządzanie konfiguracją (Configuration Management w modelu FCAPS) wymaga automatycznego archiwizowania konfiguracji sprzętu sieciowego. W kontenerach standardem jest narzędzie Oxidized.

  • Pobieranie inwentarza przez API LibreNMS: Oxidized nie wymaga ręcznego definiowania listy urządzeń – pobiera je automatycznie z punktu końcowego API NMS
  • Dedykowany kontener wykonawczy: Usługa loguje się na przełączniki i routery protokołem SSH, pobiera konfigurację (running-config) i maskuje hasła
  • Automatyczne wersjonowanie w repozytorium Git: Każda wykryta zmiana konfiguracji powoduje utworzenie nowego commita w lokalnym lub zdalnym repozytorium Git
  • Wizualizacja różnic (Diff View) w GUI LibreNMS: Operator widzi bezpośrednio w karcie urządzenia kolorowe porównanie zmian: usunięte linie na czerwono, dodane na zielono
Wykrywanie nieautoryzowanych zmian: Połączenie pułapek SNMP trap `ciscoConfigManEvent` z kontenerem Oxidized pozwala na natychmiastowe pobranie konfiguracji w sekundę po wpisaniu komendy write memory przez administratora.
Mikroserwis Oxidized Automatyczny backup konfiguracji sieciowej z kontenerem Oxidized LibreNMS • Inwentarz urządzeń • REST API endpoint • Widok zakładki Config Wizualizacja zmian Diff API Kontener Oxidized • Pobiera listę węzłów • Logowanie SSH / Telnet • Zrzut konfiguracji Port API: :8888 Repozytorium Git • Historia wersji • Git commit per zmiana • Kto zmienił i kiedy Wolumen: /root/.config # Konfiguracja integracji w docker-compose.yml: oxidized: image: oxidized/oxidized:latest volumes: [ "./oxidized_data:/root/.config/oxidized" ] environment: [ "CONFIG_RELOAD_INTERVAL=3600" ] # LibreNMS automatycznie odpytuje kontener Oxidized na porcie 8888 i wyświetla diff w GUI.
Slajd 24/55
Sieci kontenerowe (Docker Networking) dla NMS
Cel slajdu: Zrozumienie działania sterowników sieciowych Dockera (bridge, host, macvlan) oraz przepływu ruchu telemetrycznego i izolacji wirtualnych portów.

Sieci kontenerowe i bezpieczeństwo

Domyślnym i zalecanym modelem sieciowym w Docker Compose jest sieć typu Bridge, tworząca prywatny wirtualny przełącznik wewnątrz jądra systemu operacyjnego.

  • Sterownik Bridge Network: Tworzy dedykowany interfejs mostka (np. `br-xxx`) na hoście; każdy kontener otrzymuje wirtualną parę interfejsów `veth`
  • Wbudowany demon DNS Dockera (127.0.0.11): Automatyczne rozwiązywanie nazw usług w sieci projektu; kontener łączy się z bazą podając nazwę `db` zamiast adresu IP
  • Translacja adresów źródłowych (SNAT / MASQUERADE): Pakiety SNMP wysyłane przez kontener do fizycznych routerów są tłumaczone na adres IP fizycznej karty sieciowej hosta
  • Selektywne mapowanie portów wejściowych (DNAT): Na zewnątrz wystawiane są wyłącznie porty niezbędne (`8000/tcp`, `514/udp`, `162/udp`); pozostałe są całkowicie niewidoczne z LAN
Wirtualna para interfejsów (veth pair): Konstrukcja jądra Linux działająca jak wirtualny kabel krosowy: jeden koniec (`veth`) jest wpięty do wirtualnego przełącznika mostka na hoście, a drugi koniec (`eth0`) znajduje się wewnątrz przestrzeni nazw kontenera.
Sieci kontenerowe Docker Bridge Wirtualne sieci kontenerowe (Docker Networking) dla NMS Wirtualny Mostek Programowy (Docker Bridge: nms_net, 172.28.0.0/16) librenms 172.28.0.2 veth0 -> bridge db (MariaDB) 172.28.0.3 veth1 -> bridge redis 172.28.0.4 veth2 -> bridge Wbudowany DNS 127.0.0.11 Rozwiązuje nazwy # Interfejs fizyczny serwera hosta: eth0 (IP: 192.168.1.100/24) • Wychodzące zapytania SNMP: Kontener (172.28.0.2) -> NAT (iptables MASQUERADE) -> eth0 -> Switch. • Przychodzący ruch webowy: Przeglądarka -> 192.168.1.100:8000 -> DNAT (docker-proxy) -> 172.28.0.2:8000. • Izolacja: Usługi db i redis NIE są dostępne z sieci fizycznej 192.168.1.0/24 (brak mapowania portów). Wirtualny przełącznik programowy bridge w jądrze Linux gwarantuje pełną separację podsieci.
Slajd 25/55
Analiza trybu network_mode: host vs dedykowany bridge
Cel slajdu: Inżynierskie porównanie parametrów wydajnościowych, narzutu jądra oraz ryzyk bezpieczeństwa przy wyborze trybu sieci kontenerowej.

Sieci kontenerowe i bezpieczeństwo

Dobór trybu sieciowego w pliku Compose ma bezpośredni wpływ na wydajność akwizycji danych telemetrycznych oraz bezpieczeństwo usług bazodanowych.

  • Tryb domyślny Bridge: Gwarantuje hermetyczną izolację usług, lecz wymaga przejścia pakietów przez tablicę śledzenia połączeń `nf_conntrack` i translację NAT
  • Tryb bezpośredni Host (`network_mode: host`): Kontener współdzieli przestrzeń sieciową z serwerem fizycznym; brak narzutu wirtualnego przełącznika
  • Problem saturacji tablicy conntrack: W gigantycznych sieciach wysyłanie dziesiątek tysięcy pakietów UDP fping/SNMP w ciągu sekund potrafi przepełnić tablicę `nf_conntrack`
  • Ryzyko kolizji portów w trybie host: Dwie usługi nie mogą korzystać z tego samego portu TCP/UDP na serwerze fizycznym; utrata separacji adresowej
Rekomendacja inżynierska: Dla 95% wdrożeń NMS standardowa sieć bridge z dedykowaną podsiecią jest w zupełności wystarczająca. Tryb host stosuje się wyłącznie w dedykowanych węzłach odpytujących (Distributed Pollers) w sieciach operatorskich ISP.
Bridge vs Host Network Analiza architektoniczna: network_mode: host vs bridge Tryb Domyślny: bridge • Pełna izolacja sieciowa • Brak kolizji portów między usługami • Wbudowany DNS service discovery • Narzut NAT (conntrack) przy >10k OID/s • Pakiety ICMP fping wymagają CAP_NET_RAW Zalecany dla 95% wdrożeń NMS Tryb Bezpośredni: host • Zerowy narzut sieciowy (Zero Overhead) • Maksymalna szybkość dla fping i SNMP • Natywne odbieranie broadcastów L2 • Całkowity brak izolacji portów! • Port 8000 zajmuje port fizycznego hosta Stosowany w ultraszybkich pollerach ISP # Kiedy warto rozważyć tryb network_mode: host? 1. Skrajnie duża sieć: > 50 000 odpytywanych interfejsów na minutę, gdzie tablica conntrack ulega saturacji. 2. Odbiór pakietów rozgłoszeniowych autoodkrywania (CDP/LLDP RAW sockets) bezpośrednio z karty sieciowej. Architektura hybrydowa: Baza MariaDB i Redis w sieci bridge, a tylko dispatcher w trybie host.
Slajd 26/55
Bezpieczeństwo kontenerów – Standardy CIS i Docker Rootless
Cel slajdu: Opanowanie inżynierskich zasad utwardzania (hardening) środowiska kontenerowego NMS zgodnie ze standardami CIS Benchmark oraz dyrektywą NIS 2.

Sieci kontenerowe i bezpieczeństwo

Serwer NMS posiada dostęp SNMP i SSH do wszystkich węzłów infrastruktury teleinformatycznej. Przełamanie jego zabezpieczeń stanowiłoby bezpośrednie zagrożenie dla całej organizacji.

  • Zasada najmniejszych uprawnień (Least Privilege): Odrzucenie zbędnych uprawnień jądra (`cap_drop: ALL`) i przyznanie jedynie `NET_RAW` dla testów pingu ICMP
  • Blokada eskalacji uprawnień (`no-new-privileges`): Zabezpieczenie przed próbami podniesienia uprawnień procesu wewnątrz kontenera poprzez binaria z bitem SUID
  • Architektura Docker Rootless: Uruchomienie całego demona Dockera w przestrzeni zwykłego użytkownika bez uprawnień roota w systemie operacyjnym hosta
  • Automatyczne skanowanie podatności (CVE): Integracja narzędzi audytowych (Trivy, Docker Scout) w celu wykrywania luk w bibliotekach PHP, OpenSSL i MariaDB
Zakaz używania flagi --privileged: Flaga privileged: true całkowicie wyłącza mechanizmy izolacji cgroups i AppArmor, dając procesowi w kontenerze bezpośredni dostęp do urządzeń sprzętowych hosta. Nigdy nie stosuj jej w NMS!
Bezpieczeństwo kontenerów CIS Standardy bezpieczeństwa kontenerów NMS (CIS Benchmark) 1. Tryb Rootless • Demon dockerd bez root • User namespaces jądra • Przełamanie kontenera Brak uprawnień na hoście 2. Ograniczanie Praw • cap_drop: [ "ALL" ] • cap_add: [ "NET_RAW" ] • no-new-privileges:true Minimalne uprawnienia 3. Skanowanie Podatności • Docker Scout / Trivy • Analiza CVE bibliotek • Weryfikacja bazy NVD Zgodność z NIS 2 # Zabezpieczenie kontenera aplikacji w docker-compose.yml: security_opt: - no-new-privileges:true # Blokuje eskalację uprawnień przez bity SUID cap_drop: [ "ALL" ] # Odrzuca wszystkie uprawnienia jądra Linux cap_add: [ "NET_RAW", "NET_BIND_SERVICE" ] # Zezwala wyłącznie na ICMP fping i port <1024 Zgodność ze standardem Center for Internet Security (CIS Docker Benchmark v1.6).
Slajd 27/55
Zarządzanie sekretami produkcyjnymi (Secrets Management)
Cel slajdu: Przedstawienie standardów bezpiecznego przekazywania wrażliwych poświadczeń do kontenerów za pomocą mechanizmu Docker Secrets i sufiksów _FILE.

Sieci kontenerowe i bezpieczeństwo

Przekazywanie haseł do bazy danych lub poświadczeń SNMP v3 w czystym tekście przez zmienne środowiskowe `environment:` jest uznawane za błąd bezpieczeństwa w audytach ISO 27001.

  • Podatność zmiennych środowiskowych: Zmienne przekazane w `environment` są widoczne dla każdego użytkownika wykonującego `docker inspect` oraz w plikach `/proc/PID/environ`
  • Mechanizm Docker Secrets: Poświadczenia są montowane jako wirtualne pliki w pamięci operacyjnej RAM (ścieżka `/run/secrets/`) bez zapisu na dysku
  • Wzorzec zmiennych `_FILE`: Oficjalne obrazy MariaDB i LibreNMS wspierają odczyt hasła ze wskazanego pliku (np. `MARIADB_PASSWORD_FILE`)
  • Ochrona uprawnień na serwerze hosta: Pliki z sekretami na dysku serwera muszą posiadać restrykcyjne uprawnienia dostępu `chmod 400` lub `chmod 600`
Integracja z HashiCorp Vault: W dojrzałych środowiskach korporacyjnych sekrety są dynamicznie pobierane z zewnętrznego magazynu Vault w momencie startu kontenera, co eliminuje przechowywanie haseł w plikach tekstowych na serwerze.
Docker Secrets w NMS Bezpieczne zarządzanie sekretami w środowisku produkcyjnym Praktyka Niebezpieczna: Plik .env • Hasła zapisane jawnym tekstem • Widoczne w poleceniu docker inspect • Widoczne w procesach systemowych /proc Ryzyko commita hasła do Git! Dopuszczalne tylko w laboratorium Standard Produkcyjny: Docker Secrets • Hasła w plikach montowanych w RAM (tmpfs) • Ścieżka: /run/secrets/db_password • Brak widoczności w zmiennych środowiska Ścisła kontrola uprawnień 0400 Wymóg w środowiskach ISO 27001 # Konfiguracja Docker Secrets w pliku docker-compose.yml: services: db: secrets: [ db_password ] environment: [ "MARIADB_PASSWORD_FILE=/run/secrets/db_password" ] secrets: db_password: { file: "./secrets/mariadb_pass.txt" }
Slajd 28/55
Monitorowanie wydajności środowiska Docker
Cel slajdu: Przedstawienie narzędzi i metod nadzoru nad samym środowiskiem kontenerowym NMS z wykorzystaniem kontenera cAdvisor oraz integracji z Prometheusem.

Sieci kontenerowe i bezpieczeństwo

System NMS monitoruje sieć, lecz sam również musi podlegać ciągłemu nadzorowi telemetrycznemu. Narzędzie cAdvisor (Container Advisor) bada kondycję kontenerów w czasie rzeczywistym.

  • Odczyt z grup kontrolnych jądra (cgroups): Bezpośrednia analiza zużycia procesora, pamięci podręcznej stron (page cache) oraz operacji dyskowych I/O
  • Natywny format metryk Prometheus: cAdvisor udostępnia punkt końcowy `/metrics` zgodny ze standardem OpenMetrics, gotowy do skrobania
  • Wczesne wykrywanie wycieków pamięci (OOM): Monitorowanie wskaźnika `container_memory_working_set_bytes` pozwala na reakcję zanim mechanizm jądra OOM Killer zabije bazę danych
  • Izolowane montowanie w trybie tylko do odczytu: Wolumeny systemowe (`/sys`, `/var/run`) montowane są z flagą `:ro`, co zapobiega modyfikacji parametrów jądra
Out-Of-Memory (OOM) Killer: Mechanizm jądra Linux, który w sytuacji krytycznego wyczerpania wolnej pamięci RAM bezwzględnie zabija proces zużywający najwięcej pamięci (najczęściej jest to baza danych MariaDB lub poller PHP).
Telemetria cAdvisor Telemetria kontenerów z narzędziem Google cAdvisor Gniazdo Docker • /var/run/docker.sock • Statystyki jądra cgroups • Pamięć RAM, CPU, I/O Zasoby hosta Linux Kontener cAdvisor • gcr.io/cadvisor/cadvisor • Eksport metryk w czasie rzecz. • Agregacja per kontener Port metryk :8080 Prometheus & Grafana • Scrape /metrics • Wykresy zużycia RAM • Alerty o braku pamięci Detekcja OOM Killer # Konfiguracja cAdvisor w docker-compose.yml: cadvisor: image: gcr.io/cadvisor/cadvisor:v0.49.1 volumes: [ "/:/rootfs:ro", "/var/run:/var/run:ro", "/sys:/sys:ro", "/var/lib/docker/:/var/lib/docker:ro" ] ports: [ "8080:8080" ] # Udostępnia metryki Prometheus pod adresem: http://IP_SERWERA:8080/metrics
Slajd 29/55
Alternatywy dla Docker Engine – Podman i Podman Compose
Cel slajdu: Zapoznanie z technologią Podman, architekturą pozbawioną demona oraz wdrażaniem stosów NMS w środowiskach Red Hat Enterprise Linux.

Sieci kontenerowe i bezpieczeństwo

W korporacyjnych dystrybucjach Enterprise Linux (RHEL, CentOS Stream, AlmaLinux, Rocky Linux) domyślnym narzędziem kontenerowym jest Podman.

  • Architektura Daemonless: Podman nie posiada centralnego demona systemowego działającego w tle; uruchomienie kontenera to bezpośrednie wywołanie procesu przez `runc`
  • Natywny tryb Rootless: Zwykły użytkownik bez uprawnień roota może bez problemu pobierać obrazy, tworzyć wolumeny i uruchamiać kontenery NMS
  • Integracja z systemd: Podman potrafi automatycznie wygenerować pliki jednostek `systemd`, co ułatwia nadzór nad restartem usług po restarcie serwera
  • Narzędzie `podman-compose`: Zapewnia pełną zgodność ze standardem plików `docker-compose.yml` bez konieczności modyfikacji konfiguracji
Koncepcja Podów (Pods): Podman wspiera natywnie koncepcję "Podów" znaną z Kubernetesa – grupę kontenerów współdzielących ten sam adres IP i przestrzeń sieciową localhost (np. kontener LibreNMS i kontener bazy danych w jednym Podzie).
Podman vs Docker Alternatywa dla Dockera: Podman i architektura Rootless Architektura Docker • Klient CLI wysyła żądania API • Ciągły demon dockerd w tle (root) • Gniazdo UNIX /var/run/docker.sock Awaria demona = awaria kontenerów Pojedynczy punkt awarii (SPOF) Architektura Podman (Daemonless) • Brak jakiegokolwiek demona w tle • Kontenery to bezpośrednie procesy jądra • Domyślnie 100% rootless (bez roota) Natywna integracja z systemd Standard w RHEL / AlmaLinux / Rocky # Zgodność składniowa: Podman jest bezpośrednim zamiennikiem Dockera: $ alias docker=podman $ podman-compose up -d # Uruchamia ten sam plik docker-compose.yml # Generowanie usługi systemd dla automatycznego startu przy bootowaniu: $ podman generate systemd --name librenms_app > ~/.config/systemd/user/librenms.service Brak konieczności instalowania oprogramowania firm trzecich w korporacyjnych dystrybucjach Red Hat.
Slajd 30/55
Systemy NMS w klastrze Kubernetes
Cel slajdu: Zrozumienie zaawansowanej orkiestracji systemów monitoringu w klastrze Kubernetes, obiektów StatefulSet oraz specyfiki obsługi pamięci masowej dla plików RRD.

Wdrożenie produkcyjne i sizing

W wielkich organizacjach korporacyjnych systemy NMS są migrowane ze środowisk Docker Compose do zarządzanych klastrów Kubernetes (K8s).

  • Obiekt StatefulSet dla bazy MariaDB: Zapewnia stabilne identyfikatory sieciowe oraz dedykowany wolumen dyskowy (PersistentVolume) montowany w trybie RWO
  • Skalowalne wdrożenie Web UI (Deployment): Możliwość dynamicznego zwiększania liczby podów interfejsu WWW za pomocą kontrolera Ingress i mechanizmu HPA
  • Problem wolumenów ReadWriteMany (RWX): Konieczność równoczesnego zapisu plików RRD przez wiele podów pollerów wymaga wydajnych klastrów CephFS lub GlusterFS
  • Zarządzanie instalacją przez Helm Charts: Automatyzacja parametryzacji wdrożenia za pomocą ustandaryzowanych szablonów konfiguracyjnych
NFS a baza RRDtool: Nigdy nie montuj wolumenu RRDtool przez tradycyjny protokół sieciowy NFS v3/v4 w klastrze produkcyjnym. Blokady plików (file locking) przez sieć powodują drastyczny spadek IOPS i uszkadzanie nagłówków plików RRD.
Kubernetes w architekturze NMS Orkiestracja klasy Enterprise: System NMS w klastrze Kubernetes Kubernetes Cluster (Orkiestracja Skalowania) Deployment (Web UI) Replicas: 2 (HPA) Ingress / Service :80 StatefulSet (MariaDB) Pojedynczy Master PVC (RWO Block Storage) Dispatcher Pody Skalowanie automatyczne Współdzielony Ceph/NFS # Największe wyzwanie NMS w Kubernetes: Persystencja plików RRDtool • Pliki .rrd wymagają trybu zapisu wielowęzłowego (ReadWriteMany - RWX). • Protokół NFS wprowadza zbyt duże opóźnienia blokad i niszczy wydajność zapisu RRD. • Rozwiązanie: Rezygnacja z RRDtool na rzecz bazy Prometheus TSDB lub VictoriaMetrics w K8s. Wdrożenie LibreNMS w K8s realizuje się za pomocą oficjalnych wykresów Helm (Helm Charts).
Slajd 31/55
Planowanie wdrożenia produkcyjnego NMS w kontenerach
Cel slajdu: Wyrobienie umiejętności inżynierskiego doboru architektury hosta kontenerowego w zależności od wymagań SLA, dostępnego budżetu i skali monitorowanej infrastruktury.

Wdrożenie produkcyjne i sizing

Inżynier projektujący system monitoringu musi podjąć fundamentalną decyzję: czy zastosować prosty i niezawodny serwer Standalone Docker, czy rozbudowany klaster rozproszony.

  • Podejście Standalone (KISS): Pojedynczy serwer fizyczny z Docker Compose i nośnikami NVMe jest w stanie bez trudu obsłużyć do 1500 urządzeń i 30 000 portów
  • Prostota utrzymania i niski koszt TCO: Brak konieczności utrzymywania skomplikowanej infrastruktury wirtualizacyjnej i sieci overlay
  • Architektura rozproszona dla korporacji: Wydzielenie bazy danych MariaDB na osobną maszynę oraz rozmieszczenie kontenerów pollerów w odległych oddziałach firmy
  • Koncepcja czasu powrotu po awarii (RTO): Przy dobrze zaplanowanych kopiach wolumenów czas podniesienia serwera Standalone od zera wynosi poniżej 15 minut
Zasada KISS (Keep It Simple, Stupid): Inżynierska zasada projektowa głosząca, że prostota układu jest najwyższą gwarancją jego niezawodności. Niepotrzebne komplikowanie architektury NMS zwiększa liczbę potencjalnych punktów awarii.
Strategie wdrożenia NMS Planowanie wdrożenia produkcyjnego NMS w kontenerach Podejście 1: Standalone Host • 1 mocny serwer fizyczny (lub VM) • Docker Compose z dyskiem NVMe • Ekstremalnie proste zarządzanie Zasada KISS (Keep It Simple) • Backup wolumenów co 24h Zalecane do 1 500 węzłów Podejście 2: Klaster Rozproszony • Dedykowany serwer bazy MariaDB • Osobny serwer Nginx + Web GUI • Rozproszone pollery w oddziałach Skala Enterprise > 3 000 węzłów • Wysoki koszt i złożoność TCO Wymaga dedykowanego inżyniera # Kluczowy wniosek inżynierski przy wyborze architektury: Większość awarii monitoringu wynika ze zbyt skomplikowanej infrastruktury klastrowej. Pojedyncza maszyna z Docker Compose, szybkimi dyskami NVMe RAID10 i automatycznym backupem zapewnia wyższą dostępność operacyjną (99.9% SLA) niż niestabilny klaster Kubernetes.
Slajd 32/55
Wymiarowanie serwera dla skonteneryzowanego NMS
Cel slajdu: Nabycie umiejętności inżynierskiej kalkulacji zasobów CPU, RAM, IOPS i przestrzeni dyskowej oraz definiowania twardych limitów zasobów w pliku Compose.

Wdrożenie produkcyjne i sizing

Kontenery współdzielą zasoby serwera fizycznego. Brak zdefiniowanych limitów w pliku Compose może doprowadzić do sytuacji, w której wyciek pamięci w jednym kontenerze unieruchomi cały serwer.

  • Alokacja pamięci dla kontenera MariaDB: Co najmniej 50-60% pamięci przypisanej do bazy powinno zasilać bufor `innodb_buffer_pool_size`
  • Szacowanie zapotrzebowania na pamięć pollerów: Każdy wątek roboczy dispatchera zużywa średnio 60-100 MB pamięci RAM podczas parsowania MIB-ów
  • Wymagania dotyczące dysków NVMe: Zastosowanie nośników półprzewodnikowych jest bezwzględnym wymogiem dla wolumenów `db_data` oraz `rrd_data`
  • Dyrektywy `deploy.resources.limits`: Konfiguracja twardych limitów (limits) i gwarantowanych rezerwacji (reservations) dla każdego mikroserwisu
Pamięć podręczna a pliki RRD: Przy 20 000 portów baza RRD zajmuje około 8 GB. Posiadanie co najmniej 16 GB pamięci RAM na serwerze pozwala jądru Linux na utrzymanie większości aktywnych plików RRD w pamięci podręcznej (page cache), drastycznie przyspieszając odczyty.
Hardware Sizing w kontenerach Planowanie zasobów sprzętowych (Hardware Sizing) dla Dockera Liczba Węzłów vCPU / Pamięć RAM Rezerwacje Compose Dysk i Wymagany IOPS Do 50 węzłów (~ 1 000 portów) 2 vCPU / 4 GB RAM db: 1GB, app: 1GB 50 GB SSD (~100 IOPS) 50 - 300 węzłów (~ 8 000 portów) 6 vCPU / 12 GB RAM db: 4GB, disp: 2x2GB 200 GB NVMe (~800 IOPS) > 1 000 węzłów (> 25 000 portów) 16+ vCPU / 32 GB RAM db: 12GB, disp: 4x2GB NVMe RAID10 > 3 000 IOPS # Konfiguracja limitów zasobów w docker-compose.yml (zapobieganie OOM): deploy: resources: limits: { cpus: '4.0', memory: 4096M } reservations: { cpus: '2.0', memory: 2048M } # Gwarantuje, że kontener nie zajmie całej pamięci RAM serwera w trakcie nagłego piku zdarzeń.
Slajd 33/55
Architektura sieci zarządzania (Management VLAN)
Cel slajdu: Zrozumienie integracji serwera kontenerowego z fizycznymi sieciami wirtualnymi VLAN (standard IEEE 802.1Q) oraz separacji ruchu zarządzającego od sieci użytkowników.

Integracja sieciowa infrastruktury

Podstawową zasadą bezpieczeństwa sieciowego jest całkowity zakaz wystawiania interfejsów SNMP urządzeń infrastruktury w ogólnodostępnych podsieciach użytkowników.

  • Dedykowany VLAN zarządzający (np. VLAN 99): Wszystkie interfejsy zarządzające przełączników i routerów otrzymują adresację w odseparowanej podsieci
  • Tagowanie ramek IEEE 802.1Q na hoście: Serwer fizyczny podłączony jest portem typu Trunk; jądro Linux obsługuje podinterfejsy tagowane (np. `eth0.99`)
  • Listy kontroli dostępu ACL na routerze L3: Dostęp do VLAN 99 jest dozwolony wyłącznie ze źródłowego adresu IP serwera monitorującego NMS
  • Brak możliwości podsłuchu SNMP w sieci biurowej: Nawet niezaszyfrowane pakiety SNMP v2c są bezpieczne, gdyż nie pojawiają się w gniazdkach sieciowych pracowników
Płaszczyzna zarządzania (Management Plane): Część architektury sieciowej odpowiedzialna za nadzór, konfigurację i telemetrię urządzeń (SNMP, SSH, Syslog). Musi być całkowicie odizolowana od płaszczyzny danych (Data Plane).
Management VLAN 802.1Q Integracja sieciowa: Dedykowany Management VLAN (802.1Q) Serwer NMS (Host) Karta fizyczna: eth0 Tag IEEE 802.1Q Podinterfejs eth0.99 IP: 10.99.0.10/24 VLAN 99: Zarządzanie Trunk Switch Rdzeniowy L3 Port Gi1/0/1 (Trunk) SVI: Interface Vlan99 Brama: 10.99.0.1 ACL: Tylko IP NMS! Izolacja od użytkowników Urządzenia LAN Switche dostępowe Routery brzegowe Adresacja w VLAN 99 Brak dostępu z biura # Konfiguracja podinterfejsu 802.1Q w systemie Linux (/etc/netplan/01-netcfg.yaml): vlans: eth0.99: { id: 99, link: eth0, addresses: [ 10.99.0.10/24 ] } # Pakiety SNMP z kontenera wychodzą bezpośrednio z interfejsu eth0.99 z tagiem VLAN 99. Ruch telemetryczny jest w 100% odizolowany od sieci użytkowników biurowych (VLAN 10, 20). Standard IEEE 802.1Q gwarantuje fizyczną separację płaszczyzny zarządzania (Management Plane).
Slajd 34/55
Konfiguracja SNMP na MikroTik RouterOS pod serwer Docker
Cel slajdu: Przedstawienie kompletnej procedury bezpiecznej konfiguracji agenta SNMP, zapory firewall oraz wysyłki zdarzeń Syslog na urządzeniach MikroTik RouterOS.

Integracja sieciowa infrastruktury

Podłączenie urządzeń MikroTik do skonteneryzowanego LibreNMS wymaga skoordynowanej konfiguracji wspólnoty SNMP, ochrony filtra firewall oraz aktywacji trapów.

  • Restrykcja źródłowego IP (`addresses=10.99.0.10/32`): Agent SNMP odpowiada wyłącznie na pakiety pochodzące z konkretnego adresu serwera hosta Docker
  • Usunięcie domyślnej wspólnoty `public`: Podstawowy wymóg bezpieczeństwa eliminujący podatność na skanowanie podatności przez intruzów
  • Dwupoziomowa ochrona zaporą ogniową Firewall: Reguła w łańcuchu `input` blokuje zapytania UDP 161 ze wszystkich innych interfejsów i podsieci
  • Przekierowanie logów zdarzeń do kontenera: Konfiguracja akcji zdalnego logowania (`remote=10.99.0.10`) przesyła ostrzeżenia i błędy do kontenera `syslog-ng`
Wysyłka pułapek trap-version: W RouterOS należy upewnić się, że parametr trap-version jest ustawiony na 2 (SNMP v2c). Wersja 1 nie wspiera 64-bitowych liczników i nie przekazuje pełnego kontekstu obiektu.
Konfiguracja MikroTik pod Docker Konfiguracja SNMP w MikroTik RouterOS pod serwer Docker # 1. Konfiguracja wspólnoty SNMP v2c z blokadą źródłowego adresu IP: [admin@MikroTik] > /snmp community add name=NmsCorpCommunity addresses=10.99.0.10/32 read-access=yes remove [find name=public] # BEZWZGLĘDNIE usuń domyślną wspólnotę public! # 2. Aktywacja agenta SNMP i konfiguracja parametrów kontaktu: [admin@MikroTik] > /snmp set enabled=yes contact="NOC-Team" location="DC-Warszawa-R1" \ trap-target=10.99.0.10 trap-community=NmsCorpCommunity trap-version=2 # 3. Zabezpieczenie na zaporze ogniowej Firewall (Filter Rules): [admin@MikroTik] > /ip firewall filter add chain=input action=accept protocol=udp dst-port=161 src-address=10.99.0.10 \ comment="Zezwol na odpytywanie z kontenera LibreNMS" add chain=input action=drop protocol=udp dst-port=161 comment="Blokuj pozostale SNMP" # 4. Włączenie wysyłki logów zdarzeń Syslog do kontenera syslog-ng: [admin@MikroTik] > /system logging action add name=docker-syslog target=remote remote=10.99.0.10 [admin@MikroTik] > /system logging add topics=critical,error,warning action=docker-syslog
Slajd 35/55
Konfiguracja SNMP na przełącznikach Cisco pod serwer Docker
Cel slajdu: Przedstawienie inżynierskiego standardu konfiguracji agenta SNMP, list kontroli dostępu ACL oraz strumieniowania logów na przełącznikach Cisco Catalyst w systemie Cisco IOS.

Integracja sieciowa infrastruktury

Na przełącznikach Cisco Catalyst ochrona agenta SNMP realizowana jest poprzez powiązanie ciągu community ze standardową listą kontroli dostępu (ACL).

  • Filtrowanie dostępowe listą ACL: Jawne zezwolenie na zapytania SNMP wyłącznie z adresu IP serwera hosta Dockera (`permit host 10.99.0.10`)
  • Uprawnienia tylko do odczytu (RO): Bezwzględna rezygnacja z uprawnień zapisu (RW), zapobiegająca modyfikacji konfiguracji przełącznika przez SNMP
  • Aktywacja pułapek sprzętowych (`enable traps`): Przełącznik natychmiast powiadamia kontener `snmptrapd` o awariach zasilaczy redundantnych, modułów SFP i portów
  • Kierowanie logów Syslog (`logging host`): Przesyłanie komunikatów o poziomie ważności `warnings` i wyższym do kontenera `syslog-ng`
Standard SNMP v3 na Cisco: W sieciach produkcyjnych zaleca się zastąpienie SNMP v2c konfiguracją grupy v3: snmp-server group NMSGRP v3 priv read V1VIEW access ACL-NMS-SERVER oraz użytkownika z szyfrowaniem SHA i AES.
Konfiguracja Cisco IOS pod Docker Konfiguracja SNMP na przełącznikach Cisco IOS pod Docker # 1. Zdefiniowanie standardowej listy kontroli dostępu ACL: Switch-Core(config)# ip access-list standard ACL-NMS-SERVER Switch-Core(config-std-nacl)# permit host 10.99.0.10 Switch-Core(config-std-nacl)# deny any log # 2. Powiązanie wspólnoty SNMP z listą ACL (tylko do odczytu RO): Switch-Core(config)# snmp-server community SecCorpNms RO ACL-NMS-SERVER Switch-Core(config)# snmp-server location "Serwerownia Główna R2" Switch-Core(config)# snmp-server contact "NOC noc@uczelnia.pl" # 3. Włączenie generowania i wysyłki pułapek SNMP Traps: Switch-Core(config)# snmp-server enable traps Switch-Core(config)# snmp-server host 10.99.0.10 version 2c SecCorpNms # 4. Skierowanie strumienia dziennika zdarzeń Syslog do kontenera: Switch-Core(config)# logging host 10.99.0.10 Switch-Core(config)# logging trap warnings # Switch przesyła zdarzenia linkDown/linkUp równolegle protokołem SNMP Trap i Syslog.
Slajd 36/55
Konfiguracja agenta snmpd w systemach Linux
Cel slajdu: Przedstawienie standardu bezpiecznej konfiguracji demona Net-SNMP na serwerach Linux z wykorzystaniem SNMP v3 AuthPriv oraz restrykcji adresów nasłuchu.

Integracja sieciowa infrastruktury

Serwery z systemem Linux (np. bazy danych, wirtualizatory KVM) powinny być monitorowane za pomocą nowoczesnego, szyfrowanego profilu SNMP v3.

  • Restrykcja adresu nasłuchiwania (`agentaddress`): Związanie usługi z konkretnym adresem IP w sieci zarządzającej; zapobiega nasłuchiwaniu na wszystkich interfejsach
  • Bezpieczny poziom ochrony `authPriv`: Kombinacja skrótu kryptograficznego SHA (uwierzytelnianie) oraz szyfrowania symetrycznego AES (poufność danych)
  • Separacja pliku poświadczeń `/var/lib/snmp/`: Definicja użytkownika za pomocą polecenia `createUser` przy zatrzymanej usłudze, co powoduje bezpieczne haszowanie haseł
  • Weryfikacja komunikacji z poziomu kontenera: Test odpytania za pomocą polecenia `snmpget -v3` z kontenera aplikacji LibreNMS
SNMP v3 AuthPriv: Najwyższy poziom bezpieczeństwa protokołu SNMP gwarantujący integralność wiadomości (brak możliwości modyfikacji pakietu w locie), uwierzytelnienie nadawcy oraz pełne szyfrowanie zawartości algorytmem AES.
Konfiguracja Net-SNMP pod Docker Konfiguracja demona snmpd na serwerach Linux pod Docker # 1. Konfiguracja pliku /etc/snmp/snmpd.conf na monitorowanym serwerze Linux: # Nasłuch wyłącznie na adresie w sieci zarządzającej (brak nasłuchu na 0.0.0.0!): agentaddress udp:10.99.0.20:161 # 2. Definicja widoku MIB obejmującego całe drzewo systemowe: view systemonly included .1 # 3. Utworzenie bezpiecznego użytkownika SNMP v3 (AuthPriv SHA + AES): # Zatrzymaj usługę: sudo systemctl stop snmpd # Dopisanie do /var/lib/snmp/snmpd.conf: createUser secmon SHA HasloUwierzytelniania123! AES HasloSzyfrowania123! # Dopisanie do /etc/snmp/snmpd.conf: rouser secmon priv systemonly # 4. Restart usługi i weryfikacja z kontenera LibreNMS: $ sudo systemctl start snmpd $ docker compose exec librenms snmpget -v3 -u secmon -a SHA -A HasloUwierzytelniania123! \ -x AES -X HasloSzyfrowania123! -l authPriv 10.99.0.20 sysDescr.0
Slajd 37/55
Testy akceptacyjne po wdrożeniu stosu NMS
Cel slajdu: Przedstawienie usystematyzowanej metodyki i procedur weryfikacji poprawności działania wszystkich komponentów skonteneryzowanego stosu NMS przed oddaniem do eksploatacji.

Utrzymanie i ciągłość działania NMS

Po uruchomieniu kontenerów za pomocą Docker Compose niezbędne jest przeprowadzenie formalnych testów akceptacyjnych sprawdzających każdy kanał komunikacyjny.

  • Weryfikacja osiągalności warstwy 3 (ICMP): Test narzędziem fping bezpośrednio z wnętrza kontenera poller w celu wykluczenia problemów z routingiem mostka Docker
  • Test odpytywania SNMP i parsowania MIB: Pobranie podstawowych obiektów systemowych (sysDescr, sysUpTime) za pomocą snmpget i snmpwalk
  • Symulacja odbioru komunikatów asynchronicznych: Wysłanie testowej ramki Syslog oraz pułapki SNMP Trap z monitorowanego urządzenia do kontenerów sidecar
  • Próba generalna mechanizmu powiadamiania: Wymuszenie wysyłki alertu testowego za pomocą polecenia `lnms alert:test` w celu sprawdzenia webhooków i bramki pocztowej
Testy akceptacyjne NMS: Zestaw procedur walidacyjnych mających na celu potwierdzenie, że system monitorowania nie tylko poprawnie uruchomił swoje procesy składowe, ale potrafi skutecznie i bezstratnie komunikować się ze wszystkimi segmentami nadzorowanej sieci.
Testy akceptacyjne stosu NMS Macierz testów akceptacyjnych skonteneryzowanego stosu NMS Test 1: Osiągalność ICMP (fping) • Narzędzie: fping w kontenerze poller exec librenms fping -c 3 10.99.0.1 • Warunek: 0% utraty pakietów, RTT < 5 ms ✓ Weryfikacja stosu sieciowego i mostka Test 2: Odpytanie SNMP v2c/v3 • Narzędzie: snmpget / snmpwalk snmpwalk -v2c -c ComName 10.99.0.1 sysDescr • Warunek: Poprawny ciąg opisu platformy ✓ Weryfikacja ACL i wspólnoty agenta Test 3: Asynchroniczne Trapy i Syslog • Emulacja: logger na Linux / test trap logger -n 10.99.0.10 -d -P 514 "Test NMS" • Warunek: Wpis w tabeli syslog bazy DB ✓ Weryfikacja sidecarów syslog-ng/trapd Test 4: Reguły alertów i powiadomienia • Narzędzie: lnms alert:test lnms alert:test -d 1 -r 1 • Warunek: Dostarczenie powiadomienia ✓ Weryfikacja kanału Email/Webhook
Slajd 38/55
Strategia kopii zapasowych w Dockerze
Cel slajdu: Przedstawienie procedury tworzenia spójnych kopii zapasowych baz danych SQL, baz szeregów czasowych RRD oraz konfiguracji środowiska kontenerowego.

Utrzymanie i ciągłość działania NMS

Prawidłowy backup systemu NMS w Dockerze wymaga skoordynowanego zabezpieczenia bazy relacyjnej, wolumenu plików RRD oraz plików definicji stosu.

  • Spójny logiczny zrzut bazy MariaDB: Wykonanie mariadb-dump z flagą `--single-transaction`, która gwarantuje transakcyjną spójność bez blokowania operacji zapisu bazy
  • Opróżnienie bufora RRDcached przed backupem: Wysłanie komendy `FLUSHALL` do gniazda rrdcached w celu wymuszenia zapisu wszystkich oczekujących próbek na dysk
  • Archiwizacja dedykowanego wolumenu RRD: Skopiowanie zawartości wolumenu przy użyciu tymczasowego kontenera pomocniczego (docker run --rm --volumes-from)
  • Zabezpieczenie tożsamości stosu (.env i YAML): Przechowywanie klucza aplikacji `APP_KEY`, haseł bazodanowych oraz certyfikatów SSL w bezpiecznym repozytorium
Transakcyjna spójność kopii: Zastosowanie flagi --single-transaction w silniku InnoDB powoduje utworzenie punktu spójności (snapshotu) w ramach jednej transakcji ACID. Dzięki temu zrzut bazy odzwierciedla stan z jednej chwili, a proces pollowania nie jest wstrzymywany.
Strategia kopii zapasowych w Dockerze Strategia tworzenia kopii zapasowych (Backup) w Dockerze 1. Źródła danych NMS MariaDB (SQL) Metadane, urządzenia, alerty Wolumen RRD Szeregi czasowe wykresów Konfiguracja (.env) Klucze APP_KEY, sekrety 2. Operacje backupu Zrzut spójny MariaDB: mariadb-dump --single-transaction Archiwizacja RRD: rrdcached FLUSHALL tar -czf rrd.tar.gz Kopia plików YAML: tar -czf cfg.tar.gz compose.yml .env 3. Magazyn (Repo) • Szyfrowanie GPG • Rotacja (7 dni) • Wypychanie offsite: - Protokół SFTP - Zasób NFS / NAS - Pamięć S3 / Rclone Reguła 3-2-1 3 kopie, 2 nośniki, 1 poza firmą
Slajd 39/55
Procedura Disaster Recovery od zera
Cel slajdu: Przedstawienie kompletnej procedury odtworzenia awaryjnego systemu monitorowania na zupełnie nowym serwerze fizycznym lub wirtualnym w czasie poniżej 15 minut.

Utrzymanie i ciągłość działania NMS

Największą przewagą architektury kontenerowej jest możliwość błyskawicznego odtworzenia całego środowiska na nowej maszynie w przypadku fizycznej awarii serwera głównego.

  • Przygotowanie nowego środowiska uruchomieniowego: Instalacja Docker Engine i wdrożenie konfiguracji za pomocą skryptu Ansible lub ręcznego klonowania repozytorium
  • Selektywne uruchomienie bazy danych i import: Podniesienie wyłącznie kontenera bazy (`docker compose up -d db`), a następnie zaimportowanie zrzutu SQL strumieniem pipe
  • Rozpakowanie archiwum wolumenu RRD i korekta UID: Przywrócenie plików bazy szeregów czasowych z zachowaniem identyfikatorów właściciela `chown -R 1000:1000`
  • Pełny rozruch stosu i weryfikacja integralności: Podniesienie wszystkich usług (`docker compose up -d`) oraz wykonanie skryptu walidacyjnego `validate.php`
Wskaźniki RTO i RPO: RTO (Recovery Time Objective) określa maksymalny dopuszczalny czas niedostępności systemu po awarii (w kontenerach poniżej 15 min). RPO (Recovery Point Objective) definiuje maksymalny akceptowalny wiek utraconych danych metrycznych (zależny od częstotliwości kopii zapasowych, np. 24 h).
Procedura Disaster Recovery od zera Oś czasu Disaster Recovery: Odtworzenie NMS od zera Krok 1 (0-3 min) Świeży host OS • Instalacja Docker • Klonowanie repozytorium • Przywrócenie .env • Pobranie backupów Pobrane pliki: db.sql.gz, rrd.tar.gz Krok 2 (3-7 min) Baza MariaDB • compose up -d db • Oczekiwanie na socket • Import SQL: zcat db.sql.gz | mariadb -u ... Status bazy: Odtworzone tabele Krok 3 (7-11 min) Wolumen RRD • Rozpakowanie tar.gz • Korekta uprawnień: chown -R 1000:1000 • Weryfikacja katalogów Status plików: Bazy RRD gotowe Krok 4 (11-13 min) Start i Walidacja • compose up -d • Test validate.php • Polling w tle • Port 8000 dostępny RTO < 15 min System w pełni sprawny
Slajd 40/55
Konteneryzacja stosu Prometheus i Grafana
Cel slajdu: Przedstawienie architektury nowoczesnego, modułowego stosu telemetrycznego opartego na modelu odpytywania HTTP (Pull), bazie TSDB oraz bramce snmp_exporter.

Alternatywne architektury kontenerowe NMS

Poza tradycyjnymi zintegrowanymi systemami (jak LibreNMS) powszechnym standardem w inżynierii sieciowej stał się stos złożony z bazy Prometheus, eksportera SNMP i Grafany.

  • Prometheus TSDB jako wysokowydajna baza metryk: Optymalizowana baza szeregów czasowych z językiem zapytań PromQL i natywną kompresją danych
  • snmp_exporter jako brama protokołowa: Kontener pośredniczący: odbiera żądania HTTP GET ze ścieżki `/snmp?target=IP`, odpytuje switch po SNMP i zwraca metryki tekstowe
  • Grafana do unifikacji dashboardów: Elastyczna warstwa prezentacji danych łącząca metryki sieciowe ze statystykami serwerów i kontenerów
  • Rozdzielenie ról w mikroserwisach: Każdy komponent stanowi niezależny kontener o minimalnym narzucie, restartowany bez zakłócania działania pozostałych
Model Pull w monitorowaniu SNMP: Prometheus regularnie odpytuje kontener snmp_exporter po protokole HTTP (port 9116). Dopiero w momencie nadejścia zapytania HTTP eksporter wykonuje zapytanie SNMP GET/WALK do fizycznego urządzenia sieciowego i natychmiast konwertuje surowe OID na format OpenMetrics.
Prometheus i Grafana w Dockerze Architektura stosu Prometheus + Grafana + SNMP Exporter Środowisko Docker Compose (Sieć wewnętrzna bridge) Prometheus TSDB • Port HTTP: 9090 • Model: Scrape Pull • Silnik szeregów czasowych snmp_exporter • Port HTTP: 9116 • Tłumacz OID -> Metryki • Moduły z pliku snmp.yml Grafana Dashboard • Port Web UI: 3000 • Język zapytań: PromQL • Dynamiczne panele NOC Alertmanager • Port HTTP: 9093 • Grupowanie i wyciszanie • Webhooki, Slack, SMS Sieć LAN / Urządzenia Switch Core Cisco SNMP v2c/v3 (UDP 161) Router BGP MikroTik SNMP v2c/v3 (UDP 161) SNMP GET
Slajd 41/55
Konfiguracja snmp_exporter w kontenerze
Cel slajdu: Przedstawienie mechanizmu relabelingu w Prometheusie oraz konfiguracji demona snmp_exporter tłumaczącego zapytania SNMP na metryki OpenMetrics.

Alternatywne architektury kontenerowe NMS

Demon snmp_exporter działa jako bezstanowy tłumacz protokołów. Prometheus odpytuje go przez HTTP, a eksporter wykonuje zapytanie SNMP w locie.

  • Rola pliku `snmp.yml`: Skompilowany plik konfiguracyjny zawierający definicje tablic MIB, nazwy metryk oraz wersję i poświadczenia SNMP
  • Modułowość odpytywania urządzeń: Wybór modułu (np. `if_mib` dla przełączników, `mikrotik` lub `cisco_wlc`) dopasowanego do typu urządzenia
  • Mechanizm `relabel_configs` w Prometheusie: Przekształcenie adresu urządzenia sieciowego w parametr adresu URL `target`, podczas gdy żądanie HTTP kierowane jest na adres kontenera `snmp-exporter:9116`
  • Natywne etykiety (Labels) w formacie OpenMetrics: Automatyczne mapowanie indeksów interfejsów na czytelne nazwy, np. `ifName` lub `ifAlias`
Prometheus Relabeling: Mechanizm modyfikacji metadanych celów (targets) przed wykonaniem odpytania. Zmienna __address__ zostaje przekierowana na port eksportera, a oryginalny IP routera zostaje wstrzyknięty do parametru zapytania HTTP __param_target.
Konfiguracja snmp_exporter w kontenerze Mechanizm scrape i relabeling w Prometheus snmp_exporter prometheus.yml (Scrape Config) scrape_configs: - job_name: 'snmp_switches' static_configs: - targets: ['10.99.0.1'] metrics_path: /snmp params: module: [if_mib] relabel_configs: - source_labels: [__address__] target_label: __param_target - target_label: __address__ replacement: snmp-exporter:9116 Przepływ zapytania scrape 1. Prometheus wysyła żądanie HTTP GET :9116/snmp?target=10.99.0.1&module=if_mib 2. snmp_exporter pyta urządzenie SNMP GetBulk / GetNext (UDP 161) 3. Konwersja OID na format metryk ifHCInOctets{ifName="ge-0/0/1"} 98452104 Odpowiedź HTTP 200 OK z danymi
Slajd 42/55
Konteneryzacja NetBox: Source of Truth w Dockerze
Cel slajdu: Przedstawienie wdrożenia systemu NetBox w kontenerach Docker jako centralnego źródła prawdy o infrastrukturze sieciowej oraz integracji z NMS.

Alternatywne architektury kontenerowe NMS

W nowoczesnych środowiskach sieciowych system monitorowania NMS nie powinien być konfigurowany ręcznie, lecz zasilany automatycznie ze źródła prawdy (Source of Truth).

  • Oficjalny projekt `netbox-docker`: Kompletny stos kontenerów: aplikacja NetBox (Django), kolejka asynchroniczna worker, baza PostgreSQL oraz broker Redis
  • Separacja danych i wolumenów: Trwałe przechowywanie bazy PostgreSQL, plików multimedialnych oraz raportów w dedykowanych wolumenach Dockera
  • Automatyzacja rejestracji urządzeń (NetDevOps): Gdy inżynier zarejestruje nowy przełącznik w NetBox, webhook powiadamia LibreNMS o konieczności rozpoczęcia monitorowania
  • Dynamiczne inwentarze (Dynamic Inventory): Prometheus lub LibreNMS cyklicznie odpytują API NetBoksa, automatycznie aktualizując listę celów odpytywania
Source of Truth (SoT): Wzorzec architektoniczny w inżynierii sieciowej, w którym jedna centralna baza (np. NetBox) zawiera autorytatywną definicję stanu docelowego sieci (adresy IP, VLAN-y, urządzenia). Systemy NMS odzwierciedlają ten stan, zamiast być miejscem pierwotnego wprowadzania danych.
NetBox w Dockerze Konteneryzacja NetBox: Centralne źródło prawdy (Source of Truth) Stos kontenerów netbox-docker netbox / netbox-worker Aplikacja Django Web + procesy asynchroniczne PostgreSQL (Baza danych) Relacyjna ewidencja IPAM, DCIM, prefiksów Redis + Redis-Cache Kolejka zadań rq worker i buforowanie zapytań Interfejsy API i Webhooki REST API / GraphQL / Powiadomienia webhook Integracja z NMS (Automatyzacja) 1. Rejestracja urządzenia w NetBox Wprowadzenie IP, modelu, lokalizacji i roli 2. Webhook lub Dynamic Inventory Wyzwalacz HTTP POST do skryptu orkiestracji 3. Automatyczna rejestracja w NMS Wywołanie lnms device:add w LibreNMS
Slajd 43/55
Automatyzacja wdrożenia z Ansible
Cel slajdu: Przedstawienie deklaratywnego wdrażania i zarządzania cyklem życia skonteneryzowanego stosu NMS za pomocą Ansible (Infrastructure as Code).

Automatyzacja i orkiestracja infrastruktury

Ręczne konfigurowanie plików na serwerze produkcyjnym jest podatne na błędy. Ansible umożliwia pełną automatyzację instalacji Dockera i uruchomienia stosu NMS.

  • Kolekcja `community.docker`: Oficjalny moduł `docker_compose_v2` pozwalający deklaratywnie zarządzać projektem Compose bezpośrednio z poziomu playbooka
  • Szablony Jinja2 dla konfiguracji środowiskowej: Generowanie pliku `.env` w oparciu o zmienne hosta, unikalne hasła i dynamiczne adresy IP
  • Szyfrowanie poświadczeń (Ansible Vault): Przechowywanie haseł bazy danych MariaDB i kluczy API w zaszyfrowanych plikach w repozytorium Git
  • Gwarancja idempotencji: Uruchomienie playbooka na działającym systemie nie powoduje restartu sprawnych kontenerów, chyba że zmieniła się konfiguracja
Idempotencja w Ansible: Właściwość operacji polegająca na tym, że wielokrotne wykonanie playbooka przynosi dokładnie taki sam rezultat jak wykonanie pojedyncze. Jeżeli pliki konfiguracyjne i obrazy nie uległy zmianie, Ansible nie wykonuje zbędnych akcji na serwerze.
Wdrożenie z Ansible Automatyzacja wdrożenia stosu NMS za pomocą Ansible (IaC) deploy_nms.yml (Ansible Playbook) - name: Wdrozenie stosu NMS hosts: nms_servers tasks: - name: Utworzenie katalogu projektu file: path=/opt/nms state=directory - name: Wdrozenie konfiguracji .env template: src=.env.j2 dest=/opt/nms/.env - name: Uruchomienie kontenerow community.docker.docker_compose_v2: project_src: /opt/nms state: present pull: missing Zalety podejścia Infrastructure as Code 1. Pełna powtarzalność wdrożenia Brak ręcznych błędów konfiguracyjnych 2. Kontrola wersji w repozytorium Git Śledzenie każdej zmiany parametrów .env 3. Szyfrowanie haseł z Ansible Vault Bezpieczne przechowywanie kluczy i haseł Idempotencja: wielokrotne uruchomienie
Slajd 44/55
Laboratorium 1: Instalacja Dockera na Ubuntu 24.04 LTS
Cel slajdu: Przeprowadzenie kompletnej instalacji oficjalnego środowiska Docker Engine oraz wtyczki Docker Compose na serwerze z systemem Ubuntu 24.04 LTS.

Ćwiczenia laboratoryjne

Pierwszym krokiem praktycznym jest przygotowanie czystego środowiska serwerowego poprzez instalację oficjalnych pakietów Docker CE z repozytorium producenta.

  • Czyszczenie niekompatybilnych pakietów: Usunięcie starych dystrybucyjnych pakietów `docker.io` zapobiegające konfliktom zależności
  • Instalacja oficjalnego klucza GPG Dockera: Bezpieczne dodanie zweryfikowanego klucza kryptograficznego do katalogu `/etc/apt/keyrings/`
  • Konfiguracja repozytorium APT: Dodanie oficjalnego repozytorium pakietów dla wersji dystrybucji Ubuntu 24.04 LTS Noble Numbat
  • Konfiguracja uprawnień bez sudo: Dodanie konta administratora do grupy systemowej `docker` i odświeżenie sesji poleceniem `newgrp docker`
Grupa docker a bezpieczeństwo: Członkostwo w grupie docker daje uprawnienia równoważne użytkownikowi root, ponieważ pozwala montować dowolny katalog hosta do kontenera. Na serwerach produkcyjnych do grupy tej powinni należeć wyłącznie uprawnieni administratorzy.
Laboratorium 1: Instalacja Dockera Laboratorium 1: Instalacja Docker Engine i Docker Compose # Krok 1: Usunięcie ewentualnych starych/nieoficjalnych pakietów: $ sudo apt-get remove docker docker-engine docker.io containerd runc # Krok 2: Instalacja zależności i pobranie oficjalnego klucza GPG Dockera: $ sudo apt-get update && sudo apt-get install -y ca-certificates curl gnupg $ sudo install -m 0755 -d /etc/apt/keyrings $ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # Krok 3: Dodanie repozytorium APT i instalacja pakietów Docker CE: $ echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list $ sudo apt-get update && sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # Krok 4: Dodanie bieżącego użytkownika do grupy docker (praca bez sudo): $ sudo usermod -aG docker $USER && newgrp docker # Krok 5: Weryfikacja instalacji za pomocą kontenera testowego: $ docker run --rm hello-world Hello from Docker! This message shows that your installation appears to be working correctly.
Slajd 45/55
Laboratorium 2: Przygotowanie compose.yml i .env
Cel slajdu: Praktyczne przygotowanie bezpiecznego pliku środowiskowego .env z losowymi hasłami kryptograficznymi oraz walidacja struktury compose.yml.

Ćwiczenia laboratoryjne

Przed uruchomieniem stosu LibreNMS należy prawidłowo skonfigurować parametry środowiskowe, aby uniknąć stosowania domyślnych haseł.

  • Pobranie szablonu ze źródła referencyjnego: Pozyskanie oficjalnych plików wzorcowych z repozytorium GitHub projektu `librenms/docker`
  • Generowanie kluczy kryptograficznych: Użycie polecenia `openssl` do wygenerowania 256-bitowego klucza `APP_KEY` oraz hasła bazy MariaDB
  • Interpolacja parametrów w pliku `.env`: Wprowadzenie unikalnych poświadczeń, strefy czasowej `Europe/Warsaw` i identyfikatorów UID/GID
  • Statyczna weryfikacja składniowa: Uruchomienie `docker compose config --quiet` w celu wychwycenia błędów wcięć YAML przed startem kontenerów
Klucz APP_KEY: 256-bitowy klucz szyfrujący frameworka Laravel. Służy do szyfrowania sesji użytkowników, haseł urządzeń oraz poświadczeń SNMP v3 w bazie danych. Utrata klucza uniemożliwia odszyfrowanie haseł w LibreNMS!
Laboratorium 2: Konfiguracja .env Laboratorium 2: Konfiguracja środowiska .env i weryfikacja YAML # Krok 1: Utworzenie katalogu roboczego i pobranie wzorca .env: $ mkdir -p /opt/nms-librenms && cd /opt/nms-librenms $ curl -fsSL https://raw.githubusercontent.com/librenms/docker/master/examples/compose/.env -o .env # Krok 2: Konfiguracja haseł bazy i dopisanie unikalnego APP_KEY: $ DB_PASS="$(openssl rand -hex 16)" $ sed -i "s|MYSQL_PASSWORD=.*|MYSQL_PASSWORD=$DB_PASS|" .env $ echo "APP_KEY=base64:$(openssl rand -base64 32)" >> .env # (Alternatywa: docker compose exec librenms lnms key:generate --show) # Krok 3: Pobranie oficjalnego pliku compose.yml: $ curl -fsSL https://raw.githubusercontent.com/librenms/docker/master/examples/compose/compose.yml -o compose.yml # Krok 4: Weryfikacja składni i poprawności interpolacji zmiennych: $ docker compose config --quiet && echo "Składnia pliku Compose jest w 100% poprawna!" # Podgląd przetłumaczonej konfiguracji z podstawionymi hasłami: $ docker compose config | head -n 25
Slajd 46/55
Laboratorium 3: Rozruch stosu i pierwsze logowanie
Cel slajdu: Uruchomienie wszystkich kontenerów stosu LibreNMS, śledzenie procesu migracji bazy danych, sprawdzenie stanu zdrowia i utworzenie konta administratora.

Ćwiczenia laboratoryjne

Po prawidłowej konfiguracji następuje proces pierwszego rozruchu, podczas którego aplikacja automatycznie tworzy schemat tabel w bazie MariaDB.

  • Uruchomienie w trybie odłączonym (`-d`): Wywołanie `docker compose up -d` powoduje sekwencyjne pobranie obrazów i wystartowanie usług zgodnie z dyrektywami `depends_on`
  • Diagnostyka logów startowych: Śledzenie logów za pomocą flagi `-f` w celu upewnienia się, że skrypty migracji zakończyły się sukcesem
  • Weryfikacja mechanizmów Healthcheck: Polecenie `docker compose ps` potwierdza, czy baza danych i serwer web osiągnęły stan `healthy`
  • Inicjalizacja konta administratora: Wykonanie polecenia `lnms user:add` wewnątrz działającego kontenera aplikacji LibreNMS
Pierwsze logowanie do panelu: Po wykonaniu kroków laboratoryjnych panel dostępny jest w przeglądarce pod adresem http://<IP_SERWERA>:8000. Użytkownik loguje się poświadczeniami utworzonymi za pomocą narzędzia lnms.
Laboratorium 3: Rozruch stosu Laboratorium 3: Rozruch stosu, inspekcja logów i utworzenie admina # Krok 1: Pobranie obrazów i uruchomienie całego stosu w tle: $ docker compose up -d [+] Running 6/6: Network compose_default Created, Container compose-db-1 Started ... # Krok 2: Śledzenie logów inicjalizacji bazy i migracji tabel: $ docker compose logs -f librenms librenms-1 | Initializing LibreNMS container... librenms-1 | Migrating database... Migration table created successfully. librenms-1 | Configuration cache cleared! OK: Listening on port 8000 # Krok 3: Weryfikacja statusu kontenerów (kolumna STATUS: Up / healthy): $ docker compose ps NAME IMAGE COMMAND SERVICE STATUS compose-db-1 mariadb:10.11 "docker-entrypoint.s…" db Up (healthy) compose-librenms-1 librenms/librenms:latest "/init" librenms Up (healthy) 0.0.0.0:8000->8000/tcp # Krok 4: Utworzenie pierwszego konta administratora przez CLI lnms: $ docker compose exec librenms lnms user:add -r admin -p AdminHaslo123! -e admin@lab.local admin
Slajd 47/55
Laboratorium 4: Dodanie węzła w kontenerze przez lnms
Cel slajdu: Przeprowadzenie procedury dodania węzła sieciowego do bazy LibreNMS z poziomu konsoli kontenera oraz weryfikacja procesu pollowania i tworzenia baz RRD.

Ćwiczenia laboratoryjne

Dodawanie węzłów sieciowych przez CLI pozwala na pełną automatyzację i ominięcie interfejsu graficznego w potokach wdrożeniowych.

  • Syntetyczny test komunikacji SNMP: Sprawdzenie odpowiedzi OID `sysDescr.0` z poziomu kontenera w celu potwierdzenia poprawności wspólnoty
  • Rejestracja urządzenia poleceniem `device:add`: Zapisanie węzła w bazie SQL wraz z konfiguracją protokołu SNMP v2c/v3
  • Wymuszenie natychmiastowego pollowania: Uruchomienie `lnms device:poll` generuje strukturę tablic interfejsów, pamięci RAM i procesora
  • Kontrola generowania plików RRD: Weryfikacja utworzenia plików `.rrd` w podkatalogu `/data/rrd/<IP>` na wolumenie trwałym
Struktura plików RRD: Dla każdego nowo dodanego węzła LibreNMS tworzy katalog nazwany adresem IP lub nazwą DNS węzła. Wewnątrz tworzone są oddzielne pliki .rrd dla każdego interfejsu, czujnika temperatury czy rdzenia procesora.
Laboratorium 4: Dodanie węzła przez lnms Laboratorium 4: Rejestracja i odpytanie węzła sieciowego przez lnms # Krok 1: Weryfikacja osiągalności agenta SNMP z wnętrza kontenera: $ docker compose exec librenms snmpget -v2c -c NmsCorpCommunity 10.99.0.1 sysDescr.0 SNMPv2-MIB::sysDescr.0 = STRING: RouterOS RB5009UG+S+IN v7.14.3 (stable) # Krok 2: Dodanie urządzenia do monitorowania za pomocą lnms device:add: $ docker compose exec librenms lnms device:add --v2c -c NmsCorpCommunity 10.99.0.1 Device added successfully with id 1! # Krok 3: Wymuszenie pierwszego pollowania urządzenia (inicjalizacja danych): $ docker compose exec librenms lnms device:poll 10.99.0.1 #### Load poller module core #### OS: routeros, Hardware: RB5009, Version: 7.14.3 #### Load poller module ports #### (8 ports discovered) Polled 1 device in 2.14 secs. 18 RRD files updated. # Krok 4: Weryfikacja utworzonych plików baz RRD na wolumenie: $ docker compose exec librenms ls -la /data/rrd/10.99.0.1/ -rw-r--r-- 1 librenms librenms 184560 Sep 29 21:00 port-id1.rrd ...
Slajd 48/55
Laboratorium 5: Pełna kopia i symulacja odtworzenia
Cel slajdu: Praktyczne przetestowanie procedury Disaster Recovery: eksport danych, celowe usunięcie wolumenów i pełne odtworzenie sprawności systemu.

Ćwiczenia laboratoryjne

Kopia zapasowa, która nie została przetestowana pod kątem odtworzenia, nie stanowi realnego zabezpieczenia. W tym ćwiczeniu studenci symulują awarię dysku.

  • Zrzut strumieniowy bazy do archiwum GZIP: Wykonanie zrzutu SQL w locie za pomocą potoku powłoki i kompresora gzip bez zapisywania nieskompresowanych plików
  • Kopia wolumenu przez kontener kontenerowy: Zastosowanie lekkiego obrazu `alpine` do skopiowania plików bez naruszania uprawnień właściciela
  • Celowa destrukcja środowiska (`compose down -v`): Flaga `-v` trwale kasuje wszystkie wolumeny Dockera, symulując całkowitą utratę danych na dyskach
  • Odtworzenie i weryfikacja integralności: Zaimportowanie zrzutu SQL, rozpakowanie archiwum RRD i potwierdzenie integralności komendą `validate.php`
Flaga -T w docker compose exec: Przy przekierowywaniu strumienia wejściowego (np. potok zcat plik.sql.gz | docker compose exec -T db ...) flaga -T wyłącza alokację pseudo-terminala TTY, co jest bezwzględnie wymagane do poprawnego przesłania surowych danych binarnych lub tekstu.
Laboratorium 5: Kopia i symulacja odtworzenia Laboratorium 5: Ćwiczenie Disaster Recovery w środowisku testowym # Krok 1: Wykonanie zrzutu bazy SQL i archiwizacja wolumenu RRD: $ docker compose exec db mariadb-dump -u librenms -pTajneHasloDB --single-transaction librenms | gzip > /tmp/backup_db.sql.gz $ docker run --rm --volumes-from compose-librenms-1 -v /tmp:/backup alpine tar -czf /backup/backup_rrd.tar.gz -C /data rrd # Krok 2: Symulacja katastrofy – zniszczenie kontenerów i wolumenów: $ docker compose down -v Removing compose-librenms-1 ... done | Removing volume compose_db-data ... done # Krok 3: Odtworzenie bazy danych na czystym wolumenie: $ docker compose up -d db && sleep 10 $ zcat /tmp/backup_db.sql.gz | docker compose exec -T db mariadb -u librenms -pTajneHasloDB librenms # Krok 4: Odtworzenie plików RRD do wolumenu: $ docker run --rm -v compose_rrd-data:/dest -v /tmp:/backup alpine tar -xzf /backup/backup_rrd.tar.gz -C /dest # Krok 5: Podniesienie całego stosu i walidacja: $ docker compose up -d && docker compose exec librenms ./validate.php OK: Database schema correct, RRD directory writable. Recovery complete!
Slajd 49/55
Laboratorium 6: Prometheus, Grafana i SNMP w Compose
Cel slajdu: Samodzielne uruchomienie nowoczesnego mikroserwisowego stosu telemetrycznego, integracja bazy Prometheus z Grafaną i wizualizacja metryk SNMP switcha.

Ćwiczenia laboratoryjne

Ćwiczenie to pozwala studentom poznać alternatywne podejście do monitorowania oparte na modelu Pull, zapytaniach PromQL i elastycznych panelach Grafany.

  • Definicja trzech mikroserwisów w jednym pliku Compose: Uruchomienie kontenerów `prom/prometheus`, `prom/snmp-exporter` oraz `grafana/grafana`
  • Weryfikacja tłumacza snmp_exporter przez HTTP: Przetestowanie działania bramki narzędziem `curl` z przekazaniem adresu IP urządzenia jako parametru URL
  • Wewnętrzna komunikacja DNS w sieci mostka: Skonfigurowanie źródła danych (Data Source) w Grafanie z użyciem nazwy serwisu `http://prometheus:9090`
  • Budowa pierwszego wykresu przepustowości w PromQL: Wizualizacja natężenia ruchu komendą `rate(ifHCInOctets[2m]) * 8` bezpośrednio w panelu Grafany
Wyrażenie PromQL dla przepustowości: Metryka ifHCInOctets to 64-bitowy licznik rosnący. Funkcja rate(ifHCInOctets[2m]) oblicza liczbę bajtów na sekundę w oknie 2 minut. Pomnożenie przez 8 daje wynik w bitach na sekundę (bps), który Grafana automatycznie formatuje do Mb/s lub Gb/s.
Laboratorium 6: Prometheus i Grafana Laboratorium 6: Uruchomienie stosu Prometheus + Grafana + SNMP # Krok 1: Przygotowanie katalogu, pliku prometheus.yml oraz compose.yml: $ mkdir -p /opt/prom-stack && cd /opt/prom-stack $ echo -e "global:\n scrape_interval: 15s" > prometheus.yml $ cat << 'EOF' > compose.yml services: prometheus: { image: prom/prometheus, ports: ["9090:9090"], volumes: ["./prometheus.yml:/etc/prometheus/prometheus.yml"] } snmp-exporter: { image: prom/snmp-exporter, ports: ["9116:9116"] } grafana: { image: grafana/grafana, ports: ["3000:3000"] } EOF # Krok 2: Uruchomienie stosu telemetrycznego: $ docker compose up -d [+] Running 4/4: Network prom-stack_default Created, Container prom-stack-grafana-1 Started ... # Krok 3: Test metryk ze switcha za pośrednictwem snmp_exporter: $ curl -s "http://localhost:9116/snmp?target=10.99.0.1&module=if_mib" | grep ifHCInOctets | head -n 3 ifHCInOctets{ifDescr="ether1",ifIndex="1"} 148590214 # Krok 4: Połączenie Prometheus jako Data Source w Grafanie (port 3000): URL w Grafanie: http://prometheus:9090 -> Kliknij "Save & Test" (Data source is working)
Slajd 50/55
Rozwiązywanie problemów w kontenerach NMS
Cel slajdu: Przedstawienie usystematyzowanego algorytmu diagnozowania i rozwiązywania najczęstszych awarii i problemów eksploatacyjnych w skonteneryzowanych systemach NMS.

Eksploatacja i diagnostyka

Eksploatacja systemów NMS w kontenerach wprowadza specyficzne rodzaje awarii związane z uprawnieniami wolumenów, izolacją sieciową oraz buforowaniem logów.

  • Pętla restartów (CrashLoop) i inspekcja logów: Błyskawiczna analiza przyczyny za pomocą `docker compose logs --tail 50 <service>` i kodu wyjścia w `docker inspect`
  • Konflikty uprawnień do plików RRD: Niezgodność identyfikatorów UID/GID procesu wewnątrz kontenera (`librenms`, UID 1000) z właścicielem katalogu na hoście
  • Problemy z ruchem SNMP i translacją NAT: Weryfikacja widocznego adresu źródłowego zapytań SNMP na zaporze monitorowanego routera
  • Zapełnienie dysku przez pliki logów JSON Dockera: Konieczność globalnego skonfigurowania sterownika rotacji logów w pliku `/etc/docker/daemon.json`
Rotacja logów w Docker Daemon: Domyślnie Docker gromadzi wszystkie logi kontenerów w nieskończoność w formacie JSON na partycji /var/lib/docker/. W systemach monitorowania, generujących tysiące zdarzeń na minutę, brak rotacji prowadzi do 100% zapełnienia partycji systemowej!
Rozwiązywanie problemów NMS Drzewo diagnostyczne rozwiązywania problemów (Troubleshooting) Objaw: Ciągłe restarty kontenera • Przyczyna: Błąd bazy / brak APP_KEY docker compose logs <serwis> • Sprawdź status bazy: docker compose ps Rozwiązanie: Popraw zmienne w .env Objaw: Permission Denied (/data/rrd) • Przyczyna: Niewłaściwy UID hosta ls -ld /opt/data/rrd • Proces librenms działa z UID 1000 Rozwiązanie: chown -R 1000:1000 Objaw: Brak odpowiedzi SNMP w NMS • Przyczyna: Blokada firewall lub złe IP exec librenms snmpget ... • Sprawdź reguły iptables i trasowanie Rozwiązanie: Dodaj IP hosta do ACL Objaw: Brak miejsca na dysku (/var) • Przyczyna: Niekontrolowane logi Dockera du -sh /var/lib/docker/containers/* • Brak rotacji w daemon.json Rozwiązanie: max-size 50m w daemon.json
Slajd 51/55
Dobre praktyki eksploatacji kontenerów NMS
Cel slajdu: Zestawienie fundamentalnych reguł inżynierskich gwarantujących wysoką dostępność, stabilność i bezpieczeństwo systemów monitorowania sieci w kontenerach.

Eksploatacja i diagnostyka

Wdrażając system NMS w kontenerach należy stosować sprawdzone zasady inżynierii oprogramowania i administracji systemami Unix.

  • Definiowanie limitów pamięci i procesora: Zapobieganie awariom całego serwera hosta w przypadku wycieku pamięci w procesach pollerów
  • Cykliczne testy zdrowia (Healthchecks): Umożliwienie silnikowi Docker automatycznego wykrywania zakleszczonych zapytań SQL lub zawieszonych wątków
  • Separacja danych i konfiguracji (12-Factor App): Przechowywanie konfiguracji w środowisku, a danych w wolumenach, co gwarantuje pełną bezstanowość kontenerów aplikacyjnych
  • Optymalizacja I/O za pomocą buforów RRDcached: Kluczowe wdrożenie bufora pamięci RAM eliminujące degradację wydajności macierzy dyskowej
Metodologia 12-Factor App: Zbiór dobrych praktyk tworzenia nowoczesnych aplikacji chmurowych i kontenerowych. Trzeci czynnik (Config) nakazuje bezwzględne oddzielenie konfiguracji zmiennej (hasła, adresy IP) od kodu i obrazu aplikacji.
Dobre praktyki eksploatacji Dobre praktyki eksploatacji kontenerów NMS w produkcji Niezawodność i Zasoby 1. Sztywne limity RAM i CPU Definicja `mem_limit` i `cpus` w Compose Chroni hosta przed Linux OOM Killer 2. Dedykowane Healthchecki Weryfikacja gniazda SQL i kodu HTTP 200 Automatyczny restart zawieszonych usług 3. Pamięć podręczna RRDcached Buforowanie losowych zapisów w RAM Redukcja IOPS dysków SSD o 85-90% ✓ Wymuszone restart: unless-stopped Bezpieczeństwo i Operacje 4. Zasada 12-Factor App Sekrety i hasła wyłącznie w zmiennych .env Nigdy nie zapisuj haseł w obrazach Dockera 5. Uruchamianie bez uprawnień root Zastosowanie no-new-privileges:true Odrzucenie zbędnych uprawnień jądra Linux 6. Automatyzacja kopii i rotacja Codzienny zrzut MariaDB i archiwum RRD Wypychanie szyfrowanych kopii poza serwer ✓ Testowanie odtworzenia co kwartał
Slajd 52/55
Przyszłość konteneryzacji w inżynierii sieciowej
Cel slajdu: Przedstawienie trendów ewolucyjnych na styku konteneryzacji i inżynierii sieciowej: paradygmatu NetDevOps, narzędzia Containerlab oraz integracji OpenTelemetry.

Trendy i ewolucja technologii

Konteneryzacja przestała być domeną wyłącznie aplikacji webowych. Dziś kontenery rewolucjonizują testowanie i zarządzanie sieciami teleinformatycznymi.

  • Narzędzie Containerlab do symulacji sieci: Możliwość uruchomienia na jednym laptopie w kontenerach kompletnych routerów producentów takich jak Nokia SR Linux, Arista cEOS czy Cisco
  • Potoki CI/CD dla reguł monitorowania: Każda zmiana reguły alertu lub konfiguracji pollowania jest testowana syntetycznie w zwirtualizowanej topologii przed wdrożeniem na produkcji
  • Konteneryzacja agentów brzegowych (Edge Monitoring): Uruchamianie małych kontenerów z demonami SNMP/gNMI bezpośrednio na przełącznikach brzegowych wyposażonych w procesory x86/ARM
  • Konwergencja z OpenTelemetry: Stopniowa migracja ze statycznego odpytywania SNMP na strumieniową telemetrię push w standardzie OpenTelemetry i gRPC
Projekt Containerlab: Otwarte narzędzie orkiestracji topologii sieciowych w kontenerach. Pozwala zdefiniować w pojedynczym pliku YAML złożoną topologię wielu przełączników i połączyć je wirtualnymi kablami (veth pairs), tworząc wierną replikę sieci produkcyjnej do testów NMS.
NetDevOps i Containerlab Kierunki rozwoju: NetDevOps, Containerlab i CI/CD sieci Potok CI/CD walidacji reguł NMS i konfiguracji sieci 1. Git Commit • Nowa reguła alertu • Zmiana ACL w YAML • Nowa definicja MIB GitLab / GitHub 2. Containerlab • Start wirtualnej sieci • Routery w kontenerach • Emulacja BGP/OSPF Wirtualna topologia 3. Test NMS • Odpytanie SNMP • Wywołanie awarii linku • Weryfikacja alertu Automatyczny test 4. Produkcja • Wdrożenie na fizyczne • Zero-Downtime • Zgodność ze stanem Fizyczna sieć LAN
Slajd 53/55
Słownik kluczowych pojęć prezentacji 5
Cel slajdu: Usystematyzowanie najważniejszych terminów technicznych i pojęć z zakresu konteneryzacji oraz orkiestracji systemów monitorowania sieci teleinformatycznych.

Podsumowanie i weryfikacja wiedzy

Zrozumienie współczesnego monitoringu wymaga biegłego posługiwania się pojęciami z pogranicza inżynierii sieciowej, wirtualizacji i konteneryzacji.

  • Obraz OCI i Kontener: Rozróżnienie między statycznym, niezmiennym szablonem (Image) a działającym, odizolowanym procesem (Container)
  • Cgroups i Namespaces: Fundamenty jądra Linux: cgroups ograniczają zasoby (RAM/CPU), namespaces izolują widok (procesy, sieć, punkty montowania)
  • Wolumeny trwałe (Volumes): Mechanizm bezpiecznego składowania baz danych SQL i RRD poza ulotnym cyklem życia kontenera
  • RRDcached i Dispatcher: Architektura buforowania I/O i asynchronicznego kolejkowania w pamięci RAM umożliwiająca skalowanie monitoringu
Open Container Initiative (OCI): Niezależna organizacja standaryzacyjna powołana w 2015 r., definiująca specyfikację formatu obrazów kontenerów (Image Spec) oraz środowiska wykonawczego (Runtime Spec), gwarantując pełną zgodność między Dockerem, Podmanem i Kubernetesem.
Słownik pojęć Słownik 10 kluczowych pojęć konteneryzacji i NMS 1. Obraz kontenera (OCI Image) Niezmienny szablon warstwowy zawierający kod i biblioteki. 2. Kontener (Container) Uruchomiona instancja obrazu izolowana przez namespaces. 3. Docker Compose Narzędzie deklaratywnej orkiestracji wielokontenerowej w YAML. 4. Cgroups & Namespaces Mechanizmy jądra Linux: limit zasobów i izolacja widoku. 5. Wolumen trwały (Named Volume) Zarządzana przestrzeń dyskowa poza warstwą CoW kontenera. 6. Mostek sieciowy (Bridge Network) Wirtualny przełącznik L2 z wewnętrznym DNS 127.0.0.11. 7. RRDcached Demon buforujący operacje I/O zapisu wykresów RRD w RAM. 8. Dispatcher Poller Skalowalny proces pollowania pobierający zadania z Redis. 9. Rootless Docker / Podman Uruchamianie silnika bez uprawnień root dla bezpieczeństwa. 10. Source of Truth (NetBox) Centralna baza autorytatywnego stanu docelowego sieci.
Slajd 54/55
Pytania kontrolne i powtórzenie materiału
Cel slajdu: Syntetyczna weryfikacja stopnia przyswojenia wiedzy z zakresu konteneryzacji systemów NMS, architektury pamięci masowej i izolacji sieciowej.

Podsumowanie i weryfikacja wiedzy

Poniższy zestaw pytań problemowych pozwala sprawdzić zrozumienie kluczowych kompromisów architektonicznych występujących przy wdrażaniu kontenerów.

  • Analiza narzutu I/O plików RRD: Zrozumienie, dlaczego protokoły sieciowe plików (NFS/CIFS) bez bufora pamięci podręcznej nie nadają się do zapisu szeregów czasowych
  • Wybór trybu sieciowego w skrajnych skalach: Uzasadnienie zastosowania trybu `host` w celu uniknięcia tablicy śledzenia połączeń `nf_conntrack`
  • Zarządzanie zasobami jądra Linux: Świadomość mechanizmu OOM Killer i konieczności sztywnego limitowania zużycia pamięci RAM w cgroups
  • Koordynacja rozproszonych wątków (Redis): Zasada działania kolejki zadań i mechanizmów distributed lock w architekturze mikrousług
Wskazówka dydaktyczna: Odpowiedzi na te pytania wymagają nie tylko pamięciowego opanowania składni komend, ale przede wszystkim zrozumienia interakcji zachodzących między stosem kontenera, jądrem Linux a monitorowaną siecią LAN.
Pytania kontrolne Pytania kontrolne i powtórzenie materiału (Weryfikacja wiedzy) Pytanie 1: RRDcached a sieć NFS Dlaczego wolumen /data/rrd nie powinien być montowany przez NFS bez bufora RRDcached? Odp: Ogromny narzut losowych operacji IOPS blokuje wątki I/O i zawiesza odpytywanie. Pytanie 2: network_mode host vs bridge Kiedy dla kontenera NMS należy wybrać network_mode: host zamiast domyślnego bridge? Odp: Przy >500 węzłach, by uniknąć narzutu SNAT i nasycenia tablicy conntrack jądra. Pytanie 3: Brak limitu mem_limit Jakie ryzyko niesie brak limitów pamięci RAM w definicji usług w docker-compose.yml? Odp: Wyciek pamięci może aktywować OOM Killera, który zabije krytyczny proces hosta. Pytanie 4: Rola Redis w Dispatcherze Jaką rolę pełni broker Redis w architekturze ze skalowanymi kontenerami pollerów? Odp: Kolejkuje zadania i zarządza blokadami (locks), zapobiegając duplikacji odpytań.
Slajd 55/55
Źródła, literatura i dokumentacja techniczna
Cel slajdu: Zestawienie oficjalnej literatury technicznej, specyfikacji branżowych OCI i NIST oraz oficjalnych repozytoriów oprogramowania otwartego.

Podsumowanie i weryfikacja wiedzy

Poniższy wykaz obejmuje zweryfikowane oficjalne źródła wiedzy technicznej, stanowiące punkt wyjścia do dalszych badań i projektów wdrożeniowych.

  • Oficjalna dokumentacja Docker Engine: Podręcznik konfiguracji, izolacji zasobów i zarządzania siecią (docs.docker.com)
  • Projekt LibreNMS Docker: Oficjalne repozytorium GitHub zawierające definicje obrazów i przykłady Compose (github.com/librenms/docker)
  • Specyfikacje Open Container Initiative: Oficjalne standardy formatu obrazu OCI Image Spec oraz środowiska OCI Runtime Spec
  • Standardy bezpieczeństwa CIS i NIST: Wytyczne bezpiecznej konfiguracji kontenerów wg CIS Docker Benchmark oraz NIST SP 800-190
Dostęp do materiałów: Wszystkie odnośniki w poniższej bibliografii prowadzą do oficjalnych portali dokumentacji technicznej i są weryfikowane pod kątem aktualności standardów.
Źródła i literatura Źródła, literatura techniczna i oficjalna dokumentacja Oficjalne repozytoria i projekty • LibreNMS Docker Repository github.com/librenms/docker • Docker Engine & Compose Docs docs.docker.com/engine • Prometheus & snmp_exporter prometheus.io / github.com/prometheus • NetBox Community Docker github.com/netbox-community/netbox-docker • Containerlab Network Labs containerlab.dev Wszystkie odnośniki w 100% zweryfikowane Standardy i literatura akademicka • Open Container Initiative (OCI) Image & Runtime Specifications (opencontainers.org) • CIS Docker Benchmark v1.6.0 Center for Internet Security (cisecurity.org) • NIST SP 800-190 Application Container Security Guide • The Twelve-Factor App Metodologia aplikacji chmurowych (12factor.net) • Turnbull J.: The Docker Book Podręcznik konteneryzacji środowisk Linux Materiały do dalszych studiów i projektów
← Poprzednia prezentacja Następna prezentacja →