A method for dynamic recursive tracing of operation and maintenance logs based on the ReAct paradigm

Abstract

The application discloses a kind of operation and maintenance log dynamic recursive traceability methods based on ReAct paradigm, it is related to operation and maintenance log analysis technical field, including obtaining structured clue, generating log query task, searching state fingerprint, recursive query log and generating traceability result, by ReAct intelligent body from initial time window in operation and maintenance log extraction associated object, backtracking direction and candidate time window, generate log query task and state fingerprint, when not search to have been executed fingerprint, call log query tool, to query log deduplication, to determine recursive revenue value with the ratio of the number of new events and the number of scanned rows, according to recursive revenue value expansion candidate time window, update associated object or end query branch, and connect new event and form traceability result.The application realizes the dynamic adjustment of query path by state fingerprint deduplication and recursive revenue control, reduces repeated scanning, improves operation and maintenance log traceability efficiency and result traceability.

Description

Technical Field

[0001] This invention relates to the field of operation and maintenance log analysis technology, specifically a dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm. Background Technology

[0002] With the development of cloud computing, microservices and distributed systems, applications, hosts, containers and network devices in the operation and maintenance environment continuously generate a large number of heterogeneous logs. After a failure occurs, operation and maintenance personnel usually set query conditions based on alarm time, host identifier, process identifier and session identifier, gradually expand the query time range and associate logs from different sources in order to restore the propagation process and root cause of the abnormal event.

[0003] Existing log tracing methods mostly use fixed query rules or preset call chains, making it difficult to dynamically adjust the query objects and time ranges based on the obtained log evidence. In cross-host and cross-process tracing scenarios, the same query is easily executed repeatedly, resulting in a large number of invalid scans. Furthermore, there is a lack of quantitative basis for controlling the continuation, switching, and termination of queries, leading to problems such as evidence omission, recursive out-of-control, and low tracing efficiency.

[0004] To address this, this application proposes a dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm, which can dynamically adjust the query path based on newly added log evidence and restrict invalid recursion. Summary of the Invention

[0005] The purpose of this invention is to provide a dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm, in order to solve the technical problems of existing log tracing methods mentioned in the background art, such as difficulty in dynamically adjusting the query object and time range according to newly added log evidence, easy repetition of the same query and generation of invalid scans, lack of recursive continuation, switching and termination basis, resulting in evidence omission, recursion out of control and low tracing efficiency.

[0006] To achieve the above objectives, this invention provides the following technical solution: a dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm, comprising: S1. Obtain the operation and maintenance logs within the initial time window. The ReAct agent, driven by the pre-trained large language model, extracts the associated objects, backtracking directions, and candidate time windows to form structured clues. S2. Convert the structured clues into a log query task consisting of preset query fields, and generate a status fingerprint based on the preset query fields and corresponding field values; S3. Retrieve the state fingerprint from the set of executed fingerprints. If the retrieval is successful, end the current log query branch. If the retrieval fails, the ReAct agent calls the log query tool based on the model context protocol to obtain the query log and the number of scanned lines. S4. Determine the number of new events outside the evidence chain and the next associated object based on the query log, and use the ratio of the number of new events to the number of scanned rows as the recursive reward value. S5. When the recursive return value is not less than the upper threshold, expand the candidate time window. When the recursive return value reaches the lower threshold and is less than the upper threshold, update the current associated object. Then generate the next log query task and repeat the state fingerprint generation, retrieval and query. When the recursive return value is less than the lower threshold, end the current log query branch. S6. Arrange the newly added events in chronological order and generate the source tracing results.

[0007] Preferably, the specific process of forming structured clues is as follows: The operation and maintenance logs are sorted and segmented according to timestamps. Each operation and maintenance log segment is input into the ReAct agent to identify abnormal events, host identifiers, process identifiers, and session identifiers. The objects represented by logs with at least one identical identifier are identified as associated objects. The backtracking direction is determined based on the chronological relationship between the log timestamps of associated objects and the timestamps of abnormal events. The time intervals covered by associated logs are identified as candidate time windows.

[0008] Preferably, the specific process of converting structured clues into a log query task consisting of preset query fields is as follows: Parse the structured clues to obtain the current associated object, backtracking direction, and candidate time window. The preset query fields include the current associated object field, the candidate time window field, and the backtracking direction field. Write the object identifier of the current associated object into the current associated object field. Combine the start time and end time of the candidate time window into the candidate time window field value and write it into the candidate time window field. Write the backtracking direction into the backtracking direction field. Encapsulate the current associated object field, candidate time window field, and backtracking direction field into a log query task.

[0009] Preferably, the specific process for generating the state fingerprint is as follows: Read the candidate time window field, the current associated object field, and the backtracking direction field from the log query task, normalize the format of each field value, concatenate the field name and the corresponding field value according to the preset order of the field name to form a fingerprint source string, perform a hash operation on the fingerprint source string, and use the resulting hash value as the status fingerprint.

