Monitorering & strategi av loggning i distribuerade system: Visualisering med hjälp av Elasticstack

Monitorering & strategi av

loggning i distribuerade system

Visualisering med hjälp av Elasticstack

Monitoring & strategy for logging in distributed systems Visualising with Elasticstack

Philip Wingfelt Roman Eichler

Fakulteten för hälsa, natur-och teknikvetenskap Datavetenskap

C-uppsats 15hp

Handledare: Stefan Alfredsson Examinator: Johan Eklund Datum: 2020-01-14

Förord

Tack till våra arbetskamrater, flickvänner, och familjer. Utan er hade arbetet troligtvis gått mycket fortare, men vi hade nog blivit utbrända då.

Speciellt tack till våra handledare, Jesper Hellberg och Stefan Alfredsson som har hjälpt oss genom hela arbetet både med bra feedback men även genom utvecklingsidéer och många trevliga samtal.

Och slutligen ett stort tack till ÅF Pöyry - som under arbetets gång bytte namn till AFRY - för att vi fick göra vårt arbete hos er!

i

ii FÖRORD

Sammanfattning

Detta arbete har utförts för att svara på frågan: “Hur mår vårt system?”. Genom att jämföra olika monitoreringsmöjligheter och sätt att hantera loggfiler drogs slutsatsen att Elasticstack är lämpligt för att svara på frågeställningen. Arbetet belyser för- och nackdelar med Elasitcstack, hur systemet kan implementeras, och vad som är viktigt att tänka på. Vidare presenteras resultatet i form av statistiska grafer samt sökbara loggstrukturer. Slutligen diskuteras en strategi för hur skrivning till loggen bör ske, både för att logga mer användbar data, men också för att underlätta användandet av Elasticstack. Ett blad med rekommendationer har tagits fram och hittas under Bilagor.

iii

iv SAMMANFATTNING

Abstract

This project was created to answer the question: “How is our system doing?”. By comparing different monitoring options and ways to handle log files, the conclusion was drawn that Elasticstack is suitable to answer the question in mind. This thesis presents pros and cons with Elasticstack, how the system was implemented, and what’s important to keep in mind. Further, the result is presented as statistical graphs and searchable log-structures. Lastly, a discussion concerning log-strategy is presented. This strategy was created to specify how one should write to a log file to only store relevant data and to ease use of Elasticstack. A sheet with these recommendations is attached as an Appendix.

v

vi ABSTRACT

Innehåll

Förord i

Sammanfattning iii

Abstract v

Figurer xi

Tabeller xiii

Listings xv

1 Introduktion 1

1.1 Vad är loggning? . . . . 2

1.2 Uppdragsgivaren . . . . 2

1.3 Uppdraget . . . . 3

1.4 Mål & Syfte . . . . 3

1.5 Metod . . . . 4

2 Bakgrund 5 2.1 Befintligt system . . . . 5

2.2 Elasticstack . . . . 6

2.2.1 Filebeat . . . . 6

vii

viii INNEHÅLL

2.2.2 Logstash . . . . 7

2.2.3 Elasticsearch . . . . 7

2.2.4 Kibana . . . . 8

2.2.5 Plugins . . . . 8

2.2.5.1 Grok . . . . 8

2.2.5.2 Date Filter Plugin . . . . 9

2.2.5.3 Elasticsearch Output Plugin . . . . 9

2.3 Liknande System . . . . 9

2.3.1 Graylog . . . . 9

2.3.2 Splunk . . . . 10

2.3.3 Octopussy . . . . 10

2.3.4 Fluentd . . . . 10

2.3.5 Zipkin . . . . 10

2.4 Andra använda verktyg . . . . 11

2.4.1 Virtual Box . . . . 11

2.4.2 Grok Debugger . . . . 11

2.5 Reguljära Uttryck . . . . 11

3 Implementation 13 3.1 Testmiljö . . . . 13

3.2 Implementation av Elasticstack . . . . 14

3.2.1 Multiline i Filebeat . . . . 15

3.2.2 Taggning i Logstash . . . . 17

3.2.3 Parsing med Grok . . . . 19

3.2.4 Visualisering i Kibana . . . . 23

3.3 Driftsättning av systemet . . . . 25

3.4 Utvecklingsmöjligheter . . . . 28

INNEHÅLL ix

4 Strategi för loggning 31

4.1 Tidigare forskning . . . . 31

4.1.1 Vanliga misstag . . . . 31

4.1.2 Loggning och arkitektur . . . . 34

4.1.3 Diskussion . . . . 35

4.2 Nulägesanalys . . . . 36

4.3 Förslag på strategi . . . . 36

5 Resultat 39 5.1 Evaluering av monitoreringsverktyg . . . . 39

5.1.1 Jämförelse av verktyg . . . . 41

5.2 Dataanalys . . . . 43

5.3 Tidig användning av systemet . . . . 44

6 Slutsats 47

Förkortningar 50

Litteraturförteckning 52

Bilagor 56

A Förslag på loggnings-strategi 59

B logstash.conf 61

C filebeat.yml 63

D Fler grafer från Kibana 69

x INNEHÅLL

Figurer

2.1 Visualisering av Elasticstacks arkitektur . . . . 6

3.1 Översikt av kommandofönster för Elasticstack . . . . 15

3.2 Översikt över alla logginlägg, uppdelat i olika kategorier. . . . 24

3.3 Antal logg-medddelanden över tid uppdelad i kategorier. . . . 25

4.1 Visualisering av klassisk logg-arkitektur. . . . 34

4.2 Visualisering av arkitektur byggt kring en logg som kommunikationkanal. 35 5.1 Dashboard i Kibana som visar antal logg-meddelanden per tidsenhet. . . 43

5.2 Dashboard i Kibana med en övergripande vy över testdatan. . . . . 44

D.1 Graf från Kibana: Logcount by category . . . . 69

D.2 Graf från Kibana: Logcount by percent . . . . 70

D.3 Graf från Kibana: Logcount over time . . . . 70

D.4 Graf från Kibana: Loglevel over time . . . . 71

D.5 Graf från Kibana: Errors by category . . . . 71

D.6 Graf från Kibana: Warnings by category . . . . 72

D.7 Dashboard från Kibana: Dashboard - Home . . . . 72

xi

xii FIGURER

Tabeller

5.1 Jämförelse av verktygen: Elasticstack, Graylog och Octopussy . . . . . 41 5.2 Jämförelse av verktygen: Splunk, Fluentd, Zipkin . . . . 41

xiii

xiv TABELLER

Listings

2.1 Exempel på reguljära uttryck . . . . 12

3.1 Exempel på struktur för gemensamt logghuvud . . . . 15

3.2 Exempel på egna reguljära uttryck för att hitta tidsstämplar . . . . 16

3.3 Kommandon för plugin-installation för Logstash . . . . 18

3.4 Specificering av in- & out-put för Logstash i logstash.conf . . . . 18

3.5 Filter för borttagning av Filebeats taggar i logstash.conf . . . . 19

3.6 Reguljära Uttryck från Grok . . . . 20

3.7 Filter för parsning av logghuvuden i logstash.conf . . . . 21

3.8 Konvertering av datatyp för fältet payload_size i logstash.conf . . . . . 22

3.9 Omdefiniering av datum i logstash.conf . . . . 22

xv

xvi LISTINGS

Kapitel 1

Introduktion

När ett datorsystem ska underhållas nämns ofta termer som “hygien” och “mående”

- som inte alls har med duschen eller hälsan att göra. Inom datateknik används dessa termer för att enkelt kunna beskriva hur lätt ett system är att underhålla och vad ett systems status är. Uttryckt i dessa termer handlar detta arbete om att ta fram hur ett datasystem mår genom att övervaka händelser i systemet - liknande en pulsmätare.

Vidare undersöker arbetet en aspekt av systemets hygien som ofta blir försummad;

loggning.

