fairlane.systems

PROMETHEUS · TECH

Prometheus: CNCF-Time-Series-DB für Metriken, Pull-Modell und PromQL

Prometheus 3.x als CNCF-graduierter Industrie-Standard für Metrik-Sammlung. Pull-Modell, PromQL, Service-Discovery. Self-host, Apache 2.0, KMU-tauglich.

Recherche & Faktencheck: · Stand: 2026-05

Was ist Prometheus?

Prometheus ist eine quelloffene Time-Series-Datenbank speziell für Metriken (Zahlenreihen mit Zeitstempel) und die dazugehörige Abfragesprache PromQL. Das Projekt wurde 2012 bei SoundCloud gestartet, 2016 an die Cloud Native Computing Foundation übergeben und ist seit 2018 CNCF-graduiert – der zweite Status nach Kubernetes selbst. Mai 2026 läuft Prometheus stabil in Version 3.x und ist über die gesamte CNCF-Welt hinweg der De-facto-Standard für Metrik-Sammlung.

Kern-Idee: Prometheus zieht (scrapt) Metriken in regelmässigen Intervallen von HTTP-Endpunkten unter /metrics. Jede Anwendung, jeder Service, jeder Host stellt seine Zahlen in einem einfachen Textformat bereit. Prometheus speichert die Werte intern in einer TSDB (Time-Series-Database), die auf hohe Schreib-Raten und kompakten Speicher optimiert ist. Eine 25-Container-Instanz mit 30 Tagen Retention verbraucht typischerweise 6 bis 10 GB Disk.

Prometheus ersetzt keine SQL-Datenbank – es ist eine sehr spezialisierte Komponente. Für Logs (Volltext) ist Loki oder Elasticsearch zuständig, für Traces eher Jäger, Tempo oder SigNoz. Prometheus deckt den Bereich "Zahlen über die Zeit" ab: CPU-Last, RAM-Nutzung, HTTP-Latenz, Anzahl ausgelöste Mahnungen pro Stunde, Anzahl LLM-Requests pro Provider. Genau diese Klasse von Daten wird mit Prometheus extrem effizient gespeichert und über PromQL ausgewertet.

Lizenz: Apache 2.0 – keine kommerzielle Klausel, keine Open-Core-Limitierung, vollständig self-hostbar ohne Sternchen. Das ist einer der Hauptgründe für die breite Industrie-Adoption: weder Vendor-Lock-in noch Lizenz-Risiko bei kommerzieller Nutzung.

Warum es zählt

Für ein Schweizer KMU löst Prometheus drei harte Probleme gleichzeitig: Datenort, Kosten, Industrie-Standard.

Datenort: Prometheus läuft komplett self-hosted auf Hetzner Falkenstein oder Helsinki. Mandanten-Metriken (Anzahl Logins, Anzahl bearbeiteter Mandate, API-Latenzen) verlassen die EU/CH nie. Damit ist die revDSG-Forderung nach "angemessener Sicherheit" formal und praktisch erfüllbar – anders als bei US-SaaS-Diensten, die zumindest eine Daten-Transfer-Folgenabschätzung verlangen.

Kosten: Apache 2.0 bedeutet null Lizenzkosten. Ein CPX21 bei Hetzner (4 GB RAM, 3 vCPU, ca. CHF 12 pro Monat) trägt Prometheus plus Grafana plus Loki für ein typisches KMU-Setup. Datadog vergleichbar startet bei USD 15 pro Host pro Monat, für 5 Hosts also USD 75 – bevor Logs und Traces überhaupt eingerechnet sind.

Industrie-Standard: PromQL ist die mit Abstand am breitesten verstandene Metriken-Abfragesprache. Jeder erfahrene DevOps-Engineer kennt sie. Bei einem Personalwechsel ist das Wissen also portabel – ein wichtiger Faktor für KMU, die nicht von einem einzigen Mitarbeiter abhängig sein möchten. Auch Cloud-Anbieter (AWS Managed Prometheus, Google Cloud Monitoring, Grafana Cloud) sprechen alle PromQL – eine spätere Migration in die Cloud ist ohne Code-Änderung möglich.

Für Treuhand- und Anwaltskanzleien mit Berufsgeheimnis nach StGB Art. 321 ist Prometheus zudem die ehrlichere Wahl: kein US-Cloud-Anbieter, keine Subpoena-Risiken, keine Auftragsverarbeitungs-Diskussionen. Alles bleibt im eigenen Rechenzentrum oder bei einem EU-Hoster mit klaren Vertragsbedingungen.

Wie es funktioniert

Prometheus läuft als einzelner Go-Prozess. Konfiguration in einer YAML-Datei (prometheus.yml), Daten in einem lokalen Verzeichnis (data/). Kein externer Storage-Layer, keine Replikation in der Basis-Installation (für HA: zwei parallele Prometheus-Instanzen scrapen denselben Set oder via Thanos/Cortex).

