Tracing Back Log Data to its Log Statement: From Research to Practice

Schipper, Daan; Aniche, Maurício; Deursen, Arie van

doi:10.1109/msr.2019.00081

Cited by 17 publications

(3 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A key assumption in this work is that it is possible to associate each log message with a unique logging statement in source code. We highlight that, while we do not describe a solution here, this is a reasonable assumption because there is already work on identifying the mapping between logging statements and log messages [4,11]. Therefore, we simply assume that the mapping is known.…”

Section: Log Slicingmentioning

confidence: 99%

Towards Log Slicing

Dawes

Shin

Bianculli

2023

Lecture Notes in Computer Science

View full text Add to dashboard Cite

This short paper takes initial steps towards developing a novel approach, called log slicing, that aims to answer a practical question in the field of log analysis: Can we automatically identify log messages related to a specific message (e.g., an error message)? The basic idea behind log slicing is that we can consider how different log messages are “computationally related” to each other by looking at the corresponding logging statements in the source code. These logging statements are identified by 1) computing a backwards program slice, using as criterion the logging statement that generated a problematic log message; and 2) extending that slice to include relevant logging statements.The paper presents a problem definition of log slicing, describes an initial approach for log slicing, and discusses a key open issue that can lead towards new research directions.

show abstract

Section: Log Slicingmentioning

confidence: 99%

Towards Log Slicing

Dawes

Shin

Bianculli

2023

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…An often-occurring challenge is the need to (re)construct an interpretable model of a system's execution. To this end, several authors investigate the combination of log analysis with (static) source code analysis, where they try to (partially) match events in logs to log statements in the code, and then use these statements to reconstruct a path through the source code to help determine what happened in a failed execution [50,51,52,53]. Gadler et al employ Hidden Markov Models to create a model of a system's usage patterns from logged events [54], while Pettinato et al model and analyze the behavior of a complex telescope system using Latent Dirichlet Allocation [55].…”

Section: Related Workmentioning

confidence: 99%

Spectrum-Based Log Diagnosis

Rosenberg

Moonen

2020

Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

View full text Add to dashboard Cite

Background: Continuous Engineering practices are increasingly adopted in modern software development. However, a frequently reported need is for more effective methods to analyze the massive amounts of data resulting from the numerous build and test runs. Aims: We present and evaluate Spectrum-Based Log Diagnosis (SBLD), a method to help developers quickly diagnose problems found in complex integration and deployment runs. Inspired by Spectrum-Based Fault Localization, SBLD leverages the differences in event occurrences between logs for failing and passing runs, to highlight events that are stronger associated with failing runs. Method: Using data provided by Cisco Norway, we empirically investigate the following questions: (i) How well does SBLD reduce the effort needed to identify all failure-relevant events in the log for a failing run? (ii) How is the performance of SBLD affected by available data? (iii) How does SBLD compare to searching for simple textual patterns that often occur in failure-relevant events? We answer (i) and (ii) using summary statistics and heatmap visualizations, and for (iii) we compare three configurations of SBLD (with resp. minimum, median and maximum data) against a textual search using Wilcoxon signed-rank tests and the Vargha-Delaney measure of stochastic superiority. Results: Our evaluation shows that (i) SBLD achieves a significant effort reduction for the dataset used, (ii) SBLD benefits from additional logs for passing runs in general, and it benefits from additional logs for failing runs when there is a proportional amount of logs for passing runs in the data. Finally, (iii) SBLD and textual search are roughly equally effective at effort-reduction, while textual search has slightly better recall. We investigate the cause, and discuss how it is due to characteristics of a specific part of our data. Conclusions: We conclude that SBLD shows promise as a method for diagnosing failing runs, that its performance is positively affected by additional data, but that it does not outperform textual search on the dataset considered. Future work includes investigating SBLD's generalizability on additional datasets. CCS CONCEPTS • Software and its engineering → Software development process management; Software defect analysis.

show abstract

“…Based on the log templates, these approaches automatically compose regular expressions to match log messages that are associated with each of the extracted log templates. Following studies [51], [52] applied [5] on production logs (e.g., Google's production logs) and achieved a very high accuracy. However, source code is often not available for log parsing tasks, for example, when the log messages are produced by closed-source software or third-party libraries; not to mention the efforts for performing static analysis to extract log templates using different logging libraries or different programming languages.…”

Section: Prior Work On Log Parsingmentioning

confidence: 99%

Logram: Efficient Log Parsing Using n-Gram Dictionaries

Dai¹,

Shang³

et al. 2020

Preprint

View full text Add to dashboard Cite

Software systems usually record important runtime information in their logs. Logs help practitioners understand system runtime behaviors and diagnose field failures. As logs are usually very large in size, automated log analysis is needed to assist practitioners in their software operation and maintenance efforts. Typically, the first step of automated log analysis is log parsing, i.e., converting unstructured raw logs into structured data. However, log parsing is challenging, because logs are produced by static templates in the source code (i.e., logging statements) yet the templates are usually inaccessible when parsing logs. Prior work proposed automated log parsing approaches that have achieved high accuracy. However, as the volume of logs grows rapidly in the era of cloud computing, efficiency becomes a major concern in log parsing. In this work, we propose an automated log parsing approach, Logram, which leverages n-gram dictionaries to achieve efficient log parsing. We evaluated Logram on 16 public log datasets and compared Logram with five state-of-the-art log parsing approaches. We found that Logram achieves higher parsing accuracy than the best existing approaches and also outperforms these approaches in efficiency (i.e., 1.8 to 5.1 times faster than the second-fastest approaches in terms of end-to-end parsing time ). Furthermore, we deployed Logram on Spark and we found that Logram scales out efficiently with the number of Spark nodes (e.g., with near-linear scalability for some logs) without sacrificing parsing accuracy. In addition, we demonstrated that Logram can support effective online parsing of logs, achieving similar parsing results and efficiency to the offline mode.

show abstract

Tracing Back Log Data to its Log Statement: From Research to Practice

Cited by 17 publications

References 28 publications

Towards Log Slicing

Towards Log Slicing

Spectrum-Based Log Diagnosis

Logram: Efficient Log Parsing Using n-Gram Dictionaries

Contact Info

Product

Resources

About