Operation and maintenance methods, devices and electronic equipment of trading systems

Abstract

This application discloses a method, apparatus, and electronic device for the operation and maintenance of a transaction system. The method relates to the field of operation and maintenance. The method includes: acquiring multi-source log data generated by the transaction system, wherein the multi-source log data includes at least multiple system logs and multiple business logs; performing standardization and template matching processing on the multiple system logs to obtain system log processing results, wherein the system log processing results include multiple standardized system logs and multiple target templates corresponding to the standardized system logs; restoring the transaction status based on the multiple business logs to obtain business log processing results; identifying multiple target abnormal events based on the system log processing results and the business log processing results; merging the multiple target abnormal events to obtain initial alarm information; and performing fault analysis on the initial alarm information through an alarm intelligence agent to obtain an alarm report for the operation and maintenance of the transaction system.

Description

Technical Field

[0001] This application relates to the field of operation and maintenance, and more specifically, to a method, apparatus, and electronic equipment for the operation and maintenance of a trading system. Background Technology

[0002] In the field of distributed system log monitoring and operation and maintenance, related technical solutions mainly rely on two traditional methods: one is single-point log analysis based on keyword regular expression matching, and the other is static threshold alarms based on fixed time windows. The former performs a full-text scan of log content by preset keywords (such as "error") to quickly identify surface anomalies of individual service nodes; the latter sets fixed trigger conditions, such as issuing an alarm if an interface reports more than 30 errors within five minutes. These methods are easy to deploy, suitable for anomaly detection of single components, and have certain practical value in scenarios with simple system structures and small log sizes.

[0003] The above-mentioned operation and maintenance methods are not applicable when applied to complex transaction systems with high concurrency and multi-component collaboration (such as all-in-one card systems). With the rapid development of mobile payment and IoT technologies, all-in-one card systems have evolved from simple single-machine processing to massive distributed systems including software gateways, front-end servers, transaction security management platforms (TSM), mobile services, and underlying databases (such as Oracle databases). In this environment, system logs come from multiple sources, have inconsistent formats, and are out of sequence, with a lack of semantic correlation mechanisms between logs from different components. When complex transaction failures involving multiple system components occur, the logs originate from different systems, have inconsistent formats, and are out of sequence, making it impossible to correlate the scattered logs and reconstruct sessions. In a high-concurrency, out-of-order, multi-source log environment, it is impossible to effectively reconstruct cross-component transaction links. Operation and maintenance personnel can only rely on multi-departmental collaborative troubleshooting after user reports, a cumbersome process with delayed responses. This results in long fault location times and low accuracy during operation and maintenance, impacting user experience and system stability.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for the operation and maintenance of a transaction system, which at least solves the technical problem that, due to reliance on manual repair reporting, it is impossible to effectively restore the cross-component transaction link in a high-concurrency, out-of-order, multi-source log environment, resulting in long fault location time and low accuracy when pushing alarms.

[0006] According to one aspect of the embodiments of this application, a method for operating and maintaining a transaction system is provided, comprising: acquiring multi-source log data generated by the transaction system, wherein the multi-source log data includes at least multiple system logs and multiple business logs, wherein the system logs are logs generated by system components of the transaction system to record system operating status, connection anomalies, or service errors, and the business logs are logs triggered by payment interaction behaviors initiated by terminal devices; performing standardization processing and template matching processing on the multiple system logs to obtain system log processing results, wherein the system log processing results include multiple standardized system logs and multiple target templates corresponding to the multiple standardized system logs. The process includes: a target template indicating at least one system error characteristic; restoring transaction status based on multiple business logs to obtain business log processing results, where the business log processing results at least indicate the corresponding business types when multiple terminals in the target monitoring area conduct transactions; determining multiple target abnormal events based on the system log processing results and business log processing results, where the target abnormal events are at least one of the following: system-level abnormal events and business-level abnormal events; merging multiple target abnormal events to obtain initial alarm information; and performing fault analysis on the initial alarm information through an alarm intelligence agent to obtain an alarm report for transaction system operation and maintenance.

[0007] Optionally, multiple system logs are standardized and template matched to obtain system log processing results, including: replacing the dynamic parameters in the multiple system logs with preset placeholders to obtain multiple standardized system logs, wherein dynamic parameters refer to parameters whose values ​​are not fixed in different system logs; performing similarity matching between the multiple standardized system logs and multiple templates in a template library to obtain target templates corresponding to the multiple standardized system logs; and determining the set consisting of the multiple standardized system logs and the target templates corresponding to the multiple standardized system logs as the system log processing results.

[0008] Optionally, multiple standardized system logs are matched with multiple templates in a template library to obtain target templates corresponding to each standardized system log. This includes: determining a first type of template from multiple templates in the template library, wherein the first type of template is a template whose length difference between the lexical sequence and the lexical sequence of the first system log is less than a first preset threshold, and the first system log is any one of the multiple standardized system logs; determining the edit distance between multiple templates in the first type of template and the first system log to obtain multiple edit distances, wherein the edit distance of the first template is the minimum number of operation steps required to convert the lexical sequence of the first system log into the lexical sequence of the first template, and the first template is any one of the first type of templates; converting the multiple edit distances into multiple similarity percentages, and determining the first type of templates with a similarity percentage greater than a second preset threshold as candidate templates; obtaining the target words defined in the template content of the candidate templates, and determining the candidate templates whose target words all exist in the first system log as the target templates corresponding to the first system log.

[0009] Optionally, transaction status restoration is performed based on multiple business logs to obtain business log processing results, including: using the terminal number as the isolation key, session extraction is performed on multiple business logs to obtain multiple transaction sessions, where each transaction session reflects the complete lifecycle of a transaction on a terminal; from the multiple transaction sessions, transaction code sequences are extracted to obtain multiple transaction code sequences, each consisting of multiple transaction operation codes arranged chronologically, with each transaction code sequence corresponding to one of the multiple transaction sessions; business type matching is performed on the multiple transaction code sequences to obtain the business types corresponding to each of the multiple transaction sessions; error codes associated with each of the multiple transaction sessions are extracted, and the error codes associated with each of the multiple transaction sessions are converted into standardized Chinese descriptions using a preset error code translation table. A set of initial error business information corresponding to multiple transaction sessions is obtained. A preset error code translation table stores standardized Chinese meanings for various error codes. The initial error business information sets corresponding to multiple transaction sessions are filtered in the following way to obtain target error business information sets corresponding to multiple transaction sessions: The target standardized Chinese description is filtered from the initial error business information set corresponding to the first transaction session to obtain the target error business information set corresponding to the first transaction session. Here, the first transaction session can be any one of the multiple transaction sessions, and the target standardized Chinese description is the standardized Chinese description mapped to the normal business rejection code under the business type corresponding to the first transaction session. The business types corresponding to multiple transaction sessions and the target error business information sets are jointly determined as the business log processing result.

[0010] Optionally, business type matching is performed on multiple transaction code sequences to obtain business types corresponding to multiple transaction sessions, including: extracting transaction opcode combinations contained in multiple transaction code sequences to obtain multiple transaction opcode combinations, wherein each transaction code sequence in the multiple transaction code sequences corresponds to one transaction opcode combination in the multiple transaction opcode combinations; for the multiple transaction opcode combinations, business type matching is performed through a business type rule base to obtain business types corresponding to multiple transaction sessions, wherein the business type rule base contains multiple predefined mapping relationships between transaction opcode combinations and corresponding business types.

[0011] Optionally, multiple target abnormal events are determined based on the system log processing results and business log processing results, including: determining the matching frequency corresponding to multiple target templates based on the system log processing results, wherein the matching frequency of the first target template is the total number of standardized system logs that simultaneously match the first target template, and the first target template is any one of the multiple target templates; generating a system-level abnormal event for each target template whose matching frequency is greater than a corresponding first threshold, wherein the first threshold is a system-level abnormal event triggering threshold; determining the business type whose transaction result is failed in the business log processing results as the target business type; determining the frequency of the target business type appearing in the business log processing results as the failure frequency; generating a business-level abnormal event for each target business type whose failure frequency is greater than a corresponding second threshold, wherein the second threshold is a business-level abnormal event triggering threshold; and determining the set of all generated system-level abnormal events and all business-level abnormal events as multiple target abnormal events.

[0012] Optionally, the method further includes: determining the first threshold corresponding to any one of the multiple target templates by: determining multiple initial first thresholds corresponding to the first target template, wherein each of the multiple initial first thresholds corresponds to a time period, the multiple initial first thresholds are determined based on the first abnormal event data within the historical time period, the first abnormal event data being all system-level abnormal events corresponding to the first target template generated within the historical time period; determining the first target time period that generates multiple system logs, and determining the initial first threshold corresponding to the first target time period as the first threshold corresponding to the first target template.

[0013] Optionally, the method further includes: determining the second threshold corresponding to any target business type in the following manner: obtaining multiple initial second thresholds corresponding to the first target business type, wherein the first target business type is any one of all target business types whose transaction result is failure, each of the multiple initial second thresholds corresponds to a time period, the multiple initial second thresholds are determined based on the second abnormal event data within the historical time period, the second abnormal event data is all business-level abnormal events corresponding to the first target business type generated within the historical time period; determining the second target time period that generates multiple business logs, and determining the initial second threshold corresponding to the second target time period as the second threshold corresponding to the first target business type.

[0014] Optionally, multiple target abnormal events are merged to obtain initial alarm information, including: merging multiple target abnormal events acquired within the target time window according to timestamps to obtain an abnormal event set; extracting multi-dimensional features corresponding to the abnormal event set, wherein the multi-dimensional features include an error code set, a set of involved systems, a set of involved physical regions, and a set of abnormal business types; generating a target hash key based on the multi-dimensional features; and determining the multi-dimensional features corresponding to the abnormal event set as the initial alarm information when the count of the target hash key in the database is 0 within a preset time period.

[0015] Optionally, the alarm agent performs fault analysis on the initial alarm information to obtain an alarm report for transaction system operation and maintenance. This includes: when the initial alarm information hits the target information, the alarm agent is guided by prompts to perform multiple rounds of fault reasoning analysis on the initial alarm information to obtain a preliminary alarm report. Each round of fault reasoning analysis includes anomaly characterization, root cause location, business assessment, and processing measure generation. The target information is at least one of the following: a preset anomaly class name, a preset component identifier; the preliminary alarm report is verified for accuracy to obtain an accuracy verification result, and if the accuracy verification result is successful, the preliminary alarm report is determined as the alarm report for transaction system operation and maintenance.

[0016] Optionally, the alarm agent is guided by prompts to perform multiple rounds of fault reasoning analysis on the initial alarm information to obtain a preliminary alarm report. This includes: iteratively executing steps 1-3 until a stopping condition is reached, at which point the iteration stops; the alarm agent analyzes the initial alarm information after the iteration stops to generate a preliminary alarm report. The stopping condition is that the iteration rounds reach a preset maximum number of rounds or a target preset number of rounds. The alarm agent's response indicates termination of the iteration process. The initial iteration rounds are 0, the target preset number of rounds is less than the preset maximum number of rounds, and the response information is an alarm... The response information of the entity to the verification prompt words input to the alarm agent. The verification prompt words are used to guide the alarm agent to evaluate the fault reasoning and analysis process: Step 1: Under the guidance of the target prompt words, the alarm agent is driven to call various fault diagnosis tools to perform anomaly identification, root cause location, business evaluation, and handling measure generation on the initial alarm information to obtain target analysis information. The target analysis information includes all the information generated in the process of anomaly identification, root cause location, business evaluation, and handling measure generation; Step 2: The target analysis information is determined as the new initial alarm information; Step 3: The iteration round is incremented by 1.

