Fault data analysis method, device, equipment and medium

Abstract

The present application relates to the technical field of data analysis, and discloses a fault data analysis method, device, equipment and medium, comprising: acquiring a fault event sequence of a target fault device, judging whether each event has an event association identifier; if yes, generating a fault context object according to the associated events; otherwise, generating a fault context object by associating each event with the event closest in time according to the timestamp. Extracting the request data, response data, HTTP status code and exception type in the object, and performing interface format specification verification to obtain a verification result. Then, judging whether the verification result, status code and exception type match a preset fault rule; if yes, directly outputting a standard analysis result; otherwise, filling the fault context object into a prompt word template, and then calling a large language model to generate a natural language analysis result. It can be applied to financial technology, medical health and other business system platforms. The present application improves the accuracy and readability of fault analysis.

Description

Technical Field

[0001] This invention relates to the field of data analysis technology, and in particular to a fault data analysis method, apparatus, equipment and medium. Background Technology

[0002] In the fintech field, distributed dashboards are widely used in core scenarios such as online transaction monitoring, risk control decision display, payment gateway status dashboards, and customer asset overviews. These applications typically employ a front-end / back-end separation architecture, where a single user operation triggers browser scripts, multiple API requests, gateway forwarding, and collaborative processing by back-end microservices. When dashboards experience data loading failures, transaction submission timeouts, or abnormal asset display, the root cause may lie on the browser side (e.g., script errors), the network layer (e.g., request timeouts), or the server side (e.g., the risk control interface returning an unexpected status). Current technologies rely on front-end monitoring tools, network packet capture platforms, and back-end log systems to collect independent data, lacking the ability to uniformly correlate events for a single transaction or operation.

[0003] In the healthcare field, dashboard systems are widely used in electronic medical record (EMR) dashboards, real-time monitoring of patient vital signs, access to medical images, self-service registration and payment terminals, and hospital resource scheduling interfaces. These systems have extremely high requirements for data accuracy and continuity; any failure can affect clinical decisions or treatment processes. However, existing monitoring technologies typically store fault data in a fragmented manner, from the browser side (e.g., front-end errors on doctor workstations), the network side (e.g., HTTP timeouts in image transmission), and the server side (e.g., HIS system database anomalies), lacking an event correlation mechanism tailored to individual patient sessions or single treatment operations. Furthermore, existing fault reports are filled with technical stacks and status codes, making them difficult for clinical engineers and non-IT healthcare personnel to understand, while error reports from patient-facing self-service terminals lack user-friendly natural language guidance. Therefore, there is an urgent need for a fault diagnosis solution that integrates multi-source event correlation, interface contract verification, sensitive information anonymization, and role-based natural language interpretation to ensure the reliability and compliance of healthcare dashboards. Summary of the Invention

[0004] This invention provides a fault data analysis method, apparatus, computer equipment, and medium to solve the problems of poor accuracy and readability of existing fault data analysis methods on the market.

[0005] Firstly, a fault data analysis method is provided, including: Obtain the sequence of fault events of the target faulty device within a preset time window; Determine whether the fault events in the fault event sequence have preset event association identifiers; If the fault event has an event association identifier, then the fault events in the fault event sequence are associated based on the event association identifier to obtain a fault context object; If the fault event does not have an event association identifier, then each fault event without an event association identifier is associated with the fault event that is closest in time in the fault event sequence according to the timestamp to obtain a fault context object; Extract the request data, response data, HTTP status code, and exception type from the fault context object; The request data and the response data are validated for interface format specifications to obtain the specification validation result. Determine whether the verification result, the HTTP status code, and the exception type match the preset fault rules; If a match is found, the standard analysis result of the fault context object is output based on the specification verification result, the HTTP status code, and the exception type. If there is no match, the fault context object is filled into the preset prompt word template to obtain the filled prompt word; The natural language analysis results of the fault context object are generated based on the filled-in prompt words using a preset large language model.

[0006] Secondly, a fault data analysis device is provided, comprising: The data acquisition module is used to acquire the sequence of fault events of the target faulty device within a preset time window; The event association module is used to determine whether the fault events in the fault event sequence have a preset event association identifier. If the fault event has an event association identifier, the fault events in the fault event sequence are associated based on the event association identifier to obtain a fault context object. If the fault event does not have an event association identifier, each fault event without an event association identifier is associated with the fault event in the fault event sequence that is closest in time according to the timestamp to obtain a fault context object. The specification verification module is used to extract the request data, response data, HTTP status code and exception type from the fault context object, perform interface format specification verification on the request data and the response data, and obtain the specification verification result. An anomaly detection module is used to determine whether the verification result, the HTTP status code, and the anomaly type match preset fault rules. If they match, the module outputs the standard analysis result of the fault context object based on the verification result, the HTTP status code, and the anomaly type. If they do not match, the module fills the fault context object into a preset prompt word template to obtain the filled prompt word. The result generation module is used to generate natural language analysis results of the fault context object based on the filled prompt words using a preset large language model.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described fault data analysis method.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described fault data analysis method.

