Różne określenia prędkości transferu danych

W sieciach komputerowych spotkamy się z kilkoma miarami prędkości przesyłania danych:

– bandwidth
– throughput
– goodput

1. bandwidth

Jest to określenie na fizyczną, teoretyczną i maksymalną przepustowość danego medium czy kanału. Można też użyć pojęcia pojemność. Jeśli mowa o kanale to trzeba pamiętać, że składa się z wielu elementów takich jak urządzenia, złącza, media transmisyjne, zakłócenia, oprogramowanie itp. Jest to zatem teoretyczna i „fabryczna” pojemność w idealnych warunkach bez zakłóceń. Coś jak rura rura wodociągu, którą o danej średnicy. Jeśli 1m długości rury mieści 1m³ wody to to jest jej pojemność. Ile tak naprawdę wody można „przepchnąć” przez tą rurę zależy od wielu czynników np. od wydajności źródła (pompy), zaworów leżących na drodze itp. Jedno jest pewne: rura (jak i łącze IT) ma określoną maksymalną pojemność (przepustowość). Jeśli rurą (z pewnych fizycznych powodów) można przepychać wodę z prędkością 1mb/s to większej prędkości nie osiągniemy. W świeci sieci LAN Ethernet mamy wiele standardów połączeń. Jednym z nich jest Ethernet 1Gbps, ful duplex. Podobnie jak w rurze z wodą, mamy tu wiele czynników wpływających na maksymalną przepustowość:

– zakłócenia
– szumy
– szybkość elektroniki
– szybkość rozchodzenia się sygnału elektrycznego w danym nośniku (np. 250 000 km/s)
– narzut samej technologii połączenia

Ten ostatni punkt zawiera w sobie narzut różnych protokołów sygnalizacyjnych działających na poziomie elektroniki w danym łączu. Przykładem może być autonegocjacja, ramki PASUE, odstępy międzyramkowe i  inna sygnalizacja. Jest o minimalny ruch ale zawsze coś.

Jeśli dana technologia oferuje nam 1Gbps to nie uzyskamy szybszego transferu. Co gorsza, ta prędkość jest prędkością netto ponieważ danych nie transmitujemy w sieci LAN/WLAN i innych ot tak sobie tylko za pomocą protokołów. Protokołu posiadają pewne dane administracyjne (np. nagłówki) co, przy stałej pojemności łącza, daje na mniej miejsca na nasze dane!

Pojęcie bandwidth czasem jest także określane w Hz a nie w bitach/sek. Przykładem jest Ethernet bandwidth o wielkości 125 MHz. Tu pojawia się kwestia kodowania sygnału więc 125 MHz != 125 Mbps. Ale o tym raczej mówimy na telekomunikacji.

To jeszcze nie wszystko. Może się okazać, że natywna przepustowość jest mniejsza niż podaje „producent” ponieważ jej część zawsze jest konsumowana na sprawy organizacyjne samej technologii. Generalnie kiedy mamy informację, że to łącze daje nam przepustowość 1Gbps, to do dyspozycji będziemy mieć nieco mniej. Producenci często podają parametry okablowania. Tutaj inny opis.

2. throughput

Jest to realna prędkość jaką uzyskamy w danym łączu czy kanale. Jest ona zazwyczaj mierzona eksperymentalnie i mocno zależy od wielu czynników takich jak obciążenie procesora/układu generującego ruch. Jest zawsze mniejsza od przepustowości kanału.

Poniżej widok ramki Ethernet – ona jako pierwsza wprowadza narzut w postaci miejsca na preambułę, pola adresów, typu, CRC i inne.

3. goodput

To określenie na maksymalną prędkość transferu naszych danych roboczych. Wpływa na nią narzut administracyjny protokołów komunikacyjnych oraz proces enkapsulacji. Każdy protokół do porcji przenoszonych danych dodaje nagłówek, co ogranicza możliwą do przesłania ilość danych roboczych.

Cały proces można czytelnie pokazać na bazie enkapasulacji. Ramka daje nam 1500 bajtów ale odpada pole Typ/Długość dwa bajty czyli zostaje 1498. Z tego (przy protokole IPv4) odpada 20 bajtów nagłówka IP i kolejno, jeśli używamy UDP, 8 bajtów jego nagłówka. Zatem mamy do dyspozycja w każdej ramce: 1500-2-20-8 = 1470 bajtów. Teraz jeszcze nagłówek ramki Ethernet.

Przykład testu prędkości transferu danych PC – RouterBoard RB49G na łączu 1 Gbps

Z niewiadomych przyczyn mamy około 36% oferowanej przez połączenie prędkości.

4. latency

Jest to opóźnienie na trasie całego kanału wynikające z wielu czynników np. zwłoki w przetwarzaniu danych (sygnału) w układach elektronicznych. Zwłoka może jest i minimalna ale jest. Kiedy na drodze naszych danych leży wiele urządzeń, każde dodaje małą zwłokę. Zwłoka może tez wynikać z obciążenia procesorów, które realizują także inne zadania (choć to zależy od urządzenia, jego przeznaczenia, oprogramowani itp)

Pomiary prędkości

Przepustowość łącza możemy badać na wiele różnych sposobów:
– programem
– sprzętem
– protokołem TCP lub UDP
– w jedną stronę lub w obie jednocześnie
– generując określoną ilość pakietów na sekundę o podanej wielkości

Podstawowe opcje testowania:
a. Protokół
Jeśli użyjemy protokołu UDP otrzymamy znacznie mniejszy narzut administracyjny niż przy protokole TCP co przełoży się na większą ilość danych użytkowych jakie możemy przesłać w jednostce czasu.

b. Kierunek
Testować przepustowości możemy generując ruch w jedną stronę lub w obie jednocześnie. Wprawdzie nasze łącza są zazwyczaj typu full-duplex ale test w obei strony jednocześnie zawsze mocniej obciąża urządzenia jak i media.

c. Generowanie pojedynczych pakietów
Posiadając generator pakietów możemy wygenerować strumień pewnej ilość pakietów na sekundę (pps) a każdy o wybranej wielkości, co pozwala także wygenerować pewien ruch wynikający z iloczynu pps*rozmiar pakietu

Przykładowe programy

