Vrijdag 14.00 uur is de monitoring groen. CPU op 35%, comfortabel geheugen, schijf ver van het plafond. Support ontvangt echter screenshots: het afrekenen duurt acht seconden, soms langer. Het team opent Grafana, bladert tussen twaalf standaard geïmporteerde dashboards – node_exporter, nginx, enkele applicatietellers – en vindt niets dat stijgt op het moment van klachten.
Dit is geen mislukking van Prometheus. Dit is een fout in de signaalkeuze. Je meet de toestand van de machine, niet het pad dat een commando aflegt als het vertraagt.
Wat Prometheus goed doet — en wat het niet voor jou zal doen
Prometheus slaat tijdreeksen op en bevraagt deze in PromQL. Het is geweldig in het beantwoorden van vragen als "is /api/checkout p95 verdubbeld sinds de implementatie om 11.00 uur?" » of “Is de PostgreSQL-verbindingspool sinds gisteren voortdurend vol?” ".
Het raadt niet welke statistieken u aanbelangen. Voordat u nog een exporteur installeert, stelt u een eenvoudige vraag: Als de site morgen langzaam is, welke curve moet deze dan omhoog gaan zodat het team weet waar te graven? Al het andere is geruststellend geluid.
Een metriek die niet kan antwoorden “langzamer dan gisteren, op welke route?” » wordt alleen gebruikt ter decoratie van een dashboard.
RED, USE en zakelijke statistieken: drie rasters, één bestelling
Drie frames komen vaak voor. Ze sluiten elkaar niet uit: ze stapelen zich op.
| Kader | Vraag | Nuttige voorbeelden |
|---|---|---|
| ROOD | Reageert de dienst snel genoeg en zonder fouten? | http_requests_total, verhouding 5xx, duurhistogram per route |
| GEBRUIK | Is de onderliggende hulpbron verzadigd? | CPU wachtend I/O, schijf, DB-verbindingen inactief = 0 |
| Beroep | Bereikt de gebruiker zijn doel? | checkout_started versus checkout_completed, verlaten winkelwagen |
Voor een dynamische API of site begint u met RED op kritieke routes – niet de hele catalogus. Een latentiehistogram op /api/cart en /api/betaling is beter dan honderd tellers op zelden genoemde beheerderseindpunten.
De USE-methode wordt essentieel zodra RED traagheid vertoont zonder HTTP-fout: de server reageert binnen drie seconden met 200 omdat de database het moeilijk heeft, niet omdat PHP slecht rekent.
Histogrammen: kalibreer buckets op uw SLO, niet op defecten
Een veel voorkomende fout: het kopiëren van generieke buckets (0.005, 0.01, 0.025…) wanneer uw interne SLO zegt: “95% van de betalingsverzoeken < 500 ms”. Slecht gekozen buckets liggen op p95: het berekende kwantiel valt tussen twee buckets en verzacht een echte degradatie.
Voorbeeld van een PromQL-query voor een p95 via route:
histogram_kwantiel(
0,95,
sum(rate(http_request_duration_seconds_bucket[5m])) door (de, route)
)
Pas de buckets aan uw realiteit aan: als de meeste verzoeken onder de 200 ms passen, maar het afrekenen tot 2 seconden kan duren, moeten uw buckets dit bereik bestrijken – en niet alleen de zone onder de seconde.
Waarschuw voor wat de ervaring verbreekt, niet bij willekeurige drempels: p95 checkout > 2 s gedurende tien minuten, DB-pool zonder inactieve verbinding beschikbaar, Redis-bestandsvertraging boven een zakelijke drempel. Een waarschuwing “schijf op 70%” zonder gebruikerscorrelatie voedt alertvermoeidheid zonder de kassa te beschermen.
Etiketten en kardinaliteit: de stille valstrik
Prometheus is geen houtopslagplaats. Elke labelwaarde vermenigvuldigt de tijdreeks. http_requests_total{user_id="8842"} of {url="/product/chaise-rouge-42"} kan een gezonde installatie binnen enkele dagen naar een onbeheersbare TSDB brengen.
Pragmatische regels:
- Routesjabloon ja (
/api/cart/{id}), volledige URL nr. - HTTP-code, methode, omgeving ja; klant-ID nr.
- Gegevens nodig per gebruiker of per bestelling? Sporen of gestructureerde logboeken, geen Prometheus-labels.
Op een bescheiden VPS kost ongecontroleerde kardinaliteit RAM en trage PromQL-query's - wanneer je dit het meest nodig hebt.
Wat u eerst moet instrumenteren, afhankelijk van uw hosting
Op gedeelde of kleine VPS mag u de stack van een hyperscaler niet dupliceren:
- Toepassing — duur per kritieke route, fouten, verzadiging van de DB-pool als u deze beheert.
- Nginx of reverse proxy — upstream-latentie, actieve verbindingen.
- node_exporter — BasisGEBRUIK (CPU, RAM, schijf) om duidelijke verzadiging uit te sluiten.
OpenTelemetry of een native Prometheus-client (Go, Node, PHP met aangepaste bibliotheek) in het hart van de app verslaat een verzameling exotische exporteurs. Vaak is een lokale bewaartermijn van vijftien dagen voldoende; verder zijn Thanos of Mimir alleen zinvol met volume en een toegewijd ops-team.
Vergelijk de aanbiedingen waar u uw eigen agenten kunt installeren via onze overzicht — gedeelde strikte limiet soms Prometheus on-host; een beheerde VPS of cloud biedt meer marge.
Wanneer statistieken niet langer voldoende zijn
Prometheus aggregaat. Eén langzame zoekopdracht op duizend snelle zoekopdrachten kan onzichtbaar blijven in p95. Sporadische traagheid, occasionele Redis-locks, de SQL-query vergeten in een zeldzaam codepad: hier heb je een trace (Tempo, Jaeger) of gecorreleerde logs nodig met een gemeenschappelijke request_id — onderwerp behandeld in Centralized logs.
De drie pijlers vullen elkaar aan:
- Statistieken — trend, waarschuwing, SLO.
- Logboeken — tekstuele context, stacktracering, parameters.
- Traces — pad van een verzoek via services.
Prometheus alleen is niet volledig waarneembaar. Dit is het juiste hulpmiddel voor geaggregeerde signalen, op voorwaarde dat u de juiste signalen heeft gekozen.
De top: de illusie van volledige dashboards
Dit is wat de tutorials “Grafana in tien minuten” weglaten.
Door metrieken te kiezen, gokt u op de plausibele knelpunten in uw architectuur – en verwijdert u de rest van de ruis.
Beslis en ga vooruit zonder blinde vlek
Over een halve dag kunt u Prometheus weer in de diagnostische dienst zetten:
- Geef twee kritieke paden op (afrekenen, inloggen, partner-API) — niet “gehele site”.
- Pas ROOD toe op deze routes: teller, fouten, histogram met uitgelijnde SLO-buckets.
- Voeg een USE-statistiek toe gekoppeld aan de hoofdverdachte (DB-pool, Redis, taakwachtrij).
- Controleer de labels — verwijder alle dimensies met een hoge kardinaliteit.
- Vervang een CPU-waarschuwing door een p95- of verzadigingspoolwaarschuwing; testen onder gesimuleerde belasting.
- Documenteer een PromQL-query die de wachtdienst moet starten bij het eerste incident.
Om hosts te vergelijken waarbij u controle heeft over de installatie (VPS, cloud, gedeeltelijke PaaS), gebruikt u de vergelijker en de gidsen. Als de traagheid ondoorzichtig blijft na het opschonen van de statistieken, ga dan verder met Distributed tracing in plaats van een vijftiende dashboard toe te voegen.
Concrete oefening: simuleer een degradatie (verminderde DB-pool, kunstmatige latentie) en verifieer dat een enkele PromQL-query de defecte laag in minder dan vijf minuten identificeert. Als dat niet het geval is, vertellen uw statistieken nog steeds het verkeerde verhaal.
Veelgestelde vragen
Welke minimale statistieken voor een API?
ROOD: stroom, fouten, duur in histogram. Compleet met de verzadiging van de verbindingspool of de cache als de traagheid daarmee samenhangt – niet alleen de CPU van de server.
Waarom te veel labels vermijden?
Elk label vermenigvuldigt de tijdreeks. Routesjabloon en HTTP-code ja; user_id en volledig URL-nr. Individuele details worden vastgelegd in sporen of logboeken.
Teller, meter of histogram — wat te kiezen?
Teller met rate() voor volumes; maatstaf voor onmiddellijke status; histogram voor latenties met buckets die zijn gekalibreerd volgens uw SLO.
Is Prometheus alleen genoeg om traagheid te diagnosticeren?
Voor geaggregeerde trends en waarschuwingen wel. Vul voor sporadische uitschieters aan met gecorreleerde logboeken en sporen. Prometheus is geen vervanging voor regel voor regel onderzoek.
De volgende keer dat een dashboard volledig groen is terwijl gebruikers langzamer gaan rijden, stelt u een vraag: welke statistiek ontbreekt om het verhaal te vertellen van wat ze ervaren? Dit is waar een nuttige Prometheus begint.