[0009] The aforementioned fault data analysis method, apparatus, computer equipment, and storage medium can obtain the fault event sequence of the target faulty device within a preset time window. By limiting the time window, the search scope can be effectively narrowed, irrelevant data interference can be reduced, and the efficiency and accuracy of subsequent analysis can be improved. Furthermore, it can determine whether each event carries a preset event association identifier, quickly identifying whether there is a precise association basis, providing a decision-making basis for selecting the optimal association strategy. If it does, the relevant events are associated based on the identifier to form a fault context object. High-precision matching is achieved using the association identifier, ensuring that all contexts of the same fault are completely and unambiguously aggregated, avoiding information fragmentation. If the identifier is missing, each event is associated with the event closest in time in the sequence based on the timestamp, also generating a fault context object. Even when the association identifier is missing, a usable fault context can still be constructed based on time proximity, enhancing the system's robustness to scenarios with incomplete data. Subsequently, request data, response data, HTTP status codes, and exception types are extracted from the object. Key diagnostic features are accurately extracted from the complex context, providing structured and computable input for subsequent verification and attribution. Interface format specification verification is performed on the request and response data to obtain verification results. Contract verification accurately distinguishes between client-side structural violations and server-side contract breaches, improving the granularity and accuracy of root cause localization. Next, it is determined whether the verification results, status codes, and exception types match preset fault rules. Based on multi-dimensional structured information, known fault patterns are quickly matched to achieve deterministic determination of high-frequency problems. If they match, standard analysis results are directly output based on this structured information. Consistent and predictable standard conclusions are directly output for faults that match the rules, avoiding unnecessary model calls and improving overall efficiency and output stability. If they do not match, the fault context object is filled into a preset prompt word template, and then a large language model is called to generate natural language analysis results based on the filled prompt words, improving the accuracy and readability of fault analysis. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of an application environment for a fault data analysis method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a fault data analysis method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a fault data analysis device according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] The fault data analysis method provided in this invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The server can obtain the sequence of fault events of the target faulty device within a preset time window through the client and determine whether each event has a preset event association identifier. If it does, the server associates the related events based on the identifier to form a fault context object. If the identifier is missing, the server associates each event with the event closest in time in the sequence based on the timestamp, also generating a fault context object. Subsequently, the server extracts request data, response data, HTTP status codes, and exception types from this object and performs interface format specification validation on the request and response data to obtain the validation results. Next, the server determines whether the validation results, status codes, and exception types match the preset fault rules. If they match, the server directly outputs standard analysis results based on this structured information. If they do not match, the server fills the fault context object into a preset prompt word template and then calls a large language model to generate natural language analysis results based on the filled prompt words, improving the accuracy and readability of the fault analysis. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The present invention will now be described in detail through specific embodiments.

[0014] Please see Figure 2 As shown, Figure 2 A flowchart illustrating the fault data analysis method provided in this embodiment of the invention includes the following steps: S1. Obtain the sequence of fault events of the target faulty device within a preset time window.

[0015] In the fintech field, the target faulty device typically refers to servers, cloud hosts, container instances, or terminal devices (such as ATMs and smart teller machines) running core financial business systems (such as online trading engines, risk control decision platforms, payment gateways, market data push services, or customer asset dashboards). Failures in these devices may manifest as transaction timeouts, inconsistent order statuses, abnormal returns from risk control interfaces, push delays, or failures to load data on front-end dashboards. These issues directly affect fund security and transaction continuity, thus requiring the rapid identification of the root cause through multi-source event correlation and natural language interpretation.

[0016] In the healthcare field, the target faulty devices include both backend servers supporting hospital information systems (such as electronic medical record systems, image archiving and communication systems, and registration and payment platforms) and terminal devices connected to the medical Internet of Things (such as bed monitors, mobile nursing terminals, and self-service report printers). When these devices experience interface response timeouts, data reporting interruptions, abnormal image loading, or incorrect dashboard indicator displays, it may affect the timeliness of clinical decisions or treatment processes. Therefore, fault diagnosis methods based on event correlation and intelligent interpretation are also needed.

[0017] In this embodiment of the invention, obtaining the fault event sequence of the target faulty device within a preset time window includes: Obtain the fault data of the target faulty device on a preset browser, a preset network, and a preset server to obtain browser fault data, network fault data, and server fault data; Confirm the fault trigger time of the target faulty device; The fault time window is determined based on the preset time window length and the fault trigger time. Obtain the browser failure data, network failure data, and server failure data from the failure event window, and generate a candidate failure event set; The candidate fault event set is sorted in ascending order from earliest to latest according to the timestamp to obtain the fault event sequence.

[0018] In this embodiment of the invention, the search scope is effectively narrowed by limiting the time window, quickly focusing on fault-related events, reducing interference from irrelevant data, and improving the efficiency and accuracy of subsequent analysis.

[0019] In detail, the acquisition of fault data of the target faulty device on the preset browser, preset network, and preset server ends, resulting in browser fault data, network fault data, and server fault data, is achieved by deploying probe scripts in the browser to listen for console errors, unhandled Promise rejections, and page interaction events; configuring interceptors at the network gateway to capture request headers, response headers, status codes, and request / response body summaries; embedding middleware in the server application to record request processing logs, exception stacks, and processing time; and reporting these three types of data to the backend analysis service via a unified message channel, thereby obtaining multi-source heterogeneous raw fault data.

[0020] In detail, the confirmation of the fault trigger time of the target faulty device is achieved by the trigger manager continuously monitoring the real-time data stream reported by the browser, network and server. When a preset automatic trigger condition is detected (such as HTTP status code greater than or equal to 400, script exception, request timeout) or a manual fault report submitted by the user through the interface is received, the moment is recorded as the fault trigger time. If multiple trigger conditions exist at the same time, the earliest time point is taken as the final trigger time.

