PDLogger: Automated Log Instrumentation

• PDLogger is an automated, end-to-end logging framework that integrates LLMs, advanced static analysis, and prompt engineering to generate context-aware log statements.
• It employs a three-phase process comprising log position prediction, context-enriched log generation via backward slicing, and log refinement through level calibration and deduplication.
• Empirical evaluations on Java projects demonstrate significant improvements in log precision, quality, and variable selection compared to prior approaches.

PDLogger is an automated end-to-end logging framework developed to generate precise and high-quality log statements in real-world software systems, particularly where multiple logs may coexist within individual methods. It addresses the shortcomings of earlier automated systems, which often focus on isolated sub-tasks such as log position or message prediction and lack integration of semantic dependencies across control-flow and data-flow boundaries. PDLogger’s approach comprises three distinct but integrated phases—log position prediction, log generation with enriched context, and log refinement—to produce comprehensive and semantically coherent log instrumentation. The framework leverages LLMs, advanced static analysis, and prompt engineering to achieve notable improvements in logging precision, log statement quality, and robustness across various codebases (Duan et al., 26 Jul 2025).

1. Framework Overview and Motivation

PDLogger’s architecture is motivated by the operational realities of modern software systems, where developers must instrument code with multiple log statements that are contextually appropriate and collectively sufficient for fault diagnosability. Existing tools generally lack the capacity to identify all suitable log positions within complex methods or to capture deeper inter-procedural semantic dependencies required for informative logging. PDLogger rectifies these deficiencies by executing a three-phase process: (1) structured log position prediction informed by control-flow context, (2) log statement synthesis supported by backward program slicing and expanded variable/function candidate sets, and (3) log refinement targeting level calibration and redundancy elimination (Duan et al., 26 Jul 2025).

2. Log Position Prediction

The first phase, log position prediction, statically analyzes each method to determine candidate logging points across all relevant code blocks, including branches, try-catch, loops, and method entry/exit sequences. Each block is annotated with explicit start and end positions. Block-type–aware heuristics guide this phase, exemplified by rules such as prioritizing logs after key branch events (e.g., following exception handling in a catch block) and eschewing loop logs that do not reflect value changes across iterations. These heuristics are encoded as structured prompts, highlighting control-flow structure and settings for candidate selection. The prompts are then used as input to an LLM, which infers likely log insertion points while minimizing false positives. Accurate slicing entry point determination during this process is essential to prevent propagation of errors in later generation steps (Duan et al., 26 Jul 2025).

3. Log Generation via Semantic Context Enrichment

In the log generation phase, PDLogger exploits backward program slicing to extract semantic control and data dependency context from each candidate position. This technique uncovers all relevant preceding computations and data flows, extending context beyond intra-method boundaries. The enrichment process expands the set of candidate logging variables to encompass parameters, locals, class member variables, static variables, and inherited variables: $v \in V_p \cup V_m \cup V_c \cup V_s \cup V_i$ where $V_p$, $V_m$, $V_c$, $V_s$, and $V_i$ denote, respectively, parameters, method-local variables, class members, static variables, and inherited variables.

Additionally, function-level information is incorporated: $f \in F_m \cup F_i \cup F_d \cup F_l \cup F_s$ where $F_m$ represents member methods, $F_i$ inherited methods, $F_d$ default interface methods, $F_l$ lambda expressions, and $F_s$ statically imported methods. The total candidate set becomes $f \cup v$.

An enriched prompt combining the backward slice and the candidate variable/function set is submitted to the LLM (often employing Chain-of-Thought prompting). The output includes the insertion position, log level, context-aware message, and specific variables or function calls to be logged. This approach enables the generation of logs that reflect actual developer intent and facilitate observability (Duan et al., 26 Jul 2025).

4. Log Statement Refinement: Level Adjustment and Deduplication