Datenfluss: (1) Zielanwendung exportiert Metriken unter /metrics als simpler HTTP-Endpoint im Text-Format. (2) Prometheus liest die scrape_configs in der YAML und pollt jeden Endpoint im konfigurierten Intervall (Standard 15s). (3) Werte landen in der lokalen TSDB. (4) Grafana oder ein anderes Frontend fragt Prometheus via PromQL ab.

docker-compose.yml-Beispiel für ein KMU-Setup:

```yaml services: prometheus: image: prom/prometheus:v3.0.0 volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prom-data:/prometheus command: - --config.file=/etc/prometheus/prometheus.yml - --storage.tsdb.retention.time=30d - --storage.tsdb.retention.size=10GB ports: ["9090:9090"] restart: unless-stopped volumes: prom-data: ```

Service-Discovery: Statt jeden Endpunkt einzeln zu listen, kann Prometheus via Docker, Kubernetes, Consul oder einer einfachen file_sd_configs-Datei automatisch neue Targets aufnehmen. Für ein KMU mit 10 bis 25 Containern reicht oft static_configs oder docker_sd_configs.

PromQL ist die Abfragesprache. Beispiele: `rate(http_requests_total[5m])` (Requests pro Sekunde, gemittelt über 5 Minuten), `histogram_quantile(0.95, http_duration_bucket)` (P95-Latenz), `up == 0` (welche Services antworten nicht). Damit lassen sich Dashboards in Grafana und Alert-Regeln formulieren.

Alerts: Prometheus evaluiert Alert-Regeln und reicht sie an Alertmanager weiter. Alertmanager gruppiert, dedupliziert und sendet an Receiver (Telegram, Slack, E-Mail). Bei Fairlane läuft das so: 4 Critical-Alerts (Service down, Disk voll, Backup fehlgeschlagen, Cert abgelaufen) gehen direkt auf Telegram, 12 Warn-Alerts sammeln sich im Daily-Digest.

Setup in 5 Schritten

  1. 01docker-compose-Datei mit prometheus:v3.0 anlegen, Volume für Daten persistieren, Retention auf 30 Tage und 10 GB Disk-Limit setzen.
  2. 02prometheus.yml mit scrape_configs schreiben: node-exporter:9100 für Host-Metriken, cadvisor:8080 für Container, plus /metrics pro App.
  3. 03Service-Discovery aktivieren (docker_sd_configs oder file_sd_configs), damit neue Container automatisch aufgenommen werden.
  4. 04Alert-Rules in rules.yml definieren, Alertmanager-Receiver konfigurieren (Telegram-Bot, Slack-Webhook oder SMTP).
  5. 05Grafana danebenstellen, Prometheus als Datasource anbinden, Community-Dashboard 1860 (Node-Exporter) und 893 (Docker) importieren.

Wann Prometheus einsetzen

Prometheus ist die richtige Wahl, wenn Metriken über die Zeit beobachtet werden sollen und mindestens eine der folgenden Bedingungen gilt: (a) Self-Hosting ist gewünscht oder vorgeschrieben, (b) das Setup hat mindestens 5 Container oder Hosts, (c) ein Grafana-Dashboard ist geplant, (d) Alerts auf Schwellwerte sind nötig.

Konkrete Fälle: Eine n8n-Plattform mit 20+ Workflows, von denen einige geschäftskritisch sind. Eine RAG-Pipeline mit Qdrant, deren Latenz beobachtet werden muss. Ein LiteLLM-Gateway mit mehreren LLM-Providern, wo Provider-Latenz und Fehlerquote sichtbar sein soll. Ein Treuhand-System mit Mahnung-Cron-Jobs, deren Erfolg gemessen werden muss. Eine Anwaltskanzlei mit eigenen Express-APIs, deren Antwortzeit für SLAs relevant ist.

Bei Fairlane überwacht Prometheus seit 2023 produktiv: 25 Docker-Container, 21 PM2-Services, 12 Cron-Jobs, 6 PostgreSQL-Datenbanken. Setup-Aufwand war 3 Tage, laufender Wartungsaufwand ca. 2 Stunden pro Monat (Retention-Anpassung, Alert-Tuning, Dashboard-Updates).

Wann NICHT

Prometheus ist die falsche Wahl, wenn (a) nur eine einzelne Stand-Seite überwacht werden soll – Uptime Kuma reicht, (b) das Team unter 1 Person liegt und Self-Hosting-Wartung nicht leistbar ist – Grafana Cloud Free reicht, (c) Logs oder Traces das eigentliche Bedarfsfeld sind – Loki bzw. SigNoz sind dann passender, (d) sehr hohe Cardinality (Millionen Labels) erwartet wird – VictoriaMetrics ist hier deutlich effizienter.

