Storage service fault analysis method and device, electronic equipment and medium

Abstract

This application provides a storage service fault analysis method, apparatus, electronic device, and medium, belonging to the field of artificial intelligence technology, and applicable to the financial and medical fields. The method includes: acquiring fault information and a device topology diagram of the storage device; locating associated devices connected to the storage device based on the device topology diagram; performing device relationship analysis on the storage device and associated devices to obtain target device relationship data; performing similarity retrieval in a preset device relationship database based on the target device relationship data to obtain reference device relationship data; associating the reference device relationship data with reference fault causes; acquiring the reference fault causes associated with the reference device relationship data; and performing fault analysis using a pre-trained language model based on the reference fault causes and fault information. This application embodiment can improve the accuracy of storage service fault analysis.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, applicable to the financial and medical fields, and particularly to a storage service fault analysis method and apparatus, electronic device and medium. Background Technology

[0002] Storage services refer to cloud or on-premises services that provide persistent storage, management, and access capabilities for data. Storage service failures can lead to data loss or access interruptions, directly impacting business operations. Operations and maintenance personnel need to take timely and targeted measures to remediate the failures, minimize business downtime, and ensure the storage service is restored as quickly as possible.

[0003] In related technologies, fault signals are analyzed based on preset fault assessment rules. For example, if the access latency to the RBD volume, a block storage interface provided by the Ceph distributed storage system, exceeds a set threshold, and the placement group (PG) corresponding to this storage interface has inconsistency alarms, the fault assessment rules determine that the cause of the fault may be a data repair conflict. However, this method relies on static fault assessment rules, and the accuracy of fault analysis needs to be improved. Therefore, how to improve the accuracy of storage service fault analysis has become an urgent problem to be solved. Summary of the Invention

[0004] To address the technical problem of how to improve the accuracy of storage service fault analysis, the main objective of this application is to propose a storage service fault analysis method, apparatus, electronic device, and medium, which aims to improve the accuracy of storage service fault analysis.

[0005] To achieve the above objectives, a first aspect of this application proposes a storage service fault analysis method, the method comprising: Obtain fault information and device topology diagram of storage devices; Based on the device topology diagram, locate the associated devices connected to the storage devices; Perform device relationship analysis on storage devices and associated devices to obtain target device relationship data; Based on the target device relationship data, similarity retrieval is performed in a pre-set device relationship database to obtain reference device relationship data; among which, the reference device relationship data is stored in association with reference fault causes. Obtain the reference fault cause associated with the reference device relationship data, and perform fault analysis based on the reference fault cause and fault information using a pre-trained language model.

[0006] In some embodiments, device relationship analysis is performed on the storage device and associated devices to obtain target device relationship data, including: Obtain interaction status data between the storage device and associated devices; Based on the interaction state data, a dependency analysis is performed on the storage device and associated device to obtain dependency data. Based on the dependency data, a target device dependency tree is generated as the target device relationship data.

[0007] In some embodiments, the device relationship database includes a candidate device dependency tree; based on the target device relationship data, similarity retrieval is performed in a preset device relationship database to obtain reference device relationship data, including: Calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree to obtain the target similarity; Based on target similarity, a reference device dependency tree is determined from the candidate device dependency tree, which serves as the reference device relationship data.

[0008] In some embodiments, the kernel similarity between the target device dependency tree and the candidate device dependency tree is calculated to obtain the target similarity, including: Retrieve the storage device attributes of the storage device and the associated device attributes of the associated device; Generate node labels for the target device dependency tree based on storage device attributes and associated device attributes; Based on the node labels, calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree to obtain the target similarity.

[0009] In some embodiments, candidate device dependency trees are stored in association with candidate fault description text; the target similarity is obtained by calculating the kernel similarity between the target device dependency tree and the candidate device dependency trees, including: Calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree to obtain the first similarity score; Generate the current fault description text based on the target device dependency tree and fault information; Obtain candidate fault description texts associated with the candidate device dependency tree, calculate the semantic similarity between the current fault description text and the candidate fault description texts, and obtain the second similarity. The first and second similarity scores are fused to obtain the target similarity score.

[0010] In some embodiments, device relationship analysis is performed on the storage device and associated devices to obtain target device relationship data, including: Retrieve device logs from associated devices; Based on device logs and preset anomaly detection rules, identify abnormal devices from the associated devices; Device relationship analysis is performed on storage devices and abnormal devices to obtain target device relationship data.

[0011] In some embodiments, fault analysis is performed using a pre-trained language model based on reference fault causes and fault information, including: Based on the fault information, the storage device is analyzed using a language model to determine the primary cause of the fault. Based on the device logs, a language model is used to analyze the faulty device and determine the second cause of the fault. Based on the reference fault cause, the first fault cause, and the second fault cause, the target fault cause is generated using a language model.