[0017] Optionally, the accuracy of the preliminary alarm report is verified to obtain the accuracy verification result, including: determining multiple target diagnostic tools from a preset diagnostic tool library through the alarm agent, and generating multiple verification actions to verify the accuracy of the preliminary alarm report through the multiple target diagnostic tools; executing the multiple verification actions through the multiple target diagnostic tools to obtain the verification action execution result; and analyzing the verification action execution result through the alarm agent to obtain the accuracy verification result.

[0018] According to another aspect of the embodiments of this application, an alarm information determination device is also provided, comprising: acquiring multi-source log data generated by a transaction system, wherein the multi-source log data includes at least multiple system logs and multiple business logs, wherein the system logs are logs generated by system components of the transaction system for recording system operating status, connection anomalies, or service errors, and the business logs are logs triggered by payment interaction behavior initiated by a terminal device; a first processing module, configured to perform standardization processing and template matching processing on the multiple system logs to obtain a system log processing result, wherein the system log processing result includes multiple standardized system logs and multiple target templates corresponding to the multiple standardized system logs, wherein the target templates are at least used to indicate A system error reporting feature; a transaction status restoration module, used to restore the transaction status based on multiple business logs to obtain business log processing results, wherein the business log processing results are used to indicate the corresponding business types when multiple terminals in the target monitoring area conduct transactions; a determination module, used to determine multiple target abnormal events based on the system log processing results and business log processing results, wherein the target abnormal events are at least one of the following: system-level abnormal events and business-level abnormal events; a second processing module, used to merge and process the multiple target abnormal events to obtain initial alarm information; and a fault analysis module, used to perform fault analysis on the initial alarm information through an alarm intelligence agent to obtain an alarm report for transaction system operation and maintenance.

[0019] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, in which a program is stored, wherein, when the program is running, it controls the device where the non-volatile storage medium is located to execute the above-mentioned operation and maintenance method of the transaction system.

[0020] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the above-described operation and maintenance method of the transaction system when it runs.

[0021] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions, which, when executed by a processor, implement the above-described operation and maintenance method for the transaction system.

[0022] In this embodiment, multi-source log data generated by the transaction system is acquired. This multi-source log data includes at least multiple system logs and multiple business logs. System logs are generated by system components of the transaction system to record system operating status, connection anomalies, or service errors. Business logs are triggered by payment interactions initiated by terminal devices. The system logs are standardized and template-matched to obtain system log processing results. These results include multiple standardized system logs and multiple target templates corresponding to them. Each target template indicates at least one system error characteristic. The transaction status is then determined based on the multiple business logs. The process involves restoring the system logs to their original state, obtaining the business log processing results. These results indicate the corresponding business types for transactions conducted by multiple terminals within the target monitoring area. Based on the system log processing results and the business log processing results, multiple target anomalies are identified. These anomalies are at least one of the following: system-level anomalies or business-level anomalies. These multiple target anomalies are then merged to obtain initial alarm information. An alarm intelligence agent performs fault analysis on the initial alarm information to generate an alarm report for transaction system maintenance. Different processing methods are applied to the system logs and business logs to obtain system log processing results and business log processing results, thus restoring the transaction status. By identifying multiple target anomalies based on the two types of log processing results and analyzing them through an alarm intelligence agent to obtain the final alarm report for maintenance, the system ... Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0024] Figure 1 This is a hardware structure block diagram of a computer terminal for implementing an operation and maintenance method for a trading system, according to an embodiment of this application.

[0025] Figure 2 This is a flowchart of an operation and maintenance method for a trading system provided according to an embodiment of this application;

[0026] Figure 3 This is a flowchart of another operation and maintenance method for a trading system provided according to an embodiment of this application;

[0027] Figure 4 This is a block diagram of a module structure provided according to an embodiment of this application;

[0028] Figure 5 This is a schematic diagram of the structure of an operation and maintenance device for a transaction system according to an embodiment of this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] The information collected in this application embodiment is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant regions, and necessary confidentiality measures have been taken. It does not violate public order and good morals, and provides corresponding operation entry points for users to choose to authorize or reject the automated decision results. If the user chooses to reject, the process will proceed to the expert decision-making process.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0033] A unified campus card system refers to a distributed information system integrated into the university campus environment for unified management of comprehensive services such as student and faculty identification, payment, access control, library borrowing, and utility bill payment. This system achieves the business goal of "one card (or one code) for access and unified settlement" through multi-terminal and multi-platform collaboration. The system is a distributed system comprising a software gateway, a front-end server, a transaction security management platform (TSM), mobile services, and an underlying database (such as an Oracle database).

[0034] Large Language Model (LLM): A general-purpose natural language processing model trained on massive amounts of text data. It can generate coherent text content based on input prompts and has the ability to understand, reason, and generate language.

[0035] In related technologies, with the rapid development of mobile payment and IoT technologies, the architecture of smart card systems has evolved from simple single-machine processing to a massive distributed system encompassing a software gateway, front-end server, Transaction Security Management Platform (TSM), mobile services, and underlying databases (such as Oracle databases). In this environment, system logs come from multiple sources, have inconsistent formats, and exhibit chaotic timing, with a lack of semantic correlation mechanisms between logs from different components. When complex transaction failures involving multiple system components occur, the logs originate from different systems, have inconsistent formats, and exhibit chaotic timing, making it impossible to correlate the scattered logs and reconstruct sessions. In high-concurrency, out-of-order, multi-source log environments, it is impossible to effectively reconstruct cross-component transaction chains. Maintenance personnel can only rely on multi-departmental collaborative troubleshooting after user reports, a cumbersome process with delayed responses. This results in long fault location times and low accuracy during maintenance, impacting user experience and system stability. Therefore, due to the reliance on manual repair reporting, in high-concurrency, out-of-order, multi-source log environments, it is impossible to effectively reconstruct cross-component transaction chains, resulting in long fault location times and low accuracy when pushing alarms. To solve this problem, this application provides relevant solutions, which are described in detail below.

[0036] According to an embodiment of this application, an embodiment of an operation and maintenance method for a trading system is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] The methods and embodiments provided in this application can be executed on a computer terminal or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing an operation and maintenance method for a trading system is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0038] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0039] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the operation and maintenance method of the trading system in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned operation and maintenance method of the trading system. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0040] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0041] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0042] Under the aforementioned operating environment, embodiments of this application provide a method for the operation and maintenance of a trading system, such as... Figure 2 The diagram shown is a flowchart of an operation and maintenance method for a trading system according to an embodiment of this application, including:

[0043] Step S202: Obtain multi-source log data generated by the transaction system.

[0044] The multi-source log data includes at least multiple system logs and multiple business logs. The system logs are generated by the system components of the transaction system to record the system's operating status, connection anomalies, or service errors. The business logs are logs triggered by payment interaction behaviors initiated by terminal devices.

[0045] Step S204: Standardize and template match multiple system logs to obtain the system log processing results.

[0046] The system log processing results include multiple standardized system logs and multiple target templates corresponding to the multiple standardized system logs. The target template is used to indicate at least one system error characteristic.

[0047] Step S206: Restore the transaction status based on multiple business logs to obtain the business log processing result.

[0048] Among them, the business log processing results are used to indicate at least the corresponding business types when multiple terminals in the target monitoring area conduct transactions.

[0049] Step S208: Determine multiple target abnormal events based on the system log processing results and the business log processing results.

[0050] The target abnormal event must be at least one of the following: a system-level abnormal event or a business-level abnormal event.

[0051] Step S210: Merge multiple target abnormal events to obtain initial alarm information.

[0052] Step S212: The alarm agent performs fault analysis on the initial alarm information to obtain an alarm report for the operation and maintenance of the transaction system.

[0053] In some embodiments of this application, the transaction system is specifically a unified card system. Step S202 is implemented by a log collection module, which is deployed on the host machine or log agent node of each component of the transaction system. Through a standardized log collection agent, it non-intrusively monitors and collects raw log files from each component of the system in real time. The multi-source log data includes two categories: system logs and business logs, whose sources and contents are defined as follows:

[0054] System logs are generated by the system components of the transaction system to record system operating status, connection anomalies, or service errors. They record system-level status events, including but not limited to: network anomalies such as connection timeouts in the soft gateway component; thread pool exhaustion, message queue backlog, and high load warnings on the front-end server; key loading anomalies in the Transaction Security Management Platform (TSM); and database errors such as connection rejection and session timeouts in the underlying database. All system logs are structured or semi-structured text. Each log entry contains fields such as timestamp, hostname, port number, IP address, numeric error code, and stack trace. The content does not include business semantic information such as user identity, transaction amount, or payment medium type.

[0055] Business logs are logs triggered by payment interactions initiated by terminal devices (such as POS terminals, mobile apps, and NFC card readers). For a smart card system, business logs specifically refer to logs with clear business semantics actively output by application-layer services during the process of user-facing terminal devices initiating or participating in payment interactions. Their core function is to depict the complete business lifecycle of a transaction, rather than the system's operational status. Each business log is strongly associated with a specific terminal payment action (linked via terminal number), and its generation occurs at key nodes in the transaction process, such as: payment request issuance (e.g., "scanning successful"); payment instruction sent to the TSM (e.g., "initiate signature verification"); TSM return a result (e.g., "verification successful" or "rejected: insufficient balance"); payment result written to the account (e.g., "deduction successful").

[0056] After obtaining multi-source log data, it is necessary to process the out-of-order logs from multiple sources. The method in this embodiment of the application processes multi-source system logs by executing steps S204 and S206. The specific execution order of steps S204 and S206 is not limited. Steps S204 and S206 can be processed simultaneously in parallel or in the order of steps S204 and S206.

[0057] To address the technical shortcomings of inefficient regular expression matching, high false matching rates, and service restarts required for rule updates caused by heterogeneous system log formats and dynamically changing parameters, this application's embodiment proposes a structured system log matching method in step S204 based on variable standardization and three-stage similarity verification. This step does not rely on full-text regular expression scanning in traditional methods. Traditional full-text regular expression scanning consumes a huge amount of CPU resources when dealing with tens of thousands of concurrent logs per second, and modifying matching rules usually requires a service restart, leading to monitoring interruptions. Step S204, by removing dynamic parameters, constructing a standardized log skeleton, and combining a template library for hierarchical similarity calculation, achieves efficient, accurate, and hot-updated matching of massive heterogeneous system logs, thereby providing structured and semantic input data for subsequent anomaly detection and root cause analysis.

[0058] In the technical solution provided in step S204, there are multiple ways to perform standardization and template matching on multiple system logs to obtain the system log processing result. For example, the dynamic parameters in the multiple system logs are replaced with preset placeholders to obtain multiple standardized system logs. Here, dynamic parameters refer to parameters whose values ​​are not fixed in different system logs. The multiple standardized system logs are matched with multiple templates in the template library to obtain the target templates corresponding to the multiple standardized system logs. The set consisting of the multiple standardized system logs and the target templates corresponding to the multiple standardized system logs is determined as the system log processing result.

