Bootcamp backendontwikkeling met FastAPI · Les

Prometheus-metrics en RED/USE-dashboards

Expose latency-, fout- en saturatiemetrics en visualiseer de servicestatus met Grafana-dashboards.

Les 3 van 413 stappen

Prometheus-metrics en RED/USE-dashboards is een gratis Bootcamp backendontwikkeling met FastAPI-les op CoddyKit. Dit is les 3 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Bootcamp backendontwikkeling met FastAPI. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Bootcamp backendontwikkeling met FastAPI bevat in totaal 4 lessen.

Waarom metrics belangrijk zijn

Logs vertellen je wat er is gebeurd tijdens één verzoek; meetwaarden vertellen je hoe de hele service zich gedraagt in de loop van de tijd. Een meetwaarde is een numerieke tijdreeks die met een vast interval wordt bemonsterd. Daardoor is deze goedkoop op te slaan en snel te aggregeren over miljoenen verzoeken.

Voor een FastAPI-backend zijn vooral drie vragen belangrijk:

Verwerkt de service verkeer? verzoekfrequentie
Doet de service het niet goed? foutenfrequentie
Is de service traag? verzoeklatentie

Prometheus is een pull-gebaseerde tijdreeksdatabase: deze haalt periodiek gegevens op van een HTTP-eindpunt /metrics dat je app beschikbaar stelt, slaat de metingen op en laat je ze opvragen met PromQL. Grafana zet die opvragingen vervolgens om in dashboards.

De vier typen meetwaarden

Prometheus heeft vier basistypen meetwaarden. Het kiezen van het juiste type is de belangrijkste modelleringsbeslissing.

Teller — neemt alleen toe (of wordt bij een herstart teruggezet naar 0). Gebruik deze voor totalen: verwerkte verzoeken, fouten, verzonden bytes. Je vraagt de snelheid op, niet de onbewerkte waarde.
Meter — kan toenemen en afnemen. Gebruik deze voor de huidige toestand: verzoeken die momenteel worden verwerkt, geheugengebruik, wachtrijdiepte en de grootte van de verbindingspool.
Histogram — deelt observaties (zoals latentie) in vooraf gedefinieerde bereiken in, plus een _sum en _count. Hiermee kun je kwantielen aan de serverkant berekenen.
Samenvatting — lijkt op een histogram, maar berekent kwantielen aan de clientkant; deze kan niet over instanties heen worden geaggregeerd. Geef voor latentie in gedistribueerde services de voorkeur aan histogrammen.

from prometheus_client import Counter, Gauge, Histogram

REQUESTS = Counter("http_requests_total", "Total HTTP requests", ["method", "path", "status"])
IN_FLIGHT = Gauge("http_requests_in_flight", "Requests currently being served")
LATENCY = Histogram("http_request_duration_seconds", "Request latency in seconds", ["method", "path"])

REQUESTS.labels("GET", "/users", "200").inc()
IN_FLIGHT.inc()
LATENCY.labels("GET", "/users").observe(0.042)
IN_FLIGHT.dec()

print("counter, gauge and histogram updated")

<code>/metrics</code> beschikbaar maken in FastAPI

Om Prometheus je app te laten uitlezen, koppel je een eindpunt dat alle geregistreerde meetwaarden weergeeft in de tekstindeling voor Prometheus. De bibliotheek prometheus_client levert generate_latest() en het juiste inhoudstype.

Je kunt dit handmatig aansluiten, of prometheus-fastapi-instrumentator gebruiken, dat automatisch het aantal verzoeken en de latentie instrumenteert. Door het eerst handmatig te doen, wordt de werking duidelijker.

Vervolgens configureer je Prometheus om met een uitleesinterval (meestal 15s) verbinding te maken met http://your-app:8000/metrics.

from fastapi import FastAPI, Response
from prometheus_client import generate_latest, CONTENT_TYPE_LATEST

app = FastAPI()

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

Labels en kardinaliteit

Met labels maak je van één meetwaarde meerdere tijdreeksen. http_requests_total{method="GET", path="/users", status="200"} is een andere reeks dan dezelfde meetwaarde met status="500".

Kardinaliteit is het aantal unieke combinaties van labels. Dit is veruit de grootste oorzaak van een te hoog geheugengebruik in Prometheus.

Goede labels: begrensde verzamelingen — HTTP-methode, statuscode, routesjabloon.
Gevaarlijke labels: onbegrensde waarden — gebruikers-id's, verzoek-id's, onbewerkte URL's met padparameters en tijdstempels.

Label altijd met het routesjabloon (/users/{id}), niet met het opgeloste pad (/users/4827), anders maakt elke gebruiker nieuwe reeksen.