[0012] To achieve the above objectives, a second aspect of this application provides a storage service fault analysis apparatus, the apparatus comprising: The data acquisition module is used to acquire fault information and device topology diagrams of storage devices; The associated device lookup module is used to find associated devices connected to the storage device based on the device topology diagram; The device relationship analysis module is used to perform device relationship analysis on storage devices and associated devices to obtain target device relationship data; The similarity recall module is used to perform similarity recall in a preset device relationship database based on the target device relationship data to obtain reference device relationship data; wherein, the reference device relationship data is stored in association with the reference fault cause. The fault analysis module is used to obtain reference fault causes associated with the reference equipment relationship data and perform fault analysis based on the reference fault causes and fault information using a pre-trained language model.

[0013] To achieve the above objectives, a third aspect of the present application provides an electronic device, the electronic device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method described in the first aspect.

[0014] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of the first aspect described above.

[0015] The storage service fault analysis method, apparatus, electronic device, and medium proposed in this application first acquire fault information and a device topology diagram of the storage device to determine the fault manifestation of the storage device and the connection layout between devices. Based on the device topology diagram, related devices are identified, taking into account the potential impact of surrounding devices on the storage device, thus broadening the scope of fault analysis. Device relationship analysis is performed on the storage device and related devices to obtain target device relationship data, deeply exploring the intrinsic connections between devices. Based on the target device relationship data, similarity retrieval is performed in a pre-set device relationship database to obtain reference device relationship data, thereby obtaining reference fault causes associated with the reference device relationship data. Since similar device relationships may have similar fault causes, the reference fault causes associated with the reference device relationship data provide a reliable basis for subsequent language model fault analysis. By combining the reference fault causes and fault information with a pre-trained language model for fault analysis, the accuracy of storage service fault analysis can be improved. Attached Figure Description

[0016] Figure 1 This is a flowchart of the storage service fault analysis method provided in the embodiments of this application; Figure 2 yes Figure 1 The flowchart of step S103 in the process; Figure 3 yes Figure 2 Another flowchart of step S103 in the process; Figure 4 yes Figure 1 The flowchart of step S104 in the process; Figure 5 yes Figure 4 The flowchart of step S401 in the text; Figure 6 yes Figure 4 Another flowchart of step S401 in the process; Figure 7 yes Figure 1 The flowchart of step S105 in the process; Figure 8 This is a schematic diagram of the structure of the storage service fault analysis device provided in the embodiments of this application; Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0018] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] First, let's analyze some of the terms used in this application: Artificial intelligence (AI) is a new branch of computer science that studies, develops, and applies theories, methods, technologies, and systems to simulate, extend, and expand human intelligence. It aims to understand the essence of intelligence and produce intelligent machines that can react in a way similar to human intelligence. Research in this field includes robotics, speech recognition, image recognition, natural language processing, and expert systems. AI can simulate the information processes of human consciousness and thought. Furthermore, AI utilizes digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceiving the environment, acquiring knowledge, and using that knowledge to achieve optimal results.

[0021] This application provides a storage service fault analysis method, apparatus, electronic device, and medium, aiming to improve the accuracy of storage service fault analysis.

[0022] The storage service fault analysis method, apparatus, electronic device, and medium provided in this application are specifically described through the following embodiments. First, the storage service fault analysis method in this application is described.

[0023] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0024] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0025] The storage service fault analysis method provided in this application relates to the field of artificial intelligence technology. This storage service fault analysis method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the storage service fault analysis method, but is not limited to the above forms.

[0026] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0027] Figure 1 This is an optional flowchart of the storage service fault analysis method provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S105.

[0028] Step S101: Obtain fault information and device topology diagram of the storage device; Step S102: Based on the device topology diagram, locate the associated devices connected to the storage device; Step S103: Perform device relationship analysis on the storage device and associated devices to obtain target device relationship data; Step S104: Based on the target device relationship data, perform similarity retrieval in the preset device relationship database to obtain reference device relationship data; wherein, the reference device relationship data is stored in association with the reference fault cause. Step S105: Obtain the reference fault cause associated with the reference device relationship data storage, and perform fault analysis based on the reference fault cause and fault information using a pre-trained language model.

[0029] In some embodiments, step S101 specifically refers to various relevant information exhibited when a storage device malfunctions, such as abnormal states, error codes, and abnormal performance indicators reflecting the device's failure status. A device topology diagram is a graphical representation used to show the connection relationships and layout structure between the storage device and other devices in the storage system, clearly illustrating the physical or logical connections between the devices. It should be noted that storage systems are typically multi-tiered storage architectures; therefore, the device topology diagram includes the faulty storage device, as well as storage devices, network devices, host devices, etc., directly or indirectly connected to the faulty storage device at various levels.

