Operation and maintenance database fault positioning system based on artificial intelligence

Abstract

The invention discloses an operation and maintenance database fault positioning system based on artificial intelligence, particularly relates to the technical field of database fault positioning, and comprises a distributed data acquisition module, a data analysis module, a fault positioning module, an alarm and notification module and an intelligent repair module. Accurate and real-time data acquisition can be ensured, influence on database performance is avoided, acquisition frequency is adaptively adjusted to optimize resource occupation, fault prediction accuracy is improved, fault reasons can be quickly positioned, operation and maintenance personnel can be timely notified, a comprehensive repair scheme can be provided for the operation and maintenance personnel, and maintenance efficiency is improved. And the database fault positioning and repairing efficiency, resource utilization, stability and reliability are integrally improved.

Description

Technical Field

[0001] This invention relates to the field of database fault location technology, and more specifically, to an artificial intelligence-based database fault location system. Background Technology

[0002] With the rapid development of information technology, databases are being used more and more widely in various industries, and their stable operation is crucial. However, databases may experience various failures during operation, affecting the normal operation of business.

[0003] Traditional database operation and maintenance mainly relies on manual experience for fault diagnosis and repair, which is inefficient and makes it difficult to accurately and quickly locate the cause of the fault. As the scale and complexity of databases increase, existing database fault location systems suffer from problems such as incomplete data collection, single analysis methods, and inaccurate fault location. At the same time, with the development of artificial intelligence, intelligent operation and maintenance has become a trend. Integrating artificial intelligence algorithms into database operation and maintenance to improve the efficiency of fault detection and handling and achieve refined and intelligent operation and maintenance is the future development direction.

[0004] A search revealed that Chinese patent CN114968727A discloses a fault location method for databases across infrastructure based on artificial intelligence operation and maintenance. This method applies artificial intelligence technology to the operation and maintenance of databases, connecting the database to information from infrastructure IaaS layer devices, and quickly performing fault location and root cause analysis based on database alarm information.

[0005] However, the above structure still has the following shortcomings in practical use:

[0006] 1. Only specific key performance indicator vectors of the IaaS infrastructure layer and a limited number of alarm information from the database are collected. The data collection is not comprehensive enough and cannot cover multiple key performance indicators of servers, networks and databases.

[0007] 2. It mainly utilizes the CNN convolutional neural network to output the alarm root cause with the highest probability, and the analysis method is relatively simple;

[0008] 3. It is difficult to dynamically adjust resource consumption and data collection strategies according to database load and failure risk, which may affect database performance or data comprehensiveness under different load conditions;

[0009] 4. In terms of fault repair, it only outputs the root cause of the alarm, and lacks the functions of automatic fault repair and detailed repair suggestions.

[0010] In response to the above situation, the present invention provides an artificial intelligence-based fault location system for operation and maintenance databases. Summary of the Invention

[0011] To overcome the aforementioned deficiencies of the prior art, the present invention provides an artificial intelligence-based fault location system for operation and maintenance databases to solve the problems mentioned in the background art.

[0012] To achieve the above objectives, the present invention provides the following technical solution: an artificial intelligence-based fault location system for operation and maintenance databases, which includes a distributed data acquisition module for comprehensively collecting key indicator data from the infrastructure layer of the operation and maintenance database;

[0013] The data analysis module performs joint and correlation analysis on the collected key indicator data, uses the random forest algorithm to establish a correlation model between data, and uses a long short-term memory network to learn from historical fault data to establish a fault prediction model.

[0014] The fault location module can quickly locate the cause of a database failure based on the results of the data analysis module.

[0015] The alarm and notification module promptly issues alarms and notifies maintenance personnel through various means when a database failure or potential failure is detected.

[0016] The intelligent repair module automatically attempts to perform simple fault repair operations based on the fault location results, and provides detailed repair suggestions for faults that cannot be repaired automatically.

[0017] Preferably, the key performance indicator data includes server performance indicators, network performance indicators, and database performance indicators, wherein;

[0018] Server performance metrics include, but are not limited to, CPU utilization, memory utilization, and disk I / O speed;

