System fault diagnosis methods, equipment, media and program products

Abstract

The present application discloses a system fault diagnosis method, device, medium and program product, which relate to the field of computer technology, including extracting fault data fragments for system fault diagnosis from a system database based on fault description information, reducing the impact of large and redundant information on the extraction of useful information, extracting fault knowledge fragments for system fault diagnosis from a system knowledge base based on fault description information, performing fault diagnosis based on the fault data fragments and fault knowledge fragments, reducing dependence on experience, solving the technical problems of cumbersome and inefficient system fault diagnosis process, and achieving the technical effect of accurate fault diagnosis.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a system fault diagnosis method, device, medium and program product. Background Art

[0002] With the rapid development of information technology, Linux systems, due to their stability, open source nature, and powerful functionality, have been widely adopted in fields such as servers, cloud computing, and embedded devices. However, as system scale and complexity continue to increase, the probability of failure also increases. Related Linux system fault diagnosis methods rely primarily on the experience of system administrators and analysis of system logs. Administrators need to be familiar with various system commands and tools to troubleshoot problems. Administrators lacking relevant experience may find it difficult to determine the cause of the problem. Furthermore, system logs are voluminous and complex, requiring administrators to spend considerable time sifting through them to identify useful fault information. This results in a cumbersome and inefficient diagnostic process. Summary of the Invention

[0003] The present application provides a system fault diagnosis method, device, medium and program product to at least solve the problem of cumbersome and inefficient fault diagnosis process in related technologies.

[0004] This application provides a system fault diagnosis method, including:

[0005] Obtain fault description information of the target system;

[0006] Extracting fault data fragments from a pre-built database based on the fault description information, wherein the database is used to store relevant data of the target system;

[0007] Extracting fault knowledge fragments from a pre-built knowledge base based on the fault description information, where the knowledge base is used to store relevant knowledge for system fault diagnosis;

[0008] Perform fault diagnosis on the target system based on the fault data fragments and fault knowledge fragments and generate a diagnosis report.

[0009] The present application also provides a system fault diagnosis device, comprising:

[0010] An acquisition module is used to obtain fault description information of the target system;

[0011] A first extraction module is used to extract fault data fragments from a pre-built database based on the fault description information, wherein the database is used to store relevant data of the target system;

[0012] The second extraction module is used to extract fault knowledge fragments from a pre-built knowledge base based on the fault description information, wherein the knowledge base is used to store relevant knowledge of system fault diagnosis;

[0013] The generation module is used to perform fault diagnosis on the target system based on the fault data fragments and the fault knowledge fragments and generate a diagnosis report.

[0014] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned system fault diagnosis methods when executing the computer program.

[0015] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned system fault diagnosis methods are implemented.

[0016] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned system fault diagnosis methods when executed by a processor.

[0017] Through the present application, fault data fragments used for system fault diagnosis are extracted from the system database based on the fault description information, reducing the impact of the huge amount of redundant information on the extraction of useful information. Fault knowledge fragments used for system fault diagnosis are extracted from the system knowledge base based on the fault description information. Fault diagnosis is performed based on the fault data fragments and fault knowledge fragments, reducing the dependence on experience. Therefore, the technical problems of the cumbersome and inefficient system fault diagnosis process can be solved, and the technical effect of accurate fault diagnosis can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0019] Figure 1 A flowchart of a system fault diagnosis method provided in an embodiment of the present application;

[0020] Figure 2 A schematic diagram of the structure of a system fault diagnosis method provided in an embodiment of the present application;

[0021] Figure 3 A timing flow chart of a system fault diagnosis method provided in an embodiment of the present application;

[0022] Figure 4 A schematic diagram of the structure of a system fault diagnosis device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0024] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0025] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0026] With the rapid development of information technology, Linux, thanks to its robust stability, open-source flexibility, and comprehensive functionality, has become widely adopted in a variety of fields, including servers, cloud computing platforms, and embedded devices. It has become a crucial operating system supporting the operation of modern information systems. However, with the continuous expansion of system scale and increasing architectural complexity, the likelihood of Linux system failures has also increased. Once an anomaly occurs, how to quickly and accurately locate the cause and develop an effective solution has become a critical issue in ensuring stable system operation.

[0027] Currently, Linux troubleshooting methods primarily rely on the system administrator's experience and manual analysis. This typically involves reviewing system log files and using various command tools (such as dmesg, journalctl, and top) to extract key information and infer the cause of the fault. While this approach can address common issues to a certain extent, it also has several limitations. First, system logs often contain a large amount of redundant information, and relevant information is often buried within the vast amount of data, making information sifting through the logs cumbersome. Second, this approach requires a high level of administrator expertise and experience, meaning it relies heavily on experience. When faced with rare or complex fault types, inexperienced operators may struggle to make accurate and prompt judgments, resulting in long troubleshooting times and low diagnostic efficiency. Furthermore, the continuous evolution of the Linux technology ecosystem, with the emergence of new modules, kernel features, and application environments, places a higher demand on administrators to maintain their knowledge and address various potential faults.

[0028] For example, rule-based fault diagnosis methods predefine fault rules. When a system anomaly occurs, the system's status information is matched against the predefined fault rules to determine the fault type and cause. However, developing fault rules requires specialized knowledge and extensive experience, and it is difficult to cover all possible faults, limiting the scope of diagnosis. When encountering new fault types, new fault rules need to be manually added, resulting in high maintenance costs. Furthermore, conflicts between rules can lead to inaccurate diagnostic results.

[0029] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the system fault diagnosis method depends, the specific application environment architecture or specific hardware architecture is described here.

[0030] Before describing the present application in detail, it is preferred to explain the technical terms involved.

[0031] Retrieval-Augmented Generation (RAG) is an artificial intelligence technology that combines information retrieval technology with language generation models.

[0032] Natural Language Processing (NLP) is a branch of artificial intelligence and linguistics that aims to enable computers to understand, interpret, and generate natural human language.

[0033] An embodiment of the present application provides a system fault diagnosis method, and the method is described in detail in conjunction with the execution process of the system fault diagnosis method.

[0034] Figure 1 A flow chart of a system fault diagnosis method provided in an embodiment of the present application is applied to a diagnostic system or a diagnostic device. The diagnostic system or the diagnostic device can be run on a computer device, specifically including the following steps: Figure 1 The following steps are shown:

[0035] S101: Obtain fault description information of the target system.