[0021] In detail, the method of determining the fault time window based on the preset time window length and the fault trigger time is to read the preset time window radius in the system configuration (the default value is 10 seconds, which can be dynamically adjusted according to the average response time of the application or historical fault data), extend the radius forward and backward with the fault trigger time as the center, calculate the start time (trigger time minus radius) and end time (trigger time plus radius) of the window, and form a closed interval as the fault time window.

[0022] In detail, the step of obtaining the browser failure data, network failure data, and server failure data in the failure event window and generating a candidate failure event set involves iterating through all previously collected browser failure data, network failure data, and server failure data, comparing the timestamp of each data entry one by one, retaining only data entries whose timestamps fall between the start and end times of the failure time window, and merging these retained data into a new set, namely the candidate failure event set.

[0023] In detail, sorting the candidate fault event set in ascending order from earliest to latest according to the timestamp to obtain the fault event sequence involves calling a sorting algorithm to rearrange all events in the candidate fault event set in ascending order of time, using their timestamp field as the sorting key. If multiple events have the same timestamp, they can be further sorted by event type or preset priority, and finally an ordered list of events, i.e., the fault event sequence, is output.

[0024] S2. Determine whether the fault events in the fault event sequence have preset event association identifiers.

[0025] In this embodiment of the invention, determining whether a fault event in the fault event sequence carries a preset event association identifier involves traversing the fault event sequence, reading the preset association identifier field (e.g., correlation_id or trace_id) of each event one by one, and determining whether the field exists and is not empty; if at least one valid identifier exists in the sequence, it is determined to "carry" the identifier, otherwise it is determined to "not carry" the identifier.

[0026] If the fault event has an event association identifier, then execute S3 to associate the fault events in the fault event sequence based on the event association identifier to obtain a fault context object.

[0027] In this embodiment of the invention, the step of associating fault events in the fault event sequence based on the event association identifier to obtain a fault context object includes: Extract the associated identifiers from the fault event sequence to generate an associated identifier set; Obtain the fault event pair corresponding to each associated identifier in the associated identifier set in the fault event sequence, and generate a fault event pair set; Identify the event type for each fault event pair in the set of fault event pairs; Based on the set of event types, the set of fault event pairs is classified and aggregated to generate a fault context object.

[0028] In detail, the step of extracting the correlation identifiers from the fault event sequence and generating a correlation identifier set involves iterating through each event in the fault event sequence that has been sorted by time, reading the preset correlation identifier field (such as correlation_id, trace_id, or request_id) for each event, and determining whether the field exists and is not empty.

[0029] In detail, obtaining the fault event pair corresponding to each associated identifier in the associated identifier set in the fault event sequence and generating a fault event pair set involves scanning the entire fault event sequence again for each associated identifier value in the associated identifier set to find all events carrying the same associated identifier; combining these events in pairs (or more accurately, taking all events corresponding to the identifier as an event group) to form a mapping structure with the associated identifier as the key and the corresponding event list as the value.

[0030] In detail, identifying the event type of each fault event pair in the fault event pair set, wherein the event type includes browser-side events, network-side events, and server-side events, and generating an event type set, involves determining the data source of each event within each event group (i.e., multiple events corresponding to each associated identifier) ​​in the fault event pair set: if the event contains browser-specific fields (such as page path, element identifier, console error), it is marked as a "browser-side event"; if the event contains network-specific fields (such as request headers, response headers, status codes, request bodies), it is marked as a "network-side event"; if the event contains server-specific fields (such as request processing logs, exception stack traces), it is marked as a "server-side event".

[0031] In detail, the step of classifying and aggregating the set of fault events based on the set of event types to generate a fault context object involves classifying all browser-side events under the same association identifier into a "browser event list," all network-side events into a "network event list," and all server-side events into a "server event list" according to the tags in the event type set; then supplementing common information such as fault trigger time (taking the earliest timestamp in the group of events), the association identifier itself, and the page path or request path, and encapsulating this information into a unified data structure, namely the fault context object.

[0032] In this embodiment of the invention, high-precision matching is achieved by using association identifiers to ensure that all contexts of the same fault are aggregated completely and unambiguously, thus avoiding information fragmentation.

[0033] If the fault event does not have an event association identifier, then execute S4: associate each fault event without an event association identifier with the fault event that is closest in time in the fault event sequence according to the timestamp to obtain a fault context object.

[0034] In this embodiment of the invention, the step of associating each fault event without an event association identifier with the fault event that is closest in time in the fault event sequence based on the timestamp to obtain a fault context object includes: Obtain the timestamp of each fault event in the fault event sequence to obtain a timestamp set; Based on the timestamp set, the fault event sequence is sorted in ascending order of time to obtain an ordered fault event sequence. Calculate the time interval between adjacent fault events in the ordered fault event sequence; The adjacent fault events in the ordered fault event sequence with a time interval less than a preset threshold are associated to obtain a fault context object.

[0035] In detail, obtaining the timestamp of each fault event in the fault event sequence to obtain a timestamp set involves iterating through each event in the initially filtered fault event sequence, reading its timestamp field (such as timestamp or event_time) from the data structure of each event, extracting the timestamp value and storing it in a temporary record corresponding to the event; if a timestamp is missing for a certain event, it is approximately estimated based on the reporting time or system receiving time of the event and marked as "estimated timestamp".