[0030] In some embodiments, step S102 specifically refers to other devices that have a direct or indirect connection with the storage device, as found through the device topology map, including but not limited to network switches, routers, other storage devices, or servers.

[0031] In some embodiments, step S103 specifically refers to analyzing the connection methods, data interaction patterns, and dependencies between storage devices and associated devices to obtain target device relationship data that reflects their dependencies and interactions. Understandably, in modern storage systems, network devices, faulty devices, and storage devices at various levels work collaboratively. Storage device failures are often not isolated events but complex problems caused by the collaborative action of multiple devices. For example, the connection between storage devices and network devices is a critical path for data transmission. When network devices experience issues such as network link interruptions or excessive network latency, data access requests from storage devices may not be responded to in a timely manner or data may not be transmitted normally. This can lead to performance degradation, data loss, or inaccessibility due to prolonged waiting for data transmission. Furthermore, data in a storage system migrates and is accessed between storage devices at different levels. When a storage device at one level experiences performance degradation or read / write errors, it may trigger abnormal access to other storage devices. Therefore, the analysis of storage device failures cannot be limited to the faulty device itself but needs to comprehensively consider the collaborative impact between the associated multiple devices. By analyzing the device topology diagram, identifying the related devices that are directly or indirectly connected to the faulty storage device, and conducting a comprehensive inspection and analysis of the status of these devices, the cause of the fault can be accurately located, and effective repair measures can be taken.

[0032] In step S104 of some embodiments, specifically, the device relationship database is a pre-built database used to store relationship information and fault causes between devices. The relationship information describes the connection methods, dependencies, data flow paths, etc., between devices. Relationship information is stored in association with fault causes; that is, each piece of relationship information corresponds to one or more possible fault causes, which are derived from historical fault summaries. Understandably, in the device relationship database, the relationship information serves as an index for fault causes. When a fault is detected in a device, the aforementioned relationship information is used as a candidate. By comparing the target device relationship data with the candidate information, similar relationship information can be quickly found, and the corresponding fault cause can be obtained as a reference fault cause. Understandably, since storage device faults may be complex problems caused by the collaborative action of multiple devices, similar device relationships may have similar fault causes. Therefore, using reference device relationship data to obtain reference fault causes leverages historical experience, providing a validated set of candidate causes for subsequent analysis and reducing the uncertainty of reasoning from scratch using the language model.

[0033] In some embodiments, step S105 specifically refers to a pre-trained language model, which is a natural language processing model trained on a large amount of data, capable of interpreting and reasoning about reference fault causes and fault information to determine the fault cause.

[0034] Steps S101 to S105, as illustrated in this embodiment, firstly, fault information and a device topology diagram of the storage device are obtained to determine the fault manifestation of the storage device and the connection layout between devices. Related devices are located based on the device topology diagram, taking into account the potential impact of surrounding devices on the storage device, thus broadening the scope of fault analysis. Device relationship analysis is performed on the storage device and related devices to obtain target device relationship data, deeply exploring the intrinsic connections between devices. Based on the target device relationship data, similarity retrieval is performed in a pre-set device relationship database to obtain reference device relationship data, thereby obtaining reference fault causes associated with the reference device relationship data. Since similar device relationships may have similar fault causes, the reference fault causes associated with the reference device relationship data provide a reliable basis for subsequent language model fault analysis. By combining the reference fault causes and fault information with a pre-trained language model for fault analysis, the accuracy of storage service fault analysis can be improved.

[0035] In step S101 of some embodiments, specifically, the fault information and device topology diagram of the storage device can be obtained by the monitoring system actively pushing information. For example, when the monitoring system detects an abnormality in the storage device, it automatically sends the relevant fault logs, error codes, and device topology information to the analysis system; or the fault information and device topology diagram of the storage device can be obtained by manual input. For example, after discovering a fault, the maintenance personnel manually enter the fault phenomena, device status, and topology diagram observed on-site into the system; it is not limited to this.

[0036] In step S102 of some embodiments, specifically, the associated devices connected to the storage device can be found by parsing the connection relationships in the device topology graph. For example, the network devices, host devices, etc. directly connected to the faulty storage device can be determined by using the node and edge information in the topology graph. Alternatively, the storage device configuration file can be queried to determine the associated devices connected to the storage device. For example, the connected devices can be found based on the connection parameters recorded in the storage device configuration file, such as IP address and port number. This is not limited to this.

[0037] Please see Figure 2 In some embodiments, step S103 includes, but is not limited to, steps S201 to S203: Step S201: Obtain the device logs of the associated devices; Step S202: Based on the device logs and preset anomaly determination rules, identify the abnormal device from the associated devices; Step S203: Perform device relationship analysis on storage devices and abnormal devices to obtain target device relationship data.

