Monitoring metryk w kontenerach

Moduł opisuje kompletny, kontenerowy stos do zbierania i wizualizacji metryk: Prometheus gromadzi szeregi czasowe, eksportery udostępniają dane, a Grafana prezentuje je w postaci paneli. Całość uruchamia się jednym plikiem Compose na dowolnym hoście z Dockerem.

• Skład stosu: Prometheus, Grafana, node-exporter oraz snmp-exporter w jednej sieci Docker; każdy kontener pełni jedną rolę
• Wymagania: 64-bitowy Linux z Docker Engine i wtyczką Compose, około 2 GB wolnego miejsca na obrazy oraz dostęp do monitorowanych urządzeń przez SNMP
• Obiekty nadzoru: Sam host z Dockerem przez node-exporter oraz dowolny router lub przełącznik przez SNMP w wersji v2c
• Efekt końcowy: Panele Grafana z obciążeniem procesora, pamięcią hosta i ruchem na interfejsach sieciowych, odpytywane na żywo z Prometheusa

Zrzut: cztery kontenery w docker ps albo schemat stosu.

Układ materiału i plan zajęć

Materiał podzielono na pięć bloków: instalacja Dockera, gotowe pliki stosu, uruchomienie i organizacja danych, działanie każdego elementu oraz budowa paneli z diagnostyką. Bloki przerabiasz po kolei od góry, bo każdy następny korzysta z plików i pojęć poprzedniego.

• Blok 1: Instalacja Dockera: Oficjalna procedura dla Ubuntu, repozytorium producenta i weryfikacja (slajdy 7-8)
• Blok 2: Pliki stosu: Skąd wziąć pliki, pełny docker-compose.yml oraz prometheus.yml do skopiowania (slajdy 9-11)
• Blok 3: Start i rozbudowa: Uruchomienie, anatomia konfiguracji, dopisywanie hostów, routerów i portów (slajdy 12-16)
• Blok 4 i 5: Dane i panele: Wolumeny, model pobierania, eksportery, SNMP, RouterOS, Grafana, PromQL i diagnostyka (slajdy 17-45)

Zrzut: spis treści lub strona startowa kursu.

Logi mówią co się stało, metryki pokazują jak system pracuje

Log systemowy opisuje pojedyncze zdarzenie, natomiast metryka to wartość liczbowa próbkowana w czasie, na przykład obciążenie procesora co 15 sekund. Dopiero wykres takiej serii ujawnia trendy i anomalie. W praktyce oba źródła łączą się w jedno okno diagnostyki: metryka pokazuje kiedy coś się działo, a log mówi co dokładnie.

• Trzy filary obserwowalności: Metryki (liczby w czasie), logi (zdarzenia tekstowe) oraz ślady rozproszone; moduł dotyczy pierwszego filaru
• Przykład praktyczny: Log powie, że interfejs zmienił stan, a metryka ifInOctets pokaże, że ruch narastał przez godzinę przed awarią
• Zaleta Prometheusa: Wielowymiarowe etykiety, na przykład ifDescr z nazwą interfejsu, pozwalają jednym zapytaniem objąć wszystkie porty routera
• Rola Grafany: Panel łączy wiele zapytań w jeden czytelny obraz: wykres, miernik i tabelę

Zrzut: wykres metryki obok pliku logu.

Cztery kontenery i jeden kierunek inicjacji

Wszystkie połączenia inicjuje Prometheus wewnątrz sieci Docker. Grafana pyta Prometheusa, Prometheus odpytuje eksportery, a snmp-exporter tłumaczy odpowiedzi SNMP z routera na format tekstowy. Dzięki temu zapora na monitorowanych hostach przepuszcza tylko ruch do eksporterów, a hasła nie opuszczają centrali.

• Kontener prometheus: Port 9090, baza w wolumenie prometheus_data oraz konfiguracja z pliku prometheus.yml
• Kontener grafana: Port 3000, dane w wolumenie grafana_data, źródło Prometheus dodane automatycznie
• Eksportery: node-exporter na porcie 9100 czyta jądro Linuksa, snmp-exporter na porcie 9116 tłumaczy SNMP na HTTP
• Obiekty zewnętrzne: Host z Dockerem przez interfejs proc oraz router przez UDP 161 o wspólnocie SNMP v2c

Zrzut: strzałki przepływu danych między usługami.

Kolejność startu ma znaczenie tylko przy starcie

Kontener Grafana zależy od Prometheusa, więc Compose uruchamia go później. Po starcie usługi działają niezależnie i odtwarzają połączenie po każdej przerwie, dlatego chwilowy brak Prometheusa nie wymaga restartu Grafany. W praktyce oznacza to odporność na restart pojedynczej usługi bez odtwarzania całego stosu.

• depends_on w Compose: Wpis przy usłudze grafana wymusza start kontenera prometheus jako pierwszego przy poleceniu up -d
• Brak twardego oczekiwania: Grafana ponawia próby połączenia ze źródłem, a Prometheus ponawia pobieranie celów oznaczonych jako down
• restart: unless-stopped: Każdy kontener wraca po restarcie hosta; stan sprawdza się poleceniem docker ps
• Sieć monitorująca: Wewnętrzne nazwy prometheus, grafana i snmp-exporter działają dzięki wbudowanemu DNS Dockera

Zrzut: depends_on w pliku Compose i kolejność startu.

Sześć kroków jednego cyklu pobrania

Cykl zaczyna się od zapytania HTTP GET do punktu metrics. Eksporter odpowiada tekstem, Prometheus parsuje go, dopisuje etykiety i zapisuje próbki w bazie. Grafana później czyta te próbki zapytaniami PromQL.

• Krok 1-2: Prometheus co 15 sekund wykonuje GET http://node-exporter:9100/metrics i otrzymuje tekst z setkami linii
• Krok 3-4: W zadaniu snmp Prometheus pyta snmp-exporter z parametrami module, auth i target, a eksporter wykonuje spacer SNMP po routerze
• Krok 5: Parser dopisuje etykiety job, instance oraz własne, na przykład nazwę urządzenia
• Krok 6: Próbki trafiają do bloków TSDB w wolumenie danych z wybraną retencją, na przykład 30 dni

