Abnormal alarm processing method and device based on user journey view and storage medium

Abstract

The invention discloses an exception alarm processing method and device based on a user journey view and a storage medium, relates to the technical field of distributed system monitoring and operation and maintenance, and discloses an exception alarm processing method based on the user journey view, and the method comprises the steps: obtaining an exception message generated by interface calling when an exception of interface calling is detected; querying pre-configured user journey configuration based on an abnormal interface in the abnormal message, and obtaining a user journey node corresponding to the abnormal interface so as to complement the service context of the abnormal message; and based on the complemented abnormal message, matching a preset alarm rule to generate an alarm notification. According to the method, the interface exception is associated with the user journey node, so that deep fusion of the exception alarm and the service scene is realized, the alarm information has a clear service context, the problem that the traditional alarm information is isolated and lacks a service view angle is solved, and the accuracy of exception positioning and the operation and maintenance response efficiency are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of distributed system monitoring and operation and maintenance technology, and in particular to anomaly alarm handling methods, devices and storage media based on user journey view. Background Technology

[0002] Currently, common anomaly alerts are typically sent via SMS and email for rapid problem localization and response. However, alert messages only contain anomaly stack information, lacking contextual information such as user identity and user actions, resulting in an incomplete reflection of the business scenario at the time of the anomaly. Consequently, operations personnel cannot directly locate problems based on alert content and must manually perform correlation analysis on logs, or even enter the production environment for on-site investigation, to complete the context of the alert content, making the entire problem localization process inefficient.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide an anomaly alarm processing method, device and storage medium based on user journey view, which aims to solve the technical problem of low efficiency in problem localization caused by the lack of business context information such as user operation behavior in anomaly alarms.

[0005] To achieve the above objectives, embodiments of this application provide an anomaly alarm handling method based on a user journey view, the anomaly alarm handling method based on a user journey view comprising: When an exception is detected in an API call, the exception message generated by the API call is retrieved. Based on the abnormal interface in the abnormal message, query the pre-configured user journey configuration to obtain the user journey node corresponding to the abnormal interface, so as to complete the business context of the abnormal message; Based on the completed abnormal message, a preset alarm rule is matched to generate an alarm notification.

[0006] In one embodiment, before the step of querying the pre-configured user journey configuration based on the exception interface in the exception message, the exception alarm handling method based on the user journey view further includes: Based on business log data, obtain the user's operation behavior sequence, and generate candidate user journeys based on the operation behavior sequence; Cluster analysis is performed on the candidate user journeys to identify common operation paths with the same business objectives, and these common operation paths are identified as user journeys. Each user journey is broken down into multiple consecutive user journey nodes according to the business process; Based on the interface call records, the corresponding interfaces are associated with the corresponding user journey nodes to establish a mapping relationship between the user journey and the interfaces, thereby obtaining the user journey configuration.

[0007] In one embodiment, the step of completing the business context of the abnormal message includes: Obtain the error code from the exception message; Based on the error code, query the error code management platform to obtain the application information corresponding to the error code, and then complete the application information into the exception message.

[0008] In one embodiment, before the step of obtaining the exception message generated by the interface call when an exception is detected, the exception alarm handling method based on the user journey view further includes: Intercept exception objects thrown by interface calls through pre-defined AOP aspects; The exception handling JAR package is invoked to extract exception data from the exception object, and the exception data is encapsulated into the exception message and sent to the Kafka cloud service. The exception data includes the end-to-end ID, exception interface, error code, error information and user information. The abnormal message was retrieved by monitoring the Kafka cloud service.

[0009] In one embodiment, after the step of obtaining the exception message generated by the interface call when an exception is detected, the exception alarm handling method based on the user journey view further includes: The abnormal messages are subjected to error information noise reduction processing to identify and filter abnormal types that do not require real-time intervention; Among them, the exceptions that do not require real-time intervention include exceptions caused by failure of business logic verification.

[0010] In one embodiment, the step of matching the completed abnormal message with a preset alarm rule to generate an alarm notification includes: Extract feature information from the completed exception message, the feature information including the user journey node, error code, exception type and exception interface; The feature information is matched with preset alarm rules; Based on the matching results, generate an alarm notification containing the business context.

[0011] In one embodiment, after the step of matching the completed abnormal message with preset alarm rules to generate an alarm notification, the abnormal alarm processing method based on the user journey view further includes: Based on preset statistical dimensions and statistical periods, the completed abnormal messages are aggregated and queried to generate statistical result data; The statistical results are then converted into visual charts for display.

[0012] In one embodiment, after the step of matching the completed abnormal message with preset alarm rules to generate an alarm notification, the abnormal alarm processing method based on the user journey view further includes: Based on the end-to-end ID carried in the completed exception message, query the end-to-end tracing platform to obtain the corresponding call chain view; Based on the return codes and error messages of each application instance in the call chain view, the original root application that caused the exception is determined.