Middleware om RED-signalen vast te leggen

De duidelijkste manier om elk eindpunt te instrumenteren is één ASGI-middleware die het aantal verzoeken en de latentie registreert, gelabeld met de methode, het routesjabloon en de statuscode.

Let erop dat we request.scope["route"].path (of het overeenkomende padjabloon) uitlezen in plaats van de onbewerkte URL, zodat de kardinaliteit begrensd blijft. Dezelfde drie labels voeden de weergaven voor Rate, Errors en Duration.

import time
from fastapi import FastAPI, Request
from prometheus_client import Counter, Histogram

REQUESTS = Counter("http_requests_total", "Total requests", ["method", "path", "status"])
LATENCY = Histogram("http_request_duration_seconds", "Latency", ["method", "path"])

app = FastAPI()

@app.middleware("http")
async def record_metrics(request: Request, call_next):
    route = request.scope.get("route")
    path = getattr(route, "path", request.url.path)
    start = time.perf_counter()
    response = await call_next(request)
    LATENCY.labels(request.method, path).observe(time.perf_counter() - start)
    REQUESTS.labels(request.method, path, str(response.status_code)).inc()
    return response

De RED-methode

De RED-methode (bekend geworden door Tom Wilkie) is de standaardmanier om verzoekgestuurde services zoals een FastAPI-API te bewaken. Houd voor elke service het volgende bij:

Rate — verzoeken per seconde
Errors — mislukte verzoeken per seconde (of als fractie)
Duration — verdeling van de verzoeklatentie (p50/p95/p99)

RED is verzoekgericht: het beschrijft de ervaring van de aanroepers van je service. Drie dashboardrijen per service — snelheid, foutverhouding en latentiepercentielen — geven je voor elke microservice een consistente, vergelijkbare weergave.

PromQL voor snelheid en fouten

Je vraagt tellers op met rate(). Deze berekent de gemiddelde toename per seconde over een tijdvenster. Het venster (bijvoorbeeld [5m]) moet minstens vier keer zo lang zijn als je uitleesinterval.

Snelheid — totale verzoeken per seconde over alle routes:

sum(rate(http_requests_total[5m]))

Foutverhouding — fractie van de verzoeken die 5xx retourneren:

sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

De operator =~ zoekt met een reguliere expressie, dus "5.." omvat 500, 502, 503 enzovoort. Gebruik by (path) om een resultaat per route uit te splitsen.

PromQL voor latentiepercentielen

Omdat we een histogram hebben gebruikt, slaat Prometheus cumulatieve tellers voor buckets op met de naam http_request_duration_seconds_bucket en een label le ("kleiner dan of gelijk aan"). histogram_quantile() schat een percentiel op basis van die buckets.

p95-latentie over de hele service:

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Je moet de buckets eerst omwikkelen met rate(...) en het label le behouden in de by()-clausule, anders is het kwantiel onjuist. Percentielen (p95/p99) zijn beter dan gemiddelden, omdat een enkele trage staart onzichtbaar blijft in een gemiddelde.

# Default Histogram buckets are tuned for seconds; override for fast APIs:
from prometheus_client import Histogram

LATENCY = Histogram(
    "http_request_duration_seconds",
    "Request latency in seconds",
    ["method", "path"],
    buckets=(0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0),
)

De USE-methode

RED houdt de verzoekstroom in de gaten; de USE-methode (Brendan Gregg) houdt de resources in de gaten die deze verzoeken verwerken. Houd voor elke resource (CPU, geheugen, schijf, verbindingspool en werkthreads) het volgende bij:

Benutting — het percentage van de tijd dat de resource actief was
Verzadiging — hoeveel werk erop wacht in de wachtrij (bijvoorbeeld verzoeken die wachten op een databaseverbinding)
Fouten — foutgebeurtenissen voor die resource

USE vindt problemen die RED mist: als je databaseverbindingspool verzadigd is, neemt de latentie toe voordat de foutenfrequentie stijgt. Een meter voor db_pool_in_use ten opzichte van de poolgrootte is een klassiek verzadigingssignaal voor een FastAPI-app.

from prometheus_client import Gauge

DB_POOL_SIZE = Gauge("db_pool_size", "Configured max DB connections")
DB_POOL_IN_USE = Gauge("db_pool_in_use", "DB connections currently checked out")
DB_POOL_WAITERS = Gauge("db_pool_waiters", "Requests waiting for a connection")

def snapshot_pool(pool):
    DB_POOL_SIZE.set(pool.size())
    DB_POOL_IN_USE.set(pool.checkedout())
    DB_POOL_WAITERS.set(pool.overflow() if pool.overflow() > 0 else 0)

Het Grafana-dashboard bouwen

