Log-based event analysis method, electronic device, and computer program product

Abstract

This application relates to the field of computer technology and provides a log-based event analysis method, electronic device, and computer program product, including: acquiring protocol interaction logs of a solid-state drive; determining matching event pairs from the protocol interaction logs; extracting key fields of each event in the matching event pair; performing consistency verification on the matching event pair based on the key fields of each event in the matching event pair; generating a consistency verification conclusion; generating corresponding evidence anchors for each key field of each event in the matching event pair; the evidence anchors at least include a source identifier, a location identifier, and a content consistency identifier generated based on the event; generating and outputting structured analysis results based on the consistency verification conclusions; the structured analysis results include the consistency verification conclusions and references to the evidence anchors corresponding to each event in the matching event pair; the description field of the structured analysis results is composed of the consistency verification conclusions and the referenced evidence anchors.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a log-based event analysis method, electronic device, and computer program product. Background Technology

[0002] Currently, automated testing of SSDs (Solid State Drives) can only output raw logs and basic test reports. When test anomalies occur, manual screening of commands, status codes, and other evidence from the logs is required, which can easily lead to problems such as missing evidence and inability to reproduce conclusions.

[0003] How to efficiently analyze abnormal events in logs is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] This application provides a log-based event analysis method, electronic device, and computer program product that can improve the efficiency and accuracy of event analysis.

[0005] In a first aspect, embodiments of this application provide a log-based event analysis method, including: Obtain the protocol interaction log of the solid-state drive and determine the matching event pairs from the protocol interaction log; Extract the key fields of each event in the matching event pair, and perform a consistency check on the matching event pair based on the key fields of each event in the matching event pair to generate a consistency check conclusion; For each key field of the matched event pair, a corresponding evidence anchor is generated; wherein, the evidence anchor includes at least a source identifier, a location identifier, and a content consistency identifier generated based on the event; A structured analysis result is generated and output based on the consistency verification conclusion. The structured analysis result includes the consistency verification conclusion and a reference to the evidence anchor point corresponding to each event in the matching event pair. The description field of the structured analysis result is composed of the consistency verification conclusion and the referenced evidence anchor point.

[0006] Secondly, embodiments of this application provide a log-based event analysis apparatus, comprising: The event determination module is used to obtain the protocol interaction log of the solid-state drive and determine matching event pairs from the protocol interaction log; The event verification module is used to extract the key fields of each event in the matching event pair, and perform consistency verification on the matching event pair based on the key fields of each event in the matching event pair, and generate a consistency verification conclusion. The evidence generation module is used to generate corresponding evidence anchors for each key field of the matching event pair; wherein the evidence anchors include at least a source identifier, a location identifier, and a content consistency identifier generated based on the event; The result output module is used to generate and output structured analysis results based on the consistency verification conclusion. The structured analysis results include the consistency verification conclusion and references to the evidence anchors corresponding to each event in the matching event pair. The description field of the structured analysis results is composed of the consistency verification conclusion and the referenced evidence anchors.

[0007] Thirdly, embodiments of this application provide an electronic device, 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 method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the method described in the first aspect above.

[0010] In this embodiment, during automated testing, logs from the host-SSD hardware interaction layer, i.e., protocol interaction logs, are acquired. These logs may include multiple events, and causal relationships exist between different events; events with causal relationships are considered matching event pairs. For each matching event pair, key fields are extracted from the events within the pair. The extracted fields are used to verify the time within the matching event pair, yielding a consistency verification conclusion. For each key field of an event in the matching event pair, an evidence anchor point is generated corresponding to that event. Combining the consistency verification conclusion and the evidence anchor point, a structured analysis result is generated for user review. Through evidence anchor points and consistency verification, the analysis results can be traced back to corresponding evidence fragments, improving reproducibility and auditing capabilities, and enhancing the accuracy and efficiency of event analysis. Attached Figure Description

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

[0012] Figure 1 This is a system architecture diagram provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the log-based event analysis method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the log-based event analysis method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the log-based event analysis method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of the log-based event analysis device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0015] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0016] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0017] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0018] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0019] The log-based event analysis method provided in this application can be applied to terminal devices such as mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, robots, and personal digital assistants (PDAs). This application does not impose any restrictions on the specific type of terminal device.

[0020] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows: Status code: refers to the execution result code returned by the device / system, which usually includes a "status code category field" and a "specific status value field".

[0021] Status Code Type (SCT) field.

[0022] The specific status value field is called Status Code, abbreviated as SC.

[0023] Interaction Entry: Refers to a Submission Queue Entry, abbreviated as SQE. It originates from the instruction descriptor written by the host to the SQ submission queue, recording what operation the host wants the SSD to perform; it does not include SCT and SC.

[0024] Completion Entries: These refer to completion queue entries, translated as Completion Queue Entry, or CQE for short. They correspond to the records of execution results returned by the SSD and are command completion entries in the log. Specifically, they originate from the acknowledgments written to the completion queue (CQE) after the SSD has processed the command, recording the actual execution result of the command, including the actual SCT and SC.

[0025] This application belongs to the field of solid-state drive testing and storage protocol diagnostics technology. Current automated testing frameworks can output raw logs and standard test reports, but when complex failures occur, engineers still need to manually sift through multiple logs for key evidence (such as timestamps, commands, object identifiers, status codes, key parameters, etc.) and perform defect analysis and localization based on experience. This presents problems such as a high risk of missing evidence and difficulty in reproducing and quantifying analytical conclusions.

[0026] Current "automatic summarization / automatic reporting" solutions mostly focus on text generation or result display, lacking structured extraction of key fields, traceable evidence chains, and deterministic consistency verification of "expected behavior - actual behavior," resulting in insufficient reliability of automated defect analysis.

[0027] Therefore, there is a need for a technical solution that can perform structured processing of logs within a computer system, construct evidence chains, and perform consistency checks, thereby stably outputting high-quality, traceable structured defect analysis conclusions and diagnostic results.

[0028] The embodiments of this application are applicable to the automated testing and diagnosis of solid-state drive firmware and protocol stacks, and are especially applicable to the joint debugging and testing of storage protocols and hardware devices such as NVMe / TCG (Non-Volatile Memory Express / Trusted Computing Group).

