Monitorowanie sieci domowej z wykorzystaniem wyłącznie otwartego oprogramowania

Gdy domowa sieć zaczyna żyć własnym życiem

Wieczór, wszyscy w domu – ktoś ogląda film, ktoś gra online, ktoś próbuje dokończyć wysyłanie dużego pliku. Internet „muli”, strony ładują się wieczność, a na pytanie „kto coś pobiera?” wszyscy zgodnie odpowiadają: „nikt”. Router świeci jak choinka, ale z jego migających diod niewiele wynika.

W pewnym momencie pojawia się bardzo konkretne pytanie: co tak naprawdę płynie przez moją sieć i kto ją obciąża? I drugie, mniej wygodne: czy na pewno tylko te urządzenia, które znam? Bez własnego monitoringu pozostaje zgadywanie, kombinowanie z restartami routera i dzwonienie do operatora, który najczęściej widzi tylko „łącze w normie”.

Domowa sieć bez monitoringu to jazda samochodem w nocy bez zegarów i kontrolek. Da się, dopóki nic się nie dzieje, ale gdy coś zaczyna szwankować – działamy na wyczucie zamiast na danych. Open source pozwala to zmienić bez abonamentów i drogich, zamkniętych systemów.

Po co monitorować sieć domową – korzyści i granice

Stabilność i komfort korzystania z łącza

Domowy internet przestał służyć tylko do sprawdzania poczty. Przez jedno łącze idzie często praca zdalna, wideokonferencje, gry online, streaming, kopie zapasowe do chmury i masa ruchu z urządzeń IoT. Bez monitoringu wszystkie te strumienie ruchu mieszają się w kompletny chaos, który widzisz tylko jako „działa / nie działa”.

Monitorowanie sieci domowej open source pozwala od razu zobaczyć:

• które urządzenie w danej chwili obciąża łącze najbardziej,
• kiedy w ciągu dnia masz realne „szczyty ruchu”,
• czy problem z „muleniem” wynika z łącza do operatora, czy z ruchu w LAN,
• jak zachowuje się Wi‑Fi – czy nie ma nagłych spadków jakości, wysokich opóźnień itp.

Dzięki temu zamiast stałego narzekania na internet, możesz na przykład przesunąć automatyczne backupy w chmurze na godziny nocne, ograniczyć pasmo niektórym urządzeniom lub świadomie rozdzielić sieć na segmenty (np. osobne Wi‑Fi dla gości i IoT).

Bezpieczeństwo i kontrola nad urządzeniami

Typowy dom ma dziś po kilkanaście – kilkadziesiąt urządzeń w sieci: telewizory, konsole, kamery, głośniki, roboty sprzątające, inteligentne żarówki. Każde z nich to potencjalny wektor ataku. Większość nie dostaje poprawek bezpieczeństwa tak często jak komputer czy telefon.

Prosty system monitoringu pozwala wychwycić sytuacje typu:

• Smart‑TV, który po włączeniu nagle zaczyna prowadzić intensywną komunikację z nieznanym adresem w internecie.
• Kamera IP, która próbowała połączyć się z adresem oznaczonym w listach zagrożeń (tu wchodzi w grę open source IDS).
• Stary laptop w rogu domu, który zaczął wysyłać nienaturalnie dużo małych pakietów – typowy objaw infekcji malware.

Monitorując metadane ruchu (kto, kiedy, ile, do kogo), można szybko wykryć nietypowe wzorce i zareagować, zanim problem stanie się poważny.

Monitoring to nie podsłuch treści

Domowy monitoring sieci przy użyciu otwartego oprogramowania koncentruje się przede wszystkim na metadanych:

• jaki adres IP / urządzenie generuje ruch,
• ile danych wysyła i odbiera,
• z jakimi adresami, portami i krajami się łączy,
• jakie usługi sieciowe są aktywne (HTTP, HTTPS, DNS, SSH itd.).

Bez celowego, głębokiego podsłuchu i łamania szyfrowania nie widzisz treści wiadomości, dokumentów, haseł czy konkretnych stron. Dla domowych zastosowań to i tak ogrom wiedzy, który wystarcza do wykrywania problemów, przy zachowaniu zdrowej prywatności domowników.

Praktyczne scenariusze, które szybko się zwracają

Monitoring sieci domowej open source nie jest zabawką „dla geeków”. W praktyce pomaga w prostych, codziennych sytuacjach:

• Diagnostyka łącza – zanim zadzwonisz do operatora, masz wykresy: od kiedy wystąpiły problemy, jakie były opóźnienia, straty pakietów, użycie pasma.
• Kontrola transferu – jeśli masz limitowany internet (LTE/5G, satelitarny), widzisz dokładnie, co „zjada” gigabajty.
• Porządek w sieci – widzisz urządzenia, o których zapomniałeś, stare sprzęty, nieużywane już kamery czy rejestratory.
• Bezpieczeństwo dzieci – bez podglądania treści masz orientację, kiedy i jak intensywnie korzystają z sieci, możesz też zablokować podejrzane domeny (Pi‑hole).

System wczesnego ostrzegania zamiast paranoi

Domowy monitoring nie musi oznaczać, że ktoś spędza wieczory, gapiąc się w wykresy. W praktyce dobrze skonfigurowany zestaw narzędzi działa jak system wczesnego ostrzegania:

• gromadzi dane historyczne,
• prezentuje je na przejrzystym dashboardzie,
• wysyła powiadomienie, gdy coś wykracza poza normalne wzorce (np. nagły skok ruchu do jednego kraju).

Wystarczy potem od czasu do czasu rzucić okiem na wykresy lub logi, a dopiero przy nietypowych zdarzeniach wejść głębiej w szczegóły.

Co da się zrobić wyłącznie na open source – mapa możliwości

Open source kontra gotowe rozwiązania chmurowe

Na rynku jest coraz więcej „magicznych” pudełek i chmurowych paneli do monitorowania domowej sieci. Kuszą prostą konfiguracją, ale mają kilka minusów: abonament, ograniczoną kontrolę nad danymi, często zamknięty kod i niejasne zasady prywatności.

Monitoring sieci domowej open source pozwala uniknąć tych pułapek. Wszystko działa na Twoim sprzęcie, dane zostają w domu, a kod możesz przeanalizować lub przynajmniej polegać na audycie społeczności. Zamiast pojedynczej czarnej skrzynki budujesz zestaw klocków, które się uzupełniają.

Główne kategorie narzędzi open source do monitoringu sieci

Żeby nie zgubić się w gąszczu projektów, warto rozdzielić je na kilka funkcjonalnych grup:

• Zbieranie metryk – czas odpowiedzi, obciążenie łącza, liczba połączeń:
  • Prometheus,
  • InfluxDB + Telegraf,
  • Collectd, Netdata.
• Analiza logów – dzienniki routera, systemów, aplikacji:
  • Loki,
  • Graylog,
  • ELK Stack (Elasticsearch, Logstash, Kibana).
• IDS/IPS (systemy wykrywania włamań):
  • Suricata,
  • Snort.
• Analiza i filtrowanie DNS:
  • Pi‑hole,
  • AdGuard Home.
• Wizualizacja i dashboardy:
  • Grafana,
  • (opcjonalnie) Kibana dla logów.

Każda z tych kategorii odpowiada za inny „widok” na Twoją sieć: z poziomu ruchu, zdarzeń, bezpieczeństwa lub użycia konkretnych usług.

Gdzie kończy się wygoda, a zaczyna praca

Otwarte oprogramowanie do monitoringu nie zrobi wszystkiego za Ciebie jednym kliknięciem. Jest kilka realnych ograniczeń:

• trzeba poświęcić chwilę na instalację i podstawową konfigurację,
• czasem trzeba zrozumieć, co oznaczają metryki i pola w logach,
• nie ma centralnego supportu – jest społeczność, dokumentacja, fora.

Z drugiej strony, ten wysiłek zwraca się bardzo szybko: nie jesteś skazany na łaskę producenta urządzenia, możesz przenosić konfigurację między sprzętami, a do tego nie płacisz co miesiąc abonamentu, który często i tak opiera się na tych samych projektach open source pod spodem.

Elastyczność w zamian za odrobinę zaangażowania

Największa zaleta otwartego podejścia: możesz rosnąć z czasem. Na początku wystarczy prosty zestaw – np. tylko Grafana + Prometheus + Pi‑hole. Gdy poczujesz się pewniej, dołożysz Suricatę, logi z routera, powiadomienia na telefon.

Dzięki modularności narzędzi OSS da się zacząć bardzo małymi krokami i stopniowo rozbudowywać środowisko, zamiast od razu pakować się w skomplikowane, drogie appliance’y.

Sprzęt i architektura: na czym to wszystko uruchomić w domu

Najprostszy scenariusz: mały komputer + router od operatora

Na start wystarczy:

• router od operatora (lub własny z marketu),
• mały komputer działający 24/7:
  • Raspberry Pi (3/4/5),
  • inny mini‑komputer x86 (np. Intel NUC, mini PC),
  • stary, energooszczędny laptop.