[0036] The target system can be a Linux system or other computer system, and the fault description can be a natural language description of the target system's operational anomaly proactively provided by the system administrator, maintenance personnel, or end user. This information, typically presented in text format, expresses the target user's understanding and observation of the current system fault phenomenon and serves as an input for diagnosing system faults. The fault description can be understood as a clear diagnostic instruction, indicating the relevant characteristics of the target system's fault to be diagnosed. For example, the fault description might be "The server is suddenly inaccessible, and SSH connection is unavailable." SSH (Secure Shell) is a network protocol for secure remote login and command execution. This description contains key features for fault diagnosis and helps facilitate diagnosis and troubleshooting. Furthermore, for complex or multi-factorial faults, the user's subjective judgment and empirical description can provide additional clues for the diagnostic system, accelerating the matching of existing knowledge bases and improving diagnostic efficiency. Furthermore, allowing users to input fault descriptions enables more flexible human-computer collaboration, enhancing the usability and practicality of the diagnostic system.

[0037] It is understandable that the fault description information can be entered by the user when the target system is experiencing some kind of fault and needs to be promptly identified and repair suggestions provided; it can also be entered by maintenance personnel when performing routine maintenance when the target system is operating normally. The input scenario of the fault description information is not limited.

[0038] Optionally, before extracting the fault data fragment from the pre-built database based on the fault description information, the method further includes:

[0039] Obtain at least one original information from the target system's log information, performance indicators, kernel dump information, operation information, configuration information, and access information; extract keyword information from the log information using a natural language processing algorithm; identify performance anomaly information from performance indicators using a statistical analysis algorithm; and store at least one original information, keyword information, and performance anomaly information in a database.

[0040] It is understood that a database for storing target system-related data can be constructed in the following manner: relevant data from the target system is collected and stored in a local data storage module. The relevant data includes at least one type of raw information, such as log information, performance indicators, kernel dump information, operational information, configuration information, access information, and audit information. Specifically, relevant information can be collected using the target system's own tools / data collection programs, such as syslog to collect system log information, top to collect information such as CPU and memory usage, vmstate to collect performance indicators such as disk I / O, and coredump to collect kernel dump information. Alternatively, third-party or self-developed software can be used to collect the required system operational information and obtain information such as system configuration files. It is understood that the data collection program can be triggered periodically or when specific events occur. The collected raw information of the target system is retained in the local data storage module, and the collected raw information is preprocessed, including data cleaning, feature extraction, and normalization, to provide high-quality data for subsequent processing. In other words, the database stores both raw and processed information. Specifically, data cleansing algorithms can be used to clean up raw data, identifying and removing duplicate records and / or data containing incorrect formats. Natural language processing techniques can be used to extract key words from log information that reflect system failures. Statistical analysis algorithms can be used to identify abnormal performance information, such as unusual fluctuations in performance indicators, abnormal stack information, audit information, and function call flows. Subsequently, normalization functions can be used to normalize different data types, essentially unifying the data format. This pre-processing of data (such as identifying log keywords and performance anomaly indicators) improves the speed and accuracy of extracting fault data fragments describing faults from the database.

[0041] S102: Extract fault data segments from a pre-built database based on the fault description information.

[0042] The database is used to store relevant data of the target system.

[0043] It is understandable that, based on the above S101, the fault description information is converted into structured query conditions, and at least one fault data segment that matches the fault description information is retrieved from the database, and the specific extraction or query method is not limited. Among them, the fault data segment refers to the information segment related to system failures, abnormal behaviors, error events, etc. that is screened out from the database that records the system operation status, logs and / or performance indicators. For example, based on the above example, the fault data segment can be "data reflecting the SSH connection status", "data reflecting the server access status" and "data reflecting the network connection status". In addition, the fault data segment can include content such as data type, collection module, timestamp and specific data.

[0044] Optionally, extracting fault data fragments from a pre-built database based on the fault description information can be achieved through the following steps:

[0045] The fault data segments corresponding to the fault description information are extracted from the pre-built database through the pre-trained language model.

[0046] It is understood that fault description information can be used as input to a pre-trained language model. The language model can then extract the fault data segments involved in the fault description from the database. These fault data segments can be considered key data segments for fault diagnosis. The specific network structure and extraction method of the large language model are not limited.

[0047] S103: Extract fault knowledge fragments from a pre-built knowledge base based on the fault description information.

[0048] Among them, the knowledge base is used to store relevant knowledge of system fault diagnosis.

[0049] As can be understood, based on the above S102, the knowledge base integrates expert-organized fault cases, open source community solutions, relevant technical documents, security advisories, and other information. Relevant knowledge fragments for diagnosing the fault description information are extracted from the knowledge base, such as fault cases, solutions, and related documents for a fault similar or identical to the fault description information. In other words, the knowledge base automatically searches for existing historical information similar or identical to the fault description information, providing support for rapid diagnosis and resolution of the fault problem.

[0050] In one embodiment, the fault description information describes the fault "server unresponsiveness", and the fault knowledge fragment is relevant knowledge extracted from the knowledge base, including the fault phenomenon (such as system crash, service unresponsiveness, etc.), cause analysis (such as configuration error, insufficient resources, code defects, etc.) and solution (patching, configuration modification, restarting service, etc.).

[0051] Optionally, fault knowledge fragments are extracted from a pre-built knowledge base based on the fault description information. This can be achieved through the following steps:

[0052] The fault description information is converted into a vector representation through a pre-trained word vector model to obtain at least one word vector, wherein the at least one word vector is at least one word item mapped to at least one numerical vector of a preset dimension, and the at least one word item is obtained by word segmentation processing of the fault description information; the fault knowledge fragment is extracted from a pre-built knowledge base based on the at least one word vector and the fault description information through a pre-trained multi-dimensional feature model.

[0053] It is understandable that the fault description information is converted into a vector representation using a word vector model to obtain at least one word vector. Specifically, the word vector model performs word segmentation processing on the fault description information to obtain at least one word item. Based on the above example, the fault description information is split into multiple words "server", "suddenly", "inaccessible", "SSH" and "unable to connect". The specific word segmentation method is not limited. For example, for fault description information expressed in English, each word can be regarded as a word item, and for fault description information expressed in Chinese, a phrase can be regarded as a word item. Subsequently, at least one word item is mapped to a preset dimension to obtain at least one word vector, which is a numerical vector. The multi-dimensional feature model is used to index and search the knowledge base based on the extracted at least one word vector and the fault description information to obtain multiple candidate knowledge fragments and the similarity of each candidate knowledge fragment. The candidate knowledge fragments are sorted from high to low according to their similarity, and the top N candidate knowledge fragments with higher similarity are selected as the retrieval results. The retrieval results include the fault knowledge fragments, where N can be adjusted according to actual conditions. Alternatively, the multi-dimensional feature model directly outputs the fault knowledge fragments.

