Grafana plus Prometheus plus Loki: Monitoring-Stack self-hosted

Monitoring ist im SMB-Umfeld oft ein Stiefkind: entweder fehlt es ganz, oder es läuft ein teures SaaS-Abo, das jährlich teurer wird, je mehr Hosts und Logs hinzukommen. Dabei lässt sich ein vollwertiger Observability-Stack mit Grafana, Prometheus und Loki auf einer einzigen Linux-VM betreiben — inklusive Metriken, Logs, Alarmierung und Dashboards. In diesem Beitrag zeigen wir Ihnen, wie ein solcher Stack 2026 aussieht, welche Storage-Größen Sie für 30 Tage Retention einplanen sollten und welche Stolpersteine wir aus Kundenprojekten kennen.

Die Idee dahinter ist einfach: Prometheus sammelt Metriken (CPU, RAM, Disk, Netzwerk, SMART, SNMP), Loki sammelt Logs (syslog, journald, Container-Logs), Grafana stellt beides dar und alarmiert. Alles als Container, alles versioniert, alles reproduzierbar.

Architektur und Sizing der Monitoring-VM

Für einen typischen SMB-Kunden mit 20 bis 50 zu überwachenden Hosts (Proxmox-Nodes, TrueNAS, OPNsense, Switches, Windows-Server) reicht eine einzelne VM völlig aus. Wir empfehlen eine Debian-12- oder Ubuntu-24.04-LTS-VM auf dem Proxmox-Cluster mit folgender Ausstattung:

Komponente	Sizing	Anmerkung
vCPU	4 Cores	reicht für 50 Targets bei 15s Scrape
RAM	8 GB	Prometheus 3 GB, Loki 2 GB, Grafana 1 GB
Boot-Disk	32 GB	OS, Docker, Compose-Files
Daten-Disk	200—500 GB	TSDB plus Loki-Chunks, siehe Storage-Sizing
Netzwerk	1 GbE	reicht problemlos

Die Daten-Disk legen wir bewusst separat als zweites virtuelles Laufwerk an, damit ein Snapshot der VM nicht den TSDB-Inhalt aufbläht. Auf dem Storage-Layer landet die Daten-Disk idealerweise auf einem ZFS-Pool mit SSDs — die Prometheus-TSDB ist random-write-lastig und mag keine drehenden Platten.

Docker-Compose-Layout

Wir bündeln den kompletten Stack in einem einzigen Compose-File unter /opt/observability/. Das hat den Vorteil, dass Updates, Backups und Restore über einen einzigen Pfad laufen. Die Konfigurationen werden über bind-mounts eingebunden, die Daten liegen auf der separaten Daten-Disk unter /var/lib/observability/.

services:
  prometheus:
    image: prom/prometheus:v3.2.1
    volumes:
      - ./prometheus:/etc/prometheus:ro
      - /var/lib/observability/prometheus:/prometheus
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.retention.time=30d
      - --storage.tsdb.retention.size=120GB
    restart: unless-stopped

  loki:
    image: grafana/loki:3.4.1
    volumes:
      - ./loki/loki-config.yml:/etc/loki/local-config.yaml:ro
      - /var/lib/observability/loki:/loki
    command: -config.file=/etc/loki/local-config.yaml
    restart: unless-stopped

  grafana:
    image: grafana/grafana:11.5.0
    ports:
      - "3000:3000"
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning:ro
      - /var/lib/observability/grafana:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD__FILE=/run/secrets/grafana_admin
    secrets:
      - grafana_admin
    restart: unless-stopped

  snmp-exporter:
    image: prom/snmp-exporter:v0.28.0
    volumes:
      - ./snmp:/etc/snmp_exporter:ro
    restart: unless-stopped

secrets:
  grafana_admin:
    file: ./secrets/grafana_admin.txt

Wichtig: kein ports: für Prometheus und Loki nach außen. Der Zugriff erfolgt ausschließlich über Grafana, und Grafana selbst sitzt hinter einem Reverse-Proxy (Caddy oder Traefik) mit Let’s-Encrypt-Zertifikat und Basic-Auth oder OIDC.

Prometheus-Scrape-Konfiguration in der Praxis

Die prometheus.yml ist das Herzstück. Wir empfehlen eine Trennung in logische Job-Gruppen, statt alles in eine flache Liste zu kippen. Für einen typischen Kunden sieht das so aus:

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    site: neuburg-hq

scrape_configs:
  - job_name: node
    file_sd_configs:
      - files: [/etc/prometheus/targets/node-*.yml]

  - job_name: proxmox-pve
    metrics_path: /pve
    static_configs:
      - targets: [pve01.intern, pve02.intern, pve03.intern]
    params:
      module: [default]

  - job_name: snmp-switches
    static_configs:
      - targets: [sw-core.intern, sw-acc01.intern, sw-acc02.intern]
    metrics_path: /snmp
    params:
      module: [if_mib]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp-exporter:9116

Die Trennung über file_sd_configs hat den Riesenvorteil, dass neue Hosts ohne Prometheus-Reload eingepflegt werden können — ein einfaches echo in die YAML-Datei reicht, Prometheus liest die Targets-Files alle 30 Sekunden neu ein. Für die SNMP-Überwachung von Switches nutzen wir das if_mib-Modul des snmp-exporter, das Interface-Counter, Fehlerzähler und Linkstatus liefert. Mehr zur Netzwerk-Integration finden Sie in unserem Beitrag zu OPNsense.

Loki und promtail für Log-Aggregation