Zrzut: zapytanie HTTP do punktu metrics w przeglądarce.

Silnik kontenerów jako fundament stosu

Zalecana metoda to instalacja z oficjalnego repozytorium APT producenta. Procedura polega na dodaniu klucza GPG i repozytorium, instalacji pakietów oraz weryfikacji testem hello-world. Producent wspiera 64-bitowe wydania Ubuntu LTS, w tym 22.04, 24.04 i 26.04.

• Krok 1: Pakiety ca-certificates curl, katalog /etc/apt/keyrings oraz klucz z adresu download.docker.com
• Krok 2: Dodanie repozytorium APT z kryptonimem wydania i instalacja docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
• Krok 3: Weryfikacja poleceniami docker --version, docker compose version oraz sudo docker run hello-world
• Praca bez sudo: Dodanie użytkownika do grupy docker i ponowne logowanie (pełny listing na następnym slajdzie)

Zrzut: wynik docker --version i hello-world.

Wklej linijka po linijce

Poniższe polecenia wykonuje się w terminalu Ubuntu z uprawnieniami sudo. Pierwszy blok dodaje repozytorium producenta, drugi instaluje pakiety, trzeci weryfikuje działanie, a czwarty nadaje pracę bez sudo. Każdą komendę wklejasz osobno i czekasz na jej koniec; całość trwa kilka minut na zwykłym łączu.

• Blok repozytorium: Aktualizacja APT, pakiety pomocnicze, klucz GPG oraz plik docker.sources z kryptonimem wydania
• Blok instalacji: Pięć pakietów jednym poleceniem apt install, potem odświeżenie listy pakietów przed instalacją
• Weryfikacja: Kontener hello-world pobiera się i wypisuje potwierdzenie, a polecenia version pokazują silnik i wtyczkę Compose
• Grupa docker: Polecenie usermod działa dopiero po ponownym zalogowaniu; do tego czasu używa się sudo

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world
docker --version
docker compose version

Zrzut: terminal z wykonywaniem komend instalacji.

Trzy pliki wystarczą do startu

Do uruchomienia stosu potrzebne są trzy pliki: docker-compose.yml, prometheus.yml oraz provisioning źródła danych. Czwarty, snmp.yml, dostarcza sam obraz snmp-exporter, więc nie trzeba go pisać. Pliki znajdują się w katalogu _grafana_stack dołączonym do materiałów.

Przykładowy zestaw stosu kontenerów możesz pobrać z github za pomocą polecenia git clone https://github.com/IgorBrzezek/simpleGRAFANA.

• Katalog _grafana_stack/: Gotowy zestaw: docker-compose.yml, prometheus/prometheus.yml oraz grafana/provisioning/datasources/prometheus.yml
• Wariant ręczny: Utworzenie tej samej struktury trzema poleceniami mkdir i skopiowanie listingów z dwóch następnych slajdów
• Jedyna zmiana: Adres routera w prometheus.yml (przykładowy 192.168.1.1) podmienia się na własny przed startem
• Hasło Grafany: Wartość zmien-mnie w sekcji environment podmienia się na własne przed pierwszym startem

Zrzut: drzewo katalogu monitoring w menedżerze plików.

Cały stos w jednym pliku

Poniższy listing to kompletna zawartość pliku docker-compose.yml. Jawne wersje obrazów gwarantują powtarzalność, a montowania ro dostarczają konfigurację bez wbudowywania jej w obrazy. Plik przechodzi sprawdzenie składni poleceniem docker compose config.

• Cztery usługi: prometheus, node-exporter, snmp-exporter i grafana, każda z publikacją jednego portu
• Dwa wolumeny: prometheus_data na bazę TSDB oraz grafana_data na panele i użytkowników
• Dwa dowiązania ro: Pliki prometheus.yml i provisioning, tylko do odczytu dla kontenerów
• snmp.yml z obrazu: Brak montowania oznacza użycie pełnego pliku wbudowanego w obraz snmp-exporter

name: grafana-stack
networks:
  monitoring: {}
volumes:
  prometheus_data: {}
  grafana_data: {}
services:
  prometheus:
    image: prom/prometheus:v3.5.0
    container_name: prometheus
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.path=/prometheus
      - --storage.tsdb.retention.time=30d
      - --web.enable-lifecycle
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"
    networks:
      - monitoring
    restart: unless-stopped
  node-exporter:
    image: prom/node-exporter:v1.9.1
    container_name: node-exporter
    command:
      - --path.rootfs=/host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/host:ro,rslave
    ports:
      - "9100:9100"
    networks:
      - monitoring
    restart: unless-stopped
  snmp-exporter:
    image: prom/snmp-exporter:v0.28.0
    container_name: snmp-exporter
    ports:
      - "9116:9116"
    networks:
      - monitoring
    restart: unless-stopped
  grafana:
    image: grafana/grafana:11.6.5
    container_name: grafana
    environment:
      GF_SECURITY_ADMIN_USER: admin
      GF_SECURITY_ADMIN_PASSWORD: "zmien-mnie"
      GF_USERS_ALLOW_SIGN_UP: "false"
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning:ro
    ports:
      - "3000:3000"
    networks:
      - monitoring
    restart: unless-stopped
    depends_on:
      - prometheus

Zrzut: otwarty plik docker-compose.yml w edytorze.

Pięć zadań i jedno źródło danych

Poniżej pełna treść pliku prometheus.yml: dwa wpisy node-exporter, dwa wpisy snmp dla interfejsów oraz po jednym wpisie na moduły mikrotik i UCD Linuksa. Każdy wpis to osobny cel na stronie Targets; przykładowe adresy podmieniasz na własne.

