CN115729783A - Failure risk monitoring method, device, storage medium and program product - Google Patents

Abstract

Embodiments of the present application provide a failure risk monitoring method, device, storage medium, and program product. The method includes obtaining the current operating status of the system, the current operating status includes the current values of multiple operating indicators, and combining the current operating status with multiple historical The running status is matched separately to obtain the corresponding matching degrees of multiple historical running statuses. Different historical running statuses correspond to different sampling times. The historical running status includes multiple running indicators that have the largest matching degree among the historical values corresponding to the sampling time. Fault events in the historical operating state corresponding to the value, and generate fault risk prompts based on the fault events. The method provided in this embodiment can improve the comprehensiveness and accuracy of monitoring.

Description

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

technical field

The embodiments of the present application relate to the technical field of software testing, and in particular to a failure risk monitoring method, device, storage medium and program product.

Background technique

In order to ensure the normal operation of the software, production operation and maintenance personnel usually monitor the operation of the servers, databases, networks, and clients deployed by the application system, and track down and locate problems based on the monitored indicator data.

In related technologies, an early warning is usually given when one or more indicators exceed a threshold.

However, during 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 provide early warnings for the monitored indicators, and it often happens that failure warnings are not issued when there is a risk of failure. Comprehensiveness and accuracy are low.

Contents of the invention

Embodiments of the present application provide a failure risk monitoring method, device, storage medium, and program product, so as to improve the comprehensiveness and accuracy of monitoring.

In the first aspect, the embodiment of the present application provides a failure risk monitoring method, including:

Obtain 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 to obtain matching degrees corresponding to the multiple historical operating states; different historical operating states correspond to different sampling times; the historical operating states include multiple The historical value of the running indicator at the corresponding sampling time;

Obtaining a plurality of fault events in the historical operating state corresponding to the maximum value among the matching degrees, and generating a fault risk prompt according to the fault events.

In a possible design, said matching the current running state with multiple historical running states respectively includes:

If none of the multiple current values exceeds the corresponding preset threshold range, the current running state is matched with multiple historical running states respectively.

In a possible design, after the acquisition of the current operating state of the system, further includes:

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

Obtaining a plurality of operating states to be matched by screening from a plurality of historical operating states; the fault event corresponding to the operating state to be matched includes the fault event corresponding to the fault warning;

The step of matching the current operating state with multiple historical operating states to obtain matching degrees respectively corresponding to the multiple historical operating states includes:

Matching the current operating state with the plurality of operating states to be matched respectively to obtain matching degrees respectively corresponding to the operating states to be matched.

In a possible design, the matching of the current running state and multiple historical running states to obtain matching degrees corresponding to the multiple historical running states respectively includes:

Acquiring the first vector of the current running state and a plurality of second vectors of the historical running state;

Computing the Mahalanobis distance between the first vector and the second vector for the second vector of each historical operating state among the plurality of historical operating states, and determining the historical The matching degree corresponding to the running status.

In a possible design, before the matching of the current running state and multiple historical running states respectively, further includes:

Divide the preset collection period into multiple time intervals;

For each time interval, the historical operation state is collected according to the sampling frequency corresponding to the time interval, and the collected historical operation state is associated and stored with the fault event occurring at the corresponding collection time.

In a possible design, before performing the collection of the historical operation state according to the sampling frequency corresponding to the time interval, it also includes:

According to the confidence requirements and sampling error requirements, determine the demand for fault events;

collecting a plurality of fault events according to the demand;

dividing the plurality of fault events into a plurality of different time intervals;

For each time interval, obtain the number of fault events occurring in the time interval;

According to the number of fault events respectively corresponding to the multiple time intervals, the sampling frequencies respectively corresponding to the multiple time intervals are determined.

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

Determining the number of acquisitions corresponding to the preset acquisition period;

For each time interval, calculate the ratio between the number of fault events corresponding to the time interval and the total number of the plurality of fault events, and determine the sampling corresponding to the time interval according to the ratio and the number of acquisitions frequency.

In a possible design, for each time interval, before collecting the historical operation state according to the sampling frequency corresponding to the time interval, it also includes:

Determine the target duration according to the software iteration frequency;

For each time interval, the collection of historical operation status according to the sampling frequency corresponding to the time interval includes:

