Fault risk monitoring method, device, storage medium and program product

Abstract

The embodiment of the present application provides a fault risk monitoring method, device, storage medium and program product, the method includes obtaining the current operating state of the system, the current operating state includes the current values ​​of multiple operating indicators, matching the current operating state with multiple historical operating states respectively, obtaining the matching degrees corresponding to the multiple historical operating states respectively, different historical operating states correspond to different sampling times, the historical operating state includes the historical values ​​of multiple operating indicators at the corresponding sampling time, obtaining the fault event under the historical operating state corresponding to the maximum value of the multiple matching degrees, and generating a fault risk prompt according to the fault event. The method provided by this embodiment can improve the comprehensiveness and accuracy of monitoring.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of software testing technology, and in particular to a fault risk monitoring method, device, storage medium, and program product. Background Art

[0002] In order to ensure the normal operation of the software, production and operation and maintenance personnel usually monitor the operation of the servers, databases, networks, and clients deployed in the application system, and trace and locate problems based on the monitored indicator data.

[0003] In the related art, an early warning is usually issued when one or more indicators exceed a threshold.

[0004] However, in the process of implementing this application, the inventors found that there are at least the following problems in the prior art: the existing methods can only issue warnings for monitored indicators, and often fail to issue fault warnings when there is a risk of failure, and the comprehensiveness and accuracy of monitoring are low. Summary of the invention

[0005] The embodiments of the present application provide a fault risk monitoring method, device, storage medium and program product to improve the comprehensiveness and accuracy of monitoring.

[0006] In a first aspect, an embodiment of the present application provides a fault risk monitoring method, including:

[0007] Acquire the current operating state of the system; the current operating state includes current values ​​of multiple operating indicators;

[0008] Matching the current running state with a plurality of historical running states respectively to obtain the matching degrees corresponding to the plurality of historical running states respectively; different historical running states correspond to different sampling times; the historical running states include the historical values ​​of the plurality of running indicators at the corresponding sampling times;

[0009] Fault events under historical operating conditions corresponding to maximum values ​​of multiple matching degrees are obtained, and a fault risk prompt is generated according to the fault events.

[0010] In a possible design, matching the current running state with a plurality of historical running states respectively includes:

[0011] If the multiple current values ​​do not exceed the corresponding preset threshold range, the current operating state is matched with the multiple historical operating states respectively.

[0012] In a possible design, after obtaining the current operating state of the system, the method further includes:

[0013] If at least one of the multiple current values ​​exceeds the corresponding preset threshold range, a corresponding fault warning is generated;

[0014] Filtering and obtaining a plurality of operating states to be matched from the plurality of historical operating states; the fault events corresponding to the operating states to be matched include the fault events corresponding to the fault warnings;

[0015] The matching the current running state with a plurality of historical running states respectively to obtain the matching degrees respectively corresponding to the plurality of historical running states includes:

[0016] The current running state is matched with the plurality of running states to be matched respectively, and the matching degrees corresponding to the plurality of running states to be matched are obtained respectively.

[0017] In a possible design, matching the current running state with a plurality of historical running states respectively to obtain matching degrees corresponding to the plurality of historical running states respectively includes:

[0018] Acquire a first vector of the current running state and a plurality of second vectors of the historical running states;

[0019] For the second vector of each historical operating state in the plurality of historical operating states, a Mahalanobis distance between the first vector and the second vector is calculated, and a matching degree corresponding to the historical operating state is determined according to the Mahalanobis distance.

[0020] In a possible design, before matching the current running state with a plurality of historical running states respectively, the method further includes:

[0021] Divide the preset collection period into multiple time intervals;

[0022] For each time interval, historical operating status is collected according to a sampling frequency corresponding to the time interval, and the collected historical operating status is associated with a fault event occurring at the corresponding collection time and stored.

[0023] In a possible design, before collecting the historical operating status according to the sampling frequency corresponding to the time interval, the method further includes:

[0024] Determine the required quantity of failure events based on confidence requirements and sampling error requirements;

[0025] Collecting a plurality of fault events according to the demand;

[0026] Dividing the multiple fault events into multiple different time intervals;

[0027] For each time interval, obtaining the number of fault events occurring in the time interval;