• Wpis 1-2, node-exporter: Kontener node-exporter:9100 (host: docker-host) oraz drugi host 192.168.1.10:9100 (host: serwer-2)
• Wpis 1-2, snmp if_mib: Routery 192.168.1.1 i 192.168.1.2; ten sam moduł obsłuży też Cisco i switche
• snmp-mikrotik: Moduł mikrotik dla MikroTika: kondycja, wireless i DHCP (metryki mtxr)
• snmp-linux: Moduły ucd_la_table, ucd_memory, ucd_system_stats dla Linuksa z demonem snmpd; CPU Cisco wymaga modułu z generatora
• Provisioning: Adres http://prometheus:9090 jako domyślne źródło; flaga isDefault eliminuje klikanie

Plik 1 z 2: _grafana_stack/prometheus/prometheus.yml (konfiguracja Prometheusa)

# Konfiguracja Prometheusa dla stosu NMS.
# Adresy 192.168.1.x sa przykladowe: podmien je na wlasne hosty i routery.
# SNMP: w urzadzeniach wlacz usluge SNMP v2c (np. MikroTik: /snmp set enabled=yes,
# Cisco: snmp-server community <wspolnota> RO, Linux: pakiet snmpd + rocommunity).
global:
  scrape_interval: 15s
  scrape_timeout: 10s
  evaluation_interval: 15s

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

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]
        labels:
          host: "docker-host"
      # Drugi host z node-exporterem na porcie 9100:
      - targets: ["192.168.1.10:9100"] # PODMIEN na adres drugiego hosta
        labels:
          host: "serwer-2"

  # Interfejsy dowolnych urzadzen SNMP (MikroTik, Cisco, switche): modul if_mib.
  - job_name: "snmp"
    metrics_path: /snmp
    params:
      module: [if_mib]
      auth: [public_v2]
    static_configs:
      - targets: ["192.168.1.1"] # PODMIEN na adres pierwszego routera
        labels:
          urzadzenie: "router-glowny"
      - targets: ["192.168.1.2"] # PODMIEN na adres drugiego routera
        labels:
          urzadzenie: "router-oddzial"
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp-exporter:9116
    scrape_interval: 60s
    scrape_timeout: 55s

  # Dane specyficzne MikroTika (kondycja, wireless, DHCP): modul mikrotik.
  - job_name: "snmp-mikrotik"
    metrics_path: /snmp
    params:
      module: [mikrotik]
      auth: [public_v2]
    static_configs:
      - targets: ["192.168.1.1"] # PODMIEN na adres urzadzenia MikroTik
        labels:
          urzadzenie: "router-glowny"
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp-exporter:9116
    scrape_interval: 60s
    scrape_timeout: 55s

  # Linux z demonem snmpd: obciazenie, pamiec i CPU z MIB UCD-SNMP.
  - job_name: "snmp-linux"
    metrics_path: /snmp
    params:
      module: [ucd_la_table, ucd_memory, ucd_system_stats]
      auth: [public_v2]
    static_configs:
      - targets: ["192.168.1.20"] # PODMIEN na adres Linuksa z snmpd
        labels:
          host: "serwer-linux-snmp"
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp-exporter:9116
    scrape_interval: 60s
    scrape_timeout: 55s

Plik 2 z 2: _grafana_stack/grafana/provisioning/datasources/prometheus.yml (źródło danych Grafany)

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    isDefault: true
    url: http://prometheus:9090
    access: proxy
    editable: true

Zrzut: otwarty plik prometheus.yml w edytorze.

Od plików do działających kontenerów

Po sprawdzeniu składni poleceniem config stos startuje jednym poleceniem up -d. Kontenery pobierają się z rejestru, a po kilkunastu sekundach wszystkie cztery mają status Up. Układ katalogu pokazano poniżej.

• Krok 1: docker compose config renderuje i sprawdza składnię pliku bez tworzenia czegokolwiek
• Krok 2: docker compose up -d tworzy sieć, wolumeny i kontenery: prometheus, node-exporter, snmp-exporter oraz grafana
• Oczekiwany wynik: Wszystkie kontenery w stanie Up, porty 3000, 9090, 9100 i 9116 wystawione na hoście
• Krok 3: docker ps potwierdza stan, a curl localhost:9090/-/healthy odpowiada Prometheus Server is Healthy

Zrzut: wynik docker compose up -d i docker ps.

Pięć klocków, z których Prometheus korzysta

Prometheus czyta tylko wybrane pola. Globalne interwały decydują o rytmie, zadanie grupuje cele, static_configs wskazuje adresy, params dokleja parametry zapytania, a relabeling przepisuje adresy przed pobraniem. Pól nieopisanych w dokumentacji Prometheus nie czyta, więc literówka w nazwie pola kasuje zadanie po cichu.

• global: scrape_interval 15 sekund, scrape_timeout 10 sekund i evaluation_interval 15 sekund dla całego serwera
• job_name: Nazwa zadania widoczna na Targets i w etykiecie job każdej próbki; zadania node, snmp i pochodne
• static_configs: Jawna lista celów z opcjonalnymi etykietami host i urzadzenie do filtrowania w panelach
• params i relabel_configs: Tylko w zadaniu snmp: doklejają module i auth oraz kierują pobranie na bramkę snmp-exporter:9116

Zrzut: global, zadanie, cele i relabeling w pliku.

Trzy kroki do nowego celu

Na drugim hoście uruchamia się kontener eksportera, w prometheus.yml dopisuje się jeden wpis z etykietą, a Prometheus przeładowuje konfigurację bez restartu. Po minucie cel ma stan up.

• Krok 1, drugi host: Jedno polecenie docker run z montowaniami ro i flagą path.rootfs; port 9100 musi być osiągalny z hosta monitorującego
• Krok 2, wpis: Nowy blok targets z etykietą host w zadaniu node-exporter; nazwa etykiety posłuży do filtrowania paneli
• Krok 3, reload: Żądanie POST do /-/reload przeładowuje konfigurację; restart kontenera nie jest potrzebny
• Kontrola: Strona Targets pokazuje nowy wiersz, a zapytanie node_load1{host="serwer-2"} zwraca pierwsze próbki

Zrzut: uruchomienie eksportera na drugim hoście.

