Konfiguracja stosu monitoringu Grafana + Prometheus na twoim VPS (przewodnik po Docker Compose)

Jeśli nie masz pewności, czym właściwie są Prometheus i Grafana, przeczytaj nasz artykuł o Prometheus vs Grafana. Jeśli znasz już różnicę, oto jak uruchomić je razem.

Ten wpis to część praktyczna. Wdraża Prometheusa, Grafanę i Node Exportera na jednym VPS przy użyciu Docker Compose, stawia HTTPS przed Grafaną za pomocą Caddy, importuje pulpit Node Exporter Full (ID 1860) i pokazuje, jak zbierać metryki z drugiego VPS przez WireGuard.

Pierwotny test z kwietnia 2026 działał na Ubuntu 24.04 LTS z Docker Engine 27.x i Docker Compose v2.30. Wersje przypięte w konfiguracji poniżej zostały od tego czasu zaktualizowane do obecnie wspieranych wydań. W tym pierwotnym teście z pięcioma hostami hub zużywał około 300 MB RAM na biegu jałowym i od 530 do 650 MB przy ciągłym zbieraniu metryk.

TL;DR

• VPS pełniący rolę huba uruchamia Prometheusa, Grafanę i Node Exportera w jednym stosie Compose, a Caddy jest zainstalowany na hoście jako odwrotne proxy.
• Prometheus i Grafana nasłuchują wyłącznie na 127.0.0.1. Dostęp publiczny prowadzi przez Caddy z automatycznym HTTPS.
• Kolejne serwery dodasz, instalując na każdym Node Exportera i dopisując wpisy do prometheus.yml.
• WireGuard to zalecana ścieżka sieciowa między hubem a węzłami. Sieć prywatna sprawdza się, gdy twoje serwery już są w tej samej sieci prywatnej.
• Do testu z pięcioma hostami poniżej wystarczył VPS z 2 GB, ale traktuj to jako punkt odniesienia, a nie sztywną regułę zależną od liczby hostów.

Co zbudujesz

Tak z grubsza będzie wyglądać cała konfiguracja, gdy skończysz.

                 +-------------------+
                 |  Your laptop      |
                 +---------+---------+
                           | HTTPS
                           v
+--------------------------+----------------------------+
| MONITORING HUB VPS    (2 GB RAM starting point) |
|  Caddy        (reverse proxy, auto HTTPS)             |
|  Grafana      (port 3000, only via Caddy)             |
|  Prometheus   (port 9090, internal only)              |
|  Node Exporter (port 9100, scraped on localhost)      |
+----+---------------------------------+----------------+
     |                                 |
     | scrape over WireGuard           | scrape over WG
     v                                 v
+----+--------+                  +-----+-------+
|  App VPS 1  |                  |  App VPS 2  |
|  Node Expo. |                  |  Node Expo. |
+-------------+                  +-------------+

Cały stos monitoringu mieści się na jednym VPS pełniącym rolę huba. Na każdym innym VPS, który chcesz obserwować, działa wyłącznie Node Exporter. Prometheus na hubie pobiera z nich metryki, Grafana je wizualizuje, a Caddy obsługuje HTTPS.

Co jest potrzebne

Do dokładnie takiej konfiguracji potrzebujesz jednego VPS z Ubuntu na huba, domeny oraz dostępu sudo.

• VPS z co najmniej 2 GB RAM działający na Ubuntu 24.04 LTS.
• Nazwa domeny z rekordem A wskazującym na publiczne IP VPS (na przykład grafana.example.com). Jest niezbędna do HTTPS.
• Dostęp root lub sudo przez SSH.

W całym przewodniku zamieniaj grafana.example.com na subdomenę, którą faktycznie skierowałeś na swój VPS monitorujący. Tej samej domeny użyj w zmiennej środowiskowej Grafany, przy sprawdzaniu DNS oraz w Caddyfile.