[0019] Network performance metrics include, but are not limited to, bandwidth utilization, latency, and packet loss rate;

[0020] Database performance metrics include, but are not limited to, query response time, transaction processing speed, and number of connections.

[0021] Preferably, the distributed data acquisition module adopts distributed data acquisition to ensure the real-time performance and accuracy of the data, while avoiding excessive impact on database performance; specifically;

[0022] S1. Set up a central control node and multiple data acquisition nodes distributed in different locations. The central control node is responsible for coordinating and managing the work of each acquisition node. Each acquisition node is responsible for specific data acquisition tasks. Each acquisition node can independently collect data from a specific part of the database infrastructure, including a specific server, network device, or part of the database instance.

[0023] S2. Use Kafka and RabbitMQ as message queues or HDFS as a distributed file system to transmit the collected data. The collection nodes send the data to the message queues or file systems, and the central control node or data analysis module can retrieve the data from these intermediate storages for processing.

[0024] Preferably, the distributed data acquisition module also has the function of adaptively adjusting the acquisition frequency, dynamically adjusting the acquisition frequency according to the database load and fault risk, so as to optimize resource consumption while ensuring data comprehensiveness;

[0025] S1. Continuously monitor database load metrics, including CPU utilization, memory utilization, disk I / O speed, and number of database connections. Establish a threshold system for load metrics. When the load exceeds a certain threshold, the database is considered to be in a high-load state, and when the load is below a certain threshold, the database is considered to be in a low-load state.

[0026] S2. Analyze historical fault data to identify fault modes related to database load. For example, when CPU utilization and memory utilization increase simultaneously, performance bottlenecks may occur, increasing the risk of faults. Use the data analysis module to predict potential fault risks and output the probability or level of fault risks based on the input indicator data.

[0027] S3. Based on the assessment results of database load and failure risk, dynamically adjust the data collection frequency. For example, when the database is under high load or the failure risk is high, reduce the collection frequency to reduce the impact on database performance. When the database is under low load or the failure risk is low, increase the collection frequency to ensure the comprehensiveness of the data.

[0028] Preferably, the data analysis module uses a logistic regression model for fault prediction, and the prediction probability formula is: P(y=1|X)=1 / (1+exp(-(w0+w1x1+w2x2+...+wnxn)));

[0029] Where y is the predicted result of whether a fault occurs, 1 indicates that a fault has occurred, and 0 indicates that a fault has not occurred; X is the input feature vector including various key indicator data; wi is the corresponding weight coefficient; and n is the number of features.

[0030] Suppose we want to analyze the relationship between CPU utilization (x), memory utilization (y1), and query response time (z). This can be achieved through the concept of linear regression: z = ax + b * y1 + c, where a and b are coefficients and c is a constant term.

[0031] Preferably, when a database malfunctions, the specific steps for quickly locating the cause of the malfunction based on the results of the data analysis module are as follows:

[0032] S1. Compare the current indicator data with the normal state data to identify abnormal indicators;

[0033] S1.1 Establish a normal state indicator database. The distributed data acquisition module continuously collects server performance indicators, network performance indicators and database performance indicators under normal operating conditions. Statistical analysis is performed on the collected normal state data to determine the reasonable range and statistical parameters such as mean and standard deviation of each indicator. For example, the average value of a certain indicator over a period of time plus or minus a few standard deviations is used as the upper and lower limits of the normal range.

[0034] S1.2 Real-time monitoring and comparison: Continuously monitor the key indicator data of the database during operation. When the database fails or is suspected of failing, immediately obtain the current indicator data and compare the current indicator data with the corresponding indicators in the normal state indicator database. If an indicator exceeds the normal range, mark it as an abnormal indicator.

[0035] S2. Use fault prediction models and correlation models to analyze the relationships between abnormal indicators and determine possible fault points;

[0036] S2.1 When abnormal indicators appear, these abnormal indicators are input into the pre-trained fault prediction model. If the fault prediction model outputs a high probability of fault occurrence, it means that these abnormal indicators match the known fault modes.

