Observability is een term die je weinig tegenkomt in het testvak. Terwijl dit veld ons zo veel te bieden heeft! Deel 1 – Wat is observability en waarom is het belangrijk voor testers van deze serie was een introductie tot observability; wat het is, en waarom het belangrijk is om iets van af te weten. In deze tweede blogpost gaan we in op concrete manieren waarop je observability kunt inzetten in het testvak.
Wat is observability
Hoe zat het ook alweer met observability? Wij gebruiken de volgende definitie:
Observability is het vermogen om, op basis van output (logs, metrics, traces), te verklaren wat er intern in het systeem gebeurt.
Omdat we hier wat verder zullen inzoomen op observability-technieken kan het geen kwaad om toe te lichten wat met logs, metrics en traces bedoeld wordt.
Logs zijn de administratie van wat er in een systeem gebeurt. Dit kan gaan over access logs (wie heeft waar toegang toe gehad en wanneer), foutmeldingen maar ook applicatie-specifieke informatie.
Metrics geven kwantitatief inzicht in het systeem. Dit kan het percentage zijn van het geheugen of de cpu dat gebruikt wordt, maar ook de status en responstijd van requests.
Traces correleren logs en metrics om de relatie tussen gebeurtenissen in het systeem duidelijk te maken. Door bijvoorbeeld een unieke identifier te volgen tussen frontend, backend en database kan de “reis” van een verzoek van de gebruiker in kaart gebracht worden.
Hoewel het concept observability in de DevOps-wereld is ontstaan, zijn de onderliggende principes toepasbaar in vrijwel iedere IT-ontwikkelfilosofie en technologie-stack. Zolang je toegang hebt tot logs en metrics, kun je al data samenbrengen om inzicht te verschaffen in wat er gebeurt. Observability-tooling zoals Grafana, Datadog of Cloudwatch biedt vooral schaalbaarheid en gemak in het samenbrengen van datastromen, en het aantrekkelijk presenteren in dashboards, maar is in de kern geen vereiste.
Observability voor testers
In het eerste artikel bespraken we testen als de activiteit(en) waarmee we kunnen aantonen wat de kwaliteit van een testobject is. Hiervoor zijn we al gewend om een combinatie van verschillende tools en technieken in te zetten. Denk aan verkennend testen, testautomatisering, misschien al wel AI-powered testing. Maar welke strategie we ook kiezen, observability biedt kansen om effectiever te zijn. Ik zal drie manieren bespreken waarop het onze technieken versterkt.
Meer zicht
Het meest voor de hand liggende voordeel van observability, is simpelweg het toegenomen zicht op de applicatie. Als tester hoeven we niet enkel te kijken naar de output van een black box, met observability kunnen we ook zien wat er binnenin gebeurt.
Voorbeeld
Op basis van onze metrics in productie weten we dat onze applicatie op piekmomenten 500 requests per seconde op het betalingen-endpoint verwerkt, maar uit onze logs weten we ook dat dit soms samengaat met fouten. Voor het testen van verbeteringen in de stabiliteit van de applicatie, testen we met een hypothese: de applicatie kan 500 requests per seconde aan zonder fouten. Wanneer we performance-tests draaien in onze acceptatieomgeving, houden we niet alleen de output (status en responstijden) in de gaten, maar observeren we ook andere metrics en logs. Zo zien we dat de betalingen nu slagen, maar dat er ook bijwerkingen zijn: als de systemen onder druk staan, zien we foutmeldingen ontstaan op andere endpoints.
Testen is vaak experimenteren. En bij experimenteren is het cruciaal dat we goed in staat zijn effecten en vooral ook bijwerkingen te observeren. Dit kan al zo simpel zijn als het doorspitten van logfiles wanneer er iets onverwachts is gebeurd.
Meer begrip
Goede observability bundelt logs, metrics en traces zodanig dat we niet alleen zien wat er gebeurt, maar ook snappen waarom.
Traces kunnen ons helpen met het koppelen van metrics en logs, of zelfs het in kaart brengen van een hele gebruikersreis door de applicatie heen. Dit is met name nuttig met het opsporen van problemen in productie die door lastig na te spelen zijn.
Dashboards kunnen worden ingericht om snel begrip van een situatie mogelijk te maken. Hier zijn veel strategieën voor, maar voor het perspectief van testers is er één specifiek het benoemen waard: de RED-methode.
RED-methode
RED staat voor:
- Rate – Requests per seconde
- Errors – Aantal falende requests
- Duration – Tijd die requests duren
Bron: Grafana Labs
De RED-methode wordt beschouwd als een goede graadmeter van hoe blij je gebruikers zijn. Falende requests zitten je gebruikers direct dwars, en lang durende requests zorgen voor traagheid. Deze staan vaak in relatie tot het aantal requests per seconde en/of tot elkaar. Deze methode is goed toe te passen op diensten, bijvoorbeeld in een microservice-architectuur, en kan gebruikt worden voor alerting en SLA’s (Service Level Agreements).
Het maken van dashboards klinkt soms als een imponerende taak, maar het helpt hier om klein te beginnen. Begin bijvoorbeeld met tellen van (soorten) http-errors, je zult je verbazen hoeveel je dit al vertelt over de gezondheid van je applicatie.
Meer focus
Begrip van onze applicatie helpt ons een hoop, maar nog niet met de moeilijkste vraag in het testvak: wat gaan we testen, en wanneer is het goed genoeg? Tijd is altijd beperkt, en ondanks dat automatisering en AI hierin deels kunnen helpen, zijn mensuren en geld dat ook. We stoppen niet met testen wanneer we alle risico’s hebben afgedekt, we stoppen wanneer we de risico’s *goed genoeg* hebben afgedekt. We moeten prioriteren. En zoals we hebben gezien in deel 1, is het hierin cruciaal dat we dit doen op basis van informatie uit productie. Zo ontstaat een cyclus van feedback die met iedere iteratie de applicatie verbetert.
Voorbeeld
We analyseren metrics van de productieomgeving en zien dat de API-response time voor de zoekfunctie in de piekuren gemiddeld 2 seconden is, terwijl dit 's nachts 200 milliseconden is. Hieruit leiden we af dat deze functie onder belasting kwetsbaar is. Op basis hiervan kunnen we beslissen om meer tijd te besteden aan load- en stresstests, en juist minder aan tests en optimalisaties van enkele requests.
De juiste focus aanbrengen in je testactiviteiten is moeilijk, omdat elke situatie anders is. Observability kan ons van de juiste informatie voorzien bij het maken van keuzes. Maar wees er bewust van dat dit vaak samenhangt met de prioriteiten van je team als geheel. Maak afspraken over welke metrics het meest belangrijk zijn, bijvoorbeeld in de vorm van Service Level Objectives (SLO’s). Hierop kun je dan weer je kwaliteitsstrategie baseren.
Conclusie
In complexe en constant veranderende IT-landschappen is het van belang om continu te kunnen begrijpen wat er gebeurt in de systemen waar we voor verantwoordelijk zijn. Observability biedt ons meer zicht, begrip en helpt met focus brengen in het prioriteren van testactiviteiten.
In het volgende deel van deze serie beschrijven we een voorbeeld van onze favoriete observability-stack, en hoe je dit zelf in de praktijk kunt brengen.
