Samodzielne monitorowanie sieci domowej: narzędzia i konfiguracja w praktyce

Po co w ogóle monitorować sieć domową i czego się spodziewać

Typowe problemy w domowej sieci, które monitoring „łapie” od razu

Domowa sieć rzadko „pada” całkowicie. Częściej dzieje się coś nieoczywistego: Netflix się przycina, wideokonferencja rwie głos, a strony niby działają, ale wolniej niż zwykle. Bez danych wszystko sprowadza się do zgadywania: „to pewnie dostawca”, „może Wi‑Fi”, „może za dużo urządzeń”. Monitoring sieci domowej pozwala zamienić to zgadywanie w konkrety.

Najczęstsze problemy, które dobrze skonfigurowany monitoring wyciągnie na wierzch:

• Zrywanie Wi‑Fi – chwilowe spadki zasięgu, przełączanie między pasmami 2,4/5 GHz, zapchany kanał przez sąsiadów.
• „Znikający” internet – router działa, ale połączenie do operatora (WAN) się rozłącza, restart modemu pomaga „na chwilę”.
• Losowe lagi – ping rośnie skokowo, gry online dostają „skoki” opóźnień, a rozmowy VoIP zaczynają przerywać.
• Wolne łącze – ktoś ściąga duży plik, robi backup w chmurze lub aktualizacje i zjada całą przepustowość.

Zamiast tłumaczyć rodzinie, że „to chyba wina dostawcy”, lepiej wejść na wykresy i zobaczyć: między 19:00 a 21:00 upload stoi na 100% albo ping do routera jest idealny, a do internetu rośnie – czyli problem raczej po stronie operatora.

Co konkretnie daje monitoring sieci domowej

System monitorowania sieci domowej nie jest fanaberią dla adminów. To praktyczne narzędzie, które pozwala:

• złapać przyczynę problemu w czasie – gdy coś się wysypie o 3:00 w nocy, rano widać na wykresach, kiedy i jak długo była przerwa;
• udokumentować awarie – przy reklamacji do operatora pokazujesz logi: „przerwy od 22:15 do 22:45, codziennie przez tydzień”;
• określić, co jest wąskim gardłem – czy to Wi‑Fi, router, łącze od dostawcy, czy nadmierne obciążenie przez jedno urządzenie;
• utrzymać kontrolę nad rozrostem sieci – im więcej IoT, kamer i urządzeń, tym łatwiej coś „zagubić” bez monitoringu.

Po kilku tygodniach zbierania danych zaczyna być widać wzorce: kiedy sieć jest obciążona, kiedy dostawca ma problemy, które urządzenia są najbardziej aktywne. Dzięki temu decyzje o zmianie routera, dołożeniu access pointa czy zmianie taryfy nie są już strzałem w ciemno.

Czego monitoring nie zrobi, choć czasem się tego oczekuje

Monitoring sieci domowej to termometr, a nie lek. Sam w sobie nie przyspieszy internetu, nie poprawi zasięgu ani nie naprawi kiepskiego kabla w ścianie. Może jedynie pokazać:

• że link od dostawcy rzadko osiąga deklarowaną przepustowość,
• że router ma 100% obciążenia CPU przy większym ruchu,
• że Wi‑Fi na jednym z pięter ma dramatycznie niski sygnał.

Ta informacja sama nie rozwiązuje problemu, ale daje mocny argument do działania: wymiany sprzętu, przebudowy sieci, zmiany operatora. Różnica jest taka, że decyzja opiera się na danych, a nie na „wydaje mi się, że wieczorami jest gorzej”.

Jednorazowe testy kontra stałe monitorowanie

Większość użytkowników zna jednorazowy speedtest albo kliknięcie „pinguj” w jakiejś aplikacji. To fotka w jednym momencie. Stały monitoring tworzy film, na którym widać, jak parametry zmieniają się w czasie.

Różnice są zasadnicze:

• Test jednorazowy – przydatny, gdy chcesz szybko sprawdzić, czy coś działa tu i teraz.
• Stały monitoring – zbiera dane automatycznie, bez nadzoru, 24/7, a potem prezentuje je na wykresach i w logach.

Jednorazowy test nigdy nie złapie problemu, który występuje przez 5 minut o północy. Stały monitoring złapie, zapisze i pokaże – i na tym polega jego przewaga.

Podstawy: co warto monitorować w domu (prosty model w głowie)

Trzy poziomy domowej sieci: WAN, router, urządzenia

Żeby sensownie monitorować sieć domową, dobrze mieć w głowie prosty model. Najprościej podzielić całą infrastrukturę na trzy poziomy:

• Łącze do dostawcy (WAN) – modem, ONT, port WAN w routerze i wszystko, co „na zewnątrz domu”.
• Router/brama – centralne urządzenie, które rozdziela internet, robi NAT, firewall i zarządza ruchem.
• Urządzenia domowe (LAN / Wi‑Fi) – komputery, telefony, telewizory, konsole, IoT, access pointy.

Monitoring powinien dotykać każdego z tych poziomów. Ping tylko do zewnętrznego serwera nie pokaże, że problem leży między laptopem a routerem. Z kolei ping tylko do routera nie pokaże kłopotów po stronie dostawcy.

Kluczowe parametry: dostępność, ping, przepustowość, obciążenie

