CN111817896A - Interface monitoring method and device - Google Patents
Interface monitoring method and device Download PDFInfo
- Publication number
- CN111817896A CN111817896A CN202010685466.5A CN202010685466A CN111817896A CN 111817896 A CN111817896 A CN 111817896A CN 202010685466 A CN202010685466 A CN 202010685466A CN 111817896 A CN111817896 A CN 111817896A
- Authority
- CN
- China
- Prior art keywords
- traffic
- flow
- response
- baseline
- service node
- 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.)
- Granted
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/0681—Configuration of triggering conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Abstract
The invention provides an interface monitoring method and device, the method is: acquiring flow data corresponding to each service node at the current time; determining a preset flow baseline corresponding to the current time; determining whether the interface is abnormal or not by combining the flow baseline and the flow data corresponding to each service node; and if the interface is abnormal, sending alarm information for indicating that the interface is abnormal. According to the scheme, whether the interface is abnormal or not is determined by comparing the flow base line corresponding to the current time with the flow data of each service node acquired at the current time, the flow base lines corresponding to different time points are preset, the interface is monitored by utilizing the flow data and the flow base lines corresponding to the different time points in one day, and the accuracy and timeliness of monitoring the abnormity of the interface are improved.
Description
Technical Field
The invention relates to the technical field of data processing, in particular to an interface monitoring method and device.
Background
The interface is an important way for a user to access and visit the background application, and the stability and the usability of the interface can affect the service operation of the whole background application, so that the interface needs to be monitored.
Currently, the monitoring method for the interface is generally as follows: and monitoring data such as the flow rate, the response time and the like of the interface. However, because the difference of user access interfaces at different time points every day is large, an alarm threshold value cannot be accurately set, and only when data such as flow, response time and the like are greatly changed, the interface abnormality can be known from alarm, namely, the interface abnormality cannot be accurately and timely detected by the conventional interface monitoring mode.
Disclosure of Invention
In view of this, embodiments of the present invention provide an interface monitoring method and apparatus, so as to solve the problem that an existing interface monitoring method cannot accurately and timely detect an interface abnormality.
In order to achieve the above purpose, the embodiments of the present invention provide the following technical solutions:
the first aspect of the embodiments of the present invention discloses an interface monitoring method, including:
acquiring flow data corresponding to each service node at the current time;
determining a preset flow baseline corresponding to the current time, wherein the flow baseline is determined according to historical flow data corresponding to each service node;
determining whether an interface is abnormal or not by combining the flow baseline and the flow data corresponding to each service node;
and if the interface is abnormal, sending alarm information for indicating that the interface is abnormal.
Preferably, the historical traffic data includes historical request traffic and historical response traffic, and the process of determining the traffic baseline includes:
acquiring historical request flow and historical response flow corresponding to each service node every minute in the previous N weeks, wherein N is a positive integer;
determining a request traffic baseline corresponding to the L-th minute of the H-th hour on the Mth day in the week by using the historical request traffic of each service node corresponding to the L-th minute of the H-th hour on the Mth day in the previous N weeks, wherein M is an integer greater than or equal to 1 and less than or equal to 7, H is an integer greater than or equal to 1 and less than or equal to 24, and L is an integer greater than or equal to 1 and less than or equal to 60;
determining a response traffic baseline corresponding to the L minute of the H hour of the M day of the week according to the historical response traffic of each service node corresponding to the L minute of the H hour of the M day of the week in the previous N weeks;
determining a difference baseline of the request response traffic corresponding to the L minute of the H hour of the M day of the week through the difference between the historical request traffic and the historical response traffic of each service node corresponding to the L minute of the H hour of the M day of the week in the previous N weeks;
calculating the sum of the historical request traffic of each service node corresponding to the L minute of the H hour of the M th day of the week in the previous N weeks to obtain the total historical request traffic corresponding to the L minute of the H hour of the M th day of the week in the previous N weeks;
determining a total request flow baseline corresponding to the L minute of the H hour on the M day in one week by using the total historical request flow corresponding to each week in the previous N weeks;
calculating the sum of the historical response flow of each service node corresponding to the L minute of the H hour of the M th day of the week in the previous N weeks to obtain the total historical response flow corresponding to the L minute of the H hour of the M th day of the week in the previous N weeks;
determining a total response flow baseline corresponding to the L minute of the H hour on the M day in one week according to the total historical response flow corresponding to each week in the previous N weeks;
and determining a difference baseline of the total request response flow rate corresponding to the L minute at the H hour on the Mth day in the week by using the difference between the total historical request flow rate and the total historical response flow rate corresponding to each week in the previous N weeks.
Preferably, the determining whether an interface is abnormal or not by combining the traffic baseline and the traffic data corresponding to each service node includes:
calculating the sum of the request flows corresponding to each service node to obtain a total request flow, and calculating the sum of the response flows of each service node to obtain a total response flow;
for each service node, if the request flow of the service node is not within the range of the request flow baseline, determining that an interface is abnormal;
for each service node, if the response flow of the service node is not within the range of the response flow baseline, determining that the interface is abnormal;
for each service node, if the difference between the request flow and the response flow of the service node is not within the range of the difference baseline of the request response flow, determining that the interface is abnormal;
if the total request flow is not in the range of the total request flow baseline, determining that the interface is abnormal;
if the total response flow is not in the range of the total response flow baseline, determining that the interface is abnormal;
and if the difference between the total request flow and the total response flow is not within the range of the difference baseline of the total request response flow, determining that the interface is abnormal.
Preferably, the method further comprises:
and if the interface is not abnormal, adding the flow data corresponding to each service node to a data statistics sequence.
Preferably, after adding the traffic data corresponding to each of the service nodes to the data statistics sequence, the method further includes:
and updating the flow baseline by using the flow data in the data statistics sequence.
A second aspect of an embodiment of the present invention discloses an interface monitoring apparatus, including:
the acquisition component is used for acquiring flow data corresponding to each service node at the current time;
the centralized analysis component is used for determining a preset flow baseline corresponding to the current time, and the flow baseline is determined according to historical flow data corresponding to each service node;
and the alarm judgment component is used for determining whether the interface is abnormal or not by combining the flow baseline and the flow data corresponding to each service node, and sending alarm information for indicating that the interface is abnormal if the interface is abnormal.
Preferably, the historical traffic data includes historical request traffic and historical response traffic, and the centralized analysis component for determining the traffic baseline includes:
the acquisition module is used for acquiring historical request flow and historical response flow corresponding to each service node every minute in the previous N weeks, wherein N is a positive integer;
a first determining module, configured to determine a baseline of the requested traffic corresponding to the H-th hour and the L-th minute of the M-th day of the week by using the historical requested traffic of each service node corresponding to the H-th hour and the L-th minute of the M-th day of the previous N weeks, where M is an integer greater than or equal to 1 and less than or equal to 7, H is an integer greater than or equal to 1 and less than or equal to 24, and L is an integer greater than or equal to 1 and less than or equal to 60;
a second determining module, configured to determine, according to the historical response traffic of each service node corresponding to the lth minute at the H hour on the mth day of the week in the previous N weeks, a response traffic baseline corresponding to the lth minute at the H hour on the mth day of the week;
a third determining module, configured to determine a difference baseline between the request response traffic corresponding to the H-th hour and the L-th minute on the M-th day in the week according to a difference between the historical request traffic and the historical response traffic of each service node corresponding to the L-th minute on the H-th day in the previous N weeks;
the first calculation module is used for calculating the sum of the historical request flow of each service node corresponding to the H hour and the L minute of the M day of each week in the previous N weeks to obtain the total historical request flow corresponding to the H hour and the L minute of the M day of each week in the previous N weeks;
a fourth determining module, configured to determine a total requested traffic baseline corresponding to the lth minute in the H hour on the mth day in a week by using the total historical requested traffic corresponding to each week in the previous N weeks;
a second calculating module, configured to calculate a sum of the historical response traffic of each service node corresponding to the H-th hour and the L-th minute of the M-th day of the week in the previous N weeks, to obtain a total historical response traffic corresponding to the H-th hour and the L-th minute of the M-th day of the week in the previous N weeks;
a fifth determining module, configured to determine a total response traffic baseline corresponding to the lth minute at the H hour on the mth day in one week according to the total historical response traffic corresponding to each week in the previous N weeks;
a sixth determining module, configured to determine a difference baseline between total request response traffic corresponding to the lth minute on the H hour on the mth day of the week by using a difference between the total historical request traffic and the total historical response traffic corresponding to each week in the previous N weeks.
Preferably, the traffic data includes a request traffic and a response traffic, and the alarm determination module includes:
the calculation module is used for calculating the sum of the request flows corresponding to each service node to obtain a total request flow, and calculating the sum of the response flows of each service node to obtain a total response flow;
a first determining module, configured to determine, for each service node, that an interface is abnormal if a requested traffic of the service node is not within a range of the requested traffic baseline;
a second determining module, configured to determine, for each service node, that an interface is abnormal if a response traffic of the service node is not within a range of the response traffic baseline;
a third determining module, configured to determine, for each service node, that the interface is abnormal if a difference between a request traffic and a response traffic of the service node is not within a range of a difference baseline between the request and the response traffic;
a fourth determining module, configured to determine that the interface is abnormal if the total requested traffic is not within a range of the total requested traffic baseline;
a fifth determining module, configured to determine that the interface is abnormal if the total response traffic is not within the range of the total response traffic baseline;
a sixth determining module, configured to determine that the interface is abnormal if a difference between the total request traffic and the total response traffic is not within a range of a difference baseline of the total request response traffic.
Preferably, the apparatus further comprises:
and the adding component is used for adding the flow data corresponding to each service node to the data statistics sequence if the interface is not abnormal.
Preferably, the apparatus further comprises:
and the updating component is used for updating the flow baseline by utilizing the flow data in the data statistics sequence.
Based on the above method and apparatus for monitoring an interface provided by the embodiments of the present invention, the method includes: acquiring flow data corresponding to each service node at the current time; determining a preset flow baseline corresponding to the current time; determining whether the interface is abnormal or not by combining the flow baseline and the flow data corresponding to each service node; and if the interface is abnormal, sending alarm information for indicating that the interface is abnormal. According to the scheme, whether the interface is abnormal or not is determined by comparing the flow base line corresponding to the current time with the flow data of each service node acquired at the current time, the flow base lines corresponding to different time points are preset, the interface is monitored by utilizing the flow data and the flow base lines corresponding to the different time points in one day, and the accuracy and timeliness of monitoring the abnormity of the interface are improved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
Fig. 1 is a flowchart of an interface monitoring method according to an embodiment of the present invention;
FIG. 2 is a flow chart of determining a flow baseline provided by an embodiment of the present invention;
fig. 3 is another flowchart of an interface monitoring method according to an embodiment of the present invention;
fig. 4 is a block diagram of an interface monitoring apparatus according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In this application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
It can be known from the background art that the interface is monitored by monitoring the data of the flow rate, the response time and the like of the interface at present, but because the difference of the user access interface at different time points every day is large, the alarm threshold value cannot be accurately set, and the interface abnormality can be known from the alarm only when the data of the flow rate, the response time and the like are greatly changed, so that the interface abnormality cannot be accurately and timely detected.
Therefore, the embodiment of the invention provides an interface monitoring method and device, which preset flow baselines corresponding to different time points, and monitor an interface by using flow data and the flow baselines corresponding to different time points in one day so as to improve the accuracy and timeliness of monitoring the abnormality of the interface.
Referring to fig. 1, a flowchart of an interface monitoring method provided in an embodiment of the present invention is shown, where the interface monitoring method includes:
step S101: and acquiring flow data corresponding to each service node at the current time.
It should be noted that the interface corresponds to a service node cluster, the service node cluster includes a plurality of service nodes, and the traffic data of each service node is acquired by the acquisition probe, and it can be understood that one service node corresponds to one acquisition probe.
The traffic data includes request traffic (traffic that the interface receives the request) and response traffic (traffic that the interface responds to the request).
In the process of implementing step S101 specifically, traffic data corresponding to each service node at the current time (several hours and several minutes of the day of the week), for example, traffic data corresponding to each service node at 21 hours and 50 minutes of the wednesday of the current week, are acquired through the acquisition probe corresponding to each service node.
Step S102: and determining a preset flow baseline corresponding to the current time.
It should be noted that the traffic baseline is determined according to the historical traffic data corresponding to each service node collected in advance, for example, the historical request traffic and the historical response traffic corresponding to each service node every minute in the previous N weeks are collected in advance, that is, the historical traffic data includes the historical request traffic and the historical response traffic, and the traffic baseline is determined by using the historical request traffic and the historical response traffic corresponding to each service node every minute in the previous N weeks, where N is a positive integer.
It should be noted that, when acquiring the historical traffic data corresponding to each service node, the corresponding acquisition time (several hour minutes of the week) is recorded.
It is understood that, when setting the flow baselines, there are respective corresponding flow baselines at H hour and L minute on M day of the week, M is an integer of 1 or more and 7 or less, H is an integer of 1 or more and 24 or less, and L is an integer of 1 or more and 60 or less.
In the process of implementing step S102 specifically, a flow baseline corresponding to the same hour (the same hour on the same day of the week) on the same day (the same day of the week) at the current time (the same minute on the same hour on the same day of the week) is determined, such as: if the traffic data corresponding to each service node for 21 hours and 50 minutes of wednesday of the current week (current time) is collected, the traffic baseline corresponding to 21 hours and 50 minutes of wednesday is determined.
It should be noted that the flow baseline includes: a request traffic baseline (also called a single-service node request traffic baseline), a response traffic baseline (also called a single-service node response traffic baseline), a difference baseline of request response traffic (also called a difference baseline of single-service node request response traffic), a total request traffic baseline, a total response traffic baseline, and a difference baseline of total request response traffic.
It should be further noted that the above mentioned flow baseline is a data range, that is, the flow baseline includes corresponding flow ranges, such as: the requested traffic baseline includes corresponding requested traffic ranges (an upper requested traffic limit and a lower requested traffic limit), and the response traffic baseline includes corresponding response traffic ranges, and examples of the remaining traffic baselines are not necessarily illustrated.
Step S103: and determining whether the interface is abnormal or not by combining the flow baseline and the flow data corresponding to each service node. If the interface is abnormal, step S104 is executed, and if the interface is not abnormal, step S105 is executed.
In the process of implementing step S103 specifically, the sum of the request traffic corresponding to each service node (the sum of the request traffic at the current time) is calculated to obtain the total request traffic, and the sum of the response traffic of each service node (the sum of the response traffic at the current time) is calculated to obtain the total response traffic.
And comparing the request traffic of the service node with a request traffic baseline (the request traffic baseline corresponding to the current time) for each service node, and if the request traffic of the service node is not in the range of the request traffic baseline (the request traffic range), namely if the request traffic of the service node is not in the range from the upper limit of the request traffic to the lower limit of the request traffic, determining that the interface is abnormal.
And aiming at each service node, comparing the response flow of the service node with a response flow baseline, and if the response flow of the service node is not in the range of the response flow baseline, determining that the interface is abnormal.
And determining that the interface is abnormal if the difference between the request traffic and the response traffic of the service node is not within the range of the difference baseline of the request response traffic for each service node, such as the difference baseline between the request traffic and the response traffic of the service node and the difference baseline of the request response traffic.
And comparing the total request flow with the total request flow baseline, and determining that the interface is abnormal if the total request flow is not in the range of the total request flow baseline.
And comparing the total response flow with the total response flow baseline, and determining that the interface is abnormal if the total response flow is not in the range of the total response flow baseline.
And comparing the difference between the total request flow and the total response flow with the difference baseline of the total request response flow, and determining that the interface is abnormal if the difference between the total request flow and the total response flow is not within the range of the difference baseline of the total request response flow.
Step S104: and sending alarm information for indicating the interface is abnormal.
In the process of implementing step S104 specifically, when it is determined that the interface is abnormal, sending alarm information for indicating that the interface is abnormal, and prompting a technician, where the manner of sending the alarm information includes, but is not limited to: and sending a mail containing alarm information to a designated mailbox, sending a short message prompt containing the alarm information to a designated number, and displaying the alarm information on designated equipment in a popup window mode.
It is to be understood that the above-mentioned manner for sending the alarm information is only used for illustration, and the specific manner for sending the alarm information is not limited.
Step S105: and adding the flow data corresponding to each service node to the data statistics sequence.
In the process of specifically implementing step S105, if no abnormality occurs in the interface, that is, there is no abnormality in the traffic data (the traffic data acquired at the current time) corresponding to each service node, deleting the earliest historical traffic data (the historical traffic data used for determining the traffic baseline before) acquired before, and adding the traffic data acquired currently to the data statistics sequence.
Preferably, it can be understood that, in order to ensure that the determined traffic baseline is more in line with the actual situation, the traffic baseline needs to be updated, the traffic baseline is updated by using the traffic data in the data statistics sequence, for example, the traffic baseline (updated traffic baseline) needed in the next week (only by way of example) is determined by using the traffic data in the data statistics sequence, and the abnormal situation of the interface in the next week is monitored by using the updated traffic baseline in combination with the traffic data of each service node acquired in the next week.
In the embodiment of the invention, the flow baselines corresponding to different time points are preset, whether the interface is abnormal or not is determined by comparing the flow baselines corresponding to the current time with the flow data of each service node acquired at the current time, namely, the interface is monitored by using the flow data corresponding to the different time points and the flow baselines in one day, and the accuracy and timeliness of monitoring the interface abnormality are improved.
The above embodiment of the present invention relates to a process of determining a traffic baseline in step S102 in fig. 1, and referring to fig. 2, a flowchart for determining a traffic baseline provided in an embodiment of the present invention is shown, including the following steps:
step S201: and acquiring the historical request traffic and the historical response traffic corresponding to each service node every minute in the previous N weeks.
In the process of implementing step S201 specifically, for each service node, the historical request traffic and the historical response traffic corresponding to the service node every minute in the previous N weeks are obtained, where N is a positive integer.
It can be understood that, when obtaining the historical request traffic and the historical response traffic corresponding to the service node every minute in the previous N weeks, the time for obtaining the historical request traffic and the historical response traffic (i.e., the time for collecting the historical request traffic and the historical response traffic) is recorded, for example, the historical request traffic and the historical response traffic of the collection service node are recorded in the fraction of the week.
Step S202: and determining a request traffic baseline corresponding to the H hour and the L minute on the M day in the week by using the historical request traffic of each service node corresponding to the H hour and the L minute on the M day in the previous N weeks.
M is an integer of 1 to 7 inclusive, H is an integer of 1 to 24 inclusive, and L is an integer of 1 to 60 inclusive.
In the specific implementation process of step S203, a fluctuation range of the request traffic corresponding to the lth minute of the H hour of the mth day of the week is determined by using the historical request traffic of each service node corresponding to the lth minute of the H hour of the mth day of the week in the previous N weeks, so as to determine the request traffic baseline corresponding to the lth minute of the H hour of the mth day of the week.
Step S203: and determining a response traffic baseline corresponding to the H hour and the L minute on the M day in the week according to the historical response traffic of each service node corresponding to the H hour and the L minute on the M day in the previous N weeks.
In the specific implementation process of step S203, a fluctuation range of response traffic corresponding to the lth minute of the H hour of the mth day of the week is determined by using the historical response traffic of each service node corresponding to the lth minute of the H hour of the mth day of the week in the previous N weeks, so as to determine a response traffic baseline corresponding to the lth minute of the H hour of the mth day of the week.
Step S204: and determining a difference baseline of the request response traffic corresponding to the L minute at the H hour at the M day in the week according to the difference between the historical request traffic and the historical response traffic of each service node corresponding to the L minute at the H hour at the M day in the previous N weeks.
In the specific implementation of step S204, a fluctuation range of a difference between the request-response traffic of each service node corresponding to the lth minute of the H hour of the mth day of the week is determined according to a difference between the historical request traffic and the historical response traffic of each service node corresponding to the lth minute of the H hour of the mth day of the previous N weeks, so as to determine a difference baseline of the request-response traffic corresponding to the lth minute of the H hour of the mth day of the week.
Step S205: and calculating the sum of the historical request flow of each service node corresponding to the L minute of the H hour on the M th day of the week in the previous N weeks to obtain the total historical request flow corresponding to the L minute of the H hour on the M th day of the week in the previous N weeks.
In the specific implementation process of step S205, the sum of the historical request traffic of each service node corresponding to the lth minute of the H hour of the mth day of each week in the previous N weeks is calculated, that is, the sum of the historical request traffic of all service nodes in the same minute of the same hour of the same day of the previous N weeks is determined, so as to obtain the total historical request traffic corresponding to the lth minute of the H hour of the mth day of each week in the previous N weeks.
Step S206: and determining a total request flow baseline corresponding to the L minute of the H hour on the M day in the week by using the total historical request flow corresponding to each week in the previous N weeks.
In the specific implementation of step S206, a fluctuation range of the total requested traffic corresponding to the H hour and L minute on the M th day in the week is determined by using the total historical requested traffic corresponding to each week in the previous N weeks (the total historical requested traffic corresponding to the H hour and L minute on the M th day in the week), so as to determine the total requested traffic baseline corresponding to the H hour and L minute on the M th day in the week.
Step S207: and calculating the sum of the historical response flow of each service node corresponding to the L minute of the H hour on the M th day of the week in the previous N weeks to obtain the total historical response flow corresponding to the L minute of the H hour on the M th day of the week in the previous N weeks.
In the specific implementation process of step S207, the sum of the historical response traffic of each service node corresponding to the lth minute of the H hour of the mth day of the week in the previous N weeks is calculated, that is, the sum of the historical response traffic of all service nodes in the same minute of the same hour of the same day of the week in the previous N weeks is determined, so as to obtain the total historical response traffic corresponding to the lth minute of the H hour of the mth day of the week in the previous N weeks.
Step S208: and determining a total response flow baseline corresponding to the L minute of the H hour on the M day in one week according to the total historical response flow corresponding to each week in the previous N weeks.
In the specific implementation process of step S208, a fluctuation range of the total response flow rate corresponding to the H-th hour and the L-th minute on the M-th day in the week is determined according to the total historical response flow rate corresponding to each week in the previous N weeks (the total historical response flow rate corresponding to the H-th hour and the L-th minute on the M-th day in the week), so as to determine the total response flow rate baseline corresponding to the H-th hour and the L-th minute on the M-th day in the week.
Step S209: and determining a difference baseline of the total request response flow rate corresponding to the L minute at the H hour on the M day in the week by using the difference between the total historical request flow rate and the total historical response flow rate corresponding to each week in the previous N weeks.
In the specific implementation of step S209, a fluctuation range of a difference between total request response flow rates for the H-th hour and the L-th minute on the M-th day in the week is determined by using a difference between a total historical request flow rate (a total historical request flow rate for the H-th hour and the L-th minute on the M-th day in the week) and a total historical response flow rate (a total historical response flow rate for the H-th hour and the L-th minute on the M-th day in the week) corresponding to each week in the previous N weeks, so as to determine a difference baseline of the total request response flow rates for the H-th hour and the L-th minute on the M-th day in the week.
To better explain the contents of the above embodiments of the present invention, fig. 1 and fig. 2 show the contents of comparing the traffic data corresponding to the current time with the traffic baseline, which are exemplified by the processes a1 to A3 and by the processes B1 to B3, it should be noted that the processes a1 to A3 are contents of comparing the total requested traffic corresponding to the current time with the total requested traffic baseline, and the processes B1 to B3 are contents of comparing the difference between the total requested traffic and the total response traffic corresponding to the current time with the total requested response traffic baseline.
And A1, collecting and adding the request traffic of each service node at the current time (denoted by t below) to obtain the total request traffic (denoted by D below) corresponding to the current time t. And acquiring the total historical request flow of the time corresponding to the current time t in each week in the previous N weeks of { t-W, -2W, t-3W, …, t-NW }, wherein the total historical request flow of the time corresponding to the current time t in each week in the previous N weeks is marked as { D1, D2, D3, …, DN }, wherein t-NW represents the time corresponding to the nth week and t in the previous N weeks, and DN represents the total historical request flow of the time corresponding to the nth week and t in the previous N weeks.
A2, determining a total request traffic baseline corresponding to the current time t by using { D1, D2, D3, …, DN }, wherein the specific contents are as follows:
averaging { D1, D2, D3, …, DN }, i.e.
The { D1, D2, D3, …, DN } are sorted in descending order, the 0.8N data after sorting is taken as Dx, the 0.2N data after sorting is taken as Dy, and it is required to be noted that the integers are rounded up when the 0.8N and the 0.2N are not integers.
The upper limit Dmax and the lower limit Dmin of the total requested traffic baseline corresponding to the current time t are respectively
And
a3, comparing the total request flow at the current time t with the corresponding total request flow, if Dmin is less than or equal to D and less than or equal to Dmax, the total request flow at the current time t is normal data, and the interface is not abnormal. If D is less than Dmin or D is greater than Dmax, the total request flow of the current time t is abnormal data, and the interface is abnormal.
B1, collecting and summing the request traffic of each service node at the current time (hereinafter denoted by t), obtaining the total request traffic (hereinafter denoted by Dreq) corresponding to the current time t, collecting and summing the response traffic of each service node at the current time t, obtaining the total response traffic (hereinafter denoted by Dres) corresponding to the current time t, and calculating the difference (hereinafter denoted by S) between the total request traffic and the total response traffic corresponding to the current time t.
Acquiring the difference between the total historical request flow and the total historical response flow of the time corresponding to the current time t in each week of the previous N weeks { t-W, -2W, t-3W, …, t-NW }, wherein the difference between the total historical request flow and the total historical response flow of the time corresponding to the current time t in each week of the previous N weeks is represented as { S1, S2, …, SN }, wherein t-NW represents the time corresponding to the nth week of the previous N weeks and t, and SN represents the difference between the total historical request flow and the total historical response flow of the time corresponding to the nth week and t of the previous N weeks.
B2, determining a difference baseline of the total request response flow corresponding to the current time t by using { S1, S2, …, SN }, wherein the specific contents are as follows:
averaging { S1, S2, …, SN }, i.e.
Sorting { S1, S2, …, SN } according to the sequence from small to large, taking the 0.8N data after sorting as Sx, taking the 0.2N data after sorting as Sy, and rounding up when 0.8N and 0.2N are not integers.
The upper limit Smax and the lower limit Smin of the difference baseline between the total request response traffic corresponding to the current time t are respectively
And
b3, comparing the difference between the total request flow and the total response flow at the current time t with the difference baseline between the total request response flow, if Smin is less than or equal to S and less than or equal to Smax, indicating that the difference between the total request flow and the total response flow at the current time t is normal data, and the interface has no abnormality. If S is less than Smin or S is more than Smax, the difference between the total request flow and the total response flow of the current time t is represented as abnormal data, and the interface is abnormal.
In the embodiment of the invention, the flow baseline corresponding to the L minute of the H hour on the M day of the week is determined in advance according to the historical flow data of every minute of the previous N weeks. Whether the interface is abnormal is determined by comparing the flow base line corresponding to the current time with the flow data of each service node acquired at the current time, namely, the interface is monitored by using the flow data and the flow base lines corresponding to different time points in one day, so that the accuracy and the timeliness of monitoring the abnormity of the interface are improved.
To better explain the contents shown in fig. 1 and fig. 2 of the above embodiments of the present invention, another flowchart of an interface monitoring method shown in fig. 3 is used for illustration, and it should be noted that fig. 3 is used for illustration only and includes the following steps.
It should be noted that the interface monitoring method according to the embodiment of the present invention is applied to an interface monitoring apparatus, where the interface monitoring apparatus includes: the device comprises a collecting assembly, a centralized analysis assembly and an alarm judging assembly.
Step S301: the collection component collects historical traffic data of each service node every minute for the previous N weeks, records collection time (obtained by the time sequence in fig. 3), and the centralized analysis component stores the historical request traffic and the historical response traffic of each service node into a database (stored in a warehouse by classified traffic in fig. 3).
Step S302: and the centralized analysis component performs sum calculation on the historical request traffic and the historical response traffic of all the service nodes every minute in the previous N weeks, and stores the calculation result (total traffic per unit time) into a database.
Step S303: the centralized analysis component calculates a flow baseline using the data in the database.
Step S304: the collection component collects the flow data of each service node at the current time, and the centralized analysis component carries out flow sum calculation on the flow data of each service node obtained by current collection.
Step S305: and the alarm judgment component is used for judging abnormal traffic by combining the traffic node of each service node and the sum calculation result.
Step S306: if the alarm judging component determines that the flow is not abnormal, the centralized analysis component deletes the historical flow data acquired earliest, adds the flow data acquired at present to the data statistical sequence, and predicts the future flow baseline. And if the alarm judgment component determines that the flow is abnormal, the alarm judgment component carries out abnormal alarm.
It should be noted that, the content of each step in fig. 1 and fig. 2 in the above embodiment of the present invention can be referred to for the execution principle of step S301 to step S306, and is not described again here.
Corresponding to the interface monitoring method provided in the embodiment of the present invention, referring to fig. 4, an embodiment of the present invention further provides a structural block diagram of an interface monitoring apparatus, where the interface monitoring apparatus includes: a collection component 401, a centralized analysis component 402 and an alarm judgment component 403;
the acquisition component 401 is configured to acquire traffic data corresponding to each service node at the current time.
And a centralized analysis component 402, configured to determine a preset traffic baseline corresponding to the current time, where the traffic baseline is determined according to historical traffic data corresponding to each service node.
And an alarm determining component 403, configured to determine whether an interface is abnormal by combining the traffic baseline and traffic data corresponding to each service node, and send alarm information indicating that the interface is abnormal if the interface is abnormal.
In the embodiment of the invention, the flow baselines corresponding to different time points are preset, whether the interface is abnormal or not is determined by comparing the flow baselines corresponding to the current time with the flow data of each service node acquired at the current time, namely, the interface is monitored by using the flow data corresponding to the different time points and the flow baselines in one day, and the accuracy and timeliness of monitoring the interface abnormality are improved.
Preferably, as shown in connection with fig. 4, the historical traffic data includes historical request traffic and historical response traffic, and the centralized analysis component 402 for determining the traffic baseline includes: the device comprises an acquisition module, a first determination module, a second determination module, a third determination module, a first calculation module, a fourth determination module, a second calculation module, a fifth determination module and a sixth determination module, wherein the execution principle of each module is as follows:
the acquisition module is used for acquiring historical request flow and historical response flow corresponding to each service node every minute in the previous N weeks, wherein N is a positive integer.
The first determining module is used for determining a request traffic baseline corresponding to the L-th minute of the H-th hour on the M-th day of the week by using the historical request traffic of each service node corresponding to the L-th minute of the H-th hour on the M-th day of the previous N weeks, wherein M is an integer greater than or equal to 1 and less than or equal to 7, H is an integer greater than or equal to 1 and less than or equal to 24, and L is an integer greater than or equal to 1 and less than or equal to 60.
And the second determining module is used for determining a response flow baseline corresponding to the L-th minute of the H-th hour of the M-th day of the week according to the historical response flow of each service node corresponding to the L-th minute of the H-th hour of the M-th day of the previous N weeks.
And the third determining module is used for determining a difference baseline of the request response flow rate corresponding to the L-th minute of the H-th hour of the M-th day of the week through the difference between the historical request flow rate and the historical response flow rate of each service node corresponding to the L-th minute of the H-th hour of the M-th day of the previous N weeks.
The first calculation module is used for calculating the sum of the historical request flow of each service node corresponding to the H-th hour and the L-th minute of the M-th day of each week in the previous N weeks to obtain the total historical request flow corresponding to the H-th hour and the L-th minute of the M-th day of each week in the previous N weeks.
And the fourth determining module is used for determining a total request flow baseline corresponding to the L minute of the H hour on the Mth day in the week by using the total historical request flow corresponding to each week in the previous N weeks.
And the second calculation module is used for calculating the sum of the historical response flow of each service node corresponding to the L-th minute of the H-th hour of the M-th day of the week in the previous N weeks to obtain the total historical response flow corresponding to the L-th minute of the H-th hour of the M-th day of the week in the previous N weeks.
And the fifth determining module is used for determining a total response flow baseline corresponding to the L minute of the H hour on the Mth day in one week according to the total historical response flow corresponding to each week in the previous N weeks.
And the sixth determining module is used for determining a difference baseline of the total request response flow rate corresponding to the L minute of the H hour on the Mth day of the week by using the difference between the total historical request flow rate and the total historical response flow rate corresponding to each week in the previous N weeks.
In the embodiment of the invention, the flow baseline corresponding to the L minute of the H hour on the M day of the week is determined in advance according to the historical flow data of every minute of the previous N weeks. Whether the interface is abnormal is determined by comparing the flow base line corresponding to the current time with the flow data of each service node acquired at the current time, namely, the interface is monitored by using the flow data and the flow base lines corresponding to different time points in one day, so that the accuracy and the timeliness of monitoring the abnormity of the interface are improved.
Preferably, in conjunction with the content shown in fig. 4, the traffic data includes request traffic and response traffic, and the alarm determination component 403 includes: the device comprises a calculation module, a first determination module, a second determination module, a third determination module, a fourth determination module, a fifth determination module and a sixth determination module, wherein the execution principle of each module is as follows:
the calculation module is used for calculating the sum of the request flows corresponding to each service node to obtain a total request flow, and calculating the sum of the response flows of each service node to obtain a total response flow;
the first determining module is used for determining that the interface is abnormal if the request flow of the service node is not within the range of the request flow baseline for each service node.
And the second determining module is used for determining that the interface is abnormal if the response flow of the service node is not in the range of the response flow baseline for each service node.
And the third determining module is used for determining that the interface is abnormal if the difference between the request flow and the response flow of the service node is not within the range of the difference baseline of the request response flow for each service node.
And the fourth determining module is used for determining that the interface is abnormal if the total request flow is not in the range of the total request flow baseline.
And the fifth determining module is used for determining that the interface is abnormal if the total response flow is not in the range of the total response flow baseline.
And the sixth determining module is used for determining that the interface is abnormal if the difference between the total request flow and the total response flow is not within the range of the difference baseline of the total request response flow.
Preferably, in combination with the content shown in fig. 4, the interface monitoring apparatus further includes:
and the adding component is used for adding the flow data corresponding to each service node to the data statistical sequence if the interface is not abnormal.
Preferably, in combination with the content shown in fig. 4, the interface monitoring apparatus further includes:
and the updating component is used for updating the flow baseline by utilizing the flow data in the data statistics sequence.
In summary, embodiments of the present invention provide an interface monitoring method and apparatus, where flow baselines corresponding to different time points are preset, and the interface is monitored by using the flow data and the flow baselines corresponding to different time points in a day, so as to improve accuracy and timeliness of monitoring an interface abnormality.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the system or system embodiments are substantially similar to the method embodiments and therefore are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for related points. The above-described system and system embodiments are only illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. An interface monitoring method, the method comprising:
acquiring flow data corresponding to each service node at the current time;
determining a preset flow baseline corresponding to the current time, wherein the flow baseline is determined according to historical flow data corresponding to each service node;
determining whether an interface is abnormal or not by combining the flow baseline and the flow data corresponding to each service node;
and if the interface is abnormal, sending alarm information for indicating that the interface is abnormal.
2. The method of claim 1, wherein the historical traffic data includes historical request traffic and historical response traffic, and wherein determining the traffic baseline comprises:
acquiring historical request flow and historical response flow corresponding to each service node every minute in the previous N weeks, wherein N is a positive integer;
determining a request traffic baseline corresponding to the L-th minute of the H-th hour on the Mth day in the week by using the historical request traffic of each service node corresponding to the L-th minute of the H-th hour on the Mth day in the previous N weeks, wherein M is an integer greater than or equal to 1 and less than or equal to 7, H is an integer greater than or equal to 1 and less than or equal to 24, and L is an integer greater than or equal to 1 and less than or equal to 60;
determining a response traffic baseline corresponding to the L minute of the H hour of the M day of the week according to the historical response traffic of each service node corresponding to the L minute of the H hour of the M day of the week in the previous N weeks;
determining a difference baseline of the request response traffic corresponding to the L minute of the H hour of the M day of the week through the difference between the historical request traffic and the historical response traffic of each service node corresponding to the L minute of the H hour of the M day of the week in the previous N weeks;
calculating the sum of the historical request traffic of each service node corresponding to the L minute of the H hour of the M th day of the week in the previous N weeks to obtain the total historical request traffic corresponding to the L minute of the H hour of the M th day of the week in the previous N weeks;
determining a total request flow baseline corresponding to the L minute of the H hour on the M day in one week by using the total historical request flow corresponding to each week in the previous N weeks;
calculating the sum of the historical response flow of each service node corresponding to the L minute of the H hour of the M th day of the week in the previous N weeks to obtain the total historical response flow corresponding to the L minute of the H hour of the M th day of the week in the previous N weeks;
determining a total response flow baseline corresponding to the L minute of the H hour on the M day in one week according to the total historical response flow corresponding to each week in the previous N weeks;
and determining a difference baseline of the total request response flow rate corresponding to the L minute at the H hour on the Mth day in the week by using the difference between the total historical request flow rate and the total historical response flow rate corresponding to each week in the previous N weeks.
3. The method of claim 2, wherein the traffic data includes request traffic and response traffic, and the determining whether the interface is abnormal or not by combining the traffic baseline and the traffic data corresponding to each of the service nodes comprises:
calculating the sum of the request flows corresponding to each service node to obtain a total request flow, and calculating the sum of the response flows of each service node to obtain a total response flow;
for each service node, if the request flow of the service node is not within the range of the request flow baseline, determining that an interface is abnormal;
for each service node, if the response flow of the service node is not within the range of the response flow baseline, determining that the interface is abnormal;
for each service node, if the difference between the request flow and the response flow of the service node is not within the range of the difference baseline of the request response flow, determining that the interface is abnormal;
if the total request flow is not in the range of the total request flow baseline, determining that the interface is abnormal;
if the total response flow is not in the range of the total response flow baseline, determining that the interface is abnormal;
and if the difference between the total request flow and the total response flow is not within the range of the difference baseline of the total request response flow, determining that the interface is abnormal.
4. The method of claim 1, further comprising:
and if the interface is not abnormal, adding the flow data corresponding to each service node to a data statistics sequence.
5. The method of claim 4, wherein adding the traffic data corresponding to each of the serving nodes to the data statistics sequence further comprises:
and updating the flow baseline by using the flow data in the data statistics sequence.
6. An interface monitoring apparatus, the apparatus comprising:
the acquisition component is used for acquiring flow data corresponding to each service node at the current time;
the centralized analysis component is used for determining a preset flow baseline corresponding to the current time, and the flow baseline is determined according to historical flow data corresponding to each service node;
and the alarm judgment component is used for determining whether the interface is abnormal or not by combining the flow baseline and the flow data corresponding to each service node, and sending alarm information for indicating that the interface is abnormal if the interface is abnormal.
7. The apparatus of claim 6, wherein the historical traffic data comprises historical request traffic and historical response traffic, and wherein the centralized analysis component for determining the traffic baseline comprises:
the acquisition module is used for acquiring historical request flow and historical response flow corresponding to each service node every minute in the previous N weeks, wherein N is a positive integer;
a first determining module, configured to determine a baseline of the requested traffic corresponding to the H-th hour and the L-th minute of the M-th day of the week by using the historical requested traffic of each service node corresponding to the H-th hour and the L-th minute of the M-th day of the previous N weeks, where M is an integer greater than or equal to 1 and less than or equal to 7, H is an integer greater than or equal to 1 and less than or equal to 24, and L is an integer greater than or equal to 1 and less than or equal to 60;
a second determining module, configured to determine, according to the historical response traffic of each service node corresponding to the lth minute at the H hour on the mth day of the week in the previous N weeks, a response traffic baseline corresponding to the lth minute at the H hour on the mth day of the week;
a third determining module, configured to determine a difference baseline between the request response traffic corresponding to the H-th hour and the L-th minute on the M-th day in the week according to a difference between the historical request traffic and the historical response traffic of each service node corresponding to the L-th minute on the H-th day in the previous N weeks;
the first calculation module is used for calculating the sum of the historical request flow of each service node corresponding to the H hour and the L minute of the M day of each week in the previous N weeks to obtain the total historical request flow corresponding to the H hour and the L minute of the M day of each week in the previous N weeks;
a fourth determining module, configured to determine a total requested traffic baseline corresponding to the lth minute in the H hour on the mth day in a week by using the total historical requested traffic corresponding to each week in the previous N weeks;
a second calculating module, configured to calculate a sum of the historical response traffic of each service node corresponding to the H-th hour and the L-th minute of the M-th day of the week in the previous N weeks, to obtain a total historical response traffic corresponding to the H-th hour and the L-th minute of the M-th day of the week in the previous N weeks;
a fifth determining module, configured to determine a total response traffic baseline corresponding to the lth minute at the H hour on the mth day in one week according to the total historical response traffic corresponding to each week in the previous N weeks;
a sixth determining module, configured to determine a difference baseline between total request response traffic corresponding to the lth minute on the H hour on the mth day of the week by using a difference between the total historical request traffic and the total historical response traffic corresponding to each week in the previous N weeks.
8. The apparatus of claim 7, wherein the traffic data comprises request traffic and response traffic, and wherein the alarm determination component comprises:
the calculation module is used for calculating the sum of the request flows corresponding to each service node to obtain a total request flow, and calculating the sum of the response flows of each service node to obtain a total response flow;
a first determining module, configured to determine, for each service node, that an interface is abnormal if a requested traffic of the service node is not within a range of the requested traffic baseline;
a second determining module, configured to determine, for each service node, that an interface is abnormal if a response traffic of the service node is not within a range of the response traffic baseline;
a third determining module, configured to determine, for each service node, that the interface is abnormal if a difference between a request traffic and a response traffic of the service node is not within a range of a difference baseline between the request and the response traffic;
a fourth determining module, configured to determine that the interface is abnormal if the total requested traffic is not within a range of the total requested traffic baseline;
a fifth determining module, configured to determine that the interface is abnormal if the total response traffic is not within the range of the total response traffic baseline;
a sixth determining module, configured to determine that the interface is abnormal if a difference between the total request traffic and the total response traffic is not within a range of a difference baseline of the total request response traffic.
9. The apparatus of claim 6, further comprising:
and the adding component is used for adding the flow data corresponding to each service node to the data statistics sequence if the interface is not abnormal.
10. The apparatus of claim 9, further comprising:
and the updating component is used for updating the flow baseline by utilizing the flow data in the data statistics sequence.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010685466.5A CN111817896B (en) | 2020-07-16 | 2020-07-16 | Interface monitoring method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010685466.5A CN111817896B (en) | 2020-07-16 | 2020-07-16 | Interface monitoring method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111817896A true CN111817896A (en) | 2020-10-23 |
| CN111817896B CN111817896B (en) | 2023-04-18 |
Family
ID=72865504
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010685466.5A Active CN111817896B (en) | 2020-07-16 | 2020-07-16 | Interface monitoring method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111817896B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115348151A (en) * | 2022-08-12 | 2022-11-15 | 中国工商银行股份有限公司 | Port flow false alarm method, device, equipment, medium and program product |
| CN116886517A (en) * | 2023-09-04 | 2023-10-13 | 江苏点石乐投科技有限公司 | Alarm system and method based on flow data |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150229661A1 (en) * | 2011-11-07 | 2015-08-13 | Netflow Logic Corporation | Method and system for confident anomaly detection in computer network traffic |
| CN105281966A (en) * | 2014-06-13 | 2016-01-27 | 腾讯科技（深圳）有限公司 | Method and device for identifying abnormal traffic of network equipment |
| CN107276808A (en) * | 2017-06-21 | 2017-10-20 | 北京华创网安科技股份有限公司 | A kind of optimization method of Traffic Anomaly monitoring |
| CN107819633A (en) * | 2017-11-30 | 2018-03-20 | 国网河南省电力公司商丘供电公司 | It is a kind of quickly to find and handle the system and its processing method of network failure |
| WO2018095513A1 (en) * | 2016-11-22 | 2018-05-31 | Huawei Technologies Co., Ltd. | Bandwidth calendaring in sdn |
| CN108632863A (en) * | 2018-04-28 | 2018-10-09 | 中国联合网络通信集团有限公司 | Flow method for early warning, device and server |
| CN109039821A (en) * | 2018-08-21 | 2018-12-18 | 平安科技（深圳）有限公司 | Network flow monitoring method, device, computer equipment and storage medium |
| CN109194539A (en) * | 2018-08-13 | 2019-01-11 | 中国平安人寿保险股份有限公司 | Data management-control method, device, computer equipment and storage medium |
| CN111064635A (en) * | 2019-12-10 | 2020-04-24 | 中盈优创资讯科技有限公司 | Abnormal traffic monitoring method and system |
-
2020
- 2020-07-16 CN CN202010685466.5A patent/CN111817896B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150229661A1 (en) * | 2011-11-07 | 2015-08-13 | Netflow Logic Corporation | Method and system for confident anomaly detection in computer network traffic |
| CN105281966A (en) * | 2014-06-13 | 2016-01-27 | 腾讯科技（深圳）有限公司 | Method and device for identifying abnormal traffic of network equipment |
| WO2018095513A1 (en) * | 2016-11-22 | 2018-05-31 | Huawei Technologies Co., Ltd. | Bandwidth calendaring in sdn |
| CN107276808A (en) * | 2017-06-21 | 2017-10-20 | 北京华创网安科技股份有限公司 | A kind of optimization method of Traffic Anomaly monitoring |
| CN107819633A (en) * | 2017-11-30 | 2018-03-20 | 国网河南省电力公司商丘供电公司 | It is a kind of quickly to find and handle the system and its processing method of network failure |
| CN108632863A (en) * | 2018-04-28 | 2018-10-09 | 中国联合网络通信集团有限公司 | Flow method for early warning, device and server |
| CN109194539A (en) * | 2018-08-13 | 2019-01-11 | 中国平安人寿保险股份有限公司 | Data management-control method, device, computer equipment and storage medium |
| CN109039821A (en) * | 2018-08-21 | 2018-12-18 | 平安科技（深圳）有限公司 | Network flow monitoring method, device, computer equipment and storage medium |
| CN111064635A (en) * | 2019-12-10 | 2020-04-24 | 中盈优创资讯科技有限公司 | Abnormal traffic monitoring method and system |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115348151A (en) * | 2022-08-12 | 2022-11-15 | 中国工商银行股份有限公司 | Port flow false alarm method, device, equipment, medium and program product |
| CN116886517A (en) * | 2023-09-04 | 2023-10-13 | 江苏点石乐投科技有限公司 | Alarm system and method based on flow data |
| CN116886517B (en) * | 2023-09-04 | 2023-11-24 | 江苏点石乐投科技有限公司 | Alarm system and method based on flow data |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111817896B (en) | 2023-04-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9384079B2 (en) | System operations management apparatus, system operations management method and program storage medium | |
| CN107871190B (en) | Service index monitoring method and device | |
| US8352867B2 (en) | Predictive monitoring dashboard | |
| EP3249483B1 (en) | Information processing device and information processing method | |
| CN111817896B (en) | Interface monitoring method and device | |
| CN108718303B (en) | Safe operation and maintenance management method and system | |
| EP2613263B1 (en) | Operations management device, operations management method, and program | |
| KR100689844B1 (en) | Realtime detection and analysis method and systems of infiltration/inflow and leakage in the sewer | |
| CN111698306A (en) | Hydrological real-time flow data acquisition and processing method based on Internet of things | |
| CN114283590B (en) | Traffic flow peak prediction method and device and electronic equipment | |
| WO2011062189A1 (en) | Event sensor device and event sensing method | |
| CN110635947A (en) | Abnormal access monitoring method and device | |
| US7769651B2 (en) | Method and system of processing billing data | |
| JP6625839B2 (en) | Load actual data determination device, load prediction device, actual load data determination method, and load prediction method | |
| KR102102112B1 (en) | Inventory management method of drug distribution corporation | |
| CN101605339A (en) | Monitoring of network bandwidth resources operating position and prompt system and method | |
| CN113342608A (en) | Method and device for monitoring streaming computing engine task | |
| KR20210016980A (en) | Server and method for estimating used amount of missed data in advanced metering infrastructure system | |
| CN113782173B (en) | Intelligent parameter information acquisition system for predicting state of clinical emergency equipment | |
| US20230069206A1 (en) | Recovery judgment apparatus, recovery judgment method and program | |
| CN108093423A (en) | A kind of discovery method of base station location exception in user bill big data based on Ransac algorithms | |
| EP3982453A1 (en) | Component replacement method and component replacement system | |
| CN108307428B (en) | LTE cell concentration analysis method and system based on MR data | |
| CN115220946A (en) | Abnormal data detection method, device, equipment and storage medium | |
| EP3928258A1 (en) | Improved computer-implemented event forecasting and information provision |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |