Multi-dimensional system fault analysis method and device, computer device and readable storage medium
Patent Information
- Application Number
- CN202610866986.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-16
- Publication Date
- 2026-10-23
AI Technical Summary
[0002]当前系统故障定位技术主要分为两类:一是基于固定规则的专家系统,通过预定义的映射关系进行匹配,虽具针对性但灵活性与覆盖面不足,难以应对复杂多变的故障场景;二是基于传统机器学习模型的方案,虽能从历史数据中学习,但模型推理和泛化能力有限,无法有效处理未知故障或进行多维度关联推理
[0008]本申请实施例的多维度系统故障分析方法、装置、计算机设备和可读存储介质,采集从硬件层到应用层的多维度、异构监控数据,并进行预处理以及赋予其基于运维经验的层级权重。然后将数据构造为规范的提示词输入给AI大模型,由大模型执行模拟专家思维的、具有优先级的根源故障分析,输出故障分析结果。本申请实现了多源异构监控数据的深度融合与智能关联分析,能够在无需大量预定义规则的前提下,自适应识别复杂、多变及未知类型的系统故障,显著提升故障定位的准确性、实时性与覆盖范围。同时强化模型的泛化能力与关联推理能力,实现对多源、异构数据的深度挖掘与全局关联分析,从而在复杂系统场景下实现更高效、更鲁棒的故障定位,提高系统运维效率与稳定性。
Smart Images

