CN112260858A - Alarm method capable of automatic detection and terminal - Google Patents
Alarm method capable of automatic detection and terminal Download PDFInfo
- Publication number
- CN112260858A CN112260858A CN202011059023.1A CN202011059023A CN112260858A CN 112260858 A CN112260858 A CN 112260858A CN 202011059023 A CN202011059023 A CN 202011059023A CN 112260858 A CN112260858 A CN 112260858A
- Authority
- CN
- China
- Prior art keywords
- alarm
- data
- request data
- historical
- threshold value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0876—Aspects of the degree of configuration automation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Mathematical Physics (AREA)
- Automation & Control Theory (AREA)
- Telephonic Communication Services (AREA)
Abstract
The invention discloses an alarm method and a terminal capable of automatic detection; the invention comprises the following steps: acquiring all historical request data in a first preset time period, and generating a daily alarm threshold according to the historical request data; monitoring and calculating request data in real time to obtain real-time alarm data, judging whether the real-time alarm data exceeds the alarm threshold value of the current day, and if so, generating and recording an alarm record; the historical request data in the preset period is calculated and counted, and a proper fluctuation upper limit is calculated according to a certain algorithm to serve as an alarm threshold value of the index. Therefore, the trouble of manually setting the threshold value is avoided, and the same index of different services can be ensured to have different alarm threshold values, so that differentiated service operation and maintenance are realized. In addition, the alarm threshold value can change along with the change of historical data, automatic updating every day is achieved, manual intervention and modification are not needed, and operation and maintenance cost is greatly saved.
Description
Technical Field
The invention relates to the technical field of network service operation and maintenance, in particular to an alarm method and a terminal capable of automatic detection.
Background
Currently, in the field of software service operation and maintenance, most of the existing alarm systems alarm around a fixed threshold or a manually set threshold. Namely, when the value of the operation and maintenance index of a certain software service exceeds a set alarm threshold value, the system triggers an alarm and pushes alarm information to software service developers.
The existing alarm system based on a fixed threshold or manually set the threshold has the following disadvantages:
1. the alarm system with fixed threshold value can not carry out differentiation operation and maintenance on different services. For example, regarding the operation and maintenance index of the average query response time of the MySQL, the background query of the A service is a table with small data volume, and the query is fast; the B service background needs to inquire the table with larger data quantity, and the inquiry is time-consuming. If the warning system sets the threshold value of the MySQL average query response time of all the services to be 1s, the warning sensitivity of the service A is very low, while the service B can trigger the warning all the time, and unnecessary harassment is caused to development personnel.
2. Setting the threshold manually is time consuming and labor intensive. Taking the company where the applicant is located as an example, the company currently has more than 2000 network services with different sizes, and dozens of different operation and maintenance indexes are arranged below each service, and a great amount of labor cost is consumed for manually establishing an alarm threshold value for each operation and maintenance index. Meanwhile, the work also requires that developers have abundant operation and maintenance experience.
3. The threshold cannot be updated automatically. No matter the alarm system is a fixed threshold or a manual threshold, once the threshold is set, the threshold cannot be changed, and when the external environment changes, developers need to change the appropriate threshold again, so that the operation and maintenance cost is increased.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: the alarm method and the terminal capable of automatic detection are provided, the alarm threshold value can be automatically updated according to the service historical data, differentiated service operation and maintenance are achieved, and meanwhile operation and maintenance cost is reduced.
In order to solve the technical problems, the invention adopts the technical scheme that:
an alarm method capable of automatic detection, comprising the following steps:
s1, acquiring all historical request data in a first preset time period, and generating a daily alarm threshold according to the historical request data;
and S2, monitoring and calculating the request data in real time to obtain real-time alarm data, judging whether the real-time alarm data exceeds the alarm threshold value of the current day, and if so, generating and recording an alarm record.
The invention has the beneficial effects that: according to the scheme, the historical request data in the preset period are calculated and counted, and the proper fluctuation upper limit is calculated according to a certain algorithm to serve as the alarm threshold of the index. Therefore, the trouble of manually setting the threshold value is avoided, and the same index of different services can be ensured to have different alarm threshold values, so that differentiated service operation and maintenance are realized. In addition, the alarm threshold value can change along with the change of historical data, automatic updating every day is achieved, manual intervention and modification are not needed, and operation and maintenance cost is greatly saved.
Drawings
FIG. 1 is a schematic diagram of a main flow of an alarm method capable of automatic detection according to an embodiment of the present invention;
FIG. 2 is a schematic flow chart of an alarm method capable of automatic detection according to an embodiment of the present invention;
fig. 3 is a schematic structural diagram of an alarm terminal capable of automatic detection according to an embodiment of the present invention.
Description of reference numerals:
1. an alarm terminal capable of automatic detection; 2. a processor; 3. a memory.
Detailed Description
In order to explain technical contents, achieved objects, and effects of the present invention in detail, the following description is made with reference to the accompanying drawings in combination with the embodiments.
Referring to fig. 1 and 2, an alarm method capable of automatic detection includes:
s1, acquiring all historical request data in a first preset time period, and generating a daily alarm threshold according to the historical request data;
and S2, monitoring and calculating the request data in real time to obtain real-time alarm data, judging whether the real-time alarm data exceeds the alarm threshold value of the current day, and if so, generating and recording an alarm record.
From the above description, the beneficial effects of the present invention are: the historical request data in the preset period is calculated and counted, and a proper fluctuation upper limit is calculated according to a certain algorithm to serve as an alarm threshold value of the index. Therefore, the trouble of manually setting the threshold value is avoided, and the same index of different services can be ensured to have different alarm threshold values, so that differentiated service operation and maintenance are realized. In addition, the alarm threshold value can change along with the change of historical data, automatic updating every day is achieved, manual intervention and modification are not needed, and operation and maintenance cost is greatly saved.
Further, the step S1 of generating the alarm threshold value for the current day according to the historical request data specifically includes:
s11, calculating a discrete coefficient of the historical record in a first preset time period, if the discrete coefficient is smaller than 1, generating a daily alarm threshold according to historical request data in the first preset time period, and if the discrete coefficient is larger than 1, generating the daily alarm threshold according to historical request data in a second preset time period, wherein the first preset time period is larger than the second preset time period.
According to the description, when the alarm threshold value on the day is calculated, the data volatility is judged by calculating the discrete coefficient, so that the time period data for calculating the alarm threshold value is selected, and the condition that the alarm threshold value is lowered due to lower data in the early stage to cause frequent alarm is avoided.
Further, the step S1 of generating the alarm threshold value for the current day according to the history request data further includes:
s12, calculating an average value and a standard deviation by using historical HTTP request data in a preset time period according to a '3 Sigma rule' of normal distribution, and taking the average value +3 times of the standard deviation as a daily alarm threshold value of each operation and maintenance index.
As can be seen from the above description, the method only needs to calculate the mean value and the standard deviation of the data, and greatly saves the calculation overhead in a big data scene.
Further, the step S1 is preceded by the steps of:
and S01, analyzing the network request agent log through a big data calculation tool at a preset fixed time every day, calculating and counting the request data of the previous day and storing the request data into a data warehouse, wherein the preset fixed time is earlier than the calculation time of the alarm threshold value of the current day.
According to the description, the network request agent log is analyzed and stored in the data warehouse before the alarm threshold value is calculated every day, and a data basis is provided for the calculation of the alarm threshold value on the following day.
Further, the method also comprises the following steps:
and S3, starting a timing scanning program, scanning the alarm records in the database, and if a new alarm record is found, packaging the alarm information and submitting to remind corresponding service personnel.
According to the description, the alarm records in the database are scanned through the timing scanning program, and corresponding service personnel can be reminded in time.
Referring to fig. 1 and fig. 2, a first embodiment of the present invention is:
an alarm method capable of automatic detection, comprising the following steps:
s01, analyzing the network request agent log through a big data calculation tool at a preset fixed time every day, calculating and counting the request data of the previous day and storing the request data into a data warehouse, wherein the preset fixed time is earlier than the calculation time of the alarm threshold value of the current day; corresponding to the "analyze yesterday's network request proxy log every day to get data index" and "write result into data warehouse" in fig. 2;
in this embodiment, the data index includes: 4xx request error rate (4xx request is the request with response status code beginning with 4, mostly caused by client error), 5xx request error rate (5xx request is the request with response status code beginning with 5, mostly caused by server error), average time consumption of HTTP request, MySQL slow request number and average time consumption of MySQL slow request.
In the following, we take the data index of "average time consumed by HTTP request" as an example to describe the specific operation details of each module. The average time consumption of HTTP requests is a data index used to describe how fast the web service responds. The index here takes minutes as the statistical granularity, and the average consumed time calculation formula of the HTTP request in a certain minute is as follows:
the average HTTP request consumption is the total consumed time of all HTTP requests and/or the total number of HTTP requests;
therefore, by means of a Spark big data calculation tool, in a T +1 off-line calculation mode (data of the previous day is calculated at fixed time every day), a Nginx log is analyzed (Nginx is a network request agent, all HTTP requests forwarded by the agent are recorded in the log in a certain format, the log comprises information such as request time, response time consumption, request state codes and the like), historical data of average time consumption of all service HTTP requests are stored in a table of a Hive data warehouse, and the granularity of aggregation calculation is in a minute level. In other words, the average elapsed time for all HTTP requests within a certain past minute of a certain service can be looked up through this table.
S1, acquiring all historical request data in a first preset time period, and generating a daily alarm threshold according to the historical request data; corresponding to "reading index history data of past two weeks from data warehouse" to "writing threshold result to database" of fig. 2;
the step S1 of generating the alarm threshold value for the current day according to the history request data specifically includes:
s11, calculating a discrete coefficient of the historical record in a first preset time period, if the discrete coefficient is smaller than 1, generating a daily alarm threshold according to historical request data in the first preset time period, and if the discrete coefficient is larger than 1, generating the daily alarm threshold according to historical request data in a second preset time period, wherein the first preset time period is larger than the second preset time period.
The step S1 of generating the alarm threshold value for the current day according to the history request data further includes:
s12, calculating an average value and a standard deviation by using historical HTTP request data in a preset time period according to a '3 Sigma rule' of normal distribution, and taking the average value +3 times of the standard deviation as a daily alarm threshold value of each operation and maintenance index.
In this embodiment, with Spark, we read the data in the past two weeks from the table of the HIVE data warehouse storing index history data as the input data of the model.
With 5 minutes as a statistical interval, for data (e.g., 10: 00-10: 05) within a certain 5 minutes of each service, the model has HTTP request average consumed time data of 14 × 5-70 minutes, and we consider that the data within the same time period of the same service are not greatly different, and at the level of 70 sample capacity, the model can be considered to be subject to normal distribution in statistics as a whole. For a set of data that follows a normal distribution, the "3 Sigma rule" for normal distribution applies.
Where μ is the mean of a set of normal distribution data, which is used to describe the average level of the set of data. σ (i.e., Sigma) is the standard deviation of a set of normally distributed data, which describes the degree of dispersion of the set of data. "3 Sigma Law" considers that for a set of sample data that follows a normal distribution, there is a probability that 99.74% of the samples will fall within the interval (μ -3 σ, μ +3 σ), and that the sample falls outside this range by only about three thousandths, which is considered a small probability event. In an alarm system, an abnormal situation is often considered to be an event with a small probability.
Therefore, referring to the '3 Sigma rule' of normal distribution, in the model calculation of the system, the average consumed time can be calculated by using the existing average consumed time of HTTP requests of 70 minutes, the average consumed time and the standard deviation are calculated, the standard deviation of +3 times of the average consumed time is used as the fluctuation upper limit of the operation and maintenance index, and once the average consumed time appearing subsequently exceeds the fluctuation upper limit, it is considered that the service is possibly abnormal, and an alarm message needs to be sent to notify developers.
The above situation is only applicable to the situation that the index data is stably represented, if the data in the previous period is stable at a lower level in the past two weeks, the data is at a higher level and the data fluctuation is large due to the update of the service version and other reasons in the later period. Because the mean value of the data needs to be brought into calculation in the early stage, the mean value level in the current threshold value can be reduced, and because the current index has larger fluctuation, the mean value level can often exceed the lower alarm threshold value, thereby causing frequent alarm. If the situation is reversed, the early stage is high, and the late stage is low, the alarm threshold value is high, and the alarm sensitivity of the current stage is greatly reduced.
Therefore, the model is adjusted by combining with the actual situation, and a discrete coefficient is introduced to judge whether the past historical data has great volatility. The formula for the dispersion coefficient is shown below:
cv＝σ/μ,
that is, the standard deviation is larger than the upper mean value, the dispersion coefficient is larger than 1, which indicates that the fluctuation of the data is larger, and the dispersion coefficient is smaller than 1, which indicates that the fluctuation of the data is smaller.
When the discrete coefficient of the data is found to be larger than 1 in modeling, the fact that the historical data has large fluctuation changes is shown, the data which is too long is not enough to be adopted, and mu + 3sigma is calculated by using the data which serves the last 3 days as the fluctuation upper limit, namely the alarm threshold.
S2, monitoring and calculating request data in real time to obtain real-time alarm data, judging whether the real-time alarm data exceeds the alarm threshold value of the current day, and if so, generating and recording an alarm record; corresponding to "analyze the current real-time network request agent log to obtain the current index actual value" to "record abnormal in the database alarm information table" in fig. 2;
the method comprises the steps that a spark streaming program is started (the program can run uninterruptedly), Nginx logs are analyzed and statistically calculated, the current actual value of the average consumed time of a real-time service HTTP request is obtained, the latest model result in MySQL is read into a spark streaming cache in advance, after the average consumed time per minute data in the current 5 minutes is calculated, the current consumed time per minute data is compared with a corresponding alarm threshold value in the cache, and if the current consumed time per minute data exceeds the threshold value, alarm information is recorded in an alarm recording table of MySQL.
S3, starting a timing scanning program, scanning the alarm records in the database, if a new alarm record is found, packaging alarm information, and submitting and reminding corresponding service personnel; corresponding to "read the latest data in the alarm information table" and "send alarm information to the developer" in fig. 2.
The system background can additionally start a Java program to scan an alarm record table in MySQL at regular time, and if newly appeared alarm records are found, the alarm information can be packaged and sent to corresponding service developers to remind the developers to pay attention.
Referring to fig. 3, the second embodiment of the present invention is:
an alarm terminal 1 capable of automatic detection comprises a memory 3, a processor 2 and a computer program stored on the memory 3 and capable of running on the processor 2, wherein the processor 2 implements a corresponding step of an embodiment when executing the computer program.
In summary, according to the alarm method and the terminal capable of automatic detection provided by the present invention, the historical request data in the preset period is calculated and counted, and a suitable fluctuation upper limit is calculated according to a certain algorithm to serve as the alarm threshold of the indicator. Therefore, the trouble of manually setting the threshold value is avoided, and the same index of different services can be ensured to have different alarm threshold values, so that differentiated service operation and maintenance are realized. In addition, the alarm threshold value can change along with the change of historical data, automatic updating every day is achieved, manual intervention and modification are not needed, and operation and maintenance cost is greatly saved. The volatility of historical data is determined by calculating the discrete coefficient, the time period data for calculating the alarm threshold is judged, the condition that the alarm threshold is lowered due to lower early-stage data and frequent alarms are caused is avoided, the alarm threshold is calculated by referring to the 3Sigma rule of normal distribution, and the calculated amount can be greatly reduced under the background of big data.
The above description is only an embodiment of the present invention, and not intended to limit the scope of the present invention, and all equivalent changes made by using the contents of the present specification and the drawings, or applied directly or indirectly to the related technical fields, are included in the scope of the present invention.
Claims (10)
1. An alarm method capable of automatic detection, which is characterized by comprising the following steps:
s1, acquiring all historical request data in a first preset time period, and generating a daily alarm threshold according to the historical request data;
and S2, monitoring and calculating the request data in real time to obtain real-time alarm data, judging whether the real-time alarm data exceeds the alarm threshold value of the current day, and if so, generating and recording an alarm record.
2. The alarm method capable of automatic detection according to claim 1, wherein the step S1 of generating the alarm threshold value for the current day according to the historical request data specifically includes:
s11, calculating a discrete coefficient of the historical record in a first preset time period, if the discrete coefficient is smaller than 1, generating a daily alarm threshold according to historical request data in the first preset time period, and if the discrete coefficient is larger than 1, generating the daily alarm threshold according to historical request data in a second preset time period, wherein the first preset time period is larger than the second preset time period.
3. The method according to claim 1, wherein the step S1 of generating the alarm threshold value for the current day according to the historical request data further comprises:
s12, calculating an average value and a standard deviation by using historical HTTP request data in a preset time period according to a '3 Sigma rule' of normal distribution, and taking the average value +3 times of the standard deviation as a daily alarm threshold value of each operation and maintenance index.
4. The warning method capable of automatic detection according to claim 1, wherein said step S1 is preceded by the steps of:
and S01, analyzing the network request agent log through a big data calculation tool at a preset fixed time every day, calculating and counting the request data of the previous day and storing the request data into a data warehouse, wherein the preset fixed time is earlier than the calculation time of the alarm threshold value of the current day.
5. The method of claim 1, further comprising the steps of:
and S3, starting a timing scanning program, scanning the alarm records in the database, and if a new alarm record is found, packaging the alarm information and submitting to remind corresponding service personnel.
6. An alarm terminal capable of automatic detection, comprising a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the processor executes the computer program to realize the following steps:
s1, acquiring all historical request data in a preset time period, and generating a daily alarm threshold according to the historical request data;
and S2, monitoring and calculating the request data in real time to obtain real-time alarm data, judging whether the real-time alarm data exceeds the alarm threshold value of the current day, and if so, generating and recording an alarm record.
7. The alarm terminal capable of automatic detection according to claim 6, wherein the step S1 of generating the alarm threshold value for the current day according to the historical request data specifically includes:
s11, calculating a discrete coefficient of the historical record in a first preset time period, if the discrete coefficient is smaller than 1, generating a daily alarm threshold according to historical request data in the first preset time period, and if the discrete coefficient is larger than 1, generating the daily alarm threshold according to historical request data in a second preset time period, wherein the first preset time period is larger than the second preset time period.
8. The alarm terminal capable of automatic detection according to claim 6, wherein the step S1 of generating the alarm threshold value for the current day according to the historical request data further comprises:
s12, calculating an average value and a standard deviation by using historical HTTP request data in a preset time period according to a '3 Sigma rule' of normal distribution, and taking the average value +3 times of the standard deviation as a daily alarm threshold value of each operation and maintenance index.
9. The alarm terminal capable of automatic detection according to claim 6, wherein said step S1 is preceded by the steps of:
and S01, analyzing the network request agent log through a big data calculation tool at a preset fixed time every day, calculating and counting the request data of the previous day and storing the request data into a data warehouse, wherein the preset fixed time is earlier than the calculation time of the alarm threshold value of the current day.
10. The alarm terminal capable of automatic detection according to claim 6, further comprising the steps of:
and S3, starting a timing scanning program, scanning the alarm records in the database, and if a new alarm record is found, packaging the alarm information and submitting to remind corresponding service personnel.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011059023.1A CN112260858A (en) | 2020-09-30 | 2020-09-30 | Alarm method capable of automatic detection and terminal |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011059023.1A CN112260858A (en) | 2020-09-30 | 2020-09-30 | Alarm method capable of automatic detection and terminal |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112260858A true CN112260858A (en) | 2021-01-22 |
Family
ID=74234416
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011059023.1A Pending CN112260858A (en) | 2020-09-30 | 2020-09-30 | Alarm method capable of automatic detection and terminal |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112260858A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113342623A (en) * | 2021-05-28 | 2021-09-03 | 福建福诺移动通信技术有限公司 | Visual early warning system and method based on dynamic threshold method |
| CN113380008A (en) * | 2021-05-12 | 2021-09-10 | 四川新网银行股份有限公司 | Dynamic threshold value adjusting method based on number of hits and hit rate |
| CN113608960A (en) * | 2021-07-09 | 2021-11-05 | 五八有限公司 | Service monitoring method and device, electronic equipment and storage medium |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105406991A (en) * | 2015-10-26 | 2016-03-16 | 上海华讯网络系统有限公司 | Method and system for generating service threshold by historical data based on network monitoring indexes |
| US20170097632A1 (en) * | 2015-10-05 | 2017-04-06 | Hongtao You | Method of cloud data services of industrial process automation systems |
| CN108377201A (en) * | 2018-02-09 | 2018-08-07 | 腾讯科技（深圳）有限公司 | Network Abnormal cognitive method, device, equipment and computer readable storage medium |
| CN108512691A (en) * | 2018-02-07 | 2018-09-07 | 复旦大学 | Cloud automatic early-warning O＆M monitoring system based on Hadoop |
| CN108509634A (en) * | 2018-04-10 | 2018-09-07 | 深信服科技股份有限公司 | Jitterbug monitoring method, monitoring device and computer readable storage medium |
| CN110086649A (en) * | 2019-03-19 | 2019-08-02 | 深圳壹账通智能科技有限公司 | Detection method, device, computer equipment and the storage medium of abnormal flow |
| CN110175108A (en) * | 2019-05-30 | 2019-08-27 | 深圳前海微众银行股份有限公司 | Performance test methods, device, equipment and computer readable storage medium |
| CN111506625A (en) * | 2020-04-20 | 2020-08-07 | 中国建设银行股份有限公司 | Alarm threshold determination method and device |
-
2020
- 2020-09-30 CN CN202011059023.1A patent/CN112260858A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170097632A1 (en) * | 2015-10-05 | 2017-04-06 | Hongtao You | Method of cloud data services of industrial process automation systems |
| CN105406991A (en) * | 2015-10-26 | 2016-03-16 | 上海华讯网络系统有限公司 | Method and system for generating service threshold by historical data based on network monitoring indexes |
| CN108512691A (en) * | 2018-02-07 | 2018-09-07 | 复旦大学 | Cloud automatic early-warning O＆M monitoring system based on Hadoop |
| CN108377201A (en) * | 2018-02-09 | 2018-08-07 | 腾讯科技（深圳）有限公司 | Network Abnormal cognitive method, device, equipment and computer readable storage medium |
| CN108509634A (en) * | 2018-04-10 | 2018-09-07 | 深信服科技股份有限公司 | Jitterbug monitoring method, monitoring device and computer readable storage medium |
| CN110086649A (en) * | 2019-03-19 | 2019-08-02 | 深圳壹账通智能科技有限公司 | Detection method, device, computer equipment and the storage medium of abnormal flow |
| CN110175108A (en) * | 2019-05-30 | 2019-08-27 | 深圳前海微众银行股份有限公司 | Performance test methods, device, equipment and computer readable storage medium |
| CN111506625A (en) * | 2020-04-20 | 2020-08-07 | 中国建设银行股份有限公司 | Alarm threshold determination method and device |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113380008A (en) * | 2021-05-12 | 2021-09-10 | 四川新网银行股份有限公司 | Dynamic threshold value adjusting method based on number of hits and hit rate |
| CN113380008B (en) * | 2021-05-12 | 2022-07-08 | 四川新网银行股份有限公司 | Dynamic threshold value adjusting method based on number of hits and hit rate |
| CN113342623A (en) * | 2021-05-28 | 2021-09-03 | 福建福诺移动通信技术有限公司 | Visual early warning system and method based on dynamic threshold method |
| CN113342623B (en) * | 2021-05-28 | 2022-05-17 | 福建福诺移动通信技术有限公司 | Visual early warning system and method based on dynamic threshold method |
| CN113608960A (en) * | 2021-07-09 | 2021-11-05 | 五八有限公司 | Service monitoring method and device, electronic equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112260858A (en) | Alarm method capable of automatic detection and terminal | |
| CN112035404B (en) | Medical data monitoring and early warning method, device, equipment and storage medium | |
| CN110377569B (en) | Log monitoring method, device, computer equipment and storage medium | |
| US10771306B2 (en) | Log monitoring system | |
| CN111539633A (en) | Service data quality auditing method, system, device and storage medium | |
| CN110535713B (en) | Monitoring management system and monitoring management method | |
| CN106940677A (en) | One kind application daily record data alarm method and device | |
| CN101252462B (en) | Alarming page furbishing method as well as server and client end | |
| CN104618948B (en) | The method and system of transmitting file in a kind of monitoring | |
| CN114154035A (en) | Data processing system for dynamic loop monitoring | |
| CN111984495A (en) | Big data monitoring method and device and storage medium | |
| CN107688626A (en) | Slow inquiry log processing method, device and electronic equipment | |
| WO2023109806A1 (en) | Method and apparatus for processing active data for internet of things device, and storage medium | |
| CN114090529A (en) | Log management method, device, system and storage medium | |
| CN114417200B (en) | Network data acquisition method and device and electronic equipment | |
| CN109522349B (en) | Cross-type data calculation and sharing method, system and equipment | |
| CN115277355A (en) | Method, device, equipment and medium for processing state code data of monitoring system | |
| CN115185710A (en) | Transaction interface time consumption counting and early warning method | |
| US11782873B2 (en) | System and method for managing timeseries data | |
| CN114493720A (en) | Method, device, storage medium and equipment for monitoring Kafka consumers | |
| CN113760669A (en) | Problem data warning method and device, electronic equipment and storage medium | |
| CN113472881A (en) | Statistical method and device for online terminal equipment | |
| CN113222223A (en) | Wind control linkage early warning method, system, equipment and storage medium for real-time warehouse | |
| CN111061609A (en) | Log monitoring method and system | |
| CN116132395B (en) | Message processing method, electronic device and computer readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20210122 |