Observability – alleen monitoring is een doodlopend einde

Observability, of in het Nederlands observeerbaarheid, is een manier om uit te drukken hoe goed de interne status van een systeem afgeleid kan worden uit de data die zij genereert. Als een systeem niet “observeerbaar” is betekent dit dat de huidige waarden van interne variabelen niet bepaald kan worden met de data die voorhanden is.

Metrieken staan niet gelijk aan observeerbaarheid

Sinds het begin van de computer bestaan er logs. Strings weergeven op een apparaat die door mensen bestuurd werd om deze mensen te helpen met het bepalen van wat er aan de hand is.
Vervolgens kwamen er packages om te bepalen wat de status van een systeem is zoals sysstat, sar en netstat. Deze worden tot op de dag van vandaag nog gebruikt.

Metrieken zijn sinds de jaren 80 enorm in opkomst; snap, cacti en nu het, door Etsy ontwikkelde, erg populaire statsd. Bovenop deze systemen hebben andere monitoring bedrijven een business model gebouwd zoals SignalFX (nu Splunk), Datadog en vele anderen. De bruikbaarheid is enorm toegenomen maar de basis blijft een getal aangevuld met tags zodat je de datapunten kunt snijden en groeperen.

Een request van een gebruiker (met problemen) gaat door je code en genereert daarbij honderden, misschien wel duizenden metrieken; CPU load, I/O stats, cache hits, etc. Gelabeld met informatie zoals server, versienummer en AWS regio.

Na logs en metrieken kwamen de APM leveranciers; NewRelic, AppDynamics, Dynatrace, etc. Dit was een mooie aanvulling omdat je voor het eerst mee kon kijken wat er in de code zelf gebeurde. De APM data scharen we onder de noemer traces. Los van de deze leveranciers zijn er ook veel open source bibliotheken beschikbaar die ontwikkelaars kunnen gebruiken om vanaf dag 1 instrumentatie op te nemen in hun code. Daarover later meer.

Het grappige is eigenlijk dat de leveranciers in de top van het Gartner kwadrant niet meer zoveel van elkaar verschillen en dat je daar bijna geen slechte aankoop kunt doen. Uiteraard zijn er ook voldoende open source producten beschikbaar om een groot gedeelte van de monitoring stack mee in te vullen.

Zonder hoge kardinaliteit, succes met debuggen

Kardinaliteit verwijst naar het aantal unieke items in een set. Een uniek ID heeft altijd de hoogste kardinaliteit en een simpel getal de laagste. Als je een set met klantgegevens hebt is een BSN nummer de hoogste kardinaliteit, voor- en achternaam een stukje lager en geslacht is al weer een stuk lager.

Kardinaliteit is belangrijk omdat dit het startpunt is voor je debugsessie. Unieke ID’s zoals een username, winkelwagen id of request id zijn een ideaal startpunt om te kunnen volgen wat er plaats heeft gevonden en waar het fout is gegaan.

Voor een lange periode maakte het niet zoveel uit als je geen hoge kardinaliteit logs, metrieken of traces tot je beschikking had. Een monolitische applicatie met een web, app en data laag waren met het kijken naar dashboards wel te bevatten. Als je daar een CPU metriek omhoog zag schieten kon je met een debugger wel door de applicatie code heen stappen om het probleem te vinden en je wist intuïtief al wel waar je ongeveer moest zoeken.

Toen kwamen de containers, schedulers, microservices, mesh routing, serverless en lambda functies van de wereld om de hoek kijken. Een request maakt tussen de 20 en 30 hops vanaf het apparaat waar de gebruiker op werkt. Debugging is niet meer een zaak van “waar in de code is mijn probleem?” maar “waar in het systeem is de code met mijn probleem?”. Je kunt niet langer naar een dashboard kijken om te zien welke node of component traag is want vaak wordt alles traag.

Ook belangrijk om te noemen is aggregatie. Veel systemen die gebruik maken van metrieken om data punten te plotten aggregeren data naarmate het veroudert om zo efficiënt te kunnen rapporteren en minder impact op de opslag te hebben. Op zichzelf valide punten maar als je over tijd terug wilt zoeken en in wilt zoomen om te zien of problemen zich eerder voorgedaan hebben en hoe dat zich toen uitte is het van essentieel belang dat er geen ruwe data verwijdert wordt. Uiteraard hoef je de data niet 10 jaar te bewaken maar 3 jaar ruwe data is geen overbodige luxe.

Unknown unknowns vs known unknowns

Monitoring tools zijn effectief in het herkennen van known unknowns. Je weet ongeveer al welke problemen er kunnen voorkomen dus richt je de dashboards en alerts in zodat ze in staat zijn om deze aannames te bewaken en te signaleren als het fout gaat.

