This report has conducted a research of comparing a few open source search engines. The research contains two evaluation processes, the first evaluation will evaluate each open source search engine found on today’s market. Points will be given between one to five points depending on how well the open source search engine meets the requirements. The open source search engine with the highest score will then be chosen for implementation. The first evaluation resulted in Elasticsearch being the selected open source search engine and will continue to the implementation phase. The second evaluation will be measuring the system performance and the relevance of the SERP (Search Engine Results Pages). This phase will evaluate the system performance by taking time measurements on how long it takes for the search engines to deliver the SERP. The relevance of the search results will be judge by a group of CSN employers. The group will be giving point be-tween one to five points depending on the relevance of the SERP. It will eval-uate Elasticsearch with the search engine CSN are using today on their web-site (www.csn.se). This phase resulted in Elasticsearch being the better in performance measurements but not in the relevance of the SERP. This was discussed and came to the conclusion that most points were lost because of the first search result Elasticsearch delivered. If this search result was re-moved Elasticsearch could deliver as good results as the old search engine. The survey came to the conclusion that Elasticsearch is recommended for CSN if certain problem areas could be corrected before implementation into their systems.

System Administrators use many of the same tactics that are implemented by hackers to validate the security of their systems, such as port scanning and vulnerability scanning. Port scanning is slow, and can be highly inaccurate. After a scan is complete, the results of the scan must be cross checked with a vulnerability database to discover if any vulnerabilities are present. While these techniques are useful, they have severe limitations. System Administrators have full access to all of their machines. They should not have to rely exclusively on port scanning them from the outside of their machines to check for vulnerabilities when they have this level of access. This thesis introduces a novel concept for replacing port scanning with a Log File Inventory Management System. This system will be able to automatically build an accurate system inventory using existing log files. This system inventory will then be automatically cross checked with a database of known vulnerabilities in real-time resulting in faster and more accurate vulnerability reporting than is found in traditional port scanning methods.

Deciding which database management system (DBMS) to use has perhaps never been harder. In recent years there has been an explosive growth of new types of database management systems that address different issues and performs well for different scenarios. This thesis is an improving case study of an Event Persistence Solution for the Eiffel Framework, which is a framework used for achieving traceability in very-large-scale systems development. The purpose of this thesis is to investigate whether it is possible to improve the performance of the Eiffel Event Persistence Solution by changing from MongoDB, to Elasticsearch or ArangoDB. Experiments were conducted to measure the request throughput for 4 types of requests. As a prerequisite to measuring the performance, support for the different DBMSs and the possibility to change between them was implemented. The results showed that Elasticsearch performed better than MongoDB in terms of nested-document-search as well as for graph-traversal operations. ArangoDB had even better performance for graph-traversal operations but had an inadequate performance for nested-document-search. / 决定使用哪个数据库管理系统（DBMS）可能从未如此困难过。近年来，新型数据库管理系统呈现爆炸式增长，它们解决了不同的问题，并在不同的情境中表现出优异性能。本论文是针对Eiffel框架的事件持久性解决方案的改进案例研究，该框架被用于实现超大规模系统开发中的可追溯性。本文的目的是研究是否可以通过摒弃MongoDB并改用Elasticsearch或ArangoDB来提高Eiffel事件持久性解决方案的性能。为测量4种类型的请求的请求吞吐量进行了实验。作为衡量性能的前提条件，实施了对不同数据库管理系统（可在这些系统之间进行更换）的支持。结果表明，Elasticsearch在嵌套文档搜索和图形遍历操作方面的性能均优于MongoDB。 ArangoDB在图形遍历操作方面具有比前者更好的性能，但在嵌套文档搜索方面的性能不佳。

The purpose of this thesis is to investigate and implement a framework for log management and analysis tailored to the treatment planning system (TPS) RayStation. A TPS is a highly advanced software package used in radiation oncology clinics, and the complexity of the software makes writing robust code challenging. Although the product is tested rigorously during development, bugs are present in released software. The purpose of the the framework is to allow the RayStation development team insight into errors encountered in clinics by centralizing log file data recorded at clinics around the world. A framework based on the Elastic stack, a suite of open-source products, is proposed, addressing a set of known issues described as the access problem, the processing problem, and the analysis problem. Firstly, log files are stored locally on each machine running RayStation, some of which may not be connected to the Internet. Gaining access to the data is further complicated by legal frameworks such as HIPAA and GDPR that put constraints on how clinic data can be handled. The framework allows for access to the files while respecting these constraints. Secondly, log files are written in several different formats. The framework is flexible enough to process files of multiple different formats and consistently extracts relevant information. Thirdly, the framework offers comprehensive tools for analyzing the collected data. Deployed in-house on a set of 38 machines used by the RayStation development team, the framework was demonstrated to offer solutions to each of the listed problems.