I detta kapitel presenteras en överblick av arbetet, uppdraget samt uppdragsgiva- ren. Här presenteras även ämnet loggning och hur ämnet berör projektet. I sektion 5.1 Evaluering av monitoreringsverktyg (sid. 39) diskuteras vilka verktyg som kunde användas för undersökningen av systemet - en jämförelse av olika pulsmätare. I sektio- nerna 5.2 Dataanalys och 5.3 Tidig användning av systemet (sid. 43, respektive sid. 44) visas resultaten av undersökningen. Systemets hygien undersöks i en nulägesanalys och förbättringsförslag redovisas i sektion 4 Förslag på strategi (sid. 31).

1

2 KAPITEL 1. INTRODUKTION

1.1 Vad är loggning?

Loggning, loggar och alla begrepp runtomkring ämnet är ofta uttryckt i vaga termer och kan innebära flera olika meningar beroende på vem som använder begreppen [1].

I detta arbete behandlas loggar där den allra vanligaste tolkningen stämmer in. Andra tolkningar kommer även att diskuteras i sektion 4 Strategi för loggning (sid. 31).

En logg i detta arbete är en textfil som innehåller en mängd logg-meddelanden eller logg-inlägg, som i sin tur är strukturerade beskrivningar om vad som har hänt i ett data- system. Loggning är därmed processen att skapa loggar, vilket i detta arbete görs av datasystem (se sektion 2.1, sid. 5).

Logg-analys som detta arbete främst fokuserar på är processen att ur en eller fler loggar skapa en övergripande bild över händelserna i systemet, sortera och filtrera datan och slutligen upptäcka mönster bland informationen. Logg-analys kan genomföras både manuellt och automatiserad. Manuell logg-analys är kortfattat att en människa läser obehandlade loggmeddelanden och därefter drar slutsatser om systemet. Automatiserad logganalys som används i arbetet innebär att låta en dator läsa loggar och skapa hel- hetsbilder över datamängden i form av statistiska beräkningar. Därefter finns flera olika möjligheter hur slutsatser kan dras ur datamängden, även här är processen uppdelad i manuell och automatiserad analys. Den automatiserade analysen kan innefatta artificiell intelligens som vidare analyserar data, det är ett ämne som arbetet inte berör. Den slutliga manuella processen kommer att diskuteras i sektion 3 Implementation (sid. 13) och sektion 5 Resultat (sid. 39).

1.2 Uppdragsgivaren

ÅF Pöyry AB (hädanefter benämnt som AFRY eller uppdragsgivaren) är ett företag

som intar en ledande roll på den internationella marknaden inom rådgivning, design och

teknik. Företaget skapar lösningar med fokus på hållbarhet och globala trender däribland

1.3. UPPDRAGET 3 digitalisering och urbanisering. Företaget är en arbetsgivare för över 17 000 experter inom industri, infrastruktur och energi [2].

AFRY består av fem divisioner; Infrastructure, Industrial & Digital Solutions, Pro- cess Industries, Energy och Management Consulting. Uppdraget i denna rapport kom- mer att ligga under Digital Solutions och handledas av Jesper Hellberg som är anställd konsult på AFRYs kontor i Karlstad. Det var Hellberg som kom med uppdragsförslaget och hjälpte till under hela projektet vid frågor och problem kring utveckling av monitor- eringssystemet och driftsättningen. Hellberg var även ansvarig för att tillhandahålla materiell utrustning samt programvara och testdata som krävdes för att utföra uppgiften.

1.3 Uppdraget

I Oktober 2018 hölls en presentation på AFRYs kontor i Karlstad om framtida examens- arbeten. En av de presenterade uppgifterna kallades för "Hur mår vårt system?", och handlade om att monitorera systemet som konstruerades för kunden Hertz First Rent A Car AB (hädanefter benämnt som Hertz). Uppgiften skulle innefatta ett sätt att monitorera systemet under drift, underlätta felsökning vid krasch, samt formulera en strategi för att logga. Uppgiften är intressant för uppdragsgivaren då den ska resultera i ett verktyg som uppdragsgivaren sedan kan använda under driften av sina tjänster för att underlätta underhåll och förhoppningsvis minska driftstopp. Mer konkret vad som bör göras är inledningsvis inte specificerat, det var upp till oss tillsammans med uppdragsgivaren att begränsa uppdraget och formulera en specifikation.

1.4 Mål & Syfte

Arbetets mål var att skapa eller implementera en eller flera applikationer för att monitor-

era det befintliga systemet (se sektion 2.1). Monitoreringsverktyget skulle underlätta i

4 KAPITEL 1. INTRODUKTION att skapa en helhetsbild över systemet och underlätta vid övervakning under drift. Dessa krav var ställda för att uppfylla en förhoppning om att minska driftstopp samt underlätta vid underhåll av systemet.

1.5 Metod

Eftersom specifikationen av uppdraget inte påvisade vilka verktyg som skulle användas och implementeras inleddes som första del av arbetet en förundersökning som resulte- rade i en jämförelse av ett antal olika verktyg (se sektion 5.1, sid. 39).

Andra delen av arbetet gick ut på att sätta upp en isolerad testmiljö med en första implementation av det valda verktyget Elasticstack (se sektion 2.2, sid. 6). I denna version användes batch-körning för att analysera testdata. Denna del av arbetet gjordes för att kunna planera och förbereda den tredje delen av arbetet samt få en förståelse för hur Elasticstack fungerar och kan anpasas till uppgiften.

Tredje delen av arbete gick ut på att implementera Elasticstack - med hjälp av kunskaper och lärdomar tagna från tidigare version - på en egen server för att skapa en kontinuerlig monitorering av det befintliga systemets testserver.

Under arbetets genomförande har genom diskussion med handledare Hellberg samt

kollegor och logganalys ett flertal brister i logghanteringen och loggformat upptäckts i

det befintliga systemet. Därav utökades uppdraget till att skapa ett förslag om loggnings-

strategi som uppdragsgivaren kan använda som en grund för att utveckla en strategi om

hur loggar bör hanteras på kontoret (se sektion 4, sid. 31).

Kapitel 2 Bakgrund

I detta kapitel förklaras vilka förutsättningar som låg till underlag för uppdraget, i form av det befintliga systemet som undersöktes. Här finns även information om mjukvaror som användes för att skapa en lösning till uppdraget samt information om andra mjuk- varor med liknande egenskaper som ingick i en jämförelse (se sektion 5.1, sid. 39) för att avgöra vilket eller vilka verktyg som var bäst lämpade för att utveckla en lösning.

2.1 Befintligt system

AFRY tillhandahåller - på uppdrag av biluthyrningsfirman Hertz - en digital lösning för onlinebokning och ärendehantering. Systemet består av flera JBoss-serverar som driver ett flertal java-applikationer, webb- samt apache-serverar. Tanken är att resultatet av projektet skall operera parallellt med dessa applikationer, helt utan att påverka dem.

Gemensamt för alla dessa applikationer är att de skriver till en central serverlogg samt egna loggfiler.

5

6 KAPITEL 2. BAKGRUND

2.2 Elasticstack

Elasticstack - tidigare känt som ELK-stack - är en grupp av modulära verktyg för att övervaka ett system under körning. Det tidigare namnet ELK-stack är ett akronym som kommer av modulerna Elasticsearch, Logstash, och Kibana. Företaget Elastic bytte namn på ELK-stack till Elasticstack när modulen Beats kom till. I detta arbete används Elasticstack och dess olika moduler för att analysera data som befinner sig i olika logg- filer som ligger på Hertz server. Hur beslutet att använda Elasticstack fattades diskuteras under Evaluering av monitoreringsverktyg (se sektion 5.1, sid. 39).

Figur 2.1: Visualisering av Elasticstacks arkitektur

Figur 2.1 ovan visar hur de olika delarna i Elasticstack används i relation till varan- dra. Mer specifikt vad varje modul gör förklaras nedan.

