Autor: [Piotr Wasilewski](/autorzy/piotr-wasilewski) Architekt rozwiązań chmurowych · Zweryfikowano Kwiecień 2026 1. [Strona główna](/) › 2. [Baza wiedzy](/baza-wiedzy/) › 3. Prometheus + Grafana — monitoring # Prometheus + Grafana — monitoring stack dla VPS i serwerów Opublikowano: 10 kwietnia 2026 · Kategoria: VPS / Monitoring Prometheus i Grafana to dziś standard monitoringu w środowiskach cloud-native i on-premise. Prometheus zbiera metryki metodą pull — sam odpytuje eksportery co 15 sekund i przechowuje dane w lokalnej bazie time series. Grafana wizualizuje te dane na dashboardach z wykresami i alertami. Ten artykuł przeprowadzi cię przez pełną instalację: Prometheus + node\_exporter (metryki systemu), Grafana (dashboardy) i Alertmanager (powiadomienia Slack/email). Całość postawisz w godzinę. ## Architektura stack Prometheus Komponent Rola Port Prometheus Scraper metryk + TSDB + PromQL + reguły alertów 9090 node\_exporter Metryki systemu Linux: CPU, RAM, dysk, sieć 9100 Grafana Dashboardy, wykresy, alerty wizualne 3000 Alertmanager Routing alertów: Slack, email, PagerDuty, webhook 9093 Blackbox Exporter HTTP/HTTPS/TCP/ICMP probe — monitoring dostępności URL 9115 ## Instalacja przez Docker Compose Najwygodniej postawić cały stack przez Docker Compose. Utwórz katalog `/opt/monitoring/` i plik `docker-compose.yml`: version: "3.8" services: prometheus: image: prom/prometheus:latest volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - ./rules/:/etc/prometheus/rules/ - prometheus\_data:/prometheus command: - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.path=/prometheus' - '--storage.tsdb.retention.time=15d' - '--web.enable-lifecycle' ports: - "127.0.0.1:9090:9090" restart: unless-stopped grafana: image: grafana/grafana:latest volumes: - grafana\_data:/var/lib/grafana environment: - GF\_SECURITY\_ADMIN\_PASSWORD=zmien-to-haslo - GF\_USERS\_ALLOW\_SIGN\_UP=false ports: - "127.0.0.1:3000:3000" restart: unless-stopped alertmanager: image: prom/alertmanager:latest volumes: - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml ports: - "127.0.0.1:9093:9093" restart: unless-stopped node\_exporter: image: prom/node-exporter:latest network\_mode: host pid: host volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - '--path.procfs=/host/proc' - '--path.sysfs=/host/sys' - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)' restart: unless-stopped volumes: prometheus\_data: grafana\_data: ## Konfiguracja prometheus.yml \# /opt/monitoring/prometheus.yml global: scrape\_interval: 15s evaluation\_interval: 15s external\_labels: env: 'production' alerting: alertmanagers: - static\_configs: - targets: \['alertmanager:9093'\] rule\_files: - 'rules/\*.yml' scrape\_configs: - job\_name: 'prometheus' static\_configs: - targets: \['localhost:9090'\] - job\_name: 'node' static\_configs: - targets: - 'localhost:9100' # serwer monitoring - 'web01:9100' # serwer www 1 - 'web02:9100' # serwer www 2 - 'db01:9100' # serwer bazy danych relabel\_configs: - source\_labels: \[\_\_address\_\_\] target\_label: instance - job\_name: 'blackbox' metrics\_path: /probe params: module: \[http\_2xx\] static\_configs: - targets: - https://example.com - https://api.example.com/health relabel\_configs: - source\_labels: \[\_\_address\_\_\] target\_label: \_\_param\_target - source\_labels: \[\_\_param\_target\] target\_label: instance - target\_label: \_\_address\_\_ replacement: blackbox:9115 ## Instalacja node\_exporter na serwerach bez Dockera \# Pobierz node\_exporter (sprawdz aktualna wersje na github.com/prometheus/node\_exporter) wget https://github.com/prometheus/node\_exporter/releases/download/v1.8.2/node\_exporter-1.8.2.linux-amd64.tar.gz tar xvf node\_exporter-1.8.2.linux-amd64.tar.gz sudo mv node\_exporter-1.8.2.linux-amd64/node\_exporter /usr/local/bin/ sudo useradd --no-create-home --shell /bin/false node\_exporter # Usluga systemd sudo tee /etc/systemd/system/node\_exporter.service <<'UNIT' \[Unit\] Description=Node Exporter After=network.target \[Service\] User=node\_exporter ExecStart=/usr/local/bin/node\_exporter Restart=on-failure \[Install\] WantedBy=multi-user.target UNIT sudo systemctl daemon-reload sudo systemctl enable --now node\_exporter # Sprawdz czy dziala curl http://localhost:9100/metrics | grep node\_cpu ## PromQL — podstawowe zapytania PromQL to potężny język do analizy metryk. Poniżej najważniejsze zapytania do monitoringu serwera — możesz je wkleić bezpośrednio w Grafanie podczas tworzenia paneli: \# Uzycie CPU w procentach 100 - (avg by(instance) (rate(node\_cpu\_seconds\_total{mode="idle"}\[5m\])) \* 100) # Zajeta pamiec RAM (%) 100 \* (1 - (node\_memory\_MemAvailable\_bytes / node\_memory\_MemTotal\_bytes)) # Uzycie dysku (%) 100 \* (1 - (node\_filesystem\_avail\_bytes{mountpoint="/"} / node\_filesystem\_size\_bytes{mountpoint="/"})) # Ruch sieciowy (MB/s) - wyslane rate(node\_network\_transmit\_bytes\_total{device!="lo"}\[5m\]) / 1024 / 1024 # Load average 1-minutowy node\_load1 # Liczba procesow node\_procs\_running # Uptime serwera (dni) (time() - node\_boot\_time\_seconds) / 86400 # HTTP RPS (jesli masz nginx-prometheus-exporter) rate(nginx\_http\_requests\_total\[5m\]) # P95 latencja (z histogram\_quantile) histogram\_quantile(0.95, rate(http\_request\_duration\_seconds\_bucket\[5m\])) ## Reguły alertów (alerting rules) \# /opt/monitoring/rules/node\_alerts.yml groups: - name: node\_alerts rules: - alert: HighCpuUsage expr: 100 - (avg by(instance)(rate(node\_cpu\_seconds\_total{mode="idle"}\[5m\])) \* 100) > 85 for: 5m labels: severity: warning annotations: summary: "Wysokie uzycie CPU na {{ $labels.instance }}" description: "CPU: {{ $value | printf \\"%.1f\\" }}% przez ostatnie 5 minut" - alert: HighMemoryUsage expr: 100 \* (1 - (node\_memory\_MemAvailable\_bytes / node\_memory\_MemTotal\_bytes)) > 90 for: 3m labels: severity: critical annotations: summary: "Krytyczne uzycie RAM na {{ $labels.instance }}" - alert: DiskSpaceLow expr: 100 \* (1 - (node\_filesystem\_avail\_bytes{mountpoint="/"} / node\_filesystem\_size\_bytes{mountpoint="/"})) > 85 for: 10m labels: severity: warning annotations: summary: "Malo miejsca na dysku: {{ $labels.instance }}" - alert: InstanceDown expr: up == 0 for: 1m labels: severity: critical annotations: summary: "Serwer niedostepny: {{ $labels.instance }}" ## Alertmanager — routing na Slack i email \# /opt/monitoring/alertmanager.yml global: smtp\_from: 'alerts@example.com' smtp\_smarthost: 'smtp.example.com:587' smtp\_auth\_username: 'alerts@example.com' smtp\_auth\_password: 'haslo-smtp' route: receiver: 'slack-ops' group\_by: \['alertname', 'instance'\] group\_wait: 30s group\_interval: 5m repeat\_interval: 4h routes: - match: severity: critical receiver: 'pagerduty-critical' - match: severity: warning receiver: 'slack-ops' receivers: - name: 'slack-ops' slack\_configs: - api\_url: 'https://hooks.slack.com/services/TWOJ-WEBHOOK' channel: '#ops-alerts' title: '{{ .GroupLabels.alertname }}' text: '{{ range .Alerts }}{{ .Annotations.summary }} {{ end }}' - name: 'pagerduty-critical' pagerduty\_configs: - service\_key: 'twoj-pagerduty-key' inhibit\_rules: - source\_match: alertname: 'InstanceDown' target\_match\_re: alertname: '.\*' equal: \['instance'\] ## Grafana — importowanie gotowych dashboardów Grafana ma repozytorium gotowych dashboardów na `grafana.com/grafana/dashboards`. Najważniejsze ID do importu (Dashboards → Import → wklej ID): - **ID 1860** — Node Exporter Full — kompletny dashboard systemu Linux (CPU, RAM, dysk, sieć, temperatura, procesy) - **ID 13978** — Node Exporter Quickstart — uproszczony, czytelny overview - **ID 9614** — NGINX — metryki nginx-prometheus-exporter (RPS, kody HTTP, connections) - **ID 9628** — PostgreSQL Database — metryki postgres\_exporter - **ID 14191** — Blackbox Exporter — status HTTP probe, SSL expiry countdown Po imporcie ustaw data source na Prometheus i wybierz odpowiednią instancję z dropdowna. Gotowe dashboardy pokryją 80% potrzeb monitoringu bez pisania własnych zapytań PromQL. ## Nginx reverse proxy przed Grafaną server { listen 443 ssl http2; server\_name monitoring.example.com; ssl\_certificate /etc/letsencrypt/live/monitoring.example.com/fullchain.pem; ssl\_certificate\_key /etc/letsencrypt/live/monitoring.example.com/privkey.pem; location / { proxy\_pass http://127.0.0.1:3000; proxy\_http\_version 1.1; proxy\_set\_header Host $host; proxy\_set\_header X-Real-IP $remote\_addr; proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for; proxy\_set\_header X-Forwarded-Proto $scheme; } } ## Najczęstsze pytania Czym różni się Prometheus od Zabbix i Nagios? + Prometheus jest oparty na pull model — sam odpytuje endpointy /metrics co określony interwał (domyślnie 15s). Zabbix i Nagios używają agentów push lub aktywnych checków. Prometheus przechowuje dane jako time series w lokalnej bazie TSDB, ma silny język zapytań PromQL i świetnie integruje się z Grafaną. Zabbix ma bardziej rozbudowany built-in UI i jest lepszy dla klasycznego IT monitoringu (Windows, SNMP). Dla środowisk cloud-native i kontenerów Prometheus + Grafana jest standardem de facto. Ile RAM i dysku potrzebuje Prometheus? + Prometheus jest bardzo wydajny. Dla 10 serwerów z node\_exporter, retencją 15 dni i scrape interval 15s potrzebuje ok. 1-2 GB RAM i 20-30 GB dysku. Dla 100 serwerów: 4-8 GB RAM i 200-400 GB dysku. Prometheus kompresuje dane TSDB efektywnie (ok. 1-2 bytes per sample). Domyślna retencja to 15 dni — możesz ją skrócić (--storage.tsdb.retention.time=7d) lub używać remote write do długoterminowego storage (Thanos, Mimir, VictoriaMetrics). Czym jest PromQL i jak go używać? + PromQL (Prometheus Query Language) to język zapytań do metryk time series. Podstawowe koncepty: instant vector (wartości w chwili t), range vector (wartości w przedziale \[5m\]), funkcje (rate(), irate(), avg\_over\_time(), histogram\_quantile()). Przykłady: "rate(http\_requests\_total\[5m\])" — RPS z ostatnich 5 minut; "100 - (avg by(instance)(rate(node\_cpu\_seconds\_total{mode='idle'}\[5m\])) \* 100)" — użycie CPU w procentach. PromQL jest potężny ale ma krzywą nauki — Grafana ma gotowe dashboardy które generują zapytania automatycznie. Jak skonfigurować alerty w Alertmanager? + Alertmanager obsługuje routing alertów z Prometheusa do różnych kanałów (email, Slack, PagerDuty, webhook). Najpierw definiujesz reguły alertów w Prometheusie (alerting rules w YAML — warunek PromQL + czas trwania). Alertmanager odbiera alerty i routing: grupuje powiązane alerty (grouping), wycisza (silencing), obsługuje inhibition (jeden alert blokuje inny). Konfiguracja routingu w alertmanager.yml określa receivers i route — możesz wysyłać krytyczne alerty na PagerDuty, a warnings na Slack. ## Sprawdź oferty pasujące do tego scenariusza Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne. Contabo VPS z 4-8 GB RAM — idealny dla Prometheus + Grafana stack z 10+ serwerami VPS Monitoring [Aktywuj rabat →](/out/contabo) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/contabo) Mikr.us Tani VPS do nauki Prometheusa i Grafany przed produkcją Dev/Test [Aktywuj rabat →](/out/mikrus) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/mikrus) LH.pl Hosting zarządzany — bez własnego monitoringu, panele wbudowane Managed [Aktywuj rabat →](/out/lh-pl) #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/lh-pl) ## Powiązane strony - [Graylog — centralizacja logów](/baza-wiedzy/graylog-centralizacja-logow) - [Monitorowanie strony z UptimeRobot](/baza-wiedzy/monitorowanie-strony-uptime-robot) - [Bezpieczeństwo VPS — checklist](/baza-wiedzy/bezpieczenstwo-vps-checklist) - [Wszystkie artykuły](/baza-wiedzy/)