Was ist der Unterschied zu Uptime Kuma?

Uptime Kuma beantwortet „läuft es?“. Prometheus und Grafana beantworten „warum ist es langsam, und seit wann?“ – CPU, Speicher, Festplatte, Netzwerk und App-Metriken im Zeitverlauf. Viele betreiben beides: Kuma für Ausfall-Alarme, Grafana für Trends und Kapazitätsplanung.

Wie viel Speicher braucht Prometheus?

Grob 1–2 Byte pro Messwert nach der Kompression. Zehn Server mit je tausend Zeitreihen, alle 15 Sekunden abgefragt, ergeben rund 60 Millionen Messwerte pro Tag – in der Größenordnung von 100 MB. Mit der Standard-Aufbewahrung von 15 Tagen sind das ein paar Gigabyte.

Welchen Tarif sollte der Monitoring-Server haben?

Micro-IP (2 GB RAM, $10/Monat) überwacht ein bis zwei Dutzend Hosts bequem. Kommen App-Metriken mit hoher Kardinalität dazu oder willst du Monate an Daten behalten, wechsle zu Small-IP. Eine eigene IP gibt dir HTTPS für Grafana und eine feste Adresse für die Whitelist auf deinen Zielservern.

Sollte der Monitoring-Server getrennt von dem sein, was er überwacht?

Ja. Läuft Grafana auf dem Server, dem gerade der Speicher ausgegangen ist, verlierst du den Blick auf das Problem genau dann, wenn du ihn brauchst. Ein kleiner separater VPS läuft weiter, wenn ein Produktivserver es nicht tut.

VPS für Grafana + Prometheus: Server-Monitoring

Q: Kann ich Server mit NAT-Tarif überwachen?

Ja, aber nicht per Scraping – ein NAT-Server nimmt keine eingehenden Verbindungen zu seinem Exporter an. Lass auf der NAT-Maschine Prometheus im Agent-Modus laufen und schieb die Metriken per remote_write an deinen Monitoring-Server. Der Monitoring-Server selbst sollte einen Tarif mit eigener IP haben.

CPU, RAM, Festplatte und Dienst-Metriken aller Server an einem Ort: Prometheus, node_exporter und Grafana auf einem VPS, hinter HTTPS.

„Der Server ist langsam“ ist ein nutzloser Bugreport – außer du kannst einen Graphen öffnen und sehen, dass der Speicher drei Tage lang vor dem Absturz gestiegen ist. Genau das liefern Prometheus und Grafana: CPU, RAM, Festplatte und Netzwerk jedes Servers, alle 15 Sekunden aufgezeichnet und als Diagramme dargestellt, in denen du zurückscrollen kannst. Stell sie auf einen eigenen kleinen VPS, und sie beobachten weiter, auch wenn ein Produktivserver umfällt.

Die Bausteine

node_exporter auf jedem Server, den du beobachten willst – stellt Systemmetriken auf Port 9100 bereit.
Prometheus auf dem Monitoring-VPS – holt (scrapt) diese Metriken und speichert sie.
Grafana – die Dashboards, hinter HTTPS.
Optional Alertmanager oder Grafana-Alerting, das dich benachrichtigt, wenn etwas eine Grenze überschreitet.

Was du brauchst

Micro-IP ($10/Monat, 2 vCPU, 2 GB RAM, 25 GB) überwacht ein bis zwei Dutzend Server. Mehr Hosts, eigene App-Metriken oder monatelange Aufbewahrung: Small-IP.
Eine eigene IPv4 für den Monitoring-Server – Grafana wird per HTTPS ausgeliefert, und deine Zielserver können Port 9100 für eine feste Adresse freigeben.

1. node_exporter auf jedem Zielserver

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

Ersetze 203.0.113.10 durch die Adresse deines Monitoring-VPS. Lass 9100 nie für die ganze Welt offen – der Port verrät viel über deinen Server.

2. Prometheus und Grafana auf dem 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 vor Grafana:

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

Melde dich an (admin / admin, danach ändern), füge Prometheus als Datenquelle unter http://prometheus:9090 hinzu und importiere das Community-Dashboard „Node Exporter Full“ (ID 1860). In etwa einer Minute hast du ein komplettes System-Dashboard.

Server mit NAT-Tarif

Ein NAT-Server nimmt eingehende Verbindungen nur auf seinem persönlichen SSH-Port an, Prometheus kann seinen Exporter also nicht abfragen. Dreh die Richtung um: Lass auf der NAT-Maschine Prometheus im Agent-Modus laufen und schieb die Daten an den Monitoring-Server, der Remote Writes bereits annimmt (das Flag --web.enable-remote-write-receiver oben).

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

Stell diesen Push-Endpunkt über Caddy mit Basic Auth bereit, statt Port 9090 roh zu öffnen.

Ehrliche Hinweise

Prometheus holt sich die Daten selbst – ideal für eine Flotte unter deiner Kontrolle, umständlich für alles hinter NAT, daher der Agent-Trick. Sein lokaler Speicher ist nicht für Jahre an Historie gedacht; für lange Aufbewahrung kommt später ein Remote-Store dazu. Und Dashboards sind nur die halbe Miete: Richte am ersten Tag mindestens drei Alarme ein (Festplatte über 85 %, Speicherdruck, Ziel nicht erreichbar), sonst schaust du dir die Graphen erst an, wenn schon etwas kaputt ist.