[0038] In some embodiments, step S201 specifically refers to the device log, which is a series of events and operation information automatically recorded by the associated device during operation. It includes various state changes, operation records, error information, etc. of the associated device and can reflect the operating status of the device at different points in time.

[0039] In some embodiments, step S202 specifically involves an anomaly determination rule, which is a pre-defined criterion for determining whether a device is in an abnormal state. This rule is based on the characteristics of the device during normal operation and potential anomalies. Information from the device log is compared with the rule to determine if the device is abnormal. Understandably, a faulty storage device refers to a device that has experienced a clear functional failure or severe performance degradation and requires diagnosis. An abnormal device, on the other hand, refers to a device that deviates from the normal baseline but has not necessarily resulted in functional loss. Related devices that deviate from the performance baseline range but have not triggered alarm conditions can be considered abnormal devices, while storage devices that trigger alarm conditions can be considered faulty devices.

[0040] In some embodiments, step S203 can be performed by parsing the connection relationship between the storage device and the abnormal device based on the device topology diagram to obtain the device communication link as the target device relationship data; or the device dependency tree can be obtained by parsing the dependency relationship between the storage device and the abnormal device as the target device relationship data; it is not limited to this.

[0041] Steps S201 to S203 as shown in the embodiments of this application identify abnormal devices from associated devices based on device logs and preset anomaly judgment rules. This can accurately filter out abnormal associated devices that may affect storage device failures, without having to perform indiscriminate analysis on all associated devices. This improves the targeting and efficiency of the analysis, making the target device relationship data more relevant and reliable, and providing a more accurate foundation for subsequent fault analysis.

[0042] Please see Figure 3 In some embodiments, step S103 may include, but is not limited to, steps S301 to S303: Step S301: Obtain the interaction status data between the storage device and the associated device; Step S302: Based on the interaction state data, perform dependency analysis on the storage device and associated device to obtain dependency data; Step S303: Generate a target device dependency tree as target device relationship data based on the dependency relationship data.

[0043] In some embodiments, step S301 specifically refers to various state information between the storage device and associated devices during data transmission, command interaction, etc., such as data transmission direction and interface call relationships. Interaction state data between the storage device and the faulty device can be obtained for dependency analysis to obtain dependency data.

[0044] In step S302 of some embodiments, specifically, based on the interaction state data, the interdependence between the storage device and associated devices is analyzed, including the degree and direction of dependence between the devices in terms of functional implementation, data processing, etc., to determine their inherent connections. Dependency analysis helps to understand the mutual influence between devices and provides a basis for fault diagnosis and system optimization.

[0045] In some embodiments, step S303 specifically refers to the target device dependency tree as a data model that uses a graphical tree structure to represent the dependency relationship between storage devices and associated devices. The nodes in the tree represent devices, and the connections between nodes represent the dependency relationship between devices. This model can display the hierarchical architecture of the storage system and the complex dependency hierarchy between devices.

[0046] For example, in financial applications, a trading server sends trading data to a storage device (write operation), and the storage device returns a success or failure status to the trading server (read operation). The database server performs data backup and recovery operations through the storage interface. Based on this, it is determined that the trading server relies on the storage device for persistent storage of trading data; the trading server depends on the storage device. The database server relies on the storage device for data backup and recovery; the database server depends on the storage device. The network switch provides a data transmission channel for the trading server and the storage device; the trading server and the storage device depend on the network switch. Therefore, a target device dependency tree is constructed with the network switch as the root node, the storage device as a subordinate node of the network switch, and the trading server and database server as subordinate nodes of the storage device.

[0047] For example, in medical applications, medical imaging equipment sends image data to storage devices (write operation), and the storage device returns a success or failure status to the medical imaging equipment (read operation); the electronic medical record system reads patient medical record data from the storage device (read operation). Medical imaging equipment and the electronic medical record system depend on the storage device. Therefore, a target device dependency tree is constructed with the storage device as the root node, and the medical imaging equipment and the electronic medical record system as subordinate nodes of the storage device.

[0048] Steps S301 to S303 as shown in the embodiments of this application obtain the interaction status data between the storage device and the associated device, and perform dependency analysis based on the interaction status data to obtain dependency data. The dependency tree of the target device is generated based on the dependency data as the target device relationship data. The dependency relationship between the devices is presented in an intuitive tree structure, which can show the hierarchical architecture of the storage system and the complex dependency hierarchy between devices. This helps to discover potential fault impact paths and improve the efficiency and accuracy of subsequent fault analysis.

