Freitag 14 Uhr, die Überwachung ist grün. CPU bei 35 %, komfortabler Speicher, Festplatte weit von der Decke. Der Support erhält jedoch Screenshots: Der Checkout dauert acht Sekunden, manchmal auch länger. Das Team öffnet Grafana, scrollt zwischen zwölf standardmäßig importierten Dashboards – node_exporter, nginx, einige Anwendungszähler – und findet nichts, was zum Zeitpunkt der Beschwerden aufsteigt.
Dies ist kein Versagen von Prometheus. Dies ist ein Fehler bei der Signalwahl. Sie messen den Zustand der Maschine, nicht den Weg, den ein Befehl nimmt, wenn er langsamer wird.
Was Prometheus gut kann – und was nicht
Prometheus speichert Zeitreihen und fragt sie in PromQL ab. Es eignet sich hervorragend zur Beantwortung von Fragen wie „Hat sich „/api/checkout“ p95 seit der Bereitstellung um 11 Uhr verdoppelt?“ » oder „Ist der PostgreSQL-Verbindungspool seit gestern ständig voll?“ ".
Es errät nicht, welche Kennzahlen Sie betreffen. Bevor Sie einen weiteren Exporter installieren, stellen Sie eine einfache Frage: Wenn die Baustelle morgen langsam ist, welche Kurve muss dann nach oben gehen, damit das Team weiß, wo gegraben werden muss? Alles andere ist beruhigendes Geräusch.
Eine Metrik, die nicht antworten kann: „Langsamer als gestern, auf welcher Route?“ » wird nur zur Dekoration eines Armaturenbretts verwendet.
RED, USE und Geschäftsmetriken: drei Raster, eine Bestellung
Es entstehen häufig drei Frames. Sie schließen sich nicht gegenseitig aus – sie stapeln sich.
| Rahmen | Frage | Nützliche Beispiele |
|---|---|---|
| ROT | Reagiert der Dienst schnell genug und fehlerfrei? | „http_requests_total“, Verhältnis 5xx, Dauerhistogramm pro Route |
| VERWENDUNG | Ist die zugrunde liegende Ressource gesättigt? | CPU wartet auf E/A, Festplatte, DB-Verbindungen im Leerlauf = 0 |
| Beruf | Erreicht der Benutzer sein Ziel? | „checkout_started“ vs. „checkout_completed“, verlassener Warenkorb |
Beginnen Sie bei einer dynamischen API oder Site mit ROT auf kritischen Routen – nicht im gesamten Katalog. Ein Latenzhistogramm auf „/api/cart“ und „/api/paid“ ist besser als hundert Zähler auf selten aufgerufenen Admin-Endpunkten.
Die USE-Methode wird unverzichtbar, sobald RED ohne HTTP-Fehler langsam ist: Der Server antwortet in drei Sekunden mit 200, weil die Datenbank Probleme hat, nicht weil PHP schlecht rechnet.
Histogramme: Kalibrieren Sie Buckets anhand Ihres SLO, nicht anhand von Fehlern
Ein häufiger Fehler: Das Kopieren generischer Buckets („0,005“, „0,01“, „0,025“ …), wenn Ihr internes SLO sagt „95 % der Checkout-Anfragen < 500 ms“. Schlecht ausgewählte Buckets liegen auf p95: Das berechnete Quantil liegt zwischen zwei Buckets und glättet eine echte Verschlechterung.
Beispiel einer PromQL-Abfrage für ein p95 nach Route:
„promql histogram_quantile( 0,95, sum(rate(http_request_duration_seconds_bucket[5m])) by (the, route) )
Passen Sie die Buckets an Ihre Realität an: Wenn die meisten Anfragen unter 200 ms passen, der Checkout aber bis zu 2 s dauern kann, müssen Ihre Buckets diesen Bereich abdecken – und nicht nur den Subsekundenbereich.
Warnung darüber, was **das Erlebnis stört**, nicht bei willkürlichen Schwellenwerten: p95-Checkout > 2 s für zehn Minuten, DB-Pool ohne verfügbare Leerlaufverbindung, Redis-Dateiverzögerung über einem geschäftlichen Schwellenwert. Eine „Festplatte bei 70 %“-Warnung ohne Benutzerkorrelation schürt [Alarmmüdigkeit](/de/blog/alertes-fatigue/), ohne die Kasse zu schützen.
## Etiketten und Kardinalität: die stille Falle
Prometheus ist kein Blockhaus. Jeder Labelwert multipliziert die Zeitreihe. „http_requests_total{user_id="8842"}` oder „{url="/product/chaise-rouge-42"}` können eine fehlerfreie Installation innerhalb weniger Tage in eine nicht verwaltbare TSDB überführen.
Pragmatische Regeln:
- **Routenvorlage** ja (`/api/cart/{id}`), vollständige URL-Nr.
- **HTTP-Code, Methode, Umgebung** ja; Kunden-ID-Nr.
- Benötigen Sie Angaben pro Benutzer oder pro Bestellung? **Spuren** oder **strukturierte Protokolle**, keine Prometheus-Labels.
Auf einem bescheidenen VPS kostet unkontrollierte Kardinalität RAM und verlangsamt PromQL-Abfragen – wenn Sie es am meisten brauchen.
## Was je nach Hosting zuerst instrumentiert werden soll
Auf **gemeinsamen oder kleinen VPS** den Stack eines Hyperscalers nicht duplizieren:
1. **Anwendung** – Dauer pro kritischer Route, Fehler, DB-Pool-Sättigung, wenn Sie es verwalten.
2. **Nginx oder Reverse-Proxy** – Upstream-Latenz, aktive Verbindungen.
3. **node_exporter** – Grundlegende NUTZUNG (CPU, RAM, Festplatte), um eine offensichtliche Sättigung auszuschließen.
OpenTelemetry oder ein nativer Prometheus-Client (Go, Node, PHP mit angepasster Bibliothek) im Herzen der App schlägt eine Sammlung exotischer Exporteure. Oft reicht eine lokale Aufbewahrung von fünfzehn Tagen aus; Darüber hinaus machen Thanos oder Mimir nur mit Lautstärke und einem engagierten Einsatzteam Sinn.
Vergleichen Sie die Angebote, bei denen Sie Ihre eigenen Agenten über unser [Verzeichnis](/de/verzeichnis/) installieren können – gemeinsames striktes Limit, manchmal Prometheus auf dem Host; Ein verwalteter VPS oder eine Cloud eröffnet mehr Spielraum.
## Wenn Kennzahlen nicht mehr ausreichen
Prometheus **Aggregate**. Eine langsame Abfrage von tausend schnellen kann in p95 unsichtbar bleiben. Sporadische Langsamkeit, gelegentliche Redis-Sperren, vergessene SQL-Abfrage in einem seltenen Codepfad: Hier benötigen Sie einen **Trace** (Tempo, Jaeger) oder **korrelierte Protokolle** mit einer gemeinsamen „request_id“ – Thema, das in [Zentralisierte Protokolle](/de/blog/logs-centralises/) behandelt wird.
Die drei Säulen ergänzen sich:
- **Metriken** – Trend, Warnung, SLO.
- **Protokolle** – Textkontext, Stack-Trace, Parameter.
- **Traces** – Pfad einer Anfrage durch Dienste.
Prometheus allein ist keine vollständige Beobachtbarkeit. Dies ist das richtige Tool für aggregierte Signale – vorausgesetzt, Sie haben die richtigen Signale ausgewählt.
## Der Gipfel: die Illusion vollständiger Dashboards
Folgendes wird in den „Grafana in zehn Minuten“-Tutorials weggelassen.
:::Höhepunkt
**Das standardmäßige Stapeln der Exporter vermittelt die Illusion, beobachtbar zu sein.** Bei einem Checkout-Fehler sind niedrige CPU-Leistung und grüner Arbeitsspeicher beruhigend – während ein erschöpfter Verbindungspool oder eine fehlende Redis-Sperre in Ihren Diagrammen dennoch alle Zeitüberschreitungen erklären. Das Problem ist nicht das Werkzeug: Es liegt darin, dass die Anzahl der Kurven mit der Fähigkeit, Langsamkeit zu erklären, verwechselt wurde.
:::
Bei der Auswahl von Metriken setzen Sie auf die plausiblen Engpässe in Ihrer Architektur – und beseitigen den Rest des Rauschens.
## Entscheide dich und gehe ohne blinden Fleck voran
Innerhalb eines halben Tages können Sie Prometheus wieder in den Diagnosedienst einbeziehen:
1. **Listen Sie zwei kritische Pfade auf** (Kaufabwicklung, Anmeldung, Partner-API) – nicht „die gesamte Website“.
2. **Wenden Sie RED** auf diese Routen an: Zähler, Fehler, Histogramm mit SLO-ausgerichteten Buckets.
3. **Fügen Sie eine USE-Metrik hinzu**, die mit dem Hauptverdacht verknüpft ist (DB-Pool, Redis, Jobwarteschlange).
4. **Überprüfen Sie die Beschriftungen** – entfernen Sie alle Dimensionen mit hoher Kardinalität.
5. **Ersetzen Sie eine CPU-Warnung** durch eine p95- oder Sättigungspool-Warnung; Test unter simulierter Belastung.
6. **Dokumentieren Sie eine PromQL-Abfrage**, die der Bereitschaftsdienst beim ersten Vorfall starten muss.
Um Hosts zu vergleichen, bei denen Sie die Kontrolle über die Installation haben (VPS, Cloud, teilweise PaaS), verwenden Sie den [Vergleicher](/de/vergleich/) und die [Anleitungen](/de/ratgeber/). Wenn die Langsamkeit nach bereinigten Metriken weiterhin undurchsichtig bleibt, fahren Sie mit [Verteiltes Tracing](/de/blog/tracing-distribue/) fort, anstatt ein fünfzehntes Dashboard hinzuzufügen.
**Konkrete Übung:** Simulieren Sie eine Verschlechterung (reduzierter DB-Pool, künstliche Latenz) und stellen Sie sicher, dass eine einzelne PromQL-Abfrage die fehlerhafte Schicht in weniger als fünf Minuten identifiziert. Wenn nicht, erzählen Ihre Kennzahlen immer noch die falsche Geschichte.
## Häufig gestellte Fragen
### Welche Mindestmetriken für eine API?
ROT: Fluss, Fehler, Dauer im Histogramm. Schließen Sie die Sättigung des Verbindungspools oder des Caches ab, wenn die Langsamkeit damit zusammenhängt – nicht nur die Server-CPU.
### Warum zu viele Labels vermeiden?
Jede Beschriftung vervielfacht die Zeitreihe. Routenvorlage und HTTP-Code ja; Benutzer-ID und vollständige URL-Nr. Einzelne Details gehen in Spuren oder Protokolle ein.
### Zähler, Messgerät oder Histogramm – was soll man wählen?
Zähler mit „rate()“ für Volumina; Anzeige für den momentanen Status; Histogramm für Latenzen mit Buckets, die auf Ihr SLO kalibriert sind.
### Reicht Prometheus allein aus, um Langsamkeit zu diagnostizieren?
Für aggregierte Trends und Warnungen ja. Ergänzen Sie bei sporadischen Ausreißern korrelierte Protokolle und Spuren – Prometheus ersetzt nicht die zeilenweise Untersuchung.
---
Wenn ein Dashboard das nächste Mal vollständig grün ist, während die Benutzer langsamer werden, stellen Sie eine Frage: *Welche Kennzahl fehlt, um die Geschichte dessen zu erzählen, was sie erleben?* Hier beginnt ein nützlicher Prometheus.