[0059] In some embodiments of this application, dynamic parameters refer to parameters whose values ​​are not fixed in different system logs, including but not limited to IP addresses, port numbers, and numeric error codes. Preset placeholders refer to preset fixed string identifiers used to replace dynamically changing parameters in the original logs during system log standardization processing; their form is... <var>This identifier is a pre-defined, semantically neutral string identifier that carries no semantic information. It serves solely as a general symbol for structured template matching, eliminating format differences in system logs caused by non-fixed parameters such as values, addresses, and timestamps. By stripping away these dynamically changing values ​​from the system logs, the unchanging plain text portion—the log's structural skeleton—is extracted, eliminating the interference caused by numerical differences in these parameters on template matching. Specifically, through streaming log matching accelerated by a trie-based prefix tree, for each system log entry in a multi-login set, the field values ​​of all dynamic parameters included in the pre-defined dynamic parameter list are replaced with pre-defined placeholders. <var>This ultimately yielded multiple standardized system logs.

[0060] In some embodiments of this application, there are multiple ways to perform similarity matching between multiple standardized system logs and multiple templates in a template library to obtain target templates corresponding to each of the multiple standardized system logs. For example, taking any one of the multiple standardized system logs as an example, the process of similarity matching is described as follows: A first type of template is determined from multiple templates in the template library, wherein the first type of template is a template whose length difference between the lexical sequence and the lexical sequence of the first system log is less than a first preset threshold, and the first system log is any one of the multiple standardized system logs; the edit distances between multiple templates in the first type of templates and the first system log are determined respectively to obtain multiple edit distances, wherein the edit distance of the first template is the minimum number of operation steps required to convert the lexical sequence of the first system log into the lexical sequence of the first template, and the first template is any one of the first type of templates; the multiple edit distances are converted into multiple similarity percentages, and the first type of templates with a similarity percentage greater than a second preset threshold are determined as candidate templates; the target words defined in the template content of the candidate templates are obtained, and the candidate templates whose target words all exist in the first system log are determined as the target templates corresponding to the first system log.

[0061] It should be noted that the operation and maintenance system used to execute steps S202-S212 maintains a pre-built template library in memory. The template library is a structured collection of templates in JSON or YAML format, containing no fewer than 1000 system-level error templates. Each template defines a specific error characteristic (a specific system error behavior pattern and the specific underlying error) and contextual meaning. Each template in the library mainly contains the following fields:

[0062] template_id (template unique identifier): A globally unique identifier for a template, used for precise referencing, version management, and log tracking within the system. The format is a fixed prefix + a combination of numbers and letters.

[0063] pattern (template matching skeleton): A standard string containing preset placeholders. This field is the standardized text structure skeleton of the template, consisting of fixed semantic terms and one or more placeholders. <var>A general log structure used to describe a specific type of system error. Composition rules: All dynamic parameters (e.g., IP address, port number) are replaced with... <var>It preserves fixed text, punctuation, and grammatical structure; tokens are arranged in the original log order, with spaces and punctuation preserved to ensure the integrity of the semantic skeleton; it does not contain any variable names, type descriptions, or regular expression syntax.

[0064] Keywords (core keywords): Template-specific strong characteristic words (referring to unique and irreplaceable words in the corresponding error type of the template), such as connection timeout and connection failed.

[0065] system_type (system to which it belongs): This field is used to identify the system component or service module to which the template belongs, and is used for fault classification, topology association and alarm aggregation.

[0066] error_level: This field identifies the severity level of the error represented by the template, providing a priority basis for system anomaly convergence and alarm triggering strategies. Examples include "FATAL (fatal error, causing service unavailability or account fund abnormalities)," "ERROR (critical error, affecting some business functions (such as signature verification failure, network timeout)," and "WARN (warning-level event, which may be a momentary fluctuation or non-critical anomaly (such as connection pool alarm, response delay))."

[0067] The following explanation uses the first system log as an example to further illustrate the process of determining the target templates corresponding to multiple standardized system logs:

[0068] The first stage, length pre-detection (fast filtering), identifies the first type of template from multiple templates in the template library:

[0069] The first system log is segmented into tokens based on spaces and punctuation marks, resulting in a token sequence denoted as T_tokens = [t1, t2, ... t]. k ], where k is the total number of terms in the first system log (including terms t1 to t2). k ).

[0070] For each template in the template library, the following operation is performed: the template is segmented into tokens based on spaces and punctuation marks, resulting in a token sequence for each template. Templates whose length difference between their token sequence and the token sequence of the first system log is less than a first preset threshold (e.g., 3) are identified as first-class templates. The length difference between the token sequence of any template and the token sequence of the first system log is the absolute value of the difference between the total number of tokens in the template's token sequence and the total number of tokens k in the first system log's token sequence. If the length difference exceeds the first preset threshold, the template is directly determined to be mismatched, and the calculation is terminated early. By filtering out first-class templates from the template library through this process, the computational power consumption of subsequent calculations is significantly reduced.

[0071] The second stage involves determining all candidate templates from the first type of templates through dynamic programming edit distance calculation. This involves determining the edit distance between multiple templates in the first type of templates and the first system log. For these multiple templates, the edit distance refers to the minimum number of operation steps required to transform the token sequence of the first system log into the token sequence of the first template. This process can be understood as follows: Construct a two-dimensional state matrix, where the rows represent each token in the token sequence of the first system log, and the columns represent each token in the token sequence of the first template. Starting from the first element in the upper left corner of the two-dimensional state matrix, calculate the minimum number of operation steps required to transform the token sequence of the first system log into the token sequence of the first template (operations include adding a token, deleting a token, or replacing a token) row by row and column by column. The value obtained when progressing to the lower right corner (the last element) of the matrix is ​​the edit distance of the first template.

[0072] After calculating the edit distances between multiple templates in the first category and the first system log using the above method, the edit distances of each template in the first category are processed into multiple similarity percentages. Templates in the first category with a similarity percentage greater than a second preset threshold (e.g., 85%) are identified as candidate templates.

[0073] To prevent misjudgments due to similar but semantically completely different statements (e.g., "connection successful" and "connection failed" with very close edit distances), a third-stage keyword coverage verification (precise verification) is performed to determine the target template corresponding to the first system log:

[0074] For each candidate template, the target word set defined in its keywords field (i.e., the pre-defined strong feature words in the template) is obtained. Each target word in the template's keywords set is traversed, and it is determined whether the target word exists as a continuous substring in the original text of the first system log (case-insensitive, ignoring whitespace differences). If all target words in the target word set exist in the first system log, the candidate template is confirmed as the final target template for the first system log. If any target word is missing, the candidate template is excluded and not included in the matching result. This step further extracts the keywords (core keywords) defined in the template content and verifies whether all of these keywords exist in the current standardized log (first system log). Only when 100% keyword coverage is achieved is the match considered final, ensuring the accuracy of template matching.