[0029] A typical scenario involves collecting host-side logs and NVMe / TCG command interaction and completion logs during SSD automated testing. This involves performing structured parsing, domain mapping, and consistency verification to automatically output structured defect analysis results and diagnostic conclusions. The diagnostic conclusions can then be further presented in a report for reproduction and localization.

[0030] The system architecture used in the embodiments of this application Figure 1This is a system architecture diagram of the log-based event analysis method according to an embodiment of this application. It includes a terminal 140, an Internet 130, a gateway 120, a server 110, etc.

[0031] Terminal 140 can take various forms, including desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. Terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data.

[0032] Server 110 refers to a computer system that can provide certain services to terminal 140. Compared to ordinary terminal 140, server 110 has higher requirements in terms of stability, security, and performance. Server 110 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines).

[0033] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from terminal 140 to server 110 are forwarded to the corresponding server 110 via gateway 120. Messages sent from server 110 to terminal 140 are also forwarded to the corresponding terminal 140 via gateway 120.

[0034] General Description of Embodiments in this Application According to one embodiment of this application, a log-based event analysis method is provided, which can be executed by an SSD test host or a laboratory automated testing platform (including a server, test controller, or workstation).

[0035] Figure 2 This is a flowchart illustrating a log-based event analysis method, such as... Figure 2 As shown, a log-based event analysis method according to one embodiment of this application may include: Step 210: Obtain the protocol interaction log of the solid-state drive and determine the matching event pairs from the protocol interaction log; Step 220: Extract the key fields of each event in the matching event pair, and perform consistency verification on the matching event pair based on the key fields of each event in the matching event pair to generate a consistency verification conclusion. Step 230: For each key field of the matched event pair, generate a corresponding evidence anchor point; wherein, the evidence anchor point shall at least include a source identifier, a location identifier, and a content consistency identifier generated based on the event; Step 240: Generate and output structured analysis results based on the consistency verification conclusion. The structured analysis results include the consistency verification conclusion and references to the evidence anchors corresponding to each event in the matching event pair. The description field of the structured analysis results is composed of the consistency verification conclusion and the referenced evidence anchors.

[0036] Steps 210-240 are described in detail below.

[0037] In step 210, the interaction item event is obtained by parsing the protocol interaction log, corresponding to the host-issued instruction record carried by the submission queue entry in the storage protocol, which can represent the original business fields such as command type, operation parameters, queue identifier, and command identifier. The completion item event is also obtained by parsing the protocol interaction log, corresponding to the device execution feedback record carried by the completion queue entry in the storage protocol, which can represent the execution result fields such as status code category field and status code value field.

[0038] The protocol interaction log is an NVMe / TCG command interaction and completion log, representing the protocol interaction between the host and the SSD, and belongs to the protocol layer log. The protocol interaction log can be obtained in real time or periodically, and interaction events and completion events can be extracted from it. Interaction events can refer to request events, and completion events can refer to response events.

[0039] Interaction events correspond to submission queue entries where the host sends instructions to the storage device, while completion events correspond to completion queue entries where the storage device sends a response after executing the instruction. A single complete host-storage device protocol interaction has a one-to-one pair of interaction events and completion events. Matching these involves establishing binding relationships between interaction events and completion events with a causal relationship of request and response from all interaction events and completion events in the protocol interaction log. This aligns interaction events and completion events, forming a complete business chain by linking the instruction issuance record with the device execution result record. A single interaction event only reflects the operation instruction, and a single completion event only reflects the execution result. Matching and binding them allows for the simultaneous acquisition of instruction parameters and actual execution status, providing a complete context for subsequent extraction of structured feature information and retrieval of a pre-defined rule database. The resulting binding combination after matching is a matched event pair; each matched event pair includes one interaction event and one completion event.

[0040] Matching event pairs are associated combinations formed after alignment processing. A single matching event pair binds a set of interactive event items and completion event items that have a causal relationship between request and response. This can establish a strong association between command issuance behavior and device feedback behavior, eliminating the matching chaos problem caused by time sequence offset of multi-source logs.

[0041] The protocol interaction log generates a large number of interaction events and completion events in batches. These events are stored in a disordered manner according to time order, making it impossible to directly distinguish which device feedback corresponds to which issued instruction. Matching processing is to eliminate the ambiguity of correspondence caused by the mixed logs, sort out the one-to-one corresponding combination of instructions and receipts, and ensure that subsequent rule judgments are carried out based on the complete interaction context, avoiding the distortion of event analysis results due to mismatch between instructions and results.

[0042] For example, interactive events and completion events can be precisely matched using the queue identifier and command identifier they both carry. Interactive events and completion events corresponding to the same set of queue identifiers and command identifiers are considered to be matched.

[0043] In step 220, key fields of each event in the matched event pair are extracted to form a structured evidence chain. The structured evidence chain is a standardized data set formed after extracting key fields from the original event records, representing all valid field information within the event. It can directly participate in rule retrieval and consistency comparison operations without relying on the original log text. Structured evidence chains can be extracted for each event; that is, for each matched event pair, structured evidence chains for the interaction items and completion items in that pair can be obtained.

[0044] For example, a structured chain of evidence can include multiple fields such as device capability determination field, command parameter field, actual status code field, and object identifier field. All fields and their corresponding field information are uniformly encoded and named in a standardized manner before being stored in structured feature information.

[0045] The pre-set rule database can store multiple rules with multi-dimensional judgment conditions. Each rule can map the corresponding expected status code based on preconditions such as device capabilities, command parameters, and operation objects, providing a standardized protocol benchmark for event difference judgment.

[0046] For example, the rules stored in the preset rule database can be configured with multi-level condition constraints. The conditions are composed of various structured feature information of interaction item events and completion item events. The output content of the rule can include the expected status code defined by the protocol standard. Mutual exclusion constraints can be set between multiple rules to avoid decision conflicts caused by multiple rules hitting at the same time.

[0047] After obtaining the expected status code, the expected status code can be compared with the actual status code extracted from the completed item event, and the comparison result can be used as the consistency verification conclusion.