Domowa sieć nie wymaga dziesiątek metryk. Wystarczy kilka, za to monitorowanych regularnie:

• Dostępność (up/down) – czy router odpowiada, czy zewnętrzne hosty odpowiadają; typowo mierzone pingiem.
• Ping/latencja – czas odpowiedzi do routera (diagnostyka LAN/Wi‑Fi) i do Internetu (diagnostyka WAN).
• Jitter – zmienność opóźnień; istotna przy grach i VoIP.
• Przepustowość – jaką realnie prędkość wysyłania/pobierania osiąga łącze przy teście.
• Obciążenie routera – wykorzystanie CPU, pamięci RAM, obciążenie interfejsów sieciowych.
• Siła i jakość sygnału Wi‑Fi – poziom RSSI, prędkość linku, liczba ponownych transmisji.

Połączenie kilku z tych parametrów daje pełny obraz. Jeżeli ping do routera jest niski, a do internetu wysoki – problem leży poza domem. Jeśli oba są wysokie lub router gubi odpowiedzi, wąskie gardło jest w sieci lokalnej.

Dane techniczne a dane wrażliwe – granica, której lepiej nie przekraczać

Monitoring sieci domowej łatwo zamienić w podglądanie wszystkich, kto, kiedy i na jakie strony wchodzi. Technicznie da się zbierać takie dane (np. przez pełne logowanie pakietów, proxy lub DPI), ale w domu to zły kierunek. Po pierwsze – kwestie prywatności. Po drugie – ogromna ilość danych i komplikacja.

Bezpieczny, zdrowy zakres domowego monitoringu to:

• statystyki ruchu per urządzenie (ile MB/s, jaki procent łącza),
• dane o stanie interfejsów (up/down, błędy, obciążenie),
• parametry wydajnościowe (CPU, RAM, obciążenie Wi‑Fi),
• stany połączeń WAN (czas pracy, wymuszone restarty, zmiana adresu IP).

Nie ma potrzeby logowania pełnych adresów URL czy zawartości pakietów. Do diagnostyki problemów z internetem wystarczają dane zagregowane. Takie podejście jest praktyczne i nie wchodzi w konflikt z prywatnością domowników.

Jak często zbierać dane, żeby nie zabić domowego sprzętu

Domowy monitoring nie może przeciążać routera czy Raspberry Pi. Interwały zbierania danych trzeba dobrać rozsądnie. Dla większości przypadków wystarczą:

• Ping – co 10–60 sekund, w zależności od potrzeb; przy 10 sekundach zmiany są już bardzo dobrze widoczne.
• SNMP z routera – co 30–60 sekund; rzadsze próbkowanie znacząco odciąża słabszy sprzęt.
• Testy przepustowości – kilka razy dziennie, najlepiej poza godzinami szczytu.
• Parametry Wi‑Fi – co 30–60 sekund, jeśli router udostępnia takie dane.

Za gęste zbieranie danych (np. ping co 1 sekundę z kilku urządzeń jednocześnie) w małej sieci bardziej przeszkadza, niż pomaga. Z drugiej strony pomiary raz na 10 minut są zbyt rzadkie, aby wychwycić krótkie przerwy. Złoty środek to interwały rzędu kilkudziesięciu sekund.

Niezbędne elementy zestawu do monitoringu w praktyce

Router z obsługą logowania, SNMP lub API

Bez sensownego routera monitoring sieci domowej będzie mocno ograniczony. Nie chodzi o drogi sprzęt klasy korporacyjnej, ale o kilka konkretnych funkcji:

• Logi systemowe – możliwość zapisania logów na zewnętrzny serwer (syslog) lub chociaż lokalnie z dostępem przez WWW/SSH.
• SNMP – prosty protokół monitorowania, który pozwala zbierać dane o interfejsach, CPU i pamięci.
• SSH/Telnet – zdalny dostęp do powłoki lub konsoli routera; przydaje się przy bardziej zaawansowanych skryptach.
• API HTTP – niektóre routery oferują WebAPI, z którego można pobierać statystyki bezpośrednio.

Jeżeli router od operatora jest bardzo ograniczony, można rozważyć dwa warianty: postawienie za nim własnego routera (modem/ONT w trybie bridge) albo wgranie alternatywnego firmware (OpenWrt, jeśli sprzęt jest wspierany). W obu przypadkach zyskujesz znacznie większą kontrolę nad danymi do monitoringu.

Mała maszyna pod monitoring: Raspberry Pi, stary laptop, mini‑PC, NAS

System monitoringu sieci domowej wymaga urządzenia, które będzie działać non‑stop. Typowe opcje to:

• Raspberry Pi – małe, energooszczędne, łatwo dostępne; idealne dla Netdata, Prometheusa, Smokepinga czy Grafany.
• Stary laptop/PC – świetny na start, jeśli już leży w szafie; większy pobór prądu, ale zero kosztów zakupu.
• Mini‑PC – droższe, ale często mocniejsze; dobre, gdy chcesz uruchomić więcej usług.
• NAS z obsługą Dockera – wielu producentów pozwala uruchamiać kontenery; monitoring można wtedy postawić obok istniejących usług.