[0036] In detail, the step of sorting the fault event sequence according to the timestamp set in ascending order to obtain an ordered fault event sequence is to use a sorting algorithm (such as quicksort or mergesort) to rearrange the events in the original fault event sequence in ascending order of timestamps, using the values ​​in the timestamp set as the sorting key.

[0037] In detail, the calculation of the time interval between adjacent fault events in the ordered fault event sequence is to calculate the absolute value of the time difference between each pair of adjacent events by subtracting the timestamp of the previous event from the timestamp of the current event in the sorted ordered fault event sequence, starting from the second event.

[0038] In detail, the step of associating adjacent fault events with time intervals less than a preset threshold in the ordered fault event sequence to obtain a fault context object involves setting a time interval threshold (default value is 2000 milliseconds, which can be dynamically adjusted according to the system average response time or fault type), traversing the time intervals of all adjacent events, and marking adjacent events with intervals less than the threshold as belonging to the same fault cluster; using a connected component algorithm to recursively connect adjacent events that meet the conditions into several event groups, and then selecting the event group containing the fault trigger event (or the one closest to the user report time) as the associated event group for this fault.

[0039] In this embodiment of the invention, a usable fault context is constructed based on temporal proximity when an association identifier is missing, thereby enhancing the system's robustness to scenarios with incomplete data.

[0040] S5. Extract the request data, response data, HTTP status code, and exception type from the fault context object.

[0041] In this embodiment of the invention, extracting the request data, response data, HTTP status code, and exception type from the fault context object includes: Locate the network request event in the fault context object; Read the status code field from the network request event to obtain the HTTP status code; Extract the preset request body fields from the network request event to generate request data; Extract the preset response body fields from the network request event to generate response data; Locate the exception type event in the network request event and read the exception type event.

[0042] In detail, locating network request events in the fault context object involves reading the "network event list" field from the fault context object. This list contains one or more network request-related events (such as request sending, response receiving, timeout records, etc.). The list is then traversed, prioritizing the event that is closest to the fault trigger time and carries an HTTP status code as the target network request event. If there is only one network event, it is used directly; if there is no network event, it is marked as missing and subsequent extraction is terminated.

[0043] In detail, the step of reading the status code field in the network request event to obtain the HTTP status code involves searching for a field named "status", "http_status", or "status_code" in the located target network request event and reading its integer value (such as 200, 404, 500). If the field does not exist or its value is empty, an attempt is made to parse the status code from the response header. If it still cannot be obtained, it is marked as an "unknown status code" and recorded.

[0044] In detail, the step of extracting the preset request body field from the network request event and generating request data involves reading a field named "request_body", "req_data" or "request" from the target network request event. This field may be a JSON string, XML text or form-encoded data. If the request body has been truncated (e.g., only the first N characters are kept to save storage), the truncated digest is used directly. If the request body field is empty, a "no request body" flag is generated.

[0045] In detail, the step of extracting the preset response body field from the network request event and generating response data involves reading a field named "response_body", "resp_data" or "response" from the target network request event. This field typically contains data returned by the server. If the response body is truncated due to being too large or not recorded, an available summary or fragment is used. If the response body field is empty, a "no response body" flag is generated.

[0046] In detail, the process of finding exception type events in the network request events and reading the exception type events involves first searching the "browser event list" within the same fault context object for events with the event type "script exception" or "unhandled asynchronous rejection," and extracting the exception type from them (such as "TypeError" or "ReferenceError"). If no such event is found, the process continues to search the "server event list" for events containing exception stack traces or error messages, and parses the exception type using regular expression matching or a predefined list of exception class names (such as "NullPointerException" or "SQLException"). If no exception type is found, the event is marked as "no exception type".

[0047] S6. Perform interface format specification verification on the request data and the response data to obtain the specification verification result.

[0048] In this embodiment of the invention, the step of performing interface format specification verification on the request data and the response data to obtain the specification verification result includes: Identify the request path and request method of the requested data; The target interface specification structure is obtained from the preset interface specification library according to the request path and the request method; Extract the request fields from the request data to obtain a sequence of request fields; Check whether each field in the request field sequence conforms to the target interface specification structure, and generate a request verification result; Extract the response fields from the response data to obtain the response field sequence; Check whether each field in the response field sequence conforms to the target interface specification structure, and generate a response verification result; The request verification result and the response verification result are combined to generate the standard verification result.

[0049] In detail, the identification of the request path and request method of the request data is achieved by reading the "request path" field (e.g., / api / v1 / report) and the "request method" field (e.g., GET, POST) from the target network request event in the fault context object; if the request path contains query parameters or dynamic fragments, normalization processing is first performed (removing parameter values ​​and replacing numeric IDs with placeholders) to obtain a standardized path and method pair that can be used to match the specification.

[0050] In detail, the step of retrieving the target interface specification structure from a pre-set interface specification library based on the request path and the request method involves searching the pre-loaded interface specification library using the standardized path and request method as a joint key. The interface specification library is a key-value store (such as Redis or memory mapping), where the key is the request method + request path, and the value is an interface specification object conforming to OpenAPI or a custom format (including the required fields of the request fields, type definitions, and structural constraints of the response fields). If the search fails, it is marked as "specification missing" and subsequent verification steps are skipped.

[0051] In detail, the step of extracting the request fields from the request data to obtain the request field sequence involves parsing the request data according to its format type (JSON, XML, form, etc.): if it is JSON, all field names and corresponding value types are extracted recursively; if it is XML, it is converted to JSON structure before extraction; if it is a form, key-value pairs are extracted; finally, a serialized list containing field paths (such as user.name), value types, and whether they exist is generated, which is the request field sequence.