2.2.1 Filebeat

Filebeat är en version av modulen Beats [3]. Beats är en applikation för att läsa in data från olika källor, med möjlighet att göra det samtidigt som källan producerar mer data.

Beroende på vilken typ av källa Beats skall läsa data ifrån finns olika versioner av Beats.

I detta arbete är det främst loggar som är relevant, därför används versionen Filebeat, då den är specialiserad för att läsa direkt från logfiler. Exempel på andra versioner är Packetbeat, för att läsa nätverksdata; Metricbeat, för att läsa av lasten på ett system;

samt Heartbeat, för att mäta bland annat tider som system har varit under körning.

Filebeat i sig är en fristående applikation som på ett enkelt och prestandasnålt sätt

hjälper till att centralisera loggar och filer från nästan obegränsat många källor [3].

2.2. ELASTICSTACK 7 Utöver att kunna komma ihåg var applikationen läste senast efter en systemkrash använder sig Filebeat även av ett mottrycks-sensitivt protokoll för att förebygga krascher.

Vid kommunikation med Logstash eller Elasticsearch kan Filebeat skicka mer data än vad de två förstnämnda applikationerna klarar att hantera; de kan då be Filebeat att sakta ner. När stockningen är utredd kan Filebeat återgå till sin normala läsningsfart och fortsätta skicka vidare data.

2.2.2 Logstash

Logstash är modulen av Elasticstack som sammanslår och processerar data som sedan skickas vidare till sökmotorn (i.e. Elasticsearch). Logstash gör det möjligt att ta in data samtidigt från flera olika källor för att sedan berika och transformera datan innan den indexeras hos sökmotorn [4].

I detta arbete användes logstash främst som en pipeline mellan Filebeats och Elastic- search medan majoriteten av databearbetningen utfördes av Grok (se sektion 2.2.5.1).

2.2.3 Elasticsearch

Elasticsearch är en sök- och analyserings-motor som är den centrala delen i Elasticstack [4]. Verktyget har flera olika användningsområden; allt ifrån säkerhets- och företags- analys till sökning i applikationer och på webbsidor. I detta arbete användes Elastic- search som analyseringsverktyg för loggdata. Innan rå data indexeras i Elasticsearch parsas, normaliseras och berikas den av verktyg som Filebeat och Logstash. Efter in- dexeringen i Elasticsearch kan komplexa frågor ställas mot motorn på liknande sätt som mot databaser.

Data som indexeras i Elasticsearch blir en del av så kallade Elasticsearch Index som

är en kollektion av relaterade dokument i JSON format . Verktyget använder sig av något

som kallas inverted index som innebär att varje unikt ord i ett dokument listas och att

8 KAPITEL 2. BAKGRUND varje dokument där ordet förekommer identifieras. Detta index skapas samtidigt som Elasticsearch går igenom indexeringsfasen och lagrar all data som tas emot ifrån vald källa (i detta fall logstash) [4].

2.2.4 Kibana

Kibana är ett grafiskt verktyg som direkt bygger på Elasticsearch [5]. Genom att på ett stilrent sätt visualisera all data som sparas i Elasticsearch tillåter Kibana användaren att enkelt hitta i stora mängder data. Kibana gör det möjligt för användaren att söka i och filtrera stora datamängder på kort tid med hjälp av taggar som är fäst på den sorterade datan som finns lagrad i Elasticsearch.

2.2.5 Plugins

Elasticstack är som tidigare nämnt en grupp verktyg som till stor grad är modulariserade.

Detta innebär att verktygen är anpassade till att kunna användas både med varandra men är även relativt enkla att konfigurera till att arbeta med andra programvaror. Den sistnämnda egenskapen resulterar i en rad olika plugins till de olika modulerna i Elastic- stack som kan användas för att anpassa implementationen på det sättet som krävs av uppgiften. Här följer de olika plugins som användes för att med Elasticstack skapa en lösning till uppdraget.

2.2.5.1 Grok

Grok är ett plugin till Logstash som används för filtrering av data [6]. Groks uppgift är

att parsa texten i loggfilerna så att datan kan indexeras som önskad med olika taggar i

Elasticsearch. Med andra ord så omvandlar Grok texten som är skapad för att den ska

läsas av människor till strukturerad och sökbar data för maskiner. Detta gör Grok med

hjälp av reguljära uttryck (se sektion 2.5, sid. 11).

2.3. LIKNANDE SYSTEM 9 2.2.5.2 Date Filter Plugin

Date Filter Plugin är ett plugin till Logstash (se sektion 2.2.2) som tillåter manipulation av fältet som innehåller ett inläggs tidsstämpel. Med hjälp av filtret kunde tidsstämpeln, som automatiskt sätts av Filebeat (se sektion 2.2.1) till inläsningstiden, sättas till den tiden då inlägget skapades [7]. Tiden när ett loginlägg skapades är sparad som en tidsstämpel i början av varje logginlägg i det befintliga systemet.

2.2.5.3 Elasticsearch Output Plugin

Elasticsearch Output Plugin är ett plugin till Logstash som används för att Logstash ska kunna skicka utdata till Elasticsearch. Pluginet tillåter Logstash att kommunicera med Elasticsearch med hjälp av HTTP [8].

2.3 Liknande System

I arbetet används Elasticstack för att analysera datan. Här beskrivs liknande mjukvara som kan genomföra uppgiften som Elasticstack utför i arbetet men som valdes bort, se sektion 5.1 Evaluering av monitoreringsverktyg (sid. 39) för vidare diskussion om varför.

2.3.1 Graylog

Graylog är en grupp av verktyg som fungerar väldigt likt Elasticstack. Delarna som ingår

i Graylog är Elasticsearch, MongoDB, Graylog main server samt Graylog web interface

[9]. I Graylog används Elasticsearch som lagringspunkt för inkommande loggmeddelan-

den, MongoDB som lagring för så kallad meta-data (i.e. konfigurationer), Graylog main

server agerar som mellanhand för alla delar i systemet medan Graylog web interface är

det grafiska användargränssnittet [10].

10 KAPITEL 2. BAKGRUND

2.3.2 Splunk

Splunk är ett verktyg som löser samma problem som Elasticstack och Graylog. De tre huvudkomponenterna i Splunk är dess forwarder, indexer och search head. Forwarder skickar data till olika indexers som lagrar och indexerar data samt svarar på sökför- frågningar. Search head är frontend av verktygets webbgränssnitt där komponenterna kan föras samman från olika servrar eller delas upp till olika servrar [11].

2.3.3 Octopussy

Octopussy är ett monitoreringsverktyg som är specialiserad på så kallade sysloggar som skapas av enheter som supportar syslog protokollet. Huvuduppgiften av Octopussy är att alarmera administratörer om olika event såsom systemavbrott, attacker på system eller fel i applikationer [12].

2.3.4 Fluentd

Fluentd är ett verktyg som uppfyller samma funktioner som Logstash och Filebeat genom att läsa in data från olika källor och konvertera dessa till JSON format som sedan kan skickas till verktyg för monitorering och analys som exempelvis Elasticsearch [13].

Filosofin bakom Fluentd är att skapa ett väldigt snabbt och resurssnålt sätt att samla data och skicka det mellan applikationer.

2.3.5 Zipkin

Zipkin är en applikation som används för distribuerad tracing och identifikation av fördröjningsproblem. Applikation fungerar på det sättet att det fästs unika ID:n på samt- liga förfrågningar bland serverapplikationer som följer med meddelanden hela vägen.

Därefter samlar Zipkin ihop data från dessa ID:n för att få information om bland annat

2.4. ANDRA ANVÄNDA VERKTYG 11 fördröjning. Därefter tillåts användaren att analysera datan i ett grafiskt användargräns- snitt [14].

2.4 Andra använda verktyg

Under arbetes gång har fler verktyg förutom Elasticstack använts, dessa verktyg beskrivs här för att ge läsaren en bättre förståelse av lösningsvägen för uppdraget.