[0010] Preferably, the specific process of retrieving the state fingerprint from the executed fingerprint set is as follows: The recursive query path of the log query task corresponding to the state fingerprint is determined as the current log query branch. The set of executed fingerprints is stored in the recursive state table. The executed state fingerprint that matches the current state fingerprint is retrieved from the recursive state table. If the retrieval is successful, the current log query branch is marked as a duplicate log query branch and the current log query branch is terminated. If the retrieval fails, the state fingerprint, the current log query branch identifier and the query level are written into the recursive state table, and then the corresponding log query task is executed.

[0011] Preferably, the specific process for obtaining the query log and the number of rows scanned is as follows: The ReAct agent generates a tool call request that conforms to the model context protocol. The tool call request includes a log query task identifier and preset query fields. The log query tool parses the tool call request, generates a parameterized log query statement and executes it in the log index. It reads the number of scanned rows from the query execution statistics and returns the query log and the number of scanned rows to the ReAct agent.

[0012] Preferably, the specific process for determining the number of newly added events outside the chain of evidence and the next associated object is as follows: Event identifiers are generated based on the log source identifier, timestamp, and log content summary of the query logs. The event identifiers are matched with existing event identifiers in the evidence chain. Unmatched query logs are identified as new events, and the number of new events is counted. Extract the object identifiers contained in each new event, exclude the object identifiers that are the same as the currently associated object, count the frequency of each remaining object identifier in the new event, and determine the object corresponding to the object with the highest frequency as the next associated object.

[0013] Preferably, the calculation process for the recursive return value is as follows: Read the number of new events and the number of scanned rows. When the number of scanned rows is greater than zero, calculate the ratio of the number of new events to the number of scanned rows and determine the resulting ratio as the recursive reward value. When the number of scanned rows is equal to zero, determine the recursive reward value as zero.

[0014] Preferably, the specific process of controlling the current log query branch based on the recursive return value is as follows: If the upper threshold is set to be greater than the lower threshold, and the recursive return value is not less than the upper threshold, keep the current associated object unchanged, merge the time windows of equal length adjacent to the candidate time window into the candidate time window along the backtracking direction, generate the next log query task based on the expanded candidate time window, and execute state fingerprint generation, state fingerprint retrieval and log query in sequence. If the recursive return value reaches the lower threshold but is less than the upper threshold, keep the candidate time window unchanged, update the next associated object to the current associated object, generate the next log query task based on the updated current associated object, and execute state fingerprint generation, state fingerprint retrieval and log query in sequence. If the recursive return value is less than the lower threshold, mark the current log query branch as the end log query branch.

[0015] Preferably, the specific process for generating the traceability result is as follows: The newly added events are sorted by timestamp. A pointing relationship is established between the newly added events that trigger the next log query task and the newly added events obtained by the next log query task, generating a directed evidence chain. The event identifier, associated object, timestamp and corresponding state fingerprint of each newly added event in the directed evidence chain are associated and stored to form the tracing result.

[0016] Compared with the prior art, the beneficial effects of the present invention are: 1. This invention analyzes the operation and maintenance logs within the initial time window using a ReAct agent driven by a pre-trained large language model, extracts related objects, backtracking directions, and candidate time windows, and encapsulates structured clues into log query tasks. It realizes the dynamic generation of subsequent query conditions and recursive query paths based on the current log evidence, which solves the problem that existing fixed query rules are difficult to adjust the query objects and time ranges as fault clues change. It reduces the operation of operation and maintenance personnel repeatedly setting query conditions, and enables continuous querying of logs across hosts, processes, and sessions along related clues, thereby improving the log retrieval efficiency and source tracing adaptability of complex faults. 2. This invention generates a state fingerprint by performing format normalization, concatenation, and hashing operations on the current associated object, candidate time window, and backtracking direction in the log query task. The fingerprint is then retrieved from the executed fingerprint set in the recursive state table. This enables the identification of duplicate log query states and the termination of corresponding log query branches. It solves the problem of circular calls and repeated scanning that may occur after dynamically generating recursive query tasks due to the regeneration of the same query conditions. It avoids repeated queries of the same log range, reduces the number of log query tool calls and index scanning overhead, and enables each log query branch to proceed in an orderly manner. 3. This invention generates event identifiers based on log source identifiers, timestamps, and content summaries, deduplicates existing events in query logs and evidence chains, counts the number of newly added events, determines the next associated object with the highest frequency, and uses the ratio of the number of newly added events to the number of scanned rows to form a recursive benefit value. This achieves a quantitative evaluation of the newly added evidence and scanning cost of a single query, solving the problem that even after excluding duplicate log query tasks, the query results may still contain duplicate events, leading to inaccurate statistics on the number of newly added evidence and a lack of objective selection criteria for the next associated object. This improves the accuracy of the statistics on newly added evidence and provides a quantitative basis for the conversion and recursive control of associated objects. 4. This invention compares the recursive return value with upper and lower thresholds, expands the candidate time window when the return is high, updates the current associated object when the return is medium, and ends the current log query branch when the return is low. It also connects new events according to timestamps and query trigger relationships, realizing hierarchical control of recursive query actions and generation of directed evidence chains. This solves the problem that after obtaining new events, the next associated object, and the recursive return value, it is still impossible to determine whether to continue recursion, expand the time range, switch associated objects, or terminate the query. It reduces low-return scanning, makes the query action dynamically change with the evidence density, and improves the coherence, readability, and verifiability of the tracing results. Attached Figure Description