For each time interval in the plurality of preset collection periods corresponding to the target duration, collect the historical operation state according to the sampling frequency corresponding to the time interval, and add the collected historical operation state to the sample set;

The matching of the current running state with multiple historical running states respectively includes:

The current running state is matched with multiple historical running states in the sample set respectively.

In the second aspect, the embodiment of the present application provides a failure risk monitoring device, including:

An acquisition module, configured to acquire the current operating state of the system; the current operating state includes current values of multiple operating indicators;

A matching module, configured to match the current operating state with a plurality of historical operating states, respectively, to obtain matching degrees corresponding to a plurality of the historical operating states; different historical operating states correspond to different sampling times; the historical operating states Including multiple historical values of the operating indicators at corresponding sampling times;

A generating module, configured to obtain a plurality of fault events in historical operating states corresponding to the maximum value among the matching degrees, and generate fault risk prompts according to the fault events.

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

the memory stores computer-executable instructions;

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

In the fourth aspect, the embodiment of the present application provides a computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the above first aspect and the first Aspects of various possible designs of the described method.

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, the method described in the above first aspect and various possible designs of the first aspect is implemented.

The failure risk monitoring method, device, storage medium and program product provided in this embodiment, the method includes obtaining the current operating state of the system, the current operating state includes the current values of multiple operating indicators, and combining the current operating state with the multiple historical operating states Matching is performed separately to obtain the matching degrees corresponding to multiple historical operating states. Different historical operating states correspond to different sampling times. The historical operating states include multiple operating indicators at the historical values corresponding to the sampling time. Fault events in the historical operating state of the system, and generate fault risk prompts based on the fault events. 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 events based on the historical operating status with the highest matching degree Failure risk prompts can improve the comprehensiveness and accuracy of monitoring.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description These are some embodiments of the present application. Those skilled in the art can also obtain other drawings based on these drawings without any creative effort.

FIG. 1 is a schematic diagram of an application scenario of a failure risk monitoring method provided in an embodiment of the present application;

Fig. 2 is a schematic flow diagram 1 of the failure risk monitoring method provided by the embodiment of the present application;

FIG. 3 is a schematic flow diagram II of the failure risk monitoring method provided by the embodiment of the present application;

FIG. 4 is a schematic diagram of a sample of an application server cluster provided by an embodiment of the present application;

FIG. 5 is a schematic structural diagram of a failure risk monitoring device provided in an embodiment of the present application;

FIG. 6 is a schematic diagram of a hardware structure of a failure risk monitoring device provided by an embodiment of the present application.

Detailed ways

In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions 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 It is a part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without creative efforts fall within the protection scope of this application.

In order to ensure the normal operation of the software, production operation and maintenance personnel usually monitor the operation of the servers, databases, networks, and clients deployed in the application system, and realize early warning of failure risks by setting performance monitoring indicators and indicator thresholds, and according to the monitored indicators data to track down and locate problems.

Related performance risk early warning systems usually provide early warning when one or more indicators exceed the threshold, but there are two deficiencies in actual application scenarios: First, the existing early warning system can only provide early warning for the monitored indicators, but There are some performance indicators that cannot be comprehensively monitored due to the difficulty of monitoring. The potential risks brought by these monitoring loopholes cannot be covered by the traditional threshold early warning system, and the monitoring is not comprehensive; the second is when the values of the monitored indicators are all lower than the threshold , the threshold warning system will think 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.

In order to solve the above technical problems, the inventors of the present application found that the matching degree between the current operating index values of the application system and the samples can be calculated by collecting the operating index values and failure data of the application system in the past period of time as samples. Find the sample with the highest matching degree. This sample can be determined to be the closest to the running state of the current application system. If the sample contains a fault event, it can be judged that the system has a fault risk. At the same time, the solution and details of the sample fault event can be Provided to relevant personnel for reference. Based on this, an embodiment of the present application provides a failure risk monitoring method, which can improve the comprehensiveness and accuracy of monitoring.

FIG. 1 is a schematic diagram of an application scenario of a fault risk monitoring method provided by an embodiment of the present application. As shown in FIG. 1 , a server 101 is communicatively connected with a monitoring device 102 .