In Grafana voeg je Prometheus toe als gegevensbron en bouw je vervolgens één dashboard per service met panelen die worden gevoed door de bovenstaande PromQL:

Snelheidspaneel (tijdreeks): sum(rate(http_requests_total[5m])) by (path)
Foutverhoudingspaneel (statistiek / meter): de expressie voor de 5xx-verhouding, opgemaakt als percentage
Latentiepaneel (tijdreeks): p50-, p95- en p99-lijnen uit histogram_quantile
Verzadigingspaneel: db_pool_in_use / db_pool_size

Gebruik sjabloonvariabelen (bijvoorbeeld een vervolgkeuzelijst $path uit label_values(http_requests_total, path)), zodat één dashboard voor elke route werkt. Stel drempelwaarden (groen/oranje/rood) in op de panelen voor fouten en latentie, zodat de gezondheid in één oogopslag duidelijk is.

Alarmering op SLO's

Dashboards zijn bedoeld om door mensen te worden bekeken; waarschuwingen zijn bedoeld om je iets te laten weten. Definieer waarschuwingsregels rechtstreeks in Prometheus (of Grafana) op basis van je RED-meetwaarden, idealiter gekoppeld aan een Service Level Objective.

Een veelgebruikt patroon is een waarschuwing met meerdere tijdvensters en verbrandingssnelheden: laat een waarschuwing afgaan wanneer de foutverhouding over zowel een kort als een lang tijdvenster hoger is dan de verbrandingssnelheid van je foutenbudget. Zo voorkom je zowel voortdurend in- en uitschakelen als trage detectie.

Houd waarschuwingslabels betekenisvol (severity, service), zodat Alertmanager meldingen en tickets correct kan routeren. Waarschuw voor symptomen die gebruikers ervaren (hoge foutverhouding, hoge p99-latentie), niet voor elke interne oorzaak.

groups:
  - name: api-slo
    rules:
      - alert: HighErrorRatio
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.02
        for: 10m
        labels:
          severity: page
        annotations:
          summary: "5xx error ratio above 2% for 10m"

Korte controle

Je labelt een latentiehistogram voor een FastAPI-eindpunt /orders/{order_id}. Welke keuze voor labels houdt de kardinaliteit begrensd en de dashboards correct?

Beantwoord dit in de interactieve les

Samenvatting

Je hebt nu een end-to-end-observabilitypad voor een FastAPI-service:

Instrumenteer met prometheus_client — tellers voor totalen, meters voor de huidige toestand en histogrammen voor latentie.
Maak een eindpunt /metrics beschikbaar en laat Prometheus dit met een vast interval uitlezen.
Beperk de kardinaliteit door alleen routesjablonen en begrensde verzamelingen als labels te gebruiken.
RED (Rate, Errors, Duration) beschrijft de ervaring van verzoeken; USE (Utilization, Saturation, Errors) beschrijft de gezondheid van resources.
Vraag gegevens op met PromQL: rate() voor tellers en histogram_quantile() voor percentielen.
Visualiseer in Grafana met dashboards op basis van sjablonen en drempelwaarden, en waarschuw voor gebruikersgerichte symptomen die aan SLO's zijn gekoppeld.

Samen geven deze onderdelen je een consistente, weinig belastende weergave van de vraag of je service beschikbaar, foutgevoelig of traag is.

Gratis beginnen

Leer Bootcamp backendontwikkeling met FastAPI met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 21
Lessen: 84

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “Prometheus-metrics en RED/USE-dashboards” gratis?

Ja — je kunt hier op het web alle 3 lessen van het leerpad Bootcamp backendontwikkeling met FastAPI, waaronder “Prometheus-metrics en RED/USE-dashboards”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Bootcamp backendontwikkeling met FastAPI bevat in totaal 4 lessen.

Wat leer ik in “Prometheus-metrics en RED/USE-dashboards”?

Expose latency-, fout- en saturatiemetrics en visualiseer de servicestatus met Grafana-dashboards. Je oefent met Bootcamp backendontwikkeling met FastAPI door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met Bootcamp backendontwikkeling met FastAPI te beginnen?

Ervaring vooraf is niet nodig. Bootcamp backendontwikkeling met FastAPI op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 3 van 4.

Hoe lang duurt de les “Prometheus-metrics en RED/USE-dashboards”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over Bootcamp backendontwikkeling met FastAPI?

Ja. Elke les over Bootcamp backendontwikkeling met FastAPI bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

Gestructureerde JSON-logging en correlatie-ID's
Distributed tracing met OpenTelemetry
Prometheus-metrics en RED/USE-dashboards
Alerts op SLO's en errorbudgetten

← Terug naar Bootcamp backendontwikkeling met FastAPI