[0017] Figure 1 This is a flowchart of the dynamic recursive tracing method for operation and maintenance logs of the present invention; Figure 2 This is a flowchart of the dynamic recursive tracing data processing of operation and maintenance logs according to the present invention. Detailed Implementation

[0018] 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.

[0019] Please see Figure 1 and Figure 2 The present invention provides an embodiment of a dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm, which obtains operation and maintenance logs within an initial time window, and extracts related objects, backtracking directions and candidate time windows by a ReAct agent driven by a pre-trained large language model to form structured clues; Furthermore, the abnormal event identifier and abnormal event timestamp t0 are read from the abnormal alarm record, and then the forward data retrieval duration Ta and backward data retrieval duration Tb pre-configured by the operation and maintenance platform are read. The time interval from t0-Ta to t0+Tb is determined as the initial time window. Ta is used to cover the call, login and process startup records that may exist before the abnormality occurs, and Tb is used to cover the logs written later after the abnormality occurs. The forward data retrieval duration Ta and backward data retrieval duration Tb are from the preset configuration made by the operation and maintenance platform for log latency and typical fault duration, so that the boundary of the initial time window W0 has a traceable data source. W0 = [t0 - Ta, t0 + Tb]; W0: Initial time window; t0: The time when the abnormal event occurred, originating from the abnormal alarm record; Ta: The duration of looking back from the moment of the exception, used to retrieve logs before the exception occurred; Tb: The duration extending into the future from the moment of the exception, used to obtain logs that are delayed after the exception occurs; The system reads host logs, application logs, process logs, and session audit logs within the initial time window from the log index and sorts them in ascending order according to the timestamps carried by each log. The sorted operation and maintenance logs are divided into multiple operation and maintenance log segments according to the preset segment duration or the preset number of log entries to avoid exceeding the context capacity of the pre-trained large language model in a single input. Each operation and maintenance log retains at least the log source identifier, timestamp, and log text. The host identifier, process identifier, and session identifier present in the log text are retained as verifiable fields by the field parser. The input data to the ReAct agent includes operation and maintenance log segments, abnormal event timestamps, and structured output constraints. Allowed actions include extracting object identifiers, comparing log times, outputting structured clues, and generating tool call requests. The object identifiers and log times returned by the field parser are used as observation results. The output data includes the currently associated object, backtracking direction, and candidate time windows. The ReAct agent executes in a loop of generating actions, receiving observation results, and updating structured clues. The output object identifiers exist in the input logs. If the output format validation fails, the current extraction action is re-executed. The ReAct agent identifies abnormal events, host identifiers, process identifiers, and session identifiers in each operation and maintenance log segment, and aggregates logs according to the same identifier relationship. Logs with at least one identical identifier are considered to describe the same association relationship, and the host, process, or session represented by the group of logs is identified as the associated object. For example, if two logs both contain the host identifier h17, even if the two logs come from the application log and the process log respectively, the host h17 is still identified as the associated object. Logs containing the same process identifier p842 or the same session identifier s31 form corresponding associated objects. The object identifier of the associated object is directly taken from the log field. For each set of related logs, compare the timestamp of the logs in that set with the timestamp of the abnormal event t0. If the related log is before t0, the backtracking direction is determined to be forward backtracking, that is, querying along the direction of decreasing time. If the related log is after t0, the backtracking direction is determined to be backward tracing, that is, querying along the direction of increasing time. If the same set of related logs spans t0, it is divided into two log segments at t0 and structured threads are formed respectively, so that each structured thread has only one clear backtracking direction. Read the earliest and latest timestamps in the set of related logs, and determine the time interval defined by the earliest and latest timestamps as the candidate time window. The candidate time window is the actual coverage area of ​​the related logs, which is used to narrow the retrieval scope of the next log query. For example, the anomaly alarm record gives t0 as 10:15:00 on August 18, 2030, with a preset Ta of 300 seconds and a preset Tb of 60 seconds, resulting in an initial time window from 10:10:00 to 10:16:00. After sorting and segmenting the logs within the time window, the anomaly event is identified as a service login failure, with host identifier h17, process identifier p842, and session identifier s31. The logs associated with host identifier h17 are actually distributed from 10:12:00 to 10:16:00. At 5 minutes and 00 seconds, and since the key call logs are all earlier than the timestamp of the abnormal event, the current associated object is recorded as host:h17, the backtracking direction is recorded as backward, and the candidate time window is recorded as 10:12:00 to 10:15:00, forming a structured clue. The logs corresponding to the abnormal event are used as seed events to establish an evidence chain, providing an existing event identifier set for the determination of new events. This ensures that subsequent recursive queries are simultaneously constrained by the object, direction, and time range, reducing irrelevant logs from entering the next processing step.