[0049] Please see Figure 4 In some embodiments, step S104 includes, but is not limited to, steps S401 to S402: Step S401: Calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree to obtain the target similarity. Step S402: Based on the target similarity, determine the reference device dependency tree from the candidate device dependency tree, and use it as reference device relationship data.

[0050] In step S401 of some embodiments, specifically, device dependency trees are used to represent device relationship data. The device relationship database stores multiple tree-structured data representing the dependencies between various types of devices, i.e., candidate device dependency trees. Each candidate device dependency tree corresponds to a specific set of device connections and dependency logic, and is associated with a corresponding reference fault cause. Similarly, the target device dependency tree can intuitively and structurally present the device connections and dependency logic between the currently faulty storage device and its associated devices. Tree kernel similarity is a similarity calculation metric for tree-structured data. It quantifies the degree of similarity between two device dependency trees by measuring the degree of matching of features such as node structure, node attributes, hierarchical relationships, and connection methods.

[0051] In step S402 of some embodiments, specifically, the reference device dependency tree is the tree structure data with the highest similarity to the target device dependency tree or exceeding the similarity threshold selected from the candidate device dependency trees in the device relation database. The corresponding associated fault causes can be used as a reference for fault analysis.

[0052] Steps S401 to S402 as shown in the embodiments of this application calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree, and compare the similarity between the two in the dimensions of tree structure nodes, levels, and connections to obtain the target similarity that can quantitatively characterize the similarity between the current device relationship and the relationship information in the database. This improves the accuracy of the recalled reference device relationship data and provides a more targeted and reliable reference for subsequent fault analysis combined with pre-trained language models, thereby improving the accuracy of storage service fault analysis.

[0053] Please see Figure 5 In some embodiments, step S401 includes, but is not limited to, steps S501 to S503: Step S501: Obtain the storage device attributes of the storage device and the associated device attributes of the associated device; Step S502: Generate node labels for the target device dependency tree based on the storage device attributes and associated device attributes; Step S503: Calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree based on the node labels to obtain the target similarity.

[0054] In some embodiments, step S501 specifically refers to the inherent characteristics and operating status parameters of the faulty storage device itself, such as device model, storage capacity, firmware version, current load rate, interface type, runtime, and other information directly related to the device. Associated device attributes refer to the inherent characteristics and operating status parameters of associated devices that are connected to the faulty storage device, such as the associated device's device type, functional positioning, connection bandwidth with the storage device, data interaction frequency, and operating status. It is easy to understand that each device corresponds to a node in the device dependency tree; therefore, it is necessary to determine the node label of the node corresponding to the storage device based on the storage device attributes, and to determine the node label of the node corresponding to the associated device based on the associated device attributes.

[0055] In step S502 of some embodiments, specifically, node labels refer to the marking information used to identify the features of each node in the target device dependency tree. Each node label corresponds to a device node in a device dependency tree. The label content integrates the attribute information of the corresponding device and can intuitively reflect the core features of the device represented by the node. It is the key basis for subsequent tree kernel similarity calculation.

[0056] In step S503 of some embodiments, specifically, the node labels in the target device dependency tree and the candidate device dependency tree are compared to determine which nodes in the two trees match. The paths from the matching nodes in the two trees to their root nodes are compared to evaluate the path similarity. Based on the results of node matching and path matching, the kernel similarity of the two trees is calculated.

[0057] Taking a financial application scenario as an example, the target device dependency tree T1 includes: root node: storage device (label: device type = storage, function = data persistence, performance metric = read / write speed 100MB / s), child node 1: transaction server (label: device type = server, function = transaction processing, performance metric = CPU load 40%), child node 2: network switch (label: device type = network device, function = data transmission, performance metric = bandwidth utilization 30%). The candidate device dependency tree T2 includes: root node: storage device (label: device type = storage, function = data persistence, performance metric = read / write speed 120MB / s), child node 1: transaction server (label: device type = server, function = transaction processing, performance metric = CPU load 50%), child node 2: network switch (label: device type = network device, function = data transmission, performance metric = bandwidth utilization 25%). Nodes with the same device type are considered matching nodes, and the similarity of the root node, child node 1, and child node 2 is calculated respectively. Calculate path L1 similarity based on root node similarity and child node 1 similarity. Calculate path L2 similarity based on root node similarity and child node 2 similarity. Finally, perform a weighted sum of the root node similarity, child node 1 similarity, child node 2 similarity, path L1 similarity, and path L2 similarity to obtain the tree kernel similarity.

[0058] Steps S501 to S503, as illustrated in the embodiments of this application, generate node tags based on the device attributes of the storage device and associated device to calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree. This similarity calculation considers not only the topology, node hierarchy, and connection relationship of the two trees, but also the matching degree of device attribute features through node tags. Finally, a target similarity that can comprehensively reflect the similarity between the two device dependency trees is obtained, providing an accurate quantitative basis for subsequent selection of reference device dependency trees.

