Welkom
Welkom
Een web-schaal vloot bevat veel machines. Op elk moment zijn sommige gezond, sommige starten op, sommige worden afgebouwd en sommige zijn stil defect. De vloot overleeft dit omdat elke machine op verzoek antwoordt op twee eenvoudige vragen:
- /health — kan ik op dit moment echte verzoeken bedienen?
- /version — welke code draai ik?
Plus een metriekeindepunt (meestal /metrics) dat tellers en meters blootlegt zodat monitoringtools deze kunnen ophalen.
In deze les leer je hoe je deze eindpunten ontwerpt zodat ze de werkelijkheid weerspiegelen, wat de vier gouden signalen op proxy-niveau betekenen, en hoe waargenomen data capaciteitsbeslissingen stuurt.
Aan het einde van deze les kun je:
- Een /health-eindpunt ontwerpen dat echte padstoringen detecteert, niet alleen proceslevendigheid
- Een /version-eindpunt ontwerpen waarmee je kunt verifiëren of een implementatie is geland
- De vier gouden signalen (latentie, verkeer, fouten, verzadiging) toepassen op proxy-niveau
- Waargenomen piekmetrieken koppelen aan capaciteitsbeslissingen: wanneer omhoog schalen, wanneer afstroomen, wanneer een page uitsturen
- Redeneren over SLO's en de verbruikssnelheid van de foutenbudget als de operationele discipline achter 'hoeveel interesseert ons dit?'
De twee soorten gezondheidscontrole
Liveness vs Readiness
Liveness: is het proces überhaupt nog actief? Wordt gebruikt door orkestratoren (Kubernetes, systemd) om te bepalen of het proces opnieuw moet worden opgestart.
Readiness: is het proces klaar om nu echt verkeer te verwerken? Wordt gebruikt door load balancers om te bepalen of verzoeken moeten worden doorgestuurd.
Dit zijn verschillende vragen. Een proces dat actief is, maar geen verbinding kan maken met zijn database, is actief maar niet klaar. Een proces dat opstart, is actief maar nog niet klaar.
Shallow vs Deep Health Checks
Shallow: geeft {"status": "ok"} terug als de HTTP-handler wordt uitgevoerd. Triviaal. Detecteert alleen dat het proces is neergevallen.
Deep: test daadwerkelijk de echte verzoekpaden. Controleert of de databaseverbindingspool een verbinding kan teruggeven, of de cache bereikbaar is en of downstream-afhankelijkheden reageren. Detecteert functionele storingen die shallow-checks missen.
De afweging: diepe controles kosten meer (elke controle is in wezen een synthetische request) & kunnen een kaskade van falen veroorzaken (als de health check van elke replica de database overbelast, zorgt een trage database ervoor dat alle replicas ongezond worden, waardoor ze uit de rotatie worden gehaald, wat alle capaciteit wegneemt).
Beste praktijk: een oppervlakkige check voor liveness (snel, goedkoop, geen externe afhankelijkheden) & een diepere check voor readiness (gecachte resultaten, gedempt om downstream-systemen niet te overbelasten).
Versie-endpoints
/version geeft de git-commit, de buildtijd & de servicenaam terug. Na een deploy voer je curl https://service.example.com/version uit & controleer je of de teruggegeven commit overeenkomt met wat je hebt gepusht. Zo niet, dan is de deploy stil gefaald.
Zonder /version kan een verouderde deploy succesvol lijken & uren lang onopgemerkt blijven.
Minimale responsstructuur: {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}.
Latentie, Verkeer, Fouten, Verzadiging
Vier getallen dekken de meeste operaties
Uit het Google SRE-boek. Vier signalen die je op elk serviceniveau meet. Als je deze vier goed instrumenteert, vang je de meeste productieproblemen af voordat gebruikers ze merken.
Latency: hoe lang duurt een verzoek? Rapporteer verdelingen, niet alleen gemiddelden. De p99 (99e percentiel latency) is belangrijker dan het gemiddelde, omdat tail latency is wat gebruikers als 'traag' ervaren. Een service met een gemiddelde van 50 ms en een p99 van 5.000 ms heeft een echt probleem dat de meeste gebruikers nooit merken, maar dat de meest getroffen 1% absoluut wel voelt.
Traffic: hoeveel verzoeken per seconde? Totaal aantal verzoeken, per endpoint, per statuscode, per regio. Baseline bekend; alert op anomalieën (plotselinge daling = inkomend probleem; plotselinge piek = stroom of aanval).
Fouten: percentage mislukte verzoeken. Maak onderscheid tussen 4xx (clientfouten, niet jouw schuld) en 5xx (serverfouten, jouw schuld). Houd het foutpercentage bij als percentage van het verkeer, niet als absolute aantallen, zodat alerts werken op verschillende belastingniveaus.
Saturatie: hoe vol is het systeem? CPU-gebruik, geheugen, diepte van de verbindingspool, wachtrijlengte. De voorloper-indicator. Saturatie stijgt voordat latency of fouten verergeren. Een tier op 90% saturatie is één slechte minuut verwijderd van wachtrijinstorting.
Specifiek op een Proxy-Tier
Elk signaal licht op op de edge-laag:
- Latency op de proxy: duur van de TLS-handshake, connectietijd naar upstream, totale verzoek-responsduur. Apart gemeten omdat ze zich op verschillende delen van het pad bevinden.
- Traffic op de proxy: totaal aantal verzoeken/sec, verdeling per backend (een 'hete' backend wijst op load-balancer-skew), opbrengst per statuscode.
- Fouten op de proxy: 4xx van clients (uw gebruikers die onjuiste endpoints raken), 5xx van backends (uw services falen), interne proxy-fouten (502 = backend onbereikbaar, 504 = backend-timeout).
- Saturatie op de proxy: aantal TLS-sessies, diepte van de upstream-verbindingenpool, CPU-gebruik op de proxy zelf (TLS-terminatie is CPU-intensief).
Pro tip: een plotselinge stijging in 502's met lage backend-latentie betekent dat de backend ophangt voordat deze reageert (verbinding gereset, crash, OOM). Een stijging in 504's betekent dat de backend traag is maar nog steeds antwoordt. Lees de foutcode; die vertelt u waar de fout zich bevindt.
Lees de signalen
Uw dashboard toont de volgende waarden over de afgelopen 10 minuten:
- Verkeer: ongeveer stabiel op 800 req/s (geen piek)
- Latentie: p50 stabiel op 40ms, p99 steeg van 200ms naar 2.500ms in 5 minuten & is nog steeds aan het stijgen
- Fouten: 4xx-tarief stabiel op 0,3% (normale achtergrond); 5xx-tarief steeg van 0,1% naar 1,2% (vooral 504 Gateway Timeout)
- Saturatie: backend-CPU steeg van 45% naar 78% in dezelfde 5 minuten; proxy-CPU stabiel op 30%
Wanneer schalen, wanneer afleiden, wanneer een melding versturen
Capaciteitsbeslissingen hebben triggers nodig
Metrieken observeren is eenvoudig. Weten wanneer je daarin moet handelen, is de discipline.
Schaal op wanneer: de verzadiging een aanhoudende drempelwaarde overschrijdt (bijv. backend-CPU >70% gedurende 5 minuten), of de wachtrijdiepte groter wordt dan het doel, of de p99-latency de SLO overschrijdt. De trigger moet afvuren vóórdat er iets kapotgaat, niet op het moment dat het kapotgaat.
Een replica afleiden wanneer: deze consistent traag is of fouten geeft terwijl de overige replica's gezond zijn (één replica die heet draait is vaak een host-niveau probleem, geen applicatieprobleem), of bij het uitrollen van een nieuwe versie, of bij het netjes afbouwen van een replica.
Een mens een melding versturen wanneer: een SLO sneller wordt overschreden dan het foutbudget kan dragen, of een verzadigingstrigger afvuurt zonder dat autoscaling dit opvangt, of een kaskadepatroon zichtbaar wordt (foutenpercentage en retry-percentage stijgen beide).
Geen melding versturen wanneer: een enkele slechte minuut vanzelf oplost, of achtergrondbatchtaken verwachte periodieke pieken veroorzaken, of ruis de drempelwaarde overschrijdt (de drempelwaarde is dan fout, niet het systeem).
SLO's en foutbudgetverbruik
Een SLO (service level objective) definieert aanvaardbare prestaties: 'succesratio >= 99,9% over een periode van 28 dagen'. Het complementaire deel (0,1%) is het foutbudget.
Verbruikssnelheid (burn rate): hoe snel je het foutbudget verbruikt. Als je 10% van het budget in 1 uur verbruikt, is de snelheid 240x hoger dan duurzaam (1 uur is 1/672 van een periode van 28 dagen; 10% verbruiken in dat venster = 10% × 672 = 6720% geprojecteerd voor de volledige periode, terwijl slechts 100% is toegestaan).
Meervoudige venster-verbruikssnelheidswaarschuwingen (multi-window burn-rate alerts): melding (page) wanneer zowel een kort venster (5 minuten bij een snelheid van 14,4x) & een lang venster (1 uur bij een snelheid van 6x) sneller verbranden dan duurzaam. Dit vangt zowel snelle uitval als langzame degradatie op.
Waarom dit belangrijk is voor capaciteit: een service die draait met een SLO van 99,9% en 1% marge kan kleine schommelingen opvangen. Een service op 99,93% (krap aan de SLO voldoen) is één slechte dag verwijderd van een schending. Capaciteitsbeslissingen moeten gericht zijn op een comfortabele SLO-marge, niet op het minimum dat eraan voldoet.
Een capaciteitsbeslissing onder observatie
Je service heeft een SLO van 99,9% succesvolle aanvragen over 28 dagen. Huidige status uit monitoring over het afgelopen uur:
- Succesratio: 99,5% (aanhoudend gedurende 30 minuten)
- Backend-CPU: gemiddeld 82% over de hele vloot (doel 70%)
- p99-latentie: 800 ms (SLO-doel: <500 ms)
- Verkeer: 1.400 req/s, omhoog vanaf de basis van 1.000 req/s (40% boven normaal; trend stijgt nog steeds)
- Autoscaling: ingesteld om replicas toe te voegen wanneer de CPU > 80% gedurende 5 minuten aanhoudt; momenteel loopt een scale-up die binnen ~90 seconden 3 replicas zal toevoegen
Ontwerp een observabiliteitsplan voor de lancering
Synthese
Je kunt nu een /health ontwerpen die echte storingen vangt, een /version waarmee je deploys kunt verifiëren, dashboards met de vier gouden signalen op proxy-niveau, en capaciteitsalerts gekoppeld aan de SLO-burn rate.
Pas alle vier toe.
Jouw team gaat search.example.com lanceren (de zoekservice uit de les over falingsmodi). Het team wil observabiliteit uitrollen die problemen vangt voordat gebruikers ze merken, met een heldere beslismatrix voor al dan niet pagen. SLO: 99,9% succesvolle verzoeken, p99-latency < 300 ms, over een periode van 28 dagen.
Afsluiting van de cursus
Afsluiting van de cursus
U heeft alle vijf de lessen voltooid:
- Proxies & Origins: de vorm van de edge-laag die bijna elke publieke webdienst gebruikt
- Stateless Horizontale Schaling: waarom een stateless-laag goedkoop vermenigvuldigd kan worden & hoe je de grootte ervan bepaalt
- Scheiding van Ingress & Egress: waarom één box twee wordt, & het falingspatroon dat dit afdwingt
- Falingspatronen & Blast Radius: SPOFs, cascades, postmortems, schuldvrije actiepunten
- Observability & Capaciteit (deze les): wat je moet meten zodat problemen naar voren komen voordat gebruikers ze merken
De rode draad: een web-schaal gedistribueerd systeem is geen magie. Het is een kleine set patronen (reverse proxy, stateless replicas, ingress/egress-scheiding, bulkheads & circuit breakers, de vier gouden signalen) die doordacht zijn samengesteld. Zodra je de patronen herkent, zie je ze in elke productie-architectuur.
Begeleidelijke lessen: vijf lessen over de geometrie van *herformuleren hetzelfde materiaal als grafentheorie & meetkunde. Ze werken goed in beide volgorde.
Goed gedaan.