2.4.1 Virtual Box

Virtual Box är ett virtualiseringsverktyg som tillåter användare att emulera virtuella maskiner med olika operativsystem. Till exempel så tillåter Virtual Box att emulera en virtuell maskin med operativsystemet Linux på en fysisk maskin med operativsystemet Windows 10 [15].

2.4.2 Grok Debugger

Grok Debugger är ett onlineverktyg som hjälper vid konstruktion av reguljära uttryck.

Både med hjälp av de mönster som finns som en del av Grok (se sektion 2.2.5.1, sid. 8) och genom att skriva egna reguljära uttryck hjälper hemsidan att upptäcka fel i uttrycken [16].

2.5 Reguljära Uttryck

“Regular Expressions are patterns of characters that match, or fail to match, sequences of characters in text.” - Watt, A. (2005) [17].

Reguljära uttryck är som Watt beskriver mönster av olika tecken, där vissa tecken

och teckenkombinationer har speciellt innebörd. Uttrycken kan inte användas för sig

själva utan måste användas i script- eller programmeringsspråk. Då uttrycken matchar

12 KAPITEL 2. BAKGRUND respektive inte matchar skapar de en möjlighet att tillåta mönstermatchning och sökning i texter [17]. Tekniken är oerhört kraftfull och oundviklig inom dagens stränghantering, då reguljära uttryck är det effektivaste sättet att kunna söka i och därmed kunna utföra komplexa operationer på strängar. I Listing 2.1 visas ett enklare exempel på hur reguljära uttryck fungerar.

Förklaring till resultaten av listing 2.1: “ˆ” symbolen betyder att raden måste börja med nästföljande symbol; i detta fall bokstaven “s”. “.” symbolen är en så kallad “wild- card” och matchar med samtliga tecken utom radbrytningar, “*” anger mängden av före- gående karaktär, just “*” betyder 0 eller fler. På liknande sätt kan obegränsade mängder av mönster skapas för att kunna matcha eller ignorera värden i strängar. Mönstren är inte heller begränsade till endast enstaka bokstäver som “s” utan hela ord och texter fungerar på samma sätt. Exempelvis matchar strängen “sand” med både uttrycken “s.*”

som i listing 2.1 men även med mönstret “san.?”. “?” symbolen betyder “en eller ingen”.

Reguljära uttryck ger även möjlighet att kunna matcha siffror och talföljder; mönst- ret “\d” matchar enstaka siffror mellan 0 och 9 medan “\d*” matchar när 0 eller fler siffror följer efter varann. Den exakta implementationen av reguljära uttryck varierar lite mellan olika programmerings- och scriptspråk men grunderna brukar vara de samma.

R e g u l j ä r t u t t r y c k : ^ s .∗

Exempel s t r ä n g a r −> r e s u l t a t

s a n d −> True

s y s t e r −> True

a n d e r s −> F a l s e

Listing 2.1: Exempel på reguljära uttryck

I detta arbete användes reguljära uttryck för att tillåta en maskin att tolka och läsa in

information i logg-filer som är strukturerad för att människor skall läsa den (se sektion

3.2.3, sid. 19).

Kapitel 3

Implementation

I detta kapitel beskrivs hur arbetet stegvis genomfördes i iterationer. Huvudsakliga tanken med kapitlet är att kunna följa samma tillvägagångssätt för att kunna få liknande resultat från ett liknande system. I kapitlet diskuteras en av de största utmaningarna som stötts på under arbetets gång, vilket var att kunna parsa logghuvuden med hjälp av Grok.

Vidare så kommer även rekommendationer och relevans på vilken data som bör parsas och sedan visualiseras i Kibana att diskuteras. Kapitlet följer arbetets kronologiska ordning för att påvisa flödet av arbetsmomenten.

3.1 Testmiljö

Av uppdragssgivaren tilldelades två bärbara datorer som användes under hela projektet.

Datorerna är av märket DELL och kör operativsystemet Windows 10. Något som tidigt togs hänsyn till var att servern som tillhandahåller de webbapplikationer vi arbetar mot kör Linux istället för Windows. Då båda arbetarna är kunniga i att använda Linux beslutades i ett tidigt skede att det är lämpligast att också arbeta i en Linuxmiljö. Detta är ingenting som är nödvändigt, men underlättar arbetsprocessen och simuleringen av den riktiga miljön. Det är därför värt att i ett tidigt skede tänka över var lösningen skall

13

14 KAPITEL 3. IMPLEMENTATION appliceras i slutändan och ta hänsyn till detta redan från början.

Datorerna har restriktioner på sig som inte tillåter att andra operativsystem än Win- dows används. Därav skapades en virtuell maskin med hjälp av programmet Virtual Box (se sektion 2.4.1, sid. 11). På denna virtuella maskin installeradess operativsystemet Kubuntu, som är en distribution av Linux. Denna virtuella maskin användes under hela utvecklingsprocessen som huvudsaklig arbetsmiljö.

Eftersom projektet i första hand utvecklas som en PoC (Proof of Concept) i en lokal testmiljö sker i denna iteration av projektet ingen läsning av loggfiler i drift. Det som istället gjordes var att kopiera de 400 senaste serverloggarna, samt några hundra apache- loggar till testmiljön som testdata för att kunna utveckla lösningen kring den befintliga loggstrukturen. Skulle behovet uppstå att hantera fler eller andra typer av loggar stod handledare Hellberg för tilldelning av ny testdata.

3.2 Implementation av Elasticstack

På den virtuella maskinen installerades och testades sedan hela Elasticstack. Inlednings- vis laddades Elasticsearch och Filebeat ned. Elasticsearch kräver ingen installation i sig, det startas istället endast genom att med kommandoprompten ställa sig i den nerladdade mappen och starta processen med hjälp av kommandot:

./ bin / E l a s t i c s e a r c h

Alla andra moduler i Elasticstack startas på motsvarande sätt. För att få en tydlig över-

blick över vad som sker i varje enskild modul kördes varje modul i ett eget kommando-

fönster. En bild av detta visas i figur 3.1. Denna bild motsvarar dock en senare iteration

då alla fyra moduler var implementerad i testmiljön.

3.2. IMPLEMENTATION AV ELASTICSTACK 15

Figur 3.1: Översikt av kommandofönster för Elasticstack

I denna iteration användes Filebeat för att läsa radvis från en enda lokal textfil med loggar och skicka data direkt till Elasticsearch. Resultatet av detta blev ett enda inlägg i Elasticsearch med alla tusentals rader logg som innehåll. Problemet här var att Filebeat ej var konfigurerat för multiline läsning.

3.2.1 Multiline i Filebeat

För att Filebeat skall kunna ta hand om loggmeddelanden som sträcker sig över flera rader krävs att man specificerar i Filebeats yml-fil att man dels vill använda sig av multiline, och dels vad som avgör att ett nytt loggmeddelande börjar. Efter observationer av testdatan kunde slutsatsen dras att alla logginlägg i serverloggen har samma struktur.

Denna struktur ser ut enligt följande listing:

2019 -12 -31 2 3 : 5 9 : 5 9 , 1 2 3 I N F O [ s 8 s j e i d U :66 Ui : g 1 2 G : s i f 7 H E 0 2 L k R 6 ] [ s e r v i c e . at . s e r v e r ] ( 0 . 0 . 0 . 0 : 1 2 3 4 )

Listing 3.1: Exempel på struktur för gemensamt logghuvud

16 KAPITEL 3. IMPLEMENTATION Som visat ovan i listing 3.1 börjar varje nytt inlägg med en tidsstämpel av ett spec- iellt format. För att Filebeat skall känna igen tidsstämpeln krävs att denna specificeras med reguljära uttryck.