[0054] Optionally, a fault information vector of the fault description information is calculated, and a knowledge segment vector of at least one candidate knowledge segment is extracted from the knowledge base based on the fault information vector; the cosine similarity between the fault information vector and the knowledge segment vector is calculated, and the fault knowledge segment is determined based on the cosine similarity.

[0055] Optionally, the multidimensional feature model includes a basic feature layer, a semantic enhancement layer, and a structural feature layer. The pre-trained multidimensional feature model extracts fault knowledge fragments from a pre-built knowledge base based on at least one word vector and fault description information. This can be achieved through the following steps:

[0056] The basic feature layer calculates the word frequency weight of at least one term based on at least one word vector to determine the fault keyword terms related to the fault description information; the semantic enhancement layer generates multiple semantic vectors with context-awareness based on the fault description information and the documents included in the knowledge base; the structural feature layer converts the non-text data in the fault data segment into a structural feature vector; based on the word frequency weight of at least one term, multiple semantic vectors and structural feature vectors, the fault knowledge segment is indexed from the knowledge base.

[0057] Understandably, related technologies for indexing and retrieving knowledge points from knowledge bases suffer from insufficient retrieval accuracy and limited semantic understanding capabilities. This embodiment deeply optimizes the indexing and retrieval modules, proposing an indexing and retrieval strategy that integrates multimodal knowledge encoding with a dynamic weighted semantic matching algorithm. Specifically, a multidimensional feature model is constructed to represent a multi-layered knowledge representation system. In one embodiment, the multidimensional feature model includes a basic feature layer, a semantic enhancement layer, and a structural feature layer. The basic feature layer analyzes the similarity between fault descriptions and documents in the knowledge base from the perspective of terms / frequency. The semantic enhancement layer analyzes the similarity between fault descriptions and documents in the knowledge base from the perspective of sentence semantics. The structural feature layer analyzes the similarity between fault descriptions and documents in the knowledge base from the perspective of document structure. Finally, by comprehensively considering the similarity between fault descriptions and documents across multiple dimensions, such as word frequency, semantics, and document structure, the system accurately identifies fault knowledge segments that can be used to diagnose faults and address fault responses. This approach evaluates text similarity along three different dimensions (lexical, semantic, and structural), dynamically adjusts weights based on a pre-trained model, and ultimately calculates a comprehensive similarity to filter out relevant document segments. Among them, fault knowledge fragments include but are not limited to structured or semi-structured information content such as fault phenomenon description, common causes, diagnostic methods, repair commands and precautions, which are used to support knowledge retrieval and decision generation of automated or auxiliary diagnostic systems. The constituent elements of fault knowledge fragments can also be customized.

[0058] Optionally, the frequency weight of at least one term is calculated based on at least one word vector, which can be implemented by the following steps:

[0059] Count the number of occurrences of at least one term in each preset document included in the knowledge base to obtain a first frequency; count the number of occurrences of at least one term in all preset documents included in the knowledge base according to a preset weight to obtain a second frequency; calculate the term frequency weight of at least one term based on the first frequency and the second frequency.

[0060] It is understandable that the BM25+ algorithm can be used to calculate the term frequency weight. BM25 is a classic ranking function based on term frequency, widely used in the field of information retrieval. It evaluates the relevance between documents and retrieval / query terms by calculating the frequency of occurrence of query terms in documents, normalizing document length, and inverse document frequency. BM25+ is an enhanced version of BM25. Specifically, at least one term is directly used as a query term, or a query term is selected from it. The number of occurrences of each query term in the fault description information or each preset document is calculated to obtain a first frequency. The first frequency can also be understood as term frequency, where term frequency refers to the number of times a query term appears in a document. Generally speaking, the more a term appears in a document, the more important it may be in the document. The number of occurrences of each query term in all preset documents is calculated based on the preset weight to obtain a second frequency. The preset weight can be understood as a query term frequency enhancement factor. The newly added query term frequency term can effectively capture high-frequency fault keywords in the user input data (fault description information). Subsequently, the term frequency weight of the query term is calculated based on the first frequency and the second frequency, as shown in formula (1).

[0061] Formula (1)

[0062] Where, It represents the word frequency weight calculated by BM25+ algorithm, t is the query term, IDF(t) is the inverse document frequency of the query term, d is the preset document, is the frequency of term t in document d, i.e. the first frequency, |d| is the document length, avgdl is the average document length of the entire document set, b is the length normalization parameter, usually set to 0.75, δ is the query term frequency enhancement factor (preset weight), k1 and k2 are weights, which are parameters used to control the term frequency saturation. It is the frequency of term t in all documents q (document set), that is, the second frequency, and document t belongs to document set q.

[0063] Optionally, the multiple semantic vectors include a knowledge base document vector and a fault query vector. The semantic enhancement layer generates multiple semantic vectors with context-awareness based on the fault description information and the documents included in the knowledge base, including:

[0064] The fault description information and / or fault data fragments are vectorized and encoded to obtain a fault query vector; at least one preset document included in the knowledge base or at least one target document corresponding to the fault keyword item is vectorized and encoded to obtain a knowledge base document vector.

[0065] It is understandable that a deep semantic encoding model (such as Sentence-BERT) is introduced in the semantic enhancement layer to vectorize the fault description information or the fault data fragment extracted based on the fault description information to obtain the fault query vector. The fault data fragment can be log text, performance indicators (such as CPU utilization, disk I / O exceptions), code fragments (such as kernel panic stack), etc. Through the semantic encoding model, all preset documents or target documents are vectorized and encoded to obtain the knowledge base document vector, where the target document is the preset document corresponding to the fault keyword in the knowledge base. For example, the preset document containing a certain number of fault keywords is determined as the target document. Other models that can perform vector encoding are not described in detail. The semantic encoding model can be fine-tuned later to optimize the generation of sentence vectors (SentenceVector) on the Linux fault diagnosis corpus so that the encoding vector contains contextual semantic information and solves the polysemy problem existing in related technologies. The formula for obtaining the fault query vector and knowledge base document vector through the semantic encoding model is shown in Formula (2).