Loki ist der dritte Pfeiler. Anders als ELK indiziert Loki nicht den Log-Inhalt, sondern nur Labels — das macht den Storage-Verbrauch ungefähr um den Faktor 10 kleiner. Für die meisten SMB-Use-Cases (Audit-Logs, Auth-Logs, Container-Logs) reicht das vollkommen. Auf den zu überwachenden Hosts läuft promtail als kleiner Agent, der journald und ausgewählte Dateien an Loki schickt.

Eine schlanke promtail-config.yml auf einem Linux-Host sieht so aus:

server:
  http_listen_port: 9080
positions:
  filename: /var/lib/promtail/positions.yaml
clients:
  - url: http://monitoring.intern:3100/loki/api/v1/push
scrape_configs:
  - job_name: journal
    journal:
      max_age: 12h
      labels:
        job: systemd-journal
        host: ${HOSTNAME}
    relabel_configs:
      - source_labels: [__journal__systemd_unit]
        target_label: unit

Auf TrueNAS-Systemen lassen sich middlewared-Logs und SMB-Auditlogs ebenfalls über promtail abgreifen — spätestens dann, wenn der Kunde eine revisionssichere Nachvollziehbarkeit braucht, ist das Gold wert. Details zur Storage-Plattform finden Sie auf unserer TrueNAS-Seite.

Storage-Sizing für 30 Tage Retention

Die Frage, die wir am häufigsten hören: “Wie groß muss die Daten-Disk sein?” Die Antwort hängt von der Anzahl der Metriken und dem Log-Volumen ab. Aus unseren Projekten haben sich folgende Richtwerte herauskristallisiert:

Komponente	Faustformel	Beispiel 30 Hosts
Prometheus-TSDB	ca. 1,5 KB pro Sample pro Tag, 1500 Series pro Node	~50 GB für 30 Tage
Loki-Chunks	ca. 10 % vom Roh-Log-Volumen nach Kompression	~30 GB bei 10 GB Logs/Tag
Grafana-DB	~500 MB	vernachlässigbar
Puffer und WAL	20 % Reserve	~16 GB
Gesamt-Empfehlung	—	200 GB Daten-Disk

Wichtig: die --storage.tsdb.retention.size in Prometheus sollte ungefähr 60 % der verfügbaren Disk-Größe sein, damit Sie Puffer für WAL, Compaction und unerwartete Lastspitzen haben. Loki begrenzen Sie analog über die retention_period in der Config.

Grafana mit Provisioning — nie wieder Klick-Konfiguration

Der größte Mehrwert kommt erst, wenn Sie Datasources und Dashboards per File-Provisioning ausrollen. Das macht das Setup reproduzierbar, versionierbar in Git und Disaster-Recovery-fähig. Unter ./grafana/provisioning/datasources/datasources.yml:

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    url: http://prometheus:9090
    isDefault: true
  - name: Loki
    type: loki
    url: http://loki:3100

Dashboards werden als JSON-Dateien unter ./grafana/provisioning/dashboards/ abgelegt. Für den Einstieg eignen sich die offiziellen Dashboards mit den IDs 1860 (Node Exporter Full), 10242 (SNMP Interface Detail) und 14055 (Loki Logs). Diese sollten Sie aber an Ihre Label-Schemas anpassen — generische Dashboards funktionieren erfahrungsgemäß nur zu 70 %.

Für die Alarmierung nutzen wir Grafana Unified Alerting mit Kontaktpunkten zu E-Mail und Microsoft Teams. Wichtig sind sinnvolle Hystereseschwellen und for: 10m-Klauseln, sonst flutet der Stack das Postfach.

Backup-Strategie

Der gesamte Stack lebt unter zwei Verzeichnissen: /opt/observability/ (Config, in Git) und /var/lib/observability/ (Daten). Für das Backup reicht ein nächtliches restic-Backup der Daten-Disk, plus ein VM-Snapshot über das Proxmox-Backup. Empfehlung: das Repository der Compose- und Config-Files in einem internen Git verwalten, damit ein Bare-Metal-Rebuild in unter 30 Minuten erledigt ist. Wer schon einen Backup-Workflow für seine Kerninfrastruktur etabliert hat, kann die Monitoring-VM einfach einreihen.

Fazit

Ein self-hosted Monitoring-Stack mit Grafana, Prometheus und Loki ist 2026 keine Bastellösung mehr, sondern eine produktionsreife Alternative zu kommerziellen SaaS-Angeboten. Mit ungefähr 4 vCPU, 8 GB RAM und 200 GB Storage decken Sie ein typisches SMB-Setup mit 30 bis 50 Hosts inklusive 30 Tagen Retention ab. Die Hebel liegen in einem sauberen Compose-Layout, file-basierter Service-Discovery, Provisioning aller Grafana-Inhalte und einer disziplinierten Backup-Strategie. Wer zusätzlich Container-Logs aus einem Kubernetes-Cluster oder TrueNAS-Audits einbindet, bekommt eine vollständige Observability-Plattform für einen Bruchteil der laufenden Kosten eines SaaS-Abos.

DATAZONE unterstützt Sie bei Planung, Aufbau und Betrieb Ihres Monitoring-Stacks — von der initialen VM-Dimensionierung über die Definition sinnvoller Alarmregeln bis zum Dashboard-Tuning für Ihre konkrete Infrastruktur. Sprechen Sie uns an, wir bringen Erfahrung aus Dutzenden Linux-, Proxmox- und TrueNAS-Umgebungen mit. Kontakt aufnehmen.