[0037] S2.2 Utilize the pre-established correlation model to analyze the relationship between abnormal indicators. For example, if it is found that CPU utilization and memory utilization both rise abnormally at the same time, and the correlation model shows that these two indicators are strongly correlated with database connection timeout failures, then it can be preliminarily determined that there may be a database connection timeout failure, and finally the failure can be displayed and located.

[0038] Preferably, the alarm information includes the fault type, fault location, and severity, and the notification method includes email, SMS, and instant messaging tools.

[0039] Preferably, when the intelligent repair module performs simple fault repair, specifically;

[0040] S1. Classify common database failure types, including network connection problems, server resource overload, and database configuration errors. For each common failure type, define corresponding simple repair operations. For example, for network connection problems, try restarting the network device or resetting the network connection; for server resource overload, try closing some unnecessary processes or adjusting the server resource allocation strategy; for database configuration errors, try reloading the correct configuration file.

[0041] S2. After the fault location module determines the cause of the fault, the intelligent repair module determines whether it falls within the scope of automatic repair based on the fault type. If it is an automatically repairable fault, the corresponding repair operation is triggered immediately by calling system commands, API interfaces, or using automated scripts to perform the repair operation.

[0042] Preferably, when the intelligent repair module provides detailed repair suggestions for faults that cannot be automatically repaired, specifically;

[0043] S1. By collecting historical failure cases, expert experience, and relevant technical documents, a knowledge base containing various database failures and their solutions is established. For each type of failure, possible causes, diagnostic methods, and detailed repair suggestions are recorded. For example, for database connection timeout failures, the knowledge base can record possible causes such as network problems, excessive database server load, database configuration errors, etc., as well as corresponding diagnostic methods and repair suggestions.

[0044] S2. When encountering a fault that cannot be automatically repaired, the intelligent repair module queries and matches the fault knowledge base based on the fault location results. Based on the matching results, it generates detailed repair suggestions, which may include specific operation steps, parameters that may need to be adjusted, and hardware or software components that need to be checked. At the same time, it can provide relevant technical document links or reference materials so that maintenance personnel can further understand and solve the problem.

[0045] The technical effects and advantages of this invention are as follows:

[0046] 1. This invention comprehensively collects key indicator data through a distributed data acquisition module and combines it with advanced algorithms from a data analysis module to quickly and accurately locate the cause of database failures. The failure location module utilizes multiple models and comparative analysis to greatly improve the accuracy and speed of failure location. The intelligent repair module provides corresponding solutions for different types of failures. It can take swift action on failures that can be automatically repaired and provide detailed repair suggestions for failures that cannot be automatically repaired, greatly shortening the failure repair time and reducing the impact of database failures on business.

[0047] 2. The distributed data acquisition module of this invention adopts a distributed architecture and an adaptive acquisition frequency adjustment function, which can dynamically adjust the acquisition frequency according to the database load and failure risk. While ensuring data comprehensiveness, it avoids excessive impact on database performance and effectively optimizes resource consumption. The design of the entire system ensures efficient operation and maintenance while fully considering the rational use of resources, reducing system operating costs and improving resource utilization efficiency. Attached Figure Description

[0048] Figure 1This is an overall system diagram of the present invention.

[0049] Figure 2 This is a flowchart of the distributed data acquisition process of the present invention.

[0050] Figure 3 This is a diagram of the distributed data acquisition framework of the present invention.

[0051] Figure 4 This is a flowchart illustrating the adaptive adjustment of the acquisition frequency according to the present invention.

[0052] Figure 5 This is a flowchart of the fault location process of the present invention.

[0053] Figure 6 This is a flowchart of the intelligent repair process of the present invention. Detailed Implementation

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

[0055] As attached Figure 1-6 As shown, the present invention provides an artificial intelligence-based fault location system for operation and maintenance databases. The system includes a distributed data acquisition module, a data analysis module, a fault location module, an alarm and notification module, and an intelligent repair module.