Kluczowa sprawa: to urządzenie powinno być podłączone kablem do routera. Monitoring zrobiony po Wi‑Fi jest podatny na zakłócenia samego Wi‑Fi, przez co dane mogą być mylące.

Konfiguracja sieci: stały adres IP i stabilne połączenie

Domowy serwer monitoringu musi być łatwy do znalezienia przez router i inne urządzenia. Najprościej zapewnić to przez:

• stały adres IP na urządzeniu (konfiguracja w systemie) lub
• rezerwację DHCP w routerze po adresie MAC (router zawsze przydziela ten sam IP).

Druga metoda jest wygodniejsza w domowych warunkach: logujesz się do routera, odszukujesz urządzenie w liście klientów, dodajesz rezerwację IP. Od tej chwili monitor ma stały adres, niezależnie od restartów.

Dlaczego nie wystarczy telefon i aplikacja operatora

Większość operatorów ma swoje aplikacje mobilne do „monitoringu internetu”. Zwykle pokazują one:

• stan łącza (online/offline),
• jednorazowy lub prosty wykres prędkości,
• czasem listę podłączonych urządzeń.

To przydatne, ale dalekie od pełnego monitoringu sieci domowej. Ograniczenia są oczywiste:

• dane są przechowywane krótko lub tylko zgrubnie agregowane,
• nie masz dostępu do surowych logów ani do SNMP,
• brakuje możliwości tworzenia własnych alertów i wykresów.

Telefon nadaje się świetnie do jednorazowych testów (speedtest, ping), ale nie jako centrum monitoringu. Urządzenie mobilne śpi, wychodzisz z domu, zmieniasz sieć – pomiary przestają być ciągłe. Dlatego warto zainwestować w małą, stale włączoną maszynę.

Przegląd narzędzi: od prostych testów po pełne systemy

Najprostsze narzędzia: ping, traceroute, speedtest CLI

Każdy system operacyjny ma zestaw podstawowych narzędzi sieciowych. Do ręcznej diagnostyki przydają się szczególnie:

• ping – sprawdzanie, czy host odpowiada i w jakim czasie;
• traceroute / tracert – śledzenie trasy pakietów, przydatne gdy problem leży „dalej” niż dostawca;
• speedtest CLI – linuksowa/CLI‑owa wersja popularnego testu prędkości.

Takie narzędzia można też w prosty sposób zautomatyzować, uruchamiając skrypty w zadaniach cyklicznych (cron w Linux, Harmonogram zadań w Windows). To już zaczątek stałego monitoringu, choć jeszcze bez wygodnych wykresów.

Lekkie rozwiązania domowe: Smokeping, Netdata, LibreNMS, Zabbix, Prometheus + Grafana

Porównanie popularnych narzędzi pod kątem domowego użycia

Rozwiązań do monitoringu jest dużo, ale w domu liczy się prostota, czytelność i małe wymagania sprzętowe. Krótki przegląd pod kątem zastosowania w mieszkaniu lub małym domu:

• Smokeping – wyspecjalizowany w opóźnieniach i jitterze; świetny, gdy chcesz zobaczyć, jak „oddycha” łącze w ciągu dnia.
• Netdata – bardzo łatwa instalacja, automatyczna detekcja usług, dobre wykresy w czasie rzeczywistym.
• LibreNMS – klasyczne monitorowanie przez SNMP; dobre do śledzenia routerów, switchy, NAS‑ów.
• Zabbix – rozbudowany system, który umie dużo więcej niż potrzeba w typowym domu, ale sporo osób i tak go używa.
• Prometheus + Grafana – elastyczny zestaw; wykresy można „wyrzeźbić” dokładnie pod siebie, ale wymaga odrobiny wprawy.

Dla prostego startu wystarczy Netdata lub Smokeping. Gdy zechcesz łączyć dane z wielu źródeł (router, Pi, NAS, kilka hostów), rozsądniej wejść w Prometheusa lub Zabbixa.

Smokeping – gdy kluczowy jest ping i jitter

Smokeping to klasyk do badania jakości łącza pod kątem opóźnień. Nie śledzi CPU routera czy liczby pakietów, ale pozwala zobaczyć:

• czy opóźnienia rosną w godzinach szczytu,
• czy operator „dusi” pakiety wieczorami,
• czy są krótkie, trudne do wychwycenia przerwy.

Typowa konfiguracja domowa to kilkanaście celów pomiarowych:

• sam router (brama domowa),
• DNS operatora i publiczne DNS (np. 1.1.1.1, 8.8.8.8),
• kilka popularnych serwisów (np. duże portale, serwer gier),
• opcjonalnie – drugi punkt w Internecie (VPS), jeżeli taki masz.

Smokeping rysuje „chmurki” opóźnień. Po kilku dniach widać rytm doby i typowe problemy. Gdy ktoś narzeka, że „laguje”, zaglądasz do wykresu i od razu wiadomo, czy to wina Wi‑Fi, czy operatora.

Netdata – szybki podgląd stanu jednego lub kilku hostów

Netdata sprawdza się jako „stetoskop” do domowego serwera, routera z Linuxem czy NAS‑a. Po instalacji:

• zbiera metryki systemowe (CPU, RAM, dyski, sieć),
• pokazuje ruch na interfejsach,
• ma wbudowane prostsze alerty.