[0028] The sampling frequencies respectively corresponding to the multiple time intervals are determined according to the numbers of fault events respectively corresponding to the multiple time intervals.

[0029] In a possible design, determining the sampling frequencies corresponding to the multiple time intervals respectively according to the number of fault events corresponding to the multiple time intervals respectively includes:

[0030] Determine the number of collection times corresponding to the preset collection period;

[0031] For each time interval, a ratio between the number of fault events corresponding to the time interval and the total number of the multiple fault events is calculated, and a sampling frequency corresponding to the time interval is determined according to the ratio and the number of acquisitions.

[0032] In a possible design, before collecting the historical operating status for each time interval according to the sampling frequency corresponding to the time interval, the method further includes:

[0033] Determine the target duration based on the software iteration frequency;

[0034] For each time interval, collecting the historical operation status according to the sampling frequency corresponding to the time interval includes:

[0035] For each time interval within a plurality of preset collection periods corresponding to the target duration, collect historical operating status according to a sampling frequency corresponding to the time interval, and add the collected historical operating status to a sample set;

[0036] The matching of the current running state with a plurality of historical running states respectively includes:

[0037] The current running state is matched with a plurality of historical running states in the sample set respectively.

[0038] In a second aspect, an embodiment of the present application provides a fault risk monitoring device, including:

[0039] An acquisition module, used to acquire the current operating state of the system; the current operating state includes current values ​​of multiple operating indicators;

[0040] A matching module, used to match the current operation state with a plurality of historical operation states respectively, and obtain the matching degrees corresponding to the plurality of historical operation states respectively; different historical operation states correspond to different sampling times; the historical operation states include the historical values ​​of the plurality of operation indicators at the corresponding sampling times;

[0041] A generation module is used to obtain a fault event under a historical operating state corresponding to a maximum value among a plurality of the matching degrees, and generate a fault risk prompt according to the fault event.

[0042] In a third aspect, an embodiment of the present application provides a fault risk monitoring device, including: at least one processor and a memory;

[0043] The memory stores computer-executable instructions;

[0044] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the method described in the first aspect and various possible designs of the first aspect.

[0045] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the method described in the first aspect and various possible designs of the first aspect are implemented.

[0046] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the method described in the first aspect and various possible designs of the first aspect.

[0047] The fault risk monitoring method, device, storage medium and program product provided in this embodiment include obtaining the current operating state of the system, the current operating state includes the current values ​​of multiple operating indicators, matching the current operating state with multiple historical operating states respectively, obtaining the matching degrees corresponding to the multiple historical operating states respectively, different historical operating states correspond to different sampling times, and the historical operating state includes the historical values ​​of multiple operating indicators at the corresponding sampling time, obtaining the fault event under the historical operating state corresponding to the maximum value of the multiple matching degrees, and generating a fault risk prompt according to the fault event. The fault risk monitoring method provided in this embodiment can improve the comprehensiveness and accuracy of monitoring by obtaining multiple current operating indicators, matching the multiple operating indicators with the pre-collected historical indicators, and generating a fault risk prompt based on the fault event occurring under the historical operating state with the largest matching degree. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0049] Figure 1A schematic diagram of an application scenario of the fault risk monitoring method provided in an embodiment of the present application;

[0050] Figure 2 Schematic diagram of the process of the fault risk monitoring method provided in the embodiment of the present application Figure 1 ;

[0051] Figure 3 Schematic diagram of the process of the fault risk monitoring method provided in the embodiment of the present application Figure 2 ;

[0052] Figure 4 A sampling schematic diagram for an application server cluster provided in an embodiment of the present application;

[0053] Figure 5 A schematic diagram of the structure of a fault risk monitoring device provided in an embodiment of the present application;

[0054] Figure 6 A schematic diagram of the hardware structure of the fault risk monitoring device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0056] To ensure the normal operation of the software, production and operation and maintenance personnel usually monitor the operation of the servers, databases, networks, and clients deployed in the application system, implement fault risk warnings by setting performance monitoring indicators and indicator thresholds, and trace and locate problems based on the monitored indicator data.

