Bootcamp i backendutvikling med FastAPI · leksjon

Prometheus-metrikk og RED/USE-dashbord

Eksponer metrikk for ventetid, feil og metning, og visualiser tjenestehelsen med Grafana-dashbord.

Leksjon 3 av 413 trinn

Prometheus-metrikk og RED/USE-dashbord er en gratis leksjon i Bootcamp i backendutvikling med FastAPI på CoddyKit. Dette er leksjon 3 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Bootcamp i backendutvikling med FastAPI, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Bootcamp i backendutvikling med FastAPI inneholder totalt 4 leksjoner.

Hvorfor målinger er viktige

Logger forteller deg hva som skjedde i én forespørsel, mens metrikker forteller deg hvordan hele tjenesten oppfører seg over tid. En metrikk er en numerisk tidsserie som samples med et fast intervall, noe som gjør den billig å lagre og rask å aggregere på tvers av millioner av forespørsler.

For en FastAPI-backend er det hovedsakelig tre spørsmål som er viktige:

Betjener den trafikk? forespørselsrate
Feiler den? feilrate
Er den treg? forespørselsforsinkelse

Prometheus er en pull-basert tidsseriedatabase: Den henter jevnlig data fra et HTTP-endepunkt på /metrics som appen eksponerer, lagrer målingene og lar deg spørre dem med PromQL. Grafana gjør deretter disse spørringene om til dashbord.

De fire metriktypene

Prometheus har fire grunnleggende metriktyper. Å velge riktig type er den viktigste modelleringsbeslutningen.

Counter — går bare opp (eller tilbakestilles til 0 ved omstart). Brukes for totaler: betjente forespørsler, feil, sendte byte. Du spør etter dens rate, ikke råverdien.
Gauge — går opp og ned. Brukes for aktuell tilstand: forespørsler under behandling, minnebruk, kødybde, størrelse på connection pool.
Histogram — grupperer observasjoner (for eksempel forsinkelse) i forhåndsdefinerte intervaller, samt en _sum og _count. Gjør det mulig å beregne kvantiler på serversiden.
Summary — ligner på et histogram, men beregner kvantiler på klientsiden og kan ikke aggregeres på tvers av instanser. Foretrekk histogrammer for forsinkelse i distribuerte tjenester.

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")

Eksponere /metrics i FastAPI

For at Prometheus skal kunne hente data fra appen, monterer du et endepunkt som gjengir alle registrerte metrikker i Prometheus' tekstbaserte eksponeringsformat. Biblioteket prometheus_client gir deg generate_latest() og riktig innholdstype.

Du kan koble dette opp manuelt eller bruke prometheus-fastapi-instrumentator, som automatisk instrumenterer antall forespørsler og forsinkelse. Ved å gjøre det manuelt først blir mekanikken tydeligere.

Deretter konfigureres Prometheus til å hente data fra http://your-app:8000/metrics med et henteintervall (vanligvis 15s).

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)

Etiketter og kardinalitet

Etiketter gjør én metrikk om til mange tidsserier. http_requests_total{method="GET", path="/users", status="200"} er en annen serie enn den samme metrikken med status="500".

Kardinalitet er antallet unike kombinasjoner av etiketter. Dette er den klart største årsaken til at minnebruken i Prometheus kan eksplodere.

Gode etiketter: avgrensede mengder — HTTP-metode, statuskode, rutemal.
Farlige etiketter: ubegrensede verdier — bruker-ID-er, forespørsels-ID-er, rå URL-er med baneparametere, tidsstempler.

Bruk alltid rutemalen (/users/{id}), ikke den faktiske banen (/users/4827), som etikett. Ellers oppretter hver bruker nye serier.

En middleware for å samle inn RED-signaler

Den ryddigste måten å instrumentere hvert endepunkt på er å bruke én ASGI-middleware som registrerer antall forespørsler og forsinkelse, med etiketter for metode, rutemal og statuskode.

Legg merke til at vi leser request.scope["route"].path (eller den samsvarende rutemalen) i stedet for rå-URL-en, slik at kardinaliteten holdes avgrenset. De samme tre etikettene brukes både i visningene for Rate, Errors og 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

RED-metoden

RED-metoden (popularisert av Tom Wilkie) er standardmåten å overvåke forespørselsdrevne tjenester som et FastAPI-API på. Spor følgende for hver tjeneste:

Rate — forespørsler per sekund
Errors — mislykkede forespørsler per sekund (eller som en andel)
Duration — fordelingen av forespørselsforsinkelse (p50/p95/p99)

RED er forespørselsorientert: Det beskriver opplevelsen til klientene dine. Tre dashbordrader per tjeneste — rate, feilforhold og latenspersentiler — gir deg en konsekvent og sammenlignbar visning på tvers av alle mikrotjenester.

PromQL for rate og feil

Du spør etter Counter-metrikker med rate(), som beregner den gjennomsnittlige økningen per sekund over et tidsvindu. Vinduet (for eksempel [5m]) bør være minst fire ganger henteintervallet.

Rate — totalt antall forespørsler per sekund på tvers av alle ruter:

sum(rate(http_requests_total[5m]))

Feilforhold — andelen forespørsler som returnerer 5xx:

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

Operatoren =~ er et regex-samsvar, så "5.." fanger opp 500, 502, 503 og så videre. Bruk by (path) for å bryte ned resultatet per rute.

PromQL for latenspersentiler