Na jednym Raspberry Pi możesz mieć Netdatę do monitoringu samego Pi (czy nie brakuje RAM, czy karta SD nie zdycha) i podstawowych parametrów sieci. Netdata sama odkryje np. interfejsy sieciowe i otwarte porty, nie trzeba pisać dziesiątek reguł.

LibreNMS i Zabbix – gdy chcesz „prawdziwe NMS” w domu

LibreNMS i Zabbix są bliżej rozwiązań firmowych niż domowych, ale mają dwie mocne zalety: ogarniają różne urządzenia w jednym miejscu i potrafią wysyłać sensowne alerty.

LibreNMS jest mocno skupiony na SNMP. Świetnie dogaduje się z:

• routerami z OpenWrt/Mikrotik/EdgeOS,
• switchami zarządzalnymi,
• drukarkami sieciowymi, NAS‑ami itp.

Zabbix z kolei łączy SNMP, agentów, checki HTTP, TCP, skrypty, ping – daje duże pole manewru. Przydaje się, jeśli obok routera i Wi‑Fi chcesz też pilnować np. serwera z kontenerami, domowego Home Assistanta, czy usług typu VPN.

Prometheus + Grafana – elastyczny zestaw do „składania” własnych widoków

Prometheus zbiera metryki, Grafana je rysuje. Przy domowym monitoringu ten duet ma sens, gdy:

• chcesz połączyć dane z kilku źródeł (router, Pi, NAS, AP),
• lubisz mieć dashboardy „pod siebie”,
• nie boisz się prostych konfiguracji w YAML/JSON.

W praktyce wygląda to tak:

1. Na routerze/NAS‑ie/serwerze uruchamiasz eksportery (np. node_exporter, snmp_exporter).
2. Prometheus odpytuje te eksportery co kilkanaście–kilkadziesiąt sekund.
3. Grafana czyta dane z Prometheusa i rysuje wykresy.

Plus jest taki, że raz zrobione dashboardy służą latami. Dodanie kolejnego urządzenia to zazwyczaj dopisanie kilku linijek do konfiguracji Prometheusa i skopiowanie panelu w Grafanie.

Szybki start: prosty monitoring na jednym komputerze (bez serwera)

Monitoring z użyciem skryptów i crona

Jeśli nie chcesz od razu stawiać serwera, można zacząć od prostych skryptów uruchamianych cyklicznie. W praktyce potrzebujesz:

• jednego stałego komputera (np. domowy PC lub laptop, który często jest włączony),
• kilku skryptów bash/powershell,
• harmonogramu zadań (cron lub Harmonogram zadań Windows).

Podstawowy zestaw:

• skrypt pingujący router i kilka zewnętrznych adresów,
• skrypt odpalający speedtest CLI raz na kilka godzin i zapisujący wyniki,
• opcjonalnie skrypt zliczający ilość przesłanych danych przez interfejs (Linux: /proc/net/dev lub vnstat).

Przykład prostego logowania pinga w Linux

Na dowolnym Linuxie można dodać skrypt, który co minutę dopisze linię do pliku CSV:

#!/bin/bash
TARGETS=("192.168.1.1" "1.1.1.1" "8.8.8.8")
LOG="/var/log/home_ping.csv"

if [ ! -f "$LOG" ]; then
  echo "timestamp,target,loss,avg_ms" >> "$LOG"
fi

for t in "${TARGETS[@]}"; do
  OUT=$(ping -c 5 -w 10 "$t")
  LOSS=$(echo "$OUT" | grep -oP 'd+(?=% packet loss)')
  AVG=$(echo "$OUT" | grep -oP '(?<=rtt min/avg/max/mdev = )[0-9.]+')
  DATE=$(date -Iseconds)
  echo "$DATE,$t,$LOSS,$AVG" >> "$LOG"
done

Następnie dodajesz wpis do crona:

* * * * * /usr/local/bin/home_ping.sh >/dev/null 2>&1

Po kilku dniach masz plik z historią opóźnień. Można go wrzucić do Excela, LibreOffice, czy prostego narzędzia do wykresów i zobaczyć, jak zachowuje się łącze.

Prosty speedtest CLI z logowaniem prędkości

Podobny pomysł można zastosować do testowania przepustowości. Przykład dla speedtest CLI (wersja od Ookla):

#!/bin/bash
LOG="/var/log/home_speedtest.csv"

if [ ! -f "$LOG" ]; then
  echo "timestamp,ping_ms,download_mbps,upload_mbps" >> "$LOG"
fi

OUT=$(speedtest --format=json)
DATE=$(date -Iseconds)
PING=$(echo "$OUT" | jq '.ping.latency')
DOWN=$(echo "$OUT" | jq '.download.bandwidth' | awk '{printf "%.2f", $1*8/1000000}')
UP=$(echo "$OUT" | jq '.upload.bandwidth' | awk '{printf "%.2f", $1*8/1000000}')

echo "$DATE,$PING,$DOWN,$UP" >> "$LOG"

Takiego speedtesta warto uruchamiać rzadko, np. 4–6 razy na dobę. W przeciwnym razie sam test zacznie „zapchać” łącze i fałszować pomiary.

Monitoring w Windows przy użyciu PowerShell i Harmonogramu zadań