[0048] In step 230, for each event in the matching event pair, key fields are extracted from the event, such as command type, object identifier, key parameters, and status code, and a corresponding evidence anchor is generated for each event. For example, evidence anchors can be generated based on the content of the key fields of the event, the log source of the event, and the position of the field in the log. That is, the evidence anchor can at least include a source identifier, a location identifier, and a content consistency identifier to support location and auditing. The content consistency identifier can be a hash or signature generated based on the field content.

[0049] In step 240, a structured analysis result can be generated based on the consistency verification conclusion of the matched event pair and the evidence anchors for each event in the matched event pair. That is, the description field of the structured analysis result can be composed of the consistency verification conclusion and the cited evidence anchors. The structured analysis result can be output in the form of a report, which may include, for example, the consistency verification conclusion, the rules used, and the key fields used to generate the consistency verification conclusion.

[0050] In this embodiment, by parsing the protocol interaction logs to distinguish between two types of protocol events and constructing matching event pairs, the end-to-end correlation and standardized consistency verification of protocol interaction behavior can be automatically completed, avoiding the problems of evidence omission, matching errors, and judgment bias caused by manual log analysis, and improving the automation level and accuracy of storage test defect analysis.

[0051] In one implementation, determining matching event pairs from the protocol interaction log includes: slicing the events in the protocol interaction log into segments based on anomaly events and a preset time window to obtain a set of candidate evidence events; and determining matching event pairs from the set of candidate evidence events.

[0052] Specifically, abnormal events are identified from the protocol interaction logs. For each abnormal event, a slice of the log is extracted from the protocol interaction logs according to a preset time window, centered on that abnormal event, to form a candidate evidence event set. That is, the candidate evidence event set is a time-series log segment extracted from the protocol interaction logs based on the timestamp of the abnormal event, obtaining the local log content surrounding that abnormal event. The candidate evidence event set can define the complete log context surrounding the abnormal event, fully preserving all the original text associated with the abnormal event.

[0053] Two interactive events are identified from the set of candidate evidence events and designated as matching event pairs. For example, a request event and a response event targeting the same command identifier can be identified as a matching event pair.

[0054] In this embodiment, a set of candidate evidence events is obtained by capturing window slices of abnormal events, and matching event pairs are determined from the set of candidate evidence events. This can completely retain the original context of a single protocol interaction, filter redundant noise in the logs, reduce the amount of matching data, and improve matching efficiency and accuracy.

[0055] In one implementation, before determining matching event pairs from the protocol interaction log, the process includes: performing format parsing processing on the protocol interaction log to determine all events in the protocol interaction log; for each event in the protocol interaction log, if an event containing a preset abnormal identifier is identified and marked as an abnormal event, the abnormal event and its associated events within a preset time window are retained.

[0056] Specifically, the acquired logs are formatted and parsed, and the recorded content in the logs is converted into an event set. Timestamps, encodings, and field names can be standardized. The event set can include all events in the logs.

[0057] Format parsing is a standardized recognition and conversion process for the raw text of protocol interaction logs. It can uniformly convert unstructured log text into standardized event carriers, providing a data foundation for subsequent anomaly event screening and event type classification. In this embodiment, the format parsing process is not specifically limited.

[0058] Predefined anomaly markers are predefined log tags used to indicate abnormal behavior; for example, they could be assertion markers. These markers quickly distinguish between events valuable for defect analysis and noisy events without business analysis significance, reducing the scope of subsequent data processing and minimizing the computational overhead of invalid data on matching and rule retrieval processes. The system checks if each event in the event set has a predefined anomaly marker. If so, the event is retained and marked as an anomaly; otherwise, it is discarded. All retained anomaly events are then segmented around them, and all events within a predefined window are retained as associated events of that anomaly event.

[0059] For example, the format parsing process can identify the log printing formats corresponding to different protocol specifications, split the original text according to the log's built-in field delimitation rules, and generate log events with a unified data structure. Preset exception flags can be assertion-related markers built into the testing framework, or preset exception alarm flags and failure process flags in the logs.

[0060] In this embodiment, by sequentially performing format parsing and preset identifier filtering on the protocol interaction logs, redundant noise in the logs can be eliminated in advance, and only abnormal events can be retained to participate in the subsequent analysis process, thereby reducing the amount of invalid data computation and improving the overall processing efficiency of automated analysis of storage protocol defects.

[0061] In this embodiment, during automated testing, logs of the host-SSD hardware interaction layer, i.e., protocol interaction logs, are acquired. These logs can include multiple interaction events and completion events. An interaction event refers to a command issued by the host to the SSD, while a completion event refers to the SSD returning a processing result to the host after processing. In other words, there is a causal relationship between interaction events and completion events. Alignment processing can be performed on each interaction event and completion event to identify causally related interaction events and completion events as matching event pairs. For each matching event pair, fields are extracted from the interaction events and completion events to obtain structured evidence chains for the interaction events and completion events. Based on the structured evidence chains of the interaction events and completion events in the matching event pair, and using a preset rule database, the desired status code can be obtained, thereby determining the consistency verification rules and structured analysis results for the matching event pair. By aligning interaction events and completion events to form a complete evidence chain, and by performing structured feature extraction, evidence omissions are avoided, improving the accuracy and efficiency of event analysis.

[0062] Figure 3 This is a flowchart illustrating a log-based event analysis method, such as... Figure 3 As shown, a log-based event analysis method according to one embodiment of this application may include: Step 310: Obtain the request event log on the host side. For each request event and each response event in the request event log, if the command identifier of the request event is consistent with the command identifier of the response event, and the difference between the timestamp of the request event and the timestamp of the response event is less than a preset threshold, then the request event and the response event are determined to constitute a matching event pair. Step 320: Extract the opcode, namespace identifier, and command-specific parameters from the key fields of the request event; extract the actual status code type and actual status code from the key fields of the response event. Step 330: Perform semantic mapping on the opcode, namespace identifier, and command-specific parameters to obtain command type information and namespace status information; Step 340: According to the preset rule database, find the target rule that matches the command type information and namespace status information, and obtain the expected status code type and expected status code from the target rule; Step 350: Compare the actual status code type with the expected status code type, and compare the actual status code with the expected status code to generate a consistency verification conclusion. Step 360: For each key field of the matched event pair, generate a corresponding evidence anchor; wherein the evidence anchor includes at least a source identifier, a location identifier, and a content consistency identifier generated based on the event; Step 370: Generate and output structured analysis results based on the consistency verification conclusions. The structured analysis results include the consistency verification conclusions and references to the evidence anchors corresponding to each event in the matching event pair.