In a specific implementation process, the server 101 collects and sends the current running status to the monitoring device 102'. The monitoring device 102 acquires a current operating state; the current operating state includes current values of multiple operating indicators; matching the current operating state with multiple historical operating states respectively, and obtaining matching matches corresponding to the multiple historical operating states Different historical operating states correspond to different sampling times; the historical operating states include multiple historical values of the operating indicators at the corresponding sampling times; obtain the faults in the historical operating states corresponding to the maximum value among the multiple matching degrees event, and generate a fault risk prompt according to the fault event. The fault risk monitoring method provided by the embodiment of the present application acquires multiple current operating indicators, matches the multiple operating indicators with pre-collected historical indicators, and generates Failure risk prompts can improve the comprehensiveness and accuracy of monitoring.

Wherein, the monitoring device 102 may be a terminal device or a server.

The server 101 may be one type of server or multiple types of servers. When multiple types of servers are used, it may be determined whether to monitor the various types of servers based on the similarities and differences of the operating indicators of the servers.

Exemplarily, the server 101 may be an application server, and the current operating status of the application server may include multiple operating indicators, for example: service resource types: CPU usage, disk space usage, disk index node inode usage, memory space usage , the number of zombie processes; network category: bandwidth utilization rate, TCP connection status; application programming interface (Application Programming Interface, API) category: API accuracy rate, API response time; business volume category: current number of online users, etc. The server 102 can also be a database server, and the current operating state of the database server can include multiple operating indicators, such as: service resource class: CPU utilization, disk space utilization, disk index node inode utilization, memory space utilization, zombie process Network category: bandwidth utilization, TCP connection status; database category: time consumed by slow SQL, table space usage, the ratio of active connections to the maximum number of connections, and the number of deadlock errors (ORA-60) in early warning alert logs wait.

If 101 servers are application servers and database servers, the application servers and database servers can be considered separately during sampling and risk assessment because the indicators to be collected by the application servers and database servers are different, and the corresponding fault events can also be clearly divided belong. It should be noted that, in order to facilitate the capture of problems, they can be classified according to the location of the event error report, that is, the appearance of the problem rather than the root cause, that is, the problems found on the application server side and the problems found on the database server side.

In addition, the occurrence of fault events can also be divided into two situations: one is that a certain operating index of the system exceeds the set threshold, that is, the index performance is abnormal, and the early warning system automatically issues a fault early warning. Such events correspond to clear abnormalities Index items can be directly judged based on the attribution of the index items to determine whether it is a problem on the application server side or a problem on the database server side; Events require human judgment to determine classification.

It should be noted that the schematic diagram of the scene shown in Figure 1 is only an example, and the fault risk monitoring method and scene described in the embodiment of the present application are for more clearly illustrating the technical solution of the embodiment of the present application, and do not constitute a reference to the implementation of the present application. Those skilled in the art know that, with the evolution of the system and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

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

FIG. 2 is a first schematic flowchart of a failure risk monitoring method provided by an embodiment of the present application. As shown in Figure 2, the method includes:

201. Acquire the current operating state of the system; the current operating state includes current values of multiple operating indicators.

The execution subject of this embodiment may be a terminal device or a server, such as the monitoring device 102 shown in FIG. 1 .

The system in this embodiment may be a system installed and running on the server 101 as shown in FIG. 1 .

202. Match the current operating state with multiple historical operating states to obtain matching degrees corresponding to the multiple historical operating states; different historical operating states correspond to different sampling times; the historical operating states include multiple The historical value of the operating index at the corresponding sampling time.

Specifically, the current operating indicators of the application system can be traversed, and when an 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 index items exceeding the threshold are detected, they can be processed separately based on the value of m.

In this embodiment, there are many ways to match the current running state and the historical running state. In some embodiments, the current running state is matched with multiple historical running states to obtain multiple historical running states The matching degrees corresponding to the states may include: acquiring the first vector of the current operating state and the second vectors of the plurality of historical operating states; Two vectors, calculating the Mahalanobis distance between the first vector and the second vector, and determining the matching degree corresponding to the historical operation status according to the Mahalanobis distance.

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

Among them, x and y respectively represent the vectors of each operating index value of the current system and each operating index value vector of a certain sample, 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.

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

Among them, m is the sample size, n is the number of running indicators, ci indicates 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.

In some embodiments, for the situation where the threshold warning is not triggered, for the comprehensiveness of monitoring, full matching of each operating index can be performed. Specifically, the matching of the current operating state and multiple historical operating states respectively, It may include: if none of the multiple current values exceeds the corresponding preset threshold range, that is, m=0, matching the current running state with multiple historical running states respectively. Exemplarily, the Mahalanobis distance between the current operating index values of the application system and all samples in the sample set S can be calculated, and the ID of the sample with the smallest distance (the highest matching degree) to the current operating index can be recorded.