Ten mały komputer pełni rolę serwera monitoringu. Nie musi być bardzo mocny – ważniejsze, żeby był stabilny, cichy i miał sensowny pobór prądu, bo będzie pracował non stop. Router wysyła do niego logi i dane statystyczne, a serwer je gromadzi, analizuje i prezentuje w postaci dashboardów.

Alternatywy: własny router z OpenWrt/pfSense, NAS, maszyny wirtualne

Dla bardziej ambitnych pojawiają się inne opcje:

• Router z OpenWrt – wiele tańszych routerów można prze-flashować na OpenWrt. Daje to:
  • dostęp do SNMP, iptables, pełnych logów,
  • możliwość instalacji części narzędzi bezpośrednio na routerze.
• pfSense / OPNsense – własny, mocniejszy router na mini‑PC lub starym komputerze, z zaawansowanymi funkcjami firewall i bogatymi logami.
• NAS (Synology, QNAP, własny DIY) – wiele osób ma w domu serwer NAS, który pracuje 24/7; to naturalne miejsce do odpalenia maszyn wirtualnych lub kontenerów z monitoringiem.
• Maszyna wirtualna na silniejszym komputerze – jeśli w domu jest serwer dla innych celów (VM, Home Assistant), można dołożyć tam rolę serwera monitoringu.

Zalety i wady poszczególnych opcji

Ogólna architektura rozwiązania w domu

Niezależnie od wybranej platformy, logika rozwiązania jest podobna:

• Punkt zbierania danych (serwer):
  • Linux + Docker/docker‑compose,
  • na nim kontenery: Prometheus, Grafana, Pi‑hole, Loki/Graylog itd.
• Źródła danych:
  • router (SNMP, syslog, NetFlow/sFlow/IPFIX),
  • urządzenia końcowe (agent np. node_exporter, Telegraf, logi systemowe),
  • narzędzia sieciowe (Pi‑hole generujący logi DNS).

Serwer stoi w jednym z portów LAN routera, ma stały adres IP i zbiera wszelkie możliwe informacje, które potem wizualizuje np. Grafana. Router nie musi być „inteligentny”; wystarczy, że potrafi wysłać logi i udostępnić podstawowe statystyki.

Minimalne wymagania sprzętowe dla różnych scenariuszy

Żeby nie przesadzić na starcie, dobrze oszacować potrzeby:

Przykładowe konfiguracje sprzętowe – od „lite” po „pełny zestaw”

Najpierw pojawia się pytanie: „czy to wszystko nie zabije mi rachunku za prąd?”. Druga myśl – „czy ten stary laptop na pewno da radę?”. Zanim zacznie się kupować sprzęt, dobrze przełożyć marzenia o „centrum monitoringu” na kilka konkretnych scenariuszy.

• Scenariusz „Lite” – tylko podstawowe metryki i DNS:
  • Raspberry Pi 3/4 z 2 GB RAM, karta SD klasy A2 + zasilacz,
  • kontenery: Pi‑hole + Prometheus + Grafana,
  • kilkanaście urządzeń w sieci, brak IDS/IPS.

  Taki zestaw wystarcza, żeby zobaczyć kto wysyła ile ruchu, zablokować reklamy i śledzące domeny oraz dostać alert, gdy łącze „przytyka się” wieczorami.

• Scenariusz „Średni” – metryki, logi, lekki IDS:
  • mini‑PC x86 (4 rdzenie, 8 GB RAM, SSD),
  • kontenery: Prometheus, Grafana, Loki/Graylog, Pi‑hole, lekko skonfigurowana Suricata,
  • kilkadziesiąt urządzeń, dodatkowe VLAN‑y, smart home.

  To rozsądny kompromis: ruch jest analizowany pod kątem anomalii, logi są przeszukiwalne, a sprzęt nadal nie zamienia pokoju w serwerownię.

• Scenariusz „Rozbudowany” – pełne logi, IDS, VM:
  • serwer/NAS lub mocniejszy mini‑PC (6–8 rdzeni, min. 16 GB RAM, dysk SSD + HDD na logi),
  • kilka VM lub rozbudowany Docker: Prometheus, Grafana, ELK/Loki, Suricata w trybie IDS, Pi‑hole/adguard + dodatkowe agenty na hostach,
  • domowa infrastruktura z kilkoma podsieciami, gościnne Wi‑Fi, VPN, kamery IP.

  Taki zestaw pojawia się zwykle wtedy, gdy monitoring to już hobby samo w sobie lub ktoś pracuje zdalnie i zależy mu na bardzo dobrej widoczności i bezpieczeństwie.