[0020] Please see Figure 1 and Figure 2 The present invention provides an embodiment of a dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm, which converts structured clues into log query tasks consisting of preset query fields and generates status fingerprints based on the preset query fields and corresponding field values. Furthermore, the associated objects in the structured thread are read, and the object identifier and object category of the associated object are combined to form the field value of the current associated object. For example, the host object h17 is written as host:h17 so that the log query tool can distinguish host identifiers, process identifiers or session identifiers with the same name. Then, the start time and end time of the candidate time window are read, and the start time and end time are combined to form the candidate time window field value. The start time and end time are both derived from the earliest timestamp and latest timestamp of the associated log. The backtracking direction in the structured thread is written into the backtracking direction field. The preset query fields and their respective field values ​​are encapsulated into a log query task, and the recursive query scheduler generates a log query task identifier according to the log query branch identifier and query level. The log query task identifier is used to track tool calls to avoid the same query state being unable to be identified due to different task identifiers. Then, format normalization is performed on each field value to generate the same state fingerprint for field values ​​with the same semantics but different writing styles. Leading and trailing spaces are removed from the object identifier, and the object category is converted to a preset lowercase format. Candidate time windows are uniformly converted to a year, month, day, hour, minute, and second format with time zones, and arranged according to "start time / end time". The backtracking direction is uniformly written as backward or forward. The normalization rules are pre-saved by the log query tool's interface specification to eliminate pseudo-states caused by differences in capitalization, time zone representation, and spaces. Then, according to the preset order of candidate time window fields, currently associated object fields, and backtracking direction fields, the field names and corresponding field values ​​are concatenated into a fingerprint source string X. The field names also participate in the concatenation to avoid positional ambiguity between different field values. A preset hash operation is performed on the fingerprint source string X, and the resulting hash value is used as the state fingerprint F. The calculation relationship can be represented as: F = H(X); Where X represents the fingerprint source string formed according to the preset field order, and H represents the preset deterministic hash function. In this embodiment, the SHA-256 function is used as an example. The SHA-256 function is used to convert data of arbitrary length into a fixed-length 256-bit hash value. The same X will produce the same F, so different F will be produced when the query field value changes. The status fingerprint is used to represent a determined log query status, so that subsequent steps can determine whether the status has been executed before entering the log index library, thereby preventing the formation of a circular query due to repeated time windows or repeated associated objects during the recursive process. For example, the candidate time window is normalized as follows: 2030-08-18T10:12:00+08:00 / 2030-08-18T10:15:00+08:00; +08:00 indicates a time zone offset, meaning Beijing time is Coordinated Universal Time (UTC) plus 8 hours; The current associated object is normalized to host:h17, the backtracking direction is normalized to backward, and the following fingerprint source string is formed in a preset order: candidate_window=2030-08-18T10:12:00+08:00 / 2030-08-18T10:15:00+08:00|current_object=host:h17|backtrack_direction=backward; candidate_window is the candidate window field, current_object is the current associated object field, and backtrack_direction is the backtracking direction field; Perform a SHA-256 operation on the string to obtain the state fingerprint: bb534a531690f0190ff3bce800392035299d92833d000924a7ec71cfe4a99e3c; When the candidate window start time is changed to 10:09:00, the fingerprint source string changes accordingly and generates another state fingerprint. Therefore, the query after expanding the candidate window can be identified as the new state, while the exact same log query task will hit the original state fingerprint.

