Einen kleinen VPS mit Prometheus und Grafana überwachen

Monitoring wird oft auf unbestimmte Zeit verschoben, weil es sich anhört, als gehöre es zu einer völlig anderen Größenordnung von Betrieb. Man denkt unweigerlich an ein Dutzend Server, ein dediziertes Operations-Team und riesige Dashboards an der Wand.

Für einen einzigen kleinen VPS, auf dem die Applikation eines Kunden läuft, fühlt sich "Monitoring aufsetzen" wie massiver Overkill an – verglichen damit, sich einfach per SSH einzuloggen und htop aufzurufen, wenn sich etwas langsam anfühlt.

Aber das tatsächliche Setup für einen einzelnen Server ist extrem kompakt. Und der Unterschied zwischen "SSH, wenn sich etwas langsam anfühlt" und "ein präziser Graph der letzten Woche" ist weitaus größer, als der initiale Setup-Aufwand vermuten lässt.

Die Bausteine für einen einzelnen Server

Der node_exporter läuft direkt auf dem Server selbst. Er legt Systemmetriken wie CPU, Arbeitsspeicher, Festplatte und Netzwerk in einem Format frei, das Prometheus nativ versteht:

wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz
tar xzf node_exporter-*.tar.gz
sudo mv node_exporter-*/node_exporter /usr/local/bin/

Ein kleiner systemd-Service hält ihn dauerhaft im Hintergrund am Laufen:

# /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target

[Service]
ExecStart=/usr/local/bin/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target

Prometheus selbst kann für ein Single-Server-Setup auf exakt demselben VPS laufen. Alternativ packt man es auf einen separaten, kleinen Monitoring-VPS, falls das Monitoring einen Totalausfall des zu überwachenden Servers überleben soll. In jedem Fall ist die Konfiguration unglaublich kurz:

# prometheus.yml
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

Grafana verbindet sich dann einfach mit Prometheus als Datenquelle und verwandelt diese rohen Metriken in Dashboards. Das offizielle Community-Dashboard für den node_exporter liefert sofort fertige Graphen für CPU, Memory, Disk und Netzwerk – ohne dass man ein einziges Panel von Grund auf neu bauen müsste.

Was man davon tatsächlich hat

Die offensichtliche Antwort sind natürlich Graphen. Die weitaus nützlichere Antwort ist jedoch Historie.

"Der Server fühlt sich heute langsam an" verwandelt sich in "Die Speicherauslastung ist in den letzten zwei Wochen stetig gestiegen und stößt jetzt ans Limit". Das ist eine völlig andere, unendlich viel verwertbarere Aussage. Ein schleichendes Memory Leak, eine langsam volllaufende Festplatte oder eine schleichende Erhöhung der Load Average bei wachsendem Traffic sind in einem einzelnen htop-Schnappschuss völlig unsichtbar. In einem Wochen-Graphen sind sie schmerzhaft offensichtlich.

Alerting: Der Teil, der sich auch minimal lohnt

Dashboards setzen voraus, dass ein Mensch aktiv darauf schaut. Alerting bedeutet, dass der Server von sich aus Bescheid sagt, wenn etwas schief läuft. Schon ein minimales Alertmanager-Setup mit zwei oder drei festen Regeln deckt die Situationen sicher ab, die bei einem kleinen VPS wirklich zählen:

# alert.rules.yml
groups:
  - name: basic
    rules:
      - alert: DiskSpaceLow
        expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.10
        for: 30m
        annotations:
          summary: "Disk space below 10% on {{ $labels.instance }}"

      - alert: HighMemoryUsage
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) > 0.90
        for: 15m
        annotations:
          summary: "Memory usage above 90% on {{ $labels.instance }}"

Allein diese beiden Regeln fangen die beiden häufigsten "Der Server ist langsam gestorben und niemand hat es gemerkt"-Szenarien ab. Der Alertmanager kann den Alarm dann an E-Mail, Slack oder einen Webhook weiterleiten – also dorthin, wo man es auch tatsächlich bemerkt.

Späteres Skalieren kostet absolut keinen Aufwand

Der mit Abstand beste Grund, das für einen einzelnen Server aufzusetzen, ist die Tatsache, dass sich das Kern-Setup keinen Millimeter ändert, wenn ein zweiter Server dazukommt. Es gibt lediglich einen weiteren scrape_configs-Eintrag und eine weitere node_exporter-Installation.

Es muss später kein massives "Monitoring-Projekt" losgetreten werden. Es gibt keine schmerzhafte Migration von "kein Monitoring" zu "wir überwachen alles". Man hängt lediglich ein weiteres Target an eine Konfigurationsdatei an, die ohnehin schon da ist. Startet man mit einem Server, fügen sich der zweite, dritte und zehnte Server völlig nahtlos in ein perfekt funktionierendes System ein – anstatt der absolute Panikauslöser zu sein, ein solches System unter Druck aus dem Boden stampfen zu müssen.