Najpierw snmpwalk, potem wpis

Zanim router trafi do konfiguracji, sprawdza się go ręcznie poleceniem snmpwalk. Dopiero poprawna odpowiedź oznacza, że bramka też sobie poradzi. Wpis w zadaniu snmp to adres plus etykieta urządzenia.

• Krok 1, test: snmpwalk -v2c -c public ADRES 1.3.6.1.2.1.1.5.0; odpowiedź z nazwą urządzenia potwierdza usługę i wspólnotę
• Włączanie usługi: MikroTik /snmp set enabled=yes, Cisco snmp-server community public RO, Linux pakiet snmpd z linią rocommunity
• Krok 2, wpis: Nowy blok targets z etykietą urzadzenie w zadaniu snmp; relabeling sam dopisze instance i skieruje na bramkę
• Kontrola: Zapytanie ifInOctets{instance="ADRES"} zwraca liczniki interfejsów nowego routera

Zrzut: wynik snmpwalk z nazwą urządzenia.

Lewa liczba dla ludzi, prawa dla kontenera

Zapis ports ma postać HOST:KONTENER. Prawa liczba musi zgadzać się z usługą w środku, lewą zmieniasz dowolnie, na przykład gdy port jest zajęty. Wewnątrz sieci Docker usługi widzą się po nazwach i publikacja nie jest im potrzebna.

• Składnia: "3001:3000" wystawia Grafanę na porcie 3001 hosta; kontener nadal słucha na 3000
• Kiedy zmieniać: Konflikt z inną usługą na hoście albo ukrywanie standardowych portów przed skanowaniem
• Zapora na urządzeniach: Drugi host otwiera TCP 9100 dla monitoringu, routery odpowiadają na UDP 161
• Diagnostyka: Porty eksporterów publikuje się do ręcznych testów poleceniem curl; na produkcji zwykle się je chowa, a pobieranie działa wewnątrz sieci

Zrzut: mapowanie portów w pliku Compose.

Dane przeżywają wymianę kontenera

Bez wolumenu usunięcie kontenera kasowałoby historię metryk. Wolumen nazwany trzyma bazę TSDB, a dowiązanie pliku dostarcza konfigurację, dzięki czemu obraz pozostaje niezmienny. W efekcie wymiana obrazu na nowszy nie rusza ani historii pomiarów, ani twojej konfiguracji.

• Wolumen prometheus_data: Katalog /prometheus w kontenerze, fizycznie pod /var/lib/docker/volumes na hoście z prefiksem nazwy projektu
• Wolumen grafana_data: Katalog /var/lib/grafana z panelami, użytkownikami i historią alarmów między restartami
• Dowiązanie konfiguracji: Plik prometheus.yml montowany z flagą ro, więc kontener nie może go nadpisać
• Weryfikacja: Inspekcja Mounts kontenera pokazuje typ bind dla pliku oraz typ volume dla bazy

Zrzut: lista wolumenów docker volume ls.

Trzydzieści dni historii to świadomy kompromis

Flaga storage.tsdb.retention.time ogranicza bazę, na przykład do 30 dni. Dłuższa retencja ułatwia analizy sezonowe, lecz zwiększa zajętość dysku i czas odpowiedzi zapytań obejmujących duży zakres.

• Flaga retencji: --storage.tsdb.retention.time=30d w poleceniu startowym kontenera prometheus
• Co kasuje Prometheus: Bloki starsze niż limit usuwane są automatycznie w tle bez zatrzymywania pobierania
• Wpływ interwału: Pobranie co 15 sekund daje 5760 próbek dziennie na serię; interwał 60 sekund dla SNMP zmniejsza ten koszt czterokrotnie
• Kontrola zajętości: Polecenie docker system df oraz wykres wolnego miejsca na hoście ostrzegają przed przepełnieniem

Zrzut: flaga retencji i rozmiar katalogu bazy.

Cztery porty i cztery punkty kontrolne

Każdy kontener publikuje jeden port na hoście: Grafana 3000, Prometheus 9090, node-exporter 9100 oraz snmp-exporter 9116. Znajomość tych adresów wystarcza do ręcznej weryfikacji całego łańcucha z poziomu hosta. Zapisz te cztery liczby, bo wracają przy każdym teście diagnostycznym w dalszej części.

• Port 3000: Interfejs Grafany http://localhost:3000, pierwsze logowanie admin oraz diagnostyka API /api/health
• Port 9090: Interfejs Prometheusa z zakładkami Graph i Status Targets oraz punktem /-/healthy
• Port 9100: Surowy tekst node-exportera pod /metrics, czytelny także poleceniem curl bez przeglądarki
• Port 9116: Bramka SNMP pod /snmp z parametrami module, auth i target

Zrzut: cztery porty w docker ps.

Serwer monitorujący inicjuje każde połączenie

Prometheus nie czeka na dane, lecz zgodnie z interwałem odpytuje listę celów. Strona Status Targets pokazuje stan każdego celu: zielony up oznacza poprawne pobranie, a czerwony down wskazuje dokładny błąd. Zaglądasz tu jako pierwsze przy każdym braku danych na wykresie.

• Cel (Target): Adres HTTP z metrykami; w stosie siedem punktów: prometheus, dwa node-exportery, dwa cele if_mib oraz po jednym celu mikrotik i linux
• Stan docelowy: Po minucie od startu wszystkie siedem celów ma stan up; każdy wpis static_configs to osobny wiersz
• Interwały: 15 sekund dla hostów i samego Prometheusa, 60 sekund dla SNMP z limitem 55 sekund na odpowiedź
• API zapytań: Punkt /api/v1/query przyjmuje wyrażenia PromQL i zwraca JSON z wektorem wyników

Zrzut: strona Status Targets ze stanami up.

Prometheus odpowiada też bez pośredników

Do odczytu metryk nie potrzeba Grafany. Wbudowana przeglądarka zapytań na porcie 9090 oraz endpointy API zwracają te same dane, które później rysują panele. To najszybsza droga sprawdzenia, czy problem leży w danych czy w dashboardzie.