[0021] Please see Figure 1 and Figure 2 The present invention provides an embodiment of a dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm. The method retrieves the status fingerprint from the set of executed fingerprints. When the retrieval is successful, the current log query branch ends. When the retrieval fails, the ReAct agent calls a log query tool based on the model context protocol to obtain the query log and the number of scanned lines. Furthermore, the recursive query path containing an initial log query task and subsequent log query tasks continuously generated by that task is defined as a log query branch. The recursive query path currently containing the log query task corresponding to the state fingerprint is the current log query branch, and the current log query branch has a determinable range. The set of executed fingerprints is stored in a recursive state table. The recursive state table records at least the state fingerprint, the current log query branch identifier, and the query level. The current log query branch identifier is generated by the sequence number of the initial structured thread. The query level increases progressively from the initial log query task. Before executing the log query task, the executed state fingerprint that is completely consistent with the current state fingerprint is retrieved in the recursive state table using the state fingerprint as the retrieval key. A successful retrieval indicates that the same current associated object, the same candidate time window, and the same backtracking direction have been executed. The current log query branch is marked as a duplicate log query branch and the branch is terminated. The log query tool is no longer called, which can cut off the recursive loop before the database scan occurs. When a retrieval fails, the state fingerprint, the current log query branch identifier, and the query level are first written into the recursive state table, and then the corresponding log query task is executed. Writing before execution ensures that the other log query branch that arrives concurrently retrieves the state, avoiding two log query branches from launching the same query at the same time. Then, the same pre-trained large language model driving the ReAct agent generates a tool call request that conforms to the model context protocol based on the log query task. The model context protocol specifies the request and response structure between the ReAct agent and the log query tool. The tool call request includes the log query task identifier and preset query fields. The preset query fields are the current associated object field, the candidate time window field, and the backtracking direction field. The log query tool performs structural validation on the tool call request, reads the fields of the currently associated object to form object filtering conditions, reads the candidate time window field to form time range conditions, reads the backtracking direction field to determine the time sorting order, and binds the above conditions to the parameterized log query statement. Parameter binding is used to limit the executable fields and reduce the risk of illegal queries entering the log index. The log query tool executes the parameterized log query statement in the log index to obtain log records that meet the filtering conditions, and returns these log records as query logs to the ReAct agent. The number of rows scanned is read from the execution statistics of this query in the log index. It represents the number of log records checked to complete this query. The number of rows scanned is different from the number of returned records in the query log. For example, if the index checks 600 rows and only 12 rows meet the object and time conditions, then the number of rows scanned is 600 and the number of returned records in the query log is 12. Using the execution statistics instead of the number of returned records as the number of rows scanned can reflect the actual retrieval range consumed by a query and provide data support for calculating the number of new evidence obtained per unit scan cost. Each record in the query log retains the log source identifier, timestamp, log text, and resolvable object identifier for subsequent deduplication. For example, the log query task identifier is Q-B01-001, the current log query branch identifier is B01, the query level is 1, and the status fingerprint is: bb534a531690f0190ff3bce800392035299d92833d000924a7ec71cfe4a99e3c; If the state fingerprint is not found in the recursive state table, the state fingerprint, B01, and level 1 are written to the recursive state table. Then, a tool call request containing Q-B01-001, host:h17, 10:12:00 to 10:15:00, and backward is generated. The log query tool performs a parameterized query based on this. The execution statistics of the log index show that 600 lines are scanned and 12 query logs are returned. If another current log query branch B02 subsequently generates the exact same state fingerprint, the retrieval is successful. B02 is marked as a duplicate log query branch and B02 ends. B02 will no longer scan the 600 log lines again. Thus, duplicate tool calls and duplicate index scans are reduced without missing new query states.

[0022] Please see Figure 1 and Figure 2 The present invention provides an embodiment of a dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm, which deduplicates the query logs, determines the number of new events outside the evidence chain and the next associated object based on the query logs, and uses the ratio of the number of new events to the number of scanned rows as the recursive reward value. Furthermore, query log deduplication includes two consecutive stages: deduplication within the current batch of query logs and comparison with existing events in the evidence chain. First, the log source identifier S, timestamp T, and log text of each query log are read. The timestamp is normalized, and leading and trailing spaces that do not affect the meaning of the event are removed from the log text. Then, a log content summary C is calculated. Finally, S, T, and C are concatenated in a fixed order, and a hash operation is performed to generate the event identifier E. The calculation relationship is expressed as follows: E = H(S + T + C); Where S comes directly from the source metadata of the log index record, T comes directly from the timestamp field of the log, C is obtained from the log body, the symbol "+" indicates concatenation in a fixed order, and H is a deterministic hash function consistent with the system preset. The same log content recorded at the same time from the same source generates the same event identifier. The query logs in this batch are grouped according to the event identifier, and only one query log is kept in each group to complete the deduplication within this batch, eliminate duplicate records generated by log forwarding retries or multiple replica indexes, and prevent duplicate records from being mistakenly counted as multiple new pieces of evidence. The evidence chain is used to store the accepted event identifiers and corresponding events. Each time a log query is completed, the newly identified events are added to the evidence chain. The event identifiers in this batch, after being deduplicated, are matched one by one with the existing event identifiers in the evidence chain. Events that match successfully are not counted as new events in this batch. Unmatched query logs are identified as new events outside the evidence chain. The number of different unmatched event identifiers is counted to obtain the number of new events N. N is the count after deduplication and excluding events already in the evidence chain, which can truly reflect the extent to which the recursive query expands the evidence chain. Extract object identifiers from the log fields and log body of each new event, and exclude object identifiers that are the same as the currently associated object. Excluding the currently associated object is to prevent the next query from looping with the same object in the same time window. The remaining object identifiers are host identifiers, process identifiers, or session identifiers. Count the frequency of each remaining object identifier in different new events. If the same object identifier appears repeatedly in the same new event, it is only counted once to avoid amplifying the frequency of a single long log. The object corresponding to the object identifier with the highest frequency is determined as the next associated object. If the frequencies are the same, select the object that appears in the new event with the earliest timestamp. Read the number of new events N and the number of rows scanned M. When M is greater than zero, use the ratio of N to M as the recursive reward value R. When M equals zero, set R to zero to avoid division by zero and to indicate that the query did not obtain new evidence through a valid scan. The calculation relationship is as follows: R = N / M (M > 0); R=0 (M=0); The recursion benefit value represents the number of new events outside the evidence chain obtained for each line of log scanned. It is used to compare the density value of query benefit and scan cost. When N is large and M is small, R is large, indicating that continuing recursion along the current query state may still obtain more new evidence. When N is small and M is large, R is small, indicating that continuing recursion will result in high scan cost but it is difficult to expand the evidence chain. For example, 12 query logs are returned. After generating event identifiers based on the log source identifier, normalized timestamp, and log content summary, it is found that 3 of them have the same event identifier as other records. After deduplication within this batch, 9 different events remain. These are then matched with existing event identifiers in the evidence chain, 4 of which already exist. Therefore, the number of new events N outside the evidence chain is 9-4=5. Among the five new events, after excluding the current associated object host:h17, process identifier p842 appears in 4 new events, session identifier s31 appears in 3 new events, and another host identifier h22 appears in 2 new events. Therefore, process:p842 is determined as the next associated object. Given a scan line count M of 600, we get: R = 5 / 600 = 0.00833; N, M, and R are derived from the event identifier matching results, log index database execution statistics, and calculation results, respectively.