[0066] Formula (2)

[0067] Where, is the knowledge base document vector, is the fault query vector, a is the fault data segment, It is a semantic encoding model.

[0068] It is understandable that a structural feature layer can be designed for non-text data such as configuration files and process data structures. In other words, a specialized structural feature layer can be designed for data that reflects structural relationships. The structural feature layer can be built based on a graph neural network (GNN). The configuration file can be " / etc / sysctl.conf". The structural feature layer can be used to transform the system configuration into a property graph, using nodes to represent configuration items and edges to represent dependencies, thereby generating a structural feature vector. The formula for calculating the structural feature vector is shown in Formula (3).

[0069] Formula (3)

[0070] Where, is the feature vector of the i-th node in the l-th layer, is the neighbor set of node i, is the learnable weight matrix, is an activation function, such as ReLU.

[0071] It can be understood that the structural feature layer is used to extract the structural feature vectors of the fault data fragments, the semantic feature layer is used to extract the semantic sentence vectors of the fault data fragments, and the basic feature layer is used to extract the word vectors of the fault data fragments on the terms.

[0072] Optionally, based on the word frequency weight of at least one word, multiple semantic vectors, and structural feature vectors, fault knowledge fragments are indexed from the knowledge base. This can be achieved through the following steps:

[0073] Calculate basic feature similarity based on the word frequency weight of at least one word, wherein the basic feature similarity is used to evaluate the lexical similarity of different texts; calculate semantic feature similarity based on multiple semantic vectors, wherein the semantic feature similarity is used to evaluate the semantic similarity of different texts; calculate structural feature similarity based on structural feature vectors, wherein the structural feature similarity is used to evaluate the structural similarity of different texts; adjust the similarity weights of different network layers in the multidimensional feature model according to the target fault type through a pre-trained weight prediction model, wherein the target fault type is determined based on the fault description information; calculate comprehensive similarity based on the adjusted similarity weights of different network layers, basic feature similarity, semantic feature similarity and structural feature similarity; and take at least one target content in at least one preset document included in the knowledge base whose comprehensive similarity is greater than a preset threshold as a fault knowledge fragment.

[0074] It is understandable that a lexical feature vector is obtained by constructing a vector representation based on word frequency weights and terms, and the basic similarity between them is calculated using methods such as cosine similarity and dot product. The basic similarity can also be understood as the vector similarity after word frequency weighting. A semantic feature vector is constructed based on multiple semantic vectors such as fault query vectors and knowledge base document vectors, and the similarity between multiple semantic vectors is calculated to obtain semantic feature similarity. Semantic feature similarity can capture content with similar semantics even if the vocabulary is not exactly the same. For example, text A is "the server cannot be accessed" and text B is "the webpage cannot be opened". Although the vocabulary of the two texts is different, they are very close in semantics. The text is constructed as a graph structure, and the graph neural network is used to extract the graph structure features. After obtaining the structural feature vector, it can also be compared using methods such as cosine similarity to capture the logical structure and association relationship within the text. Subsequently, the three layers of feature vectors, namely the lexical feature vector, the semantic feature vector, and the structural feature vector, can be spliced ​​together to form a composite feature representation containing lexical, semantic, and structural information, as shown in formula (4).

[0075] Formula (4)

[0076] Where, is a composite feature representation, is the lexical feature vector, is the semantic feature vector, is the structural feature vector.

[0077] It is understandable that in order to solve the problem that cosine similarity ignores the semantic level differences, hierarchical similarity calculation is performed to calculate the basic feature similarity, semantic feature similarity and structural feature similarity respectively. The specific calculation formula is shown in formula (5).

[0078] Formula (5)

[0079] Where, is the semantic feature similarity, is the structural feature similarity, Refers to cosine similarity.

[0080] It is understandable that the trained weight prediction model determines the fault type based on the input fault description information and dynamically adjusts the similarity weights in the three dimensions of lexical, semantic, and structural according to the characteristics of different fault types. Each fault type (such as network failure, software crash, permission issue, kernel failure, application service failure, hardware adaptation failure) has different sensitivities to different features, which means that the similarity weights of each layer are automatically adjusted. This is shown in Formula (6).

[0081] Formula (6)

[0082] Where, is the weight of the basic feature similarity, is the weight of semantic feature similarity, is the weight of the structural feature similarity, Classify the basic fault keywords. Calculation of abnormal normal speed for performance indicators.

[0083] It is understandable that after determining the similarity weights of each layer, the comprehensive similarity calculation is performed, as shown in formula (7).

[0084] Formula (7)

[0085] Where, is the comprehensive similarity.

[0086] Understandably, a context-aware retrieval enhancement mechanism is set up. In order to improve the processing capabilities of long text logs and enhance the semantic understanding and retrieval effects of the model in specific fields, a long text segmentation strategy that supports context awareness and a semantic encoding enhancement strategy that integrates system domain knowledge are introduced. Among them, for ultra-long log files that exceed the maximum input length limit of the model, a method combining sliding windows and key sentence extraction is used for intelligent slicing. Specifically, the TextRank algorithm can be used to identify key sentences in the original log, extract sentences with rich semantic information as slicing anchors, and apply the sliding window mechanism on this basis to ensure that each generated sub-segment not only contains local content, but also retains sufficient contextual information. That is, the long text log is automatically divided into sub-segments including contextual information, which effectively solves the problems of contextual disconnection and semantic fragmentation in related methods, so that the subsequent vector representation and retrieval modules can more accurately capture fault clues in the log. In addition, to improve the model's ability to understand the underlying terminology of the operating system, domain-specific knowledge related to the Linux kernel was introduced when using the SBERT model for semantic encoding. This includes but is not limited to common kernel function names (such as kfree), core data structures (such as task_struct), typical error identifiers and events (such as OOM Killer, KernelPanic), and other specific features of specific fields. These are injected into the semantic encoding process by constructing a custom word embedding matrix, thereby improving the representation accuracy of key terms, enhancing the model's ability to understand system-level fault semantics, and improving recall and matching performance in professional scenarios.