[0059] Please see Figure 6 In some embodiments, step S401 may include, but is not limited to, steps S601 to S604: Step S601: Calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree to obtain the first similarity. Step S602: Generate the current fault description text based on the target device dependency tree and fault information; Step S603: Obtain the candidate fault description text associated with the candidate device dependency tree, calculate the semantic similarity between the current fault description text and the candidate fault description text, and obtain the second similarity. Step S604: Fuse the first similarity and the second similarity to obtain the target similarity.

[0060] In some embodiments, step S601 specifically involves calculating tree kernel similarity based on node labels, as illustrated in steps S501 to S503.

[0061] In some embodiments, step S602 specifically refers to the current fault description text, which is generated based on the device relationships presented by the target device dependency tree and combined with the fault information of the storage device to describe the current fault scenario and specific manifestations. It includes the fault device association, fault phenomenon, fault impact, and other content.

[0062] In some embodiments, step S603 specifically refers to the candidate fault description text, which is pre-stored in the device relationship database and is associated one-to-one with the candidate device dependency tree. It records the device relationships, fault performance, and fault characteristics in historical fault scenarios and is a textual representation of historical fault cases.

[0063] In some embodiments, step S604 can specifically involve weighted summation of the first similarity and the second similarity according to preset weights; or directly summing the first similarity and the second similarity to obtain the target similarity; it is not limited to these methods.

[0064] Taking a financial application scenario as an example, when a payment system's storage device experiences a sudden increase in transaction response time, a target device dependency tree is first constructed with the storage device as the root node, including its upstream application server cluster and downstream backup storage array. The similarity between the target device dependency tree and candidate device dependency trees is calculated using a tree kernel algorithm to obtain the first similarity score. Then, combining the target device dependency tree and the fault information, a current fault description text is generated, such as: payment database response delay causing transaction queue backlog on ten upstream application servers, and downstream real-time backup stream interruption. Candidate fault description texts associated with the candidate device dependency tree are retrieved, such as: main database CPU overload triggering a chain reaction, upstream applications experiencing timeout alarms, and backup delays. Next, the semantic similarity between the two is calculated to obtain the second similarity score. These two scores, reflecting structural and semantic similarity respectively, are weighted and fused to obtain the target similarity score. If the target similarity score exceeds a similarity threshold, the fault cause associated with the candidate device dependency tree is used as a reference fault cause, such as storage device resource overload.

[0065] Taking a medical application scenario as an example, when a hospital PACS system experiences a surge in image retrieval error rates at its image archiving storage node, the system first constructs a target device dependency tree rooted at the image archiving storage node. This tree includes multiple upstream image diagnostic workstations and downstream core switches and backup storage. The similarity between the target device dependency tree and candidate device dependency trees is calculated using a tree kernel algorithm to obtain the first similarity score. Then, the target device dependency tree and fault information are combined to generate a current fault description text, such as "PACS main storage image retrieval failure, affecting five radiology diagnostic workstations unable to access patient CT sequences, and report generation stalled." Candidate fault description texts associated with the candidate device dependency tree are retrieved, such as "storage array fiber channel card failure, causing data flow interruption to the image reading workstation, and image loading failure." Next, the semantic similarity between the two is calculated to obtain the second similarity score. These two scores, reflecting structural and semantic similarity respectively, are weighted and fused to obtain the target similarity score. If the target similarity score exceeds a similarity threshold, the fault cause associated with the candidate device dependency tree is used as a reference fault cause, such as a storage device hardware link failure.

[0066] In the embodiments of this application, steps S601 to S604 are performed to calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree. The obtained first similarity represents the similarity in the device relationship structure dimension. The semantic similarity between the current fault description text and the candidate fault description text is calculated. The obtained second similarity represents the similarity in the semantic dimension of the fault scene. The first similarity and the second similarity are fused together to obtain the target similarity that can comprehensively reflect the similarity between the current fault and historical faults, providing a more accurate quantitative standard for subsequent selection of reference device dependency trees.

[0067] Please see Figure 7 In some embodiments, step S105 includes, but is not limited to, steps S701 to S703: Step S701: Based on the fault information, perform fault analysis on the storage device using a language model to obtain the first fault cause; Step S702: Based on the device log, perform fault analysis on the abnormal device using a language model to obtain the second cause of the fault; Step S703: Based on the reference fault cause, the first fault cause, and the second fault cause, generate the target fault cause using a language model.