[0013] This application embodiment also provides an anomaly alarm processing device based on a user journey view. The anomaly alarm processing device based on a user journey view includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the anomaly alarm processing method based on a user journey view as described above.

[0014] This application embodiment also provides a storage medium, which is a computer-readable storage medium, and stores a computer program thereon. When the computer program is executed by a processor, it implements the steps of the abnormal alarm handling method based on the user journey view described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application obtains exception messages when an interface call anomaly is detected, and queries the pre-configured user journey configuration based on the exception interface in the exception message to obtain the user journey node corresponding to that interface. This maps the originally isolated technical anomaly to the user's operation path to complete a specific business goal, realizing a shift from a "system perspective" to a "business perspective." This gives the exception information clear business context semantics, thereby improving the understandability and contextual expression of alarm information. Furthermore, by matching the exception message with the completed business context with preset alarm rules to generate alarm notifications, alarm triggering not only depends on dimension indicators such as error codes or exception types, but also integrates business logic such as user operation stages and business process nodes. This effectively distinguishes the impact of anomalies on critical paths and non-critical paths, avoiding misjudgments and response delays caused by the lack of context in traditional alarms, and significantly improving the accuracy of alarms and the efficiency of operation and maintenance response. Attached Figure Description

[0016] Figure 1This is a flowchart illustrating the first embodiment of the abnormal alarm handling method based on user journey view involved in the embodiments of this application; Figure 2 This is a schematic diagram of user journey configuration for the first embodiment of the abnormal alarm handling method based on user journey view involved in the embodiments of this application; Figure 3 This is a schematic diagram of the user journey node configuration in the first embodiment of the abnormal alarm handling method based on the user journey view involved in the embodiments of this application; Figure 4 This is a flowchart illustrating the second embodiment of the abnormal alarm handling method based on user journey view involved in the embodiments of this application; Figure 5 This is a flowchart illustrating the third embodiment of the abnormal alarm handling method based on user journey view involved in the embodiments of this application; Figure 6 This is a schematic diagram of the alarm statistics information screen of the third embodiment of the abnormal alarm handling method based on user journey view involved in the embodiments of this application; Figure 7 This is a flowchart illustrating the fourth embodiment of the abnormal alarm handling method based on user journey view involved in the embodiments of this application; Figure 8 This is a request call chain view of the fourth embodiment of the abnormal alarm handling method based on user journey view involved in the embodiments of this application; Figure 9 This is a simplified flowchart of the fourth embodiment of the abnormal alarm handling method based on user journey view involved in the embodiments of this application; Figure 10 This is a schematic diagram of the structure of the abnormal alarm processing device based on the user journey view involved in the embodiments of this application.

[0017] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0018] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0019] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0020] Currently, common anomaly alerts are typically sent via SMS and email for rapid problem localization and response. However, alert messages only contain anomaly stack information, lacking contextual information such as user identity and user actions, resulting in an incomplete reflection of the business scenario at the time of the anomaly. Consequently, operations personnel cannot directly locate problems based on alert content and must manually perform correlation analysis on logs, or even enter the production environment for on-site investigation, to complete the context of the alert content, making the entire problem localization process inefficient.

[0021] In view of the above problems, this application proposes an exception alarm handling method based on user journey view. When an exception is detected in an interface call, the method obtains the exception message generated by the interface call; based on the exception interface in the exception message, the method queries the pre-configured user journey configuration to obtain the user journey node corresponding to the exception interface, so as to complete the business context of the exception message; based on the completed exception message, the method matches the preset alarm rules to generate an alarm notification.

[0022] This application provides a solution that, upon detecting an interface call anomaly, obtains an exception message and queries a pre-configured user journey configuration based on the exception interface in the exception message to obtain the user journey node corresponding to that interface. This maps the originally isolated technical anomaly to the user's operation path to complete a specific business goal, realizing a shift from a "system perspective" to a "business perspective." This gives the exception information clear business context semantics, thereby improving the understandability and contextual expression of alarm information. Furthermore, by matching the exception message with the completed business context with preset alarm rules to generate alarm notifications, alarm triggering not only depends on dimension indicators such as error codes or exception types, but also integrates business logic such as user operation stages and business process nodes. This effectively distinguishes the impact of anomalies on critical and non-critical paths, avoiding misjudgments and response delays caused by the lack of context in traditional alarms, and significantly improving the accuracy of alarms and the efficiency of operation and maintenance response.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as an anomaly alarm handling system, a distributed operation and maintenance platform, or an electronic device capable of implementing the above functions, an anomaly alarm handling device based on a user journey view, etc. The following description uses an anomaly alarm handling system based on a user journey view as an example to illustrate this embodiment and the subsequent embodiments.