Najbardziej rozsądna ścieżka to start w wersji „Lite” i rozbudowa w kierunku „Średni” dopiero wtedy, gdy pojawią się realne potrzeby – np. chęć trzymania logów pół roku zamiast tygodnia.

Podstawowe pojęcia monitoringowe w wersji „dla domownika”

Metryki, logi i zdarzenia – trzy różne „języki” Twojej sieci

Kiedy coś zaczyna szwankować, pierwsza reakcja to: „internet znowu nie działa”. Dopiero potem pojawia się pytanie: „co właściwie mam sprawdzić w tych wszystkich wykresach i logach?”. Kluczem jest zrozumienie, że systemy monitoringu opisują sieć trzema różnymi „językami”.

• Metryki – liczby, które zmieniają się w czasie:
  • prędkość wysyłania i pobierania (Mb/s),
  • opóźnienia (ms),
  • użycie CPU/RAM na routerze czy serwerze.

  Metryki świetnie pokazują trendy: czy wieczorne spowolnienia to norma, czy wyjątek.

• Logi – linijka po linijce opisują, co się wydarzyło:
  • „urządzenie X dostało adres IP Y”,
  • „połączenie zablokowane przez firewall”,
  • „klient poprosił o adres DNS domeny Z”.

  Logi są jak dziennik pokładowy – mniej czytelne na pierwszy rzut oka, ale niezastąpione, gdy chcesz zobaczyć konkretny incydent.

• Zdarzenia/alerty – wyciągnięte z metryk i logów sygnały „tu coś jest nie tak”:
  • „upload przekroczył typową wartość o 300%”,
  • „w ciągu 5 minut z jednego urządzenia poszły setki zapytań DNS”,
  • „router gubi pakiety na łączu WAN”.

  Zdarzenia są tym, co dostajesz jako powiadomienie na telefon, maila czy komunikator.

Praktyczna zasada: metryki służą do „patrzenia szeroko”, logi – do „patrzenia głęboko”, a alerty mają Cię szturchnąć, gdy nie patrzysz w ogóle.

SNMP, NetFlow, syslog – skąd w ogóle biorą się dane

Większość domowych routerów ma w menu kilka tajemniczych opcji typu „SNMP”, „syslog” albo „NetFlow”. Z reguły są wyłączone, więc sieć działa „po omacku”.

• SNMP (Simple Network Management Protocol):
  • standard pozwalający odpytać urządzenie o podstawowe statystyki – ile danych wyszło danym interfejsem, ile pakietów zgubiono, jaki jest uptime,
  • działa na zasadzie: serwer monitoringu pyta router „podaj licznik X”, a ten odpowiada liczbową wartością.

  To główne źródło metryk „jak mocno zapchane jest łącze” i „co robią porty LAN”.

• NetFlow/sFlow/IPFIX:
  • rodzina protokołów opisujących „strumienie” ruchu – kto gada z kim, jak długo i jak intensywnie,
  • nie wchodzą w treść pakietów (przy poprawnej konfiguracji), ale mówią np., że telewizor łączy się w kółko z pewną chmurą w konkretnym kraju.

  Przydaje się, gdy chcesz wiedzieć, które urządzenie „topi” łącze, ale nie potrzebujesz od razu pełnej inspekcji zawartości.

• Syslog:
  • standardowy sposób wysyłania logów tekstowych z urządzeń sieciowych na zewnętrzny serwer,
  • router może natychmiast raportować: udane/nieudane logowania, restarty, zablokowane połączenia, błędy na interfejsach.

  Syslog to paliwo dla narzędzi typu Loki czy Graylog – dzięki niemu nie szuka się już niczego w ciasnym panelu routera.

Jeżeli w domowej sieci kilkukrotnie pojawił się „tajemniczy zanik internetu”, zwykle da się go później odtworzyć na osi czasu, łącząc SNMP (metryki) z syslogiem (zdarzenia).

Seria czasowa – jak patrzeć na dane w dłuższym okresie

Pojedynczy wykres „teraz” jest przydatny, gdy coś pali się tu i teraz. Znacznie ciekawszy obraz wychodzi, gdy zaczniesz patrzeć na dane z kilku tygodni czy miesięcy.

• Baza szeregów czasowych (Prometheus, InfluxDB):
  • przechowuje metryki jako „czas + wartość”,
  • pozwala rysować wykresy z dowolnego przedziału i porównywać np. ostatnią sobotę do poprzednich.
