Laat me je een beeld schetsen.
Het is 3 uur ’s nachts. PagerDuty gaat af. Je rolt uit bed, klapt je laptop open en staart naar een hele reeks dashboards. De CPU ziet er goed uit. Het geheugen ziet er goed uit. Het foutenpercentage is... wacht eens even, wat is die piek? Is dat nieuw? Deed het dat vorige week ook al? Je opent nog vijf tabbladen. Je controleert de logs. Er zijn 847.000 logregels alleen al van het afgelopen uur.
Tegen de tijd dat je het daadwerkelijke probleem hebt gevonden, zijn er veertig minuten verstreken. Het probleem was een enkele verkeerd geconfigureerde time-out op een downstream-service. Het was gelogd. Het was technisch gezien de hele tijd zichtbaar.
Je kon het alleen niet zien.
Dit is de moderne observability in de meeste engineeringorganisaties — geen gebrek aan data, maar een catastrofale overvloed ervan, georganiseerd op manieren die tools dienen in plaats van mensen. Laten we het hebben over wat er daadwerkelijk misgaat, en hoe het oplossen ervan er in de praktijk uitziet.
Probleem #1: Je metrics meten de verkeerde laag
Hier is iets dat tegenintuïtief is: de meeste teams hebben meer metrics dan ze nodig hebben en minder inzichten dan ze denken.
De gemiddelde Kubernetes-cluster genereert duizenden metrics per minuut. Node-CPU. Pod-herstarts. Containergeheugenlimieten. Inkomende netwerkbytes, uitgaande netwerkbytes. Het is uitgebreid. Het is ook, voor het grootste deel, volkomen nutteloos tijdens een incident — omdat niets ervan de vraag beantwoordt die je gebruikers impliciet stellen, namelijk: werkt het product?
De metrics die ertoe doen zijn beschamend eenvoudig:
De vier signalen die je daadwerkelijk iets vertellen:
- Latentie → hoe lang duren verzoeken?
- Foutpercentage → hoeveel mislukken er?
- Doorvoer → hoeveel verkeer verwerken we?
- Verzadiging → hoe dicht zitten we bij de limiet?
Google noemde deze de Vier Gouden Signalen in het SRE Book en publiceerde dit bijna tien jaar geleden. De meeste teams hebben het gelezen. De meeste teams hebben nog steeds dashboards die deze cijfers begraven onder zeventien infrastructuurpanelen over schijf-I/O op knooppunten die al drie jaar geen incident hebben veroorzaakt.
Begin bij wat gebruikers ervaren. Werk terug naar de infrastructuur. Niet andersom.
Probleem #2: Logs zijn een stortplaats met een zoekvak
Niemand heeft hun logstrategie ontworpen. Wat er in werkelijkheid gebeurde, is dit: een ontwikkelaar voegde in 2019 een logregel toe, die één keer nuttig was, en nu zendt elke service bij elke functieaanroep een gestructureerde JSON-blob uit omdat iemand had gelezen dat gestructureerd loggen de best practice was en daar iets te ver in doorging.
Het resultaat is een systeem waarin je, om een signaal te vinden, precies moet weten waarnaar je op zoek bent — wat betekent dat logs pas nuttig zijn nadat je al een hypothese hebt. Dat is omgekeerd. Logs moeten hypothesen genereren, niet bevestigen.
Drie dingen die dit daadwerkelijk oplossen:
Correlatie-ID's, overal, zonder uitzondering. Elk verzoek dat je systeem binnenkomt, krijgt een unieke ID. Die ID reist mee door elke service-aanroep, elk wachtrijbericht, elke achtergrondtaak die door dat oorspronkelijke verzoek is gegenereerd. Als er iets misgaat, haal je één ID op en zie je het hele verhaal. Zonder dit is het debuggen van een gedistribueerd systeem als het oplossen van een moordmysterie waarbij alle getuigen zich in verschillende landen bevinden en niet dezelfde taal spreken.
Logniveaus die daadwerkelijk iets betekenen. Als alles INFO is, is niets INFO. Stel een standaard vast en handhaaf deze bij codereview. DEBUG is voor ontwikkeling. INFO is voor statusovergangen waar een mens oprecht om zou kunnen geven. WARN is voor afgehandelde afwijkingen. ERROR is voor zaken die menselijke aandacht vereisen. FATAL betekent: maak iemand wakker. Teams die standaard op INFO loggen in productie genereren ruis op industriële schaal.
Bewaarregels die aansluiten bij de realiteit. Je hebt geen toegang nodig om logs van acht maanden geleden tot op de milliseconde te doorzoeken. Hot storage voor zeven dagen. Warm voor dertig. Archiveer al het andere naar objectopslag tegen een fractie van de kosten, opvraagbaar als je het ooit echt nodig hebt. De meeste teams hebben het nooit nodig.
Probleem #3: Waarschuwingen zijn een 'wolf-roep'-machine
Vraag een willekeurige senior engineer wat hij doet als PagerDuty op een zaterdagmiddag afgaat. Als hij eerlijk is, zal hij je vertellen: hij controleert of het een van die waarschuwingen is, en als dat zo is, bevestigt hij het en gaat hij verder met waar hij mee bezig was.
Dat is geen luiheid. Dat is rationele aanpassing aan een gebrekkig systeem.
Alarmmoeheid is geen menselijk probleem. Het is een instrumentatieprobleem. Wanneer alarmen afgaan bij omstandigheden die geen menselijke actie vereisen, leren mensen alarmen te negeren. Wanneer mensen leren alarmen te negeren, wordt ook dat ene alarm dat echt actie vereist genegeerd. Zo krijg je een P1-incident dat technisch gezien zes alarmen heeft geactiveerd voordat iemand het opmerkte.
De oplossing vereist wat ongemakkelijke eerlijkheid over je huidige alarmconfiguratie:
Beantwoord voor elke bestaande waarschuwing twee vragen:
1. Als deze om 2 uur 's nachts afgaat, welke specifieke actie moet de dienstdoende dan ondernemen?
2. Heeft deze waarschuwing in de afgelopen 90 dagen tot die actie geleid, of werd ze gedempt?
Als je vraag één niet kunt beantwoorden, verwijder dan de waarschuwing.
Als het antwoord op vraag twee "gedempt" is, verwijder dan de waarschuwing.
Alerts moeten doelgericht zijn. Ze moeten afgaan wanneer een mens op dit moment iets specifieks moet doen dat niet tot de ochtend kan wachten. Al het andere — verminderde prestaties, verhoogde foutpercentages onder SLO-drempels, resourcegebruik dat zich in een slechte richting ontwikkelt — hoort thuis in een dashboard dat tijdens kantooruren wordt bekeken, niet in iemands oor om 3 uur 's nachts.
Probleem #4: Tracing is de tool die iedereen implementeert en niemand gebruikt
Distributed tracing is in theorie de oplossing voor het probleem "Ik heb logs van twaalf services en ik kan niet achterhalen wat er is gebeurd". Je instrumenteert je services, traces stromen door Jaeger, Tempo of X-Ray, en plotseling is de volledige levenscyclus van een verzoek zichtbaar als één samenhangend geheel.
In de praktijk hebben de meeste teams tracing geïmplementeerd en gebruiken ze het nauwelijks.
De reden is bijna altijd een van de volgende twee dingen. Ofwel is de steekproef te agressief — je legt 1% van de traces vast, dus het specifieke verzoek dat mislukte, zit bijna nooit in de steekproef — ofwel bestaan de traces wel, maar heeft niemand de gewoonte opgebouwd om ernaar te kijken tijdens incidenten, omdat de dashboards eerst kwamen en tracing pas later als een bijzaak.
De steekproefstrategie is belangrijker dan in de meeste documentatie wordt toegegeven:
Head-based sampling (beslissing bij start van verzoek):
→ Eenvoudig, lage overhead, maar je mist zeldzame fouten
Tail-based sampling (beslissing nadat verzoek is voltooid):
→ Legt fouten en trage verzoeken betrouwbaar vast
→ Hogere infrastructuurkosten, maar de moeite waard voor productie
Pragmatisch midden:
→ Sample 100% van de fouten en verzoeken boven de latentiedrempel
→ Sample 1-5% van al het andere
Als je tracing-opstelling niet elke fout voor 100% registreert, heb je juist daar een gat waar je het meest zichtbaarheid nodig hebt.
Probleem #5: Je observability-stack heeft geen eigenaar
Dit is de organisatorische tekortkoming die ten grondslag ligt aan alle technische problemen.
Observability-infrastructuur wordt gebouwd door degene die het als eerste nodig heeft. Een backend-team instrumenteert zijn services. Een platformteam zet Prometheus op. Iemand configureert Grafana-dashboards tijdens een lang weekend. Een aannemer installeert de APM-agent achttien maanden geleden en niemand weet precies hoe deze is geconfigureerd.
Het resultaat is een systeem zonder samenhangend ontwerp, zonder standaarden en zonder één persoon die het allemaal begrijpt. Als er om 2 uur 's nachts iets kapot gaat, is de vraag niet alleen wat er mis is met de applicatie — het is ook kan ik überhaupt vertrouwen op wat mijn monitoring me op dit moment vertelt.
Observability is infrastructuur. Het moet als infrastructuur worden behandeld: er moet eigenaarschap voor zijn, het moet worden onderhouden, bewust worden verbeterd en aan dezelfde betrouwbaarheidsnormen voldoen als de systemen die het monitort. Een monitoringsysteem dat tijdens een incident uitvalt, is erger dan helemaal geen monitoringsysteem — het wekt vals vertrouwen op precies het verkeerde moment.
Wijs eigenaarschap toe. Definieer normen. Beoordeel de stack op dezelfde manier als je de applicatiearchitectuur beoordeelt. Dit is geen glamoureus werk. Het is echter het verschil tussen een rooster voor oproepdiensten dat functioneert en een rooster dat je beste engineers langzaam verandert in mensen die erg goed zijn in het negeren van waarschuwingen.
Het getal dat er echt toe doet
Ruwe MTTR — gemiddelde tijd tot herstel — is de statistiek die de meeste organisaties bijhouden voor incidentbeheer. Op zich is dat prima.
Het getal waar je je op moet richten is mean time to understanding.
Herstel gaat vaak snel zodra je weet wat er mis is. Het is het weten dat om 2 uur 's nachts veertig minuten kost. Elke investering in observability — correlatie-ID's, zinvolle waarschuwingen, goede tracering, logboekhygiëne — is uiteindelijk een investering in het verkleinen van die kloof tussen er is iets mis en ik weet precies wat en waarom.
Het doel is niet meer dashboards. Het is niet meer data. Het is minder tijd besteden aan het staren naar informatie die geen antwoord geeft op de vraag die je eigenlijk stelt.
Je systeem vertelt je voortdurend dingen. De vraag is of je de omstandigheden hebt gecreëerd om er ook daadwerkelijk naar te luisteren.