[0075] In traditional regular expression matching, the time complexity is O(n log n). ( (where m is the log length), and it is extremely easy to cause catastrophic backtracking. Through the above three-stage matching, let the number of tokens in the first system log be m and the number of template tokens be k, the time complexity of a single matching is stably reduced to O(m × k). Combined with the least recently used cache (MD5 LRU) technology based on MD5 hash, the MD5 hash value of the word sequence of the successfully matched structural skeleton (i.e., the standardized system log) is generated as the cache key, and the corresponding target template is cached as the value. If the standardized system log appears again, the historical matching result is directly returned from the LRU cache to obtain the corresponding target template. The matching time is reduced from an average of 15ms to <1ms, and the matching complexity of subsequent high-frequency hot logs is further reduced to O(1). This cache adopts the least recently used (LRU) eviction policy, which automatically removes entries that have not been accessed for a long time when memory capacity is limited, ensuring the balance between cache hit rate and system resource usage. The above method is used to perform template matching on all standardized system logs to obtain target templates corresponding to multiple standardized system logs. Finally, this step outputs multiple standardized system logs and their respective precisely matched template objects (target templates).

[0076] Taking a university with 67,000 students and faculty and 1,000 POS terminals as an example, during the lunch rush, the concurrent log generation rate of the campus card system (soft gateway, front-end server, database, etc.) reaches 10,000 records per second. If using the traditional ELK technology stack (ELK is an open-source technology stack widely used for distributed system log collection, storage, analysis, and visualization), a cluster of at least 3-5 high-spec servers would be required for log parsing (with CPU utilization consistently >80%). Using the solution described in this application, only one ordinary 4-core 8GB server is needed to handle peak traffic, reducing peak CPU utilization to below 15% and log processing latency from seconds to less than 5 milliseconds. In terms of hardware procurement and power consumption for the log processing cluster alone, this can save the university 75% of its infrastructure costs.

[0077] In some embodiments of this application, to ensure that the operation and maintenance system used for transaction system operation and maintenance does not interrupt monitoring services due to template rule changes in continuous high-concurrency log processing scenarios, embodiments of this application support a seamless hot update mechanism for the template library:

[0078] When operations and maintenance personnel add or modify templates through external configuration files (e.g., adding a template definition for a new type of system error), the file system monitoring mechanism detects changes to the template configuration file (e.g., YAML or JSON format). Upon detecting an update to the file content, a template reloading process is initiated: under the protection of a Reentrant Read-Write Lock (RLock), an update operation is performed on the template library in memory. This locking mechanism allows multiple concurrent read threads to access the old version of the template library simultaneously for log matching queries during the update, while write threads only perform the loading of the new template, structure parsing, and dynamic reconstruction of the trie nodes after acquiring the write lock. After the update is complete, the template library in memory is switched to the new version. The entire switching process takes less than 200 milliseconds and is completely transparent to the upper-layer log processing module, ensuring uninterrupted monitoring even under high-concurrency read conditions.

[0079] In related technologies, due to the out-of-order concurrency of business logs and the lack of cross-component session association mechanisms, it is impossible to accurately identify specific damaged business types from massive isolated business logs. Traditional monitoring solutions can only perform keyword matching on single business logs and cannot identify the complete transaction process completed collaboratively by multiple system components. For example, they cannot distinguish between fine-grained business anomalies such as "aggregated QR code payment failure" and "NFC online transaction failure." As a result, when faced with a large number of payment failure alarms, maintenance personnel still need to manually check terminal transaction records one by one, resulting in low efficiency and a high misjudgment rate. To solve the above problems and accurately reconstruct the complete lifecycle of each transaction from massive out-of-order and concurrent business logs, and identify its corresponding business type and anomaly semantics, this application constructs a transaction state machine model with the terminal number as the isolation key through execution step S206. Combined with transaction code sequence extraction, business type matching, and error code standardization filtering mechanisms, it outputs structured business log processing results. This result is directly used to indicate the type distribution of transactions executed by each terminal in the target monitoring area, providing accurate business dimension context support for subsequent anomaly convergence and root cause localization.

[0080] In the technical solution provided in step S206, there are multiple ways to restore the transaction status based on multiple business logs and obtain the business log processing results. For example: using the terminal number as the isolation key, session interception is performed on multiple business logs to obtain multiple transaction sessions, where each transaction session reflects the complete lifecycle of a transaction on a terminal; from the multiple transaction sessions, transaction code sequences are extracted to obtain multiple transaction code sequences, each consisting of multiple transaction operation codes arranged in chronological order, with each transaction code sequence corresponding to one of the multiple transaction sessions; business type matching is performed on the multiple transaction code sequences to obtain the business types corresponding to the multiple transaction sessions; error codes associated with the multiple transaction sessions are extracted, and the error codes associated with the multiple transaction sessions are translated using a preset error code translation table. The initial error business information sets corresponding to multiple transaction sessions are obtained by converting the information into standardized Chinese descriptions. A preset error code translation table stores the standardized Chinese meanings of various error codes. The initial error business information sets corresponding to multiple transaction sessions are then filtered in the following way to obtain target error business information sets corresponding to multiple transaction sessions: The target standardized Chinese descriptions are filtered from the initial error business information set corresponding to the first transaction session to obtain the target error business information set corresponding to the first transaction session. Here, the first transaction session can be any one of the multiple transaction sessions, and the target standardized Chinese description is the standardized Chinese description mapped to the normal business rejection code under the business type corresponding to the first transaction session. The business types corresponding to multiple transaction sessions and the target error business information sets are then combined to determine the business log processing result.

[0081] In some embodiments of this application, the process of extracting multiple transaction sessions from multiple business logs using the terminal number as the isolation key is as follows: All business logs are grouped by terminal number to form several log sequences; each log sequence is sorted in ascending order by timestamp to ensure the business logs are ordered in the time dimension; in the sorted log sequences, boundary logs marked with preset identifiers ({START} and {END}) are identified. Here, {START} indicates the start node of a transaction, and {END} indicates the end node of a transaction. The content of the business logs between the two markers (including both ends) is extracted according to the closed interval from {START} to {END} to form a transaction session. A transaction session is obtained by extracting multiple business logs by timestamp and preset identifiers. A transaction session completely reflects the lifecycle of a transaction on a terminal. During the session extraction process, if {END} is not identified after {START} for more than 30 seconds, the session is forcibly closed, and the relevant cache is cleared to prevent memory leaks.

[0082] Traditional monitoring can only alert on isolated error logs and cannot distinguish specific business scenarios. This application achieves white-box management of the business chain by constructing a transaction code combination state machine based on {START} / {END} markers. This precise identification of business impairment instantly narrows the scope of operation and maintenance investigation by 90%, avoiding blind investigation of internal databases or front-end machines.

[0083] After completing the above transaction session capture, for each transaction session corresponding to each terminal (one terminal can correspond to multiple transaction sessions), perform the following operations to extract the transaction code sequence:

[0084] From the business log content contained within a transaction session, the transaction opcode field is extracted to obtain a unique transaction code sequence for each session. The transaction opcode is a predefined numeric identifier with clear business semantics. The extraction rule is as follows: all extracted transaction opcodes are concatenated sequentially according to the chronological order of the business logs within the transaction session to form a continuous transaction code sequence. This sequence fully reflects the execution path of the transaction across various components. Only one transaction code sequence is generated for each transaction session, uniquely corresponding to the execution trajectory of a complete transaction carried by that session, thus ensuring the accuracy of business type matching and the completeness of state machine reasoning.

[0085] To achieve accurate identification of the business type carried by the intercepted transaction session, a pattern matching mechanism based on transaction opcode sequences is adopted. Different types of transactions (such as aggregated QR code payments, physical card online transactions, and NFC offline transactions) follow a fixed and reproducible opcode call sequence across various system components. If only a single error code or isolated log is relied upon to determine the business type, it will be impossible to distinguish between semantically similar but fundamentally different scenarios such as "payment successful" and "payment failed and retried," or "aggregated payment" and "single card payment." Therefore, semantic-level inference based on the ordered combination pattern of opcodes is necessary to achieve white-boxing of transaction types. In some embodiments of this application, business type matching is performed on multiple transaction code sequences to obtain business types corresponding to multiple transaction sessions, including: extracting transaction operation code combinations contained in multiple transaction code sequences to obtain multiple transaction operation code combinations, wherein each transaction code sequence in the multiple transaction code sequences corresponds to one transaction operation code combination in the multiple transaction operation code combinations; for the multiple transaction operation code combinations, business type matching is performed through a business type rule base to obtain business types corresponding to multiple transaction sessions, wherein the business type rule base contains multiple predefined mapping relationships between transaction operation code combinations and corresponding business types.

[0086] Specifically, a sliding window subsequence extraction is performed on the unique transaction code sequence generated for each transaction session (as mentioned earlier, this sequence consists of opcodes arranged in chronological order) to generate all possible consecutive opcode combinations in the sequence. For example, for the transaction code sequence [68, 62, 71, 31], all the following consecutive subsequences will be extracted as candidate combinations:

[68] , [68, 62], [68, 62, 71], [68, 62, 71, 31],

[62] , [62, 71], [62, 71, 31],

[71] , [71, 31],

[31] .

[0087] Subsequently, each extracted transaction operation code combination is matched against a pre-defined business type rule base. This rule base is structured configuration data, containing multiple predefined mapping relationships between transaction operation code combinations and corresponding business types. Each mapping relationship can serve as a mapping rule, possessing a unique rule ID, with the operation code combination as the key and the standardized business type as the value. For example, [68, 62] maps to the business type "130POS aggregated QR code transaction", and [31, 59] maps to the business type "card online transaction".

[0088] The matching process follows the principle of prioritizing long combinations and precise matching: Candidate combinations are first sorted in descending order of opcode combination length, with priority given to matching the longest subsequence. For example, if both [68, 62] and [68, 62, 71] exist in the rule base, the latter is matched first. Only when the longest combination is not matched are shorter combinations matched sequentially; if multiple combinations have the same length, the matching order is determined by the priority defined in the rule base. Upon successful matching, the matched business type is identified as the business type corresponding to the transaction session to which the corresponding transaction code sequence belongs, and the rule ID used by the rule base for matching the business type is recorded for subsequent auditing and rule tracing. If no combination matches the rule base, the business type is marked as unknown and logged for rule base optimization.

[0089] After capturing the transaction session, the error code fields generated by all participating components (including the soft gateway, front-end server, TSM, Oracle database, etc.) during the session's lifecycle are extracted from the raw logs of each transaction session. A pre-configured error code translation table is loaded, converting the error codes associated with multiple transaction sessions into standardized Chinese descriptions, resulting in initial error business information sets corresponding to each transaction session. The pre-configured error code translation table stores standardized Chinese meanings for various error codes. To eliminate interference from normal business rejection behavior on fault diagnosis (such as normal payment rejection during peak periods), dynamic filtering based on business type is performed on the initial error business information set of each transaction session. This filters the target standardized Chinese descriptions in the initial error business information set, generating a target error business information set. The target standardized Chinese description is the standardized Chinese description mapped to the normal business rejection code under the business type corresponding to the first transaction session (e.g., insufficient balance). A normal business rejection code refers to a standardized response code that, under a specific transaction business type, is triggered by the user's account status, fund balance, pre-configured business rules, or cardholder's proactive behavior, and is legally used to reject the transaction based on business logic. These types of rejection codes do not reflect system failures, network anomalies, or service unavailability; they are expected and normal business behavior that does not require maintenance intervention.

[0090] In the technical solution provided in step S208, there are multiple ways to determine multiple target abnormal events based on the system log processing results and business log processing results. For example: determining the matching frequency corresponding to multiple target templates based on the system log processing results, wherein the matching frequency of the first target template is the total number of standardized system logs that simultaneously match the first target template, and the first target template is any one of the multiple target templates; generating a system-level abnormal event for each target template whose matching frequency is greater than the corresponding first threshold, wherein the first threshold is the system-level abnormal event triggering threshold; determining the business type whose transaction result is failed in the business log processing results as the target business type; determining the frequency of the target business type appearing in the business log processing results as the failure frequency; generating a business-level abnormal event for each target business type whose failure frequency is greater than the corresponding second threshold, wherein the second threshold is the business-level abnormal event triggering threshold; and determining the set of all generated system-level abnormal events and all business-level abnormal events as multiple target abnormal events.

[0091] When generating system-level exception events based on system log processing results, the matching frequency of any target template is equal to the total number of standardized system logs that simultaneously match that target template. Matching is performed based on the template ID of the target template corresponding to the standardized system log. For example, if 5 standardized system logs in the system log processing results correspond to the template ID of the first target template, then the matching frequency of the first target template is 5.

[0092] After obtaining the matching frequencies corresponding to multiple target templates, for each target template, it is determined whether its matching frequency is greater than or equal to its corresponding first threshold. If so, a system-level abnormal event is generated. This system-level abnormal event contains at least the following information: the matched target template ID (template_id); the matching frequency; the trigger timestamp; the associated system component (from the system_type field); and the error level (from the error_level field). Finally, all target templates that meet the conditions are transformed into independent system-level abnormal events, forming a system-level abnormal event set, providing infrastructure-level fault signals for subsequent root cause analysis.

[0093] To avoid false alarms or missed alarms caused by static thresholds during business surges, the aforementioned first threshold is a system-level abnormal event trigger threshold. This threshold is not a simple static threshold. The first threshold corresponding to any one of the multiple target templates is determined as follows: Multiple initial first thresholds are determined for the first target template, where each initial first threshold corresponds to a time period. These initial first thresholds are determined based on the first abnormal event data within historical time periods. The first abnormal event data consists of all system-level abnormal events corresponding to the first target template generated within the historical time period. A first target time period that generates multiple system logs is determined, and the initial first threshold corresponding to the first target time period is set as the first threshold corresponding to the first target template. The following uses the first target template as an example to further explain the process of determining the first threshold corresponding to this target template:

[0094] This application abandons static thresholds and adopts an adaptive threshold mechanism based on spatiotemporal binning to spatiotemporally bin system-level abnormal events (first historical abnormal events) of the first target template generated within a historical time period (e.g., the past three months). This mechanism automatically raises the threshold to filter noise during peak periods (e.g., peak dining times in a smart card system) and automatically lowers the threshold to ensure sensitivity during off-peak periods. Specifically, all historical first abnormal events are binned according to the dimension of (system error template ID (here, the template ID of the first target template), hour (time of day), day of week (day of week)) to obtain multiple spatiotemporal bins. Each spatiotemporal bin represents a unique time period (hour of day of week, e.g., Wednesday noon), containing all system-level abnormal events of the first target template generated within that historical time period. The following operations are performed on each spatiotemporal bin to obtain a dynamic trigger threshold for each spatiotemporal bin. This dynamic trigger threshold is an initial first threshold, and the dynamic trigger thresholds of all spatiotemporal bins constitute multiple initial first thresholds:

[0095] For each spatiotemporal bucket, calculate μ(1) and σ(1). μ(1) is the average value, representing the average frequency of system-level abnormal events occurring in the first target template within the corresponding spatiotemporal bucket. σ(1) represents the standard deviation, reflecting the degree of fluctuation and dispersion in the frequency of occurrence within that period. μ(1) + 3σ(1) is used as the dynamic trigger threshold (i.e., the initial first threshold) for determining whether the event concurrency of the current spatiotemporal bucket belongs to a sudden anomaly.

[0096] Therefore, for each target template, multiple initial first thresholds can be generated. Each initial first threshold corresponds to a unique (hour, week) combination, which is used to characterize the upper limit of normal fluctuation of the target template within that time period.

[0097] Based on the timestamps of the system logs, determine the first target time period that generates multiple system logs, and set the initial first threshold corresponding to the first target time period as the first threshold corresponding to the first target template.

[0098] In step S206, the system has completed the transaction session restoration of the business log and output the business type and target error business information set (i.e., the set of exception descriptions after filtering out normal rejection codes) corresponding to each transaction code sequence. When generating business-level exception events based on the business log processing results, the business types with failed transaction results in the business log processing results are first determined as the target business types, excluding normal transactions. As an optional implementation method, the business types with failed transaction results can be determined in the following way: if the target error business information set corresponding to a certain transaction code sequence is not empty (i.e., it contains abnormal error descriptions such as "network timeout" or "database connection failure"), then the transaction result of the business type corresponding to that transaction code sequence is judged as a failed transaction, and its business type is marked as the target business type.

[0099] Next, to accurately detect abnormal development trends at the business layer, frequency statistics will be performed on all target business types: For each target business type in the business log processing results, the frequency of its appearance in the business log processing results will be determined as the failure frequency. For each target business type, it will be determined whether its failure frequency is greater than or equal to its corresponding second threshold.

[0100] If the conditions are met, a business-level exception event is generated. This event includes the following information: target business type name; failure frequency; trigger timestamp; physical area involved (e.g., "East District Cafeteria" or "North Gate," which can be obtained by mapping from the terminal number); and associated error description (extracted from the target error business information set for auxiliary analysis). All target business types that meet the conditions generate corresponding business-level exception events, ultimately forming a business-level exception event set.

[0101] Similar to the first threshold, the second threshold is a business-level abnormal event trigger threshold. It is not a static threshold, but an adaptive threshold dynamically calculated based on historical abnormal behavior. The second threshold corresponding to any target business type (denoted as the first target business type) is determined as follows: Multiple initial second thresholds corresponding to the first target business type are obtained. The first target business type is any one of all target business types with failed transactions. Each initial second threshold corresponds to a time period. These initial second thresholds are determined based on second abnormal event data within historical time periods. The second abnormal event data consists of all business-level abnormal events corresponding to the first target business type generated within those historical time periods. The second target time period that generates multiple business logs is determined, and the initial second threshold corresponding to the second target time period is set as the second threshold corresponding to the first target business type. The following uses the first target business type as an example to further explain the process of determining the second threshold corresponding to the first target business type:

[0102] An adaptive threshold mechanism based on spatiotemporal bucketing is used to spatiotemporally bucket all business-level anomalous events (historical second anomalous events) corresponding to the first target business type generated within a historical time period (e.g., the past three months). Specifically, all historical second anomalous events are bucketed according to the dimensions of (abnormal business type, standardized rejection description, hour, weekday) to obtain multiple spatiotemporal buckets. Each spatiotemporal bucket represents a unique time period (the hour of a day of the week, e.g., Wednesday at 12 noon), containing all business-level anomalous events corresponding to the first target business type generated within that historical time period. The following operations are performed on each spatiotemporal bucket to obtain a dynamic trigger threshold for each bucket. This dynamic trigger threshold is an initial second threshold, and the dynamic trigger thresholds for all spatiotemporal buckets constitute multiple initial second thresholds:

[0103] For each business-level anomaly bucket, calculate μ(2) and σ(2). μ(2) is the average value, representing the average frequency of business-level anomalies corresponding to the first target business type within the corresponding bucket. σ(2) represents the standard deviation, reflecting the degree of fluctuation and dispersion in the frequency of occurrence within that period. μ(2) + 3σ(2) is used as the dynamic trigger threshold (i.e., the initial second threshold) for determining whether the event concurrency of the current bucket belongs to a sudden anomaly.

[0104] Therefore, for each target business type, multiple initial second thresholds can be generated, each initial second threshold corresponding to a unique (hour, week) combination, used to characterize the normal fluctuation limit of the target business type within that time period.

[0105] Based on the generation timestamp of the business logs, a second target time period for generating multiple business logs is determined, and the initial second threshold corresponding to the second target time period is set as the second threshold corresponding to the first target business type.

[0106] By executing step S208, a dual-dimensional anomaly detection mechanism integrating the system layer and the business layer is integrated. The raw, massive, out-of-order, and low-semantic log data is transformed into a structured, high-value, and traceable set of system-level and business-level anomaly events. This effectively solves the core problems of frequent alarm storms, high false alarm rates, and unclear root causes in traditional monitoring. System-level events accurately locate underlying infrastructure failures, while business-level events accurately map the types of damage to upper-layer services.

[0107] In the technical solution provided in step S210, there are several ways to merge multiple target abnormal events to obtain initial alarm information. For example, multiple target abnormal events acquired within a target time window (e.g., a window duration of 5 seconds) are merged after time alignment according to timestamps to obtain an abnormal event set; multi-dimensional features corresponding to the abnormal event set are extracted, including error code set, system set, physical region set, and abnormal business type set; a target hash key is generated based on the multi-dimensional features; if the count of the target hash key in the database is 0 within a preset time period, the multi-dimensional features corresponding to the abnormal event set are determined as the initial alarm information. Step S210 is further explained below.

[0108] Understandably, when system-level or business-level exceptions are triggered, they are not immediately pushed to downstream independently. Instead, they are sent to a 5-second merging buffer window (target time window). Within this time window, the operations and maintenance system will correlate exceptions of different dimensions that surge within the same time period. For example, the surge in "business-level exceptions: aggregated QR code transaction failure" at the front end and the surge in "system-level exceptions: soft gateway -200 error" and "database ORA-12170 error" at the lower level will be packaged and merged into a joint exception context from a global cascading perspective (i.e., the aforementioned set of exception events).

[0109] After obtaining the set of abnormal events, the following four types of multi-dimensional features are extracted from it: Error Code Set: Contains the target template ID and underlying error code matched in all system-level abnormal events; Involved System Set: Contains the system components associated with all system-level abnormal events; Involved Physical Region: Contains the physical regions associated with all business-level abnormal events (derived from terminal number mapping, such as "cafeteria"); if there are no business-level events, this field is empty; Abnormal Business Type Set: Contains the target business type identified in all business-level abnormal events (such as "130POS aggregated QR code transaction failure" and "NFC connection failure"). All four types of features are stored in set form to ensure no duplicate elements. This feature vector fully characterizes the error types, affected systems, physical scope, and damaged services covered by the abnormal event set, forming a high-dimensional, structured alarm feature description.

[0110] Subsequently, the four feature sets mentioned above are concatenated into strings according to (the set of business exception types included, the set of system error codes included, the set of system nodes involved, and the set of physical areas / canteens involved) to form a unified structured feature string. A secure hash algorithm (e.g., SHA1 hash algorithm) is then applied to this string to generate a unique, deterministic, and fixed-length target hash key. This target hash key serves as the unique identifier for this alarm event and is used for subsequent deduplication. The generation process is a deterministic algorithm, and the same feature set always generates the same hash value.

[0111] Finally, based on the historical count of the target hash key within a preset time period (e.g., 5 minutes), it is determined whether to generate an initial alarm message:

[0112] The operations and maintenance system maintains a local database table that records the recurrence count (recurrence_count) of each target hash key within the most recent preset time period. If the currently generated target hash key does not exist in the database, or its count value is 0, it is determined that the group of abnormal characteristics has appeared for the first time. Step S212 is executed directly, and the target hash key is added to the database, and its recurrence_count is initialized to 1. If the target hash key already exists and recurrence_count > 0, no initial alarm information is generated. Only recurrence_count += 1 is executed, and the call request to the alarm agent and the alarm push are directly intercepted, realizing alarm convergence at the physical level.

[0113] By executing step S210, initial alarm information is generated only when a specific cascading failure mode occurs for the first time; for repeated occurrences of system errors and business anomalies in the same area and the same group (such as two consecutive "Canteen: Soft Gateway-200+ Aggregated QR Code Failure"), the count is incremented only in the database, thus completely blocking alarm storms and wasted computing power from the architectural level.

[0114] In the technical solution provided in step S212, there are multiple ways to obtain an alarm report for transaction system operation and maintenance by performing fault analysis on the initial alarm information through an alarm intelligence agent. For example, when the initial alarm information is found to hit the target information, the alarm intelligence agent is driven to perform multiple rounds of fault reasoning analysis on the initial alarm information through prompt words to obtain a preliminary alarm report. Each round of fault reasoning analysis in the multiple rounds of fault reasoning analysis includes anomaly characterization, root cause location, business assessment, and processing measure generation. The target information is at least one of the following: a preset anomaly class name, a preset component identifier; the accuracy of the preliminary alarm report is verified to obtain the accuracy verification result, and if the accuracy verification result is passed, the preliminary alarm report is determined as an alarm report for transaction system operation and maintenance.

[0115] In the technical solution provided in step S212, the alarm agent refers to an automated diagnostic agent system driven by a large language model (LLM), possessing tool invocation capabilities, and constrained by structured strategies. Its design goal is to: upon receiving high-dimensional structured alarm information (initial alarm information), dynamically invoke pre-registered diagnostic tools through a multi-round reasoning-action loop (ReAct), perform anomaly characterization, root cause localization, business assessment, and generate handling measures, and output a reliable, executable, and traceable operation and maintenance diagnostic report (initial alarm report) under the dual constraints of a self-evaluation mechanism and a closed-loop verification mechanism.

[0116] The target information mentioned above includes at least one of the following: a preset exception class name and a preset component identifier. The preset exception class name refers to a standard naming string predefined and stored in the local knowledge base by operations and maintenance personnel during system operation, describing a specific software exception type. Its source is the fully qualified name of the exception class in common programming languages ​​(such as Java), or it consists of error pattern text that frequently appears in system logs and has clear semantics. The preset exception class names include, but are not limited to, specific stack traces for more than 40 patterns such as java.sql.SQLException and HikariPool. The preset component identifier refers to a standardized name or code pre-configured and entered into the knowledge base by operations and maintenance personnel in the system architecture, used to uniquely identify key software and hardware components within the transaction system. It originates from node names or service names in the system topology map and is used to constrain the reasoning scope of the model during the diagnostic process, avoiding misjudgments of irrelevant components.

[0117] The aforementioned prompt-guided approach can be understood as follows: upon recognizing that the initial alarm information matches the target information, a system prompt is dynamically injected into the alarm agent. This system prompt contains expert diagnostic instructions, which guide the alarm agent to switch to the corresponding domain's diagnostic logic. This forces the alarm agent to perform fault reasoning analysis according to the standard steps of anomaly characterization, root cause localization, business assessment, and processing measure generation. For example, if the target information is a Java exception class, the system prompt would contain Java expert instructions. This mechanism binds the dialogue capabilities of a general language model to vertical domain expertise, ensuring that the diagnostic behavior is domain-specific and operationally instructive.

[0118] Each round of fault reasoning analysis includes anomaly characterization, root cause localization, business assessment, and handling measure generation. In the anomaly characterization alarm agent, during each round of reasoning, based on the error code set, abnormal business type set, and system component set in the initial alarm information, a structured summary and classification of the nature, type, and scope of impact of the current fault. The output is in a standardized sentence format, such as: "This fault is a payment timeout type business anomaly, the related business is '130POS aggregated QR code transaction,' and the affected area is 'East District Cafeteria.'" This step transforms ambiguous system errors into categorizable, searchable, and comparable semantic tags, giving subsequent reasoning a clear direction. Essentially, it transforms log fragments into standard fault categories within the operational knowledge system, supporting root cause localization.

[0119] Root cause localization refers to the process by which an alarm agent, based on the qualitative analysis of anomalies, uses registered diagnostic tools to collect information according to a comprehensive approach, gradually narrowing down the scope of the fault source, and ultimately identifying the most fundamental and direct cause of the anomaly. The process of root cause localization using the comprehensive approach is as follows:

[0120] First, call the millisecond-level global inspection snapshot to locate abnormal devices: obtain an overview of the health status of all relevant system components (such as CPU, memory, number of connections) and identify abnormal devices (system components or terminals that have failed).

[0121] Next, a single-machine time-series trend analysis is performed to analyze whether the abnormal indicators of the abnormal equipment in the first 5 minutes are sudden spikes or sustained high levels.

[0122] If neither of the above two methods can locate the root cause of the failure, the final step is to log in to the target server by calling a system-level remote access tool (Secure Shell (SSH) or Windows Remote Management (WinRM)) to execute low-level commands to obtain real-time, fine-grained, high-privilege running status information, and to verify or eliminate deep-seated system-level faults.

[0123] Business assessment refers to the process by which the alerting agent, after completing the anomaly identification and root cause localization, makes a structured, quantifiable, and business-semantic comprehensive judgment based on the direct impact of the current fault on the core business functions of the trading system, its duration, its relevance to fund security, and the degree of user service interruption. Its purpose is to transform system anomalies into business risk levels and priorities that operations and maintenance personnel can understand, ensuring that handling recommendations are business-oriented and compliant.

[0124] The generation of handling measures refers to the process by which the alarm agent automatically generates one or a set of operation and maintenance handling suggestions that can be directly executed, comply with safety specifications, and have operational steps after confirming the root cause.

[0125] In some embodiments of this application, there are various ways to drive the alarm agent to perform multiple rounds of fault reasoning analysis on the initial alarm information and obtain a preliminary alarm report by guiding it with prompt words. For example, the following steps 1-3 are iteratively executed until a stopping condition is reached, after which the iteration stops. The alarm agent analyzes the initial alarm information after the iteration stops and generates a preliminary alarm report. The stopping condition is that the iteration rounds reach a preset maximum round or a target preset round. The response information of the alarm agent indicates the termination of the iteration process. The initial iteration round is 0, the target preset round is less than the preset maximum round, and the response... The response information is the alarm agent's response to the verification prompt word input into the alarm agent. The verification prompt word is used to guide the alarm agent to evaluate the fault reasoning and analysis process: Step 1: Under the guidance of the target prompt word, the alarm agent is driven to call various fault diagnosis tools to perform anomaly identification, root cause location, business assessment, and handling measure generation on the initial alarm information, obtaining target analysis information. The target analysis information includes all information generated during the anomaly identification, root cause location, business assessment, and handling measure generation process; Step 2: The target analysis information is determined as the new initial alarm information; Step 3: The iteration round is incremented by 1. The iterative process of the alarm agent is further explained below.

[0126] Based on the multi-dimensional features contained in the initial alarm information (such as the set of error codes, the set of systems involved, the set of abnormal business types, and the physical area), a target prompt word is injected into the alarm agent at the beginning of each round of diagnosis. This prompt word is preset by the system based on historical diagnostic experience and business rules, and its content includes: mandatory analysis process instructions: "Please execute in the following order: 1) Anomaly identification; 2) Root cause location; 3) Business assessment; 4) Generation of handling measures"; tool call constraints: "Only registered diagnostic tools are allowed to be called"; output format requirements: "All analysis results must be structured and must not contain speculative statements."

[0127] During each iteration, guided by the target prompt, the alarm agent invokes various fault diagnosis tools to perform anomaly identification, root cause localization, business assessment, and action measure generation on the initial alarm information, resulting in target analysis information. All intermediate results generated during the anomaly identification, root cause localization, business assessment, and action measure generation processes are integrated into the target analysis information, which includes, but is not limited to: anomaly identification conclusions, root cause localization results, business assessment conclusions, action measure recommendations, tool call records, and tool return results obtained from each tool call. At the end of each iteration, the iteration count is incremented by 1, and the target analysis information obtained in that iteration is used as the initial alarm information input for the next iteration.

[0128] After each iteration, the system determines whether the current iteration has reached the target preset iteration (i.e., the 4th iteration):

[0129] If the number of iterations is less than the target preset number of iterations, then proceed directly to the next iteration and continue executing a new round of iterations.

[0130] After the target preset number of iterations is reached, starting from that preset number of iterations, after each subsequent iteration, a lightweight verification prompt is injected into the alarm agent without interfering with the iteration process. The verification prompt is used to guide the alarm agent to evaluate the fault reasoning and analysis process. The following is an example of a verification prompt: "Based solely on all currently collected tool call results and reasoning content, strictly determine whether sufficient evidence has been obtained to form a complete, accurate, and executable diagnostic report? Please output only the following standard JSON format: {'ready': true} or {'ready': false}, without any additional explanations."

[0131] The termination condition of the iteration process is one of the following: reaching the maximum preset number of rounds (8 rounds) or satisfying the self-evaluation early stop mechanism. The self-evaluation early stop mechanism is to terminate the iteration process in advance if the number of iterations has not reached the preset maximum number of rounds but the response information indicates that the iteration process should be terminated (output {'ready':true}).

[0132] The alarm agent summarizes and integrates the initial alarm information after the iteration stops (the initial alarm information is the target analysis information accumulated in all rounds), and outputs a structured preliminary alarm report according to the preset template. The report includes: fault characterization results, root cause location results, business impact assessment results, tool call summary, and self-assessment termination mark ("terminated in advance by the self-assessment mechanism in round N (N refers to the specific termination round)").

[0133] In the technical solution provided in step S212, to further improve the accuracy of the fault alarm report, the accuracy of the preliminary alarm report is verified in the following way to obtain the accuracy verification result: The alarm agent determines multiple target diagnostic tools from the preset diagnostic tool library and generates multiple verification actions to verify the accuracy of the preliminary alarm report using these target diagnostic tools; the multiple verification actions are executed using the multiple target diagnostic tools to obtain the verification action execution result; the alarm agent analyzes the verification action execution result to obtain the accuracy verification result. Here, the preset diagnostic tool library refers to a set of lightweight, read-only, and automatically invoked diagnostic functions pre-registered and fixed during the deployment of the operation and maintenance system.

[0134] In some embodiments of this application, a first verification prompt is injected into the alarm agent. This prompt is a structured instruction with a fixed format, as follows: "Based on the conclusion in the preliminary alarm report (e.g., 'The root cause is a missing Java class'), please select up to three executable, low-latency tools from the following preset diagnostic tool library and plan specific verification actions to verify whether the conclusion is valid. Each verification action must explicitly specify the tool name, input parameters, and expected output." Guided by this first verification prompt, the alarm agent generates multiple verification actions based on the preliminary alarm report to verify the accuracy of the preliminary alarm report using multiple target diagnostic tools.

[0135] After receiving the verification action plan output by the alarm agent, the operation and maintenance system automatically and without intervention calls the corresponding target diagnostic tool to execute each verification action and obtain the verification action execution result. All calls to the target diagnostic tool are triggered by the underlying system, ensuring that they do not rely on manual operation or modify the system state.

[0136] Finally, the verification action execution results and the preliminary alarm report are input into the alarm agent. The alarm agent analyzes the verification action execution results using a second verification prompt to obtain the accuracy verification result. The second verification prompt guides the alarm agent to make an objective, binary, and verifiable truth judgment on the core conclusions (anomaly identification and root cause localization) of the original report based on the newly collected verification action execution results, independently of the original report content. The accuracy verification result consists of the following two parts: Verification status: a Boolean value, taking the value true or false, indicating whether the core conclusion of the original report is supported. If the value is true, the accuracy verification result is passed; Verification reason: a factual statement used to explain the basis for the judgment. If the accuracy verification result is passed, the preliminary alarm report is designated as an alarm report for transaction system operation and maintenance. This alarm report will be pushed to the operation and maintenance personnel's client as a standard alarm. If the accuracy verification result fails, the preliminary alarm report is considered an unverified alarm and is pushed to the operation and maintenance personnel's client.

[0137] In some embodiments of this application, to achieve continuous evolution of operational knowledge, a dual knowledge system integrating physical topology maps and multimodal experience knowledge bases is constructed, and an operational feedback closed-loop mechanism is established to support the dynamic enhancement of the diagnostic capabilities of alarm agents with usage frequency.

[0138] The actual root cause and root cause remediation actions confirmed by operations and maintenance personnel are updated in the historical feedback record table. During subsequent similar fault diagnosis, when the alarm agent calls the tool to query historical feedback records, it will perform semantic similarity matching on the historical feedback records based on features such as the current alarm's error code set, involved components, business type, and physical region. If a high-confidence historical case is found (match rate ≥ 90%), the historical root cause and remediation solution will be preferentially injected as contextual clues to guide the alarm agent to directly reuse the validated solution.

[0139] An enterprise-level physical topology graph is constructed based on the Neo4j graph database. Its nodes include: system components; physical devices (e.g., server hosts, switches, load balancers); and business areas. Edge relationships represent dependencies and communication links between components. This graph is used in the subsequent fault diagnosis phase to automatically extract the Explosion Radius of abnormal events: when a component malfunctions, graph algorithms (such as breadth-first search) identify all its directly or indirectly dependent downstream components and associated physical areas, providing contextual input to the alarm agent to assist in determining the scope of fault impact and cascading paths, thus avoiding the diagnostic process from being limited to a local perspective.

[0140] By integrating structured and unstructured operation and maintenance knowledge, a unified multimodal experience knowledge base is constructed to provide theoretical support for the alarm intelligence agent. The multimodal experience knowledge base includes, but is not limited to, the following formats: JSON / YAML files: storage standardized system configuration, interface protocols, error code meaning mapping tables; Markdown documents: storage system architecture description, business process diagrams, etc.

[0141] In some embodiments of this application, the alarm compression ratio CR is calculated using the following formula:

[0142] ,in, This refers to the number of error log entries. This refers to the final number of diagnostic reports pushed out.

[0143] For example, in a cascading failure triggered by core switch jitter, the subsystems printed 15,000 error logs within 2 minutes. Ultimately, only the error logs were pushed to maintenance personnel. A comprehensive AI diagnostic report containing root causes. Alarm compression rate up to 99.99%, completely eliminating alarm fatigue for operations and maintenance personnel.

[0144] Traditional manual troubleshooting of cross-domain faults involves tedious steps such as logging into the server, checking logs, reviewing architecture diagrams, and consulting error code manuals, taking an average of 45-60 minutes. In this application, the average fault repair time is strictly controlled to within 3 minutes, improving troubleshooting efficiency by over 95%. Specifically, the average fault repair time... Calculated using the following formula:

[0145] .

[0146] in, This refers to the time required to perform step S208 above. This refers to the time required to perform the above steps S202-S206. This refers to the time required to perform the above steps S210-S212.

[0147] The method described in this application has been deployed and operated long-term in the actual production environment of a large university campus card system. Experimental and operational data show that the system operates stably without memory overflow under high-concurrency scenarios with an average daily generation of 50 million logs. Within three months of deployment, the system successfully intercepted and consolidated multiple alarm storms caused by jitter in the underlying database and core switch, accurately consolidating tens of thousands of potentially invalid alarms into 12 high-value alarm reports. The overall average fault repair time was reduced by 85% compared to the same period of the previous year, demonstrating the extremely high feasibility and commercial value of this solution.

[0148] To more intuitively demonstrate the collaborative working process and technical effects of the various innovative mechanisms in this application in a real production environment, the following provides four typical application cases from a university campus card real production environment, along with relevant comparative data.

[0149] Case 1: Early morning holiday alert (used to highlight false alarm immunity and experience-based closed-loop capability):

[0150] Phenomenon: At 00:19, the soft gateway experienced 8 323 errors within 120 seconds (323 error means that the business for the day has ended).

[0151] Regarding the phenomenon in Case 1, related technologies frequently wake up night shift workers, requiring them to log into the server to check logs, consult error code manuals, and call the database administrator to confirm whether daily settlement is in progress. This process takes 15-30 minutes and severely leads to alarm fatigue. The method described in this application takes approximately 40 seconds. The alarm agent uses a tool to query historical feedback records, achieving 100% accuracy in historical data (historical records show: the system's daily settlement changed, and the soft gateway re-signed in, which is expected behavior). When the large model (alarm agent) performs fault reasoning analysis, the evidence is deemed sufficient after the first round of tool calls, triggering "self-assessment early stop," and directly outputting the conclusion: "Time characteristics within the daily settlement window + error code meaning + historical experience hit, comprehensively judged as expected daily settlement blockage. No intervention required, no alarm pushed."

[0152] Case 2: Java Cascading Fault (used to highlight dynamic expert mode and complex root cause localization): Phenomenon: At 11:35 a.m., the mobile service platform experienced 104 NoClassDefFoundErrors (class not found) within 120 seconds.

[0153] Regarding the phenomenon in Case 2, in related technologies, frontline operations and maintenance personnel lack Java source code analysis capabilities, making them highly susceptible to misjudging "database or network failures" based on superficial symptoms, wasting 30 minutes troubleshooting in the wrong direction. This then requires escalation to second-line development, involving cross-team communication to obtain stack traces and investigate dependency conflicts, taking 1-2 hours in total. The method used in this application takes approximately 60 seconds. The system's regular expression scan identifies features such as java.lang and automatically injects "Java expert mode instructions" into the prompt words. When the alarm agent performs fault reasoning analysis, it calls a tool to query recent critical errors, confirming that only the mobile platform is experiencing errors, instantly ruling out infrastructure (DBA / network) causes. After obtaining the complete exception chain, the alarm agent accurately locates the root cause and provides handling suggestions.

[0154] Case 3: Timeout Failure of the Transaction Security Management Platform (TSM) (Used to highlight precise source tracing and mandatory injection of business rules):

[0155] Phenomenon: At 20:11 in the evening, the TSM node encountered a network timeout error during 82 calls to the external payment interface.

[0156] Regarding the phenomenon in Case 3, the operations and maintenance team found that both the network and the peer were normal after troubleshooting, leading to confusion. A senior engineer intervened and discovered the cause. Manual investigation was highly likely to overlook the security risk that "payment timeouts may lead to one-sided fund transactions." Using the method described in this application, the process took approximately 60 seconds. The alerting AI accurately detected the timeout in the logs, precisely at 1000ms or 1015ms, determining it to be a hard-coded timeout rather than network jitter. Constrained by the system prompts, the alerting AI not only suggested "adjusting the 1-second timeout to 3-5 seconds," but also forcibly output a security warning: "Payment timeouts are highly likely to result in one-sided transactions. Please immediately verify payment records and handle any dropped orders." This completely eliminates compliance risks.

[0157] Case 4: Unique constraint violation (ORA-00001, a standard error code thrown by Oracle database systems):

[0158] Phenomenon: During the evening peak hours, the soft gateway experienced an ORA-00001 error (violation of unique constraint).

[0159] Regarding the phenomenon in Case 3, related technologies require collaboration among the operations and maintenance team, database administrator, and development team. Using the method described in this application, the process takes approximately 60 seconds. After analysis, the alerting agent indicates that "the error indicates that concurrent insertions at the application layer did not perform existence checks. This is not a database-level fault."

[0160] Table 1 below illustrates the mapping relationship between the core innovative aspects of this application and the aforementioned cases:

[0161] Table 1:

[0162]

[0163] Table 2 below illustrates the improvements of the method in this application embodiment compared to traditional methods in related technologies across various operational dimensions:

[0164] Table 2

[0165]

[0166] Based on the existing operational scale of a large university's campus card center, after deploying the operational system implementing steps S202-S212 of this application, the following cost savings are achieved: Average fault handling time is reduced from 60 minutes to 2 minutes, saving approximately 3480 man-hours annually in cross-departmental collaboration and troubleshooting. Alarm quality is improved: False alarm rates are reduced from 40% to <5%; the number of invalid wake-ups for night shift workers is reduced by 93%, significantly improving the health and focus of shift personnel. Troubleshooting accuracy is enhanced: The probability of root cause location errors is reduced from 25% to <2%; the hit rate of reusing historical experience for new faults reaches 30%~50%, achieving complete assetization of operational experience.

[0167] Figure 3 This is a flowchart of another operation and maintenance method for a transaction system provided in an embodiment of this application. First, a multi-source heterogeneous log stream is acquired (corresponding to the acquisition of multi-source log data generated by the transaction system as described above). Prefix tree matching is performed using a prefix tree acceleration matching module. Logs are discarded if no template is matched; if a template is matched, core fields are extracted and persisted to obtain the system log processing result (corresponding to the standardization and template matching processing of multiple system logs described above). State machine transaction restoration is then performed to obtain the business log processing result. Next, an adaptive anomaly detector is used to determine whether an abnormal event exceeds a corresponding threshold. If not, normal monitoring continues. If a breakthrough occurs, a 5-second joint window is entered to perform multi-dimensional hash deduplication and determine if the event hits the short-term repetition threshold. If it does, the database recurrence count is incremented by 1, and the information push is intercepted. If it does not hit, the diagnostic engine is triggered (corresponding to the above-mentioned merging of multiple target abnormal events to obtain initial alarm information, and the alarm agent performs fault analysis on the initial alarm information to obtain an alarm report for transaction system operation and maintenance): it determines whether the feature hits the Java stack. If it does, a Java expert mode Prompt is injected. If it does not hit, the regular diagnostic mode is adopted. A loop diagnosis is executed, limited to a maximum of 8 rounds. During the diagnosis process, 15 hierarchical diagnostic tools (covering graphs / time series (time series trend) / snapshots, etc.) are called. From the 4th round onwards, each round self-assesses whether it is ready, and the loop can be exited. If the early assessment and early stop are met, a summary is forcibly output, and a Markdown diagnostic report is generated. The report is validated using a two-stage closed-loop validator. If the large model passes independent validation, a standard alarm is pushed (the alarm agent performs fault analysis on the initial alarm information to obtain an alarm report for transaction system operation and maintenance). Otherwise, an alarm marked with an unverified flag is pushed.

[0168] Figure 4 This is a module structure diagram provided according to an embodiment of this application, used for an operation and maintenance system executing steps S202-S212. It comprises six layers, which, in the order of data flow, are: a data acquisition layer, a data processing layer, an anomaly convergence and routing layer, an AI diagnostic engine layer, a closed-loop verification layer, and a knowledge and graph layer. The data acquisition layer collects logs; for example, the collection source can be soft gateway logs, Trusted Service Manager (TSM) / mobile service logs, or underlying database logs. The data processing layer processes and stores the logs using a prefix tree Trie matching engine, a state machine session restoration module, and an SQLite local event library, ultimately obtaining system log processing results and business log processing results. The anomaly convergence and routing layer monitors thresholds using an adaptive threshold calculator and generates anomaly events (generating a system-level anomaly event for each target template with a matching frequency greater than the corresponding first threshold; generating a business-level anomaly event for each target business type with a failure frequency greater than the corresponding second threshold). The process involves merging data through a 5-second joint window and deduplication using a multi-dimensional hash deduplication module (corresponding to merging multiple target anomalies acquired within the target time window according to timestamps to obtain an anomaly event set). The AI ​​diagnostic engine layer initiates cyclic diagnostics via the ReAct cyclic controller and verifies early exit from the loop using a self-evaluation early stop mechanism. During the loop, various diagnostic tools are scheduled through a hierarchical tool scheduler. Hint words are injected via a Java expert dynamic injector (corresponding to the fault analysis of initial alarm information by the alarm agent to obtain alarm reports for transaction system maintenance). The closed-loop verification layer performs: Stage A: verification plan generation; Stage A.5: list tool execution; Stage B: independent judgment and labeling. Finally, the verification results are stored in the Neo4j physical topology graph of the knowledge and graph layer, the multimodal knowledge base MD / JSON, and the human feedback experience base, providing context and topology for the above steps.

[0169] Figure 5 This is a schematic diagram of the structure of an operation and maintenance device for a trading system according to an embodiment of this application, including:

[0170] The acquisition module 502 is used to acquire multi-source log data, which includes at least multiple system logs and multiple business logs.

[0171] The first processing module 504 is used to perform standardization processing and template matching processing on multiple system logs to obtain system log processing results. The system log processing results include multiple standardized system logs and multiple target templates corresponding to the multiple standardized system logs. The target template is used to indicate at least one system error feature.

[0172] The transaction status restoration module 506 is used to restore the transaction status based on multiple business logs and obtain the business log processing results. The business log processing results are used to indicate the corresponding business types when multiple terminals in the target monitoring area conduct transactions.

[0173] The determination module 508 is used to determine multiple target abnormal events based on the system log processing results and the business log processing results. The target abnormal event is at least one of the following: a system-level abnormal event or a business-level abnormal event.

[0174] The second processing module 510 is used to merge multiple target abnormal events to obtain initial alarm information.

[0175] The fault analysis module 512 is used to perform fault analysis on the initial alarm information through the alarm intelligence agent and obtain an alarm report.

[0176] It should be noted that, Figure 5 The operation and maintenance equipment of the trading system shown is used to execute... Figure 2 The operation and maintenance method of the trading system shown is therefore Figure 2 The relevant explanations in the operation and maintenance methods of the trading system also apply to the operation and maintenance equipment of the trading system, and will not be repeated here.

[0177] It should be noted that the modules in the operation and maintenance device of the above-mentioned trading system can be program modules (such as a set of program instructions to implement a certain function) or hardware modules. For the latter, they can be manifested in the following forms, but are not limited to these: each of the above modules is manifested as a processor, or the functions of each of the above modules are implemented by a processor.

[0178] This application also provides a non-volatile storage medium, which includes a stored program, wherein the operation and maintenance method of the above-mentioned transaction system is controlled by the device where the non-volatile storage medium is located during program execution.

[0179] This application also provides an electronic device, which includes a processor for running a program, wherein the above-mentioned operation and maintenance method of the transaction system is executed when the program is running.

[0180] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the above-described operation and maintenance method of the transaction system.

[0181] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0182] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0183] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0184] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0185] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0186] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.< / var> < / var> < / var> < / var>

