Grafana, Prometheus, Loki: Monitoring-Stack für Container-Apps und LLM-Workflows

Was ist der Grafana-Stack?

Der Grafana-Stack – oft auch „PLG-Stack" (Prometheus, Loki, Grafana) oder „Grafana LGTM" genannt – ist die selbst gehostete Open-Source-Antwort auf kommerzielle Observability-Produkte wie Datadog, New Relic oder Splunk. Drei Bausteine arbeiten zusammen: Prometheus sammelt und speichert Zeitreihen-Metriken (CPU, RAM, HTTP-Latenz, eigene Geschäftskennzahlen), Loki sammelt und indexiert Logs (mit minimalem Speicheraufwand, da nur Labels indexiert werden), Grafana visualisiert beides in Dashboards und Alerts.

Mai 2026 sind die aktuellen Versionen Grafana 11, Prometheus 3.0 und Loki 3.4. Prometheus 3 hat das alte 1.x-API-Format ausgemustert und ist deutlich speichereffizienter – eine 25-Container-Fairlane-Instanz mit 30 Tagen Retention braucht etwa 8 GB Disk. Loki 3 hat den Single-Binary-Modus stabilisiert; für ein KMU-Setup läuft alles in einem Docker-Container ohne S3-Backend. Grafana 11 bringt einen neuen Scenes-basierten Dashboard-Editor und die in 2025 stabilisierte Alerting-Engine mit nativem PromQL- und LogQL-Support.

Bei Fairlane läuft der gesamte Stack auf demselben Hetzner-Host wie die überwachten Anwendungen, was bewusst ist: Self-Monitoring zählt nicht zur „echten" Observability, aber löst 80% der Probleme zum Preis von 0% laufenden Cloud-Kosten.

Warum es zählt

Ohne Monitoring lebt ein KMU-Betrieb von Mandanten-Anrufen – „Eure Website ist down". Mit Monitoring kommt die Information aus dem System selbst, in der Regel Minuten bevor ein Mandant es bemerkt. Das ist der gesamte Punkt.

Konkret für einen Treuhand- oder KMU-Betrieb: CPU-Spike auf einem Container, der den Backup-Prozess blockiert, wird per Telegram-Alert um 03:00 sichtbar und nicht erst beim Morgenkaffee. Memory-Leak in einem LangChain-RAG-Pipeline-Worker wird sichtbar bevor er den Host erstickt. LLM-Provider-API antwortet langsam und das LiteLLM-Gateway routet automatisch um – der Grafana-Dashboard zeigt diesen Schwenk in Echtzeit. n8n-Workflow scheitert im stillen, weil ein Webhook nicht mehr antwortet – Loki-Query findet die Fehlerzeile in unter zwei Sekunden über 30 Tage Logs.

Für regulierte Sektoren (Treuhand, Anwaltskanzlei mit Mandantengeheimnis) ist Monitoring zusätzlich Compliance-relevant: revDSG verlangt „angemessene Sicherheit" – und ohne Audit-Logs in Loki plus Alerts auf verdächtige Zugriffsmuster ist „angemessen" schwer zu beweisen.

Wie es funktioniert

Der Stack hat vier Datenquellen-Typen, die getrennt eingeleitet und in Grafana zusammengeführt werden.

Host-Metriken via node-exporter. Ein kleiner Daemon auf jedem überwachten Host exportiert CPU, RAM, Disk, Netzwerk, Load und Filesystem-Stats unter /metrics auf Port 9100. Prometheus scrapt alle 15 Sekunden. Damit kommen Standard-Dashboards „Linux Host Overview" und „Disk Capacity" out-of-the-box – Import-ID 1860 für das beliebteste Community-Dashboard.

Container-Metriken via cAdvisor. Ein Container, der auf den Docker-Socket horcht und pro Container CPU/RAM/IO exportiert. Damit ist sichtbar, welcher Container den Host überlastet – nicht nur „CPU auf 80%" sondern „qdrant-prod auf 60% CPU seit 4 Minuten".

App-Metriken via /metrics-Endpoint. Jede selbst geschriebene Node-/Python-/Go-App exportiert eigene Zähler und Histogramme: HTTP-Request-Count, Request-Duration, Business-Events. prometheus-client-Libraries existieren für jede Sprache. Bei Fairlane exportiert n8n native Metriken, LiteLLM über `/metrics`, eigene Express-Apps über das prom-client-Paket.