Figure CN122963842A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing, and in particular to a multi-dimensional system fault analysis method, apparatus, computer equipment, and readable storage medium. Background Technology
[0002] Current system fault location technologies are mainly divided into two categories: one is expert systems based on fixed rules, which match through predefined mapping relationships. Although they are targeted, they lack flexibility and coverage, making it difficult to cope with complex and ever-changing fault scenarios. The other is solutions based on traditional machine learning models. Although they can learn from historical data, their model reasoning and generalization capabilities are limited, making it impossible to effectively handle unknown faults or perform multi-dimensional correlation reasoning. Summary of the Invention
[0003] In view of this, this application provides a multi-dimensional system fault analysis method, apparatus, computer equipment, and readable storage medium.
[0004] In a first aspect, embodiments of this application provide a multi-dimensional system fault analysis method, including: Trigger data collection to collect monitoring data from a multi-level monitoring system; Data preprocessing is performed on the monitoring data of each of the monitoring systems, and a corresponding fault weight coefficient is set for the monitoring data of each of the monitoring systems. The monitoring data containing the fault weight coefficient is filled into the preset prompt word template to form prompt words; Based on the aforementioned prompts, the AI large-scale model analysis engine is invoked to perform logical reasoning and obtain fault analysis results.
[0005] Secondly, embodiments of this application provide a multi-dimensional system fault analysis device, including: The data acquisition module is used to trigger data acquisition and collect monitoring data from a multi-level monitoring system. The preprocessing module is used to preprocess the monitoring data of each of the monitoring systems and set corresponding fault weight coefficients for the monitoring data of each of the monitoring systems. The prompt word generation module is used to fill the monitoring data with the fault weight coefficient into the preset prompt word template to form prompt words; The fault analysis module is used to call the AI large model analysis engine to perform logical reasoning based on the prompt words and obtain fault analysis results.
[0006] Thirdly, embodiments of this application provide a computer device including a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions implementing the steps of the method as described in the first aspect when executed by the processor.
[0007] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method as described in the first aspect.
[0008] This application's multi-dimensional system fault analysis method, apparatus, computer equipment, and readable storage medium collect multi-dimensional, heterogeneous monitoring data from the hardware layer to the application layer, preprocess the data, and assign hierarchical weights based on operational experience. The data is then constructed into standardized prompts and input into an AI model, which performs priority-based root cause fault analysis simulating expert thinking, and outputs the fault analysis results. This application achieves deep fusion and intelligent correlation analysis of multi-source heterogeneous monitoring data, enabling adaptive identification of complex, variable, and unknown types of system faults without requiring numerous predefined rules, significantly improving the accuracy, real-time performance, and coverage of fault location. Simultaneously, it enhances the model's generalization and correlation reasoning capabilities, achieving deep mining and global correlation analysis of multi-source, heterogeneous data, thereby achieving more efficient and robust fault location in complex system scenarios and improving system operation and maintenance efficiency and stability.
[0009] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description
[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating the multi-dimensional system fault analysis method according to an embodiment of this application is shown; Figure 2 A logical schematic diagram of the multi-dimensional system fault analysis method according to an embodiment of this application is shown; Figure 3 A structural block diagram of a multi-dimensional system fault analysis device according to an embodiment of this application is shown; Figure 4 A structural block diagram of a computer device according to an embodiment of this application is shown. Detailed Implementation
[0011] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.
[0012] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.
[0013] Existing system fault location technologies suffer from two major technical bottlenecks, making them ill-suited for modern, complex, and dynamic IT environments: (1) The rigidity and insufficient coverage of rule-based expert systems: their core relies on a predefined “fault-root cause-measure” mapping rule base. This method essentially solidifies human experience, the maintenance cost of the rule base is high, and it is difficult to exhaust all fault scenarios. When new faults or unknown combinations of faults occur outside the rule base, the system cannot effectively handle them, resulting in failure to locate the faults. It has poor flexibility and adaptability.
[0014] (2) Limitations and weak generalization ability of traditional machine learning models: Although models trained on historical data (such as recurrent neural networks RNNs) have a certain learning ability, their ability has a ceiling. These models are essentially "pattern matching" tools, which are good at learning from similar failures that have occurred in the past, but their reasoning and generalization abilities are seriously insufficient for new failures that have never been seen before or new phenomena that arise due to rapid system iteration.
[0015] In summary, the common core deficiency of existing technologies lies in the lack of an intelligent central processing unit with true "analysis" and "reasoning" capabilities. This makes it impossible to process massive amounts of heterogeneous information and cope with unknown challenges as flexibly and comprehensively as human experts. To address this problem, this application proposes a multi-dimensional system fault location scheme based on an AI large-scale model. The aim is to construct a unified and intelligent fault analysis central processing unit by introducing an artificial intelligence large-scale model. The following detailed description, in conjunction with the accompanying drawings, through specific embodiments and application scenarios, illustrates the multi-dimensional system fault analysis method, apparatus, computer equipment, and readable storage medium provided by this application. Unless otherwise specified, the following embodiments and features can be combined with each other.
[0016] This application provides a multi-dimensional system fault analysis method, such as... Figure 1 and Figure 2 As shown, the method includes: Step 101: Trigger data acquisition to collect monitoring data from the multi-level monitoring system.
[0017] This step triggers the data collection process, collecting monitoring data from a multi-level monitoring system. Data collection can be triggered by upper-level application monitoring, such as a sudden increase in transaction volume or a decrease in success rate, or automatically triggered by a critical alarm generated by any layer of the monitoring system.
[0018] The multi-layered monitoring system includes: hardware layer system, network layer system, cloud platform layer system, database layer system, and application layer system. Monitoring data is retrieved in real-time or near real-time from all layers of the monitoring system. This monitoring data includes current status data and historical alarm information.
[0019] In one embodiment of this application, a series of adapters are used to connect to different types of monitoring systems: (1) Hardware layer adapter: connects to the hardware layer system, i.e., the device hardware alarm system, and collects signals such as server status, storage array health, and power alarm. (2) Network layer adapter: connects to the network layer system, i.e., the information technology network management system, and collects information such as network traffic, packet loss rate, latency, and port status. (3) Cloud platform layer adapter: connects to the cloud platform layer system, i.e., the virtual machine management platform and container cloud management platform, and collects data such as host load, virtual machine / container status, and resource utilization (CPU, memory, disk I / O). (4) Database layer adapter: connects to the database layer system, i.e., the basic software monitoring platform, and collects performance indicators such as database connection count, slow query, lock wait, and cache hit rate. (5) Application layer adapter: connects to the application layer system, i.e., the transaction monitoring system and log center, and collects information such as application transaction success rate, response time, error log, and exception stack.
[0020] By collecting multi-dimensional data, we can provide data support for subsequent root cause analysis of failures.
[0021] Step 102: Perform data preprocessing on the monitoring data of each monitoring system, and set corresponding fault weight coefficients for the monitoring data of each monitoring system.
[0022] In this step, the aggregated monitoring data is preprocessed, and each piece of monitoring data is labeled with a fault weight coefficient of its respective level.
[0023] In one embodiment of this application, the data preprocessing of the monitoring data of each of the monitoring systems includes: The monitoring data collected from each of the monitoring systems is cleaned, formatted, and normalized; and the alarm levels of the monitoring data from different monitoring systems are mapped to a unified alarm level system.
[0024] In this embodiment, the collected heterogeneous data is cleaned, formatted, and normalized into standardized data objects defined within the system. Furthermore, alarm levels (such as critical, warning, and normal) from different monitoring systems are mapped to a unified alarm level system. This resolves the confusion in bank operations where different monitoring tools use different names and assign different levels to alarms of the same severity level, ensuring that the level standard for all alarms is unique, unified, comparable, and analyzable. It also provides standardized alarm level foundational data for subsequent weight assignment and large-scale model analysis and decision-making.
[0025] In one embodiment, a standard alarm level system is established, comprising four levels: Level 1 alarm P1, Level 2 alarm P2, Level 3 alarm P3, and Level 4 alarm P4, with alarm levels decreasing sequentially. The original alarm levels of all heterogeneous alarm sources are analyzed, and a mapping rule table between the original alarm levels and the standard alarm levels is established. An automated normalization mapping engine is configured, and the mapping rule table is integrated into the normalization mapping engine. During alarm level normalization, the normalization mapping engine automatically matches and standardizes the currently collected monitoring data (which includes alarm data).
[0026] Existing technologies face challenges in correlated analysis of multi-source heterogeneous monitoring data: monitoring systems at various levels, such as hardware, network, cloud platform, database, and application, are independent and have heterogeneous data formats. This makes it difficult for operations and maintenance personnel to perform effective correlation analysis and root cause tracing in a short time, especially in complex fault scenarios where information overload can actually prolong troubleshooting time. This application enables deep fusion and intelligent correlation analysis of multi-source heterogeneous monitoring data, linking and contextualizing previously independent monitoring data from hardware, network, cloud platform, database, and application within a single intelligent hub, thus solving the "data silo" problem in existing operations and maintenance.
[0027] In one embodiment of this application, setting a corresponding fault weight coefficient for the monitoring data of each monitoring system includes: Based on the hierarchy of the monitoring system, a fault weight coefficient is set for the monitoring data of the monitoring system; wherein, the hierarchy of the monitoring system is related to the fault impact range of the monitoring system, the larger the fault impact range, the lower the hierarchy, and the larger the fault weight coefficient.
[0028] In this embodiment, the correspondence between hierarchical levels and fault weight coefficients is pre-stored, and each level of data is preset with a fault weight coefficient. The fault weight coefficient setting follows the principle of prioritizing the underlying infrastructure, with the fault impact scope, system importance, and technology stack dependency as the core basis: the lower the level, the greater the impact and the more irreplaceable the system, that is, the lower the level, the greater the weight.
[0029] In one embodiment of this application, the hardware layer system, the network layer system, the cloud platform layer system, the database layer system, and the application layer system are sequentially arranged in a higher hierarchy and the fault weight coefficients are sequentially arranged in a lower hierarchy.
[0030] For example, the hardware layer alarms have the highest weight, set to W_h, such as 2.0; the network layer is next, set to W_n, such as 0.9; the cloud platform layer is next, set to W_p, such as 0.8; the database layer is set to W_d, such as 0.7; and the application layer has the lowest weight, set to W_a, such as 0.6. This weight will serve as key prior knowledge for subsequent large-scale model analysis and decision-making.
[0031] Existing troubleshooting methods lack clear weighting guidelines, leading operations and maintenance personnel to start troubleshooting from non-root causes such as the application layer, resulting in a significant amount of ineffective work. This application addresses this by establishing a "lower-level weight priority" strategy, forcing the analysis process to follow the most efficient path, directly targeting the root cause of the problem, significantly improving troubleshooting efficiency, and resolving the issues of unclear troubleshooting path priorities and low efficiency.
[0032] In one embodiment of this application, after setting the fault weight coefficient of the monitoring data of the monitoring system based on the hierarchy of the monitoring system, the method further includes: Based on the historical fault alarm information of the monitoring system, the fault weight coefficient of the monitoring data of the monitoring system is adjusted; wherein, the historical fault alarm information includes at least one of the fault duration and the number of faults within a preset time period.
[0033] In this embodiment, after the fault weight coefficient is determined based on the hierarchy, the determined fault weight coefficient can be adjusted based on the fault duration and the number of faults within a preset time period.
[0034] The longer the fault duration and the longer the impact on business, the higher the weight; the shorter the fault duration and the higher the recovery efficiency, the higher the weight can be maintained or appropriately reduced. For example, if the average fault duration of the equipment hardware alarm system is as long as 30 minutes in the past 3 months, and the longest fault lasted for 1 hour, far exceeding the historical average, it indicates a decline in hardware system stability, and its weight can be temporarily increased from 2.0 to 2.1; if the average fault duration of the domestically developed network management system is only 5 minutes in the past 3 months, and there are no long-term fault records, the weight can be maintained at 0.9, or reduced to 0.85 after continuous optimization of system stability.
[0035] A higher number of failures indicates poorer system stability, requiring a corresponding increase in weight, with a focus on strengthening monitoring and prioritizing fault handling. Conversely, fewer failures indicate higher stability, allowing the weight to remain unchanged or be appropriately reduced. For example, if a basic software monitoring platform experiences 8 failures in the past 3 months (an average of more than 2 per month), far exceeding other systems at the same level, its weight can be increased from 0.7 to 0.8. If a system (such as a log center) has had no failures in the past 6 months, its original weight of 0.6 can be maintained, or it can be appropriately reduced by 0.1 to 0.5 when operational resources are strained.
[0036] This application adjusts weights by using historical fault alarm information, making the weight adjustments more data-supported and more in line with the actual operating status of the system, thus making up for the lack of historical operating pattern references.
[0037] Step 103: Fill the monitoring data with the fault weight coefficient into the preset prompt word template to form a prompt word.
[0038] In this step, a prompt word is constructed by filling the preprocessed, weighted, multi-dimensional monitoring data into a preset prompt word template to create a structured prompt word.
[0039] In one embodiment of this application, the preset prompt word template includes a role definition unit, a rule unit, a data input unit, and a task instruction unit; wherein, the role definition unit is used to define the roles of the AI large model, the rule unit is used to define the rules for fault root cause analysis, the fault weight coefficient is used in the rules to indicate the analysis priority of the corresponding monitoring system, the data input unit is used to provide the monitoring data, and the task instruction unit is used to instruct the AI large model to perform tasks.
[0040] In this embodiment, the preprocessed, weighted, multi-dimensional monitoring data is constructed into a structured prompt word. The prompt word template exemplarily includes: Role Definition Unit: Used to clarify the role positioning of the large model. The role positioning is a senior IT operations expert, and this expert has the ability to perform systemic failure root cause analysis from the bottom layer to the top layer of IT architecture. An example description is "You are a senior IT operations expert who is good at performing systemic failure root cause analysis from the bottom layer to the top layer".
[0041] Rule Unit: Used to clarify the core rules and prerequisites for root cause analysis. These rules contain at least two core elements: first, failures in lower-level IT systems may cause abnormal behavior in upper-level systems, and the alarm weight of the lower-level system is higher than that of the upper-level system; second, the root cause analysis path should prioritize checking the levels with higher alarm weights. An example of this is expressed as: "Please follow these rules for analysis: 1. Failures in the lower layer (hardware, network) may cause abnormal behavior in the upper layer, and its alarm weight is higher. 2. The analysis path should prioritize checking the levels with higher weights."
[0042] Data Input Unit: This unit provides the basic data required for root cause analysis of faults. The data is presented in the form of a structured list, clearly containing the real-time operating status and alarm information of each level of the IT architecture. Each data entry is marked with the alarm weight of the corresponding level, ensuring that the large model can be analyzed based on the structured data.
[0043] Task instruction unit: Used to clarify the core execution task of the large model. The instruction content is to complete the root cause analysis of IT operation and maintenance failures based on background and rules and multi-dimensional data input, and output corresponding failure handling suggestions. An example expression is "Please perform root cause analysis based on the above information and provide handling suggestions".
[0044] Step 104: Based on the prompt words, call the AI large model analysis engine to perform logical reasoning and obtain the fault analysis results.
[0045] This step involves calling the API of the AI large model analysis engine. The AI large model refers to a language model that has been pre-trained on a large scale, such as the DeepSeek large model, which has powerful natural language understanding, logical reasoning and knowledge generation capabilities.
[0046] The AI model uses its learned general knowledge and embedded operational rules and weight information in the prompts to perform logical reasoning. The AI model prioritizes high-weight monitoring data, analyzes whether it is sufficient to explain the fault phenomenon, and verifies it sequentially downwards, ultimately identifying the most likely root cause.
[0047] This application provides a unified fault location scheme with an AI big data model as the intelligent analysis hub. This scheme collects multi-dimensional, heterogeneous monitoring data from the hardware layer to the application layer, preprocesses it, and assigns hierarchical weights based on operational experience. The data is then constructed into standardized prompts and input into the AI big data model, which performs priority-based root cause fault analysis simulating expert thinking and outputs the fault analysis results.
[0048] In one embodiment of this application, after obtaining the fault analysis results, the method further includes: The fault analysis results are analyzed to obtain a structured fault report, which includes the root cause of the fault, the root cause analysis chain, and a list of handling suggestions. The structured fault report is pushed to the equipment of maintenance personnel or the automated maintenance system.
[0049] In this embodiment, the fault analysis results generated by the AI large model are parsed into standardized fault reports.
[0050] Specifically, the natural language text returned by the AI large model is parsed into structured output, including: (1) the most likely root cause: clearly indicating the level and specific component of the fault, for example: the root cause is a network layer - core switch port failure. (2) the cause analysis chain: briefly describing the logical chain from the high-level phenomenon to the low-level root cause, for example: the application transaction timeout is due to the slow database response, and the slow database response is due to the high packet loss rate of the virtual machine host network. (3) the list of handling suggestions: providing specific and actionable handling steps, for example: contacting the network team to check the core switch port; migrating the database virtual machine to another host.
[0051] Finally, the structured fault report is pushed to the maintenance personnel's equipment or automated maintenance system via API or graphical interface.
[0052] This application achieves the following technical effects: This application integrates and contextualizes previously independent monitoring data from hardware, networks, cloud platforms, databases, and applications within a single intelligent hub. This enables deep fusion and intelligent correlation analysis of multi-source heterogeneous monitoring data, resolving the data silo problem in traditional operations and maintenance. For example, the AI model can understand the causal relationship between "a surge in slow queries in a database" and "a large number of error packets appearing on the network card of the virtual machine host," rather than simply listing two alarms. This deep, cross-level correlation analysis capability is difficult to achieve with traditional manual or rule-based automated systems.
[0053] Existing technologies suffer from high subjectivity and a lack of unified standards in fault location. Fault diagnosis heavily relies on the personal experience and knowledge of maintenance personnel, leading to inconsistent results and even misjudgments due to different personnel employing different troubleshooting paths and judgment criteria. This hinders the formation of stable and reliable maintenance quality assurance. This application eliminates inconsistencies in handling processes and results caused by differences in the personal experience, skill level, or subjective judgment of maintenance personnel by using a unified AI model for analysis of multi-dimensional data. This achieves standardization and objectivity in fault location, significantly improving the consistency and reliability of handling. For example, regardless of which maintenance personnel is on duty, the same root cause location and handling suggestions can be output for the same fault phenomenon, achieving consistent treatment of the same problem. This establishes stable and predictable maintenance service quality standards and effectively avoids significant system losses due to human error.
[0054] This application simulates and solidifies the bottom-up, priority-based troubleshooting approach of senior experts. Through a pre-defined hierarchical weighting mechanism, it guides the AI model to prioritize investigating the underlying infrastructure most likely to cause global problems. This achieves a significant improvement in the accuracy and efficiency of root cause identification, drastically reducing the average repair time. For example, it can quickly bypass application-layer symptoms and directly point to the root causes such as network and hardware issues. The process, which traditionally requires hours or even longer for manual troubleshooting, is reduced to minutes, achieving root cause identification within minutes or even seconds. This gains valuable time for rapid business recovery and greatly reduces losses caused by business interruptions.
[0055] Furthermore, large AI models have strong reasoning and generalization capabilities, which are superior to traditional machine learning models. They can effectively handle unknown faults or perform multi-dimensional correlation reasoning.
[0056] As a specific implementation of the above-mentioned multi-dimensional system fault analysis method, this application provides a multi-dimensional system fault analysis device. For example... Figure 3 As shown, the multi-dimensional system fault analysis device 300 includes: a data acquisition module 301, a preprocessing module 302, a prompt word generation module 303, and a fault analysis module 304.
[0057] Among them, the data acquisition module 301 is used to trigger data acquisition and collect monitoring data from the multi-level monitoring system; The preprocessing module 302 is used to preprocess the monitoring data of each monitoring system and set a corresponding fault weight coefficient for the monitoring data of each monitoring system. The prompt word generation module 303 is used to fill the monitoring data with the fault weight coefficient into the preset prompt word template to form a prompt word; The fault analysis module 304 is used to call the AI large model analysis engine to perform logical reasoning based on the prompt words and obtain fault analysis results.
[0058] Furthermore, the preprocessing module 302 is specifically used for: The monitoring data collected from each of the aforementioned monitoring systems is cleaned, formatted, and normalized; and, The alarm levels of monitoring data from different monitoring systems are mapped to a unified alarm level system.
[0059] Furthermore, the preprocessing module 302 is specifically used for: Based on the hierarchy of the monitoring system, a fault weight coefficient is set for the monitoring data of the monitoring system; wherein, the hierarchy of the monitoring system is related to the fault impact range of the monitoring system, the larger the fault impact range, the lower the hierarchy, and the larger the fault weight coefficient.
[0060] Furthermore, the multi-level monitoring system includes: a hardware layer system, a network layer system, a cloud platform layer system, a database layer system, and an application layer system, wherein the fault weight coefficients of the hardware layer system, the network layer system, the cloud platform layer system, the database layer system, and the application layer system decrease sequentially.
[0061] Furthermore, the device further includes: a weight adjustment module, used for: Based on the historical fault alarm information of the monitoring system, the fault weight coefficient of the monitoring data of the monitoring system is adjusted; wherein, the historical fault alarm information includes at least one of the fault duration and the number of faults within a preset time period.
[0062] Furthermore, the preset prompt word template includes a role definition unit, a rule unit, a data input unit, and a task instruction unit; wherein, the role definition unit is used to define the roles of the AI large model, the rule unit is used to define the rules for fault root cause analysis, the fault weight coefficient is used in the rules to indicate the analysis priority of the corresponding monitoring system, the data input unit is used to provide the monitoring data, and the task instruction unit is used to instruct the AI large model to perform tasks.
[0063] Furthermore, the device also includes: a report generation module, used for: The fault analysis results are analyzed to obtain a structured fault report, which includes the root cause of the fault, the root cause analysis chain, and a list of handling suggestions. The structured fault report is pushed to the equipment of maintenance personnel or the automated maintenance system.
[0064] The multi-dimensional system fault analysis device 300 in this application embodiment can be a computer device or a component within the computer device, such as an integrated circuit or a chip. The multi-dimensional system fault analysis device 300 provided in this application embodiment can achieve… Figure 1 The various processes implemented in the multi-dimensional system fault analysis method implementation example will not be repeated here to avoid repetition.
[0065] This application also provides a computer device, such as... Figure 4 As shown, the computer device 400 includes a processor 401 and a memory 402. The memory 402 stores programs or instructions that can run on the processor 401. When the program or instructions are executed by the processor 401, they implement the various steps of the above-described multi-dimensional system fault analysis method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.
[0066] The memory 402 can be used to store software programs and various data. The memory 402 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 402 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 402 in this embodiment includes, but is not limited to, these and any other suitable types of memory.
[0067] Processor 401 may include one or more processing units; optionally, processor 401 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 401.
[0068] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described multi-dimensional system fault analysis method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.
[0069] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.
[0070] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.
Claims
1. A multi-dimensional system fault analysis method, characterized in that, include: Trigger data collection to collect monitoring data from a multi-level monitoring system; Data preprocessing is performed on the monitoring data of each of the monitoring systems, and a corresponding fault weight coefficient is set for the monitoring data of each of the monitoring systems. The monitoring data containing the fault weight coefficient is filled into the preset prompt word template to form prompt words; Based on the aforementioned prompts, the AI large-scale model analysis engine is invoked to perform logical reasoning and obtain fault analysis results.
2. The method according to claim 1, characterized in that, The data preprocessing for the monitoring data of each of the monitoring systems includes: The monitoring data collected from each of the aforementioned monitoring systems is cleaned, formatted, and normalized; and, The alarm levels of monitoring data from different monitoring systems are mapped to a unified alarm level system.
3. The method according to claim 1, characterized in that, The step of setting corresponding fault weight coefficients for the monitoring data of each monitoring system includes: Based on the hierarchy of the monitoring system, a fault weight coefficient is set for the monitoring data of the monitoring system; wherein, the hierarchy of the monitoring system is related to the fault impact range of the monitoring system, the larger the fault impact range, the lower the hierarchy, and the larger the fault weight coefficient.
4. The method according to claim 3, characterized in that, The multi-level monitoring system includes: a hardware layer system, a network layer system, a cloud platform layer system, a database layer system, and an application layer system, wherein the fault weight coefficients of the hardware layer system, the network layer system, the cloud platform layer system, the database layer system, and the application layer system decrease sequentially.
5. The method according to claim 3, characterized in that, After setting the fault weight coefficients of the monitoring data based on the hierarchy of the monitoring system, the method further includes: Based on the historical fault alarm information of the monitoring system, the fault weight coefficient of the monitoring data of the monitoring system is adjusted; wherein, the historical fault alarm information includes at least one of the fault duration and the number of faults within a preset time period.
6. The method according to claim 1, characterized in that, The preset prompt word template includes a role definition unit, a rule unit, a data input unit, and a task instruction unit; wherein, the role definition unit is used to define the roles of the AI large model, the rule unit is used to define the rules for fault root cause analysis, the fault weight coefficient is used in the rules to indicate the analysis priority of the corresponding monitoring system, the data input unit is used to provide the monitoring data, and the task instruction unit is used to instruct the AI large model to perform tasks.
7. The method according to claim 1, characterized in that, After obtaining the fault analysis results, the method further includes: The fault analysis results are analyzed to obtain a structured fault report, which includes the root cause of the fault, the root cause analysis chain, and a list of handling suggestions. The structured fault report is pushed to the equipment of maintenance personnel or the automated maintenance system.
8. A multi-dimensional system fault analysis device, characterized in that, include: The data acquisition module is used to trigger data acquisition and collect monitoring data from a multi-level monitoring system. The preprocessing module is used to preprocess the monitoring data of each of the monitoring systems and set corresponding fault weight coefficients for the monitoring data of each of the monitoring systems. The prompt word generation module is used to fill the monitoring data with the fault weight coefficient into the preset prompt word template to form prompt words; The fault analysis module is used to call the AI large model analysis engine to perform logical reasoning based on the prompt words and obtain fault analysis results.
9. A computer device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that run on the processor, the program or instructions being executed by the processor to implement the steps of the multi-dimensional system fault analysis method as described in any one of claims 1 to 7.
10. A readable storage medium having a program or instructions stored thereon, characterized in that, When the program or instructions are executed by the processor, they implement the steps of the multi-dimensional system fault analysis method as described in any one of claims 1 to 7.