[0023] Please see Figure 1 and Figure 2 The present invention provides an embodiment of a dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm. When the recursive benefit value is not less than the upper threshold, the candidate time window is expanded. When the recursive benefit value reaches the lower threshold but is less than the upper threshold, the current associated object is updated. Then, the next log query task is generated and the state fingerprint generation, state fingerprint retrieval and log query are repeated. When the recursive benefit value is less than the lower threshold, the current log query branch is terminated. After each log query branch is completed, the newly added events are connected in chronological order to generate the tracing result. Furthermore, an upper limit threshold U and a lower limit threshold L are preset, with U being greater than L. Both thresholds and the recursive profit value use the same unit, representing the number of new events corresponding to a unit of scanned rows. The thresholds are obtained by replaying historical fault logs. The ratio of the number of new events to the number of scanned rows is calculated for each historical query. The high-profit query interval that can still obtain valid new evidence is used to determine U, and the low-profit query interval that is difficult to obtain new evidence is used to determine L. The determined value is then written into the recursive control configuration. When R is not less than U, it indicates that the current associated object still has a high evidence density near the current time boundary. Keeping the current associated object unchanged, the time windows of equal length adjacent to the candidate time window are merged into the candidate time window along the backtracking direction. The length of the equal-length time window is obtained by subtracting the start time from the end time of the current candidate time window. When backtracking forward, the time interval located before the current candidate time window and adjacent to its boundary is selected. When tracing backward, the adjacent time interval located after the current candidate time window is selected. After merging, the next log query task is generated according to the expanded candidate time window, and the state fingerprint generation, state fingerprint retrieval and log query are re-executed. This process expands the time coverage when the benefit is high, while keeping the object unchanged, so as to continuously track the earlier or later activities of the same object. When R reaches L and is less than U, it indicates that the current time window still contains new evidence, but the benefit of continuing to expand the time range around the current associated object is limited. At this time, the candidate time window is kept unchanged, the determined next associated object is updated to the current associated object, and the next log query task is generated according to the updated current associated object. Then, state fingerprint generation, state fingerprint retrieval and log query are executed in sequence. The association between hosts, processes or sessions is used to make the recursive path shift from existing objects to objects that are more likely to carry new clues. Since the candidate time window remains unchanged, the benefit change caused by object switching can be compared within the same time range. When R is less than L, it means that the density of new evidence obtained in this scan is lower than the minimum return required to continue the query. The current log query branch is marked as the end of the log query branch, and no more log query tasks will be generated for this branch. The three judgment intervals are R not less than U, R reaches L and is less than U, and R is less than L. The three judgment intervals do not overlap and cover all values. Therefore, the same recursive return value will only trigger one control action. In addition to ending when the return is insufficient, the current log query branch will also end when a duplicate state fingerprint is retrieved. Both ending results are written to the recursive state table in order to determine whether all log query branches have ended. For example, based on the historical fault log replay preset U is 0.008 and L is 0.003, the R of log query task Q-B01-001 is 0.00833, satisfying that R is not less than U. The current candidate time window is from 10:12:00 to 10:15:00, with a time window length of 180 seconds and a backward tracing direction. Therefore, the adjacent equal-length time window from 10:09:00 to 10:12:00 is selected and merged into the original candidate time window, resulting in an expanded candidate time window of 10:09:00 to 10:15:00. The current associated object is still host:h17. Based on this, a second log query task is generated. The second log query task obtains... Two new events are obtained and 400 lines are scanned. R = 2 / 400 = 0.005, which satisfies L not greater than R and R less than U. Among the new events, process:p842 is the non-current object with the highest frequency of occurrence. Therefore, the time from 10:09:00 to 10:15:00 remains unchanged. The current associated object is updated to process:p842 and a third log query task is generated. The third log query task obtains one new event and scans 500 lines. R = 1 / 500 = 0.002, which is less than L. Therefore, the current log query branch B01 ends. B02 has ended due to the duplicate state fingerprint. At this point, all log query branches are in the ended state. After each log query branch is completed, the newly added events determined by each query are summarized, and duplicate events between different log query branches are eliminated again according to the event identifier. Then, they are sorted in ascending order of timestamp. For the newly added events that trigger the next log query task, the pointing relationship between the event identifier and the newly added events obtained by the next log query task is recorded: In the case of expanding the candidate time window, the newly added events that are close to the candidate time window boundary and contain the current associated object are taken as expansion trigger events. In the case of updating the current associated object, the newly added events that contain the next associated object and are used to determine the object switch are taken as update trigger events. The expansion trigger event indicates that new evidence of the current associated object is still found near the candidate time window boundary, and the time range is continued to be expanded along the backtracking direction. The update trigger event indicates that the query object is switched to the next associated object because the next associated object appears in the newly added event. The pointing relationship represents the clue expansion relationship of the log query path. The final time sorting does not change the pointing relationship. Each newly added event is used as an evidence node, the extended trigger event or the update trigger event is used as the starting node, and the newly added event obtained by the next log query task is used as the target node. Directed edges are established according to the recorded pointing relationship. The nodes and directed edges of each log query branch are merged, and the event identifier, timestamp, associated object and state fingerprint are associated and stored to generate a directed evidence chain, which is used to record the evidence discovery order and recursive query path. The event identifier, associated object, timestamp and the state fingerprint corresponding to the acquisition of the newly added event are associated and stored to form the tracing result. For example, the three log query tasks yielded a total of 8 new events outside the evidence chain. After deduplication across branches, there were still 8 events, arranged by timestamp from 10:09:40 to 10:14:50. The new event at 10:11:50 in the second log query task contained both host:h17 and process:p842. This event identified process:p842 as the next associated object. Therefore, a pointing relationship was established between this event and the new events obtained by the third log query task. Each event was associated with and stored along with the event identifier, associated objects such as host:h17 or process:p842, the original log timestamp, and the corresponding status fingerprint. The final tracing result not only provides an event sequence that can be read by time, but also retains the recursive path from a new piece of evidence to trigger the next log query task and obtain subsequent evidence. This makes it easy for operations and maintenance personnel to verify which query each piece of evidence came from and why the recursion continued or stopped. This solves the problems of fixed query chains being prone to repeated scanning, blindly expanding the time range, and being difficult to explain the tracing path.