Met de architectuur die we nu hebben, en veel organisaties nog gaan krijgen, is het bijna onmogelijk om te voorspellen wat er fout gaat. De code is verspreid door het gehele systeem en wordt vaak onderhouden door meerdere teams zodat het letterlijk een naald in een hooiberg is. De unknown unknowns.

Hoe ga je dan ooit een dashboard of alert maken om deze situaties te herkennen?

De known unknowns zijn een supportprobleem. Je weet wat er kan gebeuren, je bewaakt dat en als het voorkomt weet je meestal wat de oplossing is. Deze oplossing kun je door 1e lijn support af laten handelen.

De unknown unknowns zijn een ontwikkelaars probleem. Alleen zij begrijpen o.b.v. de instrumentatie die zij gedaan hebben, en de data die dit genereert, hoe een analyse plaats moet vinden.

Observeerbaarheid als acceptatiecriteria en cultuurverandering

Observeerbaarheid wordt snel een technologische marketingterm van de monitoring bedrijven die veel marketing geld steken in het aan laten sluiten van hun product op de hype.

Observeerbaarheid is bovenal een cultuurwijziging. Het in productie kunnen volgen van requests om zo problemen te analyseren en te verhelpen moet een uitgangspunt zijn tijdens de ontwikkeling van een systeem.

Wat ga jij als ontwikkelaar doen om het jou en je collega’s in productie makkelijk te maken om een snelle analyse te kunnen doen? Ook jij wilt niet ’s nachts uren wakker gehouden worden door een acuut probleem.

Het is daarom belangrijk dat:

  • Er in de uitgevoerde testen gecontroleerd wordt op de kwaliteit van de instrumentatie.
  • Er tijdens een code review de vraag gesteld wordt of er nagedacht is over de manieren van instrumenteren en welke data punten en logs er genereert worden.
  • De organisatie nadenkt over observeerbaarheid in de ontwerp- en bouwfase.

Doodlopers

Monitoring is het kijken naar dashboards en alerts die ingericht zijn n.a.v. een eerder ervaren storing. Nooit volledig en bijna altijd een beter beeld dan de werkelijkheid. Met de opkomst van containers is deze manier van bewaken een doodlopend einde.

Monitoring moet ingericht worden op KPI’s die een indicatie geven van de kwaliteit van het systeem. Deze KPI’s dienen een brede scope te hebben om zo kleine afwijkingen in een beperkte set data niet te missen. Hoogover KPI’s als het aantal requests, het aantal errors en latency of responstijd zijn perfecte KPI’s en een goede basis voor elke service die bewaakt moet worden.

Middels machine learning en anomaly detectie moet er een signaal komen dat er iets misgaat. Vaste thresholds zijn onbruikbaar omdat geen enkel systeem tijdens zijn levensduur hetzelfde gedrag vertoont. Het analyseren van het probleem, root cause analysis, is debugging in productie en kan niet met de tools die we nu gebruiken tenzij we ze heel anders gaan inrichten.

Laten we toch kort nog even terug komen op tools; de volgende eigenschappen zijn belangrijk voor de aanschaf of het gebruik van tools die nodig zijn voor het bewaken en het analyseren / debuggen van een systeem.

  1. Er mag geen data geaggregeerd worden
  2. Er moet een near-realtime beschikbaarheid komen van logs, metrieken en traces
  3. KPI’s voor de bewaking moeten breed instelbaar zijn en alerts mogen alleen afgaan o.b.v machine learning en anomoly detectie
  4. De tool moet de devops engineer in staat stellen om de data op elke mogelijk manier te snijden en groeperen.

Conclusie

Observeerbaarheid (observability) gaat niet weg maar is echt een nieuwe stap als we praten over monitoring. Tools zijn een gedeelte van de oplossing maar als de code niet goed geïnstrumenteerd wordt alsnog nutteloos. Het begint met gewaarwording bij de ontwikkelaars dat ze vanaf het begin na moeten denken over hoe Ops engineers de door jou geschreven code in productie moeten analyseren. Die cultuurverandering is essentieel voor het slagen. Eigenlijk is observeerbaarheid de cultuurverandering en zullen de tools vanzelf wel volgen.

Een gedeelte van deze tekst is gebaseerd op “Observability – A 3-Year Retrospective” van Charity Majors. Grote kudos naar dit stuk. Ik heb geprobeerd er mijn eigen swing aan te geven en het is geenszins mijn idee geweest om dit artikel simpelweg te vertalen.

Over Coen Meerbeek

Splunk consultant @ Blue Factory, eigenaar en oprichter @ BuzzardLabs, basketbalspeler en Xbox-gamer. Lees meer van Coen op Launchers.nl en Twitter.

Speak Your Mind

*