Jeśli chcesz monitorować tylko jeden serwer i nie potrzebujesz jeszcze HTTPS, możesz uruchomić stos Compose na istniejącym VPS z pominięciem sekcji o odwrotnym proxy. Reszta przewodnika pozostaje aktualna.

Krok 1: przygotowanie serwera

Zaloguj się przez SSH na VPS-huba użytkownikiem z uprawnieniami sudo. Najpierw wykonaj aktualizację systemu.

sudo apt update && sudo apt upgrade -y

Zainstaluj Docker Engine i wtyczkę Compose z oficjalnego repozytorium Dockera.

# Install prerequisites
sudo apt install -y ca-certificates curl gnupg lsb-release

# Add Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the Docker repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Sprawdź, czy oba są zainstalowane.

docker --version
docker compose version

Oba polecenia powinny bezbłędnie zwrócić numer wersji. Dokładne wersje Docker Engine i Compose zależą od tego, co oficjalne repozytorium udostępnia w chwili instalacji.

sudo usermod -aG docker $USER

Zanim przejdziesz dalej, wyloguj się i zaloguj ponownie, żeby nowe członkostwo w grupie zaczęło działać. Grupa docker daje w praktyce uprawnienia roota, dodawaj więc do niej wyłącznie zaufanych administratorów.

Skonfiguruj UFW tak, aby na hubie monitorującym przepuszczał SSH, HTTP i HTTPS. Port 80 obsługuje przekierowanie z HTTP na HTTPS oraz walidację ACME. Sama Grafana zostaje za Caddy.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

Nie otwieraj portów 3000, 9090 ani 9100 na publiczny internet. Usługi monitoringu nasłuchują na 127.0.0.1 nie bez powodu.

Krok 2: stos Compose

Utwórz katalog na stos i konfigurację Prometheusa.

mkdir -p ~/monitoring/prometheus
cd ~/monitoring

Zapisz plik Compose.

# ~/monitoring/docker-compose.yml
services:
  prometheus:
    image: prom/prometheus:v3.13.2
    container_name: prometheus
    restart: unless-stopped
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=15d'
      - '--web.enable-lifecycle'
      - '--web.listen-address=127.0.0.1:9090'
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus_data:/prometheus
    network_mode: host
  node-exporter:
    image: prom/node-exporter:v1.12.1
    container_name: node-exporter
    restart: unless-stopped
    pid: host
    network_mode: host
    command:
      - '--path.rootfs=/host'
      - '--web.listen-address=127.0.0.1:9100'
      - '--collector.filesystem.mount-points-exclude=^/(dev|proc|sys|var/lib/docker/.+|var/lib/kubelet/.+)($$|/)'
    volumes:
      - '/:/host:ro,rslave'
  grafana:
    image: grafana/grafana:13.1.3
    container_name: grafana
    restart: unless-stopped
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_ADMIN_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false
      - GF_SERVER_ROOT_URL=https://grafana.example.com
      - GF_SERVER_HTTP_ADDR=127.0.0.1
    volumes:
      - grafana_data:/var/lib/grafana
    network_mode: host
    depends_on:
      - prometheus
volumes:
  prometheus_data:
  grafana_data:

Teraz zapisz konfigurację Prometheusa.

# ~/monitoring/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    monitor: 'monitoring-hub'
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['127.0.0.1:9090']
  - job_name: 'node'
    static_configs:
      - targets: ['127.0.0.1:9100']
        labels:
          host: 'monitoring-hub'

Utwórz plik .env z hasłem administratora Grafany. Użyj silnego hasła i nie commituj tego pliku do gita.

cat > ~/monitoring/.env <<'EOF'
GRAFANA_ADMIN_PASSWORD='replace-with-a-strong-password'
EOF
chmod 600 ~/monitoring/.env

Kilka powyższych flag zasługuje na krótkie wyjaśnienie.