• Przeglądarka Graph: Adres http://localhost:9090, zakładka Graph, wpisanie wyrażenia i Execute; widok Table pokazuje liczby, Graph rysuje wykres
• Zapytanie chwilowe: curl -G http://localhost:9090/api/v1/query --data-urlencode 'query=node_load1' zwraca JSON z wektorem
• Zapytanie zakresowe: Punkt /api/v1/query_range z parametrami query, start, end i step rysuje historię, na przykład do własnego skryptu
• Metadane: Punkty /api/v1/targets i /api/v1/label/NAZWA/values listują cele oraz dostępne wartości etykiet
• Składnia PromQL: Filtr w nawiasach {job="snmp"}, funkcje rate() i agregacje avg() by (ifDescr)

Zrzut: surowe metryki pod adresem /metrics.

Tysiąc metryk z jądra bez agenta w systemie

Kontener montuje katalogi proc i sys hosta w trybie tylko do odczytu i tłumaczy je na tekst. Żadnego oprogramowania nie instaluje się w systemie operacyjnym, cała logika siedzi w kontenerze. Dlatego ten sam kontener mierzy każdy host z osobna bez instalowania czegokolwiek w systemie.

• Montowania: /proc i /sys jako tylko do odczytu oraz korzeń pod /host z flagą rslave dla kolektora plików
• Przykłady metryk: node_cpu_seconds_total z etykietami cpu i mode, node_memory_MemTotal_bytes oraz node_load1
• Drugi host: To samo polecenie docker run na drugiej maszynie, port 9100 otwarty w zaporze oraz wpis z etykietą host w zadaniu
• Flaga rootfs: Parametr path.rootfs równy /host kieruje kolektor systemu plików na dysk hosta, nie kontenera

Zrzut: wynik zapytania do bramki SNMP.

Bramka między światem datagramów a światem HTTP

Prometheus nie mówi protokołem SNMP, więc snmp-exporter wykonuje spacer po routerze i oddaje wynik jako tekst. Parametry module, auth i target w adresie decydują, co i gdzie zostanie odpytane. Bez tej bramki Prometheus nie miałby jak zapytać routera, bo protokołu SNMP po prostu nie zna.

• Zapytanie bramki: /snmp?module=if_mib&auth=public_v2&target=ADRES_ROUTERA zwraca metryki ifInOctets i ifOperStatus
• Najprostsza droga: Obraz snmp-exporter zawiera gotowy, pełny plik snmp.yml z setkami modułów, więc na początek nie montuje się własnego
• Format ma znaczenie: W bieżących wydaniach moduł zawiera wyłącznie listę walk, a poświadczenia mieszkają w sekcji auths; stary format kończy się błędem i restartami
• Zdrowa bramka: Log z wierszem Listening on [::]:9116 oraz odpowiedzią na testowe zapytanie poleceniem curl

Zrzut: sekcje auths i modules w pliku.

Poświadczenia osobno, obiekty osobno

Sekcja auths definiuje wspólnotę w wersji 2, a sekcja modules wskazuje gałęzie MIB do spaceru. Wbudowany plik obrazu zawiera gotowe moduły: if_mib dla każdego sprzętu, mikrotik dla MikroTika oraz ucd_* dla Linuksa z demonem snmpd. Wybór modułu w adresie zapytania decyduje, które gałęzie zostaną odpytywane przy danym pobraniu.

• Auth public_v2: Para community i version 2 używana w adresie jako auth; nazwę i wspólnotę dobiera się do własnej sieci
• if_mib: Gałęzie systemowa i interfejsów; działa na MikroTiku, Cisco i switchach bez żadnej konfiguracji
• mikrotik: Gałąź producenta 1.3.6.1.4.1.14988: kondycja, wireless i DHCP; łączy się go z if_mib w jednym zapytaniu
• ucd_*: Moduły ucd_la_table, ucd_memory i ucd_system_stats czytają obciążenie, pamięć i CPU Linuksa z snmpd
• Cisco CPU: MIB CISCO-PROCESS-MIB nie ma w domyślnym pliku, więc moduł cisco buduje się generatorem z repozytorium projektu
• Brak pliku w paczce: Katalog _grafana_stack nie zawiera snmp.yml, bo kontener używa wbudowanego; własny plik z modułem routeros montuje się dopiero na slajdach 35-36

Zrzut: trzy reguły relabeling w pliku.

Trzy reguły zamieniają cel SNMP w cel HTTP

Prometheus nie łączy się wprost z routerem. Reguły przepisują adres routera do parametru target, kopiują go do etykiety instance, a adresem pobrania czynią snmp-exporter:9116. Dzięki temu jeden wpis z adresem wystarcza, aby router pojawił się w bazie z własną etykietą.

• Reguła 1: Etykieta address trafia do parametru target żądania, czyli wskazuje router docelowy
• Reguła 2: Parametr target kopiowany jest do etykiety instance, więc panele grupują po adresie routera
• Reguła 3: Adres pobrania podmieniany jest na snmp-exporter:9116, czyli na bramkę w sieci Docker
• Skutek: Dopisanie kolejnego routera to jedna linia w targets bez zmiany bramki

Zrzut: strona Targets z pięcioma celami.

Najpierw snmpwalk, potem eksporter

Zanim router trafi do prometheus.yml, warto odpytać go ręcznie narzędziem snmpwalk z pakietu snmp. Dopiero poprawna odpowiedź na wspólnotę oznacza, że bramka też sobie poradzi.

• Test ręczny: snmpwalk -v2c -c public ADRES_ROUTERA 1.3.6.1.2.1.1 pokazuje gałąź systemową: opis, nazwę i czas pracy
• Tablica interfejsów: Gałąź 1.3.6.1.2.1.2.2.1.2 zwraca nazwy portów, na przykład ether1, bridge1 czy lo
• MikroTik RouterOS: Podgląd /snmp print oraz włączenie /snmp set enabled=yes; usługa bywa domyślnie wyłączona
• Wspólnota public: Domyślny wpis zezwalający na odczyt, dobry na laboratorium, niedopuszczalny na produkcji