[0068] In some embodiments, step S701 specifically refers to the preliminary cause judgment result of the storage device failure obtained by analyzing and reasoning through a pre-trained language model based solely on the storage device's failure information. The analysis basis focuses only on the failure performance-related data of the faulty device itself.

[0069] In some embodiments, step S702 specifically refers to the fault cause judgment result obtained by analyzing the abnormal device operation data recorded in the device log through a pre-trained language model, with the analysis focusing on possible factors that may cause the fault in the associated device.

[0070] In some embodiments, step S703 specifically refers to the final fault cause judgment result generated after comprehensive analysis, cross-validation and logical integration through a pre-trained language model. It is an accurate and comprehensive fault attribution conclusion derived by integrating three dimensions of information: historical fault experience, fault performance of the faulty equipment itself, and abnormal operation data of related equipment.

[0071] Taking a financial application scenario as an example, when the database storage server of a trading system experiences a "surge in the failure rate of persistent trading instructions," this failure information is input into a pre-trained language model for analysis to obtain the first cause of the failure, such as "database storage engine write queue blocking or local disk I / O anomaly." Next, the device logs of the application server cluster and risk control computing server associated with the database server are retrieved (containing anomalies such as "database connection timeout" and "risk control computing interrupted due to data not being ready"), and these logs are input into the language model for analysis to obtain the second cause of the failure, such as "an abnormal retry storm of associated application servers leading to database connection resource exhaustion." Then, from the device relational database, a reference cause of failure is matched based on the current failure scenario, such as "data write failure caused by intermittent outages of the storage area network (SAN) switch port." Finally, the language model will comprehensively compare, cross-validate, and logically reason about the three causes of failure (SAN switch problem), the first cause of failure (storage engine / local I / O problem), and the second cause of failure (application layer connection storm) to generate the final target cause of failure, such as "the root cause is that the SAN switch port failure causes the storage link to be unstable; the database I / O anomaly and the upper layer application connection timeout are both chain phenomena triggered by this".

[0072] Taking a medical application scenario as an example, when a hospital's electronic medical record (EMR) system experiences a fault message indicating a "significantly increased delay in accessing medical record images," this fault information is input into a pre-trained language model for analysis to obtain the first fault cause, such as "a sharp drop in the SSD cache hit rate of the archive storage node or an abnormal storage service process." Next, the device logs of the clinical access workstations and the medical record retrieval API server that depend on this archive node are retrieved (which record abnormal information such as "image slice loading timeout" and "slow response to retrieval requests"), and these logs are input into the language model for analysis to obtain the second fault cause, such as "abnormal concurrent access mode of the clinical workstation, or a defect in the retrieval service causing a large number of invalid requests to impact the storage." Then, a reference fault cause is matched from the device relational database, such as "the network bandwidth between the storage node and the core switch is occupied by other high-priority services." Finally, the language model performs a comprehensive analysis, conflict resolution, and evidence weight assessment on the reference fault cause (network bandwidth contention), the primary fault cause (storage node performance issues), and the secondary fault cause (abnormal concurrent access by clinical workstations) to generate the final target fault cause, such as "the root cause is insufficient network link bandwidth of the storage node; the concurrent access mode of the clinical workstations triggers this bottleneck, which in turn manifests as a decrease in storage service performance and retrieval delay."

[0073] Specifically, by using prompt words to guide the language model to perform fault analysis in the order shown in the above steps, the open-domain and generalized text generation capabilities of the language model can be structured and accurately guided into a professional fault analysis decision-making process. This will allow the language model to leverage its powerful understanding and reasoning advantages while reducing its tendency to jump logically, thus achieving controllable, reliable, and interpretable fault analysis.

[0074] Steps S701 to S703 as shown in the embodiments of this application first analyze the fault cause of the faulty device itself based on the fault information of the storage device to obtain the first fault cause; then, based on the logs of the associated devices with abnormal operation, analyze the possible factors that caused the fault of the associated devices to obtain the second fault cause; finally, by combining the reference fault cause, the first fault cause and the second fault cause, and with the help of the reasoning ability of the language model, cross-validate and integrate the fault causes of multiple dimensions to generate the target fault cause, thereby improving the accuracy and comprehensiveness of fault cause judgment.

[0075] Please see Figure 8 This application also provides a storage service fault analysis apparatus, which can implement the above-described storage service fault analysis method. The apparatus includes: The data acquisition module is used to acquire fault information and device topology diagrams of storage devices; The associated device lookup module is used to find associated devices connected to the storage device based on the device topology diagram; The device relationship analysis module is used to perform device relationship analysis on storage devices and associated devices to obtain target device relationship data; The similarity recall module is used to perform similarity recall in a preset device relationship database based on the target device relationship data to obtain reference device relationship data; wherein, the reference device relationship data is stored in association with the reference fault cause. The fault analysis module is used to obtain reference fault causes associated with the reference equipment relationship data and perform fault analysis based on the reference fault causes and fault information using a pre-trained language model.