[0024] The first embodiment of the anomaly alarm handling method based on the user journey view proposed in this application is described in reference to... Figure 1 The method includes steps S10 to S30: Step S10: When an exception is detected in the interface call, obtain the exception message generated by the interface call.

[0025] It should be noted that an API call refers to the process by which one software component or service initiates a request to another software component or service and obtains a response. In this application, it specifically refers to a network request triggered by a user operation to access a backend application service. An exception message refers to structured data containing error status and descriptive information generated during an API call due to system errors, business logic errors, or other failures.

[0026] Optionally, steps S101 to S103 are included before step S10: Step S101: Intercept the thrown exception object through the pre-defined AOP aspect interception interface call.

[0027] Step S102: Call the exception handling JAR package, extract exception data from the exception object, encapsulate the exception data into the exception message and send it to the Kafka cloud service. The exception data includes the end-to-end ID, exception interface, error code, error information and user information.

[0028] Step S103: Retrieve the abnormal message by monitoring the Kafka cloud service.

[0029] In this embodiment, exception handling and message generation are achieved by integrating a unified exception handling component into the application. This exception handling component utilizes aspect-oriented programming (AOP) to intercept exceptions thrown by the controller layer at the global level, and then extracts key information and encapsulates it into a message.

[0030] Specifically, a unified exception handling JAR package is built to achieve exception interception and reporting. When an exception occurs during an interface call, a pre-defined AOP aspect enters the unified exception handler to intercept the exception object thrown by the interface call. This handler is implemented based on the Spring framework's `@RestControllerAdvice` and `@ExceptionHandler` annotations, capable of capturing common exception types such as the general exception class `Exception` and the parameter validation exception class `MethodArgumentNotValidException`, and triggering unified exception handling logic. Within the exception handler, key data is extracted from the exception object context, including the end-to-end ID, the exception interface, the error code, the error description (i.e., the error message), and user information (uniformly parsed from the application's local JWT token). This key data is then encapsulated into a structured exception message and sent to the Kafka message queue via an asynchronous producer pattern. In this embodiment, each business system only needs to import this unified exception handling JAR package to achieve automatic collection and reporting of exception data, eliminating the need for redundant development and improving the standardization and reusability of exception handling.

[0031] Optionally, exception logs are recorded through the business system's own logging framework, and then the log collection agent program captures and parses the log content in real time. Then, it further matches the exception stack information through predefined regular expressions and parses out the required exception data items to generate exception messages.

[0032] Optionally, after step S10, the system further includes: performing error information noise reduction processing on the abnormal message, identifying and filtering abnormal types that do not require real-time intervention; wherein, the abnormal types that do not require real-time intervention include abnormalities caused by business logic verification failures. In this embodiment, after receiving an abnormal message, its key fields such as error code, abnormal type, and error information are first parsed, and a matching judgment is made in conjunction with a preset noise reduction rule base. For example, for abnormalities with an error code of 400, an abnormal type of MethodArgumentNotValidException or ConstraintViolationException, and an error message containing features such as "invalid parameter," "verification failure," or "amount exceeding limit," they are determined to be business logic verification abnormalities, which belong to user operation compliance interception and usually do not require real-time intervention by R&D or operation and maintenance personnel. Therefore, the system can mark such abnormalities as "low priority" or filter them directly, preventing them from entering the subsequent alarm generation process, thereby effectively reducing the number of invalid alarms and avoiding alarm fatigue.

[0033] Step S20: Based on the abnormal interface in the abnormal message, query the pre-configured user journey configuration to obtain the user journey node corresponding to the abnormal interface, so as to complete the business context of the abnormal message.

[0034] It should be noted that user journey configuration refers to pre-built data configuration used to associate system interfaces with user business operations, which records the mapping relationship between user journey, user journey nodes and system interfaces.

[0035] The user journey refers to the set of continuous operations performed by a user on a system to achieve a specific business goal (such as purchasing public funds, redeeming public funds, or purchasing insurance asset management products).

[0036] User journey nodes refer to atomic operation nodes obtained by breaking down the user journey according to the business process. Each user journey node corresponds to a specific operation step in the business process and can be directly associated with system interfaces. For example, the mutual fund purchase journey includes multiple user journey nodes such as global search, product details viewing, purchase, order submission, and approval submission.

[0037] Business context refers to business scenario information related to the occurrence of an exception, including the user operation steps corresponding to the exception and the business process to which it belongs, which helps to understand the business background of the exception.