[0056] The distributed data acquisition module is used to comprehensively collect key indicator data from the infrastructure layer of the operation and maintenance database. Key indicator data includes server performance indicators, network performance indicators, and database performance indicators. Among them, server performance indicators include, but are not limited to, CPU utilization, memory utilization, and disk I / O speed; network performance indicators include, but are not limited to, bandwidth utilization, latency, and packet loss rate; and database performance indicators include, but are not limited to, query response time, transaction processing speed, and number of connections.

[0057] Specifically, the distributed data acquisition module can gain a comprehensive understanding of the operational status of the entire database system by collecting server performance metrics, network performance metrics, and database performance metrics respectively.

[0058] Furthermore, as shown in the appendix Figure 2 , 3 As shown, the distributed data acquisition module adopts distributed data acquisition to ensure the real-time performance and accuracy of the data, while avoiding excessive impact on database performance. Specifically;

[0059] S1. Set up a central control node and multiple data acquisition nodes distributed in different locations. The central control node is responsible for coordinating and managing the work of each acquisition node. Each acquisition node is responsible for specific data acquisition tasks. Each acquisition node can independently collect data from a specific part of the database infrastructure, including a specific server, network device, or part of the database instance.

[0060] S2. Use Kafka and RabbitMQ as message queues or HDFS as a distributed file system to transmit the collected data. The collection nodes send the data to the message queues or file systems, and the central control node or data analysis module can retrieve the data from these intermediate storages for processing.

[0061] Specifically, the distributed data acquisition module employs a distributed acquisition method to ensure data real-time performance and accuracy while avoiding excessive impact on database performance. Firstly, a central control node and multiple data acquisition nodes distributed across different locations are set up. The central control node coordinates and manages the work of each acquisition node, while the acquisition nodes are responsible for the specific data acquisition tasks. Each acquisition node can independently acquire data from a specific part of the database infrastructure, such as a specific server, network device, or part of a database instance. Secondly, message queues such as Kafka and RabbitMQ, or distributed file systems such as HDFS, are used to transmit the acquired data. The acquisition nodes send data to the message queue or file system, and the central control node or data analysis module can then retrieve and process the data from these intermediate storage locations.

[0062] Furthermore, as shown in the appendix Figure 4 As shown, the distributed data acquisition module also has the function of adaptively adjusting the acquisition frequency, dynamically adjusting the acquisition frequency according to the database load and fault risk, so as to optimize resource consumption while ensuring data comprehensiveness.

[0063] S1. Continuously monitor database load metrics, including CPU utilization, memory utilization, disk I / O speed, and number of database connections. Establish a threshold system for load metrics. When the load exceeds a certain threshold, the database is considered to be in a high-load state, and when the load is below a certain threshold, the database is considered to be in a low-load state.

[0064] S2. Analyze historical fault data to identify fault modes related to database load. For example, when CPU utilization and memory utilization increase simultaneously, performance bottlenecks may occur, increasing the risk of faults. Use the data analysis module to predict potential fault risks and output the probability or level of fault risks based on the input indicator data.

[0065] S3. Based on the assessment results of database load and failure risk, dynamically adjust the data collection frequency. For example, when the database is under high load or the failure risk is high, reduce the collection frequency to reduce the impact on database performance. When the database is under low load or the failure risk is low, increase the collection frequency to ensure the comprehensiveness of the data.

[0066] Specifically, the distributed data acquisition module also has the function of adaptively adjusting the acquisition frequency. Specifically, it continuously monitors the database load indicators, such as CPU utilization, memory utilization, disk I / O speed, and database connection count, and then establishes a threshold system for load indicators. If the load exceeds a certain threshold, the database is considered to be in a high-load state; if the load is below a certain threshold, the database is considered to be in a low-load state.

[0067] Simultaneously, it analyzes historical fault data to identify fault patterns related to database load. For example, when CPU and memory usage both increase, the risk of failure due to performance bottlenecks may increase. The data analysis module can predict potential fault risks and output the probability or level of fault risk based on the input metric data. Finally, based on the assessment results of database load and fault risk, it dynamically adjusts the data collection frequency. For example, when the database is under high load or the fault risk is high, the collection frequency is reduced to minimize the impact on database performance, while when the database is under low load or the fault risk is low, the collection frequency is increased to ensure data comprehensiveness.