[0057] The relevant performance risk warning system usually issues a warning when one or more indicators exceed the threshold. However, there are two deficiencies in the actual application scenarios: first, the existing warning system can only issue warnings for monitored indicators. However, some performance indicators cannot be fully monitored due to the difficulty of monitoring. The potential risks brought by these monitoring loopholes cannot be covered by the traditional threshold warning system, and the monitoring is not comprehensive. Second, when the values ​​of all monitored indicators are lower than the threshold, the threshold warning system will believe that the application is running normally and will not issue a warning, but there is still a possibility of failure in reality, and the monitoring accuracy is low.

[0058] To solve the above technical problems, the inventors of the present application have found that by collecting the values ​​of various operating indicators and data of failures of the application system in the past period of time as samples, the matching degree between the current operating indicator values ​​of the application system and the samples is calculated, and the sample with the largest matching degree is found. The sample can be determined to be the closest to the operating state of the current application system. If the sample contains a failure event, it can be determined that the system has a failure risk, and the solution and details of the sample failure event can also be provided to relevant personnel for reference. Based on this, the embodiment of the present application provides a failure risk monitoring method that can improve the comprehensiveness and accuracy of monitoring.

[0059] Figure 1 Schematic diagram of application scenarios of the fault risk monitoring method provided in the embodiment of the present application. Figure 1 As shown, the server 101 is communicatively connected with the monitoring device 102 .

[0060] In the specific implementation process, the server 101 collects and sends the current operating state to the monitoring device 102. The monitoring device 102 obtains the current operating state; the current operating state includes the current values ​​of multiple operating indicators; the current operating state is matched with multiple historical operating states respectively to obtain the matching degrees corresponding to the multiple historical operating states respectively; different historical operating states correspond to different sampling times; the historical operating state includes the historical values ​​of multiple operating indicators at the corresponding sampling time; the fault event under the historical operating state corresponding to the maximum value of the multiple matching degrees is obtained, and a fault risk prompt is generated according to the fault event. The fault risk monitoring method provided in the embodiment of the present application obtains multiple current operating indicators, matches multiple operating indicators with pre-collected historical indicators, and generates a fault risk prompt based on the fault event occurring under the historical operating state with the largest matching degree, thereby improving the comprehensiveness and accuracy of monitoring.

[0061] The monitoring device 102 may be a terminal device or a server.

[0062] The server 101 may be one type of server or multiple types of servers. When there are multiple types of servers, it may be determined whether to monitor the multiple types of servers separately based on the similarities and differences in the operating indicators of the servers.

[0063] Exemplarily, the server 101 may be an application server, and the current running state of the application server may include multiple running indicators, such as: service resource category: CPU usage, disk space usage, disk index node inode usage, memory space usage, number of zombie processes; network category: bandwidth utilization, TCP connection status; application programming interface (API) category: API correctness, API response time; business volume category: number of current online users, etc. The server 102 may also be a database server, and the current running state of the database server may include multiple running indicators, such as: service resource category: CPU usage, disk space usage, disk index node inode usage, memory space usage, number of zombie processes; network category: bandwidth utilization, TCP connection status; database category: time consumed by slow SQL, table space usage, proportion of active connections to maximum connections, number of deadlock errors (ORA-60) in the early warning alert log, etc.

[0064] If server 101 is an application server and a database server, since the application server and the database server need to collect different indicators, the application server and the database server can be considered separately during sampling and risk assessment, and the corresponding fault events can also be clearly classified. It should be noted that in order to facilitate the capture of problems, the event error location can be classified according to the appearance of the problem rather than the root cause, that is, it can be divided into problems found on the application server side and problems found on the database server side.

[0065] In addition, the occurrence of fault events is also divided into two situations: one is that a certain operating indicator of the system exceeds the set threshold, that is, the indicator performance is abnormal, and the early warning system automatically issues a fault warning. Such events correspond to clear abnormal indicator items, and it can be directly judged whether it is a problem on the application server side or a problem on the database server side based on the attribution of the indicator item; the second is the fault event reported by the operation and maintenance personnel or the user when all indicators perform normally. Such events need to be manually judged to determine the classification.

[0066] It should be noted that Figure 1 The scenario diagram shown is only an example. The fault risk monitoring method and scenario described in the embodiment of the present application are intended to more clearly illustrate the technical solution of the embodiment of the present application, and do not constitute a limitation on the technical solution provided in the embodiment of the present application. Ordinary technicians in this field can know that with the evolution of the system and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