[0038] In this embodiment, pre-configured user journey configurations can be queried by accessing a database that stores user journey configurations. The database stores corresponding user journey node information using interface identifiers as indexes. When an exception message is received, the exception interface identifier is extracted, and the corresponding user journey node data is matched in the database using an SQL query. Alternatively, the user journey configuration can be cached in a caching service such as Redis, and user journey node data can be read directly from the cache during queries, reducing database access pressure and improving query efficiency.

[0039] Optionally, user journey configurations can be pre-built manually to establish a business mapping relationship between user operation paths and system interfaces. For example, the user journey configuration might look like this. Figure 2 As shown. Specifically, based on the system's business scenario, all user operations within the system are pre-decomposed into large user journeys, such as mutual fund purchase, mutual fund redemption, and insurance asset management purchase. Subsequently, each user journey is further decomposed into multiple user journey nodes according to the business execution sequence. Taking the mutual fund purchase journey as an example, it can be decomposed into multiple user journey nodes such as global search, product details, purchase, order submission, and approval submission. Finally, through a visual configuration interface or configuration file, specific system interfaces are bound to the corresponding user journey nodes, thereby establishing a mapping relationship between user journeys, user journey nodes, and system interfaces. The user journey node configuration is as follows: Figure 3 As shown, by dividing the system's business into multiple user journeys, with each user journey associated with multiple user journey nodes, and each user journey node associated with multiple interfaces in a pre-configured manner, the association between the entire system's user behavior and system interfaces can be realized. This allows the system to use interface-based data to reverse-locate the user journey node of the specific business operation being performed by the user.

[0040] Optionally, in addition to querying the corresponding user journey node through the exception interface to complete the business context, the business context information of the exception message can be further enriched by the error code. Specifically, the exception message completion step (i.e., the step of completing the business context of the exception message) also includes the following operations: First, parse the error code from the exception message; then, query the unified error code management platform (which records detailed error code information for all systems) based on the error code to obtain the application information corresponding to the error code, including the application owner, deployment instance, and system module to which it belongs; then, add the application information to the exception message to further complete the business context.

[0041] Finally, to facilitate subsequent statistical analysis of abnormal data, the completed abnormal messages are persistently stored in the database. This implementation method combines the business perspective provided by user journey nodes with the operation and maintenance perspective corresponding to error codes to jointly construct alarm information that includes the scope of business impact and the technical responsible party, providing a complete basis for quickly delineating problems.

[0042] Step S30: Based on the completed abnormal message, match the preset alarm rules to generate an alarm notification.

[0043] It should be noted that preset alarm rules refer to a set of conditions pre-defined based on business needs and operational experience to determine whether and how to generate alarms. Examples include rules based on error codes (triggering an alarm when the error code is a specific value) or rules based on user journey nodes (triggering an alarm when an anomaly occurs at a core business node). Alarm notifications are information carriers that present anomaly-related information and handling suggestions in a specific format, used to deliver this information to operations and maintenance personnel so that they can be promptly informed and handle the anomaly.

[0044] Optionally, step S30 includes steps S310 to S330: Step S310: Extract feature information from the completed exception message, the feature information including the user journey node, error code, exception type and exception interface.

[0045] Step S310: Match the feature information with preset alarm rules.

[0046] Step S310: Based on the matching results, generate an alarm notification containing the business context.

[0047] In this embodiment, based on the rule engine, the feature information (such as error code, user journey node, exception type, exception interface, etc.) in the completed exception message can be used as input parameters and matched with the preset alarm rules in the rule engine. If the conditions in the alarm rules are met, an alarm is triggered.

[0048] Optionally, conditional judgment logic can be written to judge the feature information in the abnormal message one by one, and an alarm notification can be generated when the feature information meets the preset alarm rules.

[0049] Alarm rules can be set according to different dimensions such as error code matching, exception type matching, user journey node matching, interface matching, and occurrence frequency matching, and can also be combined based on different dimensions.

[0050] In this implementation, by associating interface anomalies with user journey nodes, rich business context information is added to the original anomaly data, solving the fundamental problem of isolated traditional alarm information and the inability to quickly understand the business scenarios affected by the anomalies. Furthermore, by matching and notifying the supplemented anomaly messages using preset alarm rules, operations and maintenance personnel or developers can intuitively identify and locate problems from a business perspective, significantly improving the efficiency of troubleshooting.

[0051] Optionally, after generating the alarm notification in step S30, AI big data models can be used for assisted analysis and localization to directly output the cause of the problem and the solution. Specifically, the AI ​​big data model-assisted anomaly localization mainly includes a preparatory stage and a real-time processing stage.