• --web.listen-address=127.0.0.1:9090 sprawia, że Prometheus nasłuchuje wyłącznie na interfejsie pętli zwrotnej hosta. Port 9090 pozostaje więc poza siecią publiczną, a Grafana i lokalna administracja nadal mają do niego dostęp.
• --web.enable-lifecycle włącza POST /-/reload, dzięki czemu możesz zastosować zmiany w konfiguracji Prometheusa bez restartu kontenera.
• pid: host, network_mode: host, montowanie bind katalogu głównego hosta oraz --path.rootfs=/host dają Node Exporterowi w kontenerze potrzebny kontekst hosta, zamiast ograniczać go do własnego środowiska kontenera.
• GF_USERS_ALLOW_SIGN_UP=false uniemożliwia odwiedzającym samodzielne zakładanie kont w Grafanie. Nie czyni to jednak Grafany prywatną: strona logowania nadal jest publicznie dostępna przez Caddy.

Wskazówka: Jeśli wolisz pominąć ręczną instalację, Cloudzy oferuje wdrożenia jednym kliknięciem dla Grafana oraz Prometheus . Wdrożenie Prometheusa może przy okazji zainstalować Node Exportera.

Krok 3: pierwsze uruchomienie i weryfikacja

Uruchom stos.

cd ~/monitoring
docker compose up -d

Odczekaj kilka sekund i sprawdź, czy wszystkie trzy kontenery działają.

docker compose ps

Wszystkie trzy usługi powinny mieć status running.

Otwórz tunel SSH z laptopa, żeby sprawdzić stronę celów Prometheusa.

ssh -L 9090:localhost:9090 your-user@your-vps-ip

Następnie otwórz w przeglądarce http://localhost:9090/targets. Powinieneś zobaczyć dwa cele, oba w stanie UP:

prometheus            UP    http://127.0.0.1:9090/metrics
node                  UP    http://127.0.0.1:9100/metrics

Jeśli któryś jest DOWN, przejdź do sekcji Najczęstsze problemy. Nie idź dalej, dopóki oba nie będą UP.

Zamknij tunel, gdy skończysz sprawdzać cele. Z zewnątrz Prometheus pozostanie dostępny wyłącznie przez ten tunel SSH. W kolejnym kroku udostępnimy Grafanę przez HTTPS.

Krok 4: odwrotne proxy z HTTPS przy użyciu Caddy

Caddy to pojedynczy plik binarny i obsługuje HTTPS automatycznie. Przy odwrotnym proxy dla jednej witryny jego konfiguracja jest krótsza niż odpowiadający blok Nginxa.

Zainstaluj Caddy z oficjalnego repozytorium.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
  sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | \
  sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

Przed kolejnym krokiem sprawdź, czy rekord DNS A dla grafana.example.com wskazuje na publiczne IP VPS. Bez tego walidacja ACME się nie powiedzie.

dig +short grafana.example.com
# Should print the VPS public IP

Edytuj plik Caddyfile.

# /etc/caddy/Caddyfile
grafana.example.com {
    reverse_proxy 127.0.0.1:3000
    encode gzip
}

Przeładuj Caddy.

sudo systemctl reload caddy

Caddy automatycznie pobiera i odnawia publicznie zaufane certyfikaty TLS przez ACME, gdy tylko domena wskazuje twój serwer, a porty 80 i 443 są osiągalne. Otwórz w przeglądarce https://grafana.example.com: powinieneś zobaczyć stronę logowania Grafany na poprawnym połączeniu HTTPS. Zaloguj się jako admin hasłem z pliku .env.

Krok 5: dodaj Prometheusa jako źródło danych i zaimportuj pulpit 1860

W interfejsie Grafany przejdź do Połączenia > Źródła danych > Dodaj źródło danych i wybierz Prometheus.

Ustaw URL na:

http://127.0.0.1:9090

W tej konfiguracji Grafana i Prometheus dzielą sieć hosta, a Prometheus nasłuchuje wyłącznie na pętli zwrotnej. Kliknij Save & test i sprawdź, czy Grafana potrafi odpytać API Prometheusa. Powinien pojawić się komunikat „Successfully queried the Prometheus API".

