# Log-Based Fault Localization with Unsupervised Log Segmentation  
[PERSON]  
1 Nokia, Rodziny Hiszpanskik 8, 02-685 Warszawa, Poland; [EMAIL_ADDRESS]  
[PERSON]  
1 Nokia, Rodziny Hiszpanskik 8, 02-685 Warszawa, Poland; [EMAIL_ADDRESS]  
[PERSON]  
2 Department of Computer Engineering, Faculty of Information and Communication Technology, Politechnika Wroclawska, Wybrzeze [PERSON] 27, 50-370 Wroclaw, Poland; [EMAIL_ADDRESS] (M.N. ); [EMAIL_ADDRESS] (O.U. )2  
[PERSON]  
2 Department of Computer Engineering, Faculty of Information and Communication Technology, Politechnika Wroclawska, Wybrzeze Stanislawa Wyspianskiego 27, 50-370 Wroclaw, Poland; [EMAIL_ADDRESS] (M.N. ); [EMAIL_ADDRESS] (O.U. )2  
Footnote 1: [[https://www.mdpi.com/journal/applsci](https://www.mdpi.com/journal/applsci)]([https://www.mdpi.com/journal/applsci](https://www.mdpi.com/journal/applsci))  
Footnote 2: [[https://www.mdpi.com/journals/pdf/1](https://www.mdpi.com/journals/pdf/1)]([https://www.mdpi.com/journals/pdf/1](https://www.mdpi.com/journals/pdf/1))  
metrics [1], test results, and textual information [2]. To obtain execution traces and metrics, the system must be instrumented in advance, that is, it must be equipped with a code that generates the mentioned data. A popular framework for this purpose is OpenTelemetry [3], which implements the concept of observability and involves understanding the internal state of a system through its outputs. A system that is observable, such as AIOps [4], is a good foundation for applying automatic diagnosis and localization methods. However, obtaining such a rich source of data from a system is infrequent and sometimes not feasible. Thus, many fault-localization methods rely on unimodal data, that is, data from only one source, such as logs. Spectrum-Based Fault Localization (SBFL) [2] is a rapidly growing field that uses unimodal data. The methods based on code coverage (spectrum) are lightweight and competitive. They are fast and scalable. They use code coverage generated by module and unit tests, which are often collected during execution. The anomaly measure is calculated based on the number of times a line appears in the passed and failed tests. The justification is that the lines of code that appear more frequently in failed tests are more likely to be the source of the problem. Statistical methods [5; 6; 7] are frequently used to calculate the suspicious scores. Based on this metric, a ranking of program lines can be produced and suggested to the software developer pointing where to look first. Ideally, the line with the actual error should be at the top of the suggestions. Machine learning [8] and deep learning [9; 10] models also use code coverage to predict the faulty lines. Training involves teaching the network to predict the test results based on code coverage. Then, during inference, virtual tests consisting of a single line of code are inputted. The output indicates that the line is a potential source of error. Deep learning methods use code coverage, represented as a Coverage Matrix [9; 11]. It allows the network to detect which changes in the test execution cause an error. However, code coverage information alone does not always correlate with the actual cause of an error. This is because the execution frequency data of a given line affects the localization result. Non-faulty code fragments can be executed more frequently than actual faulty fragments, which skews the SBFL result. Therefore, more costly and powerful Slicing-Based Fault Localization methods [12; 13; 14] are used to solve this problem. Slicing methods identify exact instructions for a given system output. The reference point is a specific instruction or variable that we want to trace. The flow is observed throughout all places, from its creation and modification to its return. Slicing can be performed statically [12; 15] or dynamically [13; 16; 17], or by combining both approaches [14] to limit the size of static slicing while improving the quality of dynamic slicing.