[0052] In the preparatory phase, a knowledge base for auxiliary diagnosis is first constructed. This involves feeding structured or unstructured root cause analysis documents and anomaly localization method documents into the AI ​​model, which then processes these materials using RAG (Retrieval-Augmented Generation) retrieval enhancement generation technology to form the knowledge base. Simultaneously, each piece of information in the knowledge base is encoded into vector form and stored. This allows the AI ​​model to quickly retrieve the most relevant documents or paragraphs for the input alert issue through similarity calculations (such as cosine similarity based on word embeddings), thereby outputting the cause of the problem and the solution. Furthermore, the large-scale model's prompts need to be configured and debugged. Structured prompts are written to clearly guide the AI ​​model on how to process input information and in what format to output results, and these prompts are continuously optimized based on historical feedback data.

[0053] During the real-time processing phase, after generating an alarm notification, the system inputs the completed abnormal alarm information (including the corresponding abnormal message and related abnormal data) into the AI ​​big model that has been debugged in the preparatory phase. The AI ​​big model combines similar cases and solutions retrieved from the knowledge base to conduct a comprehensive analysis of the current abnormal alarm, and finally directly generates a solution that includes root cause inference and specific handling steps.

[0054] Based on the above embodiments of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 Before step S20, the abnormal alarm handling method based on the user journey view further includes steps S201 to S204: Step S201: Based on business log data, obtain the user's operation behavior sequence, and generate a candidate user journey based on the operation behavior sequence.

[0055] It should be noted that business log data refers to structured data recorded by the system during operation, including user actions, API calls, and business processing results. It typically includes user identifier, operation time, operation type, and accessed API. An operation sequence refers to a continuous chain of operations performed by the same user within a preset time range, reflecting the user's continuous business interaction process. A candidate user journey is an operation path that may represent a user's specific business goal, initially formed from one or more operation sequences.

[0056] Optionally, log collection tools (such as Flink and Logstash) can be used to read business log data in real time. The business log data is grouped by user identifier and sorted in ascending order by operation timestamp. Information such as operation type and associated interfaces within each group is extracted to form an operation behavior sequence. When generating candidate user journeys, the business intent corresponding to the operation behavior sequence can be identified through predefined key interface combinations and / or business rules, thereby determining the candidate user journey. For example, if the operation behavior sequence includes a product details query interface and terminates with a purchase order submission interface, the sequence is determined to be a candidate user journey for "fund purchase"; if the operation behavior sequence terminates with a redemption application interface, the sequence is determined to be a candidate user journey for "fund redemption". Through this rule matching based on endpoint events and operation context, the original operation behavior sequence can be transformed into a candidate user journey with a clear business objective.

[0057] For example, if a user's operation sequence is detected as "calling the product list query interface → calling the product details view interface → triggering the purchase order submission interface", then the sequence is identified as a candidate user journey of "fund purchase" based on the pre-set key interface combination.

[0058] Step S202: Perform cluster analysis on the candidate user journeys to identify common operation paths with the same business objectives, and determine the common operation paths as user journeys.

[0059] It should be noted that common operation paths refer to combinations of operation steps that are common in the journeys of candidate users of the same category and reflect the same business objectives, after cluster analysis.

[0060] Optionally, the sequence of operational behaviors corresponding to each candidate user journey is transformed into a feature vector, and clustering is performed by calculating the similarity between the feature vectors corresponding to different candidate user journeys. For example, the edit distance algorithm is used to calculate sequence similarity, and candidate journeys with high similarity are grouped into the same category according to a preset similarity threshold. Subsequently, operational steps and their order that occur more frequently than a preset threshold are extracted from each category, such as core user journey nodes that occur more than 80% of the time, thereby forming common operational paths that represent the business objectives of this type.

[0061] Optionally, a hierarchical clustering algorithm is adopted. Initially, each candidate journey is regarded as an independent category. The categories with the highest similarity are gradually merged through iterative calculation until the number of categories converges to the same number as the preset business target. For example, the journey categories corresponding to typical business scenarios such as fund purchase, fund redemption, and insurance purchase are finally formed. Then, common operation paths are extracted from each stable category and determined as the corresponding user journey.

[0062] Step S203: Decompose each user journey into multiple consecutive user journey nodes according to the business process.

[0063] In this embodiment, after decomposing the user journey into multiple user journey nodes, each user journey node is labeled with a node identifier, its corresponding business stage, and its preceding and following node relationships. The preceding and following node relationships refer to labeling the preceding dependent nodes (i.e., nodes whose operations must be completed before the current user journey node operation) and the following associated nodes (i.e., nodes that can be performed after the current user journey node operation is completed), reflecting the logical order between user journey nodes.

[0064] Optionally, a business process modeling-based approach can be used for decomposition and annotation. Specifically, based on the natural order of business process execution and data dependencies, the user journey is broken down into sequentially executed user journey nodes, ensuring that each user journey node represents a complete business action. During annotation, a unique identifier is assigned to each user journey node. Simultaneously, by establishing a node relationship mapping table, the direct predecessor and successor nodes of each user journey node are explicitly defined, thereby describing the progression logic of the business process.

