Czym to się różni od Uptime Kuma?

Uptime Kuma odpowiada na pytanie „czy działa?”. Prometheus i Grafana odpowiadają na „dlaczego jest wolno i od kiedy?”: metryki CPU, pamięci, dysku, sieci i aplikacji w czasie. Wiele osób używa obu: Kuma do alertów o awariach, Grafana do trendów i planowania zasobów.

Ile miejsca zajmuje Prometheus?

Mniej więcej 1–2 bajty na próbkę po kompresji. Dziesięć serwerów eksportujących po tysiąc serii, odpytywanych co 15 sekund, daje około 60 milionów próbek dziennie: rząd wielkości 100 MB. Przy domyślnej retencji 15 dni to kilka gigabajtów.

Jaki plan powinien mieć serwer monitorujący?

Micro-IP (2 GB RAM, $10/mies.) wygodnie obsłuży kilkanaście–dwadzieścia kilka hostów. Jeśli dodasz metryki aplikacji o wysokiej kardynalności albo trzymasz miesiące danych, przejdź na Small-IP. Dedykowane IP daje HTTPS dla Grafany i stały adres do wpisania na białą listę na monitorowanych maszynach.

Czy serwer monitorujący powinien być oddzielony od tego, co monitoruje?

Tak. Jeśli Grafana działa na serwerze, któremu właśnie skończyła się pamięć, tracisz wgląd w problem dokładnie wtedy, gdy go potrzebujesz. Mały, osobny VPS działa dalej, gdy maszyna produkcyjna pada.

VPS do monitorowania serwerów: Grafana + Prometheus

Q: Czy mogę monitorować serwery na planach NAT?

Tak, ale nie przez odpytywanie: serwer NAT nie przyjmuje połączeń przychodzących do swojego eksportera. Uruchom Prometheusa w trybie agenta na maszynie NAT i wysyłaj metryki na serwer monitorujący przez remote_write. Sam serwer monitorujący powinien być na planie z dedykowanym IP.

Zbieraj w jednym miejscu metryki CPU, RAM, dysku i usług ze wszystkich swoich serwerów: Prometheus, node_exporter i Grafana na VPS-ie, za HTTPS.

„Serwer jest wolny” to bezużyteczne zgłoszenie błędu, chyba że możesz otworzyć wykres i zobaczyć, że pamięć rosła przez trzy dni przed awarią. To właśnie dają ci Prometheus i Grafana: CPU, RAM, dysk i sieć każdego serwera, zapisywane co 15 sekund i rysowane na wykresach, które możesz przewijać wstecz. Postaw je na osobnym małym VPS-ie, a będą obserwować dalej, nawet gdy maszyna produkcyjna się przewróci.

Elementy

node_exporter na każdym serwerze, który chcesz obserwować: udostępnia metryki systemowe na porcie 9100.
Prometheus na VPS-ie monitorującym: odpytuje (scrape) te metryki i je przechowuje.
Grafana: panele, za HTTPS.
Opcjonalnie Alertmanager albo alerty Grafany, żeby dać ci znać, gdy coś przekroczy próg.

Czego potrzebujesz

Micro-IP ($10/mies., 2 vCPU, 2 GB RAM, 25 GB) obserwuje kilkanaście–dwadzieścia kilka serwerów. Więcej hostów, własne metryki aplikacji albo miesiące retencji: Small-IP.
Dedykowanego IPv4 dla serwera monitorującego: Grafana jest serwowana przez HTTPS, a monitorowane maszyny mogą wpuścić na port 9100 jeden stały adres.

1. node_exporter na każdej maszynie

apt install -y prometheus-node-exporter
# allow only the monitoring server to scrape it
ufw allow from 203.0.113.10 to any port 9100 proto tcp

Zamień 203.0.113.10 na adres swojego VPS-a monitorującego. Nigdy nie zostawiaj portu 9100 otwartego na świat: zdradza bardzo dużo o twoim serwerze.

2. Prometheus i Grafana na VPS-ie monitorującym

apt update && apt install -y docker.io docker-compose-v2 caddy
mkdir -p /opt/monitoring && cd /opt/monitoring

cat > prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: nodes
    static_configs:
      - targets: ['198.51.100.21:9100', '198.51.100.22:9100']
EOF

cat > compose.yml <<'EOF'
services:
  prometheus:
    image: prom/prometheus
    volumes: [ "./prometheus.yml:/etc/prometheus/prometheus.yml:ro", "prom:/prometheus" ]
    command: [ "--config.file=/etc/prometheus/prometheus.yml", "--storage.tsdb.retention.time=15d", "--web.enable-remote-write-receiver" ]
    ports: [ "127.0.0.1:9090:9090" ]
    restart: unless-stopped
  grafana:
    image: grafana/grafana
    volumes: [ "grafana:/var/lib/grafana" ]
    ports: [ "127.0.0.1:3000:3000" ]
    restart: unless-stopped
volumes: { prom: {}, grafana: {} }
EOF

docker compose up -d

HTTPS przed Grafaną:

echo 'grafana.example.com {
    reverse_proxy 127.0.0.1:3000
}' > /etc/caddy/Caddyfile && systemctl reload caddy

Zaloguj się (admin / admin, potem zmień hasło), dodaj Prometheusa jako źródło danych pod http://prometheus:9090 i zaimportuj społecznościowy panel „Node Exporter Full” (ID 1860). W około minutę masz kompletny panel systemowy.

Serwery na planach NAT

Serwer NAT przyjmuje połączenia przychodzące tylko na swoim osobistym porcie SSH, więc Prometheus nie może odpytać jego eksportera. Odwróć kierunek: uruchom Prometheusa w trybie agenta na maszynie NAT i wysyłaj dane na serwer monitorujący, który już przyjmuje zdalne zapisy (flaga --web.enable-remote-write-receiver powyżej).

# /etc/prometheus/agent.yml on the NAT server
scrape_configs:
  - job_name: self
    static_configs: [ { targets: ['127.0.0.1:9100'] } ]
remote_write:
  - url: https://prom-push.example.com/api/v1/write

Wystaw ten punkt przyjmowania danych przez Caddy z basic auth, zamiast otwierać surowy port 9090.

Uczciwe uwagi

Prometheus działa w modelu pull: świetnie dla floty, którą kontrolujesz, niewygodnie dla wszystkiego za NAT-em, stąd sztuczka z agentem. Jego lokalny magazyn nie jest przeznaczony na lata historii; do długiej retencji dodasz później zdalny magazyn. A panele to tylko połowa wartości: ustaw pierwszego dnia przynajmniej trzy alerty (dysk powyżej 85%, presja na pamięć, maszyna niedostępna), bo inaczej zajrzysz na wykresy dopiero wtedy, gdy coś już się zepsuje.

Powiązane

VPS do monitorowania dostępności (Uptime Kuma): alerty o awariach i strony statusu
Jak skonfigurować zaporę UFW
Ile RAM-u potrzebuje VPS?