Fordi vi brukte et Histogram, lagrer Prometheus kumulative bøttetellere med navnet http_request_duration_seconds_bucket og en le-etikett ("less than or equal"). histogram_quantile() estimerer en persentil fra disse bøttene.

p95-latens på tvers av tjenesten:

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

Du må først pakke bøttene inn i rate(...) og beholde le-etiketten i by()-leddet. Ellers blir kvantilen feil. Persentiler (p95/p99) er bedre enn gjennomsnitt, fordi en enkelt treg hale blir usynlig i et gjennomsnitt.

# 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),
)

USE-metoden

RED overvåker forespørselsflyten, mens USE-metoden (Brendan Gregg) overvåker ressursene som betjener disse forespørslene. Spor følgende for hver ressurs (CPU, minne, disk, connection pool, worker-tråder):

Utilization — hvor stor andel av tiden ressursen var opptatt
Saturation — hvor mye arbeid som står i kø og venter på ressursen (for eksempel forespørsler som venter på en DB-tilkobling)
Errors — feilhendelser for ressursen

USE fanger opp problemer RED overser: Hvis connection pool-en for databasen er mettet, øker forsinkelsen før feilraten gjør det. En Gauge for db_pool_in_use sammenlignet med størrelsen på pool-en er et klassisk metningssignal for en 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)

Bygge Grafana-dashbordet

I Grafana legger du til Prometheus som datakilde og bygger deretter ett dashbord per tjeneste med paneler basert på PromQL-en ovenfor:

Rate-panel (tidsserie): sum(rate(http_requests_total[5m])) by (path)
Feilforhold-panel (statistikk / måler): uttrykket for 5xx-forholdet, formatert som prosent
Latenspanel (tidsserie): linjer for p50, p95 og p99 fra histogram_quantile
Metningspanel: db_pool_in_use / db_pool_size

Bruk malvariabler (for eksempel en $path-rullegardinmeny fra label_values(http_requests_total, path)) slik at ett dashbord fungerer for alle ruter. Angi terskler (grønn/gul/rød) på feil- og latenspanelene, slik at helsetilstanden er lett å lese ved et øyekast.

Varsling basert på SLO-er

Dashbord er for mennesker som ser på dem, mens varsler er for å få beskjed. Definer varslingsregler direkte i Prometheus (eller Grafana) basert på RED-metrikkene dine, helst knyttet til et Service Level Objective.

Et vanlig mønster er et varsel med flere tidsvinduer og burn rate: Utløs varselet når feilforholdet over både et kort og et langt tidsvindu overskrider feilbudsjettets forbrukstakt. Dette unngår både ustabile varsler og treg oppdagelse.

Hold varseletikettene meningsfulle (severity, service), slik at Alertmanager kan rute personsøkere og saker riktig. Varsle om symptomer brukerne merker (høyt feilforhold, høy p99-latens), ikke om enhver intern årsak.

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"

Hurtigsjekk

Du bruker etiketter på et latency Histogram for FastAPI-endepunktet /orders/{order_id}. Hvilket valg av etiketter holder kardinaliteten avgrenset og dashbordene korrekte?

Besvar den i den interaktive leksjonen

Oppsummering

Du har nå en komplett observability-flyt for en FastAPI-tjeneste:

Instrumenter med prometheus_client — Counter for totaler, Gauge for aktuell tilstand og Histogram for latens.
Eksponer et /metrics-endepunkt og la Prometheus hente data fra det med et fast intervall.
Begrens kardinaliteten ved å bruke rutemaler og bare avgrensede mengder som etiketter.
RED (Rate, Errors, Duration) beskriver forespørselsopplevelsen, mens USE (Utilization, Saturation, Errors) beskriver ressursenes helsetilstand.
Spør med PromQL: rate() for Counter-metrikker og histogram_quantile() for persentiler.
Visualiser i Grafana med dashbord basert på maler og terskler, og varsle om brukerrettede symptomer knyttet til SLO-er.

Tilsammen gir dette deg en konsekvent oversikt med liten ressursbruk over hvorvidt tjenesten er oppe, feiler eller er treg.

Gratis å komme i gang

Lær deg Bootcamp i backendutvikling med FastAPI med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 21
Leksjoner: 84

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Prometheus-metrikk og RED/USE-dashbord» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Bootcamp i backendutvikling med FastAPI, inkludert «Prometheus-metrikk og RED/USE-dashbord», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Bootcamp i backendutvikling med FastAPI inneholder totalt 4 leksjoner.

Hva lærer jeg i «Prometheus-metrikk og RED/USE-dashbord»?

Eksponer metrikk for ventetid, feil og metning, og visualiser tjenestehelsen med Grafana-dashbord. Du øver på Bootcamp i backendutvikling med FastAPI med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Bootcamp i backendutvikling med FastAPI?

Ingen tidligere erfaring er nødvendig. Bootcamp i backendutvikling med FastAPI på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.

Hvor lang tid tar leksjonen «Prometheus-metrikk og RED/USE-dashbord»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Bootcamp i backendutvikling med FastAPI-leksjonen?

Ja. Alle Bootcamp i backendutvikling med FastAPI-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

Strukturert JSON-logging og korrelasjons-ID-er
Distribuert sporing med OpenTelemetry
Prometheus-metrikk og RED/USE-dashbord
Varsling på SLO-er og feilbudsjetter

← Tilbake til Bootcamp i backendutvikling med FastAPI