Claims

1. A method for operating and maintaining a trading system, characterized in that, include: Acquire multi-source log data generated by the transaction system, wherein the multi-source log data includes at least multiple system logs and multiple business logs, wherein the system logs are logs generated by the system components of the transaction system to record system operating status, connection anomalies or service errors, and the business logs are logs triggered by payment interaction behavior initiated by terminal devices; The multiple system logs are standardized and template matched to obtain system log processing results. The system log processing results include multiple standardized system logs and multiple target templates corresponding to the multiple standardized system logs. The target templates are used to indicate at least one system error feature. Based on the multiple business logs, the transaction status is restored to obtain the business log processing result, wherein the business log processing result is used to indicate at least the business type corresponding to the transactions of multiple terminals in the target monitoring area. Based on the system log processing results and the business log processing results, multiple target abnormal events are determined, wherein the target abnormal event is at least one of the following: system-level abnormal event, business-level abnormal event; The multiple target abnormal events are merged and processed to obtain initial alarm information; The initial alarm information is analyzed by an alarm intelligence agent to obtain an alarm report for the operation and maintenance of the transaction system.

2. The method according to claim 1, characterized in that, The system log entries are standardized and template matched to obtain the system log processing results, including: The dynamic parameters in the multiple system logs are replaced with preset placeholders to obtain the multiple standardized system logs. The dynamic parameters refer to parameters whose values ​​are not fixed in different system logs. The multiple standardized system logs are matched with multiple templates in the template library to obtain the target templates corresponding to the multiple standardized system logs respectively; The set consisting of the multiple standardized system logs and the target templates corresponding to the multiple standardized system logs is determined as the system log processing result.

