Arbetet kunde redan i ett tidigt skede användas för att genomföra förbättringar på det befintliga systemet. Under arbetes gång har lösningens fortskridande presenterats för anställda hos ÅF vid ett flertal tillfällen där personalen har haft möjlighet att ta nytta av lösningens olika delresultat. Delresultaten bestod utav olika statistiska beräkningar som har kunnat visualiseras med Kibana (se sektion 2.2.4, sid. 8), däribland statistiken som visas i figurerna 3.3 (sid. 25) samt figur 5.2. Efter att statistiken presenterades kunde direkta förbättringar på systemet genomföras såsom minskning av logg-meddelanden
5.3. TIDIG ANVÄNDNING AV SYSTEMET 45 av typen info som inte tillförde nytta, samt att utvecklare som jobbar med det befintliga systemet har kunnat underrättas om återkommande problem i systemet.
Under presentationerna har även diskussioner uppstått om hur arbetet bör vidare-utvecklas för att göra så mycket nytta som möjligt samtidigt som andra faktorer som exempelvis driftkostnad togs hänsyn till. En av de möjligheterna för arbetets praktiska användning var att hålla arbetet separat från det befintliga systemet med möjligheten för utvecklare att sporadiskt kunna ladda in ny data för att med hjälp av statistiska beräkningar kunna upptäcka felmönster. Denna lösning avfärdades då arbetets omfång tillät att mer tid kunde ägnas åt att koppla arbetet till det befintliga systemet vilket i sin tur ledde till att arbetet har kunnat användas för bevakning av live-data.
Bevakning av live-datan var att föredra ur synpunkten att arbetet skulle göra så my-cket nytta som möjligt. Förändringar i systemet kan genom livebevakning observeras nästintill omgående i Kibana. Detta skapade en möjlighet att snabbare kunna upptäcka fel i det befintliga systemet.
46 KAPITEL 5. RESULTAT
Kapitel 6 Slutsats
Arbetet har i sitt slutskede uppnått målen och kraven givna av uppdragsgivaren. En implementation av Elasticstack (se sektion 2.2, sid. 6) som kan användas för monitore-ring av uppdragsgivarens testserver har satts upp samt ett förslag på en loggstrategi åt uppdragsgivaren har tagits fram.
I jämförelsen av verktyg (se sektion 5.1, sid. 39) har elasticstack identifierats som verktyget som var lämpligast för uppdraget. Vidare har Graylog (se sektion 2.3.1, sid. 9) samt Fluentd (se sektion 2.3.4, sid. 10) identifierats som verktyg av särskilt intresse för arbeten av liknande typ.
Vidare har en dataanalys (se sektion 5.2, sid. 43) med hjälp av Elasticstack genom-förts för att skapa en helhetsbild om systemets status, denna analys togs fram för att svara på frågan “Hur mår vårt system?” ställd av uppdragsgivaren. Resultatet av denna analys visar trender på användningen av systemet, däribland en negativ trend som visar en drastisk ökning av logg-meddelanden vid en specifik tidpunkt då användning av självbetjäningsautomater ökar. Resultat från tidiga analyser (se sektion 5.3, sid. 44) från en första PoC-version har kunnat observeras genom att personal av uppdragsgivaren har kunnat ta del av arbetet under dess genomförande. Denna användning av systemet och dess resultat bidrog genom att personal informerades om aktuella problem i systemet
47
48 KAPITEL 6. SLUTSATS som exempelvis självbetjäningsautomaterna. Utöver detta har personal kunnat observe-ra den totala mängden logg-meddelanden som skapades under en veckas drift vilket som resulterade i att åtgärder omedelbart vidtogs för att minska mängden överflödig data.
Utöver implementationen har ett förslag på en loggningsstrategi (se sektion 4, sid. 31) framarbetats som kan användas av uppdragsgivaren för att öka kvaliteten på loggar. En sammanfattning av denna strategi är inkluderad i Bilaga A. Till grund för loggstrategin ligger en kortare nulägesanalys samt tidigare forskning. Nulägesanalysen sammanfattar problemen i det nuvarande loggförfarandet som sedan ställs i kontrast till den tidigare forskningen inom ämnet. Slutsatsen ifrån denna diskussion är att loggningsförfarandet hos uppdragsgivaren är bristfällig enligt de riktlinjer som presenteras i tidigare forskning (se sektion 4.1, sid. 31) och resulterade i strategin som nämndes tidigare.
Arbetet har trots de positiva resultaten stött på ett flertal problem under genomfö-randet. De största problemen har bestått i tekniska begränsningar i den kostnadsfria ver-sionen av Elasticstack. De tekniska begränsningar i Elasticstacks kostnadsfria version har visat sig främst i avsaknad av möjligheten för alerting. Alerting (rapportering till en extern tjänst vid större fel) är en funktionalitet som uppdragsgivaren önskade, men som inte kunde implementeras under arbetets genomförande då funktionaliteten är en del av Elasticstacks kostnadsbelagda version. Huruvida det kan vara värt för uppdragsgivaren att investera i en betald licens för Elasticstack är något de själva kommer ett utreda.
Något som var av stor fördel under driftsättningen av Elasticstack var att det redan i de tidiga iterationerna togs till hänsyn för hur det befintliga systemet ser ut. Genom att efterlikna miljön hos arbetsgivarens system i utvecklingen av PoC-versionen kunde allt från konfiguration till filter återanvändas. Detta ledde till att utvecklingen för den drift-satta versionen av projektet gick väldigt fort. Detta var ett mycket bra tillvägagångssätt som kommer tas med till framtida projekt.
För att summera arbetet i sin helhet; Elasticstack är ett väl fungerande system för att monitorera ett befintligt system utan att påverka det. Filebeat kan installeras på samma
49 maskin där många andra applikationer körs utan att till synes påverka deras prestanda.
De olika modulerna har stor modularitet och tillåter ändlös konfigurering för att anpas-sas till många typer av system. Kibana tillåter snabb överblick av ett systems befintliga status och är lätt att använda för att hitta eventuella buggar. Det går även att hitta typer av problem som annars skulle förbli oupptäckta då samband mellan olika felmeddelanden kan belysa mer komplexa problem. Vidare tror vi att användingen av en gemensam loggstrategi i ett större arbetsteam skulle medföra stor nytta. Som tidigare nämnt kan skillnader i loggformat leda till mer arbete inför monitorering. Det är också värt att se över vad som loggas och ifrågasätta vad som är nödvändigt och inte. Det är därför bra att som team diskutera kring de grundregler som presenteras i loggningsstrategin, samt att gemensamt bestämma vad som bör loggas och inte. Tillsammans kan allt detta leda till ett mer välmående system som är enklare att underhålla.
50 FÖRKORTNINGAR
Förkortningar
ECS Elastic Common Schema, page 17
GDPR The General Data Protection Regulation. Dataskyddsförord-ningen, page 38
HTTP Hypertext Transfer Protocol, page 9 JSON JavaScript Object Notation, page 7
PoC Proof of Concept, page 14
Pub/Sub Messaging Publish/Subscribe Messaging. Ett system där ett subsystem kan publicera och abonnera på meddelanden i en gemensam kanal för kommunikation inuti ett distribuerat system., page 34 SLF4J The Simple Logging Facade for Java, page 19
SSL Secure Socket Layer, page 29
UUID Universally Unique Identifier, page 19
VPN Virtual Private Network, page 26
yml eller yaml, YAML Ain’t Markup Language, tidigare Yet Anot-her Markup Language, page 15
51
52 FÖRKORTNINGAR
Litteraturförteckning
[1] Chuvakin, AA. Moulder, P. Phillips, C. Schmidt, KJ. . Logging and log management. Waltham, Mass, 225 Wyman Street, Waltham, MA 02451, USA, 2013. ISBN: 9781597496360.
[2] ÅF Pöyry AB. About us, 2019. https://afry.com/en/about-us, senast hämtad 3 December 2019.
[3] Elastic. Filebeat: Lightweight log analysis & elasticsearch, 2019. https://www.
elastic.co/products/beats/filebeat, senast hämtad 10 September 2019.
[4] Elastic. What is Elasticsearch, 2019. https://www.elastic.co/what-is/
elasticsearch, senast hämtad 24 September 2019.
[5] Elastic. Kibana, 2019. https://www.elastic.co/products/kibana, senast hämtad 10 September 2019.
[6] Elastic. Grok filter plugin, 2019. https://www.elastic.co/guide/en/
logstash/current/plugins-filters-grok.html, senast hämtad 25 Septem-ber 2019.
[7] Elastic. Date filter plugin. https://www.elastic.co/guide/en/logstash/
current/plugins-filters-date.html, senast hämtad 8 Oktober 2019.
53
54 LITTERATURFÖRTECKNING [8] Elastic. Elasticsearch output plugin, 2019. https://www.elastic.co/
guide/en/logstash/current/plugins-outputs-elasticsearch.html, se-nast hämtad 25 September 2019.
[9] jetRuby Agency. Log management: Graylog vs elk, 2017. https://expertise.
jetruby.com/log-management-graylog-vs-elk-d6e8f0492323, senast hämtad 25 September 2019.
[10] Graylog Inc. Graylog documentation release 1.0.0, 2017. https://buildmedia.
readthedocs.org/media/pdf/graylog2-docs/1.0/graylog2-docs.pdf, senast hämtad 22 Oktober 2019.
[11] Asaf Yigal. Splunk and the elk stack: A side-by-side comparison, 2017. https:
//devops.com/splunk-elk-stack-side-side-comparison/, senast hämtad 25 September 2019.
[12] Diverse. Octopussy (software). https://en.wikipedia.org/wiki/
Octopussy_(software), senast hämtad 25 September 2019.
[13] Fluentd Project. What is fluentd?, 2019. https://www.fluentd.org/
architecture, senast hämtad 22 Oktober 2019.
[14] Daniel Berman. Distributed tracing with zipkin and elk. 2018-05-22. https:
//dzone.com/articles/distributed-tracing-with-zipkin-and-elk, senast hämtad 30 September 2019.
[15] Oracle. About virtual box, 2019. https://www.virtualbox.org/wiki/
VirtualBox, senast hämtad 22 Oktober 2019.
[16] Okänd. Grok debugger. https://grokdebug.herokuapp.com, senast hämtad 14 Oktober 2019.
LITTERATURFÖRTECKNING 55 [17] Watt, A. Beginning Regular Expressions. Wrox. Indianapolis, IN, 2005. ISBN:
9780764574894, 97807645955745.
[18] Colin Surprenant. grok-patterns, 2014. https://github.com/elastic/
logstash/blob/v1.4.2/patterns/grok-patterns, senast hämtad 22 Okto-ber 2019.
[19] Elastic. File output plugin | logstash, 2019. https://www.elastic.co/
guide/en/logstash/current/plugins-outputs-file.html, senast hämtad 3 december 2019.
[20] Elastic. Elastic cloud - elasticsearch-powered saas offerings, 2019. https://
www.elastic.co/cloud/, senast hämtad 12 November 2019.
[21] Microsoft. What is azure?, 2019. https://azure.microsoft.com/en-us/
overview/what-is-azure/, senast hämtad 12 November 2019.
[22] Manpages. systemctl(1) - sysetmd - debian, 2017. https://manpages.debian.
org/jessie/systemd/systemctl.1.en.html, senast hämtad 18 december 2019.
[23] Kreps, J. I Heart Logs: Event Data, Stream Processing, and Data Integration.
O’Reilly Media, Incorporated, 2014. ISBN: 9781491909386.
[24] Jieming Zhu, Shilin He, Jinyang Liu, Pinjia He, Qi Xie, Zibin Zheng, and Michael R. Lyu. Tools and benchmarks for automated log parsing. pages 121–
130, 2019.
[25] Ankush Thakur. 10 open source log collectors for centralized logging. 2019-01-14. https://geekflare.com/open-source-centralized-logging/, senast hämtad 30 September 2019.
56 LITTERATURFÖRTECKNING
Bilagor
57
Bilaga A
Förslag på loggnings-strategi
Detta är en sammanfattning av strategiförslaget beskrivet i sektion 4 (sid. 31) och är tänkt som en grund för uppdragsgivaren att vidare kunna utveckla en strategi om hur loggning i deras system bör ske. Stora delar av dessa förslag är tagna ur Logging and log management av Chuvakin et al. [1] som vi starkt rekommenderar att läsa för att få en bättre insyn i ämnet.
59
60 BILAGA A. FÖRSLAG PÅ LOGGNINGS-STRATEGI 1. Överväg var logg-inlägg bör skapas när arkitekturen i ett nytt system planeras.
2. Lagra inte all data som standard utan lagra endast kritisk information men skapa möjlighet att lagra all data eller delar av datamängden vid behov.
3. Ta hänsyn till lagarna framtagna av Chuvakin et al. när ny logg-data skall skapas.
(a) Insamlingslagen
4. När ett nytt logg-meddelande skapas försök att få varje logg-meddelande att be-svara följande frågor (översättning av frågorna ställd av Chuvakin et al.) så enkelt som möjligt. Undvik att skriva ut stack traces.
• Vem var involverad?
5. Ställ dig frågan: “Hur viktigt är det här meddelandet?” Används det endast för debugging eller har ett kritiskt fel uppstått? Tumregel: fångade exceptions bör skrivas som WARNING eller ERROR.
6. Bör denna information lagras här med avseende på säkerhet och GDPR?
Bilaga B
62 BILAGA B. LOGSTASH.CONF
Bilaga C
64 BILAGA C. FILEBEAT.YML
65
66 BILAGA C. FILEBEAT.YML
67
# - - - L o g s t a s h o u t p u t
-o u t p u t . l -o g s t a s h :
# The L o g s t a s h h o s t s
h o s t s : [ " l o c a l h o s t : 5 0 4 4 " ]
# O p t i o n a l SSL . By d e f a u l t is off .
# L i s t of r o o t c e r t i f i c a t e s for H T T P S s e r v e r v e r i f i c a t i o n s
# ssl . c e r t i f i c a t e _ a u t h o r i t i e s : [ " / etc / pki / r o o t / ca . pem " ]
# C e r t i f i c a t e for SSL c l i e n t a u t h e n t i c a t i o n
# ssl . c e r t i f i c a t e : " / etc / pki / c l i e n t / c e r t . pem "
# C l i e n t C e r t i f i c a t e Key
# ssl . k e y : " / etc / pki / c l i e n t / c e r t . key "
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = P r o c e s s o r s
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
# C o n f i g u r e p r o c e s s o r s to e n h a n c e or m a n i p u l a t e e v e n t s g e n e r a t e d by the b e a t .
p r o c e s s o r s :
- a d d _ h o s t _ m e t a d a t a : ~ - a d d _ c l o u d _ m e t a d a t a : ~
68 BILAGA C. FILEBEAT.YML
Bilaga D
Fler grafer från Kibana
Figur D.1: Graf från Kibana: Logcount by category 69
70 BILAGA D. FLER GRAFER FRÅN KIBANA
Figur D.2: Graf från Kibana: Logcount by percent
Figur D.3: Graf från Kibana: Logcount over time
71
Figur D.4: Graf från Kibana: Loglevel over time
Figur D.5: Graf från Kibana: Errors by category
72 BILAGA D. FLER GRAFER FRÅN KIBANA
Figur D.6: Graf från Kibana: Warnings by category
Figur D.7: Dashboard från Kibana: Dashboard - Home