[0065] Step S204: Based on the interface call record, associate the corresponding interface with the corresponding user journey node to establish the mapping relationship between the user journey and the interface, and obtain the user journey configuration.

[0066] It should be noted that the API call logs are records kept by the system backend regarding specific API accesses triggered by frontend operations. Establishing a mapping relationship refers to using data analysis to determine which backend interface(s) primarily provide services for each user journey node, thereby forming a correspondence between business nodes and system interfaces.

[0067] Specifically, by analyzing the set of backend interfaces triggered when each user journey node occurs in the historical call logs, a mapping relationship between user journey nodes and system interfaces is established. For example, under the "Submit Order" user journey node, if the system records frequent calls to the / api / order / submit interface, then that interface is bound to that user journey node. For operations involving multiple interfaces, such as when displaying product details, the user journey node corresponding to "Product Details" may call multiple interfaces such as rate information, limit rule query, and dividend record query, then a one-to-many mapping relationship is established.

[0068] Based on the above embodiments of this application, in the third embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 After step S30, the abnormal alarm handling method based on the user journey view includes steps S40-S50: Step S40: Based on preset statistical dimensions and statistical periods, perform aggregate queries on the completed abnormal messages to generate statistical result data.

[0069] Step S50: Convert the statistical results data into visual charts for display.

[0070] In this embodiment, the abnormal message completed in step S20 includes complete business context information such as the full-link ID, abnormal interface, error code, error message, user information application, user journey nodes, and application information. The completed abnormal message is persistently stored. To enable real-time response and statistical analysis of abnormal information, after generating an alarm notification, the system performs statistical processing on the abnormal data in the persistently stored abnormal message corresponding to the alarm notification, according to preset statistical requirements, based on multiple dimensions such as interface, error code, business function, and user. This generates statistical results data, which are then visually displayed on the operation and maintenance platform (i.e., the alarm statistics dashboard) using line charts, pie charts, bar charts, and other visual charts. This provides a basis for post-event analysis of abnormal alarms. Figure 6 As shown.

[0071] Specifically, the anomaly information corresponding to the alarm notification includes key information such as the anomaly time, the anomaly interface, the error code, the user journey, user journey nodes, and the user. Therefore, the system can perform multi-dimensional aggregation analysis on anomaly data within a specified time range according to statistical needs. The statistical dimensions (such as interface, error code, user journey, etc.) and statistical periods (such as the past hour, the current day, the past week, etc.) can both be preset through the configuration interface.

[0072] When performing statistical analysis, structured query statements (SQL statements) can be used to perform statistical calculations on persistently stored abnormal data. For high-frequency error codes in the abnormal data, a group-by approach can be used to count the frequency of each error code within the past month's abnormal data and retrieve the top ten most frequent error codes. The calculation method is similar for statistical items in the abnormal data, such as alarm interfaces, affected customers, and alarm journeys (i.e., using SQL statements to group and count by the abnormal interface, user identifier, and user journey fields, and obtaining the top few most frequent data). For historical alarm quantity trend statistics, the system can aggregate and update the daily abnormal quantity by time granularity when persistently storing abnormal messages. This allows direct querying from the database of the number of alarm notifications generated daily within the statistical period, thus enabling the creation of a time-series-based alarm trend chart.

[0073] Based on the above embodiments of this application, in the fourth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 7 After step S30, the abnormal alarm handling method based on the user journey view includes steps S60-S70: Step S60: Based on the end-to-end ID carried in the completed exception message, query the end-to-end tracing platform to obtain the corresponding call chain view.

[0074] It should be noted that the full-link ID is generated by the UUID algorithm as a unique identifier when the request accesses the first application. This identifier is passed between each application instance in the distributed system through the HTTP request header, and is used to associate the processing processes of the same business request in different systems. When an exception occurs in the interface call, the exception information generated by the interface call contains the full-link ID.

[0075] In this embodiment, during the process of the distributed system processing the user request, when the request is passed between applications, the full-link ID and the unique ID of this access are passed to each downstream application instance through the HTTP request header. Each application instance records the detailed information of each request through the unified log platform, including key data such as application name, interface name, full-link ID, return code, error information, this request ID, caller request ID, etc. The system can obtain the call details of all application instances passed by this request by calling the query interface provided by the full-link tracing platform and inputting the full-link ID, so as to construct a complete view of the request call chain, as Figure 8 shown.

[0076] Step S70: Based on the return codes and error information of each application instance in the call chain view, determine the original root application that generates the exception.