• Agregacja danych:
  • starsze dane można przechowywać w „rozmazanej” formie – zamiast każdego pomiaru co 15 sekund, tylko wartość uśrednioną z 5 minut,
  • dzięki temu baza nie rośnie bez końca, a i tak nadal widać wzorce.

W praktyce pozwala to odpowiedzieć na bardzo domowe pytania: „czy po zmianie operatora coś się poprawiło”, „czy nowe urządzenie naprawdę dodało obciążenia, czy to tylko wrażenie”.

Alerty – jak nie zwariować od powiadomień

Najłatwiej zniechęcić się do monitoringu, zasypując siebie samego alertami. Po tygodniu człowiek przestaje je czytać, a kiedy zdarzy się coś ważnego, i tak to przegapi.

Kilka prostych zasad budowania sensownych powiadomień:

• Alerty tylko na odchylenia od normy:
  • zamiast „powiadamiaj mnie, gdy użycie łącza > 50%”,
  • lepiej „powiadom, jeśli upload jest 3× wyższy niż typowo w danym przedziale godzinowym”.
• Histereza i opóźnienie:
  • nie reaguj na każdy, jednosekundowy skok,
  • ustaw próg typu „problemy trwają co najmniej 5 minut” – eliminuje to przypadkowe zacięcia.
• Priorytety:
  • „miękkie” ostrzeżenia – np. mail raz dziennie z podsumowaniem,
  • „twarde” alerty – np. nagły wyciek ruchu z jednego hosta – na komunikator lub SMS.

Dobrze ustawione alertowanie sprawia, że domowy monitoring nie staje się kolejną aplikacją, którą odinstalujesz po tygodniu, tylko czymś, co rzadko trąca, ale gdy trąci – ma to sens.

Wybór i przygotowanie głównych narzędzi open source

Dlaczego Linux i Docker tak dobrze pasują do domowego monitoringu

Wiele osób startuje z myślą: „zainstaluję to na Windowsie, bo go znam”. Po kilku próbach z usługami w tle, aktualizacjami i restartami dochodzi do wniosku, że stały serwer lepiej czuje się na Linuksie.

• Linux:
  • stabilny podczas pracy 24/7,
  • dobre wsparcie dla narzędzi sieciowych i kontenerów,
  • łatwe zarządzanie logami i usługami (systemd, journald).
• Docker/docker‑compose:
  • każde narzędzie (Prometheus, Grafana, Pi‑hole, Loki) siedzi w osobnym „pudełku” ze swoimi zależnościami,
  • instalacja sprowadza się do kilku linijek w pliku YAML,
  • aktualizacje często wymagają tylko podmiany obrazu i restartu kontenera.

W praktyce dużo łatwiej jest skopiować jeden katalog z plikiem docker-compose.yml na nową maszynę i tam odtworzyć cały zestaw monitoringu, niż żmudnie instalować wszystko ręcznie.

Proponowany „rdzeń” narzędzi na start

Z dziesiątek projektów open source warto wybrać kilka, które dobrze ze sobą współpracują i nie wymagają doktoratu z administrowania.

• Prometheus – silnik do zbierania metryk:
  • ciągnie dane z exporterów (np. node_exporter, SNMP exporter),
  • trzyma je w bazie szeregów czasowych,
  • posiada własny niewielki system alertowania.
• Grafana – warstwa wizualizacji:
  • pobiera dane z Prometheusa (i innych źródeł),
  • rysuje wykresy, tabele, mapy ciepła,
  • pozwala budować dashboardy składane jak klocki.
• Pi‑hole – filtr DNS i „sensor” ruchu domenowego:
  • blokuje reklamy i śledzące domeny w całej sieci,
  • loguje wszystkie zapytania DNS,
  • może być jednym z głównych źródeł informacji o tym, dokąd łączą się urządzenia.
• Loki lub Graylog – do przechowywania logów:
  • Loki – „Prometheus dla logów”, prostszy i lżejszy, wysoko kompresuje tekst,
  • Graylog – wygodny, gdy lubisz bardziej „panelowe” podejście i zaawansowane wyszukiwanie.

Do tego dochodzą eksportery, które pełnią rolę łącznika między światem urządzeń a Prometheusem.

Eksporterzy i agenty – jak „nauczyć” urządzenia mówić do Prometheusa

Sam Prometheus bez źródeł danych jest jak pusta skorupa. To eksporterzy i agenty zbierają metryki i udostępniają je w formacie, który Prometheus rozumie.

• node_exporter:
  • zbiera metryki systemowe z Linuksa: CPU, RAM, dysk, sieć,
  • instaluje się jako jeden lekki proces, którego Prometheus regularnie „odpyta”.