[0068] The data analysis module performs joint and correlation analysis on the collected key indicator data, uses the random forest algorithm to establish a correlation model between data, and uses a long short-term memory network to learn from historical fault data to establish a fault prediction model. The prediction probability formula is: P(y=1|X)=1 / (1+exp(-(w0+w1x1+w2x2+...+wnxn)));

[0069] Where y is the predicted result of whether a fault occurs, 1 indicates that a fault has occurred, and 0 indicates that a fault has not occurred; X is the input feature vector including various key indicator data; wi is the corresponding weight coefficient; and n is the number of features.

[0070] Suppose we want to analyze the relationship between CPU utilization (x), memory utilization (y1), and query response time (z). This can be achieved through the concept of linear regression: z = ax + b * y1 + c, where a and b are coefficients and c is a constant term.

[0071] Specifically, the data analysis module will conduct joint and correlation analysis on the collected key indicator data. It uses the random forest algorithm to build a correlation model between data, and at the same time uses a long short-term memory network to learn from historical fault data to establish a fault prediction model. In this fault prediction model, a prediction probability formula is used to represent the result of predicting whether a fault has occurred. When y represents the predicted fault occurrence, when y is 1, it means that a fault has occurred, and when y is 0, it means that a fault has not occurred. Here, X is the input feature vector, which covers various key indicator data, wi is the corresponding weight coefficient, and n represents the number of features.

[0072] For example, to analyze the relationship between CPU utilization (represented by x), memory utilization (represented by y1), and query response time (represented by z), we can use the concept of linear regression, expressed by the formula z = ax + by1 + c, where a and b are coefficients and c is a constant term.

[0073] Furthermore, as shown in the appendix Figure 5 As shown, the fault location module can quickly locate the cause of the fault based on the results of the data analysis module when the database fails.

[0074] S1. Compare the current indicator data with the normal state data to identify abnormal indicators;

[0075] S1.1 Establish a normal state indicator database. The distributed data acquisition module continuously collects server performance indicators, network performance indicators and database performance indicators under normal operating conditions. Statistical analysis is performed on the collected normal state data to determine the reasonable range and statistical parameters such as mean and standard deviation of each indicator. For example, the average value of a certain indicator over a period of time plus or minus a few standard deviations is used as the upper and lower limits of the normal range.

[0076] S1.2 Real-time monitoring and comparison: Continuously monitor the key indicator data of the database during operation. When the database fails or is suspected of failing, immediately obtain the current indicator data and compare the current indicator data with the corresponding indicators in the normal state indicator database. If an indicator exceeds the normal range, mark it as an abnormal indicator.

[0077] S2. Use fault prediction models and correlation models to analyze the relationships between abnormal indicators and determine possible fault points;

[0078] S2.1 When abnormal indicators appear, these abnormal indicators are input into the pre-trained fault prediction model. If the fault prediction model outputs a high probability of fault occurrence, it means that these abnormal indicators match the known fault modes.

[0079] S2.2 Utilize the pre-established correlation model to analyze the relationship between abnormal indicators. For example, if it is found that CPU utilization and memory utilization both rise abnormally at the same time, and the correlation model shows that these two indicators are strongly correlated with database connection timeout failures, then it can be preliminarily determined that there may be a database connection timeout failure, and finally the failure can be displayed and located.

[0080] Specifically, the fault location module constructs a normal state indicator database. This database is continuously collected by the distributed data acquisition module during normal database operation. It collects server performance indicators (such as CPU utilization, memory utilization, etc.), network performance indicators (such as bandwidth utilization, latency, etc.), and database performance indicators (such as query response time, transaction processing speed, etc.). Then, it performs in-depth statistical analysis on the collected normal state data to calculate the reasonable value range of each indicator. For example, it uses the average value of the indicator over a period of time as the center and adds or subtracts a certain number of standard deviations to determine the upper and lower limits.

[0081] During database operation, this module continuously monitors various key indicator data in real time. Once a fault or suspected fault is detected in the database, it will immediately obtain all current indicator data. Then, it will compare these current indicator data with the corresponding indicators in the normal state indicator database one by one. If the value of an indicator exceeds the predetermined normal range, the indicator will be marked as an abnormal indicator.