[0024] Working principle: During runtime, the operation and maintenance logs within the initial time window are obtained based on the abnormal alarm time, and sorted and segmented by timestamp. The ReAct agent, driven by a pre-trained large language model, identifies abnormal events and host, process and session identifiers. Based on the same identifier, the associated objects are determined. Based on the log time relationship, the backtracking direction and candidate time windows are determined to form structured clues. The current associated objects, candidate time windows and backtracking direction are written into preset query fields, encapsulated into a log query task, and the normalized field names and field values ​​are hashed to generate a state fingerprint. Before querying, the state fingerprint is retrieved from the set of executed fingerprints stored in the recursive state table. If the retrieval is successful, the current log query branch ends. If the retrieval fails, the ReAct agent calls the log query tool based on the model context protocol to obtain the query log and the number of scanned lines. The query log is deduplicated, and logs that do not match existing events in the evidence chain are identified as new events. The next associated object is determined based on the frequency of occurrence of non-current object identifiers. The ratio of the number of new events to the number of scanned lines is used as the recursive reward value. When the recursive reward value is not less than the upper threshold, the candidate time window is expanded. When the lower threshold is reached but less than the upper threshold, the current associated object is updated. When it is less than the lower threshold, the current log query branch ends. After each branch ends, the new events are sorted by time and a pointing relationship is established to generate a directed evidence chain and tracing results.

[0025] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, it is intended that all variations falling within the meaning and scope of equivalents of the claims be included within the present invention.

Claims

1. A dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm, characterized in that: include: S1. Obtain the operation and maintenance logs within the initial time window. The ReAct agent, driven by the pre-trained large language model, extracts the associated objects, backtracking directions, and candidate time windows to form structured clues. S2. Convert the structured clues into a log query task consisting of preset query fields, and generate a status fingerprint based on the preset query fields and corresponding field values; S3. Retrieve the state fingerprint from the set of executed fingerprints. If the retrieval is successful, end the current log query branch. If the retrieval fails, the ReAct agent calls the log query tool based on the model context protocol to obtain the query log and the number of scanned lines. S4. Determine the number of new events outside the evidence chain and the next associated object based on the query log, and use the ratio of the number of new events to the number of scanned rows as the recursive reward value. S5. When the recursive return value is not less than the upper threshold, expand the candidate time window. When the recursive return value reaches the lower threshold and is less than the upper threshold, update the current associated object. Then generate the next log query task and repeat the state fingerprint generation, retrieval and query. When the recursive return value is less than the lower threshold, end the current log query branch. S6. Arrange the newly added events in chronological order and generate the source tracing results.