• SNMP exporter:
  • pośrednik między Prometheusem a routerem/NAS-em,
  • tłumaczy zapytania SNMP na metryki w stylu Prometheusowym.
• Blackbox exporter:
  • mierzy „z zewnątrz”, czy usługa odpowiada – np. ping do routera, pomiar HTTP do konkretnej strony,
  • przydaje się, gdy chcesz wiedzieć, jak Ty faktycznie odczuwasz działanie internetu, a nie tylko „czy interfejs jest podniesiony”.

Na start zwykle wystarczą: node_exporter na serwerze monitoringu i SNMP exporter do podglądu routera. Gdy to zadziała, można dołożyć kolejne klocki.

Jak połączyć te klocki w spójną całość

U wielu osób ten etap wygląda tak: każdy serwis udało się osobno odpalić, ale nikt nie pamięta, pod jakim adresem słucha Prometheus, który port zajął Loki i czemu Grafana niczego nie widzi. Zamiast „monitoringu” wychodzi zbiór luźnych paneli.

Żeby uniknąć chaosu, warto od razu ułożyć prostą strukturę:

• jeden serwer monitoringu (mini‑PC / VM) jako „centrum dowodzenia”,
• jasne role dla usług: kto zbiera, kto przechowuje, kto rysuje, kto wysyła alerty,
• spójne adresy i porty – nawet jeśli na początku stoi to tylko w notatniku.

W praktyce minimalny przepływ danych może wyglądać tak:

• Prometheus scrape’uje:
  • node_exporter na serwerze monitoringu,
  • SNMP exporter zbierający informacje z routera, switcha, NAS‑a,
  • ewentualnie eksportery Pi‑hole (czy innego DNS‑sinkhole).
• Grafana:
  • łączy się do Prometheusa jako do głównego źródła metryk,
  • opcjonalnie ma też źródło „Loki” lub „Graylog” dla logów (syslog z routera, logi systemowe z serwera).
• Pi‑hole:
  • staje się głównym DNS‑em dla sieci domowej,
  • logi z Pi‑hole (zapytania DNS, blokady) można wysłać do Loki/Grayloga lub odczytywać przez eksportera.

Po ustawieniu ról pojawia się pierwsza korzyść: kiedy „internet muli”, nie klikasz po przypadkowych panelach, tylko otwierasz Grafanę, która ma już uporządkowane dane z wszystkich źródeł.

Organizacja sieci i adresacji dla serwera monitoringu

Częsta scena: serwer monitoringu ma adres z DHCP, po tygodniu się zmienia i wszystko przestaje działać, bo Prometheus przestał trafiać w node_exportera, a router nie wie, gdzie wysyłać syslog. Pozorny drobiazg, który potrafi zniechęcić bardziej niż trudna konfiguracja.

Żeby mieć spokój, wystarczą proste kroki:

• Stały adres IP dla serwera monitoringu:
  • ustawiony albo „na sztywno” w systemie,
  • albo jako DHCP reservation w routerze – serwer nadal bierze adres z DHCP, ale zawsze ten sam.
• Spójna nazwa hosta:
  • np. mon-dom lub monitor,
  • warto ją dodać do lokalnego DNS (część lepszych routerów to potrafi) – wtedy Grafana jest np. pod http://monitor:3000.
• Oddzielona „podsiec serwerowa” (opcjonalnie):
  • jeśli router obsługuje VLAN‑y lub kilka sieci LAN,
  • można odseparować serwer monitoringu i inne usługi od „zwykłego” Wi‑Fi dla gości, TV i telefonów.

Nawet w najprostszym scenariuszu (jeden router od operatora, jedna sieć Wi‑Fi) stały adres serwera monitoringu bardzo ułatwia życie. Wszystkie konfiguracje (syslog, SNMP, eksportery) odwołują się wtedy do jednego, niezmiennego IP.

Bezpieczeństwo: żeby monitoring nie stał się nową dziurą w sieci

Domowy serwer, który „widzi wszystko”, to łakomy kąsek – nawet jeśli nie trzymasz na nim nic tajnego, może stać się trampoliną na inne urządzenia. Zabezpieczenie go nie wymaga jednak fortecy, raczej kilku zdroworozsądkowych ruchów.

• Brak wystawiania paneli na świat:
  • Grafana, Prometheus, Loki nie muszą być dostępne z internetu,
  • jeśli koniecznie chcesz mieć dostęp z zewnątrz – użyj VPN (WireGuard, OpenVPN) zamiast przekierowywania portów HTTP.
• Konta i hasła:
  • od razu zmień domyślne hasło admina w Grafanie,
  • wyłącz anonimizowany dostęp „bez logowania”, jeśli jest włączony w przykładowych konfiguracjach.