[0077] It should be noted that the return code refers to the status identification code returned by each application instance after processing the request, and is used to represent the success or failure status of the request processing result.

[0078] In this embodiment, based on the call chain view, by analyzing the return codes and error information of each application instance in the call chain data, the exception propagation path is traced backwards in the order of call time. When it is found that a certain application instance returns a return code representing an error and all subsequent call chain nodes are in an abnormal state, it can be determined that this application instance is the original root application that generates the exception. Then, by combining the exception root application at the technical level with the user journey node information at the business level, the specific business link where the exception occurs and its technical reasons can be accurately located, forming a complete fault location view.

[0079] Exemplarily, in order to help understand the implementation process of the exception alarm handling method based on the user journey view obtained by combining this embodiment with the above embodiment, please refer to Figure 9 , Figure 9 which provides a brief flow schematic diagram of the exception alarm handling method based on the user journey view. Specifically: When an exception occurs in the business application, first capture the exception through the integrated unified exception handling JAR package, and asynchronously send the exception message containing key data such as error code, error information, exception interface, user information, and full-link ID to the KAFKA cloud service.

[0080] After monitoring and retrieving exception messages from the KAFKA cloud service, the exception handling application queries the user journey configuration application for the user journey and user journey node information corresponding to the exception interface. Simultaneously, it queries the unified error code platform for application information associated with the error code, including the application information, its associated responsible person, deployment instance, etc. After obtaining the user journey node information and application information, the exception handling application supplements the original exception message with the user journey, user journey node information, and application information, thereby completing the business context of the exception message.

[0081] Subsequently, the exception handling service matches the completed exception message against locally configured alarm rules. These alarm rules can be configured to match different dimensions, such as error code matching, exception type matching, user journey node matching, interface matching, and occurrence frequency matching. For example, whether the error code, exception type, and exception interface are within the alarm whitelist rules. If the match is successful, meaning the exception is within the alarm rules, an alarm notification containing the complete business context is generated and sent to the relevant developers or operations personnel. Furthermore, regardless of whether an alarm is triggered, the completed exception information is persistently stored in the exception message database.

[0082] After receiving an alarm notification, developers can use the large model platform to assist in delineation. They can input abnormal data such as error codes and error messages into the large model to obtain preliminary problem diagnosis suggestions generated by the large model. At the same time, they can also jump to the full-link tracing platform based on the full-link ID in the abnormal message to assist in delineation, visualize the distributed call chain data, and thus locate the root cause application of the abnormality, forming a closed-loop processing flow from alarm to location.

[0083] Furthermore, based on persistent storage, abnormal message data can be grouped and analyzed in real time according to multiple dimensions such as abnormal interface, error code, business function, and user. The abnormal situation can be intuitively displayed on the alarm statistics information screen through visualization charts such as line charts, pie charts, and bar charts, providing data support for operation and maintenance decisions.

[0084] This application provides an anomaly alarm processing device based on a user journey view. The anomaly alarm processing device based on a user journey view includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the anomaly alarm processing method based on the user journey view in the first embodiment described above.

[0085] The following is for reference. Figure 10The diagram illustrates a structural schematic of an anomaly alarm processing device suitable for implementing the user journey view-based embodiments of this application. The user journey view-based anomaly alarm processing device in the embodiments of this application may include various hardware and software components for implementing the user journey view-based anomaly alarm processing method. Figure 10 The illustrated anomaly alarm handling device based on user journey view is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0086] like Figure 10 As shown, the user journey view-based anomaly alarm handling device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the user journey view-based anomaly alarm handling device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the user journey view-based anomaly alarm processing device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows user journey view-based anomaly alarm processing devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0087] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0088] The anomaly alarm processing device based on user journey view provided in this application, employing the anomaly alarm processing method based on user journey view in the above embodiments, can solve the technical problem of low efficiency in problem localization due to the lack of business context information such as user operation behavior in anomaly alarms. Compared with the prior art, the beneficial effects of the anomaly alarm processing device based on user journey view provided in this application are the same as the beneficial effects of the anomaly alarm processing method based on user journey view provided in the above embodiments, and other technical features in the anomaly alarm processing device based on user journey view are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0089] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0091] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the abnormal alarm handling method based on the user journey view in the above embodiments.

[0092] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0093] The aforementioned computer-readable storage medium may be included in a user journey view-based anomaly alarm processing device; or it may exist independently and not assembled into a user journey view-based anomaly alarm processing device.

[0094] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the user journey view-based exception alarm processing device, the user journey view-based exception alarm processing device: when an exception is detected in an interface call, obtains the exception message generated by the interface call; based on the exception interface in the exception message, queries the pre-configured user journey configuration to obtain the user journey node corresponding to the exception interface, so as to complete the business context of the exception message; and based on the completed exception message, matches a preset alarm rule to generate an alarm notification.