# c a p t u r e d a t e s of t y p e ’2019 -01 -01 0 1 : 0 2 : 0 3 , 4 5 6 ’ (^\ d {4} -\ d {2} -\ d {2} \ d { 2 } : \ d { 2 } : \ d {2} ,\ d { 3 } )

# c a p t u r e d a t e s of t y p e ’2019 -01 -01 0 1 : 0 2 : 0 3 + 0 2 0 0 ’ (^\ d {4} -\ d {2} -\ d {2} \ d { 2 } : \ d { 2 } : \ d { 2 } \ + \ d { 4 } )

# c a p t u r e s d a t e s of t y p e ’[ Tue Oct 01 0 2 : 3 4 : 0 5 2019] ’ ( ^ \ [ [ M T W F S ][ a - z ] { 2 } [ J F M A S O N D ][ a - z ] { 2 } \ d {2} \ d { 2 } : \

d { 2 } : \ d {2} \ d { 4 } \ ] )

Listing 3.2: Exempel på egna reguljära uttryck för att hitta tidsstämplar

Som tidigare nämnt bestod all testdata av olika typer av loggfiler, där olika strukturer följs. I listing 3.2 visas hur de unika tidsstämplarna enligt de olika stukturerna fångades av reguljära uttryck. Genom att specificera i Filebeats yml-fil att det skall ske en radbryt- ning vid varje förekomst av någon av dessa tidsstämplar kan man säkerställa att varje unikt logginlägg separeras och hanteras enskilt. Exemplet på logghuvudet i listing 3.1 motsvarar det översta reguljära uttrycket i listing 3.2. De två nedre uttrycken är exempel på andra typer av tidsstämplar som förekommer i en senare iteration av projektet.

Då problemet med multiline var löst bestod det skapade indexet i Elasticsearch inte längre bara av ett enda inlägg, utan lika många inlägg som det fanns individuella skrivningar i den lokala textfilen med loggar. Varje inlägg innehöll mycket information.

Som tidigare beskrivet (se sektion 2.2.1, sid. 6) taggar Filebeat inläggen med den in-

formation som finns tillgänglig. I detta skede fanns inte mer information tillgänglig än

data gällande själva textfilen. De taggar som Filebeat då kunde sätta på varje inlägg

innefattade bland annat operativsystemet, vilken tid filen lästes, vad filen hette, vad

3.2. IMPLEMENTATION AV ELASTICSTACK 17 den inloggade användaren på datorn hette, vilken version av Filebeat som användes, samt med vilken offset i filen loggraden lästes ifrån. Mycket av denna information var icke relevant. För att kunna hantera de olika taggarna, samt sätta på egna behövdes programmet Logstash.

3.2.2 Taggning i Logstash

Vid läsning av stor mängd testdata framgick att lagringen på disk för alla inlästa och taggade logginlägg krävde nästan dubbelt så mycket utrymme som de ursprungliga text- filerna. Något som tidigare hade satts som ett kriterie vid evalueringen (se sektion 5.1, sid. 39) var hur stort utrymme på disk som krävs. Därför togs beslutet att ta bort nästan alla av de taggar som Filebeat själv sätter på varje inlägg. Varje tagg i sig tar inte upp mer än några få byte, men med miljontals logginlägg blir det snabbt stora datamängder.

Dessa taggar är som standard indelade i tre huvudsakliga kategorier. Kategorin host innehåller information om datorn som kör Filebeat, agent som innehåller information om användaren på datorn, samt ecs som innehåller information om tid vid läsning av fil. Tyvärr går det inte att specificera i Filebeat att taggarna inte skall skrivas, och inte heller få ut viktig information ur loggmeddelanden, vilket leder till nästa steg i implementationen: Logstash (se sektion 2.2.2, sid. 7).

Som visat i figur 2.1 (sid. 6) är Logstash steget mellan Filebeat och Elasticsearch

vars uppgift är att processera informationen Filebeat läst in innan den lagras i Elastic-

search. Elasticstack är ett väldigt modulärt system som tillåter alla sina moduler att

köras fristående. Modulärt till den grad att de olika modulerna inte som standard har

stöd för att kommunicera med varandra, där av krävs plugins (se sektion 2.2.5, sid. 8)

för att stacken skall fungera så som bilden visar. De olika pluginsen installeras enkelt

med kommandon visade i listing 3.3 nedan.

18 KAPITEL 3. IMPLEMENTATION

s u d o ./ bin / l o g s t a s h - p l u g i n i n s t a l l l o g s t a s h - input - b e a t s s u d o ./ bin / l o g s t a s h - p l u g i n i n s t a l l l o g s t a s h - output -

e l a s t i c s t a c k

s u d o ./ bin / l o g s t a s h - p l u g i n i n s t a l l l o g s t a s h - filter - g r o k s u d o ./ bin / l o g s t a s h - p l u g i n i n s t a l l l o g s t a s h - filter - d a t e

Listing 3.3: Kommandon för plugin-installation för Logstash

När Logstash är installerat skall modulen även konfigureras, detta görs i filen log- stash.conf. För att specificera vart data skall komma in och vart det skall skickas ut användes i detta exempel konfigureringen i listing 3.4.

i n p u t { b e a t s { p o r t = > 5 0 4 4 }}

o u t p u t {

e l a s t i c s e a r c h {

h o s t s = > " l o c a l h o s t : 9 2 0 0 "

m a n a g e _ t e m p l a t e = > f a l s e

i n d e x = > " % { [ @ m e t a d a t a ][ b e a t ]} -%{[ @ m e t a d a t a ][ v e r s i o n ]} -%{+ Y Y Y Y . MM . dd }"

} }

Listing 3.4: Specificering av in- & out-put för Logstash i logstash.conf

Som visat i listing 3.4 specificeras även vilket index som inläsningen skall sparas i. Detta

möjliggörs av Elasticsearch output plugin. I detta fall skapas ett nytt index för varje

dag, och döps efter dagens datum. Detta underlättar för att underhålla datamängden

som lagras i Elasticsearch och tillåter automatisk borttagning av index som är äldre

än ett visst datum. Åter igen ett sätt att spara stora mängder lagringsutrymme. Detta

tillsammans med att ta bort vissa taggar som diskuterades tidigare i denna sektion gav

3.2. IMPLEMENTATION AV ELASTICSTACK 19 stora resultat på mängden lagringsutrymme. Hur dessa taggar togs bort visas i listing 3.5.

f i l t e r { m u t a t e {

r e m o v e _ f i e l d = > [ " h o s t " , " a g e n t " , " ecs " ] }

}

Listing 3.5: Filter för borttagning av Filebeats taggar i logstash.conf

3.2.3 Parsing med Grok

Som tidigare beskrivet (se sektion 2.2.5.1, sid. 8) så är Grok ett plugin till Logstash, till för att parsa nyckelord ur texter. Grok använder sig av reguljära uttryck för att hitta och plocka ut dessa nyckelord. Grok har support för många typer av mönster redan från början. Colin Surprenant, en av skaparna av Grok, listar på sin githubsida [18] alla mönster som finns fördefinerade. Dessvärre skiljer sig testdatans mönster från de som finns fördefinerade och kan därför inte läsas med de mönster som redan finns i Grok. Det som i första skedet var intressant att parse:a var huvudet av varje loggmeddelande. Det verktyget utvecklarna på AFRY använder för att skriva till loggen heter SLF4J och med deras inställningar får logghuvudet det format som presenteras i listing 3.1 på sidan 15.

De individuella delarna i logghuvudet är i allra högsta grad av intresse för inläsning.

Att kunna sortera logg-meddelanden med avsende på vilken service det är som skrivit

kan underlätta mycket vid felsökning. Det Grok kunde erbjuda var läsning av vissa av

de individuella delarna av detta format. Som visat på Surprenants github [18] har Grok

fördefinerad reguljära uttryck och kan med dem läsa både timestamp, log_level, och

UUID som finns i detta logghuvud, som beskriver tiden då logg-meddelandet skrevs,

