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 logg-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.
Kapitel 5 Resultat
5.1 Evaluering av monitoreringsverktyg
Elasticstack är inte den enda lösningen för problemen som arbetet skulle lösa. Det jämfördes ett antal olika applikationer / applikationsgrupper för att få fram resultatet att Elasticstack är den bästa lösningen för det givna uppdraget. Verktygen som jämför-des är: Elasticstack (se sektion 2.2, sid. 6), Graylog, Octopussy, Splunk, Fluentd samt Zipkin (se sektion 2.3, sid. 9). Jämförelsen gjordes utifrån ett fåtal olika kriterier som tillsammans gjorde upp bedömningsmallen om verktyget var passande för uppdraget.
De olika kriterierna var: Kostnad, prestanda, dokumentation, visualisering, modularitet samt självständighet.
Kostnaden är självklart av stor betydelse för uppdragsgivaren då lösningen i slutän-dan skall användas i ett kommersiellt syfte och skall gynna företaget på olika sätt.
Därmed bör kostnaden för lösningen vara så låg som möjligt.
Med prestanda i kriterierna menas hur väl lösningen fungerar beroende på hur my-cket diskutrymme lösningen behöver, hur tidskrävande analysen är samt hur mymy-cket processorkraft som är nödvändig för att få lösningen att fungera optimalt. Vidare spe-cificerad så menas med prestanda om lösningen kan operera på en server som ägs av
39
40 KAPITEL 5. RESULTAT uppdragsgivarens kund utan att påverka andra processer som utförs på servern utifrån en grov uppskattning om lösningens prestanda. Då evalueringen av prestanda endast har utförts i stora drag har ej empirisk data insamlats, istället har verktygen endast delats in i grupperna Bra, Bristfällig samt Undermålig beroende på egen uppfattning av programvaran, jämförelser [24] samt recensioner [25].
Dokumentationen av verktygen är en av de viktigaste delarna i bedömningen. Kravet är att verktyget är väl dokumenterad för att lösningen och en testmiljö skall kunna skapas så effektivt som möjligt. Hur väl ett verktyg är dokumenterad och hur väl do-kumentationen är gjord är något som anses vara omöjligt att mäta empiriskt, därför behövde en uppskattning göras som delade in verktygens dokumentation i ett fåtal grupper som är: Bra, Bristfällig samt Undermålig.
Visualisering är kriteriet som har minst påverkan på bedömningen. Kriteriets menig är att verktygen skall ha någon form av grafiskt användargränssnitt som skall kunna användas av användaren för att visualisera olika delar av analysen eller på egen hand skall kunna utföra en analys av datan. Visualisering har delats upp i grupperna: Bra, Bristfällig, saknar visualisering.
Modularitet är ett kriterium som inte heller var viktig för bedömningen men som ansågs som en fördel av verktyget då olika delar av olika verktyg med hjälp av detta kan kombineras för att skapa den optimala lösningen för uppdraget. Detta kriterium är svårt om inte omöjligt att mätas empiriskt och har så med genom en uppskattning baserad på dokumentation, recensioner [25] och tidigare forskning inom området [24], delats in i följande grupper: Bra, Bristfällig, Ej modulär.
Sista kriteriet självständighet utgör ifall verktyget kräver tredjepartsprogramvara för att fungera som en lösning för uppdraget. Kriteriet är inte nödvändigtvis avgörande om huruvida verktyget är användbar för lösningen av uppdraget förutsatt att verktyget har en modularitet som är bedömt som Bra.
Efter att samtliga verktyg har bedömts har resultaten sammanfattats och delats in i
5.1. EVALUERING AV MONITORERINGSVERKTYG 41 grupperna Bra, Bristfällig samt Undermålig. Endast verktygen som hamnade i gruppen Bra har vidare undersökts för att avgöra om verktyget är optimalt för uppdraget.
5.1.1 Jämförelse av verktyg
Samtliga verktyg i undersökningen har för och nackdelar och är utmärkta val beroende på applikation. Flera av verktygen var dock inte passande för arbetets omfång och mål.
Uppdraget var främst riktad mot log-analys därmed var verktyget Zipkin (se sektion 2.3.5, sid. 10) inte lämpad för uppdraget i och med att Zipkin är ett verktyg som är skapad för tracing och fördröjnings-analys. Detta ledde till att verktyget uteslöts från vidare undersökning.
Kriterium Elasticstack (se sektion 2.2, sid. 6) Graylog [10] Octopussy [12]
Kostnad Opensource (Kostnadsfritt) Opensource (Kostnadsfritt) Opensource (Kostnadsfritt)
Prestanda Bra Bra Bra
Tabell 5.1: Jämförelse av verktygen: Elasticstack, Graylog och Octopussy
Kriterium Splunk [11] Fluentd [13] Zipkin [14]
Kostnad Enterprise från $2000/år Opensource (Kostnadsfritt) Opensource (Kostnadsfritt)
Prestanda Bra Bra N/A
Tabell 5.2: Jämförelse av verktygen: Splunk, Fluentd, Zipkin
Enligt tabell 5.1 och 5.2 uppfyllde endast Elasticstack, Graylog och Fluentd samtliga kriterier till en tillfredsställande grad. Vidare undersökning har utgått från att se på och jämföra skillnader och likheter mellan dessa verktyg.
42 KAPITEL 5. RESULTAT Graylog och Elasticstack har många likheter dock kan skillnaderna sammanfattas med att Graylog kräver tredjeparts programvara för att fungera som önskad i enlighet med uppdraget (se sektion 2.3.1, sid. 9).
Fluentd uppfyllde majoriteten av kraven till en tillfredsställande grad. Verktyget krävde dock tredjepartsprogramvara för att vara en del av en lösning till uppdraget.
En möjlig lösning som innefattar Fluentd är att till exempel kombinera verktyget med Elasticsearch samt Kibana (se sektion 2.3.4, sid. 10). Då verktyget i slutändan kräver delar av tredjepartsprogramvara precis som Graylog så valdes verktyget bort.
I och med att Elasticstack innehåller olika moduler som omfattar datainsamling, datamanipulation, dataanalys samt visualisering utan att kräva tredjeparts-programvara har Elasticstack valts som verktyg för att implementera en lösning till uppdraget.
Slutresultatet av evalueringen visar att Elasticstack och Graylog är de två program-varor som bäst uppfyller kravspecifikationen. Den stora skillnaden är att Graylog är beroende av tredjepartsprogrammvara för att lagra och presentera data. Det är dessutom ett krav att använda delar av Elasticstack för att komplettera Graylog. Av den anled-ningen beslutades att använda Elasticstack då det ger en helhetslösning istället för att utnyttja bitar av olika programvaror.