Het bouwen van een Multi-Region Health-Check Aggregator
Een gebruiker in São Paulo bereikt een defecte edge node. Ze dienen geen bugrapport in. Ze sluiten het tabblad en kijken naar iets anders.
Een normale uptime-monitor mist dit. De meeste monitors voeren probes uit vanaf één locatie. Vanaf dat ene punt ziet alles er groen uit.
Onze statuspagina gaf vroeger 100% uptime aan, terwijl echte gebruikers timeouts ervoeren. Eén globale health check hield ons voor de gek.
Hier lees je hoe we een systeem hebben gebouwd dat de waarheid spreekt.
Het probleem: Sampling Bias Als je monitor in één datacenter staat, ziet hij slechts één realiteit. Je rapporteert misschien een groene status, zelfs als je edges in Singapore en São Paulo verbindingen verliezen.
Videoverkeer maakt dit erger. Veelvoorkomende regionale storingen zijn onder andere:
- Slechte BGP-routes die één continent beïnvloeden.
- Cache evictions die zorgen voor trage origin fallbacks.
- Diskfouten die leiden tot TLS handshake timeouts.
- DNS-problemen bij specifieke lokale resolvers.
Een enkele "200 OK"-respons vertelt je bijna niets.
Onze drie regels voor health: We zijn verder gegaan dan statuscodes. We definiëren health aan de hand van drie metrieken:
- Bereikbaarheid: TCP- en TLS-handshakes moeten binnen 800ms worden voltooid.
- Latency: We houden de p95 Time-to-First-Byte (TTFB) bij. Gemiddelden verbergen de trage 'tail' die gebruikers irriteert.
- Correctheid: De response body moet een verwachte marker bevatten. Een 200 OK die een foutpagina teruggeeft, is een falen.
De oplossing: Multi-Region Probing We zijn gestopt met het gebruiken van één grote monitor. In plaats daarvan deployen we kleine Go-binaries naar goedkope regionale VPS-instances.
Elke prober:
- Controleert de edges vanaf een lokaal uitkijkpunt.
- Gebruikt
httptraceom echte TTFB-gegevens te verkrijgen. - Stuurt resultaten naar een centrale aggregator.
We gebruiken SQLite voor opslag. Het is eenvoudig en handelt onze workload af met nul overhead. We slaan ruwe samples op in plaats van vooraf geaggregeerde gegevens. Hierdoor kunnen we de geschiedenis later opnieuw beoordelen of specifieke storingen debuggen.
Het geheim: Quorum Netwerken zijn luidruchtig. Eén verloren pakketje is geen outage.
We gebruiken een quorum-systeem om valse alarmen te voorkomen. We verklaren een edge pas "down" wanneer meerdere regio's het met elkaar eens zijn. Als één regio een storing ziet maar anderen niet, pagen we het team niet. Deze ontwerpkeuze heeft 90% van onze valse meldingen geëlimineerd.
Belangrijkste lessen:
- Probe wat gebruikers raken, niet een synthetisch pad.
- Houd tail latency (p95) bij, geen gemiddelden.
- Gebruik wegwerpbare, goedkope probers in veel regio's.
- Gebruik quorum om pager fatigue te voorkomen.
- Houd je storage stack eenvoudig.
Je hebt geen zwaar observability-platform nodig. Je hebt lokale probes, ruwe data en een regel nodig die weigert in paniek te raken door ruis.