Teraz zaimportuj pulpit. Node Exporter Full (ID 1860 autorstwa rfmoz) to szeroko używany społecznościowy pulpit dla metryk Node Exportera. Obejmuje CPU, pamięć, operacje dyskowe, sieć, deskryptory plików oraz temperatury sprzętu, jeśli host je udostępnia. Ma też zmienne job i instance, więc w układzie hub-and-spoke działa bez żadnych zmian.

Przejdź do Pulpity > Nowy > Importuj pulpit, wpisz identyfikator pulpitu 1860, wybierz swoje źródło danych Prometheus i zaimportuj go.

Pulpit powinien się zapełnić, gdy tylko twój cel Node Exporter będzie UP. Pulpit 1860 korzysta w części paneli także z metryk opcjonalnych kolektorów systemd i processes, więc pojedynczy pusty panel nie musi oznaczać, że cel jest zepsuty.

Krok 6: dodaj drugi VPS (układ hub-and-spoke)

Zanim uruchomisz Node Exportera, upewnij się, że prywatny adres IP, do którego chcesz go przypiąć, faktycznie istnieje na drugim VPS. Jeśli korzystasz z WireGuarda, najpierw dokończ jego konfigurację.

Na drugim VPS zainstaluj Dockera według części o instalacji Dockera z kroku 1, ale nie otwieraj portów 80 ani 443 wyłącznie na potrzeby monitoringu. Następnie uruchom sam Node Exporter.

mkdir -p ~/node-exporter
cd ~/node-exporter

cat > docker-compose.yml <<'EOF'
services:
  node-exporter:
    image: prom/node-exporter:v1.12.1
    container_name: node-exporter
    restart: unless-stopped
    pid: host
    command:
      - '--path.rootfs=/host'
      - '--web.listen-address=10.10.0.2:9100'  # bind to the private monitoring IP, never 0.0.0.0
    volumes:
      - '/:/host:ro,rslave'
    network_mode: host
EOF

docker compose up -d

Zamień 10.10.0.2 na prywatny adres IP tego serwera używany do monitoringu. Jeśli korzystasz z WireGuarda, użyj jego adresu WireGuard; jeśli z sieci prywatnej Cloudzy, użyj adresu prywatnego interfejsu VPS. Jeśli na tym VPS działa już UFW, pozwól sięgać do Node Exportera wyłącznie hubowi monitorującemu. Na przykład, gdy prywatny adres huba to 10.10.0.1:

sudo ufw allow proto tcp from 10.10.0.1 to any port 9100
sudo ufw status

Zamień 10.10.0.1 na rzeczywisty prywatny adres IP huba. Jeśli UFW jest wyłączony, jawnie ustawiony --web.listen-address nadal trzyma Node Exportera z dala od interfejsu publicznego, ale inne maszyny mające dostęp do tej sieci prywatnej też mogą dosięgnąć portu 9100.

Dwie dobre opcje ścieżki sieciowej między hubem a węzłami:

1. Sieć WireGuard. Każdy VPS dołącza do sieci WireGuard, a Prometheus odpytuje prywatne adresy IP. Po jednorazowej konfiguracji WireGuarda to najbezpieczniejsza opcja. Oferujemy WireGuard jako wdrożenie jednym kliknięciem, mamy też gotowy poradnik konfiguracji na jego temat.
2. Sieć prywatna Cloudzy. Instancje VPS Cloudzy w tym samym regionie dostają prywatny interfejs do ruchu wschód-zachód, więc możesz odpytywać ten adres zamiast stawiać osobny tunel WireGuard.

CZYTAJ

Jak skonfigurować WireGuard VPN na VPS | przewodnik Ubuntu

Gdy Node Exporter działa już na drugim VPS i jest osiągalny pod prywatnym IP, zastąp istniejące zadanie node w pliku prometheus.yml na hubie blokiem poniżej.