Fallen: Prometheus-Retention auf 180 Tage ohne Disk-Monitoring – Prometheus füllt den Host selbst. Alle Metriken mit hoher Cardinality labeln (Mandanten-ID auf jeder Metrik) – TSDB-Index explodiert. Alerts ohne Severity-Tagging – Alert-Fatigue nach zwei Wochen, das Team ignoriert alle Telegram-Nachrichten. Prometheus als Logs-Datenbank missbrauchen – sehr langsam, dafür nicht gemacht.

Nicht-empfohlene Mischsetups: Prometheus plus Datadog parallel – doppelte Kosten, doppelte Konfiguration. Prometheus ohne Grafana – die UI von Prometheus selbst ist eine Debugging-Konsole, kein Dashboard. Wer Prometheus einsetzt, sollte Grafana mitplanen.

Vor- und Nachteile

STÄRKEN

  • Apache 2.0 ohne Open-Core-Klausel, vollständig self-hostbar
  • CNCF-graduiert, breiter Industrie-Standard, Wissen ist portabel
  • Pull-Modell mit eingebauter Erreichbarkeits-Prüfung (up-Metrik)
  • Riesiges Exporter-Ökosystem (node, blackbox, mysql, redis, nginx, ...)

SCHWÄCHEN

  • Single-Node ohne eingebaute Replikation – HA braucht Thanos oder Cortex
  • PromQL hat eine echte Lernkurve, nicht "klick und fertig"
  • High-Cardinality-Labels (Mandanten-ID auf jeder Metrik) sprengen die TSDB
  • Pure-Metrik-Fokus – für Logs/Traces braucht es Companion-Tools (Loki, Tempo)

Häufige Fragen

Wieso Pull statt Push?

Pull hat zwei Vorteile für KMU-Setups. Erstens: Prometheus weiss von jedem Ziel-Endpunkt, ob er noch antwortet – die Metrik `up == 0` ist eingebaut. Bei Push-Modellen müssen Heartbeats separat behandelt werden. Zweitens: kein Zugang zu Authentifizierungs-Token nötig – Prometheus pollt einfach. Für ephemere Jobs (Cron, kurze Skripte) gibt es Pushgateway als Push-Bridge.

Wie skaliert Prometheus bei 100+ Hosts?

Ein einzelner Prometheus-Knoten reicht für ein paar hundert Targets und einige Millionen aktive Zeitreihen. Darüber hinaus skaliert Prometheus horizontal durch Federation (mehrere Prometheus-Instanzen pro Region) oder durch Thanos/Cortex/Mimir (Cluster-Layer mit S3-Storage). Für KMU bis 50 Hosts reicht ein einzelner Knoten ohne weiteres.

Was unterscheidet Prometheus von InfluxDB?

Beide sind Time-Series-DBs. Prometheus ist Pull-basiert mit PromQL, optimiert für Service-Monitoring. InfluxDB ist Push-basiert mit Flux/InfluxQL, eher für IoT-Sensor-Daten und Anwendungs-Telemetrie. Prometheus dominiert in der CNCF-Welt (Kubernetes, Docker), InfluxDB in IoT und Edge-Computing. Für ein Container-KMU-Setup ist Prometheus die naheliegende Wahl.

Ist Prometheus 3.x kompatibel zu 2.x?

Im wesentlichen ja. Prometheus 3 hat das alte 1.x-API-Format ausgemustert, ist deutlich speichereffizienter und verarbeitet PromQL leicht strenger (einige edge-cases sind nun explizit). Die TSDB ist binär kompatibel – direktes Upgrade von 2.x auf 3.x ohne Datenverlust ist Standard. Konfigurations-YAML bleibt mit minimalen Änderungen gültig.

Verwandte Themen

GRAFANA · TECH-STACKGrafana, Prometheus, Loki: Monitoring-Stack für Container-Apps und LLM-WorkflowsLOKI · TECHLoki: Log-Aggregation als KMU-freundliche Elasticsearch-AlternativeMONITORING / TOOL-VERGLEICHMonitoring & Observability im Vergleich: Grafana, Loki, Uptime Kuma, Netdata, Zabbix, Datadog, Sentry, ELK, VictoriaMetrics, SigNozMANAGED · SERVICEManaged Service & Monitoring: Wir betreiben es weiter, Sie nutzen esLOGGING · SICHERHEIT & BETRIEBLogging und Audit-Trail: revisionsfeste Protokollierung nach OR Art. 957a für KMUDOCKER · TECH-STACKDocker-Orchestrierung für KMU: docker-compose ohne Kubernetes-Overkill

Quellen

  1. Prometheus – Documentation and PromQL · 2026-05
  2. CNCF – Prometheus graduated project · 2026-04
  3. Prometheus 3 – Release notes and migration · 2026-03
  4. Grafana Labs – Prometheus best practices · 2026-04

PASSEND ZU IHREM STACK?

Wie das in Ihrem Betrieb konkret aussieht – 30 Minuten Erstgespräch.

Erstgespräch buchen