[0067] The technical solution of the present application is described in detail with specific embodiments below. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0068] Figure 2 Schematic diagram of the process of the fault risk monitoring method provided in the embodiment of the present application Figure 1 .like Figure 2 As shown, the method includes:

[0069] 201. Obtain a current operating state of the system; the current operating state includes current values ​​of multiple operating indicators.

[0070] The execution subject of this embodiment may be a terminal device or a server, such as Figure 1 Monitoring device 102 is shown.

[0071] The system in this embodiment can be as follows Figure 1 The server 101 is shown with the system installed and running.

[0072] 202. Match the current operating state with multiple historical operating states respectively to obtain the matching degrees corresponding to the multiple historical operating states respectively; different historical operating states correspond to different sampling times; the historical operating state includes the historical values ​​of multiple operating indicators at the corresponding sampling times.

[0073] Specifically, the current operating indicators of the application system can be traversed. When a certain operating indicator exceeds the corresponding threshold, an early warning is automatically triggered, the early warning event is saved in the event list, and the indicator item and indicator value of the early warning are prompted on the front-end page. Assuming that m indicators exceeding the threshold are detected, they can be processed separately based on the value of m.

[0074] In this embodiment, there are multiple ways to match the current operating state with the historical operating state. In some embodiments, matching the current operating state with multiple historical operating states respectively to obtain the matching degrees corresponding to the multiple historical operating states respectively may include: obtaining a first vector of the current operating state and multiple second vectors of the historical operating states; for each second vector of the multiple historical operating states, calculating the Mahalanobis distance between the first vector and the second vector, and determining the matching degree corresponding to the historical operating state according to the Mahalanobis distance.

[0075] Specifically, the calculation formula of the Mahalanobis distance can be shown as formula (1):

[0076]

[0077] Where x and y represent the operating index value vectors of the current system and the operating index value vectors of a certain sample, respectively, and DM(x, y) is the Mahalanobis distance between the two. ∑ is the covariance matrix of the sample set S, and ∑-1 is the inverse matrix of the covariance matrix.

[0078] The calculation method of the covariance matrix can refer to the following formula (2):

[0079]

[0080] Where m is the sample size, n is the number of operating indicators, ci represents the i-th indicator item, cov(ci,cj)=E([ci-E(ci)][cj-E(cj)]), E(ci) represents the average value of ci, and cov(ci,cj) represents the covariance between the i-th indicator and the j-th indicator.

[0081] In some embodiments, for the case where the threshold warning is not triggered, in order to ensure the comprehensiveness of monitoring, a full match of each operating indicator can be performed. Specifically, the current operating state is matched with multiple historical operating states respectively, which may include: if multiple current values ​​do not exceed the corresponding preset threshold range, that is, m=0, then the current operating state is matched with multiple historical operating states respectively. Exemplarily, the Mahalanobis distance between the current operating indicator values ​​of the application system and all samples in the sample set S can be calculated, and the sample ID with the smallest distance (maximum matching degree) to the current operating indicator is recorded.

[0082] In some embodiments, for the case where the threshold warning has been triggered, in order to save computing resources, matching processing can be performed only for the operating indicators whose current values ​​exceed the threshold range. Specifically, after obtaining the current operating state of the system, it can also include: if there is at least one current value among the multiple current values ​​that exceeds the corresponding preset threshold range, then a corresponding fault warning is generated; multiple operating states to be matched are obtained by screening from the multiple historical operating states; the fault events corresponding to the operating states to be matched include the fault events corresponding to the fault warning; the current operating state is matched with multiple historical operating states respectively to obtain the matching degrees corresponding to the multiple historical operating states respectively, which can include: matching the current operating state with multiple operating states to be matched respectively to obtain the matching degrees corresponding to the multiple operating states to be matched respectively.

[0083] For example, in the case where the threshold warning has been triggered, that is, the event has occurred, it is only necessary to calculate the Mahalanobis distance between the current operating index value of the system and all samples in the sample set S with "event mark" as "Y", and record the sample ID with the smallest distance from the current operating index.