# Update the existing 'node' job in ~/monitoring/prometheus/prometheus.yml
  - job_name: 'node'
    static_configs:
      - targets: ['127.0.0.1:9100']
        labels:
          host: 'monitoring-hub'
      - targets: ['10.10.0.2:9100']
        labels:
          host: 'app-vps-1'
          tier: 'production'

Przeładuj Prometheusa bez restartowania kontenera.

curl -X POST http://localhost:9090/-/reload

Otwórz ponownie tunel SSH z kroku 3 i wejdź na http://localhost:9090/targets. Nowy cel powinien pojawić się jako UP. Otwórz pulpit Node Exporter Full, przełącz zmienną instance u góry na nowy serwer, a zobaczysz jego wykresy.

Zużycie zasobów i kiedy warto się rozbudować

Te liczby pochodzą z pierwotnego testu z kwietnia 2026 na VPS z Ubuntu i 2 GB pamięci przy pięciu monitorowanych hostach. Traktuj je jako punkt odniesienia dla takiego obciążenia, a nie jako gwarancję doboru zasobów dla nowszych wydań.

Rozbuduj zasoby, gdy hubowi zacznie brakować pamięci albo zapasu na dysku. Sama liczba hostów to kiepskie kryterium doboru, bo zużycie zmieniają kardynalność serii, włączone kolektory, interwał zbierania i czas retencji. Do dłuższego centralnego przechowywania Prometheus obsługuje integracje ze zdalnym magazynem. VictoriaMetrics to jedna z opcji zgodnych z Prometheusem.

Najczęstsze problemy

Siedem najczęściej występujących problemów wraz z rozwiązaniami.

1. Prometheus jest dostępny z publicznego internetu. Zwykłe mapowanie portu 9090:9090 wystawia Prometheusa na cały świat. Rozwiązanie: zostaw --web.listen-address=127.0.0.1:9090 w poleceniu Prometheusa, tak jak pokazano wyżej. Wtedy Prometheus nasłuchuje wyłącznie na interfejsie pętli zwrotnej hosta.
2. Źródło danych w Grafanie nie może dosięgnąć Prometheusa. Ten stos korzysta z sieci hosta, więc Grafana dosięga Prometheusa pod http://127.0.0.1:9090. Sprawdź, czy Prometheus działa i nadal nasłuchuje na pętli zwrotnej.
3. Pulpit Node Exportera pokazuje „No data". Trzy typowe przyczyny. (a) Prometheus nie zbiera danych z celu. Sprawdź /targets. (b) Etykieta job w zmiennej pulpitu nie zgadza się z job_name w konfiguracji scrape. (c) Zapora blokuje port 9100 między hubem a celem.
4. Hasło administratora Grafany to wciąż admin/admin na produkcji. Ustaw GF_SECURITY_ADMIN_PASSWORD z pliku .env przed pierwszym uruchomieniem. Jeśli o tym zapomniałeś, zmień hasło przy pierwszym logowaniu i wyłącz rejestrację.
5. Caddy zgłasza „ACME challenge failed". Rekord DNS A jeszcze się nie rozpropagował albo port 80 jest zablokowany. Uruchom ufw allow 80,443/tcp, poczekaj na propagację DNS i uruchom sudo systemctl reload caddy. Użyj dig +short , aby potwierdzić propagację.
6. Dysk Prometheusa się zapełnia. Etykiety o wysokiej kardynalności albo krótkie interwały zbierania przy wielu hostach potrafią szybko zapełnić wolumen. Obserwuj prometheus_tsdb_head_series oraz rozmiar wolumenu. Środki zaradcze: wyłącz nieużywane kolektory Node Exportera, wydłuż scrape_interval do 30s albo skróć retencję.
7. Błędy uprawnień przy montowaniu bind. Jeśli zamontujesz katalog hosta zamiast nazwanego wolumenu, UID kontenera (65534 dla Prometheusa, 472 dla Grafany) musi mieć prawo zapisu. Nazwane wolumeny, jak w powyższym pliku Compose, omijają ten problem.