It can be difficult to choose the right NoSQL DBMS, and some systems lack sufficient research and evaluation. There are also tools for moving and transforming data between DBMS' in order to combine or use different systems for different use cases. We have described a use case, based on requirements related to the quality attributes Consistency, Scalability, and Performance. For the Performance attribute, focus is fast insertions and full-text search queries on a large dataset of forum posts. The evaluation was performed on two NoSQL DBMS' and two tools for transforming data between them. The DBMS' are MongoDB and Elasticsearch, and the transformation tools are NotaQL and Compose's Transporter. The purpose is to evaluate three different NoSQL systems, pure MongoDB, pure Elasticsearch and a combination of the two. The results show that MongoDB is faster when performing simple full-text search queries, but otherwise slower. This means that Elasticsearch is the primary choice regarding insertion and complex full-text search query performance. MongoDB is however regarded as a more stable and well-tested system. When it comes to scalability, MongoDB is better suited for a system where the dataset increases over time due to its simple addition of more shards. While Elasticsearch is better for a system which starts off with a large amount of data since it has faster insertion speeds and a more effective process for data distribution among existing shards. In general NotaQL is not as fast as Transporter, but can handle aggregations and nested fields which Transporter does not support. A combined system using MongoDB as primary data store and Elasticsearch as secondary data store could be used to achieve fast full-text search queries for all types of expressions, simple and complex.

Idag genererar företag stora mängder av loggfiler vilket gör det svårt att hitta och undersöka felmeddelanden i alla loggfiler. En loggsamlare med Logstash, Elasticsearch och Kibana som bas har implementerats hos Ericsson Linköping. Loggsamlarens syfte är att samla loggar från testenheter och möjliggöra sökning och visualisering av dem. En utvärdering av Elasticsearch har genomförts för att se i vilken grad söktiden för sökfrågor ökar med ökad datamängd. Utvärderingen gav en indikation om att söktiden i värsta fallet är linjär.

The thesis focuses on developing prototype of e-commerce platform. This platform will be used as a base for a full-fledged e-commerce solution of specific trader in the future. The thesis deals with the analysis of the current state, analysis of available solutions, description of selected technologies, including a description of how these technologies were specifically implemented in the project. The result of this thesis is a functional prototype of e-commerce platform.

Elasticsearch has evolved from an experimental, open-source, NoSQL database for full-text documents to an easily scalable search engine that canhandle a large amount of documents. This evolution has enabled companies todeploy Elasticsearch as an internal search engine for information retrieval (logs,documents, etc.). Later on, it was transformed as a cloud service and the latestdevelopment allows a containerized, serverless deployment of the application,using Docker and Kubernetes.This research examines the behaviour of the system by comparing the length and appearance of single-term and multiple-terms queries, the scaling behaviour and the security of the service. The application is deployed on Google Cloud Platform as a Kubernetes cluster hosting containerized Elasticsearch images that work as databasenodes of a bigger database cluster. As input data, a collection of JSON formatted documents containing the title and abstract of published papersin the field of computer science was used inside a single index. All the plots were extracted using Kibana visualization software. The results showed that multiple-term queries put a bigger stress on thesystem than single-term queries. Also the number of simultaneous users querying in the system is a big factor affecting the behaviour of the system. By scaling up the number of Elasticsearch nodes inside the cluster, indicated that more simultaneous requests could be served by the system.

With the advent of digitalization, a typical organization today will contain an ecosystem of servers, databases, and other components. These systems can produce large volumes of log data on a daily basis. By using a log management system (LMS) for collecting, structuring and analyzing these log events, an organization could benefit in their services. The primary intent with this thesis is to construct a decision model that will aid organizations in finding a LMS that most fit their needs. To construct such a model, a number of log management products are investigated that are both proprietary and open source. Furthermore, good practices of handling log data are investigated by reading various papers and books on the subject. The result is a decision model that can be used by an organization for preparing, implementing, maintaining and choosing a LMS. The decision model makes an attempt to quantify various properties such as product features, but the LMSs it suggests should mostly be seen as a decision basis. In order to make the decision model more comprehensive and usable, more products should be included in the model and other factors that could play a part in finding a suitable LMS should be investigated.

There is a growing need for more efficient tools and services for log analysis. A need that comes from the ever-growing use of digital services and applications, each one generating thousands of lines of log event message for the sake of auditing and troubleshooting. This thesis was initiated on behalf of one of the departments of the IT consulting company TietoEvry in Karlstad. The purpose of this thesis project was to investigate whether the log analysis service Elastic Stack would be a suitable solution for TietoEvry’s need for a more efficient method of log event analysis. As part of this investigation, a small-scale deployment of Elastic Stack was created, used as proof of concept. The investigation showed that Elastic Stack would be a suitable tool for the monitoring and analysis needs of TietoEvry. The final version of deployment was, however, not able to fulfill all of the requirements that were initially set out by TietoEvry, however, this was mainly due to a lack of time and rather than limitations of Elastic Stack.