1. Tester przepustowości iperf
a. ipef
Program konsolowy dostępny jest dla różnych platform w postaci instalatora lub źródeł. Dla systemu Windows pobieramy spakowane archiwum i wypakujemy z niego katalog z gotowym programem. W systemie Linux można go pobrać z repozytoriów i zainstalować:

# apt install iperf

Uwaga: podczas testu należy po obu stronach połączenia zastosować tą samą wersję. Jeśli użyjemy innych połączenie nie zostanie nawiązane.

Program może pracować w trybie klienta generując ruch lub w trybie serwera przyjmując połączenie od klienta, w każdym razie otrzymamy bogate statystyki testu. Poniżej przykład testu Windows 11 — Linux (VM na tym samym komputerze). Maszyna Windows posiada adres 192.168.7.177 natomiast nasz „serwer” czyli Linux 192.168.7.151.

Na maszynie z Linux uruchamiamy iperf w trybie serwera, protokół UDP

# iperf -s -u

Na maszynie Windows przechodzimy do katalogu z iperf i uruchamiamy go z wiersza poleceń jako klienta (-c) a jako protokoł komunikacyjny do testów wybieramy UDP (domyślnie jest TCP):

> iperf -c -u 192.168.7.151

Test domyślnie trwa 10 sekund, w naszym wypadku testujemy po protokole UDP, który ma mniejszy narzut administracyjny. Po chwili pojawia się statystyka testu.

Jeśli chcemy testować TCP to uruchamiamy serwer:
# iperf -s
Oraz klienta
> iperf -c 192.168.7.151

b. jperf
Graficzna nakładka na iperf, wymaga Javy (JRE). Ważne aby nakładka była w wersji odpowiedniej dla posiadanego narzędzia iperf. Przykładowo dla iperf 2.0 mamy jperf 2.0. Ponieważ nakładka wymaga środowiska Java musimy je zainstalować.

# apt-get install default-jre

Kolejno pobieramy pakiet jperf, rozpakujemy a w nim mamy plik jperf.sh. Trzeba tylko teraz zmienić jego uprawnienia aby można było uruchamiać.

# chmod 755 jperf.sh

Teraz można już nakładkę uruchomić klikając w przycisk po prawej. Na drugiej maszynie inicjujemy test zgodny z ustawieniami serwera (tutaj TCP)

Nakładka jperf może także działać w trybie serwera pozwalając w czytelny sposób na ustawiania opcji protokołu TCP takich jak bufor, okno, segment co mocno rzutuje na osiągane przepustowości przy ruchu w protokole TCP.

2. MikroTik Bandwidth Test
Program jest wbudowany w system RouterOS, posiada serwer oraz klienta. Znajdziemy go w menu WinBox w pozycji /Tool

– Moduł serwera /Tool/BTestServer

– Moduł klienta /Tool/Bandwidth Test

a. Serwer
Aby udostępnić nasz system jako serwer testu klikamy na Enabled i tyle. Możemy także włączyć autentykacje, w tym celu wymagane będzie utworzenie dodatkowego użytkownika. Dwie opcje jaki widzimy pozwalają określić od którego portu UDP w  górę będą one alokowane dla kolejnych sesji, których ilość ustalimy poniżej. Aby test był miarodajny w czasie jego trwania nie należ naszego RouterOS obciążać innymi zadaniami. Przycisk sessions pokaże nam aktywne sesje.

b. Klient
Znacznie więcej opcji mamy w sekcji klienta. Ustalimy tu adres docelowy (serwera), protokół komunikacyjny, ilość jednoczesnych strumieni, ograniczenia prędkości i rozmiaru pakietów. Opcja random data pozwala generować dane losowe, co dodatkowo obciąża generator.

3. MikroTik PacketGenerator
Przykład testu
Aplikacja także jest wbudowana w system RouterOS i osiągalna z menu WinBox /Tools/Traffic Generator

Za jego pomocą można ustalić budowę i zawartość pakietu oraz sposób wysyłania czyli ilość pakietów na sekundę lub oczekiwana prędkość.  Aby wygenerować ruch musimy przygotować drogę pakietu (port), jego szablon czyli budowę (protokoły, adresy itp) oraz strumień określający port, rozmiar, ilość pakietów na sekundę.

4. Inne generatory pakietów
Mogą służyć do generowania pojedynczych pakietów celem testowania np. zapory ogniowej, a także do generowania większego ruchu i tym samym testowania przepustowości przy danej budowie pakietu.
– packEth
– Packet Sender
– Nping

Przydatne serwisy:
https://github.com/srkaviani/Mikrotik-Prometheus-SNMP-Exporter
SNMP Exporter: https://sbcode.net/prometheus/snmp-exporter/
https://github.com/M0r13n/mikrotik_monitoring
MikroTik exporter fot Prometheus https://github.com/akpw/mktxp
https://github.com/somsakc/docker-observium

Monitorowanie hostów MikroTik

Monitiring przeprowadzimy na bazie konetnerów z aplikacjami Prometheus + Grafana oraz SNMP Exporter.

1. Na wybranym ROS uruchamiamy protokół SNMP (/ip/snmp)

2. Ustalamy nazwę wspólnoty np „public” dając tylko prawodoczytu, w podstawowej wersji ruch SNMP będzie nieszyfrowany

3. Jeśli mamy firewall trzeba dodać regułę zezwalającą na ruch SNMP (udp, port 161) wchodzący czy wychodzący, w zależności od naszej konfiguracji

#add action=accept chain=input dst-port=161 protocol=udp

Trzeba też pamiętać o regule dopuszczającej ruch powrotny:
#add action=accept chain=input connection-state=established,related protocol=tcp

4. Zgodnie z opisem budujemy zestaw kontenerów
Link do opisu: https://github.com/IgorKha/Grafana-Mikrotik

4a. Pobieramy kontenery
#git clone https://github.com/IgorKha/Grafana-Mikrotik.git

4b. Pojawi się katalog Grafana-Mikrotik, do którego przechodzimy

4c. W tym katalogu edytujemy plik prometheus.yml znajdujący się w katalogu prometheus, dodając do konfiguracji hosty MikroTik, które chcemy monitorować:

5. Uruchamiamy kontenery (będąc w katalogu Grafana-Mikrotik)
#sudo docker compose up -d

Pierwsze uruchomienie wymaga chwili ponieważ obrazy kontenerów muszą zostać pobrane i zainstalkowane. Po uruchomieniu można sprawdzić stan zestawu kontenerów:

#sudo docker compose stats

6. Panel Grafana
W przeglądarce odtwieramy stronę Grafany pracującej na maszynie z kontenerami. Grafana nasłuchuje domyślnie na porcie 3000, połączenie nie jest szyfrowane

Za pomcą opcji Instance możemy wybierać różne hosty, zdefiniowane wcześniej w pliku prometheus.yml.

7. Statystyki przechowywane są w w/w katalogu, który zawiera pliki konfiguracyjne całości.

8. Zestaw kontenerów możemy zatrzymać za pomocą polecenia:

#sudo docker compose stop /start

Usunąć całkowicie (pozostaną same obrazy):

#sudo docker compose down

Monitorowanie hostów MikroTik za pomocą API (Prometheus + Grafana)
Link do opisu: https://github.com/akpw/mktxp?tab=readme-ov-file
Inny pomocnik: https://github.com/M0r13n/mikrotik_monitoring

1. Na hoście, który będziemy monitorować
– tworzymy grupę np: prometheus
#/user group add name=prometheus policy=api,read,winbox,test

– tworzymy użytkownika, za pomocą którego skorzystamy a API
#/user add name=prometheus group=prometheus password=nasze-haslo

– włączamy API:
#/ip service enable api
#/ip service enable api-ssl

Jeśli chcemy skorzystać z API szyfrowanego trzeba utworzyć certyfikat, opisany w innej sekcji. Odblokować także trzeba porty TCP: 8728 i 8729 na firewall.

2. Klonujemy repozytorium pakietu

#git clone https://github.com/M0r13n/mikrotik_monitoring.git

Pojawi się katalog mikrotik_monitoring a w nim mamy podkatalog mktxp. W tym katalogu edytujemy plik mktxp.conf dodając hosty, które chcemy monitorować. Poniżej przykład:

Musimy jeszcze w tym pliku (sekcja default) ustawić dane logowania do naszych Mikrotików po API czyli port, nazwa użytkownika jak i jego hasło (ustalone wcześniej) na etapie włączania API:

Jeśli monitorujemy po API bez szyfrowania to opcje w sekcji default możemy zostawić bez zmian. Warto je przejrzec celem właczenia dodatkowych elementów, które aplikacja będzie monitorować.

3. Uruchamiamy zestaw kontenerów

#sudo docker compose up -d

Aby kontenery zatrzymać
#sudo docker compose stop

Aby je całkowicie usunąć:
#sudo docker compose down
(pozostaną ich obazy oraz dane w katalogu gdzie rozpakowaliśmy cały zastaw)

Kontenery możemy monitorować:
#sudo docker compose stats

4. Logowanie do Garafany

W tym przypadku Garafana pracuje na porcie 80 naszego hosta

Materiały video:
– https://youtu.be/i5zezvoflro?feature=shared
– https://youtu.be/P9p2MmAT3PA?feature=shared
– https://youtu.be/HXu0Ifj0oWU?feature=shared
– https://youtu.be/nX38mWxtWf0?feature=shared
– https://youtu.be/RAqMP_NnGec?feature=shared
– https://youtu.be/dZfN3uYtC2I?feature=shared
– https://youtu.be/7bp9COm0K1M?feature=shared
– https://youtu.be/Lq7j-QipNrI?feature=shared

Wprowadzenie

1. Podstawowe elementy

Protokół SNMP (ang. Simple Network Management Protocol) jest rozwiązaniem o wieloletniej tradycji (od roku 1988) i obecności w świecie IT. Aktualnie to jest raczej framework a nie sam, pojedynczy protokół. Wywodzi się z protokołów SGMP (Simple Gateway Management Protocol) protokołu monitorującego routery oraz protokołu CMIP (ang. Common Management Information Protocol). Dokumentami bazowymi są RFC 1065, 66, 76 (dotyczą one wersji 1). Aktualnie mamy w użyciu wersję 1 (chyba już nie jest używana) nie wspierającą szyfrowania czy autentykacji, wersję 2c (też nie obsługuje szyfrowania ale pozwala na efektgywne pobieranie danych, wiele za jednym poleceniem) oraz wersję 3 z autentykacją i szyfrowaniem transmisji.

Protokół SNMP jest typu klient/serwer, tutaj zwany manager/agent. Mamy zatem dwa rodzaje użądzeń.

Urządzenia monitorowane: serwerem jest agent działający na monitorowanym urządzeniu. Zazwyczaj jest to oprogramowanie wbudowane przez producenta. Takie urządzenie zwane tez jest MNE (ang. Managed Network Entity). Agent monitoruje różne parametry urządzenia i może być odczytywany przez klienta (stację monitorującą) w trybie tzw. polling (ankietowanie) lub samodzielnie wysyłać informacje na bazie tzw. pułapek (ang. traps).

Urządzenia monitorujące: klientem jest oprogramowaniem działające na stacji monitorującej (np. libreNMS, openNMS, Zabbix, Observium, MikrotTik The Dude i wiele innych). Nazwany NMS (ang. Network Management Station) i jest to centralny punkt monitorowania. To on decyduje co i jak oraz kiedy monitorować, w jakich interwałach czasu itd.

Stacja NMS może być w mare prostą aplikacją (np. iReasoning MIB Browser) bardzo złożonym oprogramowaniem z dużą bazą przechowującą historię zdarzeń z wielu monitorowanych urządzeń oraz prezentującą wyniki w postaci graficznej (np. libreNSM, Grafna+Prometheus, Zabbix i wiele innych).

SNMP Manager zajmuje się wysyłaniem zapytań, odbieraniem odpowiedzi oraz pułapek z urządzeń nadzorowanych. Przykładem jest Prometheus.

SNMP frontend to aplikacja pozwalająca zarządzać managerem, budować zapytania, prezentować odpowiedzi i wyniki. Przykładem jest snmpwalk (wiersz poleceń Linux) oraz Grafana, potężny system graficznej prezentacji statystyk SNMP.

Urządzenie zarządzane takie jak serwer, router, przełącznik, accesspoint i wiele innych zawiera:

Agent SNMP jest to oprogramowanie najczęściej wbudowane w urządzenie zbierające dane z różnych jego komponentów. Aby to wykonać posiada wbudowaną bazę MIB zawierającą ustandaryzowane identyfikatory obiektów, które mogą być monitorowane. Każdy obiekt ma przyporządkowany numer OID (ang. Object Identifier) i jest zapisany w bazie MIB (o czym jest napisane dalej). Obiektem może być temperatura CPU, stan interfejsu itp.

2. Komunikacja

Protokół SNMP używa portów 161 i 162 UDP. Jest to protokół typu żądanie/odpowiedź. Protokół UDP jest bezpołączeniowy, nie gwarantuje dostarczenia danych. Nie jest to problemem ponieważ w tym wypadku NMS może ponowić żądanie. Protokół wykorzystuje kilka komunikatów:

GetRequest: menadżer (NMS) żąda informacji (Get, GetNext, GetBulk w SNMPv2)
GetResponse: agent odpowiada menadżerowi
SetRequest: menadżer może wysłać do agenta (czyli monitorowanego urządzenia) polecenie zmiany jakiegoś parameteru
Trap/Inform: agent wysyła menadżerowi informacje o pewnym zdarzeniu

Komunikacja może odbywać sie w trzech trybach:

a. Ankietowanie (polling): stacja monitorująca (manager) odpytuje agentów o stan różnych parametrów danego urządzenia. Zaletą jest minimalne obciążenie urządzenia monitorowanego, wadą jest brak informacji dla NMS w czasie rzeczywistym. Jeśli odpytywanie jest ustawione na np. co 5 minut, NMS nie zna stanu urządzenia między kolejnymi zapytaniami. Tego typu zapytania wysyłane są na port UDP 161 agenta.

b. Pułapki (trap):  w tym wypadku urządzenie monitorowane samodzielnie wysyła informacje o różnych zdarzeniach (np. przekroczenie temperatury CPU, awaria interfejsu) do NMS. Tego typu informacje wysyłane są na port UDP 162 menadżera.

c. Stacja monitorująca wysyła do urządzenia monitorowanego zlecenia zmiany pewnego parametru, np. nazwy.

3. Typy komunikatów SNMP

Protokół SNMP korzysta z kilku typów poleceń i zawartych w nich wiadomości. Poniżej kilka przykładów.

Przykład poleceń SNMP w RouterOS:

Szczegóły poleceń SNMP tutaj.

4. Identyfikatory i bazy MIB

Wszelkie obiekty, które można monitorować (takie jak CPU, pamięć itp.) zostały opisane za pomocą SMI (ang. Structure of Management Information). Jest znormalizowany sposób prezentacji danych (RFC1155, 1065). Bazuje on unikalnych identyfikatorach obiektów OID. Te identyfikatory najczęściej są przedstawiane w postaci drzewa natomiast przechowywane są tekstowych bazach MIB (ang. Management Information Base). Dobry opis tematu baz MIB znajdziesz na stronie Oracle. Przydatną przeglądarką online jest Free MIB Browser.

Każdy obiekt do monitorowania ma swój unikalny numer i pozycje w drzewie OID. Pokazano to niżej.

Struktura drzewiasta zapewnia elastyczne i unikalne nazewnictwo obiektów. Większość urządzeń różnych producentów  znajduje się w gałęzi drzewa .1.3.6.1.4.1. Powyższy przykład pokazuje, że firma Tp-Link ma ID 11863 w gałęzi .1.3.6.1.4.1. Podobnie jak w systemie DNS cała struktura zaczyna się od korzenia symbolizowanego kropką (ang. root). Dobrym miejscem na szukanie OID jest serwis OID-INFO.

Wpisy i numery jak i nazwy OID dzielą sie na dwie grupy: standardowe oraz prywatne (producentów sprzętu). Przykładem standardowego OID jest nazwa systemu (którą posiada chyba każdy sprzęt sieciowy), ma ona numer:

.1.3.6.1.2.1.1.5 (na początku jest kropka, to ważne!).

Według drzewa OID nazwę można także zapisać jako:

.iso.org.dod.internet.mgmt.mib-2.system.sysName

Poniżej przykład na bazie polecenia snmpwalk:

Na przykładzie systemu RouterOS możemy wyświetlić OID dla interfejsów radiowych. Pierwsza część .1.3.6.1.4.1 prowadzi nas do części drzewa przeznaczonej dla producentów. Kolejno mamy numer 14988 przydzielony MikroTik. Dalej mamy to, co ustaliła ta firma jeśli chodzi o numery ODI. W tym wypadku jest to częstotliwość wybranej karty radiowej (5560 MHz).

#/interface wireless print oid

Łącząc obie ilustracje:

Dla opisu zasobów systemu RouterOS wygląda to nieco inaczej (korzystamy ze standardowej bazy i ścieżki):

Te wpisy prowadzą nas do bazy MIB.

5. Baza MIB

Baza ta przechowuje odwzorowania OID – nazwa i pozwala na efektywny zapis obiektów celem ich monitorowania. Zapis danych w bazie jest zgodny z Abstract Syntax Notification v1.

Istnieją trzy rodzaje baz MIB

Bazy MIB są standardowym zapisem obiektów. Znajduje się w nich szereg obiektów systemów Unix
Bazy MIB2 (MIBII) są rozszerzeniem baz MIB o możliwości monitorowania TCP/IP
Bazy prywatne tworzone są przez producentów sprzętu i rozszerzają możliwości MIB2 o obiekty specyficzne dla danego urządzenia.

Aby odczytać bazę prywatną system NMS musi znać jej format i przeznaczenie OID. Na szczęście producenci dobrze dokumentują te kwestie oraz istnieje wiele systemów typy NMS z różnymi wtyczkami dla konkretnego producenta. Proces łącznia baz MIB nazywa się kompilacją i polega na połączeniu bazy producenta z bazami standardowymi.

Standardowe bazy MIB (po ich uprzednim pobraniu za pomocą mibs-download) znajdziemy w systemie Linux w katalogu:
/home/jnowak/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf (tutaj pojawią się po instalacji oprogramowania SNMP)
lub
/var/lib/mibs/iana oraz ietf (tutaj pojawią się po instalacji oprogramowania SNMP i ręcznym ich pobraniu).