3. The method according to claim 2, characterized in that, The multiple standardized system logs are matched with multiple templates in the template library to obtain the target templates corresponding to the multiple standardized system logs, including: A first type of template is determined from multiple templates in the template library, wherein the first type of template is a template whose length difference between the lexical sequence and the lexical sequence of the first system log is less than a first preset threshold, and the first system log is any one of the multiple standardized system logs; The edit distances between multiple templates in the first type of templates and the first system log are determined to obtain multiple edit distances. The edit distance of the first template is the minimum number of operation steps required to transform the word sequence of the first system log into the word sequence of the first template. The first template is any template in the first type of templates. The multiple edit distances are converted into multiple similarity percentages, and the first type of templates with a similarity percentage greater than a second preset threshold are determined as candidate templates; Obtain the target words defined in the template content of the candidate templates, and determine the candidate templates whose target words all exist in the first system log as the target templates corresponding to the first system log.

4. The method according to claim 1, characterized in that, Based on the aforementioned multiple business logs, the transaction status is restored to obtain the business log processing results, including: Using the terminal number as the isolation key, session interception is performed on the multiple business logs to obtain multiple transaction sessions. Among them, a transaction session is used to reflect the complete lifecycle of a transaction of a terminal. Transaction code sequences are extracted from multiple transaction sessions to obtain multiple transaction code sequences. Each transaction code sequence is composed of multiple transaction opcodes in chronological order, and each transaction code sequence corresponds to one of the multiple transaction sessions. The business type is matched with the multiple transaction code sequences to obtain the business type corresponding to each of the multiple transaction sessions; Extract the error codes associated with the multiple transaction sessions respectively, and convert the error codes associated with the multiple transaction sessions respectively into standardized Chinese descriptions through a preset error code translation table to obtain the initial error business information set corresponding to the multiple transaction sessions respectively. The preset error code translation table stores the standardized Chinese meanings corresponding to various error codes. The initial error service information sets corresponding to the multiple transaction sessions are filtered in the following way to obtain the target error service information sets corresponding to the multiple transaction sessions: The target standardized Chinese description is filtered from the initial error service information set corresponding to the first transaction session to obtain the target error service information set corresponding to the first transaction session. The first transaction session is any one of the plurality of transaction sessions, and the target standardized Chinese description is the standardized Chinese description mapped to the normal service rejection code under the service type corresponding to the first transaction session. The business type corresponding to each of the multiple transaction sessions and the target error business information set are collectively determined as the business log processing result.

