# Quality Properties of Execution Tracing, an Empirical Study
## 2 Related Works
also identified the root causes of the log-related issues, some of which are trivial to correct [17]:  
**Inappropriate log messages**: Log message is incorrectly formed including missing or incorrect variables. Majority of the log-related issues belong to this category. **Missing logging statements**: Not enough information is logged. Each Jira ticket belongs to this category where further logging was added to help with the problem analysis. Inappropriate severity levelAn important message is logged with lower severity level or a less important message with a higher severity level. **Log library configuration issues**: Different logging APIs require different configuration files. Issues related to the configuration files or their existence belong to this category. **Runtime issues**: If logging statements produce a runtime failure including NullPointerException. **Overwhelming logs**: Issues with redundant and useless log messages fall into this category which make the log output noisy and difficult to read. **Log library changes**: Changes required due to changes in the logging API. [PERSON] et al. investigates the possibility of computing logging topics automatically as the logging frequency for different topics deviates; thus, having the topic could guide developers where to insert log statements in the code [20]. Their study revealed the most intensively logged topics which are related to communications between machines and to thread interactions [20]. [PERSON] et al. conducted a study to examine whether the logging statements remain unchanged in the source code, which is important for the tools to process the logs; moreover, they create a classification model to predict whether a log statement in the source code is likely to change [32]. They found (1) the experience of developers, who created the log statements, has an impact on determining whether it will change or not; (2) log statements introduced by the owner of the file are less likely to change in the future; (3) log statements in files with lower log density are more likely to change than log statements in files with higher log density [32]. [PERSON] et al. and [PERSON] et al. confirm that log messages are frequently the only tools to analyse system failures in the field in a postmortem way [13; 27]. [PERSON] et al. study the efficiency of logging practices in five large software systems, with randomly selected 250 failure reports, and the corresponding source code; moreover, they report that postmortem analysis caused problems in 57% of the cases based on the provided log data [13]. In addition, [PERSON] et al. discover frequent, repetitive patterns among the logging failures which motivates tool support [13; 29]. A study with 20 programmers showed that improved logging resulted in reducing the failure diagnosis time by 60.7% [13]. One important finding of the study is that 39% of the error manifestations were not logged at all [13]. [PERSON] et al. formulate recommendations what to log [13]:  
1. Log detected errors regardless whether there is code to handle the error
2. Log errors of system calls
3. Log CPU, memory usage and stack frames in the case of signals as SIGSEGV, SIGTERM
4. Log switch-case default branches
5. Log exceptions including input validation and resource leaks
6. Log the branches of unusual input or environment effects that might not be covered by testing  
[PERSON] et al. implemented tool support for placing log statements in the code without human intervention and without the need of domain knowledge [27]. Their tool collects execution path information with a low-overhead logging library and does an evaluation about the frequencies of different execution paths to compute the optimal places for log statements for the developer to be able to distinguish between those paths [27]. [PERSON] et al. design and implement a cost-aware logging system which also considers the performance degradation caused by logging to decide which useful log messages to keep and which less useful ones to discard [28]. [PERSON] et al.