W Windows można zrobić podobny zestaw skryptów w PowerShell. Przykładowy ping do routera i DNS‑ów:

$targets = @("192.168.1.1","1.1.1.1","8.8.8.8")
$log = "C:logshome_ping.csv"

if (!(Test-Path $log)) {
    "timestamp,target,status,avg_ms" | Out-File -FilePath $log -Encoding utf8
}

foreach ($t in $targets) {
    $res = Test-Connection -ComputerName $t -Count 5 -ErrorAction SilentlyContinue
    $timestamp = Get-Date -Format o
    if ($res) {
        $avg = ($res | Measure-Object -Property ResponseTime -Average).Average
        "$timestamp,$t,ok,$avg" | Out-File -FilePath $log -Encoding utf8 -Append
    } else {
        "$timestamp,$t,down," | Out-File -FilePath $log -Encoding utf8 -Append
    }
}

Skrypt dodajesz jako zadanie cykliczne w Harmonogramie zadań (np. co 2 minuty). Efekt podobny jak w Linuxie – prosty dziennik stabilności połączeń.

Konfiguracja routera pod monitoring – logi, SNMP, API

Włączenie i wysyłanie logów z routera

Najpierw logowanie. W panelu routera szukasz sekcji typu „System Log”, „Syslog”, „Logi”. Przydatne opcje:

• włączenie szczegółowych logów systemowych,
• wysyłanie logów na zewnętrzny serwer (adres IP twojego serwera/log‑hosta),
• ustawienie poziomu logowania (np. warnings + errors + notices).

Jeśli router potrafi wysyłać logi na serwer syslog, na Raspberry Pi lub innym hostcie instalujesz prosty syslogd (np. rsyslog) i konfigurujesz odbiór zdalnych logów. W efekcie przy każdym restarcie łącza, zmianie IP WAN, błędach PPPoE – w logach pojawia się ślad.

Podstawowa konfiguracja SNMP

SNMP to podstawa przy monitorowaniu interfejsów i obciążenia. Na domowym routerze zwykle wystarczą:

• SNMPv2c z losową community (nie „public”),
• ograniczenie dostępu SNMP tylko z sieci LAN, najlepiej do jednego IP (twojego serwera monitoringu),
• włączenie odpytywania tylko podstawowych OID‑ów (interfejsy, system, pamięć).

W panelu konfiguracyjnym wybierasz:

1. włączenie serwera SNMP,
2. ustawienie nazwy community (np. coś losowego),
3. opcjonalnie listę dozwolonych adresów IP.

Po zapisaniu zmian sprawdzasz z serwera monitoringu, czy router odpowiada na zapytania SNMP, np.:

snmpwalk -v2c -c TWOJE_COMMUNITY 192.168.1.1 ifDescr

API i SSH – dane poza SNMP

Nie wszystkie routery mają sensowne SNMP. Niektóre (np. część modeli z OpenWrt, MikroTik, Ubiquiti) pozwalają za to:

• odpytować API HTTP/REST (np. o listę klientów, bitrate Wi‑Fi),
• łączyć się po SSH i wywoływać komendy zdalne zwracające dane w JSON/tekst.

Typowy trik: skrypt w Pythonie lub bashu loguje się na router po SSH kluczem (bez hasła) i wykonuje komendę typu:

ssh router "iw dev wlan0 station dump"

Wynik jest parsowany i zamieniany na metryki (np. liczba klientów Wi‑Fi, sygnał RSSI). Takie dane można potem wrzucić do Prometheusa (exporter), Zabbixa (sender) czy choćby do pliku CSV.

Bezpieczeństwo przy otwartym SNMP i API

Monitoring to dodatkowa powierzchnia ataku, więc konfiguracja musi być ostrożna:

• SNMP tylko w LAN, bez przekierowań na WAN,
• logowanie API/SSH tylko ze znanych adresów (firewall routera),
• dla SSH – klucze zamiast haseł, wyłączone logowanie roota,
• jeśli router wspiera SNMPv3 – użyj go zamiast v2c.

W domu to nie jest ogromny problem, ale kilka prostych zasad eliminuje najczęstsze wpadki.

Budowa małego serwera monitoringu (np. na Raspberry Pi) – krok po kroku

Przygotowanie Raspberry Pi pod monitoring

Minimalny plan dla Pi:

1. Instalacja Raspberry Pi OS Lite (bez środowiska graficznego).
2. Konfiguracja sieci – rezerwacja IP w routerze lub statyczny adres.
3. Włączenie SSH, zmiana hasła, uaktualnienie systemu.

sudo apt update && sudo apt upgrade -y
sudo raspi-config  # włączenie SSH, ustawienie strefy czasowej itp.

Pi podłączasz kablem do routera i ustawiasz w takim miejscu, żeby nie było ryzyka przypadkowego odłączenia zasilania.

Instalacja Prometheusa, Grafany i eksportera SNMP

Na świeżym Raspberry Pi można postawić prosty stos Prometheus + Grafana:

1. Instalacja Dockera i Docker Compose (dla wygody zarządzania).
2. Przygotowanie docker-compose.yml z usługami prometheus, grafana, snmp‑exporter.
3. Dodanie pliku konfiguracyjnego Prometheusa z jobami dla routera i samego Pi.

