Detta är en avhandling om hur vi utfört ett projekt som ger vår kund Ninetech en enkel översikt av loggar. Letande av specifik information såsom loggar i stora system kan vara tidskrävande. Så var fallet för företaget Ninetech. Företagets vilja var därav att ha en webbplats för att presentera loggar i ett översiktligt format. Webbplatsens syfte var att underlätta och minska tiden vid letande efter loggar. Att förkorta tiden är viktigt eftersom loggarna innehåller värdefull information som företaget använder för att lösa supportärenden. Webbplatsen som skapats är en fullständig produkt som levererats till företaget och körs i produktion. I projektet har vi haft en nära kontakt med kund, därav har en agil metod tillämpats. Som resultat har webbplatsen tillfört behovet att finna loggar snabbt och enkelt. Webbplatsen har blivit en del av Ninetechs vardagliga arbete. Störst fokus i avhandlingen ägnas åt vyn som presenterar loggar. / This is a dissertation on how we performed a project that gives our customer Ninetech a simple overview of logs. Searching of specific information such as logs in large systems can be time consuming. This was the case for the company Ninetech. Therefore, the company’s will was to have a website to present the logs in a simple format. The website’s purpose was to facilitate and reduce the time when searching for logs. It is important to shorten the time because the logs contain valuable information that the company uses to resolve support issues. The website created is a complete product delivered to the company and is currently running in production. In the project, we have had a close contact with the customer, hence has an agile method applied. As a result, the website has brought the need to find logs quickly and easily. The website has become a part of Ninetech's everyday work. The main focus of the dissertation is devoted to the view that presents logs.

För att utveckla eller underhålla mjukvara krävs en viss nivå av programförståelse. För att underlätta denna förståelse används olika typer av verktyg. Denna studie fokuserar på två olika verktyg som använder sig av dynamisk analys: enkla och multipla loggar. Studiens syfte är att undersöka om multipla loggar kan bidra till en ökad programförståelse vid programutveckling. Eclipse är en utvecklingsmiljö som används för att visa programmets källkod. Trace Compass är ett verktyg som används för att inspektera loggar. Denna studie utfördes i två moment: experiment och intervjuer. Experimentet bestod av 10 typiska förståelseuppgifter i ett program-utvecklingssammanhang. Efter experimentet utfördes en intervju med samtliga deltagare.  Resultatet av undersökningen blev att multipla loggar skulle kunna vara lämpligare att använda vid problem som var relaterade till två eller fler komponenter i ett system.  En av begränsningarna i denna studie var att studien hade för få deltagare för ett generellt ställningstagande. / To develop or maintain a piece of code requires a certain level of comprehension of the developed or maintained software itself. To achieve this goal the developer uses a set of different tools. This report will focus on two types of debug tools: single trace and multiple traces. The purpose of the study is to examine how multiple traces can contribute to an improved program comprehension. The study was carried out through experiments and interviews. The experiment consisted of 10 typical comprehension tasks in a development context. Eclipse and Trace Compass were used to display the logs. Eclipse is a development environment that shows the source code. Trace Compass is a tool for inspecting traces.  After the experiment, an interview was carried out with the subjects of the experiment. The results of this study indicated that multiple traces could have an advantage over a single trace when the task is to understand the interactions between code components in a software system. One of the limitations of the study was due to the limited number of subjects taken part in the study and cannot be used to draw a more general conclusion.

Many software systems are under test to ensure that they function as expected. Sometimes, a test can fail, and in that case, it is essential to understand the cause of the failure. However, as systems grow larger and become more complex, this task can become non-trivial and potentially take much time. Therefore, even partially, automating the process of root cause analysis can save time for the developers involved. This thesis investigates the use of a Long Short-Term Memory (LSTM) anomaly detector in system logs for root cause analysis. The implementation is evaluated in a quantitative and a qualitative experiment. The quantitative experiment evaluates the performance of the anomaly detector in terms of precision, recall, and F1 measure. Anomaly injection is used to measure these metrics since there are no labels in the data. Additionally, the LSTM is compared with a baseline model. The qualitative experiment evaluates how effective the anomaly detector could be for root cause analysis of the test failures. This was evaluated in interviews with an expert in the software system that produced the log data that the thesis uses. The results show that the LSTM anomaly detector achieved a higher F1 measure than the proposed baseline implementation thanks to its ability to detect unusual events and events happening out of order. The qualitative results indicate that the anomaly detector could be used for root cause analysis. In many of the evaluated test failures, the expert being interviewed could deduce the cause of the failure. Even if the detector did not find the exact issue, a particular part of the software might be highlighted, meaning that it produces many anomalous log messages. With this information, the expert could contact the people responsible for that part of the application for help. In conclusion, the anomaly detector automatically collects the necessary information for the expert to perform root cause analysis. As a result, it could save the expert time to perform this task. With further improvements, it could also be possible for non-experts to utilise the anomaly detector, reducing the need for an expert. / Många mjukvarusystem testas för att försäkra att de fungerar som de ska. Ibland kan ett test misslyckas och i detta fall är det viktigt att förstå varför det gick fel. Detta kan bli problematiskt när mjukvarusystemen växer och blir mer komplexa eftersom att denna uppgift kan bli icke trivial och ta mycket tid. Om man skulle kunna automatisera felsökningsprocessen skulle det kunna spara mycket tid för de invloverade utvecklarna. Denna rapport undersöker användningen av en Long Short-Term Memory (LSTM) anomalidetektor för grundorsaksanalys i loggar. Implementationen utvärderas genom en kvantitativ och kvalitativ undersökning. Den kvantitativa undersökningen utvärderar prestandan av anomalidetektorn med precision, recall och F1 mått. Artificiellt insatta anomalier används för att kunna beräkna dessa mått eftersom att det inte finns etiketter i den använda datan. Implementationen jämförs också med en annan simpel anomalidetektor. Den kvalitativa undersökning utvärderar hur användbar anomalidetektorn är för grundorsaksanalys för misslyckade tester. Detta utvärderades genom intervjuer med en expert inom mjukvaran som producerade datan som användes in denna rapport. Resultaten visar att LSTM anomalidetektorn lyckades nå ett högre F1 mått jämfört med den simpla modellen. Detta tack vare att den kunde upptäcka ovanliga loggmeddelanden och loggmeddelanden som skedde i fel ordning. De kvalitativa resultaten pekar på att anomalidetektorn kan användas för grundorsaksanalys för misslyckade tester. I många av de misslyckade tester som utvärderades kunde experten hitta anledningen till att felet misslyckades genom det som hittades av anomalidetektorn. Även om detektorn inte hittade den exakta orsaken till att testet misslyckades så kan den belysa en vissa del av mjukvaran. Detta betyder att just den delen av mjukvaran producerad många anomalier i loggarna. Med denna information kan experten kontakta andra personer som känner till den delen av mjukvaran bättre för hjälp. Anomalidetektorn automatiskt den information som är viktig för att experten ska kunna utföra grundorsaksanalys. Tack vare detta kan experten spendera mindre tid på denna uppgift. Med vissa förbättringar skulle det också kunna vara möjligt för mindre erfarna utvecklare att använda anomalidetektorn. Detta minskar behovet för en expert.