Kiedy ten stos to przesada

Jeśli zależy ci tylko na alercie, gdy adres URL przestanie odpowiadać, ten stos to przesada. Uptime Kuma jest znacznie lżejszym wyborem, gdy wystarczą podstawowe kontrole dostępności.

Często zadawane pytania

Czym różni się Prometheus od Grafany?

Prometheus to baza danych szeregów czasowych: zbiera metryki ze skonfigurowanych celów w zadanym przez ciebie interwale, zapisuje je na dysku i odpowiada na zapytania PromQL. Grafana to warstwa wizualizacji, która łączy się z Prometheusem (i wieloma innymi źródłami danych) i rysuje pulpity. Prawie zawsze potrzebujesz obu: Prometheus zbiera i przechowuje, Grafana wyświetla.

Ile pamięci RAM potrzebuje zestaw Prometheus + Grafana?

Hub monitorujący, na którym w obrębie jednego VPS działają Prometheus, Grafana, Node Exporter i odwrotne proxy, zużywa około 300 MB RAM na biegu jałowym oraz od 530 do 650 MB przy aktywnym zbieraniu z pięciu hostów co 15 sekund.

Czy mogę monitorować wiele serwerów jedną instancją Grafany?

Tak. Standardowy wzorzec to hub-and-spoke. Jedna instancja Prometheusa na VPS-hubie zbiera dane z Node Exportera działającego na każdym innym serwerze, który chcesz obserwować. Grafana na hubie odpytuje tylko tego jednego Prometheusa. Pulpit Node Exporter Full (ID 1860) obsługuje zmienną instance, więc między serwerami przełączasz się z jednego pulpitu.

Który pulpit Grafany jest najlepszy dla Node Exportera?

Do takiej konfiguracji Node Exporter Full (pulpit o ID 1860 autorstwa rfmoz) to bardzo dobry wybór domyślny. Obejmuje najważniejsze metryki hosta z Node Exportera i obsługuje zmienne job oraz instance przy monitorowaniu wielu serwerów. Część paneli zależy od opcjonalnych kolektorów Node Exportera, więc pojedynczy pusty panel nie musi oznaczać, że cel zbierania jest zepsuty.

Jak udostępnić Grafanę przez HTTPS?

Uruchom Grafanę przypiętą do 127.0.0.1:3000 i postaw przed nią odwrotne proxy, które zajmie się HTTPS. Najprostszy jest Caddy: czterowierszowy Caddyfile z reverse_proxy 127.0.0.1:3000 i blokiem domeny załatwia całość, łącznie z automatycznym zarządzaniem certyfikatami TLS.

Czy Prometheus + Grafana są darmowe do zastosowań komercyjnych?

Prometheus jest udostępniany na licencji Apache 2.0. Grafana OSS działa na AGPLv3. Wewnętrzne i komercyjne używanie niezmodyfikowanej Grafany OSS jest dozwolone, ale jej modyfikowanie, rozpowszechnianie albo udostępnianie zmodyfikowanej wersji przez sieć może rodzić obowiązek udostępnienia kodu źródłowego zgodnie z AGPL. Grafana Enterprise i Grafana Cloud podlegają odrębnym warunkom komercyjnym.

Kiedy warto przejść z Prometheusa na VictoriaMetrics?

Rozważ VictoriaMetrics, gdy dłuższa retencja, wysoka kardynalność serii albo kilka instancji Prometheusa utrudniają utrzymanie lokalnej bazy TSDB Prometheusa w ramach budżetu pamięci i dysku twojego serwera. VictoriaMetrics potrafi przyjmować dane z Prometheusa i udostępnia zgodne z nim API zapytań, więc może pełnić rolę magazynu długoterminowego albo backendu metryk dla Grafany. Przetestuj ją na własnym obciążeniu, zamiast przesiadać się przy sztywnym progu RAM.