Meten is weten met de ELK-stack

Meten is weten met de ELK-stack

Gepubliceerd: Categorie: Java & Web

We bestellen steeds meer online. Daarom ontvangen we ook steeds vaker notificaties over de levering van onze bestellingen. Ik werk bij een grote retailer aan een Kotlin-applicatie die klanten op de hoogte houdt over de verwachte aankomsttijd van hun bestelling. We gebruiken Elasticsearch, Logstash en Kibana (de ELK-stack) om inzicht te krijgen in de wijzigingen die we doen. Want meten is weten.

Klanten ontvangen op verschillende momenten pushnotificaties over de status van hun bestelling: als de bestelling is ingepland, als de bezorger onderweg is, als de bezorger er bijna is óf bij een onverwachtse wijziging in de verwachte aankomsttijd.

Notificatie-algoritme

Mijn team heeft een ingenieus algoritme bedacht voor het sturen van deze pushnotificaties. Het algoritme maakt gebruik van input uit de bezorgwagens. Deze komen met duizenden per minuut binnen. Het algoritme is optimaal wanneer de gecommuniceerde aankomsttijden zo correct mogelijk zijn. We willen onverwachte wijzigingen minimaliseren, want klanten houden niet van onnodige berichten.

Het effect van wijzigingen

Een kleine wijziging kan soms een groot effect hebben. Onze backlog bestaat uit alle wijzigingen aan het algoritme. Een grote wijziging is bijvoorbeeld een extra pushnotificatie als de bezorger er binnen 5 minuten is. Kleine wijzigingen zijn wijzigingen als het vergroten van het tijdslot of het eerder of later sturen van pushnotificaties. Hoe langer we wachten met het sturen van een bericht, hoe correcter de verwachte aankomsttijd is. Aan de andere kant willen klanten zo snel mogelijk geïnformeerd worden.

ELK-stack

We gebruiken de ELK-stack om inzicht te krijgen in het effect van de wijzigingen die we doen. Deze tooling zorgt ervoor dat de logging van onze applicatie gebruikt kan worden om dashboards te maken, waarin wij in één oogopslag kunnen zien wat er gebeurt in de applicatie. Zo kan een staafgrafiek gemaakt worden van de hoeveelheid verstuurde berichten per type, of een histogram van het aantal verstuurde berichten per klant.

Nieuwe features testen in simulatieomgeving

Naast de productieomgeving draait een simulatieomgeving. In de simulatie komt precies dezelfde input binnen (planningen en updates vanuit de bezorgwagens), maar de omgeving stuurt geen berichten naar de klant. De logging is wel hetzelfde én wordt op dezelfde manier naar de ELK-stack ontsloten als in de productieomgeving. Hierdoor kunnen we nieuwe features eerst op de simulatieomgeving testen. De grafieken vergelijken we vervolgens met de productieomgeving. Zo meten we het effect voor we features in productie zetten.

Op deze manier zien we bij een nieuwe feature of het een verbetering voor de klant is, of dat we terug naar de tekentafel moeten. Een enorme verbetering dus. Zo zie je maar weer: meten is weten!

Ronald Bakker
Over auteur Ronald Bakker

Ronald Bakker studeerde Informatica aan de Universiteit van Leiden. Hij is community leader Java bij Qualogy en sinds 2000 Java programmeur. De laatste jaren werkte Ronald via Qualogy bij ah.nl en ING Payments.

Meer posts van Ronald Bakker
Reacties
Reactie plaatsen