[0052] In detail, the step of checking whether each field in the request field sequence conforms to the target interface specification structure and generating a request verification result involves comparing each field in the request field sequence with the request field definition in the target interface specification one by one: checking whether required fields exist, whether field value types match, and whether field value formats (such as regular expressions) meet the requirements; if any required fields are missing or types do not match, the violation details (field name, expected type, actual type) are recorded, and finally a request verification result containing the result type ("client structure violation" or "client verification passed") and a list of violation details is output.

[0053] In detail, the step of extracting response fields from the response data to obtain a response field sequence involves parsing the response data in the same way, extracting the path, value type, and existence of all response fields, and generating a response field sequence.

[0054] In detail, the step of checking whether each field in the response field sequence conforms to the target interface specification structure and generating a response verification result involves comparing the response field sequence with the response field definitions in the target interface specification: checking whether the required fields required by the specification exist in the response, whether the field types are consistent, and whether the field values ​​are within the allowed range.

[0055] In detail, the merging of the request verification result and the response verification result to generate the specification verification result is based on a priority merging rule: if the request verification result is "client structure violation", then the final specification verification result is "client structure violation" with attached request violation details; otherwise, if the response verification result is "server contract violation", then the final result is "server contract violation" with attached response violation details; otherwise, if both pass, then "verification passed"; if either verification result is "specification missing", then the final result is "verification skipped (no specification)".

[0056] In this embodiment of the invention, standardized verification accurately distinguishes between client-side structural violations and server-side contract breaches, thereby improving the fine-grainedness and accuracy of fault root cause localization.

[0057] S7. Determine whether the verification result, the HTTP status code, and the exception type match the preset fault rules.

[0058] In this embodiment of the invention, deterministic determination of high-frequency problems is achieved by rapidly matching known fault modes based on multi-dimensional structured information.

[0059] If a match is found, then execute S8, and output the standard analysis result of the fault context object based on the specification verification result, the HTTP status code, and the exception type.

[0060] In this embodiment of the invention, the standard analysis result of the fault context object, based on the specification verification result, the HTTP status code, and the exception type, is obtained by using the specification verification result (e.g., client structure violation, server contract breach), the HTTP status code (e.g., 200, 404, 500), and the exception type (e.g., TypeError, NullPointerException) as input to search a preset fault rule mapping table (e.g., if the verification result is "client structure violation," the output is "request data does not conform to the interface specification, please check the front-end parameters"; if the status code is 500 and there is a server exception, the output is "internal server processing exception, it is recommended to check the back-end logs"). Once a corresponding rule is matched, the system directly outputs a structured standard analysis result (usually including fault type, root cause suggestions, and troubleshooting direction).

[0061] In this embodiment of the invention, consistent and predictable standard conclusions are directly output for rule-hit faults, avoiding unnecessary model calls and improving overall efficiency and output stability. If there is no match, then execute S9 to fill the fault context object into the preset prompt word template to obtain the filled prompt word.

[0062] In this embodiment of the invention, filling the fault context object into a preset prompt word template to obtain the filled prompt word includes: Iterate through all placeholder names in the prompt word template to generate a list of placeholder names; Based on each placeholder name in the placeholder name list, extract the corresponding field data from the fault context object to generate a field mapping table; The fault context object is mapped to the prompt word template according to the field mapping table to obtain the populated prompt word.

[0063] In detail, the step of traversing all placeholder names in the prompt word template and generating a list of placeholder names involves using regular expressions (such as \{\{([^}]+)\}\}) to scan the preset prompt word template string, extracting all placeholder identifiers (such as fault_summary, contract_result, key_events) within pairs of double curly braces; storing the extracted unique placeholder names into a list; and returning an empty list and terminating subsequent filling if there are no placeholders in the template.

[0064] In detail, the step of extracting corresponding field data from the fault context object based on each placeholder name in the placeholder name list and generating a field mapping table involves searching for a field with the same name in the fault context object for each name in the placeholder name list, or obtaining the actual data through name mapping logic (e.g., fault_summary corresponds to an automatically generated fault summary, rather than a direct field). If the field exists, its value is directly extracted; if it does not exist, a default value (such as "none" or "unknown") is generated according to preset rules. All placeholder names and their corresponding actual data are combined into key-value pairs to form a field mapping table.

[0065] In detail, the step of filling the field data into the prompt word template according to the field mapping table to obtain the filled prompt word involves iterating through each key-value pair in the field mapping table and replacing all {{key}} placeholders appearing in the prompt word template with their corresponding values ​​(in string form). If the value contains multiple lines of text or a JSON structure, it is first formatted appropriately (such as indentation and escaping) before replacement. After all replacements are completed, it is checked whether there are still unreplaced placeholders. If so, they are filled with default padding. Finally, a complete prompt word string that can be directly used as input for a large language model is output.

[0066] S10. Using a preset large language model, generate the natural language analysis result of the fault context object based on the filled prompt words.

[0067] In this embodiment of the invention, the step of generating the natural language analysis result of the fault context object using a preset large language model based on the filled-in prompt words is achieved by setting model calling parameters and sending the filled-in prompt words as user messages or system messages to the model server. Subsequently, the model generates natural language analysis text that conforms to the evidence boundaries based on the constraints provided in the prompt words (e.g., "the interpretation must not exceed the scope of evidence contained in the fault context") and structured requirements (e.g., distinguishing outputs for end users and technical support personnel). Finally, the system receives the response returned by the model, extracts the generated interpretation content from it, and outputs it as the natural language analysis result.