Przykładowa konfiguracja Docker Compose dla Prometheusa i Grafany

Prosty plik docker-compose.yml wystarczy, żeby uruchomić podstawowy zestaw usług:

version: "3.8"

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

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

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

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=zmien_mnie
    ports:
      - "3000:3000"
    restart: unless-stopped

volumes:
  prometheus_data:
  grafana_data:

Struktura katalogów na Pi może wyglądać tak:

/opt/monitoring/
  docker-compose.yml
  prometheus/
    prometheus.yml
  snmp-exporter/
    snmp.yml

Podstawowa konfiguracja Prometheusa pod domową sieć

W pliku prometheus.yml definiujesz, które urządzenia mają być odpytywane. Minimalny przykład:

global:
  scrape_interval: 30s
  evaluation_interval: 30s

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "raspberry"
    static_configs:
      - targets: ["localhost:9100"]  # node-exporter

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

Po zapisaniu konfiguracji uruchamiasz cały zestaw:

cd /opt/monitoring
docker compose up -d

Interfejs Prometheusa pojawi się na porcie 9090, Grafana na 3000. Z poziomu Prometheusa można szybko sprawdzić, czy metryki z routera spływają (np. zapytaniem ifHCInOctets).

SNMP exporter – podstawowy moduł dla routera

Domowe użycie często ogranicza się do monitorowania interfejsu WAN. W pliku snmp.yml możesz zostawić tylko moduł if_mib albo dodać prostą definicję:

modules:
  if_mib:
    walk:
      - 1.3.6.1.2.1.2       # IF-MIB
      - 1.3.6.1.2.1.31.1.1  # ifXTable
    lookups:
      - source_indexes: [ifIndex]
        lookup: ifAlias
      - source_indexes: [ifIndex]
        lookup: ifName
    overrides:
      ifAlias:
        ignore: true

Po stronie routera warto nazwać interfejsy (jeśli się da), np. opisać port WAN jako „WAN”, a porty LAN jako „LAN1/2/3”. W Grafanie łatwiej wtedy zidentyfikować, który wykres dotyczy wyjścia na internet.

Pierwsze dashboardy Grafany dla domowej sieci

Pierwsze panele można złożyć z gotowych klocków. Minimalny zestaw, który realnie pomaga:

• tablica z opóźnieniami (ping do DNS, bramy, wybranego hosta w sieci),
• wykres obciążenia łącza (download/upload na interfejsie WAN),
• wykres obciążenia CPU/ramu na routerze (jeśli to wystawiasz),
• lista aktualnie podłączonych klientów (jeśli masz takie metryki).

Typowe zapytanie dla ruchu na interfejsie (Prometheus):

rate(ifHCInOctets{instance="192.168.1.1", ifName="wan"}[5m]) * 8

Wykres pokazuje ilość bitów na sekundę. W Grafanie ustaw jednostkę na „bits/sec” i dodaj osobny panel dla ifHCOutOctets (upload).

Alerty – prosta kontrola domowej sieci

Sam wykres nie pomaga, jeśli nikt na niego nie zagląda. Prometheus ma Alertmanagera, ale na start wystarczą proste alerty mailowe lub powiadomienia na komunikator.

Przykładowy alert na brak odpowiedzi z routera (Prometheus Rule):