[0087] It can be understood that this context-aware log slicing strategy and semantic enhancement of system domain knowledge significantly improves the processing capability of long text logs and the semantic representation accuracy of professional terms, thereby enhancing the practicality and accuracy of the overall retrieval system.

[0088] S104: Perform fault diagnosis on the target system according to the fault data fragments and the fault knowledge fragments, and generate a diagnosis report.

[0089] It can be understood that, based on the above S103, the fault data fragments and the fault knowledge fragments are spliced ​​and input into a pre-trained language model for fault diagnosis to obtain a diagnostic report output by the language model, wherein the diagnostic report may include clear fault, actual description information, diagnostic basis based on the knowledge base and specific solutions and other information.

[0090] Optionally, the target system is diagnosed based on the fault data fragments and the fault knowledge fragments, and a diagnosis report is generated. This can be achieved through the following steps:

[0091] The fault data fragments and fault knowledge fragments are input into the language model for fault diagnosis, and a diagnosis report output by the language model is obtained.

[0092] It's understandable that the language model used to extract fault data segments from the database can be the same language model used for fault diagnosis. Specifically, after extracting fault data segments related to fault description information from the database using the language model, the fault knowledge segments extracted from the knowledge base are combined with the fault data segments. These segments are then fed into the language model for fault diagnosis and generated as a diagnostic report. This language model is not described in detail here.

[0093] Optionally, the fault data fragment and the fault knowledge fragment are input into the language model for fault diagnosis, and a diagnosis report output by the language model is obtained. This can be achieved through the following steps:

[0094] In the process of generating a diagnostic report, constraints and / or maximum length limits are set, wherein the constraints include at least one of fault cause analysis, feasible solutions, and maintenance recommendations, and the maximum length limit is used to limit the length of the generated text; fault data fragments and fault knowledge fragments are input into a language model for fault diagnosis, and a diagnostic report that satisfies the constraints and / or maximum length limits is obtained as output by the language model.

[0095] Understandably, during the diagnostic report generation process, to optimize the results, you can also set an upper limit on the generated text length and / or add constraints to the language model input. This allows the language model to generate a detailed fault diagnosis report based on the input information (fault data fragments and fault knowledge fragments) and the constraints. The constraints can restrict the generated content to key information such as the fault cause, feasible solutions, and maintenance recommendations. In other words, the length and content of the report text can be customized according to user needs.

[0096] Optionally, after performing fault diagnosis on the target system based on the fault data fragments and the fault knowledge fragments and generating a diagnosis report, the method further includes:

[0097] The diagnostic report is presented to the target user in at least one form of a structured web page interface, a command line interface, and a graphical interactive interface.

[0098] As can be understood, the generated fault diagnosis report is presented to users or system administrators in a visual format, improving the readability and ease of use of diagnostic information. For example, diagnostic reports can be presented to users through a structured web interface (Web Interface), a concise command line interface (CLI), and a graphical client interface (Desktop Client), catering to different usage scenarios and user preferences. The information presented to users can include fault diagnosis results, actual description information (detailed description of the detected fault phenomenon), diagnostic evidence (supporting the diagnosis conclusion, such as log analysis results, matched knowledge base entries, similarity calculation results, etc.), and recommended solutions (providing targeted remediation suggestions, steps, or links to relevant documentation resources based on the diagnosis results). Furthermore, the displayed information can be organized and formatted according to pre-set visualization templates, and the complete diagnostic report is presented to users through the selected output interface. Diagnostic results can also be exported, printed, and history query functions are supported for subsequent archiving and analysis. This visual presentation enables efficient communication of diagnostic information, improving user-friendliness and operational efficiency.

[0099] Optionally, after presenting the diagnostic report to the target user in at least one of a structured web page interface, a command line interface, and a graphical interactive interface, the method further includes:

[0100] Receive feedback from target users regarding the diagnostic report, where the feedback includes diagnostic opinion information and / or new fault information; adjust and optimize the knowledge base and / or database based on the diagnostic opinion information to regenerate the diagnostic report based on the fault description information or the new fault information; or regenerate the diagnostic report based on the new fault information.

[0101] Understandably, an interactive feedback and system optimization mechanism is implemented. After presenting a structured diagnostic report to the user or system administrator, user feedback is also obtained to achieve closed-loop management of diagnostic information and continuous system optimization. Specifically, after the diagnostic report is presented to the user via a web interface, command line interface, or client interface, the user or administrator can provide feedback on the diagnostic results, including but not limited to evaluating the diagnostic results (e.g., pointing out diagnostic inaccuracies and providing specific feedback) and providing additional information related to the current fault (e.g., new log snippets, contextual descriptions, or suspected cause analysis). Subsequently, the obtained feedback results are classified and statistically analyzed, and optimization operations such as dynamic knowledge base updates, system parameter adjustments, and / or re-diagnosis are performed based on this information. For example, based on the supplementary information or correction suggestions in the user feedback results, fault cases and solution entries in the knowledge base can be added, modified, or deleted to improve the accuracy of subsequent diagnoses. For example, based on the error type distribution and semantic feature analysis in the feedback results, relevant model parameters (e.g., word embedding matrix, encoder weights) and data collection strategies (e.g., log collection granularity, feature extraction dimensions) can be adaptively adjusted. For example, under specific conditions (such as when feedback indicates a significant deviation from the diagnostic conclusion), the data collection and diagnosis process is re-invoked and the entire diagnostic process is executed again to obtain a more accurate diagnosis. Other adjustments based on the feedback results are not detailed here. This mechanism establishes a closed-loop iterative system of diagnosis, feedback, and optimization, effectively improving the system's robustness, adaptability, and intelligence in real-world application scenarios.

[0102] Optionally, after performing fault diagnosis on the target system based on the fault data fragments and the fault knowledge fragments and generating a diagnosis report, the method further includes:

[0103] When it is determined that the diagnosis report is correct, the fault description information, fault data fragment and / or diagnostic report are stored in the knowledge base; and / or the latest fault information and safety information of the target system are added to the knowledge base.