Baza taka zawiera obiekty do monitorowania wraz z ich parametrami, poniżej przykład bazy dla urządzenia UPS

Mamy tu informacje na temat jednego z parametrów do monitorowania: „upsIdentManufacturer” czyli ID producenta UPSa. Jest to wartość typu łańcuch znaków o maksymalnej długości 32 znaki i tylko do odczytu.

Producenci tworzą własne bazy, przykładem jest MikroTik i jego baza specyficzna dla systemu RouterOS oraz urządzeń RouterBoard. Dzięki takiej bazie można korzystać z nazw obiektów nie tylko z ich numerów.

Przykładową bazę dla MikroTik można pobrać ze strony: https://mikrotik.com/download:

Bazę taką możemy pobrać i umieścić w standardowym katalogu np. /var/lib/mibs/ietf

#wget https://download.mikrotik.com/routeros/7.17/mikrotik.mib
#sudo cp mikrotik.mib /var/lib/mibs/ietf

Kolejno zmieniamy jej nazwę na „MIKROTIK-MIB”. Teraz możemy z niej korzystać jak niżej (więcej informacji w dalszej części)

#snmpwalk -v 2c -c public -m MIKROTIK-MIB 192.168.53.6 .1.3.6.1.4.1.14988.1.1.3.17 -Of

Przełącznik -Of pozwala pokazać nazwy a nie tylko identyfikatory numeryczne

Więcej informacji na temat SNMP MikroTik: https://wiki.mikrotik.com/Manual:The_Dude/MIB_Nodes.

Kompilacja nowej bazy
Pod pojęciem kompilacji rozumiemy dodanie nowej bazy MIB do managera celem rozszerzenia jego możliwości o monitorowanie dodatkowych urządzeń. Kompilacja polega na pobraniu bazy MIB producenta i wykonaniu czynności w zależności od posiadanego oprogramowania. Po kompilacji mamy możliwość odczytu specyficznych OID z danego urządzenia. Operacje taką przeprowadziny w przykładowym systemie NMS w dalszej części materiałów.

1. Architektura rozwiązania

Observium <-- SNMP -- Docker[ Pi-Hole ]

1. Skrypt na Linux pobiera statystyki z API Pi-hole v6 (/api/stats/summary)
2. Linux udostępnia te dane poprzez SNMP Extend (net-snmp)
3. Observium CE i LibreNMS zbierają statystyki SNMP z Linuxa (192.168.53.110)

2. Konfiguracja Pi-hole — API

2.1. Logowanie do panelu Pi-hole

Otwórz przeglądarkę i przejdź pod adres:

http://192.168.55.4/admin/login

Zaloguj się hasłem: ZAQ!2wsx

2.2. Generowanie klucza API (App Password)

Pi-hole v6 wymaga uwierzytelnienia dla endpointów API. Wygeneruj hasło aplikacji:

1. Przejdź do: Settings → API / Web Interface
2. Kliknij „Generate App Password”
3. Skopiuj wygenerowany token (zapisze się w schowku)

2.3. Test API (opcjonalnie z poziomu Linux 192.168.53.110)

# Pobranie tokena (SID) przez uwierzytelnienie
SID=$(curl -s -X POST http://192.168.55.4/api/auth \
  -H "Content-Type: application/json" \
  --data '{"password":"ZAQ!2wsx"}' | jq -r '.session.sid')

# Pobranie statystyk
curl -s -H "X-FTL-SID: ${SID}" \
  http://192.168.55.4/api/stats/summary | jq .

2.4. Alternatywa — brak hasła (tryb nieuwierzytelniony)

Jeśli Pi-hole nie ma ustawionego hasła (lub używasz starszej wersji), możesz pominąć uwierzytelnienie:

curl -s http://192.168.55.4/api/stats/summary | jq .

2.5. Najważniejsze endpointy

Endpoint	Opis
/api/stats/summary	Podsumowanie statystyk (zapytania, blokady, typy DNS)
/api/stats/top_domains	Najczęściej zapytane domeny
/api/stats/top_clients	Najaktywniejsi klienci
/api/dns/blocking	Status blokowania (włączone/wyłączone)

3. Przygotowanie Linux (192.168.53.110)

3.1. Instalacja pakietów

ssh yyy@192.168.53.110
# (hasło: zaq12wsx)

sudo apt update
sudo apt install -y snmpd snmp libsnmp-dev curl jq
sudo systemctl enable snmpd
sudo systemctl start snmpd

3.2. Pobranie skryptu distro (wymagane)

Skrypt distro pozwala Observium CE i LibreNMS automatycznie rozpoznać system operacyjny (dystrybucję, jądro, architekturę) zamiast wyświetlać „generic device”.

Dla LibreNMS:

sudo curl -o /usr/local/bin/distro \
  https://raw.githubusercontent.com/librenms/librenms-agent/master/snmp/distro
sudo chmod +x /usr/local/bin/distro

Dla Observium CE:

sudo curl -o /usr/local/bin/distro https://www.observium.org/files/distro
sudo chmod +x /usr/local/bin/distro

3.3. Konfiguracja SNMP (snmpd.conf)

Edytuj plik /etc/snmp/snmpd.conf:

sudo nano /etc/snmp/snmpd.conf

Zawartość minimalnej konfiguracji dla v2c:

# Nasłuch na wszystkich interfejsach
agentAddress udp:161,udp6:[::1]:161

# Widok pełny
view   all    included   .1

# Dostęp read-only dla całej sieci LAN
rocommunity  public  192.168.0.0/16  -V all

# Lokalizacja i kontakt
syslocation  "Serwer monitoringu, Home Lab"
syscontact   "Admin <admin@example.com>"

# Dystrybucja (dla Observium/LibreNMS)
extend .1.3.6.1.4.1.2021.7890.1 distro /usr/local/bin/distro

4. Agent SNMP dla Pi-hole

4.1. Skrypt pobierający statystyki

Utwórz plik /usr/local/bin/pihole-stats.sh:

sudo nano /usr/local/bin/pihole-stats.sh

Wariant 1 — skrypt z App Password w zewnętrznym pliku configa (zalecane):

sudo nano /etc/snmp/pi-hole.conf