Zrzut: wynik snmpwalk z routera.

Brak odpowiedzi też jest wynikiem

System Windows nie zawiera domyślnie usługi SNMP, więc zamiast ją doinstalowywać, stosuje się dedykowany windows_exporter na porcie 9182 z własnym zadaniem w Prometheusie. Eksporter czyta te same liczniki wydajności, które pokazuje menedżer zadań Windows.

• Objaw: Ping i SSH do hosta działają, a snmpwalk zwraca przekroczenie czasu oczekiwania
• Wniosek: Usługi SNMP w Windows po prostu nie ma i nie warto jej instalować dla jednego ćwiczenia
• Alternatywa: Eksporter windows_exporter z metrykami windows_cpu_time_total i windows_os_physical_memory_free_bytes
• Zadanie analogiczne: Osobny job w prometheus.yml o ścieżce /metrics wprost do adresu eksportera Windows

Zrzut: brak usługi SNMP na hoście Windows.

Zero klikania przy dodawaniu Prometheusa

Plik provisioning montowany do Grafany rejestruje Prometheusa jako domyślne źródło. Po starcie wystarczy zalogować się na konto admin i budować panele. Od tej pory każde zapytanie panelu domyślnie trafia do Prometheusa bez ręcznego wskazywania źródła.

• Provisioning: Plik datasources/prometheus.yml z adresem http://prometheus:9090, typem prometheus oraz flagą isDefault
• Logowanie: Adres http://localhost:3000, użytkownik admin oraz hasło z pliku Compose; diagnostyka przez /api/health
• Po instalacji: Natychmiastowa zmiana hasła oraz, na produkcji, integracja z centralnym logowaniem
• Trwałość: Użytkownicy, panele i uprawnienia zapisywane są w wolumenie grafana_data

Zrzut: provisioning źródła i ekran logowania.

Trzy zapytania dają pełny obraz hosta

Panel łączy średnie obciążenie, użycie pamięci oraz zajętość dysku. Zapytania czyta się od nazwy metryki, przez filtr w nawiasach, po funkcję agregującą. Te trzy zapytania wystarczą na codzienny podgląd zdrowia hosta.

• Obciążenie: node_load1 oraz warianty 5 i 15 minutowe pokazujące trend, nie chwilowy pik
• Pamięć: Stosunek dostępnej do całkowitej: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes
• Dysk: node_filesystem_avail_bytes{mountpoint="/"} dla partycji systemowej hosta
• Procesor: 100 * (1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m]))) jako procent zajętości

Zrzut: wykresy obciążenia, pamięci i dysku.

Router na wykresie: ruch i stan portów

Zapytania filtrują po etykiecie instance z adresem routera oraz po ifDescr z nazwą interfejsu. Ruch liczy funkcja rate, a stan pokazuje proste zapytanie o ifOperStatus i ifAdminStatus. Te same dwa zapytania zasilają gotowe dashboardy z serwisu Grafana.

• Ruch: rate(ifInOctets{instance="ADRES"}[5m]) * 8 daje bity na sekundę dla każdego interfejsu
• Jednostki: Liczniki SNMP zliczają oktety, a operatorzy mówią o bitach, stąd mnożenie przez 8
• Stany: ifOperStatus równe 1 oznacza port w górze, ifAdminStatus rozróżnia wyłączenie administracyjne od awarii
• Błędy: Metryki ifInErrors i ifOutDiscards w osobnym panelu wyłapują wadliwe okablowanie i przeciążenie

Zrzut: wykres ruchu i stanów portów routera.

Od nazwy urządzenia po procenty

Z routera MikroTik przez SNMP odczytasz cztery fundamenty: nazwę administracyjną, czas od restartu, obciążenie procesora i zajętość pamięci. Każdy ma inny typ danych i wymaga innego zapytania. Kolejne slajdy przechodzą przez każdy z nich osobno, od testu po gotowy panel.

• sysName 1.3.6.1.2.1.1.5.0: Tekst, na przykład MT_BIURO; identyfikuje urządzenie na panelach i w alarmach
• sysUpTime 1.3.6.1.2.1.1.3.0: Licznik setnych sekund od restartu; po przeliczeniu daje godziny i dni pracy
• hrProcessorLoad 1.3.6.1.2.1.25.3.3.1.2: Średnie obciążenie CPU w procentach; tabela indeksowana numerem procesora
• Pamięć: hrMemorySize 1.3.6.1.2.1.25.2.2.0 w kilobajtach plus tabela hrStorage z użyciem main memory

Zrzut: tabela czterech wskaźników z OID.

Usługa bywa domyślnie wyłączona

RouterOS nie odpowiada na SNMP, dopóki usługi się nie włączy i nie ustawi wspólnoty. Wystarczą dwa polecenia w terminalu, odpowiednik w WinBox oraz reguła zapory dla UDP 161. Po każdej zmianie powtarzasz test z następnego slajdu, aż router odpowie.

• Podgląd: /snmp print pokazuje enabled: no na świeżym urządzeniu oraz wpis community public
• Włączenie: /snmp set enabled=yes oraz /snmp community set [find default=yes] addresses=ADRES_MONITORINGU/32
• WinBox: Okno SNMP: zaznaczenie Enabled, przycisk Communities oraz ograniczenie pola Addresses
• Zapora: Reguła accept dla UDP 161 ze źródła monitoringu przed regułami drop; test z hosta monitorującego

Zrzut: terminal RouterOS z komendami SNMP.

Czytaj odpowiedź, nie tylko błąd

Narzędzia snmpget i snmpwalk z pakietu snmp zwracają wartości z typami. Poprawna odpowiedź zawiera typ i liczbę, a typowe błędy mówią dokładnie, czego brakuje: usługi, wspólnoty albo indeksu. Naucz się czytać te trzy odpowiedzi, a diagnozowanie SNMP przestanie być zgadywaniem.