[0084] 203. Obtain a fault event in a historical operating state corresponding to a maximum value among a plurality of the matching degrees, and generate a fault risk prompt according to the fault event.

[0085] For example, after obtaining the minimum distance sample ID corresponding to the maximum matching degree, the "event mark" of the sample is combined to determine whether the application system currently has a failure risk. If the "event mark" is "Y", it means there is a risk, and the front-end page prompts a risk warning as well as the matched sample details and the corresponding event resolution analysis details; if the "event mark" is "N", it means there is no risk, and there is no risk prompt on the front-end page.

[0086] The fault risk monitoring method provided in this embodiment obtains multiple current operating indicators, matches the multiple operating indicators with pre-collected historical indicators, and generates fault risk prompts based on fault events occurring under the historical operating state with the greatest matching degree, thereby improving the comprehensiveness and accuracy of monitoring.

[0087] Figure 3 Schematic diagram of the process of the fault risk monitoring method provided in the embodiment of the present application Figure 2 .like Figure 3 As shown, based on the above embodiment, for example Figure 2 Based on the illustrated embodiment, this embodiment provides an exemplary description of the generation and maintenance process of the historical operating status, that is, the risk assessment sample set. The method includes:

[0088] 301. Divide the preset collection period into multiple time intervals.

[0089] 302. For each time interval, collect historical operating status according to a sampling frequency corresponding to the time interval, and associate the collected historical operating status with a fault event occurring at a corresponding collection time and store them.

[0090] Specifically, the values ​​of various operating indicators of the application system are constantly changing over time. According to experience, failures are more likely to occur during daily business peak hours and when executing batch tasks than during other time periods. Therefore, in order to make the collected samples more representative, it is necessary to first conduct a preliminary investigation of recent production events in the system and set a reasonable sampling frequency based on the time distribution of production events.

[0091] In some embodiments, in order to save computing resources, different sampling frequencies are used in different time intervals, and the method for determining the sampling frequency may include: determining the demand for fault events based on confidence requirements and sampling error requirements; collecting multiple fault events based on the demand; dividing the multiple fault events into multiple different time intervals; for each time interval, obtaining the number of fault events occurring in the time interval; and determining the sampling frequencies corresponding to the multiple time intervals respectively based on the number of fault events corresponding to the multiple time intervals.

[0092] In some embodiments, in order to set the sampling frequency more reasonably, it can be determined based on parameters such as the fluctuation period of the software function. Specifically, the determining of the sampling frequencies corresponding to the multiple time intervals according to the number of fault events corresponding to the multiple time intervals can include: determining the number of acquisitions corresponding to the preset acquisition cycle; for each time interval, calculating the ratio between the number of fault events corresponding to the time interval and the total number of the multiple fault events, and determining the sampling frequency corresponding to the time interval according to the ratio and the number of acquisitions.

[0093] In some embodiments, the determination of the coverage duration of the sample set may refer to the software iteration frequency to improve rationality. Specifically, the target duration may be determined according to the software iteration frequency; the acquisition of historical operating status for each time interval according to the sampling frequency corresponding to the time interval may include: for each time interval within a plurality of preset acquisition cycles corresponding to the target duration, the acquisition of historical operating status according to the sampling frequency corresponding to the time interval, and adding the acquired historical operating status to the sample set; the matching of the current operating status with the plurality of historical operating statuses may include: matching the current operating status with the plurality of historical operating statuses in the sample set.

[0094] For example, first, the number of pre-survey samples can be estimated according to the overall estimation formula of the categorical variable, and the calculation formula is shown in the following formula (3):

[0095]

[0096] Where n is the sample size, z is obtained by looking up the z value table based on the confidence interval, p is the expected value of the proportion of the target population, and δ is the sampling error range.

[0097] For example, if the confidence interval is set to 95% (z value is 1.96), the sampling error range is 4%, and p(1-p) takes the maximum value of 0.25, the sample size n is 600.25. That is, at a confidence level of 95% and a sampling error range of 4%, it is necessary to collect 601 recent software production event data for investigation and analysis.

[0098] Secondly, according to the estimated sample capacity above, we can collect preliminary survey samples and divide them into multiple time intervals according to the 24 hours of a day. For example, we can divide them into 24 time intervals, namely [0:00, 1:00), [1:00, 2:00), [2:00, 3:00), ..., [23:00, 24:00), count the number of events occurring in each time interval, and calculate the proportion of the number of events in each interval to the total sample: b1, b2, b3, b4, ..., b24.

