Observability

Observability is het vermogen om te begrijpen wat er binnen een systeem gebeurt door naar de externe signalen te kijken. Het is de gewoonte om oorzaak en gevolg te zien voordat ze uitgroeien tot symptomen. Het is dat deel van de engineeringpraktijk dat «er is iets stuk» verandert in «we weten precies wat er stuk is en waarom». We bouwen onze eigen projecten, en het is voor ons belangrijk om problemen eerder op te merken dan de gebruikers. Idealiter op het moment dat het nog een kleine afwijking van een metric is, ruim voordat het een incident wordt met nachtelijke telefoontjes.

Wat wij als goede observability beschouwen

Goede observability beantwoordt de vraag «waarom en waar precies». Zij belicht het gebruikerspad, toont degradatie, detecteert regressie na een uitrol, geeft de mogelijkheid rustig terug te rollen. Zij zwijgt over kleinigheden en spreekt luid wanneer het er echt toe doet. Slechte observability is tien alerts die niemand bekijkt, een dashboard met dertig grafieken waarin je niets terugvindt, logs in platte tekst waarop je niet kunt filteren. Goede observability is drie metrics die de gezondheid van het systeem echt beschrijven, samen met gestructureerde logs waarin zoeken seconden duurt. We houden van de «drie pijlers»-benadering — metrics, logs, traces. Metrics beantwoorden «wat gebeurt er gemiddeld», logs beantwoorden «wat is er op een specifiek moment gebeurd», traces beantwoorden «hoe is een request door het systeem gegaan». Elke pijler is op zichzelf nuttig. De magie begint wanneer ze gekoppeld zijn: vanuit een alert op een metric spring je in de logs, vanuit de logs in een trace, vanuit de trace in de code.

Privé frontend monitoring

Een aparte liefde is privé frontend monitoring. Je ziet echte fouten en prestaties in de browser, en de data blijft binnen jouw infrastructuur. Zonder overdracht naar externe diensten, zonder extra afhankelijkheid, zonder dat jouw gebruikers verkeer worden voor iemand anders' advertentiemodel. We bouwen een stack op basis van Grafana Faro, OpenTelemetry en een eigen backend voor het ontvangen van events. Zo'n oplossing kost meer dan een SaaS in vijf minuten aansluiten. Een jaar later heb je een infrastructuur die zonder externe afhankelijkheid draait, zonder eventlimieten, met voorspelbare eigenaarskosten.

Wanneer backend- en frontend-signalen samenleven, stop je met data handmatig aan elkaar breien en begin je het hele systeem in één keer te zien.

Alerts als engineeringpraktijk

Een alert instellen is eenvoudig. Hem zó afstellen dat hij alleen afgaat wanneer er echt actie nodig is, is moeilijk. We volgen de regel: een alert die is afgegaan en geen actie vereist, is een slechte alert. Misschien staat de drempel verkeerd. Misschien is de metric een ongelukkige keuze. Misschien is het probleem al automatisch opgelost, en krijgt de mens tevergeefs een melding. Daarom gaat bij ons elke alert door een filter: wat is er precies geschonden, waarom doet het ertoe, welke actie wordt verwacht, waar moet je kijken. Met heldere antwoorden op deze vragen blijft de alert staan. Zulke alerts gaan zelden af en altijd terzake.

Hoe dit in onze projecten tot uiting komt

We verzamelen signalen zo dat ze helpen bij het nemen van beslissingen: welke experimenten uit te voeren, wat te optimaliseren, waar het knelpunt zit, hoeveel een fout kost. Waar het helpt, voegen we snelle manieren toe om events en experimenten te markeren, om geloof door kennis te vervangen. In producten met gebruikersverkeer hebben we standaard een paneel met Core Web Vitals, uitsplitsingen per land en apparaat, een aparte blik op de «staart» van de verdeling — omdat gemiddelden bijna altijd liegen. In backend-diensten hebben we tracing door de hele keten, zonder welke het onmogelijk is te begrijpen waarom een specifieke request zeven seconden duurde. Als je wilt overstappen van «het lijkt slechter geworden» naar «hier is de metric, hier is de oorzaak, hier is het moment van de regressie» — dat is precies onze stijl.

Status

De competentie is actief en groeit mee met onze projecten — want zonder observability verandert elk complex systeem snel in dwalen. We zijn klaar om projecten vanaf nul te nemen (stack opzetten, alerts configureren, het team opleiden) en opdrachten om een bestaande dierentuin aan dashboards te ontwarren: wat te behouden, wat weg te halen, wat te vervangen.

Volgende

Bijbel Zoeken

Orthodox hulpmiddel voor het zoeken en bestuderen van Bijbelteksten. Snel zoeken, vertalingsvergelijking, interpretaties en kindermodus.

→