[0068] In the fintech field, this solution can be applied to intelligent operation and maintenance platforms to diagnose faults in dashboard systems involving core businesses such as trading, risk control, market data, and payments. When users encounter order submission failures or data refresh anomalies on the front-end trading dashboard, the system automatically collects operation events from the browser, network request data from the gateway layer, and logs from the back-end trading engine. These are aggregated into a fault context object through associated identifiers (such as transaction serial numbers) or time windows. After interface contract verification (e.g., checking whether the amount and security code fields in the request are complete) and desensitization processing (masking sensitive information such as user accounts), the system finally generates natural language explanations for customer service personnel (providing technical support) and end users (offering retry suggestions) through heuristic rules or large language models.

[0069] In the healthcare field, this solution can be deployed in hospital electronic medical record systems or medical IoT monitoring platforms to diagnose faults such as loading failures, data not refreshing, or interface timeouts in medical dashboards (such as patient vital signs monitoring dashboards, image access interfaces, and self-service registration and payment terminals).

[0070] As can be seen, the above scheme proposes a fault data analysis method aimed at solving problems such as fragmented multi-source events, difficulty in identifying contract changes, poor output readability, data security risks, and a single processing mechanism. Its core process is as follows: First, a multi-source data collector synchronously collects fault events from the browser, network, and server sides, and determines the fault trigger time based on automatic or manual triggering conditions. Then, a preset time window is used to filter candidate events, prioritizing precise matching based on association identifiers such as request IDs. If the identifier is missing, a downgraded association is performed using time proximity scoring to generate a unified "fault context object." Next, request / response data, HTTP status codes, and exception types are extracted from this object, and a contract validator performs structural verification of requests and responses according to interface specifications to accurately identify client-side structural violations or server-side contract breaches. To avoid sensitive information leakage, the fault context object undergoes anonymization processing before entering the analysis stage. The system then uses a heuristic analyzer to match preset rules based on the verification results, status codes, and exception types. If a match is found, a deterministic standard analysis result is directly output to ensure the efficiency and consistency of handling high-frequency faults. If a match is not found, the anonymized fault context object is filled into a structured prompt word template, and a large language model is called to generate a natural language explanation for end users or technical support personnel. Evidence constraints are used to suppress model illusions. Finally, the explanation result and the associated fault context are output for interface display, work order filling, or fault tracing.

[0071] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0072] In one embodiment, a fault data analysis device is provided, which corresponds one-to-one with the fault data analysis method in the above embodiments. For example... Figure 3 As shown, the fault data analysis device includes a data acquisition module 101, an event association module 102, a standard verification module 103, an anomaly judgment module 104, and a result generation module 105. Detailed descriptions of each functional module are as follows: Data acquisition module 101 is used to acquire the fault event sequence of the target faulty device within a preset time window; The event association module 102 is used to determine whether the fault events in the fault event sequence have a preset event association identifier. If the fault event has an event association identifier, the fault events in the fault event sequence are associated based on the event association identifier to obtain a fault context object. If the fault event does not have an event association identifier, each fault event without an event association identifier is associated with the fault event in the fault event sequence that is closest in time according to the timestamp to obtain a fault context object. The specification verification module 103 is used to extract the request data, response data, HTTP status code and exception type from the fault context object, perform interface format specification verification on the request data and the response data, and obtain the specification verification result. The anomaly detection module 104 is used to determine whether the verification result, the HTTP status code, and the anomaly type match the preset fault rules. If they match, the module outputs the standard analysis result of the fault context object based on the verification result, the HTTP status code, and the anomaly type. If they do not match, the module fills the fault context object into a preset prompt word template to obtain the filled prompt word. The result generation module 105 is used to generate natural language analysis results of the fault context object based on the filled prompt words using a preset large language model.

[0073] In one embodiment, the data acquisition module 101, when performing the acquisition of the fault event sequence of the target faulty device within a preset time window, is specifically used for: Obtain the fault data of the target faulty device on a preset browser, a preset network, and a preset server to obtain browser fault data, network fault data, and server fault data; Confirm the fault trigger time of the target faulty device; The fault time window is determined based on the preset time window length and the fault trigger time. Obtain the browser failure data, network failure data, and server failure data from the failure event window, and generate a candidate failure event set; The candidate fault event set is sorted in ascending order from earliest to latest according to the timestamp to obtain the fault event sequence.

[0074] In one embodiment, the event association module 102, when performing the step of associating fault events in the fault event sequence based on the event association identifier to obtain a fault context object, is specifically used for: Extract the associated identifiers from the fault event sequence to generate an associated identifier set; Obtain the fault event pair corresponding to each associated identifier in the associated identifier set in the fault event sequence, and generate a fault event pair set; Identify the event type for each fault event pair in the set of fault event pairs; Based on the set of event types, the set of fault event pairs is classified and aggregated to generate a fault context object.

[0075] In one embodiment, the event association module 102, when performing the step of associating each fault event without an event association identifier with the fault event that is closest in time in the fault event sequence based on the timestamp to obtain a fault context object, is specifically used for: Obtain the timestamp of each fault event in the fault event sequence to obtain a timestamp set; Based on the timestamp set, the fault event sequence is sorted in ascending order of time to obtain an ordered fault event sequence. Calculate the time interval between adjacent fault events in the ordered fault event sequence; The adjacent fault events in the ordered fault event sequence with a time interval less than a preset threshold are associated to obtain a fault context object.