[0099] Again, the sampling frequency in different time intervals can be set according to the above-obtained proportion of the number of events in each time interval b1, b2, b3, b4, ..., b24. The higher the proportion of the number of events, the more likely the system is to fail in this time interval, so the sampling frequency should be higher. It is reasonable to assume that the performance indicators of the software are sampled once every n minutes on average (because the performance indicators of the software generally do not fluctuate greatly within n minutes, even if the indicators fluctuate greatly, they can be collected within the next n-minute period, and the sudden change of the indicator value that lasts for a short time can be regarded as noise, for example, n can be 5), then a total of 288 samples are collected in one day, and the sampling frequency of each interval is b1×288, b2×288, ..., b24×288, recorded as: f1, f2, f3, ..., f24.

[0100] In addition, except for the automatic warning triggered by exceeding the threshold, other fault events require manual maintenance of event information, or connecting to the existing operation and maintenance management system to obtain event information. The risk estimation system can match the samples collected at that time according to the time when the non-automatic warning event occurred, and add the event information to the event list associated with the sample.

[0101] Finally, the time period covered by the samples can be determined by combining the software iteration frequency and the number of failures. For example, samples of the system running in the past 15 days and samples of failure events in the past 180 days are collected. This is because the system is operating normally most of the time. Multiple servers collect data every 5 minutes. The sample volume collected in 15 days is sufficient to represent the normal operation of the system (the sample volume of a server in 15 days is 4320). In comparison, failure events are only occasional events, and the sampling period needs to be extended to obtain enough samples. After collecting samples for each new day, the risk assessment system will automatically clear expired samples and complete the automatic update of sample set S.

[0102] 303. Obtain a current operating state of the system; the current operating state includes current values ​​of multiple operating indicators.

[0103] 304. Match the current operating state with multiple historical operating states respectively to obtain the matching degrees corresponding to the multiple historical operating states respectively; different historical operating states correspond to different sampling times; the historical operating state includes the historical values ​​of multiple operating indicators at the corresponding sampling times.

[0104] 305. Obtain a fault event in a historical operating state corresponding to a maximum value among a plurality of the matching degrees, and generate a fault risk prompt according to the fault event.

[0105] Steps 303 to 305 in this embodiment are similar to steps 201 to 203 in the above embodiment, and are not described again here.

[0106] The fault risk monitoring method provided in this embodiment adopts different sampling frequencies for different time partitions, so that the collected samples are more representative, thereby reducing the amount of collection, increasing the pertinence of sample collection, and improving the calculation efficiency in subsequent calculations, saving calculation resources.

[0107] In order to more clearly illustrate the composition of the sample set S, the following is an example of a process of collecting samples from an application server cluster.

[0108] Figure 4 A sampling diagram for an application server cluster provided in an embodiment of the present application is shown in FIG. Figure 4 As shown in the figure, applications usually deploy multiple server nodes at the same time. Sampling can be performed on each server node separately. The sample information includes the sampling time, the values ​​of various operating indicators, and the corresponding fault events. The indicator list and the event list in the figure are associated through the sample ID. The "event mark" in the indicator list can mark whether the sample has a corresponding event. If so, the "event mark" is "Y", and if not, it is "N". The information stored in the event list can be expanded as needed, such as manually entering or connecting to an existing operation and maintenance system to obtain details of event analysis and resolution, providing decision support for troubleshooting and resolution of identified fault risks. The database server cluster is sampled in a similar way.

[0109] Figure 5 This is a schematic diagram of the structure of the fault risk monitoring device provided in the embodiment of the present application. Figure 5 As shown, the fault risk monitoring device 50 includes: an acquisition module 501 , a matching module 502 and a generation module 503 .

[0110] The acquisition module 501 is used to acquire the current operating state of the system; the current operating state includes the current values ​​of multiple operating indicators;

[0111] A matching module 502 is used to match the current operation state with a plurality of historical operation states respectively, and obtain the matching degrees corresponding to the plurality of historical operation states respectively; different historical operation states correspond to different sampling times; the historical operation states include the historical values ​​of the plurality of operation indicators at the corresponding sampling times;

