Wat is het verschil met Uptime Kuma?

Uptime Kuma beantwoordt „is het online?”. Prometheus en Grafana beantwoorden „waarom is het traag, en sinds wanneer?”: metrics van CPU, geheugen, schijf, netwerk en applicaties door de tijd. Veel mensen draaien beide: Kuma voor storingsmeldingen, Grafana voor trends en capaciteitsplanning.

Hoeveel schijfruimte gebruikt Prometheus?

Ongeveer 1–2 bytes per sample na compressie. Tien servers die elk duizend reeksen exporteren, elke 15 seconden opgehaald, komen op zo'n 60 miljoen samples per dag: in de orde van 100 MB. Met de standaardretentie van 15 dagen is dat een paar gigabyte.

Welk plan moet de monitoringserver hebben?

Micro-IP (2 GB RAM, $10/mnd) kan een tot twee dozijn hosts comfortabel aan. Voeg je applicatiemetrics met hoge cardinaliteit toe of bewaar je maanden aan data, stap dan over op Small-IP. Een dedicated IP geeft je HTTPS voor Grafana en een vast adres om op je doelen te whitelisten.

Moet de monitoringserver los staan van wat hij monitort?

Ja. Als Grafana draait op de server die net zonder geheugen zit, verlies je het zicht op het probleem precies wanneer je het nodig hebt. Een kleine aparte VPS blijft werken als een productiemachine het begeeft.

VPS voor servermonitoring met Grafana + Prometheus

Q: Kan ik servers op NAT-plannen monitoren?

Ja, maar niet door ze op te halen: een NAT-server accepteert geen inkomende verbindingen naar zijn exporter. Draai Prometheus in agent-modus op de NAT-machine en push de metrics met remote_write naar je monitoringserver. De monitoringserver zelf hoort op een plan met dedicated IP.

Verzamel CPU-, RAM-, schijf- en dienstmetrics van al je servers op één plek: Prometheus, node_exporter en Grafana op een VPS, achter HTTPS.

„De server is traag” is een nutteloze bugmelding, tenzij je een grafiek kunt openen en ziet dat het geheugen drie dagen lang opliep voor de crash. Dat is wat Prometheus en Grafana je geven: CPU, RAM, schijf en netwerk van elke server, elke 15 seconden vastgelegd en getekend in grafieken waarin je terug kunt scrollen. Zet ze op een eigen kleine VPS en ze blijven kijken, ook als een productiemachine omvalt.

De onderdelen

node_exporter op elke server die je wilt volgen: stelt systeemmetrics beschikbaar op poort 9100.
Prometheus op de monitoring-VPS: haalt (scrape) die metrics op en slaat ze op.
Grafana: de dashboards, achter HTTPS.
Optioneel Alertmanager of Grafana-alerting om je een bericht te sturen als iets een grens overschrijdt.

Wat je nodig hebt

Micro-IP ($10/mnd, 2 vCPU, 2 GB RAM, 25 GB) houdt een tot twee dozijn servers in de gaten. Meer hosts, eigen app-metrics of maanden retentie: Small-IP.
Een dedicated IPv4 voor de monitoringserver: Grafana wordt via HTTPS geserveerd, en je doelen kunnen één vast adres whitelisten voor poort 9100.

1. node_exporter op elk doel

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

Vervang 203.0.113.10 door het adres van je monitoring-VPS. Laat 9100 nooit open voor de hele wereld: het verraadt veel over je server.

2. Prometheus en Grafana op de monitoring-VPS

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

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

Log in (admin / admin, wijzig het daarna), voeg Prometheus toe als databron op http://prometheus:9090 en importeer het community-dashboard „Node Exporter Full” (ID 1860). In ongeveer een minuut heb je een volledig systeemdashboard.

Servers op NAT-plannen

Een NAT-server accepteert alleen inkomende verbindingen op zijn persoonlijke SSH-poort, dus Prometheus kan zijn exporter niet ophalen. Draai de richting om: draai Prometheus in agent-modus op de NAT-machine en push naar de monitoringserver, die al remote writes accepteert (de vlag --web.enable-remote-write-receiver hierboven).

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

Stel dat push-endpoint beschikbaar via Caddy met basic auth, in plaats van poort 9090 kaal open te zetten.

Eerlijke kanttekeningen

Prometheus werkt met pull: prima voor een vloot die je beheert en lastig voor alles achter NAT, vandaar de agent-truc. De lokale opslag is niet bedoeld voor jaren aan historie; voor lange retentie voeg je later externe opslag toe. En dashboards zijn maar de helft van de waarde: stel op dag één minstens drie alerts in (schijf boven 85%, geheugendruk, doel onbereikbaar), anders kijk je pas naar de grafieken als er al iets kapot is.

Gerelateerd

VPS voor uptime-monitoring (Uptime Kuma): storingsmeldingen en statuspagina's
Een UFW-firewall configureren
Hoeveel RAM heeft een VPS nodig?