[0076] In one embodiment, the specification verification module 103, when performing the extraction of request data, response data, HTTP status codes, and exception types from the fault context object, is specifically used for: Locate the network request event in the fault context object; Read the status code field from the network request event to obtain the HTTP status code; Extract the preset request body fields from the network request event to generate request data; Extract the preset response body fields from the network request event to generate response data; Locate the exception type event in the network request event and read the exception type event.

[0077] In one embodiment, the specification verification module 103, when performing interface format specification verification on the request data and the response data to obtain the specification verification result, is specifically used for: Identify the request path and request method of the requested data; The target interface specification structure is obtained from the preset interface specification library according to the request path and the request method; Extract the request fields from the request data to obtain a sequence of request fields; Check whether each field in the request field sequence conforms to the target interface specification structure, and generate a request verification result; Extract the response fields from the response data to obtain the response field sequence; Check whether each field in the response field sequence conforms to the target interface specification structure, and generate a response verification result; The request verification result and the response verification result are combined to generate the standard verification result.

[0078] In one embodiment, the anomaly detection module 104, when performing the step of filling the fault context object into a preset prompt word template to obtain the filled prompt word, is specifically used for: Iterate through all placeholder names in the prompt word template to generate a list of placeholder names; Based on each placeholder name in the placeholder name list, extract the corresponding field data from the fault context object to generate a field mapping table; The fault context object is mapped to the prompt word template according to the field mapping table to obtain the populated prompt word.

[0079] This invention provides a fault data analysis device aimed at solving problems such as fragmented multi-source events, difficulty in identifying contract changes, poor output readability, data security risks, and a single processing mechanism. Its core process is as follows: First, a multi-source data collector synchronously collects fault events from the browser, network, and server sides, and determines the fault trigger time based on automatic or manual triggering conditions. Then, a preset time window is used to filter candidate events, prioritizing precise matching based on associated identifiers such as request IDs. If an identifier is missing, a downgraded association is performed using time proximity scoring to generate a unified "fault context object." Next, request / response data, HTTP status codes, and exception types are extracted from this object, and a contract validator performs structural verification on the requests and responses according to interface specifications, accurately identifying client-side structural violations or server-side contract breaches. To avoid sensitive information leakage, the fault context object undergoes de-identification processing before entering the analysis stage. The system then uses a heuristic analyzer to match preset rules based on the verification results, status codes, and exception types. If a match is found, a deterministic standard analysis result is directly output to ensure the efficiency and consistency of handling high-frequency faults. If a match is not found, the anonymized fault context object is filled into a structured prompt word template, and a large language model is called to generate a natural language explanation for end users or technical support personnel. Evidence constraints are used to suppress model illusions. Finally, the explanation result and the associated fault context are output for interface display, work order filling, or fault tracing.

[0080] Specific limitations regarding the fault data analysis device can be found in the limitations of the fault data analysis method described above, and will not be repeated here. Each module in the aforementioned fault data analysis device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0081] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a fault data analysis method on the server side.

[0082] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a fault data analysis method on the client side.

[0083] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain the sequence of fault events of the target faulty device within a preset time window; Determine whether the fault events in the fault event sequence have preset event association identifiers; If the fault event has an event association identifier, then the fault events in the fault event sequence are associated based on the event association identifier to obtain a fault context object; If the fault event does not have an event association identifier, then each fault event without an event association identifier is associated with the fault event that is closest in time in the fault event sequence according to the timestamp to obtain a fault context object; Extract the request data, response data, HTTP status code, and exception type from the fault context object; The request data and the response data are validated for interface format specifications to obtain the specification validation result. Determine whether the verification result, the HTTP status code, and the exception type match the preset fault rules; If a match is found, the standard analysis result of the fault context object is output based on the specification verification result, the HTTP status code, and the exception type. If there is no match, the fault context object is filled into the preset prompt word template to obtain the filled prompt word; The natural language analysis results of the fault context object are generated based on the filled-in prompt words using a preset large language model.

[0084] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Obtain the sequence of fault events of the target faulty device within a preset time window; Determine whether the fault events in the fault event sequence have preset event association identifiers; If the fault event has an event association identifier, then the fault events in the fault event sequence are associated based on the event association identifier to obtain a fault context object; If the fault event does not have an event association identifier, then each fault event without an event association identifier is associated with the fault event that is closest in time in the fault event sequence according to the timestamp to obtain a fault context object; Extract the request data, response data, HTTP status code, and exception type from the fault context object; The request data and the response data are validated for interface format specifications to obtain the specification validation result. Determine whether the verification result, the HTTP status code, and the exception type match the preset fault rules; If a match is found, the standard analysis result of the fault context object is output based on the specification verification result, the HTTP status code, and the exception type. If there is no match, the fault context object is filled into the preset prompt word template to obtain the filled prompt word; The natural language analysis results of the fault context object are generated based on the filled-in prompt words using a preset large language model.

[0085] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0086] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0087] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0088] It should be noted that in the technical solutions disclosed in this invention, the acquisition of user information (personal image data (e.g., facial videos or pictures, facial feature videos or pictures, etc.) and personal privacy information (e.g., name, ID number, occupation, address, etc.)) is all completed with the user's knowledge and consent, and the acquisition of the relevant user information is legal and compliant.