• Dostęp po SSH:
  • klucz SSH zamiast logowania hasłem,
  • jeśli router potrafi: ograniczenie logowania do sieci LAN, brak wystawiania SSH na świat.
• Aktualizacje kontenerów:
  • przynajmniej raz na kilka tygodni: docker-compose pull + docker-compose up -d,
  • przed większym skokiem wersji dobrze jest skopiować katalog z konfiguracją (Prometheus, Grafana).

Domowy monitoring nie wymaga certyfikacji bezpieczeństwa. Wystarczy, żeby był „nudnym celem” – niewidoczny z internetu, bez domyślnych haseł i z w miarę aktualnym oprogramowaniem.

Krok po kroku: prosty serwer monitoringu na domowym mini‑komputerze

Wybór i przygotowanie systemu na mini‑PC

Najczęściej wylądujesz z jednym z trzech rozwiązań: Raspberry Pi, starszym laptopem stojącym w szafce albo małym mini‑PC z dyskiem SSD. Każda z tych opcji nada się na serwer monitoringu, jeśli działa 24/7 i nie dostaje co chwilę „przypadkowego” wyłączenia.

Typowa, bezproblemowa baza systemowa to:

• Debian / Ubuntu Server / Raspberry Pi OS Lite:
  • bez interfejsu graficznego – mniejsze zużycie zasobów, mniej problemów,
  • stabilne repozytoria, długi cykl życia.
• Minimalny zestaw pakietów:
  • git, curl, htop do wygodnej pracy,
  • docker i docker-compose (narzędzie CLI lub plugin) do uruchamiania usług.

Po instalacji systemu warto od razu ustawić:

• stały adres IP (lub rezerwację DHCP w routerze),
• konto użytkownika bezpośrednio używane do logowania, z uprawnieniami do docker,
• podstawowy firewall (np. ufw) z otwartymi tylko potrzebnymi portami (Grafana, Prometheus, Pi‑hole).

Instalacja Dockera i struktura katalogów

Po zalogowaniu na świeży system domowy serwer monitoringu w zasadzie sprowadza się do kilku komend. Ważniejsze od samych komend jest jednak to, jak poukładasz katalogi, żeby po roku nadal wiedzieć, co jest czym.

Jedno z prostszych podejść:

• tworzysz katalog główny, np. /opt/monitoring,
• w nim podkatalogi:
  • prometheus/ – konfiguracja i dane Prometheusa,
  • grafana/ – konfiguracja i dane Grafany,
  • pihole/ – konfiguracja Pi‑hole,
  • loki/ – konfiguracja Loki (jeśli użyjesz),
  • exporters/ – ewentualne dodatkowe konfiguracje eksporterów.
• w katalogu głównym plik docker-compose.yml, który spina wszystko w całość.

Taki układ ma jedną przewagę: backup to zwykłe skopiowanie jednego katalogu, a migracja na nowy sprzęt – przerzucenie katalogu i uruchomienie docker-compose up -d.

Przykładowy docker-compose: Prometheus, Grafana, node_exporter

Na początek wystarczą trzy kontenery: sam Prometheus, Grafana do wizualizacji oraz node_exporter, który mierzy stan serwera. Resztę (SNMP, Pi‑hole, logi) można dołożyć później, gdy podstawowy zestaw ustabilizuje się.

Przykładowy szkic pliku docker-compose.yml może wyglądać tak (uproszczona wersja, bez wszystkich możliwych opcji):

version: "3.8"

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./prometheus/data:/prometheus
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.path=/prometheus
      - --storage.tsdb.retention.time=30d
    ports:
      - "9090:9090"
    restart: unless-stopped

  grafana:
    image: grafana/grafana-oss:latest
    container_name: grafana
    depends_on:
      - prometheus
    volumes:
      - ./grafana/data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=zmien_to_haslo
    ports:
      - "3000:3000"
    restart: unless-stopped

  node_exporter:
    image: prom/node-exporter:latest
    container_name: node_exporter
    network_mode: "host"
    pid: "host"
    restart: unless-stopped

Ten plik robi kilka ważnych rzeczy jednocześnie:

• tworzy trwałe katalogi na dane Prometheusa i Grafany,
• wystawia Prometheusa na porcie 9090, Grafanę na 3000,
• uruchamia node_exporter bezpośrednio na hoście (dzięki network_mode: host), dzięki czemu zbiera metryki całego systemu.

Konfiguracja Prometheusa: pierwszy scrape