5. The method according to claim 4, characterized in that, The multiple transaction code sequences are matched for business types to obtain the business types corresponding to multiple transaction sessions, including: The transaction opcode combinations contained in the multiple transaction code sequences are extracted to obtain multiple transaction opcode combinations, wherein each transaction code sequence in the multiple transaction code sequences corresponds to one of the multiple transaction opcode combinations; For the multiple transaction opcode combinations, business type matching is performed through the business type rule base to obtain the business type corresponding to each of the multiple transaction sessions. The business type rule base contains multiple predefined mapping relationships between transaction opcode combinations and corresponding business types.

6. The method according to claim 1, characterized in that, Based on the system log processing results and the business log processing results, multiple target abnormal events are identified, including: Based on the system log processing results, the matching frequency corresponding to each of the multiple target templates is determined, wherein the matching frequency of the first target template is the total number of standardized system logs that simultaneously match the first target template, and the first target template is any one of the multiple target templates; To match each target template whose frequency is greater than the corresponding first threshold, a system-level abnormal event is generated, wherein the first threshold is the system-level abnormal event trigger threshold; The business types whose transaction results are failed in the business log processing results are identified as the target business types; The frequency of the target business type appearing in the business log processing results is determined as the failure frequency; For each target business type whose failure frequency is greater than the corresponding second threshold, generate a business-level exception event, wherein the second threshold is the business-level exception event trigger threshold; The set consisting of all generated system-level exception events and all generated business-level exception events is determined as the multiple target exception events.

