Figur 3.3: Antal logg-medddelanden över tid uppdelad i kategorier.
Vilka värden som är av särskild intresse beror mycket på det befintliga systemet och vad som faktiskt vill uppnås med implementationen. I en tidig iteration av arbetet undersöktes till exempel om värdet av UUID kunde användas för eventuell tracing av anrop mellan olika tjänster. Detta visade sig tyvärr inte fungera. Att ta med sig från detta är att det är viktigt att se över vilken typ av information som finns tillgänglig, och ställa sig frågan hur man på bästa sätt kan utnyttja den för att hitta annan relevant information.
Ett annat effektivt sätt att hitta relevant korrelation mellan data är att testa att sätta olika värden i förhållande till varandra, även om denna metod inte är vetenskaplig kan detta leda till intressanta slutsatser om samband i datan.
3.3 Driftsättning av systemet
Ett av målen som sattes för arbetet var att undersöka möjligheterna att låta Elasticstack köras i en live-miljö. Hur en sådan miljö kan se ut och var programvara kan köras på servrar beror mycket på policy av både uppdragsgivare och i fallet av detta arbete även på uppdragsgivarens kund som i slutändan är ägare av all data som undersökts. Därför
26 KAPITEL 3. IMPLEMENTATION kan det vara viktigt att undersöka flera olika möjligheter hur lösningen kan appliceras, vilka servrar lösningen kan köras på och när det kan ske. Därutöver kan driftkostnaden av olika möjligheter vara av stor betydelse.
I detta arbete undersöktes möjligheten att låta lösningen köras på Elastic Cloud [20]
via Microsoft Azure servrar, på en virtuell maskin på en Microsoft Azure [21] server samt möjligheten att låta uppdragsgivarens kund Hertz stå för en experimentell virtuell eller fysisk server. Elastic Cloud möjligheten valdes bort då Elastic ej erbjöd drift av logstash via servicen under arbetets genomförande. Möjligheten till en virtuell maskin via Microsoft Azure uteslöts då den sistnämnda möjligheten ansågs som mer gynnsam för samtliga inblandade parter ur ett ekonomiskt perspektiv.
Då arbetet redan vid de första delresultaten av PoC-versionen visade sig göra nytta för uppdragsgivaren och därmed servicen av uppdragsgivarens kund valde AFRY att kontakta Hertz, för att begära en experimentell server. Hertz i sin tur gav tillgång till en fysisk server där implementationen kunde genomföras.
Servern har operativsystemet Redhat Enterprise som är en distribution av Linux.
Servern befinner sig på ett slutet nät och nås endast via en VPN-tunnel. Den stora fördelen med detta är att den befinner sig på samma subnät som servern där Hertz befintliga system körs. Detta underlättar då data som skickas mellan servrarna aldrig lämnar subnätet och därför inte nödvändigtvis behöver krypteras eftersom de även är skyddade av VPN-tunneln, samtidigt som fördröjningen för paketen mellan servrarna är mycket liten. På denna server körs nu tre av fyra moduler av Elasticstack; Logstash, Elasticsearch, och Kibana. Den fjärde modulen körs på den befintliga servern och läser de lokala loggfiler som ligger där.
I föregående sektion 3 Implementation beskrevs hur de olika modulerna kördes i PoC-miljön. Då kördes varje enskild modul i ett separat kommandofönster (se figur 3.1). Den nya serverns operativsystem har inget grafiskt gränssnitt och styrdes endast via konsolen. Detta innebar att samma implementation ej var möjlig. Istället fick alla
3.3. DRIFTSÄTTNING AV SYSTEMET 27 moduler startas som en service med hjälp av ett interface som finns i många Linux dis-tributioner: systemctl. Systemctl används för att starta, stoppa och hantera olika tjänster och processer [22]. Detta möjliggör att alla moduler kan köras som bakgrundsprocesser och kan på så vis styras via systemctl. Vill man se vad varje process skriver till konsolen kan detta läsas via journalctl.
Slutligen behövde vissa förutsättningar uppfyllas för att Elasticstack i sin helhet skulle kunna fungera. Genom att öppna två portar i serverns lokala brandväg tilläts Logstash att ta emot data, och Kibana tilläts ge åtkomst till sitt gränssnitt. Elasticsearch skickar och tar emot data lokalt och behöver därför inga öppna portar. Det Elasticsearch istället kräver är gott om lagringsutrymme; det var därför i detta skede viktigt att specifi-cera vart Elasticsearch skall lagra sina indexes. Alla moduler på servern behövde också konfigureras för att kommunicera med varandra. Eftersom dessa tre moduler ligger på samma maskin - precis som i PoC-versionen - var det möjligt att återanvända alla .yml samt .conf filer från den tidigare PoC-versionen. Den största utmaningen i den tidiga implementationen var att konfigurera alla moduler så att de dels fungerar optimalt, men också så att de efterliknar hur de skulle fungera i den riktiga miljön. Detta underlättade arbetet med den driftsatta versionen.
Det var dock ett moment i den tidiga utvecklingen som ej gick att återanvända. Alla visualiseringar i Kibana krävde specifikation om vilket index-pattern som data skulle hämtas ifrån. Ett index-pattern är en samling av flera index med ett gemensamt namnfor-mat och kan därför grupperas. Det är möjlig att importera och exportera visualiseringar i Kibana, men dessvärre är det inte möjlig att ändra vilket index-pattern data kan hämtas ifrån under arbetets genomförande. Detta innebar att alla tidigare visualiseringar var tvungna att återskapas enligt det nya index-pattern.
28 KAPITEL 3. IMPLEMENTATION