Prometheus – monitoring infrastruktury i aplikacji
Prometheus to system monitoringu i alertingu zaprojektowany przede wszystkim dla środowisk dynamicznych, takich jak Linux, Docker, Kubernetes i infrastruktura chmurowa.
Jego podstawowa funkcja jest prosta:
Prometheus
|
+----------+----------+
| | |
Linux Docker Kubernetes
| | |
Metrics Metrics Metrics
Prometheus zbiera metryki liczbowe i przechowuje je jako szeregi czasowe (time series).
Jak działa Prometheus?
Najważniejszą cechą Prometheusa jest model pull.
Zamiast czekać, aż każdy serwer wyśle dane, Prometheus okresowo pyta monitorowane systemy o metryki:
Prometheus
|
| HTTP GET /metrics
v
Target
|
v
Metrics
Przykład:
node_cpu_seconds_total
node_memory_MemAvailable_bytes
node_filesystem_avail_bytes
Prometheus pobiera te wartości i zapisuje je wraz z timestampem.
Architektura
Typowa infrastruktura:
Prometheus
|
+----------------+----------------+
| | |
v v v
Linux Server Kubernetes Application
| | |
node_exporter kube-state-metrics /metrics
| | |
+----------------+----------------+
|
v
Grafana
|
v
Administrator
Prometheus odpowiada przede wszystkim za zbieranie i przechowywanie metryk, a Grafana za ich wygodną wizualizację.
/metrics
Aplikacja lub exporter udostępnia endpoint:
http://server:9100/metrics
który może zwracać np.:
node_memory_MemAvailable_bytes 4294967296
node_load1 0.42
Prometheus cyklicznie pobiera ten endpoint.
Node Exporter
Do monitorowania Linuxa bardzo często wykorzystuje się Node Exporter.
Schemat:
Linux
|
v
Node Exporter
|
| /metrics
v
Prometheus
Node Exporter może dostarczać informacje m.in. o:
- CPU,
- RAM,
- dyskach,
- filesystemach,
- sieci,
- load average,
- systemie operacyjnym.
Monitoring CPU
Przykładowo możemy obserwować:
CPU Usage
|
100% | ███
80% | ███ ███
60% | ███ ███ ███
40% | ███ ███ ███ ███
20% | ███ ███ ███ ███
+----------------------
time →
Samo wysokie CPU nie musi oznaczać problemu.
Dlatego monitoring powinien analizować również:
- load,
- memory pressure,
- I/O,
- network,
- procesy.
PromQL
Jedną z najważniejszych części Prometheusa jest PromQL – Prometheus Query Language.
Przykładowe zapytanie:
up
pokazuje, czy target jest dostępny.
Możemy również filtrować:
up{job="node"}
CPU
Przykładowe zapytanie pozwalające policzyć wykorzystanie CPU:
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
Pozwala obserwować procentowy poziom wykorzystania CPU dla hostów.
RAM
Możemy analizować dostępność pamięci:
node_memory_MemAvailable_bytes
albo procent wykorzystania pamięci:
100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)
Dysk
Przykład:
node_filesystem_avail_bytes
może pokazywać ilość dostępnego miejsca.
Można również stworzyć alert:
Filesystem
|
v
< 10% free
|
v
ALERT
Monitoring usług
Prometheus może monitorować również dostępność usług.
Przykład:
Prometheus
|
+--> Web Server
|
+--> Database
|
+--> API
|
+--> DNS
Jeżeli endpoint przestanie odpowiadać:
up == 0
można wygenerować alert.
Alertmanager
Sam Prometheus zbiera metryki i może oceniać reguły, ale do zarządzania alertami bardzo często wykorzystuje się Alertmanager.
Architektura:
Targets
|
v
Prometheus
|
| Alert
v
Alertmanager
|
+--> Email
+--> Slack
+--> PagerDuty
+--> Webhook
Przykład alertu
Załóżmy:
CPU > 90%
przez określony czas.
Logika:
IF CPU > 90%
FOR 5m
THEN ALERT
Dzięki temu chwilowy skok CPU nie musi od razu generować alarmu.
Prometheus + Kubernetes
To jedno z najważniejszych zastosowań.
Schemat:
Kubernetes
|
+---------------+---------------+
| | |
Node Pod API
| | |
node-exporter /metrics kube-state
| | |
+---------------+---------------+
|
Prometheus
|
Grafana
Prometheus może monitorować:
- nodes,
- pods,
- deployments,
- services,
- containers,
- CPU,
- RAM,
- restarty,
- dostępność workloadów.
Kubernetes i kube-state-metrics
kube-state-metrics dostarcza informacje o stanie obiektów Kubernetes.
Przykładowo:
Deployment
|
+--> desired replicas: 5
+--> available: 3
Możemy wtedy wykryć:
Desired: 5
Available: 3
ALERT
Prometheus + Docker
W środowisku Docker można monitorować kontenery:
Docker Host
|
+--> Container A
+--> Container B
+--> Container C
|
v
Metrics
|
v
Prometheus
Interesujące są m.in.:
- CPU,
- RAM,
- network,
- filesystem,
- restart count.
Prometheus + aplikacja
Prometheus nie jest ograniczony do infrastruktury.
Aplikacja może udostępniać własne metryki:
Application
|
+--> requests_total
+--> errors_total
+--> request_duration
|
v
/metrics
Prometheus je pobiera.
RED Method
W monitoringu aplikacji często wykorzystuje się metodę RED:
R – Rate
E – Errors
D – Duration
Czyli:
Requests/sec
Errors/sec
Latency
Przykładowo:
Requests: 1500/s
Errors: 2/s
p95: 120 ms
To daje znacznie lepszy obraz działania aplikacji niż samo CPU.
Monitoring HTTP
Możemy monitorować:
HTTP Requests
|
+--> 2xx
+--> 4xx
+--> 5xx
|
+--> Latency
Przykładowo alarm:
HTTP 5xx > 5%
może oznaczać poważny problem aplikacji.
Histogramy
Prometheus szczególnie dobrze nadaje się do analizowania rozkładów wartości, np. czasu odpowiedzi.
Request latency
0–50 ms █████████████
50–100 ms █████████
100–250 ms ████
250–500 ms ██
500ms+ █
Dzięki histogramom można analizować m.in. percentyle:
p50
p90
p95
p99
Prometheus i obserwowalność
W nowoczesnej infrastrukturze warto rozdzielić:
Metrics
Logs
Traces
czyli:
Observability
|
+----------+----------+
| | |
Metrics Logs Traces
| | |
Prometheus Loki Tempo/Jaeger
|
Grafana
Prometheus odpowiada przede wszystkim za metrics.
Prometheus vs logi
Prometheus:
CPU = 82%
RAM = 74%
Requests = 1500/s
Log:
2026-08-02 18:21:43
ERROR database connection timeout
Oba źródła informacji są potrzebne, ale rozwiązują różne problemy.
Prometheus + Grafana
Jedno z najpopularniejszych połączeń:
Servers
|
v
Prometheus
|
v
Grafana
|
v
Dashboard
Dashboard może prezentować:
CPU ████████░░ 82%
RAM ███████░░░ 71%
Disk █████░░░░░ 52%
Network ██████░░░░ 61%
Monitoring infrastruktury
Przykładowy dashboard:
Infrastructure
├── CPU
├── Memory
├── Disk
├── Network
├── Load
├── Processes
└── Availability
Dla Kubernetes:
Kubernetes
├── Nodes
├── Pods
├── Deployments
├── Containers
├── Restarts
└── API Server
Prometheus a bezpieczeństwo
Prometheus nie jest systemem IDS/IPS.
Nie zastępuje:
- Suricata,
- Snort,
- Zeek,
- EDR,
- SIEM.
Ale może dostarczać bardzo wartościowe metryki bezpieczeństwa.
Przykład:
SSH Connections
|
v
Prometheus
|
v
Abnormal spike
|
v
Alert
Wykrywanie anomalii
Załóżmy, że serwer normalnie wykonuje:
10 SSH connections/hour
nagle:
1500 SSH connections/hour
Może to być sygnał:
- brute force,
- skanowania,
- błędnej konfiguracji,
- kompromitacji.
Prometheus może pomóc wykryć zmianę zachowania.
Prometheus + Node Exporter + Security
Przykładowa architektura:
Linux Server
|
+------------+------------+
| |
Node Exporter Logs
| |
v v
Prometheus SIEM
|
Grafana
|
Alerting
Monitoring i bezpieczeństwo pozostają osobnymi warstwami, ale mogą się uzupełniać.
Prometheus Federation
W większych środowiskach można mieć wiele instancji Prometheusa:
Prometheus EU
|
Prometheus US
|
Prometheus Asia
|
v
Global Prometheus
Pozwala to budować większą infrastrukturę monitoringu.
High Availability
Prometheus może być uruchomiony w wielu instancjach:
Targets
|
+-------+-------+
| |
Prometheus A Prometheus B
| |
+-------+-------+
|
Storage
W większych środowiskach wykorzystuje się dodatkowe rozwiązania do długoterminowego i skalowalnego przechowywania metryk.
Retencja danych
Prometheus przechowuje dane jako time series.
Przykład:
CPU
|
+-- 10:00
+-- 10:01
+-- 10:02
+-- 10:03
...
Dłuższa retencja oznacza większe wymagania dotyczące storage.
Dlatego w dużych środowiskach często stosuje się rozwiązania takie jak:
Prometheus
|
v
Long-term Storage
Prometheus – typowe problemy
Cardinality
To jeden z najważniejszych problemów.
Niebezpieczne może być generowanie ogromnej liczby unikalnych etykiet:
user_id
request_id
session_id
Każda kombinacja labeli może tworzyć kolejną serię czasową.
W efekcie:
10 000 series
↓
1 000 000 series
↓
Storage / RAM pressure
Dlatego trzeba bardzo uważać na high-cardinality labels.
Prometheus nie powinien zbierać wszystkiego
Dobra metryka:
http_requests_total{method="GET",status="200"}
Potencjalnie problematyczna:
http_requests_total{user_id="123456789"}
Jeżeli użytkowników są miliony, liczba serii może gwałtownie wzrosnąć.
Prometheus – najlepsze praktyki
1. Monitoruj to, co ma znaczenie
Nie zbieraj bez potrzeby tysięcy metryk.
2. Kontroluj cardinality
Unikaj dynamicznych wartości w labelach.
3. Twórz sensowne alerty
Nie:
CPU > 80%
dla każdego chwilowego skoku.
Lepiej:
CPU > 90%
FOR 10m
jeżeli odpowiada to rzeczywistemu problemowi.
4. Monitoruj aplikację, nie tylko serwer
CPU może być prawidłowe, podczas gdy:
HTTP 5xx = 20%
5. Monitoruj dostępność
up == 0
jest często ważniejsze niż sama wartość CPU.
Przykładowy stack
Dla małego środowiska:
Linux
|
Node Exporter
|
Prometheus
|
Grafana
|
Alertmanager
Dla Kubernetes:
Kubernetes
|
Prometheus
|
kube-state-metrics
|
node-exporter
|
Grafana
|
Alertmanager
Dla większego środowiska:
Infrastructure
|
+------------+------------+
| | |
Linux Kubernetes Apps
| | |
+------------+------------+
|
Prometheus
|
+-------+-------+
| |
Grafana Alertmanager
|
v
SOC
Prometheus w architekturze bezpieczeństwa
Jeżeli połączymy go z tematami, które omawialiśmy wcześniej:
INTERNET
|
Firewall
|
GeoIP Blocking
|
DNS Filtering
|
TLS Inspection
|
Suricata
|
Zeek
|
Microsegmentation
|
+-------------+-------------+
| | |
Linux Kubernetes Apps
| | |
Exporter Exporters /metrics
| | |
+-------------+-------------+
|
Prometheus
|
Grafana
|
Alertmanager
|
SIEM
To bardzo dobra architektura observability + security.
Prometheus – najważniejsza rzecz
Prometheus odpowiada na pytanie:
„Jak zachowuje się moja infrastruktura i aplikacja w czasie?”
Przykładowo:
CPU
RAM
Disk
Network
Requests
Errors
Latency
Availability
Containers
Pods
Natomiast:
Suricata → Czy występuje podejrzany ruch?
Zeek → Co dzieje się w sieci?
SIEM → Jak połączyć wiele źródeł zdarzeń?
EDR → Co dzieje się na endpointach?
Dlatego Prometheus jest przede wszystkim systemem monitoringu metryk, a nie narzędziem bezpieczeństwa.
Największą wartość daje wtedy, gdy jest częścią większego stosu:
Metrics + Logs + Traces + Security Events
czyli pełnej observability i security telemetry.
Jak Discord integruje się z nowymi technologiami, takimi jak AI, Web3 i rozszerzona rzeczywistość Discord, jedna z najpopularniejszych platform komunikacyjnych Czytaj dalej
Rozszerzenia i dodatki do Firefoksa – Jak wzbogacić doświadczenie przeglądania internetu? Firefox to jedna z najpopularniejszych przeglądarek internetowych, która stawia Czytaj dalej