PIHOLE_HOST="192.168.55.4"
API_AUTH_KEY="wygenerowany_app_password"
CURL_TIMEOUT=10

sudo chmod 640 /etc/snmp/pi-hole.conf
sudo chown root:Debian-snmp /etc/snmp/pi-hole.conf

Następnie skrypt /usr/local/bin/pihole-stats.sh (wczytuje konfig z /etc/snmp/pi-hole.conf):

#!/usr/bin/env bash
set -euo pipefail

CONFIGFILE="/etc/snmp/pi-hole.conf"
[ -f "$CONFIGFILE" ] && source "$CONFIGFILE"

: ${PIHOLE_HOST:="192.168.55.4"}
: ${API_AUTH_KEY:=""}
: ${CURL_TIMEOUT:=10}

# Uwierzytelnienie przez App Password
SESSION_SID=$(curl -s --max-time ${CURL_TIMEOUT} \
  -X POST "http://${PIHOLE_HOST}/api/auth" \
  -H "Content-Type: application/json" \
  --data "{\"password\":\"${API_AUTH_KEY}\"}" \
  | jq -r '.session.sid // empty')

if [ -z "$SESSION_SID" ]; then
  echo "ERROR: auth failed"
  exit 1
fi

STATS=$(curl -s --max-time ${CURL_TIMEOUT} \
  -H "X-FTL-SID: ${SESSION_SID}" \
  "http://${PIHOLE_HOST}/api/stats/summary")

echo "$STATS" | jq -r '
  .gravity.domains_being_blocked,
  .queries.total,
  .queries.blocked,
  .queries.percent_blocked,
  .queries.unique_domains,
  .queries.forwarded,
  .queries.cached,
  .queries.types.A,
  .queries.types.AAAA,
  .queries.types.PTR,
  .queries.types.SRV
'

Wariant 2 — skrypt z hasłem bezpośrednio (prostszy, ale mniej bezpieczny):

#!/usr/bin/env bash
set -euo pipefail

PIHOLE_HOST="192.168.55.4"
PIHOLE_PASS="ZAQ!2wsx"
CURL_TIMEOUT=10

# Uwierzytelnienie i pobranie SID
SESSION_SID=$(curl -s --max-time ${CURL_TIMEOUT} \
  -X POST "http://${PIHOLE_HOST}/api/auth" \
  -H "Content-Type: application/json" \
  --data "{\"password\":\"${PIHOLE_PASS}\"}" \
  | jq -r '.session.sid // empty')

if [ -z "$SESSION_SID" ]; then
  echo "ERROR: auth failed"
  exit 1
fi

# Pobranie statystyk
STATS=$(curl -s --max-time ${CURL_TIMEOUT} \
  -H "X-FTL-SID: ${SESSION_SID}" \
  "http://${PIHOLE_HOST}/api/stats/summary")

# Wyodrębnienie wartości
echo "$STATS" | jq -r '
  .gravity.domains_being_blocked,
  .queries.total,
  .queries.blocked,
  .queries.percent_blocked,
  .queries.unique_domains,
  .queries.forwarded,
  .queries.cached,
  .queries.types.A,
  .queries.types.AAAA,
  .queries.types.PTR,
  .queries.types.SRV
'

Nadaj uprawnienia wykonania:

sudo chmod +x /usr/local/bin/pihole-stats.sh

4.2. Test skryptu

/usr/local/bin/pihole-stats.sh

Oczekiwany wynik — 11 liczb (po jednej w wierszu):

217894
184933
21358
11.55
53183
74257
71865
98765
35421
12345
6789

4.3. Rejestracja w SNMP (extend)

Dodaj do /etc/snmp/snmpd.conf:

extend .1.3.6.1.4.1.2021.7890.5 pihole /usr/local/bin/pihole-stats.sh

Uruchom ponownie snmpd:

sudo systemctl restart snmpd

4.4. Weryfikacja extensu

# Sprawdź całe drzewo nsExtendMIB
snmpwalk -v2c -c public 127.0.0.1 .1.3.6.1.4.1.2021.7890

# Sprawdź tylko dane per-line (Output2Table)
snmpwalk -v2c -c public 127.0.0.1 .1.3.6.1.4.1.2021.7890.5.4

W Output2Table zobaczysz 11 linii z wartościami liczbowymi (to są dane dla sensorów Observium).

5. Testowanie poprawnej konfiguracji SNMP

5.1. Podstawowe zapytanie

snmpwalk -v2c -c public 192.168.53.110 .1.3.6.1.2.1.1

5.2. Odczyt danych Pi-hole przez SNMP

snmpwalk -v2c -c public 192.168.53.110 .1.3.6.1.4.1.2021.7890.5

5.3. Zdalnie z innej maszyny

Z poziomu serwera Observium/LibreNMS (bez Dockera):

snmpwalk -v2c -c public 192.168.53.110 .1.3.6.1.4.1.2021.7890.5

Z poziomu kontenera Docker (Observium/LibreNMS w Dockerze):

# Przez docker exec — snmpwalk musi być zainstalowany w kontenerze
docker exec observium snmpwalk -v2c -c public 192.168.53.110 .1.3.6.1.4.1.2021.7890.5

# Jeśli kontener nie ma snmpwalk — użyj innego kontenera z narzędziami sieciowymi
docker run --rm alpine/snmp snmpwalk -v2c -c public 192.168.53.110 .1.3.6.1.4.1.2021.7890.5

# Lub bezpośrednio na hoście Docker (jeśli masz zainstalowane snmp)
snmpwalk -v2c -c public 192.168.53.110 .1.3.6.1.4.1.2021.7890.5

6. Dodawanie do Observium CE

6.1. Dodanie urządzenia Linux

1. Zaloguj się do panelu Observium CE
2. Przejdź do: Devices → Add Device
3. Wypełnij:
   • Hostname: 192.168.53.110
   • Community: public
   • SNMP Version: 2c
   • Port: 161
4. Kliknij „Add Device”

Observium automatycznie wykryje system operacyjny i rozpocznie zbieranie danych.

6.2. Statyczne sensory w config.php (jedyna metoda w CE)

Observium CE pozwala definiować statyczne sensory i liczniki w pliku config.php po stronie serwera Observium. Są one pollowane przez standardowy mechanizm SNMP.

Opcja 1 — edytuj przez docker exec (najszybsza):

# Wejdź do kontenera i edytuj config.php
docker exec -it observium nano /opt/observium/config.php
# Jeśli nie ma nano, użyj vi lub sed

Opcja 2 — skopiuj na zewnątrz, edytuj, wgraj z powrotem:

# Wyciągnij plik z kontenera
docker cp observium:/opt/observium/config.php ./config.php

# Edytuj lokalnie
nano ./config.php

# Wgraj z powrotem do kontenera
docker cp ./config.php observium:/opt/observium/config.php

Opcja 3 — zamontuj config jako wolumen (trwała, przy docker-compose):

# w docker-compose.yml observium dodaj:
services:
  observium:
    ...
    volumes:
      - ./observium-config.php:/opt/observium/config.php

# Potem edytuj observium-config.php na hoście i restartuj:
docker-compose restart

Niezależnie od opcji — dodaj poniższy kod na końcu pliku config.php:

// === Pi-hole statyczne sensory (CE) ===
// OID pobrane z rzeczywistego snmpwalk dla extend "pihole".
// Format: .5.4.1.2.6.112.105.104.111.108.101.Y
// gdzie 6.112.105.104.111.108.101 = "pihole" zakodowane w OID, Y = nr linii.
//   Y=1: domains_being_blocked
//   Y=2: queries.total
//   Y=3: queries.blocked
//   Y=4: queries.percent_blocked
//   Y=5: queries.unique_domains
//   Y=6: queries.forwarded
//   Y=7: queries.cached

$config['sensors']['static'][] = [
  'device_id' => 6,
  'class'     => 'load',
  'oid'       => '.1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.1',
  'descr'     => 'Pi-hole Domains Blocked',
  'multiplier' => 1,
];
$config['counters']['static'][] = [
  'device_id' => 6,
  'class'     => 'counter',
  'oid'       => '.1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.2',
  'descr'     => 'Pi-hole Total Queries',
  'multiplier' => 1,
];
$config['counters']['static'][] = [
  'device_id' => 6,
  'class'     => 'counter',
  'oid'       => '.1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.3',
  'descr'     => 'Pi-hole Blocked Today',
  'multiplier' => 1,
];
$config['sensors']['static'][] = [
  'device_id' => 6,
  'class'     => 'load',
  'oid'       => '.1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.4',
  'descr'     => 'Pi-hole Block Percent',
  'multiplier' => 1,
];
$config['sensors']['static'][] = [
  'device_id' => 6,
  'class'     => 'load',
  'oid'       => '.1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.5',
  'descr'     => 'Pi-hole Unique Domains',
  'multiplier' => 1,
];
$config['counters']['static'][] = [
  'device_id' => 6,
  'class'     => 'counter',
  'oid'       => '.1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.6',
  'descr'     => 'Pi-hole Forwarded Queries',
  'multiplier' => 1,
];
$config['counters']['static'][] = [
  'device_id' => 6,
  'class'     => 'counter',
  'oid'       => '.1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.7',
  'descr'     => 'Pi-hole Cached Queries',
  'multiplier' => 1,
];

Po zapisaniu wymuś odkrycie sensorów (użyj swojego ID urządzenia, np. 6):

Bezpośrednio na systemie:

cd /opt/observium
php discovery.php -h 6 -m sensors
php poller.php -h 6 -m sensors

W Dockerze:

docker exec -it observium php /opt/observium/discovery.php -h 6 -m sensors
docker exec -it observium php /opt/observium/poller.php -h 6 -m sensors

Sensory pojawią się w zakładce Health urządzenia. Jeśli nie widzisz żadnych — uruchom z flagą -d (debug):

# Użyj -i (bez -t) gdy pipe'ujesz output
docker exec -i observium php /opt/observium/poller.php -h 6 -m sensors -d 2>&1 | grep -i pihole

6.3. UNIX Agent (tylko dla Observium Subscription — płatna wersja)

Observium Subscription wspiera UNIX Agent — skrypt na Linux (192.168.53.110) wysyła dane przez TCP (port 655) do serwera Observium.

Część wspólna — konfiguracja na Linux 192.168.53.110:

sudo mkdir -p /usr/lib/observium_agent/scripts
sudo curl -o /usr/lib/observium_agent/scripts/pihole \
  https://raw.githubusercontent.com/librenms/librenms-agent/master/snmp/pi-hole
sudo chmod +x /usr/lib/observium_agent/scripts/pihole

# Konfiguracja API Pi-hole
echo 'API_URL="http://192.168.55.4"' | sudo tee /etc/snmp/pi-hole.conf
echo 'API_AUTH_KEY="wygenerowany_app_password"' | sudo tee -a /etc/snmp/pi-hole.conf

