Bootcamp i backendutveckling med FastAPI · Lektion

Prometheus-mått och RED-/USE-dashboards

Exponera mått för latens, fel och mättnad och visualisera tjänstens hälsa med Grafana-dashboards.

Lektion 3 av 413 steg

Prometheus-mått och RED-/USE-dashboards är en gratis lektion i Bootcamp i backendutveckling med FastAPI på CoddyKit. Detta är lektion 3 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Bootcamp i backendutveckling med FastAPI, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Bootcamp i backendutveckling med FastAPI innehåller totalt 4 lektioner.

Varför mätvärden är viktiga

Loggar berättar vad som hände i en enskild begäran, medan mätvärden berättar hur hela tjänsten beter sig över tid. Ett mätvärde är en numerisk tidsserie som samplas med ett fast intervall, vilket gör den billig att lagra och snabb att aggregera över miljontals begäranden.

För en FastAPI-backend är det främst tre frågor som är viktiga:

Hanterar den trafik? begärandefrekvens
Misslyckas den? felfrekvens
Är den långsam? svarstid för begäranden

Prometheus är en pull-baserad tidsseriedatabas: den hämtar regelbundet data från en HTTP-endpoint på /metrics som appen exponerar, lagrar mätvärdena och låter dig fråga dem med PromQL. Grafana omvandlar sedan frågorna till instrumentpaneler.

De fyra mätvärdestyperna

Prometheus har fyra grundläggande mätvärdestyper. Att välja rätt typ är det viktigaste beslutet när du modellerar mätvärden.

Counter — ökar bara (eller återställs till 0 vid omstart). Använd för totaler: hanterade begäranden, fel, skickade byte. Fråga efter dess rate, inte dess råvärde.
Gauge — kan öka och minska. Använd för aktuellt tillstånd: pågående begäranden, minnesanvändning, ködjup och storleken på anslutningspoolen.
Histogram — delar in observationer (till exempel svarstider) i fördefinierade intervall, samt innehåller en _sum och en _count. Gör det möjligt att beräkna kvantiler på serversidan.
Summary — liknar ett histogram men beräknar kvantiler på klientsidan och kan inte aggregeras mellan instanser. Histogram är att föredra för svarstider i distribuerade tjänster.

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

Exponera /metrics i FastAPI

För att låta Prometheus hämta data från appen monterar du en endpoint som återger alla registrerade mätvärden i Prometheus textbaserade exponeringsformat. Biblioteket prometheus_client tillhandahåller generate_latest() och rätt innehållstyp.

Du kan koppla in detta manuellt eller använda prometheus-fastapi-instrumentator, som automatiskt instrumenterar antal begäranden och svarstider. Om du först gör det manuellt blir mekanismerna tydligare.

Konfigurera sedan Prometheus så att den hämtar data från http://your-app:8000/metrics med ett hämtningsintervall (vanligtvis 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 och kardinalitet

Etiketter omvandlar ett mätvärde till flera tidsserier. http_requests_total{method="GET", path="/users", status="200"} är en separat serie från samma mätvärde med status="500".

Kardinalitet är antalet unika kombinationer av etiketter. Det är det enskilt vanligaste sättet att få Prometheus minnesanvändning att skena.

Bra etiketter: begränsade mängder — HTTP-metod, statuskod och routemall.
Farliga etiketter: obegränsade värden — användar-ID:n, begärande-ID:n, råa URL:er med sökvägsparametrar och tidsstämplar.

Etikettera alltid med routemallen (/users/{id}), inte den upplösta sökvägen (/users/4827), annars skapar varje användare nya serier.

Middleware för att fånga RED-signaler

Det renaste sättet att instrumentera varje endpoint är en enda ASGI-middleware som registrerar antal begäranden och svarstid, etiketterat med metod, routemall och statuskod.

Observera att vi läser request.scope["route"].path (eller den matchade sökvägsmallen) i stället för den råa URL:en, så att kardinaliteten hålls begränsad. Samma tre etiketter används för vyerna Rate, Errors och 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 (populariserad av Tom Wilkie) är standardmetoden för att övervaka begärandedrivna tjänster, till exempel ett FastAPI-API. För varje tjänst följer du:

Rate — begäranden per sekund
Errors — misslyckade begäranden per sekund (eller som en andel)
Duration — fördelningen av begärandenas svarstider (p50/p95/p99)

RED är begärandecentrerad: den beskriver upplevelsen hos dem som anropar tjänsten. Tre rader med instrumentpaneler per tjänst — frekvens, felkvot och svarstidens percentiler — ger en konsekvent och jämförbar vy över alla mikrotjänster.

PromQL för frekvens och fel

Counter-mätvärden frågas med rate(), som beräknar den genomsnittliga ökningen per sekund över ett tidsintervall. Intervallet (till exempel [5m]) bör vara minst fyra gånger så långt som hämtningsintervallet.

Frekvens — totalt antal begäranden per sekund över alla routar:

sum(rate(http_requests_total[5m]))

Felkvot — andelen begäranden som returnerar 5xx:

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

Operatorn =~ matchar reguljära uttryck, så "5.." fångar 500, 502, 503 och så vidare. Använd by (path) för att dela upp resultatet per rout.

PromQL för svarstidens percentiler

Eftersom vi använde ett Histogram lagrar Prometheus kumulativa bucket-räknare med namnet http_request_duration_seconds_bucket och en le-etikett ("less than or equal", mindre än eller lika med). histogram_quantile() uppskattar en percentil från dessa buckets.