7. The method according to claim 6, characterized in that, The method further includes: determining the first threshold corresponding to any one of the multiple target templates by means of the following method: Multiple initial first thresholds are determined for the first target template, wherein each of the multiple initial first thresholds corresponds to a time period, and the multiple initial first thresholds are determined based on first abnormal event data within a historical time period, wherein the first abnormal event data consists of all system-level abnormal events corresponding to the first target template generated within the historical time period. A first target time period for generating the multiple system logs is determined, and the initial first threshold corresponding to the first target time period is determined as the first threshold corresponding to the first target template.

8. The method according to claim 6, characterized in that, The method further includes: the second threshold corresponding to any target business type is determined in the following way: Obtain multiple initial second thresholds corresponding to the first target business type, wherein the first target business type is any one of all target business types whose transaction result is failure, each of the multiple initial second thresholds corresponds to a time period, and the multiple initial second thresholds are determined based on second abnormal event data within the historical time period, wherein the second abnormal event data is all business-level abnormal events corresponding to the first target business type generated within the historical time period; A second target time period for generating the multiple business logs is determined, and the initial second threshold corresponding to the second target time period is determined as the second threshold corresponding to the first target business type.

9. The method according to claim 1, characterized in that, The multiple target anomaly events are merged to obtain initial alarm information, including: Multiple target abnormal events acquired within the target time window are merged after being aligned according to their timestamps to obtain a set of abnormal events. Extract multi-dimensional features corresponding to the set of abnormal events, wherein the multi-dimensional features include a set of error codes, a set of systems involved, a set of physical regions involved, and a set of abnormal business types; Generate the target hash key based on the aforementioned multi-dimensional features; If the target hash key has a count of 0 in the database within a preset time period, the multi-dimensional features corresponding to the abnormal event set will be determined as the initial alarm information.

10. The method according to claim 1, characterized in that, The initial alarm information is analyzed by an alarm intelligence agent to obtain an alarm report for transaction system operation and maintenance, including: When the initial alarm information is found to hit the target information, the alarm agent is driven to perform multiple rounds of fault reasoning analysis on the initial alarm information through prompt words to obtain a preliminary alarm report. Each round of fault reasoning analysis includes anomaly characterization, root cause location, business assessment, and processing measure generation. The target information is at least one of the following: a preset anomaly class name or a preset component identifier. The accuracy of the preliminary alarm report is verified to obtain the accuracy verification result. If the accuracy verification result is successful, the preliminary alarm report is determined as the alarm report used for the operation and maintenance of the transaction system.

11. The method according to claim 10, characterized in that, The alarm agent is guided by prompts to perform multiple rounds of fault reasoning analysis on the initial alarm information, resulting in a preliminary alarm report, including: The iteration process proceeds iteratively through steps 1-3 until a stopping condition is reached, at which point the iteration stops. The alarm agent analyzes the initial alarm information after the iteration stops and generates a preliminary alarm report. The stopping condition is either that the iteration rounds reach a preset maximum number of rounds or that the iteration rounds reach a target preset number of rounds. The alarm agent's response indicates termination of the iteration process. The initial iteration rounds are 0, and the target preset number of rounds is less than the preset maximum number of rounds. The response information is the alarm agent's response to a verification prompt word input to the alarm agent. This verification prompt word guides the alarm agent in evaluating the fault reasoning and analysis process. Step 1: Guided by the target prompt, the alarm agent is driven to call various fault diagnosis tools to perform anomaly identification, root cause location, business evaluation, and processing measure generation on the initial alarm information to obtain target analysis information. The target analysis information includes all information generated during the anomaly identification, root cause location, business evaluation, and processing measure generation process. Step 2: Determine the target analysis information as the new initial alarm information; Step 3: Increment the iteration number by 1.

12. The method according to claim 10, characterized in that, The accuracy of the preliminary alarm report is verified to obtain the accuracy verification results, including: The alarm agent identifies multiple target diagnostic tools from a preset diagnostic tool library and generates multiple verification actions to verify the accuracy of the initial alarm report using the multiple target diagnostic tools. The verification actions are executed using the multiple target diagnostic tools to obtain the verification action execution results; The accuracy verification result is obtained by analyzing the execution result of the verification action through the alarm intelligent agent.

13. A device for determining alarm information, characterized in that, include: The acquisition module is used to acquire multi-source log data generated by the transaction system. The multi-source log data includes at least multiple system logs and multiple business logs. The system logs are logs generated by the system components of the transaction system to record system operating status, connection anomalies, or service errors. The business logs are logs triggered by payment interaction behaviors initiated by terminal devices. The first processing module is used to perform standardization processing and template matching processing on the multiple system logs to obtain system log processing results. The system log processing results include multiple standardized system logs and multiple target templates corresponding to the multiple standardized system logs. The target templates are used to indicate at least one system error feature. The transaction status restoration module is used to restore the transaction status based on the multiple business logs and obtain the business log processing result. The business log processing result is used to indicate at least the business type corresponding to the transactions of multiple terminals in the target monitoring area. The determination module is used to determine multiple target abnormal events based on the system log processing results and the business log processing results, wherein the target abnormal event is at least one of the following: system-level abnormal event, business-level abnormal event; The second processing module is used to merge the multiple target abnormal events to obtain initial alarm information; The fault analysis module is used to perform fault analysis on the initial alarm information through the alarm intelligence agent to obtain an alarm report for the operation and maintenance of the transaction system.

14. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a program, wherein when the program is executed, it controls the device where the non-volatile storage medium is located to execute the operation and maintenance method of the transaction system according to any one of claims 1 to 12.

15. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the operation and maintenance method of the trading system according to any one of claims 1 to 12.

16. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the operation and maintenance method of the trading system according to any one of claims 1 to 12.

Images