# Skrypt agent-local.sh
sudo mkdir -p /opt/observium/scripts
sudo tee /opt/observium/scripts/agent-local.sh << 'EOF'
#!/usr/bin/env bash
for script in /usr/lib/observium_agent/scripts/*; do
  [ -x "$script" ] || continue
  echo "<<<$(basename "$script")>>>"
  "$script" 2>/dev/null || true
done
EOF
sudo chmod +x /opt/observium/scripts/agent-local.sh

# Uruchom nasłuch na porcie 655
sudo apt install -y socat
sudo socat TCP-LISTEN:655,reuseaddr,fork EXEC:/opt/observium/scripts/agent-local.sh &

Konfiguracja w Observium:
Po włączeniu UNIX Agenta w config.php poller automatycznie łączy się na port 655 do urządzenia.

Wariant A — Observium na Linux (bez Dockera):

echo "\$config['poller_modules']['unix-agent'] = true;" >> /opt/observium/config.php
cd /opt/observium
php poller.php -h 6

Wariant B — Observium w Dockerze:

B1. Docker na tym samym hoście co agent:

docker exec -it observium bash -c 'echo "\$config['"'"'poller_modules'"'"']['"'"'unix-agent'"'"'] = true;" >> /opt/observium/config.php'
docker exec -it observium php /opt/observium/poller.php -h 6

B2. Docker na innym hoście niż agent:
Dodaj w docker-compose.yml: ports: - "655:655", następnie:

docker exec -it observium bash -c 'echo "\$config['"'"'poller_modules'"'"']['"'"'unix-agent'"'"'] = true;" >> /opt/observium/config.php'
docker exec -it observium php /opt/observium/poller.php -h 6

7. Dodawanie do LibreNMS

7.1. Oficjalny agent LibreNMS dla Pi-hole

LibreNMS posiada dedykowaną aplikację Pi-hole.

Krok 1: Pobranie agenta LibreNMS na Linux (192.168.53.110)

sudo mkdir -p /usr/lib/librenms_agent
sudo curl -o /usr/lib/librenms_agent/pihole \
  https://raw.githubusercontent.com/librenms/librenms-agent/master/snmp/pi-hole
sudo chmod +x /usr/lib/librenms_agent/pihole

Krok 2: Konfiguracja agenta

sudo nano /etc/snmp/pi-hole.conf

API_URL="http://192.168.55.4"
API_AUTH_KEY="ZAQ!2wsx"

Krok 3: Rejestracja w snmpd.conf

sudo nano /etc/snmp/snmpd.conf

extend pihole /usr/lib/librenms_agent/pihole

sudo systemctl restart snmpd

Krok 4: Test na serwerze LibreNMS

snmpwalk -v2c -c public 192.168.53.110 NET-SNMP-EXTEND-MIB::nsExtendOutput2Line

7.2. Dodanie urządzenia w LibreNMS

1. Zaloguj się do panelu LibreNMS
2. Przejdź: Devices → Add Device
3. Wypełnij:
   • Hostname: 192.168.53.110
   • SNMP Version: v2c
   • Community: public
   • Port: 161
4. Kliknij „Add Device”

7.3. Ręczne włączenie aplikacji Pi-hole

1. Wejdź w szczegóły urządzenia (192.168.53.110)
2. Device → Edit → Applications
3. Z listy wybierz „Pi-hole” i zapisz

Wymuś ponowne odkrycie:

./discovery.php -h 192.168.53.110

7.4. Weryfikacja w LibreNMS

• Przejdź do urządzenia → zakładka „Apps”
• Powinieneś zobaczyć „Pi-hole” z wykresami:
  • Domains being blocked
  • DNS Queries Total
  • DNS Queries Blocked
  • DNS Queries Percent Blocked
  • Unique Domains
  • Queries Forwarded / Cached
  • Query Types (A, AAAA, PTR, SRV)

8. Troubleshooting

SNMP: Connection refused

sudo ss -tlnp | grep 161
sudo systemctl status snmpd
# Sprawdź czy agentAddress w snmpd.conf jest poprawny

SNMP: No response

# Sprawdź firewall na Linux
sudo ufw status
sudo iptables -L -n | grep 161

# Sprawdź czy community string jest poprawny
snmpwalk -v2c -c public 127.0.0.1 .1.3.6.1.2.1.1

Pi-hole API: Unauthorized

# Hasło Pi-hole może być zmienione
# Wygeneruj nowy App Password w panelu Pi-hole
# Settings > API/Web Interface > Generate App Password

Skrypt pihole-stats.sh: puste wyniki

# Debug skryptu — uruchom ręcznie
bash -x /usr/local/bin/pihole-stats.sh

# Sprawdź czy curl i jq są zainstalowane
which curl
which jq

# Sprawdź czy Pi-hole jest dostępny
curl -s -o /dev/null -w "%{http_code}" http://192.168.55.4/api/stats/summary

LibreNMS: nie widzi aplikacji Pi-hole

# Wymuś ponowne odkrycie
cd /opt/librenms
php discovery.php -h 192.168.53.110

# Debug pollingu
snmpbulkwalk -v2c -c public 192.168.53.110 .1.3.6.1.4.1.2021.7890.5

Observium: brak wykresów

# Sprawdź logi pollingu (bezpośrednio na systemie)
tail -f /opt/observium/logs/poller.log

# Wymuś poll (bezpośrednio na systemie)
./poller.php -h 192.168.53.110 -d

Observium w Dockerze: SNMP connection refused

# Sprawdź czy kontener widzi Linux (192.168.53.110)
docker exec observium ping 192.168.53.110

# Sprawdź SNMP z wnętrza kontenera
docker exec observium snmpwalk -v2c -c public 192.168.53.110 .1.3.6.1.2.1.1

# Jeśli nie działa — kontener może być w innej sieci Docker.
# Użyj adresu IP bramy Docker (zwykle 172.17.0.1):
docker exec observium snmpwalk -v2c -c public 172.17.0.1 .1.3.6.1.2.1.1

Observium w Dockerze: config.php zmiany nie są widoczne

# Po edycji config.php przez docker exec ZAWSZE uruchom:
docker exec -it observium php /opt/observium/discovery.php -h 6 -m sensors
docker exec -it observium php /opt/observium/poller.php -h 6 -m sensors

# Sprawdź czy zmiany w config.php są widoczne wewnątrz kontenera:
docker exec observium grep -c pihole /opt/observium/config.php

# Debug pollera dla Pi-hole (użyj -i, nie -it, gdy pipe'ujesz):
docker exec -i observium php /opt/observium/poller.php -h 6 -m sensors -d 2>&1 | grep -i -E "(pihole|static|error|warning)"

Observium w Dockerze: sensory static nie pojawiają się

# Sprawdź rzeczywiste OID z wnętrza kontenera:
docker exec observium snmpwalk -v2c -c public 192.168.53.110 .1.3.6.1.4.1.2021.7890

# OID w nsExtendOutput2Table mają format:
# .1.3.6.1.4.1.2021.7890.5.4.1.2.{długość_nazwy}.{znaki_nazwy_ASCII}.{numer_linii}

# Przykład (dla extend "pihole"):
# .1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.1 = "2012986"  ← linia 1
# .1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.2 = "22842"    ← linia 2

# Wymuś pełne odkrycie dla urządzenia:
docker exec -it observium php /opt/observium/discovery.php -h 6

Podsumowanie OID

OID	Opis
.1.3.6.1.4.1.2021.7890.1	Distro (wykrywanie OS)
.1.3.6.1.4.1.2021.7890.5	Pi-hole extend (rejestracja)
.1.3.6.1.4.1.2021.7890.5.4.1.2.6.112.105.104.111.108.101.Y	Pi-hole stats per-line (Y=1..11)