[0063] Steps 360 and 370 have been described in detail above and will not be repeated here. Steps 310-350 will be described in detail below.

[0064] In step 310, the logs collected in this embodiment can be request event logs on the host side, i.e., host-side system logs. The request event logs can include multiple request events and response events. Each event can have its own timestamp, which is the built-in time-series record information of each event, marking the generation time of each event. Events may also correspond to identifiers, which are causal identifiers natively carried by the storage protocol and used to uniquely identify a single issued instruction. For example, they can be queue identifiers, command identifiers, etc. Identifiers can directly establish a one-to-one correspondence between request events and response events, and are the core basis for accurately binding a single complete protocol interaction.

[0065] For each event, the corresponding timestamp and command identifier can be determined. That is, the timestamp and command identifier of the request event, as well as the timestamp and command identifier of the response event, can be obtained.

[0066] Alignment processing is performed on request and response events. This process can refer to performing association matching on the extracted valid request and response events based on two dimensions: timestamp and command identifier, to obtain matching event pairs that have a causal relationship between the request and response.

[0067] For example, a match is determined when the command identifiers of the request and response events match. Alternatively, an exact match can be performed first based on the command identifier, and then a timestamp sequence window can be used to perform auxiliary matching for events with missing command identifiers or those that fail to match.

[0068] Timestamps can synchronously record two types of time-series data: the log collection time and the hardware instruction generation time, enabling multi-dimensional correction of event generation timing. After alignment processing, a unique association marker can be generated for each matching event pair, used for subsequent feature extraction, rule verification, and evidence anchor generation to transfer the binding relationship throughout the entire process, preventing the break in the association between interactive events and completed events.

[0069] This embodiment considers a request event and a response event to constitute a matching event pair only when both the command identifier and the timestamp are satisfied simultaneously. That is, if the command identifier of the request event is the same as the command identifier of the response event, and the difference between the timestamp of the request event and the timestamp of the response event is less than a preset threshold, then the request event and the response event are determined to constitute a matching event pair.

[0070] In this embodiment, by combining the two dimensions of timestamp and identifier to collaboratively perform alignment processing of interactive item events and completed item events to generate matching event pairs, it can take into account both accurate causal matching and time-series fallback matching capabilities, reduce the probability of event mismatch caused by log time-series offset and missing identifiers, and improve the completeness and accuracy of the restoration of storage protocol interaction behavior.

[0071] Specifically, for each request event and each response event, the timestamps of these two events are subtracted to obtain the time difference. That is, the time difference is the time sequence deviation value obtained by subtracting the timestamp corresponding to the request event from the timestamp corresponding to the response event. It can quantify the degree of time sequence offset between the two types of events, and is used to filter event combinations with excessively large time intervals or no business relationship, and avoid mismatches between cross-batch instructions and receipts.

[0072] A pre-set difference threshold is used to define the acceptable range of timing deviations. This threshold adapts to scenarios involving clock drift and log printing delays caused by asynchronous log collection between the host and storage devices. As a second layer of constraint beyond identifier matching, only event combinations with timing deviations within the threshold range are eligible to be bound as matching event pairs. In other words, it determines whether the calculated time difference is less than the preset difference threshold. If it is, the request and response events may form a matching event pair; otherwise, they do not.

[0073] For the two constraints of timestamp and identifier, a matching event pair can be determined when either constraint is satisfied, or both constraints can be satisfied. This embodiment does not specify a particular order for comparing the constraints.

[0074] In this embodiment, by using a dual constraint of identifier consistency and timing difference threshold to filter interaction item events and completion item events to generate matching event pairs, it is possible to balance the accuracy of protocol causal matching with the adaptability of timing asynchronous scenarios, significantly reduce the probability of event mismatch caused by log clock drift and printing delay, and improve the reliability of storage protocol interaction behavior restoration.

[0075] In step 320, each matching event pair may include a request event and a response event. For each request event, key fields such as opcode, namespace identifier, and command-specific parameters can be extracted from the request event; for each response event, key fields such as [missing information] can be extracted from the response event.

[0076] In step 330, a domain knowledge base can be pre-set, and semantic mapping can be performed on the extracted fields based on the domain knowledge base. Semantic mapping processing can convert the original field values ​​extracted from window slicing into standardized business semantic content, eliminating ambiguity caused by different log output formats and encoding methods. It allows original numeric and coded fields to have matching standardized business meanings, and the semantic information generated by mapping can be synchronously recorded as evidence anchors as textual basis for defect diagnosis. For example, semantic mapping processing can convert original command encoding into standard textual semantics of the corresponding command type, and convert Boolean-type device capability fields into standard descriptions of device support states; that is, it can obtain command type information and namespace status information. For example, the namespace status information is an unassigned state.

[0077] The domain knowledge base can provide semantic mapping benchmarks for each key field, and at the same time provide judgment rules with multiple conditions and constraints. On the one hand, it completes the conversion of the original log field encoding to unified business semantics, eliminating ambiguity caused by inconsistent expression and encoding formats of multiple source log fields. On the other hand, it matches the corresponding judgment rules based on the semantic information such as commands, parameters, and device capabilities corresponding to the event, and outputs the expected status code specified by the protocol standard as an objective benchmark for the consistency comparison of the actual status code.

[0078] In other words, the domain knowledge base is a standardized knowledge base for the entire automated log defect analysis process. It includes constraint rules and semantic interpretations related to the storage protocol. Unlike test script assertions that only store the static expected values ​​of a single test case, it can independently provide a general protocol judgment standard, enabling multiple test cases with the same parameters to reuse the same verification logic. For example, the domain knowledge base can be internally divided into a semantic mapping sub-base and a rule storage sub-base. The semantic mapping sub-base stores the correspondence between various field codes and standard business semantics; the rule storage sub-base, i.e., the pre-defined rule database, stores verification rules containing multiple sets of semantic conditions and bound to corresponding expected status codes. The domain knowledge base supports dynamic updates and expansions, and can synchronously add semantic and verification rules corresponding to new commands and status codes generated by protocol iterations.