2. The dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm as described in claim 1, characterized in that: The specific process for forming structured clues is as follows: The operation and maintenance logs are sorted and segmented according to timestamps. Each operation and maintenance log segment is input into the ReAct agent to identify abnormal events, host identifiers, process identifiers, and session identifiers. The objects represented by logs with at least one identical identifier are identified as associated objects. The backtracking direction is determined based on the chronological relationship between the log timestamps of associated objects and the timestamps of abnormal events. The time intervals covered by associated logs are identified as candidate time windows.

3. The dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm as described in claim 2, characterized in that: The specific process of converting structured clues into log query tasks consisting of preset query fields is as follows: Parse the structured clues to obtain the current associated object, backtracking direction, and candidate time window. The preset query fields include the current associated object field, the candidate time window field, and the backtracking direction field. Write the object identifier of the current associated object into the current associated object field. Combine the start time and end time of the candidate time window into the candidate time window field value and write it into the candidate time window field. Write the backtracking direction into the backtracking direction field. Encapsulate the current associated object field, candidate time window field, and backtracking direction field into a log query task.

4. The dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm as described in claim 1, characterized in that: The specific process for generating the state fingerprint is as follows: Read the candidate time window field, the current associated object field, and the backtracking direction field from the log query task, normalize the format of each field value, concatenate the field name and the corresponding field value according to the preset order of the field name to form a fingerprint source string, perform a hash operation on the fingerprint source string, and use the resulting hash value as the status fingerprint.

5. The dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm as described in claim 1, characterized in that: The specific process of retrieving the state fingerprint from the executed fingerprint set is as follows: The recursive query path of the log query task corresponding to the state fingerprint is determined as the current log query branch. The set of executed fingerprints is stored in the recursive state table. The executed state fingerprint that matches the current state fingerprint is retrieved from the recursive state table. If the retrieval is successful, the current log query branch is marked as a duplicate log query branch and the current log query branch is terminated. If the retrieval fails, the state fingerprint, the current log query branch identifier and the query level are written into the recursive state table, and then the corresponding log query task is executed.

6. The dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm as described in claim 1, characterized in that: The specific process for obtaining the query log and the number of rows scanned is as follows: The ReAct agent generates a tool call request that conforms to the model context protocol. The tool call request includes a log query task identifier and preset query fields. The log query tool parses the tool call request, generates a parameterized log query statement and executes it in the log index. It reads the number of scanned rows from the query execution statistics and returns the query log and the number of scanned rows to the ReAct agent.

7. The dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm as described in claim 1, characterized in that: The specific process for determining the number of newly added events outside the chain of evidence and the next associated object is as follows: Event identifiers are generated based on the log source identifier, timestamp, and log content summary of the query logs. The event identifiers are matched with existing event identifiers in the evidence chain. Unmatched query logs are identified as new events, and the number of new events is counted. Extract the object identifiers contained in each new event, exclude the object identifiers that are the same as the currently associated object, count the frequency of each remaining object identifier in the new event, and determine the object corresponding to the object with the highest frequency as the next associated object.

8. The dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm as described in claim 1, characterized in that: The calculation process for the recursive return value is as follows: Read the number of new events and the number of scanned rows. When the number of scanned rows is greater than zero, calculate the ratio of the number of new events to the number of scanned rows and determine the resulting ratio as the recursive reward value. When the number of scanned rows is equal to zero, determine the recursive reward value as zero.

9. The dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm according to claim 1, characterized in that: The control process for the current log query branch is as follows: If the upper threshold is set to be greater than the lower threshold, and the recursive return value is not less than the upper threshold, keep the current associated object unchanged, merge the time windows of equal length adjacent to the candidate time window into the candidate time window along the backtracking direction, generate the next log query task based on the expanded candidate time window, and execute state fingerprint generation, state fingerprint retrieval and log query in sequence. If the recursive return value reaches the lower threshold but is less than the upper threshold, keep the candidate time window unchanged, update the next associated object to the current associated object, generate the next log query task based on the updated current associated object, and execute state fingerprint generation, state fingerprint retrieval and log query in sequence. If the recursive return value is less than the lower threshold, mark the current log query branch as the end log query branch.

10. The dynamic recursive tracing method for operation and maintenance logs based on the ReAct paradigm according to claim 1, characterized in that: The specific process for generating the source tracing results is as follows: The newly added events are sorted by timestamp. A pointing relationship is established between the newly added events that trigger the next log query task and the newly added events obtained by the next log query task, generating a directed evidence chain. The event identifier, associated object, timestamp and corresponding state fingerprint of each newly added event in the directed evidence chain are associated and stored to form the tracing result.

Images