p95-svarstid för hela tjänsten:

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

Du måste först omsluta buckets med rate(...) och behålla etiketten le i by()-satsen, annars blir kvantilen fel. Percentiler (p95/p99) är bättre än medelvärden, eftersom enstaka långsamma begäranden i svansen inte syns i ett medelvärde.

# 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 övervakar begärandeflödet, medan USE-metoden (Brendan Gregg) övervakar de resurser som hanterar begärandena. För varje resurs (CPU, minne, disk, anslutningspool och arbetstrådar) följer du:

Utilization — hur stor andel av tiden resursen var upptagen
Saturation — hur mycket arbete som ligger i kö och väntar på resursen (till exempel begäranden som väntar på en databasanslutning)
Errors — felhändelser för resursen

USE upptäcker problem som RED missar: om anslutningspoolen till databasen är mättad ökar svarstiden innan felfrekvensen gör det. En Gauge för db_pool_in_use jämförd med poolens storlek är en klassisk mättnadssignal i 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)

Bygg Grafana-instrumentpanelen

I Grafana lägger du till Prometheus som datakälla och bygger sedan en instrumentpanel per tjänst med paneler som använder PromQL-frågorna ovan:

Frekvenspanel (tidsserie): sum(rate(http_requests_total[5m])) by (path)
Felkvotpanel (statistik / mätare): uttrycket för 5xx-kvoten, formaterat som procent
Svarstidspanel (tidsserie): linjer för p50, p95 och p99 från histogram_quantile
Mättnadspanel: db_pool_in_use / db_pool_size

Använd mallvariabler (till exempel en $path-rullgardinsmeny från label_values(http_requests_total, path)) så att en enda instrumentpanel fungerar för alla routar. Ange tröskelvärden (grönt/gult/rött) på fel- och svarstidspanelerna så att hälsoläget syns direkt.

Aviseringar baserade på SLO:er

Instrumentpaneler är till för att människor ska titta på dem, medan aviseringar är till för att tala om när något händer. Definiera aviseringar i Prometheus (eller Grafana) direkt utifrån dina RED-mätvärden, helst kopplade till ett Service Level Objective.

Ett vanligt mönster är en avisering baserad på förbrukningstakt över flera tidsfönster: utlös aviseringen när felkvoten under både ett kort och ett långt tidsfönster överskrider den takt som förbrukar felbudgeten. Det motverkar både fladdrande aviseringar och långsam upptäckt.

Håll aviseringarnas etiketter meningsfulla (severity, service) så att Alertmanager kan dirigera sidor respektive ärenden korrekt. Avisera om symtom som användarna märker (hög felkvot, hög p99-svarstid), inte om varje intern orsak.

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"

Snabb kontroll

Du etiketterar ett latency-Histogram för en FastAPI-endpoint /orders/{order_id}. Vilket val av etiketter håller kardinaliteten begränsad och instrumentpanelerna korrekta?

Besvara frågan i den interaktiva lektionen

Sammanfattning

Du har nu en komplett observability-kedja för en FastAPI-tjänst:

Instrumentera med prometheus_client — Counter för totaler, Gauge för aktuellt tillstånd och Histogram för svarstider.
Exponera en /metrics-endpoint och hämta data från den med Prometheus enligt ett fast intervall.
Begränsa kardinaliteten genom att endast använda routemallar och begränsade mängder som etiketter.
RED (Rate, Errors, Duration) beskriver upplevelsen av begäranden, medan USE (Utilization, Saturation, Errors) beskriver resursers hälsa.
Fråga med PromQL: rate() för Counter-mätvärden och histogram_quantile() för percentiler.
Visualisera i Grafana med mallbaserade instrumentpaneler och tröskelvärden, och avisera om användarvända symtom kopplade till SLO:er.

Tillsammans ger detta en konsekvent överblick med låg belastning över huruvida tjänsten är igång, misslyckas eller är långsam.

Gratis att börja

Lär dig Bootcamp i backendutveckling med FastAPI med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser: 21
Lektioner: 84

Börja lära dig gratis Visa hela kursen

Vanliga frågor

Är lektionen ”Prometheus-mått och RED-/USE-dashboards” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Bootcamp i backendutveckling med FastAPI, inklusive ”Prometheus-mått och RED-/USE-dashboards”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Bootcamp i backendutveckling med FastAPI innehåller totalt 4 lektioner.

Vad lär jag mig i ”Prometheus-mått och RED-/USE-dashboards”?

Exponera mått för latens, fel och mättnad och visualisera tjänstens hälsa med Grafana-dashboards. Ni övar på Bootcamp i backendutveckling med FastAPI med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Bootcamp i backendutveckling med FastAPI?

Du behöver inga förkunskaper. Utbildningen i Bootcamp i backendutveckling med FastAPI på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.

Hur lång tid tar lektionen ”Prometheus-mått och RED-/USE-dashboards”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Bootcamp i backendutveckling med FastAPI-lektionen?

Ja. Varje Bootcamp i backendutveckling med FastAPI-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

Strukturerad JSON-loggning och korrelations-ID:n
Distribuerad tracing med OpenTelemetry
Prometheus-mått och RED-/USE-dashboards
Larm för SLO:er och error budgets

← Tillbaka till Bootcamp i backendutveckling med FastAPI