The refinement stage involves two major processes: log level calibration and deduplication. Log level refinement analyzes the content of log messages, method/block location, semantic rationale, and block size to potentially elevate or demote log severity, addressing contexts where, for instance, an exception log should shift from “DEBUG” to “ERROR.” This information is provided in a feedback loop to the LLM for reevaluation.

Context-sensitive deduplication ensures compactness and utility by grouping candidate logs, ordering by line number, and applying filters to eliminate semantically redundant statements. Duplicates are pruned based on criteria such as repeated exception messages, conflicting logs across branches (retaining those with higher severity), and post-dominance of “start” logs by their corresponding “end” logs. Additional checks are performed for duplicate semantics when logs reference the same key variables (Duan et al., 26 Jul 2025).

5. Empirical Evaluation and Comparative Results

PDLogger was rigorously evaluated on a dataset of 3,113 log statements from widely used Java projects, including Apache Hadoop and Apache ActiveMQ. The system was assessed under both single-log and multi-log (all logs removed from methods) scenarios. Performance metrics indicated substantial gains over the strongest prior baselines:

• Log position precision: Increased from 0.417 (with SCLogger) to 0.54, a 29.5% improvement.
• Log level accuracy and Adjusted Overall Detection: Marked improvement (82.3% higher level accuracy), supporting the effectiveness of refinement mechanisms.
• Logging variable F1: Gains of up to 131.8%, reflecting the impact of the expanded candidate set.
• Log message quality (BERTScore): 65.7% improvement versus prior best results.
• Multi-log settings: Position precision saw a 139.0% gain, and F1 increased by 69.2%.

Ablation studies confirmed the necessity of each core component—block-type heuristic prompts, context extraction via slicing, function-aware extension, and both refinement submodules—for overall system performance (Duan et al., 26 Jul 2025).

6. Integration with LLMs and Addressed Technical Challenges

LLMs are pivotal to all three PDLogger phases. In log position prediction, structured prompts guide the model toward semantically salient insertion points, overcoming the prevalent “one-log-per-method” assumption. Log generation benefits from detailed, slice-based context and comprehensive candidate sets, allowing synthesis of developer-like, informative messages. During refinement, content-based and contextual heuristics are used to further query the LLM for optimal log level and redundancy removal.

The system addresses several technical challenges that have limited previous approaches:

• Multiple log generation per method rather than single-log constraints.
• Deep semantic dependency capture, including inter-procedural and cross-function analysis.
• Broader candidate sets (variables and functions), overcoming the traditional focus on local variables.
• Automated correction of log level and post-processing deduplication to approach developer practices.

PDLogger demonstrated consistent performance across different LLM backbones (OpenAI o3-mini, LLaMA 3-70B, DeepSeek-Chat), emphasizing its robustness and model-agnostic design (Duan et al., 26 Jul 2025).

7. Relationship to Ontology-Based Debugging and Broader Implications

PDLogger’s methodology is distinct from, but complementary to, ontology-based log and execution-trace models such as BOLD (P et al., 2020). Where PDLogger focuses on practical code instrumentation powered by LLMs and static analysis, BOLD provides standardized, ontology-centric models for source and trace representation (RDF triples, OWL ontologies), facilitating integrated trace querying, reasoning, and high-level abstractions (“spans”). A plausible implication is that PDLogger’s log instrumentation, when integrated with ontology-based approaches, could further amplify capabilities in automated trace analysis, semantic querying, and reasoning over incomplete or voluminous debug data. This suggests a direction for hybrid systems combining both the LLM-enhanced code analysis of PDLogger and the knowledge representation rigor of frameworks like BOLD.

8. Impact, Generalization, and Open Source Availability

PDLogger’s open-source implementation and demonstrable gains in logging precision, variable selection, log quality, and resilience across LLMs position it as a valuable addition to the software development toolchain. It automates a labor-intensive and error-prone process, thereby supporting enhanced system observability, faster fault diagnosis, and more reliable maintenance. The generality of its prompt engineering and semantic analysis indicates potential for further extension and integration with future LLMs and static analysis enhancements (Duan et al., 26 Jul 2025).