kategori av loggmeddelandet respektive ett unikt ID. Det Grok inte kunde känna igen

var det sista fältet inom parenteser som vi kallar thread_id; samt fältet som innehåll-

20 KAPITEL 3. IMPLEMENTATION er information om från vilken service ett logg-meddelande härstammar som vi kallar log_category. Lösningen på detta var att plocka ut alla tecken (oavsett vad de är) mellan parenteserna som omsluter fälten i formatet och döpa de till just thread_id respektive log_category. Hur detta logghuvud specificerades i ett reguljärt uttryck med hjälp av Grok visas överst i listing 3.6.

S E R V E R _ L O G H E A D %{ T I M E S T A M P _ I S O 8 6 0 1 : t i m e s t a m p }%{ S P A C E }%{

L O G L E V E L : l o g _ l e v e l }%{ S P A C E } \ [ ( % { U U I D : u u i d }) ? \ ] % { S P A C E } \ [ % { D A T A : l o g _ c a t e g o r y } \ ] % { S P A C E } \ ( % { D A T A : t h r e a d _ i d }\) D A T E S T A M P _ A P A C H E %{ DAY } %{ M O N T H } %{ M O N T H D A Y } %{ T I M E } %{ Y E A R } A P A C H E _ A C C E S S _ L O G H E A D %{ T I M E S T A M P _ I S O 8 6 0 1 : t i m e s t a m p }%{ S P A C E

}\ " %{ I P : i p _ s e n d e r }( ,%{ S P A C E }%{ I P : i p _ r e c e i v e r }) *\ " %{ S P A C E } -%{ S P A C E }%{ I N T : d e l a y }

A P A C H E _ E R R O R _ L O G H E A D \ [ % { D A T E S T A M P _ A P A C H E : t i m e s t a m p } \ ] % { S P A C E } \ [ % { L O G L E V E L : l o g _ l e v e l } \ ] % { S P A C E } ( \ [ c l i e n t %{

I P : c l i e n t _ i p } \ ] ) ?

Listing 3.6: Reguljära Uttryck från Grok

I samband med utvecklingen av de reguljära uttrycken för Grok togs även steget in i nästa iteration av projektet. Tidigare hade endast logginlägg skrivna till server- loggen tagits hänsyn till, härefter lästes även inlägg från apache-loggen. Dessa logg- typer skiljer sig något, inte minst i formatet av logghuvudet. Detta krävde då speci- ella reguljära uttryck för att matcha även dessa logghuvuden. Den ursprungliga ser- verloggens logghuvud motsvaras av den översta delen av listing 3.6 som defineras som “SERVER_LOGHEAD”. De tre nästkommande definitionerna motsvarar de nya loggtyper som tillkom. Att skriva dessa reguljära uttryck kan vara påfrestande och svårt att förstå sig på. För att underlätta utvecklingen av mönstren som Grok skulle använda utnyttjades webbverktyget Grok Debugger (se sektion 2.4.2, sid. 11).

För att sedan applicera dessa reguljära uttryck behövde logstash konfigureras för att

3.2. IMPLEMENTATION AV ELASTICSTACK 21 använda dem. Uttrycken specificerades i en fil utan filändelse och placerades i en egen mapp där logstash är installerat.

f i l t e r { g r o k {

p a t t e r n s _ d i r = > [ " . / c o n f i g / p a t t e r n s "]

m a t c h = > { " m e s s a g e " = > " ( % { S E R V E R _ L O G H E A D } | % {

A P A C H E _ A C C E S S _ L O G H E A D } | % { A P A C H E _ E R R O R _ L O G H E A D }) "

} }

}

Listing 3.7: Filter för parsning av logghuvuden i logstash.conf

Listing 3.7 visar hur de reguljära uttrycken implementeras i filen logstash.conf.

Notera att de olika definitionerna för logghuvuden är separerade med “|”-tecken som motsvarar en “eller” operator.

Logstash standard utmatning är för varje rad ett individuellt event i json format [19] där varje tagg definieras enligt “key: value”, definitionen kan även observeras i listing 3.6. När Grok har applicerat sina filter kommer även de nya fälten definieras på samma sätt i logstash och elasticsearch vilket tillåter användning, sökning, och sortering.

I varje event i json-filen specificeras också vilken datatyp varje tagg har. Som standard

är definitionen av typen string. För att bättre kunna utnyttja den inlästa datamängden är

det fördelaktigt att tilldela varje tagg en lämplig datatyp. Ett exempel på detta är taggen

payload_size som är en del av logghuvudet i apache-loggen. Denna tagg motsvarar

storleken på det paket som skickades då logginlägget skrevs. För att bättre kunna hantera

denna tagg är det fördelaktigt att lagra den som ett heltal istället för en string. För att

göra denna konvertering av datatyp krävs att detta specificeras i logstash.conf enligt

exemplet i listing 3.8.

22 KAPITEL 3. IMPLEMENTATION

f i l t e r { m u t a t e {

c o n v e r t = > { " p a y l o a d _ s i z e " = > " i n t e g e r " } }

}

Listing 3.8: Konvertering av datatyp för fältet payload_size i logstash.conf

f i l t e r { d a t e {

m a t c h = > [ " t i m e s t a m p " , " yyyy - MM - dd HH : mm : ss , SSS " , "

yyyy - MM - dd HH : mm : ssZ " , " EEE MMM dd HH : mm : ss y y y y "

]

l o c a l e = > en

r e m o v e _ f i e l d = > t i m e s t a m p }

}

Listing 3.9: Omdefiniering av datum i logstash.conf

Listing 3.9 är ett ett annat exempel på konvertering av en typ av tagg. Alla event lagrade i en json-fil har som standard en tidsstämpel. Denna tidsstämpel motsvarar den tid då Filebeat har läst loggen, inte när loggen faktiskt är skriven. I normala fall när Elasticstack appliceras live på en aktiv server är detta inget problem, men i denna PoC används statisk data från tidigare datum som inte alls stämmer överens med när datan läses. För att lösa detta kan tidsstämpeln som parsas från logginlägget konverteras till typen timestamp och låta denna ersätta den ursprungliga tidsstämpeln. För att göra denna konvertering krävs ett plugin till logstash (se sektion 2.2.5.2, sid. 9). Detta plugin kan även hantera de olika formaten på tiden som de olika typerna av loggfilerna har.

Även detta framgår i listing 3.9. Det är även nämnvärt att denna konvertering kan vara

3.2. IMPLEMENTATION AV ELASTICSTACK 23 användbar i driftsatt miljö också. Då läsning av tidigare loggdata kan förekomma, eller om Elasticstack under en kort period varit avstängd är det i allra högsta grad relevant att tagga data med den tid då den faktiskt skrevs och inte när den lästes.

Gemensamt för många av de exemplen i listings ovan är att de är definierade inom filter i logstash.conf. För att förtydliga krävs inte en ny filter-definition för varje funk- tion, det är möjligt att lägga både mutate, date och grok funktionerna inom samma filter.

För fullständigt exempel på filen logstash.conf och exempel på detta, se Bilaga B.

3.2.4 Visualisering i Kibana

Kibana ger tillgång till ett grafiskt användargränssnitt som kan användas för att skapa grafer (se sektion 2.2.4, sid. 8). Denna funktionalitet utnyttjades under arbetets gång för att ge exempel för uppdragsgivaren om hur data kan analyseras med hjälp av Kibana och Elasticsearch samt ge en möjlighet att se vad för information i datan som är relevant. Ett fåtal av graferna som skapades under arbetets gång är graferna som kan ses i Figur 3.2.

Mer grafer kan ses i Bilaga D (sid. 69).

Graferna skapas i Kibana via visualize funktionaliteten. Där ges möjligheten att

filtrera data efter index och olika taggar samt låter användaren välja mellan olika förde-

finierade graftyper och visualiseringar. Användaren ges även möjlighet att skapa egna