[0079] In addition to consistency checks on matching event pairs, the domain knowledge base can provide standardized textual explanations for diagnostic result objects and automatically generate descriptions related to defect analysis and optimization suggestions. Rules retrieved and semantic correspondences used in mappings within the domain knowledge base can be written into evidence anchors, preserving complete evidence for defect judgment and meeting audit and reproduction requirements. By configuring the domain knowledge base with relevant standards for storage protocols, semantic correspondences, and multi-condition verification rules, it is possible to uniformly complete the semantic standardization of log fields and automatically determine protocol compliance, eliminating the constraints of manual experience-based judgment and static use case expectations, and improving the universality and accuracy of storage log defect analysis.

[0080] In step 340, the preset rule database stores multiple rules with multi-dimensional judgment conditions. Each rule can use standardized business semantics as matching conditions and bind the expected status code in the corresponding scenario. This can provide a standardized judgment benchmark as specified by the protocol standard and avoid misjudgment problems caused by relying solely on matching raw numerical values.

[0081] Based on the semantic information obtained from the mapping, namely command type information and namespace state information, rules corresponding to these two can be searched from a pre-set rule database and used as target rules. In other words, target rules are the rules in the pre-set rule database that completely match both types of semantic information, and they serve as the basis for determining the results of the event analysis.

[0082] Based on the target rules, the expected status codes corresponding to the matching event pairs can be determined. For example, the target rules may have multiple conditions; different conditions correspond to different expected status codes. By searching for the conditions that the matching event pairs satisfy in the target rules, the corresponding expected status codes can be determined. Each expected status code has its own type; that is, the expected status code type and the expected status code can be obtained from the target rules. For example, the expected status code type can be SCT, and the expected status code can be 0.

[0083] In step 350, the type and actual status code can be determined based on the response event. The consistency verification conclusion is a standardized diagnostic content generated by comparing the expected status code with the actual status code. It includes the difference determination conclusion and supporting evidence, and can be directly used to output a structured diagnostic result object.

[0084] For example, the actual status code type is compared with the expected status code type to obtain the first comparison result, and the actual status code is compared with the expected status code to obtain the second comparison result. Combining the first and second comparison results, a consistency verification conclusion is generated. The consistency verification conclusion can indicate whether the two status codes and two types are consistent, thereby distinguishing between normal interaction events and abnormal interaction events with defects. The consistency verification conclusion can be output as a structured analysis result in the form of a report, and predefined data structure constraints can be imposed, such as field sets, types, mandatory rules, enumeration constraints, etc. Natural language fields can be generated using templates and constrained by the consistency verification conclusion and evidence anchors.

[0085] In this embodiment, after performing semantic mapping processing, the target rule is retrieved from the preset rule database. Based on the target rule, a consistency verification conclusion for matching event pairs is generated. This can shield the ambiguity of log field expressions, complete standardized protocol verification based on unified business semantics, and reduce the probability of rule matching errors and defect misjudgments caused by log format differences.

[0086] Let's take the comparison of expected and actual status codes as an example: The target rule sets status codes under different conditions. The conditions met by the matching event pair are determined, thus obtaining the expected status code. The expected status code is a standard execution result identifier defined within the target rule, serving as the judgment benchmark for consistency verification. It represents the compliant feedback result that the device should output in the current interaction scenario. The expected status code is used to compare with the actual status code. Differences in the comparison are fully written into the consistency verification conclusion and can also be included in the criteria for determining evidence anchor retention.

[0087] The actual status code is the execution result identifier actually returned by the storage device, extracted from the key fields of the response event. The expected status code is compared with the actual status code, and a consistency verification conclusion is obtained based on the comparison result. The consistency verification conclusion is a standardized judgment generated after comparing the expected and actual status codes, including whether there are differences between them and supporting evidence. Evidence may include semantic information of the request and response events.

[0088] In this embodiment, by retrieving the expected status code corresponding to the target rule and comparing it with the actual status code extracted from the response event, deterministic automated verification can be completed, objectively identifying the deviation between the device execution feedback and the specification requirements, and reducing subjective judgment errors caused by manual analysis.

[0089] In one implementation, the process of searching for target rules that match command type information and namespace status information according to a preset rule database includes: extracting device capability determination evidence from protocol interaction logs; wherein the device capability determination evidence represents the detection output data of device capability; obtaining command-specific parameters from key fields of the request event, and determining the parameter combination carried by the request event based on the command-specific parameters; determining whether the parameter combination matches the device capability according to the device capability determination evidence; if it matches, then continuing to execute the step of searching for target rules that match command type information and namespace status information; and / or, if it does not match, then selecting the target rule corresponding to the scenario that does not match the device capability according to the preset rule database, and obtaining the expected status code type and expected status code from the target rule.

[0090] Specifically, the device capability assessment evidence consists of the output data from device capability testing. This data characterizes the functions, formats, and protocol capabilities supported by the solid-state drive (SSD) hardware. Device capability assessment evidence can be derived from device identification and capability detection event records within the protocol interaction log. It serves as the basis for parameter validity judgment and target rule selection, and can act as an evidence anchor. Command-specific parameters are configuration fields attached to specific commands within the key fields of the request event. Different commands correspond to different command-specific parameters. Parameter combinations are the set of parameters composed of the command-specific parameters of the request event, fully representing all configuration conditions at the time of a single request event. They are used for adaptation and comparison with the device capability assessment evidence. In other words, device capability assessment evidence is first extracted from the protocol interaction log, and then parameter combinations are assembled based on the command-specific parameters within the request event.

[0091] Equipment capability assessment evidence represents the actual equipment capability. The parameter combination is matched against the actual equipment capability represented by the equipment capability assessment evidence, and different processing branches are initiated based on the matching result. For example, a preset equipment capability identifier associated with a specific parameter in the command within the parameter combination can be searched, and then compared with the capability identifier in the equipment capability assessment evidence. If the parameter combination matches the equipment capability, the target rule for a typical scenario is retrieved from the preset rule database, using command type information and namespace status information as conditions. If the parameter combination does not match the equipment capability, the target rule preset in the preset rule database for the equipment capability mismatch scenario is directly selected, and the expected status code type and expected status code corresponding to that rule are read.