[0104] Understandably, when the user or system administrator confirms the output diagnostic report and determines that the diagnosis in the diagnostic report is correct, the relevant diagnostic information is collected and structured, and used to update the knowledge base. Specifically, data keywords (such as key terms related to the current fault, function names, error codes, etc.), fault description information (such as timestamps, log fragments, abnormal behavior, etc.), diagnostic basis information (such as log analysis results, matching knowledge base entries, similarity calculation results, etc.), solution information (such as specific repair measures recommended for the fault, operating steps and reference document links), and original fault information (such as original log data, system status information and other contextual environment data) are extracted from the diagnostic process. In other words, this diagnosis is automatically or after review added to the knowledge base as a new fault case to expand the knowledge base coverage and improve the accuracy and coverage of subsequent diagnostic systems. Furthermore, the complete diagnostic process and diagnostic results can be recorded to form a traceable fault handling file to support subsequent audits, replays and model training.

[0105] It is understandable that information from specific websites can also be collected and processed and updated into the knowledge base to achieve knowledge base updates. Examples include website updates published by the Common Vulnerabilities and Exposures (CVE), information on public and fixed bugs in the Linux kernel and related components, and information from websites offering Q&A on Linux system and component troubleshooting.

[0106] For example, Figure 2This is a schematic diagram of the structure of a system fault diagnosis method provided in an embodiment of the present application. This method implements fault diagnosis based on a fault diagnosis system. Specifically, the fault diagnosis system includes a system data acquisition module, a local data storage module, a language model, a retrieval module, a generation module, a diagnostic output module, an auxiliary management module, a knowledge base, and an internet acquisition module. The system data acquisition module runs on a Linux system and is responsible for collecting system log information, memory usage information, performance metrics, kernel dump information, operational information, and configuration files, and storing the collected information in the local data storage module. The local data storage module is responsible for storing the collected raw information and performing pre-processing (data cleaning, feature extraction, and normalization, etc.) on the raw information. The language model is responsible for extracting fault data segments from the local data storage module based on the fault description information. The retrieval module is responsible for retrieving fault knowledge segments from the knowledge base and converting the fault data segments and fault knowledge segments into vector form as input for the language model. The generation module is responsible for inputting the fault data segments and fault knowledge segments into the language model for fault diagnosis and outputting a detailed diagnostic report. The diagnostic output module is responsible for presenting the diagnostic report to the user or system administrator in a visual format. The auxiliary management module is responsible for updating and maintaining the knowledge base. It receives feedback from the diagnostic output module, analyzes it, optimizes overall system performance, and updates the Linux fault knowledge base. The Linux fault knowledge base stores and integrates expert-organized fault cases, open source community solutions, relevant technical documentation, security advisories, and other information. The internet collection module collects the latest Linux fault and security information, processes it, and then expands the Linux fault knowledge base.

[0107] It is understandable that the retrieval module and the generation module are combined to build a complete system architecture that includes data collection, retrieval, generation, output, and auxiliary management. This fully leverages the advantages of knowledge base retrieval and language model generation to achieve efficient and accurate fault diagnosis. A comprehensive and accurate Linux fault knowledge base covering multi-channel knowledge is constructed. Linux fault and CVE information is updated through the Internet acquisition module, and the knowledge base is dynamically updated and maintained through the auxiliary management module, ensuring the timeliness and accuracy of the knowledge. The dynamic weight semantic matching algorithm is integrated with the retrieval strategy of multimodal knowledge encoding for efficient knowledge retrieval. At the same time, the language model output is optimized by setting the generation strategy, significantly improving the quality of the diagnosis results. The interactive function of the diagnostic result interaction mode and the optimization mechanism of the auxiliary management module are designed to achieve continuous optimization of the system based on user feedback, improving the practicality of the system. The indexing and retrieval strategy integrates multimodal knowledge encoding and dynamic weight semantic matching algorithm, integrates SBERT and GNN models in the semantic representation dimension, supports multimodal semantic encoding, dynamically allocates weights in the weight allocation dimension, supports fault type adaptation, supports multimodal data such as logs, configuration files, process trees in the data processing dimension, integrates long text segmentation technology, injects kernel symbol tables and fault codes in the domain adaptation dimension, builds a domain-specific knowledge base, and other innovations and improvements.

[0108] For example, Figure 3 The present invention provides a timing flow chart of a system fault diagnosis method provided in an embodiment of the present application. The Internet acquisition module collects Internet information and updates the knowledge base. The data acquisition module collects information based on timer / event triggers, collects Linux system-related information, and performs data cleaning, feature extraction, and normalization on the relevant information before storing it locally. After receiving the fault description information, the retrieval module vectorizes the fault data fragments and fault knowledge fragments, performs knowledge retrieval from the knowledge base, calculates the vector similarity and sorts them, and sends the detection results (fault knowledge fragments) and fault data fragments to the generation module. The generation module inputs information into the language model, generates a diagnostic report based on the strategy, and sends the diagnostic report to the diagnostic output module. The diagnostic output module outputs a visual diagnostic report to the user / administrator. The user / administrator feeds back the diagnostic results to the diagnostic output module. The diagnostic output module transmits the feedback data to the auxiliary management module. The auxiliary management module analyzes the feedback data and optimizes the diagnostic system. If the diagnosis is correct, it updates the Linux fault knowledge base, optimizes data collection and storage.

[0109] The system fault diagnosis method provided in this application obtains and stores logs, error messages and other contextual data during the operation of the Linux system. Subsequently, after using a large language model to perform a preliminary analysis of the input fault description information, it combines the fault data fragments extracted from the database and the relevant historical fault cases, solutions and technical documents retrieved from the knowledge base to generate a diagnostic report with basis support. By building a complete Linux fault knowledge base to provide external knowledge support for diagnosis, there is no need to train the language model with a large number of annotated historical fault samples, which reduces the dependence on training data and ensures that a high diagnostic accuracy can be maintained even when data is scarce. Secondly, the diagnostic conclusions are generated based on traceable information in the knowledge base. Users or system administrators can clearly understand the diagnostic basis and reasoning path, which enhances the transparency and credibility of the system and improves the interpretability of the diagnostic report. In addition, the Linux fault knowledge base can be continuously updated and expanded according to the development of the Linux system. New vulnerability information, bug repair solutions, community Q&A and other content can be integrated into the knowledge system, enabling the diagnostic system to adapt to the ever-changing technical environment and fault types. Subsequently, users or administrators can provide feedback on the diagnostic report and dynamically adjust the knowledge base content and system parameters based on the feedback information. The system can be continuously improved and perfected to adapt to the ever-changing fault diagnosis needs and further enhance the system's intelligence level and diagnostic accuracy.

