LLM root cause analysis method and system based on Java exception stack chain
By using an LLM root cause analysis system based on Java exception stack chains, rapid fault mitigation in Java distributed systems is achieved. Through automated processes, Java exceptions are accurately located, attributed, and repaired, improving analysis efficiency and fault recovery speed.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-13
- Publication Date
- 2026-03-10
AI Technical Summary
Existing technologies in Java distributed systems suffer from low efficiency in exception analysis, unclear attribution of responsibility, and lack of repair guidance, making it impossible to achieve rapid fault mitigation. Furthermore, traditional methods cannot deeply analyze Java exception stack chains and lack automatic root cause diagnosis and repair guidance.
By collecting Java exception logs in real time, filtering redundant stack traces from the framework, focusing on the business code call chain, and combining Git code correlation and Large Language Model (LLM) for root cause analysis, a structured report is generated and pushed to the responsible person, thus realizing an automated process from discovery to repair.
It significantly improves the efficiency of anomaly location, accurately assigns responsibility, provides feasible repair solutions, has the ability to predict risks, and reduces fault recovery time.
Smart Images
Figure CN121636233A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software exception analysis, and more particularly to an LLM root cause analysis method and system based on Java exception stack chains. Background Technology
[0002] In modern distributed Java systems, online application risks mainly manifest in two categories: "errors" (program exceptions) and "slowness" (resource bottlenecks). "Errors" include JVM (Java Virtual Machine) class loading exceptions, NullPointerExceptions, database connection exceptions, and branch exceptions triggered by configuration errors. "Slowness" stems from issues such as CPU overload, database connection pool exhaustion, frequent Full GC (Full Garbage Collection) caused by memory leaks, and cross-service call timeouts. These risks directly threaten system stability and user experience, and traditional exception analysis methods have many unresolved pain points.
[0003] Inefficient location: Complex Java systems have many dependencies, and exception logs often contain lengthy stack chains (such as nested calls to multiple layers of Spring and MyBatis frameworks). Developers need to manually check the stack information line by line, locate the line of business code that triggered the exception, and even search the network to match similar problems. On average, the location takes more than 30 minutes, which is difficult to meet the need for rapid loss mitigation of online failures.
[0004] Passive response and lack of foresight: Traditional methods rely on monitoring and alarms to trigger the analysis process, which can only be dealt with passively after an anomaly occurs, and cannot identify potential risks in advance (such as occasional null pointer exceptions may indicate code logic defects, and failure to fix them in time will lead to batch failures).
[0005] Unclear attribution of responsibility: The exception stack only contains the code path, which cannot be directly associated with the code submitter. Manual communication is required to confirm whether the problem belongs to the team or the individual, which delays the efficiency of collaborative repair.
[0006] Lack of remediation guidance: Even if the abnormal code is located, developers still need to analyze the root cause (such as the source of the uninitialized object of the null pointer, the resource contention point of the timeout exception) and design a remediation plan on their own. There is a lack of systematic root cause analysis and practical code adjustment suggestions, which prolongs the fault recovery cycle.
[0007] Severe log noise interference: The stack traces are lengthy and often filled with proxy call logs from frameworks such as Spring AOP and CGLIB, completely obscuring the source of the anomaly in the core business code. Developers struggle to quickly pinpoint the critical lines of code causing the real problem amidst the massive amount of framework noise, significantly reducing troubleshooting efficiency.
[0008] While existing technologies include deep learning-based log classification systems (such as LLM (Large Language Model)-based software package construction failure log classification schemes), these schemes only focus on log category division (e.g., distinguishing between "missing dependencies" and "test case failures"), failing to delve into the call chain semantics of Java exception stacks, and lacking the capabilities for code association, root cause analysis, and remediation suggestion generation. Consequently, they are ill-suited to the exception analysis needs of Java distributed systems. Therefore, there is an urgent need for an intelligent system capable of deeply parsing Java exception stack chains, associating code context, and leveraging LLM to achieve automatic root cause diagnosis and remediation guidance. Summary of the Invention
[0009] The purpose of this invention is to overcome the shortcomings of the prior art and provide an LLM root cause analysis system and method based on Java exception stack chains. Through precise parsing of exception stacks, dynamic association of Git code, deep semantic analysis of LLM, and a closed loop of real-time notification, it realizes full-process automation of Java exceptions from "discovery-location-root cause-repair-notification", solves the problems of low efficiency, unclear responsibility, and lack of guidance in traditional analysis, and meets the needs of rapid loss prevention in online failures.
[0010] To achieve the above-mentioned objectives, one aspect of the present invention provides an LLM root cause analysis method based on Java exception stack chains, comprising the following steps:
[0011] Step S1: Collect Java exception logs in real time, extract key information from the stack chain, filter redundant stacks in the framework, focus on the call chain of several layers (e.g., 3 layers) closest to the business code, and form structured data of key information.
[0012] Step S2: Based on the file path and line number parsed from the Java exception log, obtain the corresponding code snippet through the GitLab API, and extract the code committer information to confirm the attribution of responsibility;
[0013] Step S3: Use LLM to perform root cause analysis and build a structured Prompt. The input is "filtered exception stack information, associated source code snippets, and code authors identified by version control information". LLM uses its semantic understanding capabilities to simulate the diagnostic process of a senior development expert and outputs a structured remediation plan containing executable code.
[0014] Step S4: Present the root cause analysis report, code snippets, and remediation suggestions in a structured report format, and push them to the person responsible for the issue through an enterprise collaboration tool robot (such as Lark robot).
[0015] Step S5: Use a time window deduplication algorithm to reduce noise and configure an alarm whitelist. Statistical analysis of frequency trends will help predict risks.
[0016] Furthermore, step S1 includes the following steps:
[0017] Step S101: Receive exception logs output by the Java application through the Kafka message queue (supporting mainstream logging frameworks such as Logback and Log4j2), associate them with trace_id to implement distributed tracing, and ensure that the exception logs can trace back the complete call context;
[0018] Step S102: Use regular expression matching to remove fixed format noise from the logs, filter non-business-related framework call stacks by matching framework package names, and pre-configurable framework package name blacklists (such as org.springframework.*, com.baomidou.mybatisplus.*). Enterprises can add / delete package name rules according to their own technology stack to ensure that only business code stacks are retained. In terms of the corresponding stack level, the three-layer business call chain closest to the exception trigger point is retained first.
[0019] Step S103: Extract core fields from the filtered stack chain to form structured data of key information, including exception type, exception code location, exception triggering method, and associated trace_id.
[0020] Furthermore, in step S2, the file path extracted in step S1 is converted into a relative path in the Git repository, the GitLab API is called, authentication is achieved through GitLab Personal Access Token (PAT), and branch priority rules are configured (by default, the branch corresponding to the production environment is prioritized, such as master / main; if the branch does not exist, it is automatically downgraded to the test branch); the file path, branch name and line number are passed in, and the code context of the abnormal line within a predetermined range (e.g., 5-10 lines before and after) is extracted to ensure that the critical logic is included.
[0021] Furthermore, by obtaining the latest committer information of the target code file (such as the account "Zhang San 7895") through the GitLab API, and associating it with the company's internal organizational structure, the person responsible for the issue and their team can be identified, laying the foundation for accurate notifications in the future.
[0022] Furthermore, the structured Prompt in step S3 includes exception types, business call chains, and code snippets. The output format is fixed as "problem summary - root cause analysis - solution - in-depth analysis", and special analysis requirements are set for different exception types.
[0023] Furthermore, the constructed Prompt is input into the LLM (which employs a large language model with semantic understanding capabilities in the Java technology field). Leveraging the LLM's semantic understanding capabilities and knowledge from the Java technology field, the following analysis is performed:
[0024] Root cause analysis: For example, when a null pointer exception occurs, identify uninitialized objects in the code (e.g., "JsonArray jsonArray = JSON.parseArray (diaLog)" may return null, but this was not checked).
[0025] Fix generation: such as generating a code snippet for "adding a null check to jsonArray";
[0026] Prevention suggestions: such as adding a mandatory "null pointer check" rule to code reviews, or configuring log monitoring and alerts.
[0027] Furthermore, the structured report in step S4 includes exception details, responsible party, root cause analysis, remediation steps, and code snippets to ensure that developers can quickly understand and implement them.
[0028] Furthermore, in step S4, a structured report is pushed to the person responsible for the issue via Lark Webhook, and copied to the team leader. The report includes "Responsibility Assignment" and "Repair Confirmation" buttons, forming a closed-loop management system to ensure timely follow-up on issues.
[0029] Furthermore, in step S5, a unique identifier is constructed based on the exception type and code location. Within a 5-minute time window, only one report is generated for exceptions with the same identifier, reducing the frequency of LLM calls and alarm interference.
[0030] Furthermore, in step S5, a whitelist is configured on the system interface according to the exception keyword or exception type to filter out business exceptions that do not need to be processed and avoid invalid analysis.
[0031] Furthermore, in step S5, the frequency and growth trend of each type of anomaly are statistically analyzed. When the frequency of a certain type of anomaly increases by more than 50% within 1 hour, an early warning is triggered and a potential risk report is pushed out.
[0032] Another aspect of the present invention provides an LLM root cause analysis system based on Java exception stack chains, including an exception log collection and parsing module, a Git code association module, an LLM root cause diagnosis module, a notification closed-loop module, and a performance optimization module, wherein:
[0033] The exception log collection and parsing module is used to collect Java exception logs in real time, extract key information from the stack chain, filter redundant stacks in the framework, focus on the 1-5 layers of call chains closest to the business code, and select the 3 layers to ensure that the core business logic that triggers the exception is covered, while avoiding redundant stack information and forming structured data of key information.
[0034] The Git code association module is used to obtain the corresponding code snippet through the GitLab API based on the file path and line number parsed from the Java exception log, and extract the code committer information to confirm the attribution of responsibility;
[0035] The LLM Root Cause Diagnosis module uses LLM for root cause analysis, builds a structured Prompt, takes an exception stack, code snippets and context as input, and generates a root cause analysis report and remediation suggestions.
[0036] The notification loop module is used to present the root cause analysis report, code snippets, and remediation suggestions in a structured manner, and push them to the person responsible for the problem through enterprise collaboration tools (such as Lark robots);
[0037] The performance optimization module is used to implement anomaly reduction using a time window deduplication algorithm, configure an alarm whitelist, and statistically analyze frequency trends to achieve risk prediction.
[0038] Compared with existing technologies, this system and method have the following advantages:
[0039] Significantly improved analysis efficiency: The entire process of Java exception detection and root cause localization is automated. In a test conducted on the Java system of a large Internet company, 50 typical exception cases (including null pointer exception, SQL timeout, and cross-service call exception) were selected. The time taken was reduced from the traditional 30 minutes to less than 1 minute, greatly reducing the time developers spend troubleshooting.
[0040] High accuracy in root cause diagnosis: It focuses on business code through stack redundancy filtering, provides context through Git code association, and uses LLM deep semantic analysis to avoid misjudgments caused by relying on local keywords in traditional methods (such as accurately locating uninitialized objects in null pointer exceptions).
[0041] Clear accountability loop: Automatically associates code committers and provides precise notifications via Lark, resolving ambiguity in attribution and accelerating collaborative fixes;
[0042] The fix is feasible: LLM generates fix suggestions with code snippets, so developers do not need to design their own logic. They can simply replace the code to complete the fix, thus lowering the technical threshold.
[0043] Possesses risk prediction capabilities: Enables early warnings through abnormal trend statistics, shifting from "passive handling" to "proactive prevention" and reducing the online failure rate;
[0044] Adapted for distributed scenarios: Supports association of distributed links by trace_id, enabling cross-service location of the root cause of anomalies (e.g., if service A times out calling service B, it can analyze the slow method of service B). Attached Figure Description
[0045] Figure 1 This is a flowchart illustrating the LLM root cause analysis method based on Java exception stack chains.
[0046] Figure 2 This is a sample diagram of a structured Prompt.
[0047] Figure 3 This is an example image of the original exception log.
[0048] Figure 4 Example image of Git associated code.
[0049] Figure 5 Example graph showing the output analysis results for LLM.
[0050] Figure 6 This is an example diagram for a structured LLM analysis report. Detailed Implementation
[0051] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0052] like Figure 1 The diagram shown is a flowchart of the method of the present invention. This embodiment of the invention provides an LLM root cause analysis method based on Java exception stack chains, with the specific steps as follows:
[0053] Step S1, Java exception log collection and precise analysis. This includes the following steps:
[0054] Step S101, Real-time Log Collection: Receive exception logs output by Java applications through a Kafka message queue (supporting mainstream logging frameworks such as Logback and Log4j2), associate them with trace_id to achieve distributed tracing, and ensure that exception logs can trace back to the complete call context.
[0055] Step S102, Stack Redundancy Filtering: Use regular expression matching to remove fixed format noise in the logs (such as timestamp "2025-07-22T09:16:28.659+08:00", process ID "PID:1234"); filter non-business-related framework call stacks by matching framework package names (such as "org.springframework." "com.baomidou.mybatisplus."), retain only the stack level corresponding to the business code package path (such as "com.bailian.message.service."), and prioritize retaining the 3-layer business call chain closest to the exception trigger point.
[0056] Step S103, Key Information Extraction: Extract core fields from the filtered stack chain to form structured data:
[0057] Exception types (such as "java.lang.NullPointerException" and "java.sql.SQLTimeoutException");
[0058] The location of the exception code (file path "com / bailian / message / service / impl / ZhuJianOutboundProcessServiceImpl.java", line number "707");
[0059] Exception triggering methods (such as "getOutboundItemByCallId");
[0060] Associate trace_id (for distributed trace troubleshooting).
[0061] Step S2: Dynamically associate Git code and confirm responsibility attribution.
[0062] Convert the file path extracted in step S1.3 into a relative path in the Git repository, call the GitLab API (e.g., "GET / projects / :id / repository / files / :file_path / raw"), pass in the file path, branch name (e.g., "master") and line number, and extract the code context of a predetermined range of abnormal lines (e.g., 5-10 lines before and after) (ensuring that it includes key logic such as variable definitions and method calls).
[0063] By obtaining the latest committer information of the target code file through the GitLab API (such as the account "Zhang San 7895"), and associating it with the company's internal organizational structure, the person responsible for the issue and their team can be identified, laying the foundation for accurate notifications in the future.
[0064] Step S3: LLM-driven root cause analysis and remediation recommendations are generated.
[0065] Construct a structured Prompt, clearly defining LLM roles, analysis scope, and output format to ensure the accuracy of root cause diagnosis and the feasibility of remedial recommendations. An example Prompt is shown below. Figure 2 As shown, it includes exception types, business call chains, and code snippets. The output format is fixed as "problem summary - root cause analysis - solution - in-depth analysis", and special analysis requirements are set for different exception types.
[0066] Input the constructed Prompt into an LLM (such as GPT-4 or Tongyi Qianwen), and leverage the semantic understanding capabilities of the LLM and knowledge of the Java technical field to complete the following analysis:
[0067] Root cause analysis: When a null pointer exception occurs, identify uninitialized objects in the code (e.g., "JsonArray jsonArray = JSON.parseArray (diaLog)" may return null, but this was not checked).
[0068] Fix generation: For example, generating a code snippet to "add an empty check to jsonArray" (if (jsonArray== null || jsonArray.isEmpty()) { return null;});
[0069] Prevention suggestions: such as adding a mandatory "null pointer check" rule to code reviews, or configuring log monitoring alerts (to trigger a notification when the frequency of this exception exceeds a threshold).
[0070] Step S4: Structured report generation and precise notification.
[0071] Organize the root cause analysis and remediation suggestions output by LLM into a structured report, including modules such as exception details (trace_id, code location), responsible person, root cause breakdown, remediation steps, and code snippets, to ensure that developers can quickly understand and implement them.
[0072] Structured reports are pushed to the person responsible for the issue via Lark Webhook, and copied to the team leader. The reports include "Responsibility Assignment" and "Repair Confirmation" buttons, forming a closed-loop management system to ensure timely follow-up on issues.
[0073] Step S5, Performance Optimization and Risk Prediction. This includes anomaly denoising and deduplication, alarm whitelist configuration, and anomaly trend prediction. Specifically:
[0074] Anomaly denoising and deduplication: A unique anomaly identifier (e.g., “NullPointerException_ZhuJianOutboundProcessServiceImpl_707”) is constructed based on 'anomaly type + relative file path + line number' to ensure accurate deduplication of anomalies in the same scenario. Only one report is generated for anomalies with the same identifier within a 5-minute time window, reducing the frequency of LLM calls and alarm interference.
[0075] Alarm whitelist configuration: Supports configuring whitelists on the system interface by exception keywords (such as "business verification failed") or exception type to filter business exceptions that do not need to be processed (such as user input verification failure) and avoid invalid analysis.
[0076] Anomaly trend prediction: Statistically analyze the frequency and growth trend of each anomaly type. When the frequency of a certain type of anomaly (such as "database connection timeout") increases by more than 50% within 1 hour, trigger an early warning and push a potential risk report (such as "suspected database connection pool exhaustion, it is recommended to check the configuration").
[0077] Taking "NullPointerException Analysis of a Certain Enterprise Message Push System (Java Technology Stack, Based on Spring Boot + MyBatis)" as an example, the implementation process of this invention is explained in detail:
[0078] Step S1, Exception Log Collection and Analysis
[0079] Input: The system receives exception logs via Kafka. The original logs are as follows: Figure 3 As shown.
[0080] Analysis process:
[0081] Filter out noise such as timestamps and thread names, and remove framework stacks related to "org.springframework.";
[0082] Extract key information: exception type "java.lang.NullPointerException", file path "com / bailian / message / service / impl / ZhuJianOutboundProcessServiceImpl.java", line number "707", business method "getOutboundItemByCallId", and trace_id "4eba042b5456c7c6".
[0083] Step S2, Git code association.
[0084] Call the GitLab API, passing in the file path and the branch name "master", to get the code snippet before and after line 707, such as... Figure 4 As shown. Retrieve the latest submitter information for this file: account "Zhang San 7895", team "Message Development Group".
[0085] Step S3, LLM Root Cause Analysis and Remediation Recommendations.
[0086] Construct a Prompt and input it into an LLM. The LLM outputs the analysis results as follows: Figure 5 As shown.
[0087] Step S4: Report push and responsibility closure.
[0088] Generate structured reports, such as Figure 6 As shown, it is then pushed to "Zhang San 7895" via an enterprise collaboration tool robot (such as Lark robot), with a copy to the "Message R&D Team" leader;
[0089] After receiving the report, Zhang San 7895 clicked "Accept Responsibility" to confirm the processing, modified the code according to the repair plan, and submitted it for testing. The online patch was released within 10 minutes, and the anomaly was resolved.
[0090] Step S5: Performance optimization.
[0091] The system performs a 5-minute deduplication process for exceptions of type "NullPointerException_ZhuJianOutboundProcessServiceImpl_707", during which time the same type of exception will not generate a report again.
[0092] Historical data analysis of this anomaly shows no increasing trend, therefore no alert needs to be triggered.
[0093] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A method for LLM root cause analysis based on Java exception stack chain, characterized in that, Comprising the following steps: Step S1, real-time collection of Java exception logs, extraction of stack chain key information, filtering of framework redundant stacks, focusing on several layers of call chain closest to business code, forming structured data of key information; Step S2, according to the file path and line number parsed from the Java exception log, the corresponding code segment is obtained through the GitLab API, and the code submitter information is extracted to confirm the responsibility attribution; Step S3, using LLM for root cause analysis, building a structured Prompt, inputting the filtered exception stack information, the associated source code segment, and the code author determined by the version control information, LLM uses its semantic understanding ability to simulate the diagnosis process of a senior development expert, and outputs a structured repair scheme containing executable code; Step S4, report structured display of root cause analysis report, code segment, and repair suggestion, and push to the problem owner through enterprise collaboration tool robot; Step S5, using time window deduplication algorithm to realize exception noise reduction, and configuring alarm whitelist, and realizing risk prediction by counting frequency trend.
2. The Java exception stack chain based LLM root cause analysis method of claim 1, wherein, Step S1 includes the following steps: Step S101, receive the exception log output by the Java application through the Kafka message queue, associate trace_id to realize distributed link tracking, and ensure that the exception log can be traced back to the complete call context; Step S102, remove fixed format noise in the log by regular matching, and filter redundant stacks; Step S103, extract core fields from the filtered stack chain to form structured data of key information, including exception type, exception code location, exception triggering method, and associated trace_id.
3. The Java exception stack chain based LLM root cause analysis method of claim 1, wherein, In step S2, the file path extracted in step S1 is converted into a relative path in the Git repository, the GitLab API is called, the file path, branch name, and line number are input, and the code context of the predetermined range of the exception line is intercepted to ensure that the key logic is included.
4. The Java exception stack chain based LLM root cause analysis method of claim 1, wherein, In step S3, the structured Prompt includes exception type, business call chain, and code segment, and the output format is fixed as "problem summary - root cause analysis - solution - deep analysis", and special analysis requirements are set for different exception types.
5. The Java exception stack chain based LLM root cause analysis method of claim 1, wherein, In step S4, the structured report includes exception details, responsibility attribution, root cause analysis, repair steps, and code segment to ensure that developers can quickly understand and execute.
6. The Java exception stack chain based LLM root cause analysis method of claim 1, wherein, In step S4, the structured report is pushed to the problem owner through the Feishu Webhook, and the team leader is also copied; the report contains "responsibility claim" and "repair confirmation" buttons to form a closed-loop management to ensure timely follow-up of the problem.
7. The Java exception stack chain based LLM root cause analysis method of claim 1, wherein, In step S5, based on the exception type and code location, a unique identifier is built, and only one report is generated for the same identifier within a 5-minute time window, reducing the frequency of LLM calls and alarm interference.
8. The Java exception stack chain based LLM root cause analysis method of claim 1, wherein, In step S5, configure the whitelist according to the exception keyword or exception type in the system interface to filter business exceptions that do not need to be processed, avoiding invalid analysis.
9. The Java exception stack chain based LLM root cause analysis method of claim 1, wherein, In step S5, the occurrence frequency and growth trend of each abnormal type are counted, and the average frequency of the abnormality in the past 24 hours is taken as the baseline. When the actual frequency in 1 hour exceeds 150% of the baseline, a potential risk warning is triggered, and a potential risk report is pushed.
10. An LLM root cause analysis system based on a chain of Java exception stacks, characterized by, The system comprises an abnormal log collection and analysis module, a Git code association module, an LLM root cause diagnosis module, a notification closed-loop module, and a performance optimization module, wherein: The abnormal log collection and analysis module is used to collect Java exception logs in real time, extract stack chain key information, filter framework redundant stacks, focus on several layers of call chains closest to business code, and form structured data of key information. The Git code association module is used to obtain the corresponding code segment through the GitLab API according to the file path and line number parsed from the Java exception log, and extract the code submitter information to confirm the responsibility attribution. The LLM root cause diagnosis module uses LLM for root cause analysis, constructs a structured prompt, inputs the filtered exception stack information, the associated source code segment, and the code author determined by the version control information, and LLM uses its semantic understanding ability to simulate the diagnosis process of a senior development expert and output a structured repair scheme containing executable code. The notification closed-loop module is used to report and structure the root cause analysis report, the code segment, and the repair suggestion, and push them to the problem owner through an enterprise collaboration tool robot. The performance optimization module is used to realize abnormal noise reduction using a time window deduplication algorithm, configure an alarm whitelist, and realize risk prediction by counting the frequency trend.