[0092] The preset rule database stores multiple verification rules adapted to different business scenarios. These include rules for regular interaction scenarios as well as specialized rules for abnormal scenarios such as device capability mismatch. It provides the corresponding expected status code type and expected status code for different conditional branches. The target rule is a single verification rule selected from the preset rule database that adapts to all preconditions of the current interaction. It is used to output the expected status code type and expected status code required for consistency verification.

[0093] This embodiment takes into account the actual hardware capabilities of solid-state drives (SSDs) and no longer relies solely on command semantics to complete rule matching. It fully considers the objective situation that different SSDs have different capabilities, making the selected target rules more closely match the actual hardware conditions of the device under test, and ensuring that the benchmark for subsequent consistency verification is reasonable.

[0094] For example, device capability assessment evidence can include test results regarding whether the solid-state drive supports specific metadata formats and specific security functions. Parameter combinations can package specific parameters from multiple interrelated commands into a complete set, which is then used as a whole to match and assess the device capability assessment evidence. The target rules corresponding to device capability mismatch scenarios can pre-store the expected status code type and expected status code as specified in the protocol specification for that scenario. The matching results of parameter combinations and device capability assessment evidence can be synchronously stored in the evidence anchor point, fully recording the basis for branch jumps.

[0095] In addition to protocol interaction logs, evidence for determining device capabilities can also be imported from host-side logs. After time-series alignment, parameter combinations are matched and judged. These parameter combinations can be converted into standardized semantics after semantic mapping before being compared with the device capability determination evidence. Different sub-scenarios of device capability mismatches can correspond to different target rules within a pre-defined rule database. Matching or non-matching results obtained from branch judgments can be appended to the consistency verification conclusion, enriching the contextual information of defect analysis.

[0096] In this embodiment, by introducing device capability determination evidence, a preliminary matching judgment is performed on the parameter combination of the request event. The target rule in the preset rule database is selected according to whether the match is positive or negative. This can combine the actual hardware capability of the tested solid-state drive to select the verification benchmark, avoid the verification misjudgment caused by directly applying general protocol rules, and improve the adaptability and accuracy of automated log defect analysis.

[0097] In this embodiment, during automated testing, logs of the host-SSD hardware interaction layer, i.e., protocol interaction logs, are acquired. These logs can include multiple interaction events and completion events. An interaction event refers to a command issued by the host to the SSD, while a completion event refers to the SSD returning a processing result to the host after processing. In other words, there is a causal relationship between interaction events and completion events. Alignment processing can be performed on each interaction event and completion event to identify causally related interaction events and completion events as matching event pairs. For each matching event pair, fields are extracted from the interaction events and completion events to obtain key fields for the interaction events and completion events. Based on the key fields of the interaction events and completion events in the matching event pair, and using a preset rule database, the expected status code and its type can be obtained, thereby determining the consistency verification conclusion of the matching event pair. By aligning interaction events and completion events, a complete chain of evidence is formed, avoiding evidence omissions and improving the accuracy and efficiency of event analysis.

[0098] Figure 4 This is a flowchart illustrating a log-based event analysis method, such as... Figure 4 As shown, a log-based event analysis method according to one embodiment of this application may include: Step 410: Obtain the test framework log. For each assertion event and each response event in the test framework log, if the command identifier of the assertion event is consistent with the command identifier of the response event, and the difference between the timestamp of the assertion event and the timestamp of the response event is less than a preset threshold, then the assertion event and the response event are determined to constitute a matching event pair. Step 420: Extract the expected status code type and expected status code from the key fields of the assertion event, and extract the actual status code type and actual status code from the key fields of the response event; Step 430: Compare the expected status code type with the actual status code type, and compare the expected status code with the actual status code to generate a consistency verification conclusion. Step 440: For each key field of the matched event pair, generate a corresponding evidence anchor; wherein the evidence anchor includes at least a source identifier, a location identifier, and a content consistency identifier generated based on the event; Step 450: Generate and output structured analysis results based on the consistency verification conclusions. The structured analysis results include the consistency verification conclusions and references to the evidence anchors corresponding to each event in the matching event pair.

[0099] Steps 440 and 450 have been described in detail above and will not be repeated here. Steps 410-430 will be described in detail below.

[0100] In step 410, the test framework log belongs to one type of multi-source log. It is a log record generated during the operation of the automated test framework, which can retain business information such as test execution flow, test case assertion markers, command identifiers, timestamps, and expected execution results. It can serve as a data source for building matching event pairs. The test framework log carries pre-set verification information at the test case level, which can provide a ready-made expected benchmark for consistency verification.

[0101] The test framework log includes multiple assertion events and response events. Assertion events are a type of event record generated internally by the test framework log. They record verified command identifiers and can also carry information related to the expected state predefined in the test case, used to mark the verification behavior of a command execution result in the test process. Response events correspond to events where the storage device returns execution results, containing the actual output status code and command identifier of the device, representing the solid-state drive's actual response to the command issued by the host. That is, assertion events can be used as interaction events, and response events can be used as completion events.

[0102] Command identifiers are unique identifiers used to identify individual commands and establish causal relationships between assertion and response events. Both assertion and response events can contain command identifiers. Matching event pairs are combinations of assertion and response events that have a validation correspondence. If the command identifier of an assertion event matches the command identifier of a response event, then the assertion and response events constitute a matching event pair.

[0103] Assertion events and response events can also contain timestamps. A preset threshold is set, which is a pre-defined standard for judging timing deviations. This threshold is used to limit the acceptable range of time differences between assertion events and response events, filter event combinations with excessively large timing intervals or no business correspondence, and avoid incorrect pairings caused by asynchronous log printing. If the difference between the timestamp of the assertion event and the timestamp of the response event is less than the preset threshold, then the assertion event and response event can be determined to constitute a matching event pair.

[0104] This embodiment can bind assertion events and response events with a verification correspondence into matching event pairs based on the dual conditions of command identifier consistency and timestamp difference meeting a preset threshold.

[0105] After the assertion event and response event are paired, the pairing criteria, including command identifiers and time differences, can be completely stored in the evidence anchor to meet the requirements of audit reproducibility. Assertion events or response events that do not simultaneously meet both matching conditions can be marked and retained for subsequent manual review.