In some embodiments, when a threshold warning has been triggered, in order to save computing resources, matching processing may be performed only on operating indicators whose current values exceed the threshold range. Specifically, after acquiring the current operating state of the system, it may also include: if at least one of the multiple current values exceeds the corresponding preset threshold range, generating a corresponding fault warning; Multiple running states to be matched are obtained by screening the historical running states; the fault events corresponding to the running states to be matched include the fault events corresponding to the fault warning; Matching, obtaining matching degrees respectively corresponding to a plurality of the historical operation states may include: respectively matching the current operation state with the plurality of operation states to be matched, and obtaining the matching degrees corresponding to the plurality of operation states to be matched respectively suitability.

Exemplarily, for the situation 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 whose "event mark" is "Y" in the sample set S, and Record the sample ID with the smallest distance from the current running metric.

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

Exemplarily, after obtaining the minimum distance sample ID corresponding to the maximum matching degree, combine the "event flag" of the sample to determine whether the application system currently has a failure risk, and the "event flag" is "Y" indicating that there is a risk, then The front-end page prompts risk warning, matched sample details, and corresponding incident resolution analysis details; "Event Mark" is "N" to indicate that there is no risk, and there is no risk warning on the front-end page.

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 events based on the historical operating status with the highest matching degree Failure risk prompts can improve the comprehensiveness and accuracy of monitoring.

FIG. 3 is a second schematic flow diagram of the failure risk monitoring method provided by the embodiment of the present application. As shown in FIG. 3, on the basis of the above-mentioned embodiments, for example, on the basis of the embodiment shown in FIG. 2, this embodiment exemplifies the historical operation status, that is, the generation and maintenance process of the risk assessment sample set. , the method includes:

301. Divide the preset collection period into multiple time intervals.

302. For each time interval, collect historical operation statuses according to the sampling frequency corresponding to the time intervals, and store the collected historical operation statuses in association with fault events occurring at corresponding collection times.

Specifically, the values of various operating indicators of the application system are constantly changing over time. According to experience, the daily business peak period and the execution of batch tasks are more prone to failure than other time periods. Therefore, in order to make the collected samples more representative, it is necessary to conduct a pre-investigation on the recent production events of the system, and set a reasonable sampling frequency according to the time distribution of production events.

In some embodiments, in order to save computing resources, different sampling frequencies are used in different time intervals, and the method of determining the sampling frequency may include: determining the demand of fault events according to the requirements of confidence and sampling error; fault events; divide the plurality of fault events into a plurality of different time intervals; for each time interval, obtain the number of fault events occurring in the time interval; The number of events determines the sampling frequencies respectively corresponding to the multiple time intervals.

In some embodiments, in order to set the sampling frequency more reasonably, it may be determined based on parameters such as the fluctuation period of the software function. Specifically, the determining the sampling frequencies corresponding to the multiple time intervals according to the number of fault events respectively corresponding to the multiple time intervals may include: determining the number of acquisitions corresponding to the preset acquisition period; time interval, calculate the ratio between the number of fault events corresponding to the time interval and the total number of the plurality of fault events, and determine the sampling frequency corresponding to the time interval according to the ratio and the number of acquisitions.

In some embodiments, the determination of the coverage duration of the sample set may refer to software iteration frequency to improve rationality. Specifically, the target duration can be determined according to the software iteration frequency; for each time interval, the collection of the historical running state according to the sampling frequency corresponding to the time interval may include: multiple presets corresponding to the target duration For each time interval in the collection cycle, collect the historical running state according to the sampling frequency corresponding to the time interval, and add the collected historical running state to the sample set; the described current running state and multiple historical running states Performing the matching separately may include: respectively matching the current running status with multiple historical running statuses in the sample set.

Exemplarily, first, the sample size of the pre-survey can be estimated according to the general estimation formula of the classification variable, and the calculation formula is shown in the following formula (3):

Among them, n is the sample size, z is obtained by looking up the z value table according to the confidence interval, p is the expected value of the proportion of the target population, and δ is the range of sampling error.