[0112] The generating module 503 is used to obtain the fault events under the historical operating state corresponding to the maximum values ​​of the multiple matching degrees, and generate a fault risk prompt according to the fault events.

[0113] The fault risk monitoring device provided in the embodiment of the present application obtains multiple current operating indicators, matches the multiple operating indicators with pre-collected historical indicators, and generates a fault risk prompt based on the fault events that occurred under the historical operating state with the greatest matching degree, thereby improving the comprehensiveness and accuracy of monitoring.

[0114] The fault risk monitoring device provided in the embodiment of the present application can be used to execute the above-mentioned method embodiment, and its implementation principle and technical effect are similar, which will not be repeated in this embodiment.

[0115] Figure 6 A schematic diagram of the hardware structure of a fault risk monitoring device provided in an embodiment of the present application, which device may be a terminal device or a server.

[0116] The device 60 may include one or more of the following components: a processing component 601 , a memory 602 , a power component 603 , a multimedia component 604 , an audio component 605 , an input / output (I / O) interface 606 , a sensor component 607 , and a communication component 608 .

[0117] The processing component 601 generally controls the overall operation of the device 60, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 601 may include one or more processors 609 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 601 may include one or more modules to facilitate the interaction between the processing component 601 and other components. For example, the processing component 601 may include a multimedia module to facilitate the interaction between the multimedia component 604 and the processing component 601.

[0118] The memory 602 is configured to store various types of data to support operations on the device 60. Examples of such data include instructions for any application or method operating on the device 60, contact data, phone book data, messages, pictures, videos, etc. The memory 602 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0119] The power supply component 603 provides power to the various components of the device 60. The power supply component 603 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device 60.

[0120] The multimedia component 604 includes a screen that provides an output interface between the device 60 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 604 includes a front camera and / or a rear camera. When the device 60 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0121] The audio component 605 is configured to output and / or input audio signals. For example, the audio component 605 includes a microphone (MIC), and when the device 60 is in an operation mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 602 or sent via the communication component 608. In some embodiments, the audio component 605 also includes a speaker for outputting audio signals.

[0122] I / O interface 606 provides an interface between processing component 601 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: home button, volume button, start button, and lock button.

[0123] The sensor assembly 607 includes one or more sensors for providing various aspects of the status assessment of the device 60. For example, the sensor assembly 607 can detect the open / closed state of the device 60, the relative positioning of components, such as the display and keypad of the device 60, and the sensor assembly 607 can also detect the position change of the device 60 or a component of the device 60, the presence or absence of user contact with the device 60, the orientation or acceleration / deceleration of the device 60, and the temperature change of the device 60. The sensor assembly 607 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 607 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 607 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0124] The communication component 608 is configured to facilitate wired or wireless communication between the device 60 and other devices. The device 60 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 608 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 608 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0125] In an exemplary embodiment, the device 60 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components to perform the above-mentioned methods.

[0126] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 602 including instructions, and the instructions can be executed by a processor 609 of the device 60 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0127] The computer-readable storage medium mentioned above can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0128] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0129] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0130] An embodiment of the present application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, the fault risk monitoring method performed by the fault risk monitoring device as described above is implemented.

[0131] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A fault risk monitoring method, characterized in that: include: Get the current running status of the system; The current operating state includes current values ​​of a plurality of operating indicators; Matching the current running state with a plurality of historical running states respectively to obtain the matching degrees corresponding to the plurality of historical running states respectively; different historical running states correspond to different sampling times; the historical running states include the historical values ​​of the plurality of running indicators at the corresponding sampling times; Acquire a plurality of fault events under historical operating conditions corresponding to the maximum values ​​of the matching degrees, and generate a fault risk prompt according to the fault events; Before matching the current running state with a plurality of historical running states respectively, the method further includes: Divide the preset collection period into multiple time intervals; For each time interval, historical operation status is collected according to the sampling frequency corresponding to the time interval, and the collected historical operation status is associated with the fault event occurring at the corresponding collection time and stored; wherein the fault event includes a fault event reported by operation and maintenance personnel or users when all indicators are normal; Before collecting the historical operating status according to the sampling frequency corresponding to the time interval, the method further includes: Determine the required quantity of failure events based on confidence requirements and sampling error requirements; Collecting a plurality of fault events according to the demand; Dividing the multiple fault events into multiple different time intervals; For each time interval, obtaining the number of fault events occurring in the time interval; The sampling frequencies respectively corresponding to the multiple time intervals are determined according to the numbers of fault events respectively corresponding to the multiple time intervals.