Logs via Promtail nach Loki. Promtail ist ein Daemon (oder Docker-Logging-Driver), der Container-Logs aufnimmt, mit Labels versieht (container_name, log_level, service) und an Loki sendet. Loki indexiert nur die Labels, nicht den Volltext – das spart 80% Speicher gegenüber Elasticsearch. Queries laufen über LogQL: `{container="n8n"} |~ "error" | json | duration_ms > 1000` findet alle n8n-Errors mit Duration über einer Sekunde.

Alerts via Alertmanager. Prometheus evaluiert Alert-Regeln (PromQL-Ausdrücke); wenn die Bedingung wahr wird, sendet er an Alertmanager. Der gruppiert, dedupliziert und sendet an Receiver – Telegram, Slack, E-Mail, PagerDuty. Bei Fairlane geht alles an einen privaten Telegram-Channel mit Tag-basiertem Routing („urgent" pingt sofort, „info" sammelt sich in Daily-Digest).

Monitoring-Setup in 8 Schritten

1. 01Docker-Compose-Bundle mit Prometheus, Grafana, Loki, Alertmanager, node-exporter, cAdvisor, Promtail in einer monitoring.yml.
2. 02Volumes für Prometheus-Daten, Loki-Daten, Grafana-Dashboards persistieren. Backup-Cron auf Volume-Snapshot.
3. 03Prometheus scrape_configs: node-exporter:9100, cadvisor:8080, plus pro App ein /metrics-Job.
4. 04Loki-Konfig mit Retention 30 Tage, Single-Binary-Mode, filesystem-Backend.
5. 05Promtail mit Docker-Service-Discovery als Logging-Driver oder Sidecar, Labels pro Container.
6. 06Grafana-Datasources Prometheus + Loki anlegen, Community-Dashboard 1860 + 893 (Docker) importieren.
7. 07Alert-Rules in YAML im Git anlegen, über Prometheus-RuleFile laden. Alertmanager-Receiver auf Telegram-Bot.
8. 08Initialphase 2 Wochen: alle Alerts auf „warn", false-positives definieren, dann kritische auf „critical" hochstufen.

Wann den Stack einsetzen

Der Grafana-Stack ist die richtige Wahl, wenn (a) mindestens ein Docker-Container laufzeitkritisch ist, (b) ein gewisser Self-Hosting-Wille besteht und (c) die Kosten von 20+ USD pro Host und Monat für Datadog oder New Relic vermieden werden sollen.

Konkrete Anwendungsfälle: Ein KMU mit 5–25 Containern auf einem oder zwei Hosts. Eine n8n-Plattform mit 20+ Workflows, von denen einige geschäftskritisch sind (Lead-Routing, Mahnung-Erinnerung). Ein RAG-Setup mit Qdrant, dessen Latenz beobachtet werden muss. Ein LiteLLM-Gateway mit mehreren LLM-Providern, wo Provider-Latenz und Fehlerquote pro Provider sichtbar sein soll. Bei Fairlane laufen über den Stack rund 40 Dashboards und 30 Alert-Regeln – Setup-Zeit ca. 3 Tage, laufender Wartungsaufwand etwa 2 Stunden pro Monat.

Wann NICHT

Der selbst gehostete Stack ist die falsche Wahl, wenn (a) eine reine Single-Container-Anwendung ohne KMU-Komplexität überwacht werden soll – dann reicht Uptime Kuma plus die Bordmittel des Cloud-Anbieters, (b) eine Compliance-Anforderung „dedizierter Auditor-Zugang" stellt, der Self-Hosting verbietet, oder (c) das Team unter 2 Personen liegt und Self-Hosting-Wartung nicht leistbar ist – dann ist Grafana Cloud Free (10k Metriken, 50 GB Logs gratis) der ruhigere Pfad.

Weitere Fallen: Prometheus-Retention auf 90 oder 180 Tage konfigurieren, ohne Disk-Wachstum zu monitoren – Prometheus selbst kann den Host füllen. Loki ohne Retention-Policy laufen lassen – Logs wachsen unbegrenzt. Alle Alerts auf „kritisch" stellen – nach zwei Wochen Alert-Fatigue ignoriert das Team das Telegram-Notification-Pattern komplett. Grafana-Dashboards manuell in der UI zusammenbauen und nicht in Git versionieren – bei einem Disk-Crash sind 40 Dashboards weg.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Grafana Labs – Documentation (Grafana 11, alerting, Scenes) · 2026-04
2. Prometheus – Querying, recording rules, alerting (v3.0) · 2026-03
3. Grafana Loki – Best practices for labels and retention · 2026-02
4. OpenTelemetry – Metrics specification and Prometheus exposition · 2026-01