[0106] In this embodiment, by using dual constraints of command identifier and timing difference, assertion events and response events in the test framework logs are paired to generate matching event pairs. This allows for the direct reuse of built-in verification events in the test framework, reducing the overhead of rule derivation and computation, and adapting to business scenarios requiring rapid analysis of automated test logs.

[0107] In step 420, the matching event pair may include an assertion event and a response event. The assertion event includes the verification benchmark pre-defined by the test case, which can directly provide the expected status code type and expected status code, eliminating the step of deriving the expected result through a pre-defined rule database. The key fields extracted from the assertion event will participate in the generation of subsequent evidence anchors, retaining the verification basis at the test case level. The response event corresponds to the event that returns the execution result after the solid-state drive executes the command, including the execution receipt actually output by the device. The key fields of the response event carry the actual status code type and actual status code returned by the device, which is the actual object used for comparison during the consistency verification process.

[0108] In other words, fields such as expected status code type and expected status code can be extracted from assertion events as key fields, and fields such as actual status code type and actual status code can be extracted from response events as key fields.

[0109] In step 430, the expected status code type and expected status code are extracted from the assertion event within the matching event pair, and the actual status code type and actual status code are extracted from the response event. The status code type and status code are compared respectively, and a consistency verification conclusion is generated based on the results of the two comparisons.

[0110] The expected status code type is compared with the actual status code type to obtain the first comparison result, and the expected status code is compared with the actual status code to obtain the second comparison result. Combining the first and second comparison results, a consistency verification conclusion is generated.

[0111] The extracted expected status code type, expected status code, actual status code type, and actual status code, in addition to being used for comparison, can be added to the structured analysis results for easy viewing of the original comparison data later. The consistency verification conclusion, besides recording whether a match is found, can also include specific details in the difference field to assist in subsequent defect localization. When inconsistencies arise between the status code type comparison result and the status code comparison result, this special case can be marked in the consistency verification conclusion for subsequent manual review.

[0112] In this embodiment, by extracting the expected status code type and expected status code of the assertion event and the actual status code type and actual status code of the response event respectively, and comparing them item by item to generate a consistency verification conclusion, the assertion preset benchmark of the test framework can be directly reused to complete the verification, eliminating the rule base retrieval step and improving the processing efficiency of automated test log defect analysis.

[0113] In this embodiment, during automated testing, logs of the host-SSD hardware interaction layer, i.e., protocol interaction logs, are acquired. These logs can include multiple interaction events and completion events. An interaction event refers to a command issued by the host to the SSD, while a completion event refers to the SSD returning a processing result to the host after processing. In other words, there is a causal relationship between interaction events and completion events. Alignment processing can be performed on each interaction event and completion event to identify causally related interaction events and completion events as matching event pairs. For each matching event pair, fields are extracted from the interaction events and completion events. Based on a preset rule database, the desired status code can be obtained, thereby determining the event analysis result of the matching event pair. By aligning interaction events and completion events, a complete chain of evidence is formed, avoiding evidence omissions and improving the accuracy and efficiency of event analysis.

[0114] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0115] It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0116] Description of apparatus and devices in embodiments of this application Reference Figure 5 , Figure 5 The schematic diagram shows the structure of a log-based event analysis device 500 provided in an embodiment of this application. The log-based event analysis device 500 includes: The event determination module 501 is used to obtain the protocol interaction log of the solid-state drive and determine the matching event pairs from the protocol interaction log; The event verification module 502 is used to extract the key fields of each event in the matching event pair, and to perform consistency verification on the matching event pair based on the key fields of each event in the matching event pair, and generate a consistency verification conclusion. The evidence generation module 503 is used to generate corresponding evidence anchors for each key field of the event in the matching event pair; wherein the evidence anchors include at least a source identifier, a location identifier, and a content consistency identifier generated based on the event; The result output module 504 is used to generate and output structured analysis results based on the consistency verification conclusion. The structured analysis results include the consistency verification conclusion and references to the evidence anchors corresponding to each event in the matching event pair. The description field of the structured analysis results is composed of the consistency verification conclusion and the referenced evidence anchors.

[0117] In one example, the protocol interaction log is the request event log on the host side; the event determination module 501 is specifically used for: For each request event and each response event in the request event log, if the command identifier of the request event is consistent with the command identifier of the response event, and the difference between the timestamp of the request event and the timestamp of the response event is less than a preset threshold, then the request event and the response event are determined to constitute a matching event pair.

[0118] In one example, the matching event pair includes a request event and a response event; the event validation module 502 is specifically used for: Extract the opcode, namespace identifier, and command-specific parameters from the key fields of the request event; extract the actual status code type and actual status code from the key fields of the response event. Semantic mapping is performed on opcodes, namespace identifiers, and command-specific parameters to obtain command type information and namespace status information; Based on the preset rule database, search for target rules that match the command type information and namespace status information, and obtain the expected status code type and expected status code from the target rules; The actual status code type is compared with the expected status code type, and the actual status code is compared with the expected status code to generate a consistency verification conclusion.

[0119] In one example, event validation module 502 is specifically used for: Extract device capability determination evidence from the protocol interaction log; wherein, the device capability determination evidence represents the detection output data of the device capability; Retrieve command-specific parameters from the key fields of the request event, and determine the combination of parameters carried by the request event based on the command-specific parameters; Based on the evidence of equipment capability assessment, determine whether the parameter combination matches the equipment capability; If a match is found, the process continues to find the target rule that matches the command type information and namespace status information; and / or, If there is no match, the target rule corresponding to the scenario that does not match the device capability is selected according to the preset rule database, and the expected status code type and expected status code are obtained from the target rule.

[0120] In one example, the protocol interaction log is a test framework log, and the assertion events in the test framework log record verified command identifiers; the event determination module 501 is specifically used for: For each assertion event and each response event in the test framework log, if the command identifier of the assertion event is consistent with the command identifier of the response event, and the difference between the timestamp of the assertion event and the timestamp of the response event is less than a preset threshold, then the assertion event and the response event are determined to constitute a matching event pair.