2. The method according to claim 1, characterized in that The matching of the current running state with a plurality of historical running states respectively includes: If the multiple current values ​​do not exceed the corresponding preset threshold range, the current operating state is matched with the multiple historical operating states respectively.

3. The method according to claim 1, characterized in that After obtaining the current operating status of the system, the method further includes: If at least one of the multiple current values ​​exceeds the corresponding preset threshold range, a corresponding fault warning is generated; Filtering and obtaining a plurality of operating states to be matched from the plurality of historical operating states; the fault events corresponding to the operating states to be matched include the fault events corresponding to the fault warnings; The matching the current running state with a plurality of historical running states respectively to obtain the matching degrees respectively corresponding to the plurality of historical running states includes: The current running state is matched with the plurality of running states to be matched respectively, and the matching degrees corresponding to the plurality of running states to be matched are obtained respectively.

4. The method according to any one of claims 1 to 3, characterized in that: The matching the current running state with a plurality of historical running states respectively to obtain the matching degrees respectively corresponding to the plurality of historical running states includes: Acquire a first vector of the current running state and a plurality of second vectors of the historical running states; For the second vector of each historical operating state in the plurality of historical operating states, a Mahalanobis distance between the first vector and the second vector is calculated, and a matching degree corresponding to the historical operating state is determined according to the Mahalanobis distance.

5. The method according to claim 1, characterized in that The determining, according to the number of fault events respectively corresponding to the plurality of time intervals, the sampling frequencies respectively corresponding to the plurality of time intervals comprises: Determine the number of collection times corresponding to the preset collection period; For each time interval, a ratio between the number of fault events corresponding to the time interval and the total number of the multiple fault events is calculated, and a sampling frequency corresponding to the time interval is determined according to the ratio and the number of acquisition times.

6. The method according to claim 1, characterized in that Before collecting the historical operation status for each time interval according to the sampling frequency corresponding to the time interval, the method further includes: Determine the target duration based on the software iteration frequency; For each time interval, collecting the historical operation status according to the sampling frequency corresponding to the time interval includes: For each time interval within a plurality of preset collection periods corresponding to the target duration, collect historical operating status according to a sampling frequency corresponding to the time interval, and add the collected historical operating status to a sample set; The matching of the current running state with a plurality of historical running states respectively includes: The current running state is matched with a plurality of historical running states in the sample set respectively.

7. A fault risk monitoring device, characterized in that: include: An acquisition module, used to acquire the current operating state of the system; the current operating state includes current values ​​of multiple operating indicators; It is also used to divide the preset collection period into multiple time intervals; determine the demand for fault events according to the confidence requirement and the sampling error requirement; collect multiple fault events according to the demand; divide the multiple fault events into multiple different time intervals; for each time interval, obtain the number of fault events occurring in the time interval; determine the sampling frequencies corresponding to the multiple time intervals according to the number of fault events corresponding to the multiple time intervals; for each time interval, collect the historical operation status according to the sampling frequency corresponding to the time interval, and associate the collected historical operation status with the fault events occurring at the corresponding collection time and store them; wherein the fault events include fault events reported by operation and maintenance personnel or users when all indicators perform normally; A matching module, used to match the current operation state with a plurality of historical operation states respectively, and obtain the matching degrees corresponding to the plurality of historical operation states respectively; different historical operation states correspond to different sampling times; the historical operation states include the historical values ​​of the plurality of operation indicators at the corresponding sampling times; A generation module is used to obtain a fault event under a historical operating state corresponding to a maximum value among a plurality of the matching degrees, and generate a fault risk prompt according to the fault event.

8. A fault risk monitoring device, characterized in that: include: at least one processor and memory; The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the failure risk monitoring method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the fault risk monitoring method according to any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the failure risk monitoring method according to any one of claims 1 to 6 is implemented.

Images