Exemplarily, if the confidence interval is set to 95% (z value is 1.96), the sampling error range is 4%, and the maximum value of p(1-p) is 0.25, the obtained sample size n is 600.25, which is at the confidence level of 95%. , If the sampling error range is 4%, it is necessary to collect the data of 601 recent production events of the software for investigation and analysis.

Secondly, the pre-survey samples can be collected according to the sample size estimated above, and divided into multiple time intervals according to 24 hours a day, for example, it can be divided 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 that occur in each time interval, and calculate the number of events in each interval as a percentage of the sample The proportion of the total amount: b1, b2, b3, b4, ..., b24.

Thirdly, the frequency of sampling in different time intervals can be set according to the proportions b1, b2, b3, b4, . . . , b24 of the number of events in each time interval obtained above. The higher the proportion of the number of events, it means that the system is more likely to fail during this time interval, so the sampling frequency should be higher. It is reasonable to assume that the various performance indicators of the software are sampled every n minutes on average (because the various performance indicators of the software generally do not fluctuate greatly within n minutes, even if the indicators fluctuate greatly, they can be sampled in the next n minutes period. The index value mutation collected within a short period of time can be regarded as noise, for example, n can be 5), then a total of 288 samples are taken in one day, and the sampling frequency of each interval is b1×288, b2×288,… , b24×288, denoted as: f1, f2, f3, ..., f24.

Thirdly, in addition to the automatic warning triggered by exceeding the threshold, other fault events require manual maintenance of event information, or docking with 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 early warning event occurred, and add the event information to the event list associated with the sample.

Finally, the time period covered by the sample can be comprehensively considered and determined in combination with the software iteration frequency and the number of failures. For example, collecting the samples of the system running in the past 15 days and the samples of the failure events in the past 180 days. This setting is because most of the time the system They are all running normally, and multiple servers collect data every 5 minutes. The sample size collected in 15 days is enough to represent the normal operation status of the system (the sample size of a server in 15 days is 4320), compared to failure events It is only an occasional event, and the sampling period needs to be lengthened to obtain enough samples. Every time a new day's samples are collected, the risk assessment system will automatically clear expired samples and complete the automatic update of the sample set S.

303. Acquire the current operating state of the system; the current operating state includes current values of multiple operating indicators.

304. Match the current running state with multiple historical running states respectively to obtain matching degrees corresponding to the multiple historical running states; different historical running states correspond to different sampling times; the historical running state includes multiple The historical value of the operating index at the corresponding sampling time.

305. Obtain multiple fault events in historical operating states corresponding to the maximum value among the matching degrees, and generate a fault risk prompt according to the fault events.

Steps 303 to 305 in this embodiment are similar to steps 201 to 203 in the above embodiment, and will not be repeated here.

The failure risk monitoring method provided in this embodiment makes the collected samples more representative by adopting different sampling frequencies for different time zones. Therefore, the amount of collection can be reduced, the pertinence of sample collection can be increased, and the calculation efficiency can be improved in subsequent calculations, saving calculation resources.

In order to illustrate the composition of the sample set S more clearly, the following uses an example to illustrate the sample collection process of the application server cluster.

Fig. 4 is a schematic diagram of sampling for an application server cluster provided by the embodiment of the present application. As shown in Fig. 4, an application usually deploys multiple server nodes at the same time, and each server node can be sampled separately. The sample information includes sampling time, various Run indicator values and corresponding fault events, as shown in the figure, the indicator list and event list are associated through the sample ID. The "event mark" in the index list can mark whether there is a corresponding event in the sample. If there is, the "event mark" will be "Y", and if it does not exist, it will be "N". The information stored in the event list can be expanded according to needs, such as manual entry or docking with the existing operation and maintenance system to obtain details of event analysis and resolution, and provide decision support for troubleshooting and resolution of identified failure risks. Database server clusters are sampled in a similar fashion.

FIG. 5 is a schematic structural diagram of a failure risk monitoring device provided in an embodiment of the present application. As shown in FIG. 5 , the failure risk monitoring device 50 includes: an acquisition module 501 , a matching module 502 and a generation module 503 .

An acquisition module 501, configured to acquire the current operating state of the system; the current operating state includes the current values of multiple operating indicators;

The matching module 502 is configured to match the current operating state with a plurality of historical operating states respectively, and obtain matching degrees corresponding to the plurality of historical operating states; different historical operating states correspond to different sampling times; the historical operating states The state includes a plurality of historical values of the operating indicators at the corresponding sampling time;