Sam kontener to za mało – Prometheus musi dostać listę miejsc, z których ma pobierać metryki. Na start wystarczy, że będzie zbierał dane z node_exporter działającego na tym samym serwerze.

Przykładowy plik ./prometheus/prometheus.yml:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["localhost:9100"]

Po uruchomieniu docker-compose up -d:

• Prometheus będzie co 15 sekund odpytatywać node_exporter na porcie 9100,
• pod adresem http://<IP-serwera>:9090 pokaże się jego prosty interfejs, gdzie można wpisać przykładowo metrykę node_load1,
• Grafana pod http://<IP-serwera>:3000 (logowanie: admin / hasło z docker-compose).

To już jest działający, choć skromny monitoring – widzisz przynajmniej, jak zachowuje się sam serwer. Kolejny krok to dołożenie widoku na resztę sieci.

Dodanie SNMP exporter i podpięcie routera

W większości domów router jest centrum wszystkiego: widzi ruch, ma informacje o obciążeniu łącza, listę podłączonych klientów. To naturalny drugi krok po monitorowaniu samego serwera.

Najpierw trzeba upewnić się, że router potrafi mówić SNMP. Niekiedy wymaga to włączenia opcji w panelu, czasem instalacji alternatywnego firmware’u (OpenWrt, DD‑WRT). Decydując się na alternatywny soft, dobrze jest mieć chwilę na spokojne testy, a nie robić tego „na żywca” w środku tygodnia pracy zdalnej.

Kiedy SNMP na routerze jest włączone, dodajesz do docker-compose.yml usługę SNMP exporter, np.:

  snmp_exporter:
    image: prom/snmp-exporter:latest
    container_name: snmp_exporter
    volumes:
      - ./exporters/snmp/snmp.yml:/etc/snmp_exporter/snmp.yml:ro
    ports:
      - "9116:9116"
    restart: unless-stopped

W pliku ./exporters/snmp/snmp.yml określasz, jakie urządzenia chcesz obsłużyć. Dla startu możesz użyć przykładowej konfiguracji z repozytorium projektu i dopisać sekcję dla swojego routera.

Następnie rozbudowujesz konfigurację Prometheusa:

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["localhost:9100"]

  - job_name: "router-snmp"
    metrics_path: /snmp
    params:
      module: [if_mib]
    static_configs:
      - targets: ["192.168.1.1"]   # adres routera
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: "snmp_exporter:9116"

Ten blok robi za „przekładnię”: Prometheus udaje się do SNMP exporter (snmp_exporter:9116) i prosi go, żeby ten z kolei odpytatywał router po SNMP. Po kilku minutach w Prometheusie i Grafanie pojawią się nowe metryki: prędkość interfejsów, liczba błędów, liczba bajtów wysłanych i odebranych.

Grafana: pierwsze dashboardy dla serwera i routera

Najważniejsze punkty

• Bez monitoringu domowa sieć działa „na czuja” – dopiero wgląd w realne dane pokazuje, które urządzenia i kiedy naprawdę zapychają łącze, zamiast ogólnego wrażenia, że „internet muli”.
• Prosty monitoring z użyciem otwartego oprogramowania pozwala szybko odróżnić problemy po stronie operatora od kłopotów wewnątrz LAN (Wi‑Fi, lokalne transfery, kopie zapasowe, gry, streaming).
• Analiza metadanych ruchu (kto, kiedy, ile, dokąd) działa jak dodatkowa warstwa bezpieczeństwa – pomaga wychwycić podejrzane urządzenia, nietypowe połączenia i pierwsze objawy infekcji, zanim sytuacja wymknie się spod kontroli.
• Monitoring domowej sieci nie oznacza podglądania treści – pracuje głównie na statystykach i kierunkach ruchu, dzięki czemu można diagnozować problemy i pilnować bezpieczeństwa, zachowując sensowną prywatność domowników.
• W praktyce narzędzia open source szybko się „spłacają”: ułatwiają rozmowę z operatorem (konkretne wykresy opóźnień i strat), kontrolę limitowanych pakietów danych oraz porządkowanie sieci z dawno zapomnianych urządzeń.
• Dla rodziców monitoring to sposób na rozsądną kontrolę – widać kiedy i jak intensywnie dzieci korzystają z sieci oraz można blokować podejrzane domeny, bez wchodzenia w treść ich komunikacji.
• Zestaw narzędzi open source może działać jak domowy system wczesnego ostrzegania: zbiera historię, pokazuje ją na przejrzystym pulpicie i alarmuje przy nietypowych skokach ruchu, zamiast wymagać ciągłego „siedzenia na logach”.