• sysName i sysUpTime: snmpget -v2c -c public ADRES 1.3.6.1.2.1.1.5.0 1.3.6.1.2.1.1.3.0; odpowiedzi STRING oraz Timeticks z czasem
• Pamięć: snmpget ... 1.3.6.1.2.1.25.2.2.0; odpowiedź w kilobajtach, na przykład 262144
• Pułapka tabel: Zapytanie gołego OID tabeli bez indeksu zwraca No Such Object; procesor pyta się z indeksem .1
• CPU i tablica: snmpwalk ... 1.3.6.1.2.1.25.3.3.1.2 listuje obciążenie każdego procesora z osobna

Zrzut: wyniki snmpget dla czterech OID.

Inwentaryzacja przed generowaniem

Wbudowany plik snmp.yml zawiera moduły system i if_mib z nazwą i czasem pracy, lecz nic z gałęzi host-resources. Dlatego CPU i pamięć wymagają własnego modułu zbudowanego generatorem z dwóch plików MIB.

• Gotowe: Moduł system niesie sysName i sysUpTime, moduł if_mib interfejsy; oba działają bez dotykania pliku
• Brakuje: Obiektów hrProcessorLoad, hrMemorySize i hrStorage nie ma w żadnym wbudowanym module; sprawdza się to poleceniem grep po OID
• Narzędzie: Obraz prom/snmp-generator buduje moduł routeros z plików SNMPv2-MIB i HOST-RESOURCES-MIB
• Efekt: Siedem metryk: sysName, sysUpTime, hrMemorySize, hrProcessorLoad oraz trzy liczniki hrStorage z etykietą opisu

Zrzut: wyszukiwanie modułu grepem w pliku.

Z nazw MIB na numery OID

Generator czyta generator.yml oraz katalog z bazami MIB i wypisuje gotowy moduł. Plik generator.yml ma kilkanaście linii i trafia do paczki dla studentów.

• Wejście mibs/: Pliki SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF, SNMPv2-MIB, HOST-RESOURCES-MIB, IF-MIB oraz IANAifType-MIB
• Walk: Osiem nazw: sysName, sysUpTime, hrProcessorLoad, hrMemorySize oraz cztery obiekty hrStorage
• Lookups: Indeks hrStorageIndex tłumaczony na czytelny opis hrStorageDescr, sam opis ignorowany jako metryka
• Wynik: Komunikat Generated metrics 7 oraz plik z numerycznymi OID, typami, indeksami i regułami etykiet

Zrzut: terminal z uruchomieniem generatora.

Moduł ląduje na końcu pliku

Wygenerowany blok routeros dokleja się na końcu snmp.yml używanego przez stos. Po restarcie kontenera bramka odpowiada na nowy moduł, co sprawdza się jednym zapytaniem testowym przed konfiguracją Prometheusa.

• Scalenie: Blok od linii z routeros do końca pliku doklejony do snmp.yml stosu; sekcja auths pozostaje wspólna
• Restart: docker restart snmp-exporter; log potwierdza start bez błędów parsowania
• Test: Zapytanie z module routeros zwraca po jednej linii na wskaźnik, w tym hrProcessorLoad z indeksem procesora
• Kontrola: Dopiero poprawna odpowiedź bramki uzasadnia dopisanie zadania do Prometheusa

Zrzut: odpowiedź bramki z czterema wskaźnikami.

Szósty cel na stronie Targets

Zadanie różni się od snmp tylko parametrem module; relabeling jest identyczny, bo bramka ta sama. Po przeładowaniu cel snmp-routeros ma stan up, a próbki trafiają do bazy co 60 sekund. Ten sam schemat dokłada kolejne urządzenia bez dotykania bramki.

• module routeros: Jedyna zmiana względem zadania snmp; reszta parametrów i relabelingu bez zmian
• Cel: Adres MikroTika z etykietą urzadzenie; ten sam router występuje też w zadaniach snmp i snmp-mikrotik
• Interwał: 60 sekund z limitem 55 sekund, jak pozostałe zadania SNMP dla słabych procesorów
• Kontrola: Żądanie POST do /-/reload, potem strona Targets i pierwsze zapytania w Explore

Zrzut: zadanie snmp-routeros w pliku.

Sześć wierszy up i cztery liczby

Po przeładowaniu strona Targets pokazuje sześć celów w stanie up. W Explore zapytania o każdą metrykę zwracają pierwsze próbki: nazwę tekstową, setne sekundy, procent CPU i kilobajty RAM. Wartości liczbowe u ciebie będą inne, ale kształty odpowiedzi są zawsze identyczne.

• Targets: Wiersz snmp-routeros z adresem routera i stanem up; błąd mówiłby dokładnie, co nie odpowiada
• sysName: Próbka o wartości 1 z etykietą sysName z nazwą urządzenia do panelu Stat
• sysUpTime: Liczba rzędu stu milionów setnych sekund, rosnąca monotonicznie do restartu
• CPU i RAM: hrProcessorLoad w procentach oraz hrMemorySize w kilobajtach gotowe do paneli

Zrzut: strona Targets 6/6 up i wyniki Explore.

Jednostki przelicza zapytanie

Surowe metryki mają jednostki SNMP: setne sekundy, procenty i kilobajty. Dzielenia w zapytaniu zamieniają je na godziny, procenty i gigabajty czytelne na panelach. Jednostkę panelu dobierasz do wyniku, inaczej oś wprowadza w błąd.

• Nazwa: sysName{job="snmp-routeros"} w panelu Stat z legendą z etykiety sysName
• Czas pracy: sysUpTime / 100 / 3600 daje godziny; dzielenie przez 24 daje dni
• CPU: hrProcessorLoad bez przeliczeń, wprost w procentach z etykietą procesora
• RAM: Stosunek hrStorageUsed do hrStorageSize dla opisu main memory razy 100 daje procent zajętości

Zrzut: cztery wyrażenia PromQL z wynikami.

Cztery panele w dziesięć minut

Dashboard składa się z dwóch paneli tekstowych, miernika CPU i wykresu RAM. Każdy panel to jedno zapytanie z poprzedniego slajdu, typ wizualizacji i jednostka; źródło danych wybiera się raz. Taki sam układ powtarzasz dla każdego kolejnego routera.