The generating module 503 is configured to obtain a plurality of fault events in the historical operating state corresponding to the maximum value among the matching degrees, and generate a fault risk prompt according to the fault events.

The fault risk monitoring device provided in the embodiment of the present application obtains multiple current operating indicators and matches the multiple operating indicators with pre-collected historical indicators, and based on the fault events that occur in the historical operating state with the highest matching degree, Generate failure risk prompts, which can improve the comprehensiveness and accuracy of monitoring.

The failure risk monitoring device provided in the embodiment of the present application can be used to implement the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not repeat them here.

FIG. 6 is a schematic diagram of a hardware structure of a failure risk monitoring device provided in an embodiment of the present application, and the device may be a terminal device or a server.

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

The processing component 601 generally controls the overall operations of the device 60, such as those associated with display, telephone 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 method. Additionally, processing component 601 may include one or more modules to facilitate interaction between processing component 601 and other components. For example, the processing component 601 may include a multimedia module to facilitate interaction between the multimedia component 604 and the processing component 601 .

Memory 602 is configured to store various types of data to support operations at device 60 . Examples of such data include instructions for any application or method operating on device 60, contact data, phonebook data, messages, pictures, videos, and the like. The memory 602 can be implemented by any type of volatile or non-volatile storage device or their combination, 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 or Optical Disk.

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

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 a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may not only sense a boundary of a touch or swipe action, but also detect duration and pressure associated with the touch or swipe action. In some embodiments, the multimedia component 604 includes a front camera and/or a rear camera. When the device 60 is in an operation mode, such as a shooting mode or a video mode, the front camera and/or the rear camera can receive external multimedia data. Each front camera and rear camera can be a fixed optical lens system or have focal length and optical zoom capability.

The audio component 605 is configured to output and/or input audio signals. For example, the audio component 605 includes a microphone (MIC) configured to receive external audio signals when the device 60 is in operating modes, such as calling mode, recording mode and voice recognition mode. Received audio signals may be further stored in memory 602 or sent via communication component 608 . In some embodiments, the audio component 605 also includes a speaker for outputting audio signals.

The I/O interface 606 provides an interface between the processing component 601 and a peripheral interface module, which may be a keyboard, a click wheel, a button, and the like. These buttons may include, but are not limited to: a home button, volume buttons, start button, and lock button.

Sensor assembly 607 includes one or more sensors for providing various aspects of status assessment for device 60 . For example, the sensor component 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 component 607 can also detect a change in the position of the device 60 or a component of the device 60 , the presence or absence of user contact with the device 60 , the device 60 orientation or acceleration/deceleration and the temperature change of the device 60 . The sensor assembly 607 may include a proximity sensor configured to detect the presence of nearby objects in the absence of 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 component 607 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor or a temperature sensor.

The communication component 608 is configured to facilitate wired or wireless communication between the apparatus 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 broadcast signals 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 may be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, Bluetooth (BT) technology and other technologies.

In an exemplary embodiment, apparatus 60 may be programmed by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable A gate array (FPGA), controller, microcontroller, microprocessor or other electronic component implementation for performing the methods described above.

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

The above-mentioned computer-readable storage medium, the above-mentioned readable storage medium can be realized by any type of volatile or non-volatile storage device or their combination, 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 or Optical Disk. Readable storage media can be any available media that can be accessed by a general purpose or special purpose computer.

An exemplary readable storage medium is coupled to the processor such the processor can read information from, 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 may be located in application specific integrated circuits (Application Specific Integrated Circuits, ASIC for short). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

Those of ordinary skill in the art can understand that all or part of the steps for implementing the above method embodiments can be completed by program instructions and related hardware. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps including the above-mentioned method embodiments; and the aforementioned storage medium includes: ROM, RAM, magnetic disk or optical disk and other various media that can store program codes.

An embodiment of the present application further provides a computer program product, including a computer program, and when the computer program is executed by a processor, the above failure risk monitoring method performed by the failure risk monitoring device is implemented.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit it; although the application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: It is still possible to modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the various embodiments of the present application. scope.

Claims (12)

1. A fault risk monitoring method, comprising:

acquiring the current running state of the system; the current operating state comprises current values of a plurality of operating indicators;

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; different historical operating states correspond to different sampling times; the historical operating state comprises historical values of a plurality of operating indexes at corresponding sampling time;

