Eine kleine VPS mit Prometheus und Grafana überwachen

Monitoring wird oft aufgeschoben, weil es nach einer anderen Größenordnung klingt, ein Dutzend Server, ein eigenes Ops-Team, Dashboards in einem NOC. Für eine einzelne kleine VPS, auf der die Anwendung eines Kunden läuft, lässt dieser Rahmen "Monitoring einrichten" wie Overkill wirken, verglichen damit, sich einfach per SSH einzuloggen und htop laufen zu lassen, wenn sich etwas langsam anfühlt. Aber das eigentliche Setup für einen einzelnen Server ist klein, und der Unterschied zwischen "per SSH einloggen, wenn sich etwas langsam anfühlt" und "einen Graphen der letzten Woche anschauen" ist größer, als der Setup-Aufwand vermuten lässt.

Die Bausteine, für einen Server

node_exporter läuft auf dem Server selbst und stellt Systemmetriken, CPU, Speicher, Disk, Netzwerk, in einem Format bereit, das Prometheus 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/

Eine kleine systemd-Unit hält es 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 bei einem Single-Server-Setup auf derselben VPS laufen, oder auf einer separaten kleinen Monitoring-VPS, falls es einen schlechten Tag des überwachten Servers überleben soll. In beiden Fällen ist die Konfiguration kurz:

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

Grafana verbindet sich mit Prometheus als Datenquelle und macht aus diesen Metriken Dashboards, das Community-Dashboard für node_exporter (eine bekannte Dashboard-ID, die seit Jahren stabil ist) liefert CPU-, Speicher-, Disk- und Netzwerk-Graphen, ohne etwas von Grund auf bauen zu müssen.

Was das tatsächlich bringt

Die naheliegende Antwort ist Graphen, aber die nützlichere Antwort ist Verlauf. "Der Server fühlt sich heute langsam an" wird zu "die Speichernutzung ist in den letzten zwei Wochen stetig gestiegen und liegt jetzt nahe am Limit", was eine völlig andere, und deutlich handlungsrelevantere, Aussage ist. Ein Memory-Leak, eine sich langsam füllende Disk, ein schleichender Anstieg der Load Average mit wachsendem Traffic, all das ist in einem einzelnen htop-Snapshot unsichtbar und in einem Graphen über eine Woche offensichtlich.

Alerting: der Teil, der sich selbst minimal lohnt

Dashboards setzen voraus, dass sich jemand anschaut. Alerting bedeutet, dass der Server selbst meldet, wenn etwas nicht stimmt. Schon ein minimales Alertmanager-Setup, zwei oder drei Regeln, deckt die Situationen ab, die für eine kleine VPS tatsächlich wichtig sind:

# 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: "Festplattenspeicher unter 10% auf {{ $labels.instance }}"

      - alert: HighMemoryUsage
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) > 0.90
        for: 15m
        annotations:
          summary: "Speichernutzung über 90% auf {{ $labels.instance }}"

Diese zwei Regeln allein fangen die beiden häufigsten "der Server hat sich langsam verschlechtert und niemand hat's bemerkt"-Szenarien ab, und Alertmanager kann das Ergebnis per E-Mail, Slack oder Webhook senden, wohin auch immer schon Aufmerksamkeit geht.

Skalierung kostet später nichts extra

Der Grund, warum sich das selbst für einen Server lohnt, ist, dass sich das Setup nicht ändert, wenn ein zweiter Server dazukommt, er bekommt einfach einen weiteren scrape_configs-Eintrag und eine weitere node_exporter-Installation. Es gibt kein "Monitoring-Projekt", das später angestoßen werden muss, keine Migration von "kein Monitoring" zu "Monitoring", nur ein weiteres Target in einer Config-Datei, die schon da war. Mit einem Server anzufangen bedeutet, dass der zweite, dritte und zehnte Server einem System beitreten, das bereits funktioniert, statt der Auslöser zu sein, eines unter Druck aufzubauen.