• Panel 1, Stat: Zapytanie sysName, legenda z etykiety sysName, tekstowa nazwa urządzenia na górze
• Panel 2, Stat: Zapytanie sysUpTime / 100 / 3600 z jednostką godziny i progiem ostrzegawczym przy restarcie
• Panel 3, Gauge: Zapytanie hrProcessorLoad z jednostką procentów i progami 70 oraz 90
• Panel 4, Timeseries: Zapytanie procentu RAM z jednostką procentów; historia pokazuje wycieki pamięci

Zrzut: gotowy dashboard czterech paneli.

Czytaj błąd, nie zgaduj

Każda usterka ma charakterystyczny objaw: pusty cel, puste CPU albo zerujący się czas. Poniższa lista przyporządkowuje objaw do przyczyny i naprawy. Zaczynasz od góry listy i schodzisz w dół, aż objaw zniknie.

• Cel down: Bramka nie odpowiada lub router milczy; wracasz do snmpwalk z kroku drugiego
• Puste CPU: Starszy RouterOS bez gałęzi hrProcessorLoad; reszta działa, CPU czytasz z API urządzenia
• Czas od zera: sysUpTime resetuje każdy restart; wykres czasu tnie się, a nie jest to awaria monitoringu
• Nazwa liczbą: Panel sysName bez legendy z etykiety pokazuje jedynkę; legenda bierze tekst z sysName

Zrzut: lista objawów z przyczynami.

Nie rysuj od zera, zaimportuj i dostosuj

Serwis grafana.com/grafana/dashboards zawiera tysiące gotowych paneli. Import sprowadza się do wklejenia numeru ID w oknie Dashboards, New, Import oraz wskazania źródła Prometheus. Poniższe pozycje pasują do stosu z tego modułu.

• Linux, ID 1860: Node Exporter Full, pełny obraz hosta; na górze wybiera się job i host z listy, część paneli wymaga kolektorów systemd i processes
• SNMP if_mib, ID 11169: SNMP Stats dla modułu if_mib, działa od razu z naszym stosem dla MikroTika, Cisco i każdego switcha; alternatywa to ID 21962
• MikroTik rozszerzony, ID 11589: Mikrotik monitoring, bogatszy, lecz wymaga modułu mikrotik wygenerowanego z MIB producenta
• Cisco przez SNMP: Zweryfikowany szablon to ID 11169 (interfejsy Catalyst przez if_mib, procedura w tutorialu sbcode); na switchu wystarcza snmp-server community public RO, a CPU i pamięć wymagają modułu cisco z generatora (CISCO-PROCESS-MIB)

Zrzut: okno importu dashboardu z polem ID.

Nigdy nie rysuj surowego licznika

Licznik rośnie do restartu, więc jego wykres to wznosząca się linia bez informacji o tempie. Funkcje rate i increase liczą przyrost na sekundę i automatycznie korygują zerowanie licznika po restarcie. Pomyłka w tym miejscu to najczęstsza przyczyna bezsensownych wykresów u początkujących.

• Counter: ifInOctets i node_cpu_seconds_total rosną monotonicznie; 32-bitowe zawijają się po 4 miliardach, 64-bitowe praktycznie nigdy
• Gauge: node_load1, temperatura i ifOperStatus mają chwilową wartość; rysuje się je bezpośrednio funkcjami avg i max
• rate: Średni przyrost na sekundę z zakresu, na przykład rate(ifInOctets[5m]) dla ruchu interfejsu
• increase: Całkowity przyrost w zakresie, na przykład transfer w ciągu doby: increase(ifInOctets[24h])

Zrzut: wykres licznika i wskaźnika obok siebie.

Od objawu do komendy w trzech krokach

Większość awarii diagnozuje się w kolejności: Targets, log kontenera, ręczny test poleceniem curl. Poniższa sekwencja przyporządkowuje objaw do konkretnej komendy. Trzymaj się tej kolejności, a większość awarii znajdziesz w kilka minut.

• Brak danych na wykresie: Strona Targets wskaże cel down; dalej docker logs prometheus i test curl adres/metrics
• Restart snmp-exporter: Log z błędem formatu pliku snmp.yml; naprawa przez poprawny plik i restart kontenera
• SNMP timeout: Najpierw snmpwalk z hosta; brak odpowiedzi oznacza wyłączoną usługę lub złą wspólnotę, nie awarię stosu
• Pusty dashboard z importu: Wybierz źródło Prometheus, zmienną Job snmp, zakres co najmniej godziny oraz sprawdź metrykę w Explore
• Grafana bez danych: Test źródła w konfiguracji oraz sprawdzenie czasu systemowego, bo rozjazd czasu rozjeżdża wykresy

Zrzut: procedura Targets, logi, curl.

Sprawdź się przed laboratorium

Uczestnik potrafi uruchomić stos, wyjaśnić przepływ metryk, zbudować panel w Grafanie oraz zdiagnozować brak danych. Poniższe pytania i zadania weryfikują te umiejętności. Kto przejdzie zadania, ten samodzielnie postawi monitoring w swojej sieci.

• Pytania: 1. Wyjaśnij różnicę między modelem pobierania a wypychania. 2. Po co w zadaniu snmp trzy reguły relabeling. 3. Kiedy stosuje się rate, a kiedy increase.
• Zadania laboratoryjne: 1. Uruchom stos i doprowadź siedem celów do stanu up. 2. Zbuduj panel ruchu wybranego interfejsu w bitach na sekundę. 3. Dopisz trzeci router i przeładuj konfigurację bez restartu.
• Słownik: TSDB, PromQL, eksporter, cel, zadanie, relabeling, licznik, wskaźnik, wspólnota, moduł, spacer, provisioning
• Źródła: Dokumentacja Prometheus i Grafana, repozytorium snmp_exporter, dokumentacja Dockera oraz standardy protokołu SNMP

Zrzut: pytania, zadania i słownik pojęć.