Aktiv felhantering av loggdata
Mattias Åhlander
MID SWEDEN UNIVERSITY
Avdelningen för informationssystem och teknologi (IST)
Huvudområde: Datateknik Högskolepoäng: 15 hp
i
Sammanfattning
Målet med det här projektet har varit att undersöka hur en meddelandekö kan användas för att felhantera felkoder i loggfiler mer aktivt. Projektet har följt Design Science Research Methodology för utveckling och implementering av lösningen. En modell av transaktionssystemet togs fram och emulerades i nyutvecklade applikationer. Två experiment utfördes varav det första testade en längre körning med intervall mellan meddelanden och det andra en tidmätning för hur lång tid det tar att skicka 20 000 meddelanden. Det första experimentet visade att meddelandekön klarade av att hantera meddelanden som skickades över två timmar. Det andra experimentet visade att systemet tog 14 minuter och 45 sekunder att skicka och hantera alla meddelanden, vilket gav en hög genomströmning av 22.5 meddelanden per sekund utan att några meddelanden gick förlorade. Den implementerade mottagarapplikationen tog emot alla meddelanden och lyckades räkna upp antalet felkoder som presenterades i den inkomna datan. De experiment som har utförts har bevisat att en meddelandekö kan implementeras för att felhantera felkoder i loggfiler mer aktivt. De framtida arbeten som kan utföras omfattar en utvärdering av säkerheten av systemet, jämförelser av prestanda jämfört med andra meddelandeköer, utföra experimenten på kraftfullare datorer och en implementering av maskininlärning för att klassificera loggdatan.
Abstract
The main goal of this project has been to investigate how a message queue can be used to handle error codes in log files more actively. The project has followed the Design Science Research Methodology for development and implementation of the solution. A model of the transaction system was developed and emulated in newly developed applications. Two experiments were performed, the first of which tested a longer run time with intervals between messages and the second a time measurement of how long it takes to send 20 000 messages. The first experiment showed that the message queue was able to handle all messages which gave a high throughput of 22.5 messages per second without any messages being lost. The implemented consumer application received all messages and successfully counted the number of error codes in the received data. The experiments that have been carried out have proven that a message queue can be implemented to handle error codes in log files more actively. The future work that can be performed may include an evaluation of the security of the system, comparisons of performance compared to other message queues, performing the experiments on more powerful computers and implementation of machine learning to classify the log data.
iii
Förord
Jag skulle vilja tacka Knowit Sundsvall och mina handledare Mikael Nilsson och Björn Lindström. Jag skulle också vilja tacka min handledare på Mittuniversitetet, Rahim Rahmani.
Innehållsförteckning
1 Introduktion ... 1
1.1 Bakgrund ... 1
1.2 Problemformulering ... 2
1.3 Forskningsfråga ... 2
1.4 Konkreta och verifierbara mål ... 2
1.5 Avgränsningar ... 2 1.6 Översikt ... 3 2 Teori ... 4 2.1 RabbitMQ ... 4 2.1.1 Meddelande ... 4 2.1.2 Avsändare ... 4 2.1.3 Växel ... 5 2.1.4 Kö ... 5 2.1.5 Mottagare ... 5 2.2 MongoDB... 5 2.3 Loggfiler ... 6 2.4 Felkoder ... 6 2.5 Transaktioner ... 6 3 Metod ... 7 3.1 Metodval ... 7 3.2 Metodtillämpning ... 7
3.2.1 Design och utveckling ... 7
3.2.2 Demonstration och utvärdering ... 8
3.2.3 Kommunikation ... 8 4 Implementering ... 9 4.1 Utveckling av avsändarapplikationen ... 10 4.2 Utveckling av databasen ... 10 4.3 Utveckling av meddelandekön ... 11 4.4 Utveckling av mottagarapplikationen ... 11
5 Resultat och analys ... 12
5.1 Experiment 1 – Långtidskörning ... 12
5.2 Experiment 2 – Tidsmätning ... 14
6 Slutsats ... 16
v
Terminologi
Akronymer
ACK Acknowledge.
AMQP Advanced Message Queuing Protocol
DB Database
DSRM Design Science Research Methodology
GDPR Dataskyddsförordningen (General Data Protection
Regulation)
JSON JavaScript Object Notation
MQ Message Queue
1
Introduktion
1.1
Bakgrund
Användandet av digitala system ökar hos företag och organisationer. Det medför en större mängd data som behöver hanteras. En del av den datan skickas som transaktioner i flöden mellan frontend och backend. All trafik och alla händelser passerar en mellanprogramvara som sparar all information om dem i loggfiler. Om det uppstår problem med transaktionerna eller flödet läggs det till en felkod till händelsen.
Ett av de digitala systemen är ett transaktionssystem, som består av flera flöden av transaktioner som flödar mellan frontend och backend. Exempel på transaktioner är pengaröverföringar och avtal. Systemet är alltid aktivt och det medför att det är väldigt hög genomströmning av transaktioner i flödet.
Det existerande systemet hanterar flera flöden med tusentals transaktioner varje dag. För att kunna säkerställa att systemet fungerar som det ska och att inget flöde har stannat upp loggas dessa transaktioner med hjälp av en mellanprogramvara som kan spara information om alla händelser i flödena.
Den här informationen sparas som strukturerad data i loggfiler. Loggfilerna sparas i en databas och analyseras retroaktivt med fokus på de förprogrammerade felkoder som uppstått. Felkoderna är kopplade till anomalier och fel som kan uppstå i flödena.
Vid analysen av loggfilerna söker programmet efter hur många av en eller flera typer av felkoder som har uppstått inom ett givet tidsintervall. Om samma felkod har uppstått ett givet antal gånger skickas en varning till administratören.
Projektet har utförts hos Knowit Norrland i Sundsvall. De har utvecklat och underhåller några system som redan är implementerade i transaktionssystemet. Två av dessa system är logghanteringssystemet som samlar in informationen som sparas i loggfiler och systemet som hanterar och analyserar loggfilerna.
2
1.2
Problemformulering
Problemet som ligger till grund för denna uppsats är: En retroaktiv
felhantering kan leda till långsam felhantering och missade fel som i sin tur kan leda till längre perioder då flödet stannar upp.
Den implementerade lösningen för analys av felkoder i loggfilerna arbetar retroaktivt. Det innebär att när loggfilerna har sparats i databasen analyserar ett program med jämna tidsintervall dem för att hitta förutbestämda mönster av felkoder, till exempel om 15 av en viss felkod har uppstått under de 15 minuterna varnar den. Det kan leda till problem om programmet söker igenom var femtonde minut och de 15 felkoderna har uppstått under minut ett. Det innebär att administratören inte känner till felet förrän 14 minuter efter att det inträffat. Felkoderna motsvarar både allvarliga men också mindre allvarliga fel. Om det är de allvarligare felen i exemplet kan det leda till att delar av transaktionssystemet slutar fungera eller till andra problem.
1.3
Forskningsfråga
Forskningsfrågan som kommer att besvaras i det här projektet är: Kan
en meddelandekö implementeras inom ett transaktionssystem för att förbättra felhantering?
1.4
Konkreta och verifierbara mål
Studien har som mål att undersöka en alternativ felhantering som innehåller och uppnår de följande kriterierna:
Att kunna avlyssna ett aktivt flöde för att samla in all loggdata. Att mottagarapplikationen klarar av att hantera all inkommande
trafik aktivt.
Att aktivt kunna beräkna antalet av varje felkod som inträffat.
1.5
Avgränsningar
Projektet har fokus på att utveckla och utvärdera endast en lösning som utnyttjar en meddelandekö till att hantera genererad loggdata. På grund av sekretesskäl används den genererade datan för experimenten istället för den faktiska datan.
1.6
Översikt
Kapitel 2 beskriver den underliggande teori som är relevant för projektet. Kapitel 3 beskriver de metoder och verktyg som använts för att utföra studien. Kapitel 4 beskriver designen och utvecklingen av artefakten. Kapitel 5 analyserar och presenterar de uppnådda resultaten. Kapitel 6 avslutar den här studien med slutsatser om resultaten och framtida utveckling.
4
2
Teori
2.1
RabbitMQ
RabbitMQ är en mellanhand för meddelanden. Den både tar emot och vidarebefordrar meddelanden. En analogi som beskriver det är ett postkontor. Du har en brevlåda som en avsändare lämnar sitt meddelande i och en brevbärare som plockar upp meddelandet och levererar det till mottagaren. RabbitMQ är alla de tre, postkontoret, brevlådan och brevbäraren. [1]
Pika är ett bibliotek till Python som implementerar kopplingen mot RabbitMQ:s server och dess funktioner. RabbitMQ använder sig av protokollet Advanced Message Queuing Protocol (AMQP). Se Figur 1 för ett exempel på hur ett system med avsändare, växel, köer och mottagare som följer AMQP kan se ut i RabbitMQ.
Figur 1: RabbitMQ - En modell över ett system i RabbitMQ.[2]
2.1.1 Meddelande
Ett meddelande innehåller information som är representerat som en lista av bytes. Ett par exempel på meddelanden är att de kan innehålla vanlig text eller att den innehåller instruktioner för en viss uppgift som mottagaren ska utföra. [3]
2.1.2 Avsändare
En avsändare är en applikation som producerar meddelanden och skickar dem till meddelandekön. Meddelanden når inte direkt fram till kön utan de går först genom en växel. [3]
2.1.3 Växel
En växel är bunden till en eller flera köer och kan med hjälp av nycklar bestämma vilken kö meddelanden ska skickas till. Nyckeln fungerar som en adress för köerna. Växeln behöver inte skicka meddelandet till någon kö, utan kan även ta bort meddelanden om den inte känner till destinationen. En kö kan inte ta emot meddelanden om den inte har en växel bunden till sig. Växeln fungerar enligt den regel som är vald. De regler som finns är direkt, ämne, rubriker och förgrena. En förgrening innebär att ett meddelande kan delas upp för att skickas till flera köer.[4]
2.1.4 Kö
En kö agerar som en meddelandebuffert. Det är en rad av meddelanden som väntar på att hanteras. Kön följer ”först in, först ut”-principen, vilket innebär att det första meddelande som lades till på kön är även det första som kommer behandlas. En kö agerar mellanhand mellan avsändare och mottagare.[3]
2.1.5 Mottagare
Mottagaren är en applikation som är direkt kopplad mot en kö. Den hämtar och hanterar de meddelanden som ligger i kön. Mottagaren kan inte lagra meddelanden, utan de lagras i kön tills att mottagaren hanterar dem.[3]
2.2
MongoDB
MongoDB är en databas som är tillgänglig för flera plattformar. Den är klassad som en NoSQL-databas, vilket innebär att den lagrar datan i annat format än i den typiska tabellstruktur som Structured Query Language (SQL) använder. MongoDB sparar sin data i liknande format som JavaScript Object Notation (JSON). Pymongo är ett tillägg till Python som innehåller de verktyg som behövs för att kunna koppla mot databasen. [5] [6]
Datan som lagras i databasen kan se ut på flera olika sätt. Ett exempel relaterat till loggdata som lagras i databasen kan se ut enligt Figur 2, där två poster visar deras id, en tidsstämpel och en felkod.
6
Figur 2: MongoDB - Exempel på NoSQL data som ligger lagrad på databasen.
2.3
Loggfiler
Loggfiler är filer som består av loggad information om händelser i digitala system eller program. De filerna har oftast filändelsen .log. Varje loggmeddelande som läggs till har vanligtvis ett datum och en tidsangivelse med precision på mikrosekunder, som specificerar när posten genererades. Resterande information kan vara felkoder, beskrivningar och annan information som relaterar till det specifika systemet eller programmet.[7] Ett loggmeddelande har ofta skiljetecken mellan varje del av informationen. Som exemplet i Figur 3 visar används ; som ett skiljetecken mellan datum, tidsangivelse, felkod och annan information.
Figur 3: Ett loggmeddelande i en loggfil
2.4
Felkoder
Felkoder är en serie av siffror som representerar ett specifikt fel som har uppstått i ett system eller program. När ett fel uppstår så genereras en felkod. Felkoderna finns redan förutbestämda med en tillhörande beskrivning. [8]
2.5
Transaktioner
En transaktion är en händelse som antingen ett program, ett system eller en användare har initierat. När det gäller finansiella transaktioner är det monetära överföringar eller icke-monetära transaktioner. I det
existerande systemet är de monetära transaktionerna
3
Metod
3.1
Metodval
Studien kommer att fokusera på att utveckla en artefakt som kommer att besvara forskningsfrågan och uppfylla de mål som tidigare ställts. Utvecklingen av artefakten kommer att följa Design Science Research Methodology (DSRM).
DSRM är en iterativ metod som använder en stegvis modell som efter varje steg evalueras. Om evalueringen inte har ett godtyckligt resultat börjas processen om från ett tidigare steg. Metoden består av principer, övningar och rutiner. [10]
Ken Peffers har utformat en variant av DSRM som riktar sig mot utveckling av en artefakt inom informationssystem. Peffers modell följer sex steg. De sex stegen är[11] :
1. Identifiera och motivera problemet. 2. Definiera målen för en lösning 3. Designa och utveckla en artefakt.
4. Demonstrera artefakten för att lösa en del eller hela problemet. 5. Utvärdera och jämför om artefakten uppnår målen.
6. Kommunicera problemet och artefaktens design och implementation.
Forskningsstrategin experiment kommer att användas för att utvärdera artefakten.
3.2
Metodtillämpning
Problemet och målen för en lösning har redan framförts i kapitel 1.3 respektive 1.6.
8
besvara frågeställningen på bästa möjliga sätt. För att uppnå det kommer programvaran RabbitMQ och databasen MongoDB att användas.
3.2.2 Demonstration och utvärdering
Det utvecklade systemet kommer att demonstreras genom testkörningar. De utförs som två experiment. Det första experimentet går ut på att köra systemet under två timmar, där meddelanden skickas med ett angivet intervall. Det kommer visa hur bra systemet kan köra
under en längre period samt hur många bekräftelser
mottagarapplikationen skickar per sekund. I det andra experimentet skickas 20 000 meddelanden utan uppehåll. Resultatet kommer att visa hur lång tid det tog att skicka meddelandena, om några meddelanden tappades bort och om de alla hanterades korrekt.
Resultaten och mätvärdena kommer att sparas och analyseras i resultatkapitlet. En utvärdering baserad på resultaten kommer att besvara frågeställningen och diskutera hur väl målen har uppfyllts.
3.2.3 Kommunikation
De begränsningar som har tagits och artefakten som helhet kommer att evalueras och slutsatser kommer att dras utifrån hur lämpligt det är att implementera en liknande lösning på det aktuella transaktionssystemet.
4
Implementering
Grundstommen för designen av artefakten är baserad på hur meddelandekön kan implementeras i det existerande systemet. Designen har haft störst fokus på att adressera problemet och få till en aktiv felhantering. Artefakten är utformad efter de uppsatta målen och med forskningsfrågan i åtanke.
Tillgången till det existerande systemet är begränsad och därmed krävdes att det utvecklades en eller flera applikationer som efterliknar det existerande systemet och genererar liknande data som mellanprogramvaran gör.
En meddelandekö har använts för att den klarar av att tillfälligt lagra
loggmeddelanden som inte kan hanteras direkt om
mottagarapplikationen redan hanterar ett tidigare meddelande. RabbitMQ valdes ut för att den stödjer flera olika meddelandeköer och har utförliga administrationssidor. De sidorna erbjuder diagram och mätvärden över meddelandeflödet. Lösningen har valt att fokusera på endast ett av de meddelandeprotokollen, nämligen Advanced Message Queuing Protocol (AMQP).
För att efterlikna det existerande systemet ytterligare kommer loggmeddelandena också skickas till en databas. MongoDB har använts eftersom det är en NoSQL databas och den har också administrationssidor för uppsättning av en databasserver som tillhandahålls av Amazon.
Avsändarapplikationen är tänkt att efterlikna den mellanprogramvara som finns implementerad i det existerande systemet med avseende på vilken typ av data den skickar. Artefakten är tänkt att fungera på det sätt som Figur 4 visar.
10 Figur 4: Modell - En översikt över hela systemet
Python är det programspråk som valts ut för applikationerna. Anledningen till det är att både RabbitMQ respektive MongoDB har tillhörande bibliotek som kan laddas ned och importeras till applikationerna.
4.1
Utveckling av avsändarapplikationen
En lista av möjliga felkoder och felmeddelanden sammanställdes och implementerades i applikationen. Varje felkod har även en tillhörande nivå som visar hur många gånger en felkod ska uppstå innan den varnar. Applikationen plockar slumpmässigt felkoder från listan av felkoder och skickar de till databasen för lagring och till meddelandekön. Felkoderna har också ett tillhörande datum och tidsangivelse om när det felet uppstått. Loggdatan har sparats i JSON-format som sedan serialiseras innan det skickas som meddelande till kön.
4.2
Utveckling av databasen
Databasen är en MongoDB databas. Det är en NoSQL-databas, vilket innebär att det skiljer sig något från traditionella SQL-databaser. I databasen ligger posterna lagrade på dokument. Det innebär att varje post kan sparas med olika format. Dokumenten följer ”nyckel, värde”-par, där nyckeln representerar vad värdet är. I nuläget så har dokumenten endast sparats med ett unikt id som genereras av
MongoDB, en datum- och tidsangivelse samt en felkod i form av en sträng.
Databasen ligger på en molnserver hos MongoDB. Det är helt avskild från applikationerna. Den är säkrad med användarnamn och lösenord. Databasen används för att kontrollera att datans innehåll är korrekt. Den används dessutom till att ge avsändarapplikationen en högre belastning, för att efterlikna det existerande systemet.
4.3
Utveckling av meddelandekön
Meddelandekön följer protokollet AMQP, vilket innebär att den inte bara har en avsändare, en mottagare och en kö utan den har även en växel. Växeln används för att läsa av meddelandet och för att se vilken kö meddelandet ska skickas till.
RabbitMQ servern körs lokalt på datorn. Servern öppnar upp en administrationssida som går att nå via webbläsaren. Där har två växlar som är ingående respektive utgående skapats. De två växlarna är bundna till två köer som också är ingående respektive utgående.
När meddelandekön tar emot meddelandet från avsändarapplikationen sparas det på kön tills applikationen på mottagarsidan är redo att hantera det. Kön funkar enligt ”först in, först ut”-principen, vilket innebär att de meddelanden som lades till på kön först, är också de som kommer att hanteras först.
4.4
Utveckling av mottagarapplikationen
Mottagarapplikationen plockar meddelanden från meddelandekön när den har hanterat klart det tidigare meddelandet. Det första applikationen gör är att deserialisera meddelandet för att det ska vara läsbart av applikationen. Den innehåller en räknare som är separat för varje felkod. För varje felkod som mottagaren tar emot räknar den upp en räknare. När räknaren uppnått den tidigare nämnda nivån sammanställs ett varningsmeddelande som skickas i form av ett meddelande till den utgående kön som en eller flera administratörer kan prenumerera på för att få varningen. Efter att den processen är klar, skickar den tillbaka till den ingående kön en bekräftelse om att
12
5
Resultat och analys
För att se om de angivna målen i kapitel 1.6 har uppnåtts har två experiment utförts.
5.1
Experiment 1 – Långtidskörning
Det första experimentet gick ut på att låta avsändarapplikationen generera nya meddelanden som skickades till den ingående kön med 0.3 sekunders intervall. Den fick exekvera i två timmar för att få ut följande mätresultat:
ACK/s, vilket är hur många bekräftelser som skickas tillbaka till den ingående kön per sekund under körningen av testet.
En mätning av hur många meddelanden som skickats över den tiden och om alla de hanterades.
Figur 5: Experiment 1 - Bekräftelser per sekund.
Figur 7: Experiment 1 - Antal lagrade meddelanden på kön.
Vid körning visar grafen i Figur 5 att antalet bekräftelser ligger på en stadig nivå. Den ingående kön får tillbaka i snitt 2.8 bekräftelser per sekund. Observationen av Figur 6 visar att det skickas i snitt 2.9 meddelanden per sekund genom växeln. Mottagaren skickar ingen bekräftelse förrän att den har hanterat hela meddelandet. Det arbete mottagaren utför tar olika lång tid, vilket innebär att de skickade meddelandena kommer ibland behöva sparas på kön och vänta på att hanteras, vilken observeras i Figur 7.
Över den totala tiden av två timmar borde avsändarapplikationen ha genererat och skickat 24 000 meddelanden beräknat utifrån det angivna intervallet på 0.3 sekunder. Avsändarapplikationen hann endast med att generera 22 082 meddelanden. Det kan ha påverkats av flera faktorer, som till exempel:
Den tid det tog för avsändarapplikationen att sammanställa meddelandet.
Den tid det tog att först skicka meddelandet till databasen.
Den tid det tog innan en bekräftelse skickades tillbaka till avsändaren.
Andra processer som var aktiva på testdatorn under delar av körningen.
14
5.2
Experiment 2 – Tidsmätning
Det andra testet gick ut på att skicka 20 000 meddelanden utan någon fördröjning. Det gav resultat om följande mätningar:
Hur lång tid det tog att skicka antalet meddelanden.
Hur många meddelanden som kom fram och om något av de tappades bort.
Hur många felkoder som mottagarapplikationen observerade.
Figur 8: Experiment 2 - Antal meddelanden i ingående växeln.Gul är ingående och blå är utgående.
Figur 9: Experiment 2 - Antal lagrade meddelanden på kön.
En implementerad tidmätning i applikationen uppmätte att det tog 14 minuter och 45 sekunder att skicka alla meddelanden. Det ger ett medelvärde på 22.5 meddelanden per sekund. Enligt de värden som presenteras i grafen i Figur 8 observeras det att ungefär 24 meddelanden skickades per sekund. På grund av den högre genomströmningen av meddelanden går det att observera i Figur 9 att flera meddelanden lagrades på kön en kort period innan de hanterades.
En räknare höll koll på hur många meddelanden som tagits emot och den mätte att 20 000 meddelanden kom fram till mottagarapplikationen. Det innebär att ingen av de meddelanden som skickades tappades bort. Antalet felkoder summerades till en summa av 20 000, vilket tyder på att mottagarapplikationen lyckades räkna alla felkoder.
Figur 10: Experiment 2 - Antal bekräftade meddelanden per sekund
Grafen i Figur 10 visar att mottagarapplikationen skickade ungefär 25 bekräftelser per sekund. Det innebär att det tar 40 millisekunder från att mottagarapplikationen har tagit emot ett meddelande, tills att den har hanterat meddelandet och beräknat felkoden.
Vid beräkning utifrån det medelvärde som gjorts och baserat på att en månad har 30 dagar, klarar modellen av att ta emot ungefär 58 miljoner meddelanden och beräkna ungefär lika många felkoder i månaden. Det är betydligt fler meddelanden än vad det existerande systemet skickar idag.
Graferna är manuellt sparade från RabbitMQ:s administrationssidor vilket ledde till att samma minutangivelse i graferna i Figur 8 och Figur
10 inte är vid samma tidpunkt. Däremot kan liknelser av graferna ses,
där de gula och gröna kurvorna verkar följa varandra i samma mönster. Det innebär att det är hastigheten av antalet bekräftelser som bestämmer hur snabbt nya meddelanden ska skickas. De större dipparna i graferna berodde på att andra processer var aktiva på samma enhet samtidigt som mätningarna utfördes.
16
6
Slutsats
Syftet med projektet har gått ut på att undersöka ett existerande system, för att hitta en lösning som kan implementeras för en aktiv felhantering av loggdata. Det har uppnåtts genom utveckling av artefakten som besvarade forskningsfrågan och löste problemet.
En meddelandekö skulle implementeras för att förbättra felhanteringen. För att kunna uppnå det krävdes att RabbitMQ kunde hantera alla meddelanden utan förlust. RabbitMQ måste också kunna köra konstant utan avbrott i körningen. Om meddelandekön ska vara en lämplig implementering för det existerande systemet, får det inte påverka dess prestanda avsevärt.
Resultaten visar att artefakten klarar av en aktiv felhantering utan att några av felen missas. Dessutom klarar den av att räkna antalet felkoder som uppstått, likt det existerande systemet.
Därmed kan det påvisas att artefakten både besvarade forskningsfrågan och löste problemet.
Design science har visat sig varit ett bra val av metod för det här praktiska projektet. Där de olika stegen har lagt en bra grund och guidat utvecklingen av artefakten. Problemet och målen gav en klar bild av vad som behövde göras, vilket underlättade både design och utveckling av artefakten. Forskningsstrategin experiment visade sig vara rätt val för demonstrationen och utvärderingen, då experimenten gav tydliga resultat.
Det viktigaste kravet som ställdes på meddelandekön var att kunna hämta in all data från ett aktivt flöde. De utförda experimenten har gett ett positivt resultat som påvisade att lösningen klarade av all den data som skickades från flödet till meddelandekön.
Vid den höga belastningen som testades i det andra experimentet visade mottagarapplikationen att den klarade av att både ta emot alla meddelanden och att aktivt analysera alla felkoder.
Observationerna har visat att en implementering av en meddelandekö för att utföra en mer aktiv felhantering är något som skulle vara både
genomförbart, men också ha möjlighet att gynna det existerande systemet.
Alla experiment har utförts på en enklare bärbar dator, trots det har inte någon större påverkan på resultaten observerats.
När det gäller skalbarheten av artefakten krävs det ytterligare tester för att kunna avgöra om den klarar av ännu större system med större mängder data. Främst med avseende på hur den klarar av ett högt tryck under en mycket längre körning än två timmar.
De tre uppsatta målen har uppnåtts med resultat över förväntan. Där en väldigt stor mängd data kunde hanteras.
6.1
Samhälleliga och etiska aspekter
Majoriteten av den data som ligger lagrad på loggfilerna är sekretessbelagda och skyddade av dataskyddsförordningen (GDPR). Av den anledningen är experimenten utförda på genererad data som inte har någon koppling till privatpersoner eller företag.
Implementeringen av en meddelandekö har bidragit till en mer aktiv hantering av felkoder. Tack vare systemets enkla struktur och dess låga prestandakrav, kan det lätt implementeras i olika loggningssystem. Det skulle gynna företag som hanterar en stor mängd data och är i behov av en aktiv hantering av felkoder.
Artefakten har inte genomgått några tester gällande säkerheten. Om lösningen skulle implementeras som det ser ut idag skulle det kunna äventyra säkerheten i redan existerande system. Det är därmed inte rekommenderat att implementera lösningen förrän säkerheten har undersökts.
6.2
Framtida arbete
För att kunna säkerställa den bästa implementering av en meddelandekö kan fler meddelandeköer och protokoll utvärderas. Det skulle ge möjlighet till intressanta jämförelser när det gäller genomströmning av meddelanden, felhantering och prestandakrav.
18
Den ingående växeln är implementerad med en förgrening, vilket tillåter att växeln skickar till fler än en kö. Då kan mottagarapplikationen kopieras och köras med en varsin kö. Det tillåter att felkoderna kan sorteras ytterligare, och administratörer kan välja vilken grupp av felkoder de vill ta emot varningar om.
En fortsatt studie hade kunnat utveckla vidare på artefakten med avseende på den nuvarande mottagarapplikationen. Den studien skulle med hjälp av maskininlärning kunna implementera en klassificering av datan på mottagarsidan. Den utvecklade modellen skulle då med fördel kunna skrivas i Python för att implementeras i mottagarapplikationen. Ett förslag skulle vara att använda linjär regression för att hitta samband i de felkoder som uppstått eller för att klassificera loggdatan.
Källförteckning
[1] RabbitMQ, ”RabbitMQ tutorial – “Hello world!””,
https://www.rabbitmq.com/tutorials/tutorial-one-python.html Hämtad 2020-05-21
[2] RabbitMQ, “RabbitMq tutorial – Routing”,
https://www.rabbitmq.com/tutorials/tutorial-four-python.html Hämtad 2020-06-17
[3] CloudAMQP, “What is message queueing?”,
https://www.cloudamqp.com/blog/2014-12-03-what-is-message-queuing.html
Hämtad 2020-05-21
[4] RabbitMQ, “RabbitMQ tutorial – Publish/Subscribe”,
https://www.rabbitmq.com/tutorials/tutorial-three-python.html Hämtad 2020-05-21
[5] Wikipedia, “MongoDB”,
https://en.wikipedia.org/wiki/MongoDB Hämtad 2020-05-22
[6] MongoDB, “The most popular database for modern apps”, https://www.mongodb.com/
Hämtad 2020-05-22
[7] A. La Rosa, “Log Monitoring: What should we do before we start?” https://web.archive.org/web/20180214153657/https://blog.pandoraf ms.org/log-monitoring/
Publicerad 2018-02-08. Hämtad 2020-06-17 [8] Computer Hope, “What is an Error Code?”,
https://www.computerhope.com/jargon/e/errorcode.htm Publicerad 2017-04-10. Hämtad 2020-06-17
[9] BusinessDictionary, ”What is a transaction?”,
20
[11] K. Peffers, “A Design Science Research Methodology for Information Systems Research”, Journal of Management Information Systems, vol. 24, nr. 3, 2007-8, pp. 45-78.