[0095] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0097] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0098] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described user journey view-based anomaly alarm handling method. This solves the technical problem of low efficiency in problem localization due to the lack of business context information such as user operation behavior in anomaly alarms. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the user journey view-based anomaly alarm handling method provided in the above embodiments, and will not be repeated here.

[0099] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described user journey view-based exception alarm handling method.

[0100] The computer program product provided in this application can solve the technical problem of low efficiency in problem localization caused by the lack of business context information such as user operation behavior in abnormal alarms. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the abnormal alarm handling method based on user journey view provided in the above embodiments, and will not be repeated here.

[0101] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

[0102] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0103] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0104] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for handling abnormality alarm based on user journey view, characterized in that, The abnormal alarm processing method based on the user journey view comprises the following steps: When detecting that an interface call is abnormal, an exception message generated by the interface call is acquired; Based on an abnormal interface in the exception message, a pre-configured user journey configuration is queried to acquire a user journey node corresponding to the abnormal interface, so as to complete a business context of the exception message; Based on the completed exception message, a preset alarm rule is matched to generate an alarm notification. 2.The user journey view based anomaly alert handling method of claim 1, wherein, Before the step of querying the pre-configured user journey configuration based on the abnormal interface in the exception message, the abnormal alarm processing method based on the user journey view further comprises the following steps: Based on business log data, an operation behavior sequence of a user is acquired, and based on the operation behavior sequence, a candidate user journey is generated; The candidate user journey is subjected to cluster analysis to identify a common operation path with the same business target, and the common operation path is determined as a user journey; Each user journey is disassembled into a plurality of continuous user journey nodes according to a business process; According to interface call records, a corresponding interface is associated to a corresponding user journey node to establish a mapping relationship between the user journey and the interface, and the user journey configuration is obtained. 3.The user journey view based anomaly alert handling method of claim 1, wherein, The step of completing the business context of the exception message comprises the following steps: An error code in the exception message is acquired; Based on the error code, an error code management platform is queried to acquire application information corresponding to the error code, and the application information is completed in the exception message. 4.The user journey view based anomaly alert handling method of claim 1, wherein, Before the step of acquiring the exception message generated by the interface call when detecting that the interface call is abnormal, the abnormal alarm processing method based on the user journey view further comprises the following steps: An exception object thrown by an interface call is intercepted through a pre-set AOP aspect; An exception handling JAR package is called to extract exception data from the exception object, and the exception data is encapsulated into the exception message and sent to a Kafka cloud service, wherein the exception data comprises a full link ID, an abnormal interface, an error code, error information and user information; The Kafka cloud service is monitored to pull the exception message. 5.The user journey view based anomaly alert handling method of claim 1, wherein, After the step of acquiring the exception message generated by the interface call when detecting that the interface call is abnormal, the abnormal alarm processing method based on the user journey view further comprises the following steps: Error information noise reduction processing is performed on the exception message to identify and filter an exception of an exception type that does not need real-time intervention; The exception of the exception type that does not need real-time intervention comprises an exception caused by a failure of business logic verification. 6.The user journey view based anomaly alert handling method of claim 1, wherein, The step of matching a preset alarm rule based on the completed exception message to generate an alarm notification comprises the following steps: Feature information is extracted from the completed exception message, wherein the feature information comprises the user journey node, the error code, the exception type and the abnormal interface; The feature information is matched with the preset alarm rule; According to a matching result, an alarm notification containing a business context is generated.

7. The method of claim 1, wherein the method further comprises: After the step of matching the preset alarm rule based on the completed exception message to generate the alarm notification, the abnormal alarm processing method based on the user journey view further comprises the following steps: Based on the preset statistical dimension and statistical period, the completed abnormal message is aggregated and queried to generate statistical result data; The statistical result data is converted into a visual chart for display. 8.The user journey view based anomaly alert handling method of claim 1, wherein, After the step of matching the completed abnormal message with the preset alarm rule to generate an alarm notification, the user journey view-based abnormal alarm processing method further includes: According to the full-link ID carried in the completed abnormal message, a full-link tracking platform is queried to obtain a corresponding call chain view; Based on the return code and error information of each application instance in the call chain view, the original root application that caused the abnormality is determined. 9.A device for handling abnormality alarm based on user journey view, characterized in that, The user journey view-based abnormal alarm processing device includes a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the user journey view-based abnormal alarm processing method according to any one of claims 1 to 8.

10. A storage medium, characterized by The storage medium is a computer-readable storage medium, and the storage medium stores a computer program. When the computer program is executed by the processor, the steps of the user journey view-based abnormal alarm processing method according to any one of claims 1 to 8 are implemented.

Images