[0082] Subsequently, when abnormal indicators appear, the fault location module inputs these abnormal indicators into a pre-trained fault prediction model. If the model outputs a high probability of fault occurrence, it means that these abnormal indicators match a known fault mode. At the same time, the module also uses a pre-established correlation model to analyze the intrinsic relationship between these abnormal indicators. For example, when it is found that CPU utilization and memory utilization both rise abnormally, and the correlation model shows that these two indicators are strongly correlated with database connection timeout faults, it can be preliminarily judged that there may be a database connection timeout problem, and finally the location of the fault point is determined and displayed.

[0083] Furthermore, the alarm and notification module promptly issues alarms and notifies maintenance personnel through various means when a database fault or potential fault is detected. The alarm information includes the fault type, fault location, and severity, and the notification methods include email, SMS, and instant messaging tools.

[0084] Specifically, when the alarm and notification module detects a database failure or potential failure, it will immediately issue an alarm and notify the operation and maintenance personnel in various ways. The alarm information will cover the type of failure, the location of the failure, and the severity of the failure. Notification methods include email notification, SMS notification, and notification via instant messaging tools.

[0085] Furthermore, as shown in the appendix Figure 6 The intelligent repair module shown automatically attempts to perform simple fault repair operations based on the fault location results. For faults that cannot be automatically repaired, it provides detailed repair suggestions, specifically.

[0086] When the intelligent repair module performs simple fault repair:

[0087] S1. Classify common database failure types, including network connection problems, server resource overload, and database configuration errors. For each common failure type, define corresponding simple repair operations. For example, for network connection problems, try restarting the network device or resetting the network connection; for server resource overload, try closing some unnecessary processes or adjusting the server resource allocation strategy; for database configuration errors, try reloading the correct configuration file.

[0088] S2. After the fault location module determines the cause of the fault, the intelligent repair module determines whether it falls within the scope of automatic repair based on the fault type. If it is an automatically repairable fault, the corresponding repair operation is triggered immediately by calling system commands, API interfaces, or using automated scripts to perform the repair operation.

[0089] When the intelligent repair module provides detailed repair suggestions for faults that cannot be repaired automatically:

[0090] S1. By collecting historical failure cases, expert experience, and relevant technical documents, a knowledge base containing various database failures and their solutions is established. For each type of failure, possible causes, diagnostic methods, and detailed repair suggestions are recorded. For example, for database connection timeout failures, the knowledge base can record possible causes such as network problems, excessive database server load, database configuration errors, etc., as well as corresponding diagnostic methods and repair suggestions.

[0091] S2. When encountering a fault that cannot be automatically repaired, the intelligent repair module queries and matches the fault knowledge base based on the fault location results. Based on the matching results, it generates detailed repair suggestions, which may include specific operation steps, parameters that may need to be adjusted, and hardware or software components that need to be checked. At the same time, it can provide relevant technical document links or reference materials so that maintenance personnel can further understand and solve the problem.

[0092] Specifically, the intelligent repair module takes action based on the fault location results. When performing simple fault repair, it first categorizes common database fault types, such as network connection problems, server resource overload, and database configuration errors. For each common fault type, it defines corresponding simple repair operations. For example, when encountering network connection problems, it can try restarting network devices or resetting the network connection; when server resources are overloaded, it can try closing some unnecessary processes or adjusting the server resource allocation strategy; if there is a database configuration error, it can try reloading the correct configuration file. Once the fault location module determines the cause of the fault, the intelligent repair module will determine whether it falls within the scope of automatic repair based on the fault type. If it is an automatically repairable fault, it will immediately trigger the corresponding repair operation, which can be performed by calling system commands, API interfaces, or using automated scripts.