typer av visualiseringar. Inställningar för olika visualiseringar kan även sparas för att

kunna användas i senare skeden och sammanställas på så kallade dashboards (se sektion

5.2, sid. 43). Utöver detta är samtliga grafer i Kibana interaktiva och låter användaren

filtrera datamängden genom ett fåtal klick på grafer.

24 KAPITEL 3. IMPLEMENTATION

Figur 3.2: Översikt över alla logginlägg, uppdelat i olika kategorier.

Värden som ansågs som särskilt intressanta för uppdraget var log_category samt

log_level (se sektion 3.2.3). Dessa värden har i graferna i figur 3.2 satts i förhållande

till antalet förekomster i olika kombinationer. Vidare har antalet loggmeddelanden satts

i förhållande till tidpunkterna när meddelandena skrevs (se figur 3.3).

3.3. DRIFTSÄTTNING AV SYSTEMET 25

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

3.4 Utvecklingsmöjligheter

Trots att arbetet i projektets syfte ansågs vara klart fanns fortfarande stora förbätt- ringsmöjligheter. Som tidigare beskrivet finns fler typer av loggar med olika struktur.

Ett inledande förslag är att parsningen kan vidareutvecklas genom att lägga till fler mönster av fält som är av särskild intresse i mönster-filen för Grok. Hur detta genomförs förklaras genomgående i sektion 3.2.3 på sida 19. En sammanfattning av stegen som bör genomföras följer i listan nedan.

1. Lägg till filvägen till den nya loggfilen i filebeat.yml 2. Specificera formatet för multiline i filebeat.yml

3. Om formatet för tidsstämpeln är annorlunda, specificera det nya formatet i logstash.conf

4. Konstruera ett nytt Grok filter för att parsa de individuella delarna i logghuvudet.

5. Eventuellt konstruera ytterligare ett Grok filter för att parsa relevanta delar som ofta förekommer i loggmeddelandet.

6. Om nya typer av fält parsas, ge dem en lämplig datatyp.

7. Skapa nya visualiseringar i Kibana för att presentera ny data.

Vidare så kan Metricbeat (se sektion 2.2.1, sid. 6) implementeras för att kunna få

övervakning av en serverns status. Information som i detta fall skulle vara av intresse

att få ifrån servern där Elasticstack körs är det tillgängliga lagringsutrymmet och hur

mycket processorn får jobba. Att få information om lagringsutrymme från servern kan

underlätta vid bestämning av rotationscykeln för index i Elasticsearch. För att hitta

en balans mellan hur mycket som bör skriva till loggen och hur länge gamla loggar

3.4. UTVECKLINGSMÖJLIGHETER 29 skall sparas kan Metricbeat användas för att ge en direkt varning, både vid bristande lagringsutrymme, men också vid överbelastning.

Som standard saknar kommunikationen i Elasticstack kryptering, men har stöd för att SSL skall kunna sättas upp mellan de olika modulerna. Då systemet körs på ett lokalt subnät där en VPN-tunnel krävs för åtkomst har implementation av kryptering lämnats ur detta arbete men är något vi rekommenderar. Vidare saknar Kibana möj- lighet för hantering av användare vilket kan vara en potentiell säkerhetsrisk. I nuläget krävs en VPN-tunnel för att kunna komma åt användargränssnittet vilket negerar även denna säkerhetsläcka men att implementera användarhantering är något som är starkt rekommenderat, Kibana erbjuder stöd för ett flertal olika användarhanteringssystem.

Vidare så erbjuder Elastic en ytterligare modul till Elasticstack vid namn X-Pack som erbjuder mer funktionalitet som till exempel ytterligare säkerhetsåtgärder, alerting och machine learning. X-Pack är en modul som ej tillhör Elasticstacks gratisversion, därför har arbetet ej inkluderat en evaluering av dess användbarhet.

Ett råd för vidare implementation är att ställa in de delarna av Elasticstack som

ligger på servern till att automatiskt starta vid systemstart ifall servern kraschar eller ifall

servern kräver en omstart. Inställningar angående timestamp omvandling som beskrivs i

sektion 3.2.3 Parsing med Grok på sidan 19, tillåter att loggmeddelanden som skapades

under tiden logstash varit ur drift kan läsas i efterhand utan konflikter.

30 KAPITEL 3. IMPLEMENTATION

Kapitel 4

Strategi för loggning

Som tidigare nämnt i kapitlet Implementation (se sektion 3, sid. 13) och som kommer diskuteras vidare i kapitlet Resultat (se sektion 5, sid. 39) uppstod både problem och insikter under projektets gång. Mycket av det som kommit fram har pekat mot att mycket kan förbättras redan vid skrivning till loggen. Av denna anledning har vi valt att inkludera en förundersökning i hur loggning bör genomföras för att få ett bra resultat, både med och utan Elasticstack som hjälpmedel.

4.1 Tidigare forskning

I denna sektion sammanfattas information om loggning, logg-analys och logg-strategi från böckerna Logging and log managemanet av Chuvakin et al. [1] samt I heart Logs av Kreps, J. [23].

4.1.1 Vanliga misstag

I boken Loggning and log management [1] skriver Chuvakin et al. om sex lagar inom loggning samt vanliga misstag.

31

32 KAPITEL 4. STRATEGI FÖR LOGGNING 1. Insamlingslagen

“Do NOT collect log data that you NEVER plan to use.”

Samla aldrig logg-data som aldrig kommer att användas. En enkel princip som förhindrar att för mycket data döljer större problem i ett system och sparar lag- ringsutrymme.

2. Lagringslagen

“Retain log data for as long as it is conceivable that it can be used or longer if prescribed by regulations.”

Lagra logg-data så länge som den kan användas om inte andra regulationer säger annat. Att lagra logg-data för länge är endast slöseri på lagringsutrymme. Att lagra data under för kort tid kan innebära att kritisk information om systemet och händelser kan gå förlorad.

3. Monitoreringslagen

“Log all you can (which is as much as possible), but alert only on what you must respond (which is as little as possible).”

Logga så mycket som möjligt men alarmera endast när det behövs, vilket är så lite som möjligt. Lagen bör endast beaktas i samband med de andra lagarna på listan, då effektivitet av denna lag kräver att insamlingslagen används effektivt.

4. Tillgänglighetslagen

“Dont pay to make your logging or monitoring system more available than your business systems”

Loggnings- eller monitoreringssystemet bör ej vara mer tillgänglig än det faktis- ka systemet som det tillhör. Detta då loggar kan innehålla mycket information om systemet, dess arkitektur och dess svaga punkter, vilket som är potentialla säkerhetsläckor.

5. Säkerhetslagen

4.1. TIDIGARE FORSKNING 33

“Dont pay to protect your log data more than you pay to protect your critical business data.”

Logg-datan behöver inte skyddas mer än systemet det tillhör. Då logg-datan ska- pas som en biprodukt av systemet kan datan inte vara säkrare skyddat än själva systemet i sig.

6. Förändringslagen

“Logs sources, log types, and log messages change.”

Logg-data och den struktureras i meddelanden kan förändras så all information för att identifiera logg-meddelandet bör inkluderas i meddelandet för att ge ut- rymme till att ny data kan skapas av systemet.

Att ignorera de sex lagarna är först och främst ett typiskt problem enligt Chuvakin et al. [1]. Andra misstag är följande:

• Inte logga alls eller för lite

• Inte kolla på loggdata (även problem vi skådat)

• Lagrar för kort tid

• Prioritering före samling

• Endast söka efter kända fel - Loggar är väldig användbara och kan berätta myck- et mer än vad man tror. Att endast använda loggar till att leta efter fel man vet inträffat är ett stort misstag.

Chuvakin et al. nämner även vilka aspekter som bör tas hänsyn till när logg-meddelanden skapas. Författarna tar upp sex frågor som alltid bör besvaras när ett nytt logg-meddelande skrivs:

• “Who was involved?”

34 KAPITEL 4. STRATEGI FÖR LOGGNING

• “What happened?”

• “Where did it happen?”

• “When did it happen?”

• “Why did it happen?”

• “How did it happen?”

4.1.2 Loggning och arkitektur

Loggning är inte begränsad till att användas som en samling av historiskt data om händelser i ett system utan kan även användas till en grund för ett helt systems arkitektur [23].

Kreps beskriver i boken I Heart Logs [23] hur loggar kan användas som en kom- munikationskanal och som en centraliserad samlingspunkt för samtliga händelser i ett system som består av flera olika applikationer och tjänster liknande ett pub/sub system . Skillnader mellan detta tillvägagångssätt och klassiskt logg-arkitektur kan visua- liseras som i figurerna 4.1 och 4.2. Som tydligt visas i figur 4.1 kan den klassiska logg-arkitekturen snabbt bli mycket komplicerad när systemet består av en större mängd applikationer och tjänster som måste kunna kommunicera med varandra.

Figur 4.1: Visualisering av klassisk logg-arkitektur.

4.1. TIDIGARE FORSKNING 35

Figur 4.2: Visualisering av arkitektur byggt kring en logg som kommunikationkanal.

4.1.3 Diskussion

Kreps [23] och Chuvakin et al. [1] har mycket skilda vyer om vad loggning innebär, och hur olika metoder för loggning bör appliceras för att uppnå det bästa resultatet. En stor skillnad mellan de olika vyerna är dock vilken arkitektur som betraktas i de olika synsätten. Medan Chuvakin et al. betraktar den klassiska logg-arkitekturen (se figur 4.1) betraktar Kreps en nyare metod för loggning (se figur 4.2).

Chuvakin et al. lagar om loggning är bra att ta hänsyn till när loggning genomförs i mindre system eller när redan färdiga system behöver optimerad loggning. Kreps arkitektur bör dock avvägas när ett nytt större system skapas eller när ett stort system med många komplicerade kommunikationskanaler behöver optimeras.

En annan stor skillnad mellan dessa olika metoder och synsätt är också att den

klassiska logg-arkitekturen siktar på att producera loggar som skall kunna vara läsbara

för människor till skillnad från pipeline-arkitekturen som siktar på att skapa en logg

som skall vara enkelt läsbar för maskiner. Den klassiska logg-arkitekturen är därmed

anpassad för manuell logg-analys (se sektion 1.1, sid. 2), medan pipeline-arkitekturen

är mycket svår att analysera manuellt och kan kräva någon form av analysmotor med ett

gränssnitt anpassad för människor som till exempel elasticstack (se sektion 2.2, sid. 6)

eller dylikt.

36 KAPITEL 4. STRATEGI FÖR LOGGNING

4.2 Nulägesanalys

Under arbetet med testdatan har även loggnings och logg-analys processerna hos upp- dragsgivaren undersökts. Genom denna undersökning har ett flertal bristande punkter upptäckts som kommer att diskuteras i denna sektion.

En av dessa punkter är mängden av logg-meddelanden som skapades av systemet.

Systemet skapade flera miljoner logg-inlägg per vecka vilket är omöjligt att manuellt analysera, vilket uppdragsgivaren försökte att göra i viss utsträckning.

Nästa punkt är analys-metoden, uppdragsgivaren sökte endast i loggar efter kända fel och hitta orsaken till dessa istället för att leta efter mönster och okända fel i datan.

Att denna metod användes är förstålig med avseende till den stora datamängden och att en analys-motor för automatiserad logg-analys saknades.

Slutligen var innehållet i ett flertal logg-inlägg inte nödvändigt optimal för att kunna analysera loggarna. Loggar innehöll delvis stack-traces samt hela sms som skickats till slutanvändare av systemet. Därutöver var vikten av många olika meddelanden att ifrågasätta, exempelvis har inlägg som användes för debugging markerats som INFO eller till och med WARNING istället för DEBUG.

Ett ytterligare problem är blandningen av olika stavningar för samma log-level mer specifikt är det att både WARN och WARNING används i det nuvarande systemet utan att dessa innebär någon skillnad, exempel på detta kan ses i figur 3.2 på sida 24 och 3.3 på sida 25.

4.3 Förslag på strategi

Som nulägesanalysen (se sektion 4.2) och den tidigare forskningen inom ämnet (se

sektion 4.1) visar, kan flera delar i det befintliga systemet förbättras med avseende

på loggning, både för att underlätta manuell- men även automatiserad logg-analys. En

sammanfattning av strategiförslaget som utarbetades finns i Bilaga A.

4.3. FÖRSLAG PÅ STRATEGI 37 I sektion 4.2 nämndes ett flertal punkter som ansågs som de största aktuella proble- men i loggningen i systemet. Sammanfattningsvis är dessa punkter:

• För mycket data.

• Bristande analys-metod.

• Bristande innehåll i logg-meddelanden.

• Avsaknad av definition hos uppdragsgivaren vad vikten i ett logg-inlägg innebär.

Då systemet innehåller många applikationer där de flesta skapar stora mängder logg- data bör eventuellt systemets arkitektur överses. En pipeline-arkitektur som beskrivs i sektion 4.1.2 är en eventuell lösning för att skapa en bättre kommunikation mellan applikationerna och för att skapa en bättre helhetsbild över hur systemets tillstånd är.

Att ändra arkitekturen av systemet på detta sätt innebär stora förändringar och mycket arbete, då inte endast en gemensam kanal (eller pipeline) måste sättas upp utan även specialanpassade gränssnitt för varje applikation i systemet [23].

Då detta som sagt är en väldigt stor uppgift som kräver mycket planering och re- surser fokuserar strategiförslaget främst på hur systemet kan förbättras med hjälp av reglerna och råden som ges av Chuvakin et al. [1].

För att begränsa mängden logg-data är först och främst insamlingslagen (se sek- tion 4.1.1) mycket användbar. Ett annat sätt för att begränsa överflödig logg-data som nämns av Chuvakin et al. är att konfigurera loggern som används för att skriva logg- meddelanden till att inte skriva ut meddelanden med låg vikt som standard utan att anpassa systemen till att endast skriva lågviktade meddelanden som till exempel INFO och DEBUG under kortare perioder endast när de behövs. Att denna metod skulle minska data-mängden bekräftas av den första övergripande analysen av logg-datan i arbetet som kan ses i figur 5.2 (sid. 44).

Då analys-metoden tidigare har varit begränsad på grund av den stora datamängden

kan manuell analys bli möjlig när datamängden minskas. Utöver detta så kan verktyg

38 KAPITEL 4. STRATEGI FÖR LOGGNING för automatiserad analys som t.ex. elasticstack (se sektion 2.2, sid. 6) användas för att enklare undersöka systemet. För att ytterliggare underlätta automatiserad analys bör varje applikation använda samma struktur på logg-meddelanden för att underlätta parsning av inläggen (se sektion 3.2.3, sid. 19).

Det bristande innehållet i logg-meddelanden kan lösas genom att se till att varje logg-meddelande ska försöka att besvara frågorna som listas av Chuvakin et al.:

• “Who was involved?” - övers.: “Vem var involverad?”

• “What happened?” - övers.: “Vad hände?”

• “Where did it happen?” - övers.: “Var hände det?”

• “When did it happen?” - övers.: “När hände det?”

• “Why did it happen?” - övers.: “Varför hände det?”

• “How did it happen?” - övers.: “Hur hände det?”

En annan fråga som eventuellt bör ställas utöver listan av Chuvakin et al. är: “Bör detta lagras på detta sätt med avseende till GDPR och systemets integritet?”

Sista punkten på listan som handlar om vikten av meddelanden kan endast lösas

av uppdragsgivaren genom att framarbeta vad de olika vikterna (i.e. INFO, DEBUG,

WARNING, etc.) innebär för uppdragsgivarens system.