[0121] In one example, the matching event pair includes an assertion event and a response event; the event validation module 502 is specifically used for: Extract the expected status code type and expected status code from the key fields of the assertion event, and extract the actual status code type and actual status code from the key fields of the response event; The expected status code type is compared with the actual status code type, and the expected status code is compared with the actual status code to generate a consistency verification conclusion.

[0122] In one example, the event determination module 501 is specifically used for: Centered on abnormal events, the events in the protocol interaction log are sliced ​​according to a preset time window to obtain a set of candidate evidence events; Identify matching event pairs from the set of candidate evidence events.

[0123] In one example, it also includes: The format parsing module is used to perform format parsing on the protocol interaction log before determining matching event pairs from the protocol interaction log, and to determine all events in the protocol interaction log. The anomaly identification module is used to identify events containing preset anomaly identifiers for each event in the protocol interaction log and mark them as anomaly events, and retain the anomaly events and their associated events within a preset time window.

[0124] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0125] 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 merely 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. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0126] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 of this embodiment includes: at least one processor 601 ( Figure 6 (Only one is shown in the diagram), memory 602, and computer program 603 stored in said memory 602 and executable on said at least one processor 601, wherein said processor 601 executes said computer program 603 to implement the steps in any of the above-described log-based event analysis method embodiments.

[0127] Electronic device 600 can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. This electronic device may include, but is not limited to, a processor 601 and a memory 602. Those skilled in the art will understand that... Figure 6 This is merely an example of electronic device 600 and does not constitute a limitation on electronic device 600. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0128] The processor 601 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0129] In some embodiments, the memory 602 may be an internal storage unit of the electronic device 600, such as a hard disk or memory of the electronic device 600. In other embodiments, the memory 602 may be an external storage device of the electronic device 600, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 600. Furthermore, the memory 602 may include both internal and external storage units of the electronic device 600. The memory 602 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 602 can also be used to temporarily store data that has been output or will be output.

[0130] This application also provides an electronic device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0131] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0132] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the above-described method embodiments.

[0133] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying the computer program code to a photographic device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0134] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0135] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

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

[0138] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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. Such 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 this application, and should all be included within the protection scope of this application.

Claims

1. A log-based event analysis method, characterized by, include: Obtain the protocol interaction log of the solid-state drive and determine the matching event pairs from the protocol interaction log; Extract the key fields of each event in the matching event pair, and perform a consistency check on the matching event pair based on the key fields of each event in the matching event pair to generate a consistency check conclusion; For each key field of the matched event pair, a corresponding evidence anchor is generated; wherein, the evidence anchor includes at least a source identifier, a location identifier, and a content consistency identifier generated based on the event; A structured analysis result is generated and output based on the consistency verification conclusion. The structured analysis result includes the consistency verification conclusion and a reference to the evidence anchor point corresponding to each event in the matching event pair.

2. The method of claim 1, wherein, The protocol interaction log is a request event log on the host side; determining matching event pairs from the protocol interaction log includes: For each request event and each response event in the request event log, if the command identifier of the request event is consistent with the command identifier of the response event, and the difference between the timestamp of the request event and the timestamp of the response event is less than a preset threshold, then the request event and the response event are determined to constitute the matching event pair.

3. The method according to claim 2, characterized in that, The matching event pair includes a request event and a response event; The process of extracting key fields from each event in the matching event pair and performing a consistency check on the matching event pair based on the key fields of each event in the matching event pair to generate a consistency check conclusion includes: Extract the opcode, namespace identifier, and command-specific parameters from the key fields of the request event; extract the actual status code type and actual status code from the key fields of the response event. Semantic mapping is performed on the opcode, the namespace identifier, and the command-specific parameters to obtain command type information and namespace status information; According to the preset rule database, find the target rule that matches the command type information and the namespace status information, and obtain the expected status code type and expected status code from the target rule; The actual status code type is compared with the expected status code type, and the actual status code is compared with the expected status code to generate the consistency verification conclusion.

4. The method according to claim 3, characterized in that, The step of searching for target rules that match the command type information and the namespace status information according to a preset rule database includes: Extract device capability determination evidence from the protocol interaction log; wherein, the device capability determination evidence represents the detection output data of the device capability; Obtain command-specific parameters from the key fields of the request event, and determine the parameter combination carried by the request event based on the command-specific parameters; Based on the equipment capability assessment evidence, determine whether the parameter combination matches the equipment capability; If a match is found, the step of finding the target rule that matches the command type information and the namespace status information continues; and / or, If there is no match, then according to the preset rule database, select the target rule corresponding to the scenario that does not match the device capabilities, and obtain the expected status code type and expected status code from the target rule.

5. The method according to claim 1, characterized in that, The protocol interaction log is a test framework log, and the assertion event record in the test framework log contains verified command identifiers. Determining the matching event pair from the protocol interaction log includes: For each assertion event and each response event in the test framework log, if the command identifier of the assertion event is consistent with the command identifier of the response event, and the difference between the timestamp of the assertion event and the timestamp of the response event is less than a preset threshold, then the assertion event and the response event are determined to constitute the matching event pair.

6. The method according to claim 5, characterized in that, The matching event pair includes an assertion event and a response event; The process of extracting key fields from each event in the matching event pair and performing a consistency check on the matching event pair based on the key fields of each event in the matching event pair to generate a consistency check conclusion includes: Extract the expected status code type and expected status code from the key fields of the assertion event, and extract the actual status code type and actual status code from the key fields of the response event; The expected status code type is compared with the actual status code type, and the expected status code is compared with the actual status code to generate the consistency verification conclusion.

7. The method according to any one of claims 1-6, characterized in that, Determining the matching event pair from the protocol interaction log includes: Centered on abnormal events, the events in the protocol interaction log are sliced ​​according to a preset time window to obtain a set of candidate evidence events; The matching event pair is determined from the set of candidate evidence events.

8. The method according to claim 7, characterized in that, Before determining the matching event pair from the protocol interaction log, the process includes: The protocol interaction log is parsed to determine all events in the protocol interaction log. For each event in the protocol interaction log, identify events containing preset abnormal identifiers and mark them as abnormal events, and retain the abnormal events and their associated events within the preset time window.

9. An electronic device, characterized in that, include: At least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor, when executing the computer program, implements the steps of the method as claimed in any one of claims 1-8.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the method described in any one of claims 1-8.

Images