[0093] When faced with faults that cannot be automatically repaired, the intelligent repair module builds a knowledge base containing various database faults and their solutions by collecting historical fault cases, expert experience, and relevant technical documents. For each fault type, it records possible causes, diagnostic methods, and detailed repair suggestions. For example, for database connection timeout faults, the knowledge base records possible causes such as network problems, high database server load, and database configuration errors, along with corresponding diagnostic methods and repair suggestions. When encountering faults that cannot be automatically repaired, the intelligent repair module queries and matches the fault knowledge base based on the fault location results. Based on the matching results, it generates detailed repair suggestions, which may include specific operation steps, parameters that may need to be adjusted, and hardware or software components that need to be checked. At the same time, it can also provide relevant technical document links or reference materials to help maintenance personnel further understand and solve the problem.

[0094] Working principle of this invention:

[0095] This invention provides an AI-based database fault location system for operation and maintenance. In practical use, it first comprehensively collects key indicator data from the database infrastructure layer through a distributed data acquisition module, including server, network and database performance indicators.

[0096] The data analysis module performs joint and correlation analysis on this data, and uses the random forest algorithm to build an association model and the long short-term memory network to build a fault prediction model.

[0097] When the database fails, the fault location module compares the current data with the normal data to find abnormal indicators, and then uses fault prediction and correlation models to determine the possible fault points.

[0098] The alarm and notification module notifies maintenance personnel through various methods when a fault is detected;

[0099] The intelligent repair module performs simple repair operations for faults that can be automatically repaired, and provides detailed repair suggestions for faults that cannot be automatically repaired. It generates suggestions by building a knowledge base and querying and matching based on fault location results. The entire system ensures real-time and accurate data and optimizes resource usage through distributed architecture and adaptive acquisition frequency.

[0100] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An AI-based fault location system for operation and maintenance databases, characterized in that, include: The distributed data acquisition module is used to comprehensively collect key indicator data from the infrastructure layer of the operation and maintenance database; The data analysis module performs joint and correlation analysis on the collected key indicator data, uses the random forest algorithm to establish a correlation model between data, and uses a long short-term memory network to learn from historical fault data to establish a fault prediction model. The fault location module can quickly locate the cause of a database failure based on the results of the data analysis module. The alarm and notification module promptly issues alarms and notifies maintenance personnel through various means when a database failure or potential failure is detected. The intelligent repair module automatically attempts to perform simple fault repair operations based on the fault location results, and provides detailed repair suggestions for faults that cannot be repaired automatically.

2. The AI-based fault location system for operation and maintenance databases according to claim 1, characterized in that, The key performance indicators include server performance indicators, network performance indicators, and database performance indicators, among which: Server performance metrics include CPU utilization, memory utilization, and disk I / O speed; Network performance metrics include bandwidth utilization, latency, and packet loss rate; Database performance metrics include query response time, transaction processing speed, and number of connections.

3. The AI-based fault location system for operation and maintenance databases according to claim 1, characterized in that: The distributed data acquisition module employs distributed data acquisition to ensure the real-time performance and accuracy of the data, while avoiding excessive impact on database performance. Specifically; S1. Set up a central control node and multiple data acquisition nodes distributed in different locations. The central control node is responsible for coordinating and managing the work of each acquisition node. Each acquisition node is responsible for specific data acquisition tasks. Each acquisition node independently collects data from a specific part of the database infrastructure, including a specific server, network device, or part of the database instance. S2. Use Kafka and RabbitMQ as message queues or HDFS as a distributed file system to transmit the collected data. The collection nodes send the data to the message queues or file systems, and the central control node or data analysis module retrieves the data from these intermediate storages for processing.

4. The AI-based fault location system for operation and maintenance databases according to claim 1, characterized in that: The distributed data acquisition module also has the function of adaptively adjusting the acquisition frequency, dynamically adjusting the acquisition frequency according to the database load and fault risk, so as to optimize resource consumption while ensuring data comprehensiveness. S1. Continuously monitor database load metrics, including CPU utilization, memory utilization, disk I / O speed, and number of database connections. Establish a threshold system for load metrics. When the load exceeds a certain threshold, the database is considered to be in a high-load state, and when the load is below a certain threshold, the database is considered to be in a low-load state. S2. Analyze historical fault data to identify fault modes related to database load. When CPU utilization and memory utilization increase simultaneously, performance bottlenecks may occur, increasing the risk of faults. Use the data analysis module to predict potential fault risks and output the probability or level of fault risks based on the input indicator data. S3. Based on the assessment results of database load and failure risk, dynamically adjust the data collection frequency. When the database is under high load or the failure risk is high, reduce the collection frequency to reduce the impact on database performance. When the database is under low load or the failure risk is low, increase the collection frequency to ensure the comprehensiveness of the data.

