Cloud observability versus cloud monitoring

De termen cloud observability en cloud monitoring worden voortdurend door elkaar gebruikt.

Dashboards, alerts, logs, traces — het belandt allemaal onder dezelfde paraplu, en een tijdlang voelt dat prima. Je levert functionaliteit op, je houdt je metrieken in de gaten en je grijpt in als er iets breekt.

Het verschil tussen monitoring en observability merk je pas echt wanneer er iets misgaat en je gebruikelijke tools je niet helpen begrijpen waarom.

Dan pas wordt het gat zichtbaar.

Monitoring draait om het volgen van bekende signalen. Je bepaalt wat ertoe doet — CPU-gebruik, responstijden, foutpercentages — en stelt drempelwaarden in. Gaat er iets over de grens, dan krijg je een melding. Het is een model gebouwd op verwachtingen: je bepaalt vooraf hoe “gezond” eruitziet en let op afwijkingen.

Voor veel systemen werkt dat prima. Gaat een dienst 500-fouten teruggeven of schieten je responstijden voorbij een bepaald punt, dan pikt monitoring dat snel op. Je krijgt een melding, kijkt op je dashboard en weet in de eenvoudige gevallen meteen waar je moet beginnen.

De beperking komt boven zodra het probleem niet past bij wat je had voorzien. Een verzoek slaagt misschien wel, maar legt een vreemde route door je systeem af. Een afhankelijkheid gaat achteruit zonder helemaal uit te vallen. Data raakt inconsistent zonder dat er een duidelijke fout afgaat.

Vanuit je monitoring bekeken zit alles nog binnen acceptabele marges. Vanuit je gebruikers bekeken is er duidelijk iets mis.

Observability begint op een andere plek. In plaats van je alleen op vooraf bepaalde signalen te richten, geeft het je genoeg zicht op je systeem om nieuwe vragen te stellen nadat er iets onverwachts gebeurt. Logs, metrieken en traces zijn er nog steeds, maar ze dienen meer als grondstof dan als vaste indicatoren.

Het kernverschil is flexibiliteit.

Duikt er een probleem op dat je niet had voorzien, dan zit je niet vast aan de dashboards die je al gebouwd had. Je kunt verkennen. Je data op andere manieren doorsnijden. Een verzoek volgen dwars door je services heen. Gedrag vergelijken tussen omgevingen of tijdvakken.

Het gaat minder over “staat deze metriek boven een drempel” en meer over “wat gebeurt er nu werkelijk in dit systeem”. Die verschuiving telt in gedistribueerde omgevingen, waar problemen zelden binnen één service blijven.

Naarmate je systeem groeit, neemt het aantal mogelijke storingen sneller toe dan het aantal alerts dat je realistisch kunt onderhouden. Je kunt dashboards en drempelwaarden blijven toevoegen, maar er is altijd iets waar je niet aan gedacht hebt. Op termijn eindigen teams met alertmoeheid of met blinde vlekken. Soms met allebei. En er hangt onderhoud aan: metrieken moeten mee veranderen met je services, alerts vragen bijstelling, dashboards lopen achter op hoe je systeem er nu uitziet. Dat betekent niet dat monitoring ophoudt nuttig te zijn. Het houdt alleen op te volstaan in zijn eentje.

Het is verleidelijk om observability te zien als simpelweg meer logs of meer metrieken verzamelen. In de praktijk maakt dat het meestal erger. Meer data zonder structuur of context maakt het juist lastiger om te vinden wat je nodig hebt.

Wat observability echt laat werken, is hoe je data geordend en verbonden is.

Een trace rijgt alle services aan elkaar die bij één verzoek betrokken waren. Gestructureerde logs laten je filteren op betekenisvolle kenmerken in plaats van door ruwe tekst te grepen. Data met veel verschillende waarden laat je inzoomen op specifieke gebruikers, endpoints of randgevallen. Zo beweeg je van een vaag symptoom naar een concrete verklaring, zonder te gokken waar je moet kijken.

In een opzet die leunt op monitoring verloopt je incidentrespons meestal volgens een vast patroon. Er gaat een alert af. Iemand kijkt op de dashboards. Een paar bekende verdachten worden onderzocht. Is het probleem niet meteen duidelijk, dan vertraagt het debuggen en wordt het een kwestie van uitsluiten.

In een systeem met sterke observability voelt het anders. Je begint bij een symptoom — een endpoint dat raar doet, een deel van je gebruikers dat last heeft — en graaft vandaaruit dieper. Je volgt het pad van het verzoek, kijkt hoe je services op elkaar inwerkten en versmalt de scope tot de oorzaak duidelijk wordt. Het maakt ervaring en intuïtie niet overbodig, maar het geeft je beter gereedschap om allebei in te zetten.

In klassieke, meer centrale systemen kon monitoring een groot deel van je behoefte afdekken. Minder bewegende delen betekende minder onbekenden.

Cloudarchitectuur is anders:

• je services zijn verdeeld

• je afhankelijkheden liggen buiten je eigen systeem

• je infrastructuur verandert voortdurend

• één verzoek van een gebruiker gaat door meerdere lagen die je niet volledig beheerst

In die omgeving dienen problemen zich zelden aan als nette storingen. Ze komen als combinaties van kleine haperingen verspreid over meerdere onderdelen.

Daar schieten vooraf bepaalde metrieken tekort. Je hebt een manier nodig om je systeem te verkennen zoals hij zich gedraagt, niet zoals je verwachtte dat hij zich zou gedragen.

Monitoring speelt nog altijd een belangrijke rol. Je hebt alerts nodig voor kritieke situaties, en simpele signalen die je vertellen dat er duidelijk iets mis is. Zonder dat reageer je te laat.

Observability bouwt daarbovenop. Het vult de gaten wanneer de situatie niet in je draaiboek past. Denken dat het een het ander vervangt, levert doorgaans ongemakkelijke opstellingen op. Teams verzuipen dan in data zonder heldere signalen, of leunen op alerts die niet vangen wat er werkelijk speelt. De balans werkt beter: monitoring voor de storingen die je kent, observability voor al het andere.

Observability invoeren gaat niet alleen over tools toevoegen. Een veelvoorkomend patroon: een nieuw platform koppelen, traces gaan verzamelen en aannemen dat het probleem daarmee opgelost is. Maar is je instrumentatie inconsistent, of weten je teams niet hoe ze de data moeten gebruiken, dan blijft de opbrengst beperkt.

Er is ook een neiging om observability als iets van beheer te zien. In de praktijk werkt het het best als je developers erbij betrekt, omdat zij weten hoe het systeem zich hoort te gedragen en welke signalen ergens over gaan. Zonder die verbinding houd je data over die gedetailleerd oogt, maar geen antwoord geeft op de vragen die je tijdens een incident echt hebt.

Monitoring beantwoordt de vragen die je al wist te stellen. Observability helpt je met de vragen die je niet zag aankomen.

Allebei zijn ze nuttig. Het verschil komt bovendrijven zodra je systeem zich gedraagt op een manier waar je niet op gerekend had — en dat gebeurt vaker naarmate de complexiteit groeit. Op dat moment is de vraag niet of je genoeg dashboards hebt, maar of je kunt volgen wat er in je systeem gebeurt zonder te gokken.