[0089] Finally, it should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application is authorized (with knowledge and consent) by the relevant parties or fully authorized by all parties, and the executing entity can obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals. The above-described embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A fault data analysis method, characterized in that, include: Obtain the sequence of fault events of the target faulty device within a preset time window; Determine whether the fault events in the fault event sequence have preset event association identifiers; If the fault event has an event association identifier, then the fault events in the fault event sequence are associated based on the event association identifier to obtain a fault context object; If the fault event does not have an event association identifier, then each fault event without an event association identifier is associated with the fault event that is closest in time in the fault event sequence according to the timestamp to obtain a fault context object; Extract the request data, response data, HTTP status code, and exception type from the fault context object; The request data and the response data are validated for interface format specifications to obtain the specification validation result. Determine whether the verification result, the HTTP status code, and the exception type match the preset fault rules; If a match is found, the standard analysis result of the fault context object is output based on the specification verification result, the HTTP status code, and the exception type. If there is no match, the fault context object is filled into the preset prompt word template to obtain the filled prompt word; The natural language analysis results of the fault context object are generated based on the filled-in prompt words using a preset large language model.

2. The fault data analysis method as described in claim 1, characterized in that, The acquisition of the fault event sequence of the target faulty device within a preset time window includes: Obtain the fault data of the target faulty device on a preset browser, a preset network, and a preset server to obtain browser fault data, network fault data, and server fault data; Confirm the fault trigger time of the target faulty device; The fault time window is determined based on the preset time window length and the fault trigger time. Obtain the browser failure data, network failure data, and server failure data from the failure event window, and generate a candidate failure event set; The candidate fault event set is sorted in ascending order from earliest to latest according to the timestamp to obtain the fault event sequence.

3. The fault data analysis method as described in claim 1, characterized in that, The step of associating fault events in the fault event sequence based on the event association identifier to obtain a fault context object includes: Extract the associated identifiers from the fault event sequence to generate an associated identifier set; Obtain the fault event pair corresponding to each associated identifier in the associated identifier set in the fault event sequence, and generate a fault event pair set; Identify the event type for each fault event pair in the set of fault event pairs; Based on the set of event types, the set of fault event pairs is classified and aggregated to generate a fault context object.

4. The fault data analysis method as described in claim 1, characterized in that, The process of associating each fault event without an event association identifier with the fault event that is closest in time in the fault event sequence based on the timestamp to obtain a fault context object includes: Obtain the timestamp of each fault event in the fault event sequence to obtain a timestamp set; Based on the timestamp set, the fault event sequence is sorted in ascending order of time to obtain an ordered fault event sequence. Calculate the time interval between adjacent fault events in the ordered fault event sequence; The adjacent fault events in the ordered fault event sequence with a time interval less than a preset threshold are associated to obtain a fault context object.

5. The fault data analysis method as described in claim 1, characterized in that, The extraction of request data, response data, HTTP status codes, and exception types from the fault context object includes: Locate the network request event in the fault context object; Read the status code field from the network request event to obtain the HTTP status code; Extract the preset request body fields from the network request event to generate request data; Extract the preset response body fields from the network request event to generate response data; Locate the exception type event in the network request event and read the exception type event.

6. The fault data analysis method as described in claim 1, characterized in that, The step of performing interface format specification validation on the request data and the response data to obtain the specification validation result includes: Identify the request path and request method of the requested data; The target interface specification structure is obtained from the preset interface specification library according to the request path and the request method; Extract the request fields from the request data to obtain a sequence of request fields; Check whether each field in the request field sequence conforms to the target interface specification structure, and generate a request verification result; Extract the response fields from the response data to obtain the response field sequence; Check whether each field in the response field sequence conforms to the target interface specification structure, and generate a response verification result; The request verification result and the response verification result are combined to generate the standard verification result.

7. The fault data analysis method as described in claim 1, characterized in that, The step of filling the fault context object into a preset prompt word template to obtain the filled prompt word includes: Iterate through all placeholder names in the prompt word template to generate a list of placeholder names; Based on each placeholder name in the placeholder name list, extract the corresponding field data from the fault context object to generate a field mapping table; The fault context object is mapped to the prompt word template according to the field mapping table to obtain the populated prompt word.

8. A fault data analysis device, characterized in that, include: The data acquisition module is used to acquire the sequence of fault events of the target faulty device within a preset time window; The event association module is used to determine whether the fault events in the fault event sequence have a preset event association identifier. If the fault event has an event association identifier, the fault events in the fault event sequence are associated based on the event association identifier to obtain a fault context object. If the fault event does not have an event association identifier, each fault event without an event association identifier is associated with the fault event in the fault event sequence that is closest in time according to the timestamp to obtain a fault context object. The specification verification module is used to extract the request data, response data, HTTP status code and exception type from the fault context object, perform interface format specification verification on the request data and the response data, and obtain the specification verification result. An anomaly detection module is used to determine whether the verification result, the HTTP status code, and the anomaly type match preset fault rules. If they match, the module outputs the standard analysis result of the fault context object based on the verification result, the HTTP status code, and the anomaly type. If they do not match, the module fills the fault context object into a preset prompt word template to obtain the filled prompt word. The result generation module is used to generate natural language analysis results of the fault context object based on the filled prompt words using a preset large language model.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the fault data analysis method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the fault data analysis method as described in any one of claims 1 to 7.

Images