En fallgrop vid övergång till Microservices

Fallgrop

Under de senaste åren har Microservices-trenden fått ett allt starkare fäste i Sverige. Dock är inte alltid gräset grönare på den andra sidan och vägen dit kan vara allt annat än spikrak.

Många företag har redan idag komplexa IT-miljöer. Ofta både ett stort antal applikationer och en uppsjö av servrar som alla dessa applikationer körs på. I en sådan vardag är det inte helt sällan en utmaning bara att övervaka alla system. Ett ännu mer digert detektivarbete, som tenderar att spänna över flera olika förvaltningsorganisationer, uppstår när det gäller att felsöka i produktionsmiljöerna.

Mot denna bakgrund, föreställ er nu att varje applikation delas upp i flera Microservices som snurrar på ett antal ytterligare servrar. Om det var jobbigt att logga in på fem olika applikationsservrar och gräva i loggarna blir det sannolikt inte lättare när det istället rör sig om tjugo eller kanske ännu fler applikationsservrar. Att hitta den felande länken i kritiska lägen har plötsligt blivit avsevärt mer omständligt än tidigare. Inte helt optimalt när verksamheten flåsar IT i nacken i väntan på en lösning.

Vad kan man då göra för att undvika denna fallgrop?

Vi anser att en mycket bra start är att se över sina loggar och sin logghantering. Det är således ämnet för denna post.

Standardisera loggarna

Det första man bör göra är att sätta en gemensam minimi-standard för loggformat. Ett enkelt format kan inkludera datum, tidpunkt, nivå, server, service, klass, transaktions-id, meddelande osv. Ytterligare metadata är alltid trevligt, men ha i åtanke att följa GPDR och övrigt tillämpbar lagstiftning där ni verkar.

Fall inte heller för den alltför allrådande frestelsen att logga precis allt i hela världen. Se till att det som loggas faktiskt har ett värde. Med fördel implementeras denna standard som ett bibliotek som enkelt kan användas av de team som utvecklar moduler eller tjänster. Ett enkelt sätt att minska duplicering av kod, förenkla förvaltning och säkra att alla tjänster skickar med data enligt samma format.

Spara loggarna

När loggningsformatet är på plats och tjänsterna börjar logga se då till att de gör detta asynkront. Genom att frikoppla själva lagringen av loggen från övrig kodexekvering uppnås minsta möjliga prestandapåverkan. Vidare gör det att applikationen fortsätter fungera som den ska även om loggningen skulle packa ihop av någon anledning. Typiskt tråkigt om t.ex. hela applikationen stannar på grund av att lagringsutrymmet för loggarna tagit slut.

Aggregera loggarna

När loggningen kommit på plats för alla applikationer/Microservices är det hög tid att samla loggarna på ett ställe för att underlätta analys/felsökning. I första läget kan man nöja sig med en low-tech lösning som baseras på filöverföring till en gemensam disk. Där är det sedan möjligt att enkelt söka i alla loggar. Över tid bör man dock se sig om efter en mer robust lösning, gärna med användarvänligt gränssnitt. En populär stack är ELK (Elasticsearch, Logstash samt Kibana). Stacken är givetvis Open Source som sig bör och det finns gott om matnyttig information tillgänglig på Elastics hemsida.

Analysera loggarna

I low-tech alternativet kräver analys ofta sin beskärda del av komplexa grep-kommandon och kluriga bash-script. Med en ELK-stack på plats blir det istället mer fokus på att skapa frågeställningar mot loggregistret. Lättförståeliga grafer m.m. går sedan att få fram direkt i webbverktyget Kibana. När ni kommit såhär långt står ni rustade för att felsöka på ett effektivt sätt oavsett om ni har en eller ett hundra applikationsservrar i produktion.

Slutord

Även om ni sitter med en monolit-applikation idag rekommenderar vi er att börja tänka kring er logghantering. Det finns ofta tid och energi att spara genom standardisering av loggformat och aggregering av loggar till en och samma plats/system.

Oavsett lösning överväg alltid om den data ni analyserar eller rapporterna ni får fram bara har ett värde vid analystillfället eller om det även kan vara intressant att spara undan data och/eller resultat för att se trender över tid.

Lycka till!