groups:
  - name: home-alerts
    rules:
      - alert: RouterDown
        expr: up{job="router-snmp"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Router nie odpowiada"
          description: "Brak odpowiedzi SNMP z routera przez 2 minuty."

Reszta zależy od kanału powiadomień – część osób woli maila, inni webhook do Matrix/Slack/Telegram. Przy domowym użyciu zwykle wystarczy powiadomienie w telefonie, gdy router zniknie na dłużej niż kilka minut.

Praktyczne scenariusze monitorowania: dostępność, ping, przepustowość, Wi‑Fi

Dostępność internetu i routera

Najprostszy scenariusz: wykrycie, czy internet faktycznie działa, a nie tylko świeci dioda na routerze. Do tego przydają się dwa poziomy testów:

• ping do bramy (routera) – wykrywa problemy w sieci lokalnej,
• ping do zewnętrznych hostów (np. 1.1.1.1, 8.8.8.8, własny serwer VPS) – pokazuje, czy jest wyjście w świat.

Sensowna logika alertu:

• jeśli nie odpowiada router – problem w LAN lub zasilaniu,
• jeśli odpowiada router, ale nie odpowiadają hosty w internecie – problem z dostawcą.

W Prometheusie można to zamodelować np. dwoma jobami: ping-lan i ping-wan, a w regułach ustawić różne komunikaty. W praktyce różnica jest bardzo wygodna: od razu wiadomo, czy warto wyciągać kabel z gniazdka, czy dzwonić do ISP.

Stabilność pingu i wykrywanie „mikro-zacięć”

Sam fakt, że ping odpowiada, nie wystarcza. Przydatny jest też wykres opóźnienia i utraty pakietów. Daje to narzędzie typu smokeping lub eksportery pingu dla Prometheusa.

Typowe objawy widoczne na wykresie:

• losowe skoki opóźnienia co kilka minut – zakłócenia radiowe, przeładowane Wi‑Fi,
• ciągłe „zęby” pingu wieczorami – przeciążona sieć operatora,
• krótkie, ale częste przerwy – restartujący się ONT/router, problem z linią.

Jedna osoba w domu może odczuwać to jako „Discord się rwie” albo „Netflix czasem spada na gorszą jakość”, a na wykresie widać wyraźne piki i dziury. Po tygodniu takich logów masz twarde dane przy rozmowie z supportem.

Monitorowanie przepustowości: WAN i kluczowe urządzenia

Druga często spotykana potrzeba to odpowiedź na pytanie „kto lub co zjada łącze”. W wersji minimalnej wystarczy podgląd zużycia pasma na interfejsie WAN i kilku hostach.

Źródła danych mogą być różne:

• SNMP na routerze – ruch per interfejs (WAN, porty LAN, czasem nawet per VLAN),
• statystyki wbudowane w firmware (MikroTik, OpenWrt, EdgeRouter) odczytywane przez API,
• vnstat lub podobne narzędzia na pojedynczych hostach (serwer NAS, PC do gier).

W praktyce wystarcza kilka paneli:

• download/upload na WAN w czasie,
• sumaryczny ruch dzienny/miesięczny na WAN (limity FUP u niektórych operatorów),
• ruch na porcie, do którego podpięty jest np. NAS albo dekoder TV.

Przykład zapytania w PromQL dla średniego ruchu z ostatnich 5 minut:

sum by (ifName) (
  rate(ifHCInOctets{instance="192.168.1.1"}[5m])
) * 8

W Grafanie można zacząć od prostych wykresów liniowych, a później dodać panele typu „Top N interfejsów” albo progi kolorów (zielony/żółty/czerwony przy zbliżaniu się do maksymalnej przepustowości łącza).

Diagnostyka Wi‑Fi: jakość sygnału, przeciążenie pasma

Wi‑Fi to źródło większości „magicznych” problemów: czasem działa, czasem nie. Nawet podstawowy monitoring sygnału i liczby klientów potrafi szybko wskazać kierunek.

Zakres danych, które da się zwykle wyciągnąć (przez API, SNMP lub SSH):

• liczba podłączonych klientów per SSID/pasmo (2,4 / 5 GHz),
• siła sygnału RSSI lub SNR dla poszczególnych urządzeń,
• aktualna prędkość linku (PHY rate) i modulacja,
• używany kanał i szerokość pasma.

Przykładowy scenariusz z OpenWrt: skrypt na Pi co minutę wykonuje:

ssh root@router "iw dev wlan0 station dump"

Następnie parsuje wynik i eksportuje do Prometheusa metryki:

• wifi_clients{iface="wlan0"},
• wifi_signal_dbm{mac="xx:xx:xx:xx:xx:xx"},
• wifi_tx_bitrate_mbps{mac="..."} .

Na wykresie od razu widać np. spadek sygnału poniżej określonego progu w jednym pokoju – wtedy przesunięcie AP o metr lub zmiana kanału ma większy sens niż kolejne resetowanie routera.

Monitorowanie kluczowych urządzeń w domu

Sieć to nie tylko router. Kilka dodatkowych punktów pomiaru bardzo pomaga:

• NAS – obciążenie CPU, RAM, zajętość dysków, temperatura, ruch sieciowy,
• mini‑PC / serwer domowy – uptime, obciążenie, miejsce na dysku,
• urządzenia IoT bramkowe (Home Assistant, bramki Zigbee) – czy są w ogóle dostępne i jak reagują.

Wiele gotowych urządzeń ma natywne integracje z Prometheusem lub Zabbixem. W wersji minimalistycznej wystarczy nawet prosty ping + SNMP (jeśli jest).

Prosty wzór na priorytety: monitoruj wszystko, co spełnia co najmniej jedno z poniższych:

• utrata urządzenia = utrata danych (NAS),
• utrata urządzenia = brak internetu (router, ONT),
• utrata urządzenia = brak automatyki / ogrzewania (serwer HA, sterowniki).

Scenariusze z życia: kiedy dane z monitoringu realnie pomagają

Kilka typowych sytuacji, gdzie zbierane dane oszczędzają czas i nerwy:

• częste restartowanie się łącza – w logach syslog widać, że PPPoE zerwał się 15 razy w ciągu dnia, zawsze o podobnych godzinach; support nie może zrzucić winy na router, bo masz historię zdarzeń,
• nagłe spadki prędkości wieczorami – wykres przepustowości WAN pokazuje, że w godzinach szczytu ping rośnie, a realna prędkość spada o połowę; to klasyczne przeciążenie sieci operatora,
• dziwne lagi w grach – smokeping pokazuje, że ping do serwera gry skacze tylko wtedy, gdy ktoś ogląda w tym czasie wideo w 4K; wiesz, że trzeba ograniczyć QoS albo ustawić priorytety, a nie resetować konsolę,
• gubiące się Wi‑Fi w jednym pokoju – historia RSSI dla danego klienta pokazuje, że sygnał momentami leci bardzo nisko, np. po przestawieniu mebli; wystarczy przesunąć AP albo dołożyć repeater.

Wspólny mianownik jest zawsze ten sam: zamiast gdybać, masz liczby. Po tygodniu czy dwóch widać wzorce, których nie da się uchwycić „na oko”.

Najczęściej zadawane pytania (FAQ)

Po co w ogóle monitorować sieć domową, skoro „internet działa”?

Monitoring przydaje się wtedy, gdy właśnie „coś niby działa, ale nie tak jak trzeba”: Netflix się przycina, wideokonferencje rwą, gry łapią lagi. Zamiast zgadywać, czy winny jest dostawca, Wi‑Fi czy jedno przeładowane urządzenie, masz twarde dane z wykresów i logów.

Stałe zbieranie informacji pozwala zobaczyć wzorce: o której godzinie łącze się zapycha, kiedy operator ma przerwy, które urządzenie zjada cały upload. Na tej podstawie da się podjąć konkretne decyzje – czy zmieniać router, dodać access point, czy raczej iść z reklamacją do operatora.

Czego monitoring sieci domowej NIE załatwi sam z siebie?

Monitoring jest „termometrem”, a nie „antybiotykiem”. Nie przyspieszy łącza, nie poprawi zasięgu Wi‑Fi i nie naprawi kiepskiego kabla w ścianie. Pokazuje jedynie, gdzie jest problem: za słabe łącze od dostawcy, router dociśnięty do 100% CPU, bardzo słaby sygnał Wi‑Fi na jednym piętrze.

Plusem jest to, że zamiast „wydaje mi się, że wieczorami jest gorzej” masz konkret: wykresy pokazujące spadki przepustowości, piki pingu albo ciągłe restarty połączenia WAN. Na tej podstawie dużo łatwiej dyskutować z operatorem lub zaplanować wymianę sprzętu.

Jakie parametry sieci domowej warto monitorować na start?

W domowych warunkach wystarczy kilka kluczowych metryk, ale mierzonych regularnie. Podstawowy zestaw to:

• dostępność – czy router i wybrane hosty w internecie odpowiadają (ping up/down),
• ping i jitter – opóźnienia do routera (LAN/Wi‑Fi) i do internetu (WAN), oraz ich zmienność,
• przepustowość – realna prędkość pobierania i wysyłania przy testach,
• obciążenie routera – CPU, RAM, zajętość interfejsów,
• parametry Wi‑Fi – poziom sygnału, jakość linku, błędy/ponowne transmisje.

Zestawienie tych danych w czasie jasno pokazuje, czy problem siedzi w Wi‑Fi, w samym routerze, czy w łączu od operatora.

Jak często wykonywać pomiary, żeby nie „zajechać” routera?

Zbyt częste testy potrafią obciążyć słabszy sprzęt bardziej niż realny ruch w sieci. Rozsądne interwały do domu to:

• ping – co 10–60 sekund (10 s daje już bardzo czytelny obraz),
• odczyty SNMP z routera – co 30–60 sekund,
• testy przepustowości – kilka razy dziennie, najlepiej poza godzinami szczytu,
• parametry Wi‑Fi – co 30–60 sekund, jeśli router to udostępnia.

Pomiar raz na 10 minut może nie złapać krótkiej, 2‑minutowej awarii. Z kolei ping co 1 sekundę z kilku urządzeń to już niepotrzebny hałas w małej sieci.

Jakie urządzenie/router jest potrzebne do sensownego monitoringu sieci domowej?

Nie jest konieczny sprzęt klasy korporacyjnej, ale zwykły „plastikowy” router z marketu często bywa zbyt ograniczony. Szukaj modeli, które potrafią co najmniej:

• zapisywać logi systemowe lokalnie lub wysyłać je na zewnętrzny serwer (syslog),
• udostępniać dane przez SNMP (interfejsy, CPU, RAM),
• pozwalają na dostęp przez SSH/Telnet lub API HTTP, aby można było zbierać dodatkowe informacje.

Dopiero z takim routerem monitoring pokaże nie tylko „czy internet działa”, ale też jak bardzo obciążony jest sam router i jego interfejsy.

Czy monitorowanie sieci domowej narusza prywatność domowników?

Może naruszać – jeśli zaczynasz logować pełne pakiety, treść połączeń czy wszystkie odwiedzane adresy URL. W warunkach domowych taki poziom szczegółowości nie ma sensu: generuje masę danych, komplikuje konfigurację i budzi słuszne obawy o prywatność.

Bezpieczny i praktyczny zakres to statystyki ruchu per urządzenie (ile wysyła/pobiera), dane o stanie interfejsów, obciążeniu routera, sile sygnału Wi‑Fi i informacjach o połączeniu WAN (czas pracy, zerwania, zmiana IP). To w zupełności wystarcza do diagnozy problemów bez „podglądania”, kto, gdzie i co dokładnie ogląda.

Czym różni się stały monitoring sieci od jednorazowego speedtestu?

Speedtest czy pojedynczy ping to „fotka” z jednej chwili. Nadaje się do szybkiego sprawdzenia, czy coś działa tu i teraz, ale nie pokaże problemów, które występują przez kilka minut w nocy albo tylko przy pełnym obciążeniu sieci.

Stały monitoring działa jak „film”: zbiera dane 24/7 i układa je na wykresach. Dzięki temu widać, że np. codziennie między 19:00 a 21:00 upload idzie na 100% (ktoś robi backupy) albo że operator ma krótkie przerwy o 2:00 w nocy. To ta perspektywa w czasie jest największą przewagą monitoringu nad jednorazowymi testami.