Hvordan adskiller det sig fra Uptime Kuma?

Uptime Kuma svarer på »kører den?«. Prometheus og Grafana svarer på »hvorfor er den langsom, og siden hvornår?«: målinger af CPU, hukommelse, disk, netværk og applikationer over tid. Mange kører begge: Kuma til alarmer ved nedbrud, Grafana til tendenser og kapacitetsplanlægning.

Hvor meget disk bruger Prometheus?

Cirka 1–2 byte pr. måling efter komprimering. Ti servere, der hver eksporterer tusind serier, hentet hvert 15. sekund, giver omkring 60 millioner målinger om dagen: i størrelsesordenen 100 MB. Med standardopbevaringen på 15 dage bliver det et par gigabyte.

Kan jeg overvåge servere på NAT-planer?

Ja, men ikke ved at hente data: en NAT-server tager ikke imod indgående forbindelser til sin exporter. Kør Prometheus i agenttilstand på NAT-maskinen og skub målingerne til din overvågningsserver med remote_write. Selve overvågningsserveren bør ligge på en plan med dedikeret IP.

Hvilken plan skal overvågningsserveren have?

Micro-IP (2 GB RAM, $10/md.) klarer komfortabelt et eller to dusin værter. Tilføjer du applikationsmålinger med høj kardinalitet eller gemmer måneders data, så gå op til Small-IP. En dedikeret IP giver dig HTTPS til Grafana og en fast adresse at hvidliste på dine mål.

Skal overvågningsserveren være adskilt fra det, den overvåger?

Ja. Kører Grafana på den server, der lige er løbet tør for hukommelse, mister du overblikket over problemet præcis, når du har brug for det. En lille separat VPS bliver ved med at virke, når en produktionsmaskine går ned.

VPS til serverovervågning med Grafana + Prometheus

Saml CPU-, RAM-, disk- og tjenestemålinger fra alle dine servere ét sted: Prometheus, node_exporter og Grafana på en VPS, bag HTTPS.

»Serveren er langsom« er en ubrugelig fejlrapport, medmindre du kan åbne en graf og se, at hukommelsen steg i tre dage før nedbruddet. Det er, hvad Prometheus og Grafana giver dig: hver servers CPU, RAM, disk og netværk, registreret hvert 15. sekund og tegnet i grafer, du kan rulle tilbage i. Læg dem på deres egen lille VPS, så bliver de ved med at holde øje, også når en produktionsmaskine vælter.

Delene

node_exporter på hver server, du vil holde øje med: udstiller systemmålinger på port 9100.
Prometheus på overvågnings-VPS'en: henter (scraper) målingerne og gemmer dem.
Grafana: dashboards, bag HTTPS.
Valgfrit Alertmanager eller Grafanas alarmer, der giver dig besked, når noget krydser en grænse.

Det skal du bruge

Micro-IP ($10/md., 2 vCPU, 2 GB RAM, 25 GB) holder øje med et eller to dusin servere. Flere værter, egne appmålinger eller måneders opbevaring: Small-IP.
En dedikeret IPv4 til overvågningsserveren: Grafana serveres over HTTPS, og dine mål kan hvidliste én fast adresse til port 9100.

1. node_exporter på hvert mål

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

Erstat 203.0.113.10 med adressen på din overvågnings-VPS. Lad aldrig 9100 stå åben for hele verden: den afslører meget om din server.

2. Prometheus og Grafana på overvågnings-VPS'en

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 foran Grafana:

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

Log ind (admin / admin, skift det derefter), tilføj Prometheus som datakilde på http://prometheus:9090, og importér fællesskabets dashboard »Node Exporter Full« (ID 1860). På omkring et minut har du et komplet systemdashboard.

Servere på NAT-planer

En NAT-server tager kun imod indgående forbindelser på sin personlige SSH-port, så Prometheus kan ikke hente fra dens exporter. Vend retningen: kør Prometheus i agenttilstand på NAT-maskinen og skub til overvågningsserveren, som allerede tager imod fjernskrivninger (flaget --web.enable-remote-write-receiver ovenfor).

# /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

Udstil det modtagende endpoint gennem Caddy med basic auth i stedet for at åbne port 9090 direkte.

Ærlige bemærkninger

Prometheus bygger på pull: fremragende til en flåde, du kontrollerer, og besværligt for alt bag NAT, deraf agenttricket. Den lokale lagring er ikke beregnet til års historik; til lang opbevaring tilføjer du en fjernlagring senere. Og dashboards er kun halvdelen af værdien: opsæt mindst tre alarmer på dag ét (disk over 85 %, hukommelsespres, mål nede), ellers kigger du først på graferne, når noget allerede er gået i stykker.

Relateret

VPS til oppetidsovervågning (Uptime Kuma): alarmer ved nedbrud og statussider
Sådan konfigurerer du UFW-firewallen
Hvor meget RAM kræver en VPS?