[0076] The specific implementation of the storage service fault analysis device is basically the same as the specific embodiment of the storage service fault analysis method described above, and will not be repeated here.

[0077] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned storage service fault analysis method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0078] Please see Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the processing system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 to execute the storage service fault analysis method of the embodiments of this application. The input / output interface 903 is used to implement information input and output; The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0079] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described storage service fault analysis method.

[0080] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0081] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0082] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0083] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

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

[0086] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0087] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above 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. The coupling or direct coupling or communication connection between the shown or discussed units may be through some interfaces, or indirect coupling or communication connection between the apparatus or units, and may be electrical, mechanical, or other forms.

[0088] The units described above 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.

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

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

[0091] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for analyzing storage service failures, characterized in that, The method includes: Obtain fault information and device topology diagram of storage devices; Based on the device topology diagram, locate the associated devices connected to the storage device; Device relationship analysis is performed on the storage device and the associated device to obtain target device relationship data; Based on the target device relationship data, a similarity retrieval is performed in a preset device relationship database to obtain reference device relationship data; wherein, the reference device relationship data is stored in association with a reference fault cause. Obtain the reference fault cause associated with the reference device relationship data, and perform fault analysis using a pre-trained language model based on the reference fault cause and the fault information.

2. The method according to claim 1, characterized in that, The step of performing device relationship analysis on the storage device and the associated device to obtain target device relationship data includes: Obtain the interaction status data between the storage device and the associated device; Based on the interaction state data, a dependency analysis is performed on the storage device and the associated device to obtain dependency data; Based on the dependency data, a target device dependency tree is generated as the target device relationship data.

3. The method according to claim 2, characterized in that, The device relationship database includes a candidate device dependency tree; the step of performing similarity retrieval in a preset device relationship database based on the target device relationship data to obtain reference device relationship data includes: Calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree to obtain the target similarity; Based on the target similarity, a reference device dependency tree is determined from the candidate device dependency tree, which serves as the reference device relationship data.

4. The method according to claim 3, characterized in that, The step of calculating the kernel similarity between the target device dependency tree and the candidate device dependency tree to obtain the target similarity includes: Obtain the storage device attributes of the storage device and the associated device attributes of the associated device; Based on the storage device attributes and the associated device attributes, generate node labels for the target device dependency tree; Based on the node labels, the kernel similarity between the target device dependency tree and the candidate device dependency tree is calculated to obtain the target similarity.

5. The method according to claim 3, characterized in that, The candidate device dependency tree is associated with and stored with the candidate fault description text; the calculation of the tree kernel similarity between the target device dependency tree and the candidate device dependency tree to obtain the target similarity includes: Calculate the kernel similarity between the target device dependency tree and the candidate device dependency tree to obtain the first similarity. Based on the target device dependency tree and the fault information, generate the current fault description text; Obtain candidate fault description texts associated with the candidate device dependency tree, calculate the semantic similarity between the current fault description text and the candidate fault description texts, and obtain a second similarity. The first similarity and the second similarity are fused to obtain the target similarity.

6. The method according to claim 1, characterized in that, The step of performing device relationship analysis on the storage device and the associated device to obtain target device relationship data includes: Obtain the device logs of the associated devices; Based on the device logs and preset anomaly determination rules, abnormal devices are identified from the associated devices; Device relationship analysis is performed on the storage device and the abnormal device to obtain target device relationship data.

7. The method according to claim 6, characterized in that, The step of performing fault analysis using a pre-trained language model based on the reference fault cause and the fault information includes: Based on the fault information, the storage device is analyzed using the language model to obtain the first cause of the fault. Based on the device logs, the abnormal device is analyzed using the language model to obtain a second cause of the fault. Based on the reference fault cause, the first fault cause, and the second fault cause, the target fault cause is generated using the language model.

8. A storage service fault analysis device, characterized in that, The device includes: The data acquisition module is used to acquire fault information and device topology diagrams of storage devices; The associated device lookup module is used to find associated devices connected to the storage device based on the device topology diagram. The device relationship analysis module is used to perform device relationship analysis on the storage device and the associated device to obtain target device relationship data; The similarity recall module is used to perform similarity recall in a preset device relationship database based on the target device relationship data to obtain reference device relationship data; wherein, the reference device relationship data is stored in association with a reference fault cause; The fault analysis module is used to obtain reference fault causes associated with the reference device relationship data and to perform fault analysis based on the reference fault causes and the fault information using a pre-trained language model.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the storage service fault analysis method according to 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 storage service fault analysis method according to any one of claims 1 to 7.

Images