[0110] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0111] Based on the above embodiments, Figure 4 This is a schematic diagram of the structure of a system fault diagnosis device provided in an embodiment of the present application. The system fault diagnosis device 400 includes an acquisition module 401, a first extraction module 402, a second extraction module 403, and a generation module 404, wherein:

[0112] Acquisition module 401, used to obtain fault description information of the target system;

[0113] A first extraction module 402 is configured to extract fault data segments from a pre-built database based on the fault description information, wherein the database is configured to store relevant data of the target system;

[0114] The second extraction module 403 is used to extract fault knowledge fragments from a pre-built knowledge base based on the fault description information, wherein the knowledge base is used to store relevant knowledge of system fault diagnosis;

[0115] The generating module 404 is configured to perform fault diagnosis on the target system according to the fault data segments and the fault knowledge segments, and generate a diagnosis report.

[0116] Optionally, the second extraction module 403 is used to:

[0117] Convert the fault description information into a vector representation using a pre-trained word vector model to obtain at least one word vector, where the at least one word vector is at least one numerical vector obtained by mapping at least one word item to a preset dimension, and the at least one word item is obtained by performing word segmentation processing on the fault description information;

[0118] A pre-trained multi-dimensional feature model is used to extract fault knowledge fragments from a pre-built knowledge base based on at least one word vector and fault description information.

[0119] Among them, the multi-dimensional feature model includes a basic feature layer, a semantic enhancement layer and a structural feature layer.

[0120] Optionally, the second extraction module 403 is used to:

[0121] Calculating a word frequency weight of at least one word item according to at least one word vector through a basic feature layer to determine a fault keyword item related to the fault description information;

[0122] Generate multiple context-aware semantic vectors based on the fault description information and documents included in the knowledge base through the semantic enhancement layer;

[0123] The non-text data in the fault data segment is converted into a structural feature vector through the structural feature layer;

[0124] Based on the word frequency weight, multiple semantic vectors and structural feature vectors of at least one word, fault knowledge fragments are indexed from the knowledge base.

[0125] Optionally, the second extraction module 403 is used to:

[0126] Counting the number of occurrences of at least one term in each preset document included in the knowledge base to obtain a first frequency;

[0127] Counting the number of occurrences of at least one term in all preset documents included in the knowledge base according to a preset weight to obtain a second frequency;

[0128] A term frequency weight of at least one term is calculated according to the first frequency and the second frequency.

[0129] Among them, the multiple semantic vectors include knowledge base document vectors and fault query vectors.

[0130] Optionally, the second extraction module 403 is used to:

[0131] Performing vectorized encoding on the fault description information and / or the fault data fragment to obtain a fault query vector;

[0132] Vectorized encoding is performed on at least one preset document included in the knowledge base or at least one target document corresponding to the fault keyword item to obtain a knowledge base document vector.

[0133] Optionally, the second extraction module 403 is used to:

[0134] Calculating basic feature similarity based on the word frequency weight of at least one word, wherein the basic feature similarity is used to evaluate the lexical similarity of different texts;

[0135] Calculate semantic feature similarity based on multiple semantic vectors, where semantic feature similarity is used to evaluate the semantic similarity of different texts;

[0136] Calculate the structural feature similarity based on the structural feature vector, where the structural feature similarity is used to evaluate the structural similarity of different texts;

[0137] The pre-trained weight prediction model is used to adjust the similarity weights of different network layers in the multi-dimensional feature model according to the target fault type, where the target fault type is determined based on the fault description information;

[0138] The comprehensive similarity is calculated based on the adjusted similarity weights of different network layers, basic feature similarity, semantic feature similarity, and structural feature similarity;

[0139] At least one target content in at least one preset document included in the knowledge base and having a comprehensive similarity greater than a preset threshold is used as a fault knowledge fragment.

[0140] Optionally, the first extraction module 402 is configured to:

[0141] The fault data segments corresponding to the fault description information are extracted from the pre-built database through the pre-trained language model.

[0142] Optionally, the generating module 404 is used to:

[0143] The fault data fragments and fault knowledge fragments are input into the language model for fault diagnosis, and a diagnosis report output by the language model is obtained.

[0144] Optionally, the generating module 404 is used to:

[0145] During the process of generating the diagnostic report, setting constraints and / or a maximum length limit, wherein the constraints include at least one of the fault cause analysis, feasible solutions, and maintenance suggestions, and the maximum length limit is used to limit the length of the generated text;

[0146] The fault data fragment and the fault knowledge fragment are input into the language model for fault diagnosis, and a diagnosis report output by the language model that meets the constraint conditions and / or maximum length limit is obtained.

[0147] Optionally, the system fault diagnosis device 400 is used to:

[0148] The diagnostic report is presented to the target user in at least one form of a structured web page interface, a command line interface, and a graphical interactive interface.

[0149] Optionally, the system fault diagnosis device 400 is used to:

[0150] Receive feedback from target users regarding the diagnostic report, wherein the feedback includes diagnostic opinion information and / or new fault information;

[0151] Adjust and optimize the knowledge base and / or database based on the diagnostic opinion information to regenerate the diagnostic report based on the fault description information or new fault information; or

[0152] Regenerate the diagnostic report based on the new fault information.

[0153] Optionally, the system fault diagnosis device 400 is used to:

[0154] If it is determined that the diagnosis report is correct, the fault description information, the fault data fragment and / or the diagnostic report are stored in a knowledge base; and / or,

[0155] The latest fault information and safety information of the target system is added to the knowledge base.

[0156] Optionally, the system fault diagnosis device 400 is used to:

[0157] Obtaining at least one original information of the target system's log information, performance indicators, kernel dump information, operation information, configuration information, and access information;

[0158] Use natural language processing algorithms to extract keyword information from log information;

[0159] Identify performance anomalies in performance indicators through statistical analysis algorithms;

[0160] At least one of original information, keyword information and performance abnormality information is stored in a database.

[0161] For the description of the features in the embodiment corresponding to the system fault diagnosis device, reference can be made to the relevant description of the embodiment corresponding to the system fault diagnosis method, which will not be repeated here.

[0162] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned system fault diagnosis method embodiments.

[0163] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned system fault diagnosis method embodiments when running.

[0164] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0165] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned system fault diagnosis method embodiments are implemented.

[0166] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned system fault diagnosis method embodiments are implemented.

[0167] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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.