and acquiring a fault event under a historical operating state corresponding to the maximum value in the matching degrees, and generating a fault risk prompt according to the fault event.

2. The method of claim 1, wherein said matching said current operating state to a plurality of historical operating states, respectively, comprises:

and if the current values do not exceed the corresponding preset threshold value ranges, respectively matching the current running state with the historical running states.

3. The method of claim 1, wherein after obtaining the current operating state of the system, further comprising:

if at least one current value in the current values exceeds a corresponding preset threshold range, generating a corresponding fault early warning;

screening a plurality of historical operating states to obtain a plurality of operating states to be matched; the fault event corresponding to the running state to be matched comprises a fault event corresponding to the fault early warning;

the matching the current operating state with the plurality of historical operating states respectively to obtain matching degrees corresponding to the plurality of historical operating states respectively comprises:

and respectively matching the current running state with the running states to be matched to obtain matching degrees respectively corresponding to the running states to be matched.

4. The method according to any one of claims 1 to 3, wherein the matching the current operating state with a plurality of historical operating states respectively to obtain matching degrees corresponding to the plurality of historical operating states respectively comprises:

acquiring a first vector of the current running state and a plurality of second vectors of the historical running states;

and aiming at a second vector of each historical operating state in a plurality of 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.

5. The method according to any of claims 1-3, wherein prior to matching the current operating state with a plurality of historical operating states, respectively, further comprising:

dividing a preset acquisition period into a plurality of time intervals;

and aiming at each time interval, acquiring historical operating states according to the sampling frequency corresponding to the time interval, and performing associated storage on the acquired historical operating states and fault events occurring at corresponding acquisition moments.

6. The method according to claim 5, wherein before the collecting of the historical operating state according to the sampling frequency corresponding to the time interval, the method further comprises:

determining the demand of the fault event according to the confidence coefficient demand and the sampling error demand;

collecting a plurality of fault events according to the demand;

dividing the plurality of fault events into a plurality of different time intervals;

acquiring the number of fault events occurring in each time interval;

and determining sampling frequencies corresponding to the time intervals according to the number of the fault events corresponding to the time intervals.

7. The method according to claim 6, wherein the determining sampling frequencies corresponding to the plurality of time intervals according to the number of fault events corresponding to the plurality of time intervals comprises:

determining the acquisition times corresponding to the preset acquisition period;

and calculating the ratio of the number of the fault events corresponding to each time interval to the total number of the plurality of fault events, and determining the sampling frequency corresponding to each time interval according to the ratio and the acquisition times.

8. The method according to claim 5, wherein before the collecting of the historical operating state according to the sampling frequency corresponding to the time interval for each time interval, the method further comprises:

determining a target duration according to the software iteration frequency;

the collecting of the historical operating state according to the sampling frequency corresponding to each time interval comprises the following steps:

aiming at each time interval in a plurality of preset acquisition periods corresponding to the target duration, acquiring historical operating states according to sampling frequency corresponding to the time interval, and adding the acquired historical operating states into a sample set;

the matching the current operating state with the plurality of historical operating states respectively includes:

and respectively matching the current running state with a plurality of historical running states in the sample set.

9. A fault risk monitoring device, comprising:

the acquisition module is used for acquiring the current running state of the system; the current operating state comprises current values of a plurality of operating indicators;

the matching module is used for respectively matching the current running state with a plurality of historical running states to obtain matching degrees respectively corresponding to the plurality of historical running states; different historical operating states correspond to different sampling times; the historical operating state comprises historical values of a plurality of operating indexes at corresponding sampling time;

and the generating module is used for acquiring a fault event in a historical operating state corresponding to the maximum value in the matching degrees and generating a fault risk prompt according to the fault event.

10. A fault risk monitoring device, comprising: at least one processor and memory;

the memory stores computer-executable instructions;

the at least one processor executing computer-executable instructions stored by the memory causes the at least one processor to perform the fault risk monitoring method of any of claims 1 to 8.

11. A computer-readable storage medium having computer-executable instructions stored thereon which, when executed by a processor, implement the fault risk monitoring method of any one of claims 1 to 8.

12. A computer program product comprising a computer program, characterized in that the computer program, when being executed by a processor, carries out the fault risk monitoring method according to any one of claims 1 to 8.

Images