5. The AI-based fault location system for operation and maintenance databases according to claim 1, characterized in that: The data analysis module uses a logistic regression model for fault prediction, and the prediction probability formula is: P(y=1|X)=1 / (1+exp(-(w0+w1x1+w2x2+...+wnxn))); Where y is the predicted result of whether a fault occurs, 1 indicates that a fault has occurred, and 0 indicates that a fault has not occurred; X is the input feature vector including various key indicator data; wi is the corresponding weight coefficient; and n is the number of features. Using the linear regression concept z = ax + by1 + c, we analyze the relationship between CPU utilization x, memory utilization y1, and query response time z, where a and b are coefficients, and c is a constant term.

6. The AI-based fault location system for operation and maintenance databases according to claim 1, characterized in that: When a database malfunctions, the specific steps for quickly locating the cause of the malfunction based on the results of the data analysis module are as follows: S1. Compare the current indicator data with the normal state data to identify abnormal indicators; S1.1 Establish a normal state indicator database. The distributed data acquisition module continuously collects server performance indicators, network performance indicators, and database performance indicators under normal operating conditions. Statistical analysis is performed on the collected normal state data to determine the reasonable range and statistical parameters of each indicator. S1.2 Real-time monitoring and comparison: Continuously monitor the key indicator data of the database during operation. When the database fails or is suspected of failing, immediately obtain the current indicator data and compare the current indicator data with the corresponding indicators in the normal state indicator database. If an indicator exceeds the normal range, mark it as an abnormal indicator. S2. Use fault prediction models and correlation models to analyze the relationships between abnormal indicators and determine possible fault points; S2.1 When abnormal indicators appear, these abnormal indicators are input into the pre-trained fault prediction model. If the fault prediction model outputs a high probability of fault occurrence, it means that these abnormal indicators match the known fault modes. S2.2 Using a pre-established correlation model, analyze the relationship between abnormal indicators. If CPU utilization and memory utilization are found to be abnormally high at the same time, and the correlation model shows that these two indicators are strongly correlated with database connection timeout failures, then it can be preliminarily determined that there may be a database connection timeout failure, and finally the failure can be displayed and located.

7. The AI-based fault location system for operation and maintenance databases according to claim 1, characterized in that: The alarm information includes the fault type, fault location, and severity, and the notification methods include email, SMS, and instant messaging tools.

8. The AI-based fault location system for operation and maintenance databases according to claim 1, characterized in that: When the intelligent repair module performs simple fault repair, specifically; S1. Classify common database failure types, including network connection problems, server resource overload, and database configuration errors. Define corresponding simple repair operations for each common failure type. S2. After the fault location module determines the cause of the fault, the intelligent repair module determines whether it falls within the scope of automatic repair based on the fault type. If it is an automatically repairable fault, the corresponding repair operation is triggered immediately by calling system commands, API interfaces, or using automated scripts to perform the repair operation.

9. The AI-based fault location system for operation and maintenance databases according to claim 1, characterized in that: When the intelligent repair module provides detailed repair suggestions for faults that cannot be automatically repaired, it specifically; S1. By collecting historical failure cases, expert experience and relevant technical documents, a knowledge base containing various database failures and their solutions is established. For each type of failure, possible causes, diagnostic methods and detailed repair suggestions are recorded. S2. When encountering a fault that cannot be automatically repaired, the intelligent repair module queries and matches the fault knowledge base based on the fault location results. Based on the matching results, it generates detailed repair suggestions, which may include specific operation steps, parameters that may need to be adjusted, and hardware or software components that need to be checked. At the same time, it can provide relevant technical document links or reference materials so that maintenance personnel can further understand and solve the problem.

Images