[0168] The above is a detailed introduction to a system fault diagnosis method provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only intended to help understand the method and core ideas of the present application. It should be pointed out that, for those skilled in the art, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A system fault diagnosis method, characterized in that: include: Obtain fault description information of the target system; Extracting fault data fragments from a pre-built database based on the fault description information, wherein the database is used to store relevant data of the target system; Extracting fault knowledge fragments from a pre-built knowledge base based on the fault description information, wherein the knowledge base is used to store relevant knowledge of system fault diagnosis; Performing fault diagnosis on the target system according to the fault data fragment and the fault knowledge fragment, and generating a diagnosis report; The extracting of fault knowledge fragments from a pre-built knowledge base based on the fault description information includes: The fault description information is converted into a vector representation using a pre-trained word vector model to obtain at least one word vector, wherein the at least one word vector is at least one word item mapped to at least one numerical vector of a preset dimension, and the at least one word item is obtained by performing word segmentation processing on the fault description information; and fault knowledge fragments are extracted from a pre-built knowledge base based on the at least one word vector and the fault description information using a pre-trained multi-dimensional feature model, including: The multidimensional feature model includes a basic feature layer, a semantic enhancement layer and a structural feature layer; the basic feature layer calculates the word frequency weight of the at least one term based on the at least one word vector to determine the fault keyword term related to the fault description information; the semantic enhancement layer generates multiple semantic vectors with context-awareness capabilities based on the fault description information and the documents included in the knowledge base; the structural feature layer converts the non-text data in the fault data segment into a structural feature vector; based on the word frequency weight of the at least one term, the multiple semantic vectors and the structural feature vector, the fault knowledge segment is indexed from the knowledge base.

2. The method according to claim 1, characterized in that The calculating the word frequency weight of the at least one word item according to the at least one word vector includes: Counting the number of occurrences of the at least one term in each preset document included in the knowledge base to obtain a first frequency; Counting the number of occurrences of the at least one term in all preset documents included in the knowledge base according to a preset weight to obtain a second frequency; A term frequency weight of the at least one term is calculated according to the first frequency and the second frequency.

3. The method according to claim 1, characterized in that The multiple semantic vectors include a knowledge base document vector and a fault query vector, and the generating of the multiple semantic vectors with context-awareness capability by the semantic enhancement layer based on the fault description information and the documents included in the knowledge base includes: Performing vectorized encoding on the fault description information and / or the fault data segment to obtain the fault query vector; Vectorized encoding is performed on at least one preset document included in the knowledge base or at least one target document corresponding to the fault keyword item to obtain the knowledge base document vector.

4. The method according to claim 1, wherein The step of indexing fault knowledge fragments from the knowledge base based on the word frequency weight of the at least one word, the multiple semantic vectors, and the structural feature vector includes: Calculating a basic feature similarity based on the word frequency weight of the at least one word, wherein the basic feature similarity is used to evaluate the lexical similarity of different texts; Calculating semantic feature similarity based on the multiple semantic vectors, wherein the semantic feature similarity is used to evaluate the semantic similarity between different texts; Calculating structural feature similarity based on the structural feature vector, wherein the structural feature similarity is used to evaluate the structural similarity of different texts; Adjusting the similarity weights of different network layers in the multi-dimensional feature model according to a target fault type using a pre-trained weight prediction model, wherein the target fault type is determined according to the fault description information; Calculating the comprehensive similarity based on the adjusted similarity weights of different network layers, the basic feature similarity, the semantic feature similarity, and the structural feature similarity; At least one target content in at least one preset document included in the knowledge base, whose comprehensive similarity is greater than a preset threshold, is used as a fault knowledge fragment.

5. The method according to claim 1, wherein Extracting the fault data fragment from a pre-built database based on the fault description information includes: Extracting fault data segments corresponding to the fault description information from a pre-built database using a pre-trained language model; The performing fault diagnosis on the target system according to the fault data fragment and the fault knowledge fragment and generating a diagnosis report includes: The fault data segment and the fault knowledge segment are input into the language model to perform fault diagnosis, and a diagnosis report output by the language model is obtained.

6. The method according to claim 5, characterized in that Inputting the fault data segment and the fault knowledge segment into the language model for fault diagnosis, and obtaining a diagnosis report output by the language model, includes: During the process of generating the diagnostic report, setting constraints and / or a maximum length limit, wherein the constraints include at least one of a fault cause analysis, a feasible solution, and a maintenance suggestion, and the maximum length limit is used to limit the length of the generated text; The fault data segment and the fault knowledge segment are input into the language model to perform fault diagnosis, and a diagnosis report output by the language model that meets the constraint condition and / or the maximum length limit is obtained.

7. The method according to claim 1, characterized in that After performing fault diagnosis on the target system according to the fault data fragment and the fault knowledge fragment and generating a diagnosis report, the method further includes: The diagnostic report is presented to a target user in at least one of a structured web page interface, a command line interface, and a graphical interactive interface.

8. The method according to claim 7, characterized in that After presenting the diagnostic report to the target user in at least one of a structured web page interface, a command line interface, and a graphical interactive interface, the method further includes: receiving feedback from the target user regarding the diagnostic report, wherein the feedback includes diagnostic opinion information and / or new fault information; Adjust and optimize the knowledge base and / or the database according to the diagnostic opinion information to regenerate a diagnostic report according to the fault description information or the new fault information; or A diagnostic report is regenerated according to the new fault information.

9. The method according to claim 1, characterized in that After performing fault diagnosis on the target system according to the fault data fragment and the fault knowledge fragment and generating a diagnosis report, the method further includes: If it is determined that the diagnosis in the diagnostic report is correct, storing the fault description information, the fault data fragment and / or the diagnostic report in the knowledge base; and / or, The acquired latest fault information and safety information of the target system is added to the knowledge base.

10. The method according to claim 1, characterized in that Before extracting the fault data fragment from the pre-built database based on the fault description information, the method further includes: Obtaining at least one original information of the target system, including log information, performance indicators, kernel dump information, operation information, configuration information, and access information; Extracting keyword information from the log information using a natural language processing algorithm; Identifying performance anomaly information in the performance indicators through statistical analysis algorithms; The at least one original information, the keyword information and the performance abnormality information are stored in the database.

11. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the system fault diagnosis method according to any one of claims 1 to 10 when executing the computer program.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the system fault diagnosis method according to any one of claims 1 to 10.

13. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the system fault diagnosis method according to any one of claims 1 to 10 are implemented.

Images