CN111585833B - Method and device for detecting public network quality of CDN node and computer equipment - Google Patents

Method and device for detecting public network quality of CDN node and computer equipment Download PDF

Info

Publication number
CN111585833B
CN111585833B CN202010273192.9A CN202010273192A CN111585833B CN 111585833 B CN111585833 B CN 111585833B CN 202010273192 A CN202010273192 A CN 202010273192A CN 111585833 B CN111585833 B CN 111585833B
Authority
CN
China
Prior art keywords
detection
fault event
fault
event
cdn
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.)
Active
Application number
CN202010273192.9A
Other languages
Chinese (zh)
Other versions
CN111585833A (en
Inventor
赵东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sina Technology China Co Ltd
Original Assignee
Sina Technology China Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sina Technology China Co Ltd filed Critical Sina Technology China Co Ltd
Priority to CN202010273192.9A priority Critical patent/CN111585833B/en
Publication of CN111585833A publication Critical patent/CN111585833A/en
Application granted granted Critical
Publication of CN111585833B publication Critical patent/CN111585833B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14Network analysis or design
    • H04L41/145Network analysis or design involving simulating, designing, planning or modelling of a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0829Packet loss
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks

Abstract

The embodiment of the invention provides a method, a device and computer equipment for detecting public network quality of CDN nodes, wherein the method comprises the following steps: detecting whether there is a point-to-point P2P detection pair that meets the fault event condition; the fault event conditions include: the packet loss rate between the detected P2P detection pairs exceeds a first preset threshold value and lasts for a first preset time; and/or the occurrence of a delay value between the detected P2P detection pairs is increased by a second preset threshold value compared with the last acquired delay value and lasts for a second preset time period; the P2P probe pair corresponds to two CDN network nodes; if there are P2P probe pairs that meet the fault event condition, then a determination is made that a class P2P fault event occurred. According to the embodiment of the invention, each CDN node is abstracted into a logical site, the network quality of a remote destination is detected in real time by using probe tools such as ping/tcping and the like through the CDN nodes, and the network quality among the CDN nodes is judged according to indexes such as packet loss rate (packet loss) and delay (delay) and whether a P2P fault event exists or not.

Description

Method and device for detecting public network quality of CDN node and computer equipment
Technical Field
The invention relates to the field of network communication, in particular to a method and a device for detecting public network quality of CDN nodes and computer equipment.
Background
The CDN is called a Content Delivery Network, i.e., a Content Delivery Network. The CDN is an intelligent virtual network constructed on the basis of the existing network, and by means of edge servers deployed in various places and functional modules of load balancing, content distribution, scheduling and the like of a central platform, a user can obtain required content nearby, network congestion is reduced, and the access response speed and hit rate of the user are improved. The key technology of the CDN is mainly content storage and distribution technology. The generation of CDN networks has greatly improved the service quality of the internet, so that traditional large-scale network operators begin to build their own CDN networks, such as AT & T, german telecommunications, china telecommunications, and so on.
In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art: and operation and maintenance personnel manually log in the designated CDN node server for manual detection, and the real-time performance is poor.
Disclosure of Invention
The embodiment of the invention provides a method and a device for detecting public network quality of CDN nodes and computer equipment, which aim to solve the problem of poor real-time performance of manual detection.
In a first aspect, an embodiment of the present invention provides a method for detecting public network quality of a CDN network node, where the method includes:
detecting whether there is a point-to-point P2P detection pair that meets the fault event condition; the fault event conditions include: the packet loss rate between the detected P2P detection pairs exceeds a first preset threshold value and lasts for a first preset time; and/or the occurrence of a delay value between the detected P2P detection pairs is increased by a second preset threshold value compared with the last acquired delay value and lasts for a second preset time period; the P2P probe pair corresponds to two CDN network nodes;
if there are P2P probe pairs that meet the fault event condition, then a determination is made that a class P2P fault event occurred.
In a second aspect, an embodiment of the present invention provides an apparatus for detecting public network quality of a CDN network node, where the apparatus includes:
a detection module for detecting whether there is a point-to-point P2P detection pair that meets a fault event condition; the fault event conditions include: the packet loss rate between the detected P2P detection pairs exceeds a first preset threshold value and lasts for a first preset time; and/or the occurrence of a delay value between the detected P2P detection pairs is increased by a second preset threshold value compared with the last acquired delay value and lasts for a second preset time period; the P2P probe pair corresponds to two CDN network nodes;
and the judging module is used for judging that a P2P type fault event is generated if the P2P detection pair meeting the fault event condition exists.
In a third aspect, an embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored, where the computer program is executed by a processor to implement the above method for detecting public network quality of a CDN network node.
In a fourth aspect, an embodiment of the present invention provides a computer device for detecting public network quality of a CDN network node, where the computer device is characterized in that: one or more processors; a memory for storing one or more programs; when executed by the one or more processors, the one or more programs cause the one or more processors to implement the above-described method for detecting public network quality of CDN network nodes.
The technical scheme has the following beneficial effects: according to the embodiment of the invention, each CDN node is abstracted into a logical site, the network quality of a remote destination is detected in real time by using probe tools such as ping/tcping and the like through the CDN nodes, and the network quality among the CDN nodes is judged according to indexes such as packet loss rate (packet loss) and delay (delay) and whether a P2P fault event exists or not. The embodiment of the invention can automatically detect CDN nodes, has good real-time performance, can trace the source, and can know the global network quality to help decision makers to make positive adjustment.
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 some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a flowchart of a method for detecting public network quality of CDN network nodes according to an embodiment of the present invention.
FIG. 2 is a schematic diagram of a P2P point-to-point network model according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of a P2MP point-to-multipoint network model according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of a P2AP Point-to-all Point network model according to an embodiment of the present invention;
FIG. 5 is a schematic diagram of a detection relationship of a detection model of fullmesh according to an embodiment of the present invention;
FIGS. 6A-6B are logic flow diagrams illustrating exemplary detailed logic for determining the occurrence of an exception event according to one embodiment of the present invention;
FIG. 7 is a schematic diagram of data collection, processing, reporting and display according to an embodiment of the present invention;
fig. 8 is a schematic diagram of a real-time detection result from any node to any other node, which is presented in a fullmesh manner according to the embodiment of the present invention;
FIG. 9 is a diagram of an example of a display of a fault history at the front end of an embodiment of the present invention;
fig. 10 is a functional block diagram of detecting public network quality of CDN network nodes according to an embodiment of the present invention;
fig. 11 is a functional block diagram of a computer device for detecting public network quality of CDN network nodes 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.
Fig. 1 is a flowchart of a method for detecting public network quality of CDN network nodes according to an embodiment of the present invention. As shown in fig. 1, it includes the following steps:
s110: detecting whether there is a point-to-point P2P detection pair that meets the fault event condition; the fault event conditions include: the packet loss rate between the detected P2P detection pairs exceeds a first preset threshold value and lasts for a first preset time; and/or the occurrence of a delay value between the detected P2P detection pairs is increased by a second preset threshold value compared with the last acquired delay value and lasts for a second preset time period; P2P probe pairs correspond to two CDN network nodes;
s120: if there are P2P probe pairs that meet the fault event condition, then a determination is made that a class P2P fault event occurred.
Further, the method may further comprise the steps of: determining an event type of the P2P fault event; the event types include: packet loss delay increase exists; or alternatively, not.
Further, the method may further comprise the steps of: when the event type of the P2P-class fault event is that packet loss delay is increased, further judging whether two ends of the P2P detection pair have respective point-to-multipoint P2 MP-class fault events; and if the two ends of the P2P detection pair do not have respective P2MP fault events, determining that the quality of the public network between the P2P detection pair is abnormal, adding the P2P detection pair into a blacklist, and reporting the P2P fault events and test data thereof to the monitoring system.
Further, the method may further comprise the steps of: if at least one of the two ends of the P2P detection pair has a respective P2MP type fault event, adding all P2P detection pairs (i.e., P2MP detection pairs, P2MP detection pairs including multiple groups of P2P detection pairs) corresponding to the P2MP type fault event into a blacklist, and then judging whether a traffic congestion exists at an outlet of the CDN network node corresponding to the at least one end; if the traffic congestion exists, determining that the P2P fault event is generated by the traffic congestion, and reporting to a monitoring system; if the traffic congestion does not exist, determining that the quality of the public network is deteriorated and abnormal among all the P2P detection pairs corresponding to the P2MP fault events, and reporting the P2MP fault events and the test data thereof to the monitoring system.
Further, the method may further comprise the steps of: when the event type of the P2P fault event is not on, further judging whether the two ends of the P2P detection pair have respective P2MP fault events; if the two ends of the P2P detection pair do not have the P2MP fault events, the fact that the public network access abnormality occurs between the P2P detection pair is determined, the P2P detection pair is added into a blacklist, and then the P2P fault events and test data thereof are reported to a monitoring system.
Further, the method may further comprise the steps of: if at least one of the two ends of the P2P detection pair has respective P2MP fault events, adding all P2P detection pairs corresponding to the P2MP fault events into a blacklist, and then judging whether the flow congestion exists at the outlet of the CDN network node corresponding to the at least one end; if the traffic congestion exists, determining that the P2P fault event is generated by the traffic congestion, and reporting the P2P fault event generated by the traffic congestion to the monitoring system.
Further, the method may further comprise the steps of: if the traffic congestion does not exist, further judging whether at least one end has a point-to-all point P2AP fault event; if the P2AP fault event does not exist, reporting the P2MP fault event and the test data thereof to the monitoring system; if the P2AP fault event exists, judging whether detection results of other monitoring detectors of the CDN network node corresponding to the at least one end also have a P2AP fault event; if the detection results of other monitoring detectors do not have the P2AP fault event, determining that the main monitoring detector has a fault, and reporting the abnormal event of the main monitoring detector to the monitoring system; and if the detection results of other monitoring detectors have P2AP fault events, determining that the CDN network node corresponding to the at least one end is out of network, and reporting the CDN network node out-of-network events corresponding to the at least one end to the monitoring system.
Further, determining whether both ends of the P2P probing pair have respective point-to-multipoint P2MP type failure events may include the following steps; respectively judging whether abnormality exists between other CDN network nodes and the CDN network node corresponding to each end of the P2P detection pair, wherein the judgment condition for the abnormality includes: the current packet loss rate exceeds a first preset threshold; and/or the current delay value is increased by a second preset threshold value compared with the last acquired delay value; when the abnormality exists, the current end of the P2P detection pair is determined not to have the P2MP type fault event, and when the abnormality does not exist, the current end of the P2P detection pair is determined to have the P2MP type fault event.
Further, the method may further comprise the steps of: monitoring detectors are arranged in all CDN network nodes in advance, wherein detection relations exist between any two CDN network nodes, and the monitoring detectors comprise pings or tcpings.
The embodiment of the invention provides a method and computer equipment for detecting the network quality of a public network CDN node in real time. The embodiment of the invention aims to enhance the real-time performance and traceability of public network quality monitoring, provide fault abnormity early warning capability, provide visualization capability, provide a global network quality presentation method, provide real-time detailed monitoring basic data, further help a network decision maker to analyze network operation quality and help the network decision maker to quickly make judgment and positive adjustment when a fault occurs.
The embodiment of the invention introduces a point-to-point concept of P2P (point-to-multipoint), a point-to-multipoint concept of P2MP (point-to-multipoint), and a point-to-all concept of P2AP (point-to-multipoint), and abstracts each CDN node into a logical site; the method comprises the steps that a server of the CDN node uses probe tools such as ping/tcping and the like to detect the network quality of a remote target in real time, and the network quality is judged according to indexes such as packet loss rate (packet loss) and delay (delay); the method comprises the steps that probes (monitoring detectors) are deployed at all CDN nodes, and all other nodes of the whole network are detected in real time, so that detection results of a whole network fullmesh model are obtained; uploading detection results of all CDN nodes to a data receiver, and performing receiving and storage processing by the data receiver; and the display platform module calls the stored detection result to perform front-end fullmesh display. The data receiver is a database device specially used for data storage, and the monitoring data can be stored in the database device in a pre-designated format. The database device is a part of the monitoring system and is responsible for storing and retrieving data. The monitoring system comprises a data receiver and a display platform module.
The technical scheme of the embodiment of the invention is suitable for the condition that a plurality of public network CDN network nodes exist in an organization or a company.
The technical solution of the embodiment of the present invention is explained in more detail below:
description of network model
P2P Point-to-Point
Each public network CDN network node is abstracted into one point, and as shown in fig. 2, P2P is a detection relationship formed by two points.
P2MP Point-to-multipoint
Each public network CDN network node is abstracted into a point, and P2MP is a probe relationship formed by CDN network nodes 1 to 2, 3, and 4 as shown in fig. 3.
P2AP Point to all other points
Each public network CDN network node is abstracted into one point, and as shown in fig. 4, P2AP is a probe relationship formed by CDN network nodes 1 to 2, 3, and 4 … N.
Second, detecting tool
The detection model is fullmesh, that is, a detection relationship exists between any two points, as exemplified by 5 sites, as shown in fig. 5. The monitoring detector uses a network probe tool such as ping, tcping and the like to detect, for example, 100 times for each detection, and the monitoring detector deployed by the CDN node uploads a packet loss rate statistical result, a delay result and a timestamp returned in each detection to the monitoring system for storage.
Third, judging the detailed logic of abnormal event generation
As shown in the flow chart of fig. 6A-6B, the method includes the following steps:
step S1: the monitor probe first finds the P2P probe pair that meets the generate fault event condition.
Step S2: check the P2P to see if the pair is in the blacklist and if so, the event ends.
Specifically, the blacklist refers to a list of P2P probe pairs, in which the P2P probe pair does not proceed with step S3 and subsequent failure determination steps if a failure event condition is triggered.
Step S3: if the P2P probe pair is not on the blacklist, a P2P class failure event is generated.
Step S4: judging the event types of the P2P fault events, wherein the event types are divided into two types: packet loss, delay increase and jitter exist; it is not through.
In this step, a specific determination method is to respectively determine whether there is a P2P fault event between the CDN nodes at both ends and the other CDN nodes. The judgment rule is described in detail in "failure event generation condition" hereinafter.
Step S5: and if the type of the fault event is that the packet loss delay is increased, continuously judging whether the two ends of the P2P detection pair have respective P2MP fault events.
In this step, it is determined whether there is a P2MP fault between the other nodes than the P2P probe pair and each node in the P2P probe pair.
Step S6: in step S5, if not, it indicates that only the P2P probe pair has abnormal quality degradation of the public network, so the P2P probe pair is added to the black list to avoid repeated judgment of the system, and then the P2P fault event and its mtr test data are reported to the monitoring system, and the event is ended.
In this step, mtr refers to Matt's traceroute, an open source network diagnostic analysis tool.
Step S7: and step S5, if yes, putting all the pre-fault events, that is, all the P2P detection pairs corresponding to the P2 MP-type fault event, into the blacklist to avoid repeated judgment of the system. And then judging whether the machine room, namely the exit of the CDN network node included in the at least one end having the P2MP fault event, has traffic congestion.
Step S8: and step S7, if yes, it indicates that the event is generated by traffic congestion, and the event is directly reported to the monitoring system, and the event is ended.
Step S9: and step S7, if the fault event does not exist, the abnormal situation that the quality of the public network is deteriorated occurs between the P2MP detection pairs, the fault event of the P2MP and the test data such as the mtr of the fault event are reported to the monitoring system, and the event is ended.
Step S10: and step S4, if the event type is not passed, determining whether a P2MP fault exists at both ends.
Step S11: in step S10, if not, it indicates that only the P2P probe pair has a public network access exception, so the P2P probe pair is added to the blacklist to avoid repeated system determination, and then the P2P fault event and its mtr test data are reported to the monitoring system, and the event is ended.
Step S12: and step S10, if yes, putting all the P2P detection pairs corresponding to the P2 MP-type fault event into a blacklist to avoid repeated judgment of the system. And then judging whether the machine room (CDN network node) outlet has flow congestion.
Step S13: and step S12, if yes, it indicates that the event is generated by traffic congestion, and the event is directly reported to the monitoring system, and the event is ended.
Step S14: if not, the step S12 continues to determine whether the P2AP fault exists.
Specifically, the step of determining whether the P2AP fault is present comprises: and judging whether the CDN node and all other CDN nodes have a P2P fault event or not. The judgment rule refers to "failure event generation condition" below.
Step S15: if not, the P2MP fault event and the mtr test data are reported to the monitoring system in step S14, and the event is ended.
Step S16: step S14, if yes, it is determined whether the detection result of other monitoring detectors in the computer room (CDN network node) is also a P2AP fault.
In an alternative embodiment, a CDN network node may deploy multiple monitoring probes, including a primary monitoring probe and a backup monitoring probe. Whether the main monitoring detector breaks down or not can be judged by respectively capturing the monitoring data or the results of the main monitoring detector and the standby monitoring detector and comparing the monitoring data or the results.
Step S17: and step S16, if not, the main monitoring detector is in failure, and the abnormal event of the main monitoring detector is reported to the monitoring system.
Specifically, the monitoring system is used for collecting and storing monitoring data, judging a fault event according to rules, and displaying the fault in real time on a display platform.
Step S18: and step S16, if yes, indicating that the computer room (P2P detects CDN network nodes included in the computer room) is offline, and reporting the CDN network node offline event to the monitoring system. In this step, a P2AP fault occurs, which indicates that a CDN network node cannot communicate with all other CDN network nodes, and may be determined that the CDN network node is offline. In some optional embodiments, the P2AP fault event may also be reported to the monitoring system, or the CDN network node offline event may be reported to the monitoring system together with the P2AP fault event.
Definition of some concepts:
(1) failure event generating conditions
The packet loss rate between any two detected or detected CDN network nodes exceeds 5% and lasts for 5 minutes.
The occurrence of delay between any two CDN network nodes detected or probed increases by 50% over the last acquisition and lasts for 5 minutes.
Any one of the above conditions may be satisfied.
(2) Blacklist retention time
P2P entering the blacklist monitors that the entry no longer generates a failure event.
(3) P2MP event fulfillment condition
Judging whether other nodes are abnormal to the node or not, wherein the abnormal conditions are as follows:
the current packet loss rate exceeds a first preset threshold, for example, 5%.
The current delay value is increased by a second preset threshold, for example 50%, compared to the last acquired delay value.
The conditions for the P2AP fault event are: whether a P2P fault event exists in one CDN node and all other CDN nodes is determined.
Fourthly, collecting and processing data
As shown in fig. 7, the probes of each node, i.e., the monitoring probes 201, send the detection data to the designated API interface of the data receiving end (i.e., the monitoring system) in a unified manner, and the data receiving end stores the data in the relevant database, so as to facilitate subsequent calling and platform display. The monitoring system includes a data receiver 202 and a platform presentation module 203.
Design of visual display part
(1) And (3) displaying a real-time detection result:
the display method is presented in a fullmesh mode, real-time detection results from any node to any other node can be effectively displayed and matched with a data acquisition mode, and the latest P2P detection results can be refreshed in real time, as shown in FIG. 8. The fullmesh method represents an association form, namely a form in which all nodes are associated with each other.
(2) And (3) fault history record storage:
and storing the contents such as node export operator information, node names, probe information, alarm contents, alarm time and the like in a background and displaying the contents at the front end. See fig. 9 for an example.
The embodiment of the invention also provides a device for detecting the public network quality of the CDN network node. As shown in fig. 10, it includes:
a detection module for detecting whether there is a point-to-point P2P detection pair that meets a fault event condition; the fault event conditions include: the packet loss rate between the detected P2P detection pairs exceeds a first preset threshold value and lasts for a first preset time; and/or the occurrence of a delay value between the detected P2P detection pairs is increased by a second preset threshold value compared with the last acquired delay value and lasts for a second preset time period; P2P probe pairs correspond to two CDN network nodes;
and the P2P type fault event judging module is used for judging that a P2P type fault event is generated if the P2P detection pair meeting the fault event condition exists.
Further, the apparatus may further include: the event type determining module is used for determining the event type of the P2P fault event; the event types include: packet loss delay increase exists; or alternatively, not.
Further, the apparatus may further include:
a first P2 MP-class fault event determining module, configured to further determine whether each of two ends of the P2P detection pair has a point-to-multipoint P2 MP-class fault event when the event type of the P2P-class fault event is packet loss delay increase;
and the first processing and reporting module is used for determining that the quality of the public network is deteriorated abnormally between the P2P detection pairs if both ends of the P2P detection pairs do not have respective P2MP fault events, adding the P2P detection pairs into a blacklist, and reporting the P2P fault events and test data thereof to the monitoring system.
Further, the apparatus may further include:
a second processing and reporting module, configured to add all P2P detection pairs corresponding to the P2 MP-type fault event to the blacklist if at least one of two ends of the P2P detection pair has a respective P2 MP-type fault event, and then determine whether a traffic congestion exists at an outlet of a CDN network node corresponding to the at least one end; if the traffic congestion exists, determining that the P2P fault event is generated by the traffic congestion, and reporting to the monitoring system; and if the traffic congestion does not exist, determining that the quality of the public network is abnormally deteriorated among all the P2P detection pairs corresponding to the P2MP fault events, and reporting the P2MP fault events and the test data thereof to the monitoring system.
Further, the apparatus may further include:
a second P2 MP-class fault event determining module, configured to further determine whether there is a respective P2 MP-class fault event at both ends of the P2P detection pair when the event type of the P2P-class fault event is invalid;
and a third processing and reporting module, configured to determine that a public network access exception occurs between the P2P detection pairs if neither of two ends of the P2P detection pairs has a P2 MP-type fault event, add the P2P detection pair to a blacklist, and report the P2P-type fault event and test data thereof to the monitoring system.
Further, the apparatus may further include:
a fourth processing reporting module configured to: if at least one of the two ends of the P2P detection pair has a respective P2MP type fault event, adding all P2P detection pairs corresponding to the P2MP type fault event into a blacklist, and then judging whether a traffic congestion exists at an outlet of a CDN network node corresponding to the at least one end; and if the traffic congestion exists, determining that the P2P fault event is generated by the traffic congestion, and reporting the P2P fault event generated by the traffic congestion to the monitoring system.
Further, the apparatus may further include: a fifth processing reporting module configured to:
if the traffic congestion does not exist, further judging whether the at least one end has a point-to-all point P2AP fault event; if the P2AP fault event does not exist, reporting the P2MP fault event and test data thereof to the monitoring system; if the P2AP fault event exists, judging whether the detection result of other monitoring detectors of the CDN network node corresponding to the at least one end also has a P2AP fault event; if the detection results of other monitoring detectors do not have the P2AP fault event, determining that the main monitoring detector has a fault, and reporting the abnormal event of the main monitoring detector to the monitoring system; and if the detection results of other monitoring detectors have P2AP fault events, determining that the CDN network node corresponding to the at least one end is out of network, and reporting the CDN network node out-of-network events corresponding to the at least one end to the monitoring system.
Wherein, further judging whether both ends of the P2P detection pair have respective point-to-multipoint P2MP type fault events, including; respectively judging whether abnormality exists between other CDN network nodes and the CDN network node corresponding to each end of the P2P detection pair, wherein the judgment condition for the abnormality existence comprises: the current packet loss rate exceeds the first preset threshold; and/or the current delay value is increased by the second preset threshold value compared with the last acquired delay value; when the abnormality exists, the current end of the P2P detection pair is determined not to have the P2MP type fault event, and when the abnormality does not exist, the current end of the P2P detection pair is determined to have the P2MP type fault event.
Further, the device further comprises a deployment module, which is used for deploying monitoring probes on all CDN network nodes in advance, wherein a detection relationship exists between any two CDN network nodes, and the monitoring probes include ping or tcping. The embodiment of the present invention further provides a computer device for detecting the public network quality of a CDN network node, as shown in fig. 10, including one or more processors 301, a communication interface 302, a memory 303, and a communication bus 304, where the processors 301, the communication interface 302, and the memory 303 complete mutual communication through the communication bus 304.
A memory 303 for storing a computer program;
the processor 301 is configured to implement the steps of the method for detecting the public network quality of the CDN node when executing the program stored in the memory 303.
In the prior art, operation and maintenance personnel manually log in an appointed CDN node server to perform manual detection, the real-time performance is poor, the source cannot be traced, historical data cannot be checked, the early warning capability is not provided, the visualization is not provided, and the global network quality cannot be known so as to help decision makers to make positive adjustment. The computer device of the embodiment of the present invention solves the above technical problems of the prior art.
The communication bus mentioned in the electronic device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus. The communication interface is used for communication between the electronic equipment and other equipment.
The Memory may include a Random Access Memory (RAM) or a Non-Volatile Memory (NVM), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor.
The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.
The embodiment of the invention also provides a computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when being executed by a processor, the computer program realizes the steps of the method for detecting the public network quality of the CDN network node.
It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, 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.
All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the device, the electronic device and the readable storage medium embodiments, since they are substantially similar to the method embodiments, the description is simple, and the relevant points can be referred to the partial description of the method embodiments.
The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.

Claims (10)

1. A method for detecting public network quality of CDN network nodes is characterized by comprising the following steps:
detecting whether there is a point-to-point P2P detection pair that meets the fault event condition; the fault event conditions include: the packet loss rate between the detected P2P detection pairs exceeds a first preset threshold value and lasts for a first preset time; and/or the occurrence of a delay value between the detected P2P detection pairs is increased by a second preset threshold value compared with the last acquired delay value and lasts for a second preset time period; the P2P probe pair corresponds to two CDN network nodes;
if the P2P detection pair meets the fault event condition, judging that a P2P type fault event is generated;
the method further comprises the following steps:
determining an event type of the P2P-type fault event; the event types include: packet loss delay increase exists; alternatively, not go;
when the event type of the P2P-class fault event is packet loss delay increase, further determining whether the two ends of the P2P detection pair have respective point-to-multipoint P2 MP-class fault event;
if both ends of the P2P detection pair do not have respective P2MP fault events, it is determined that quality deterioration of the public network occurs between the P2P detection pair, the P2P detection pair is added into a blacklist, and then the P2P fault events and test data thereof are reported to a monitoring system.
2. The method of claim 1, further comprising:
if at least one of the two ends of the P2P detection pair has a respective P2MP type fault event, adding all P2P detection pairs corresponding to the P2MP type fault event into the blacklist, and then judging whether a traffic congestion exists at an outlet of a CDN network node corresponding to the at least one end;
if the traffic congestion exists, determining that the P2P fault event is generated by the traffic congestion, and reporting to the monitoring system;
and if the traffic congestion does not exist, determining that the quality of the public network is abnormally deteriorated among all the P2P detection pairs corresponding to the P2MP fault events, and reporting the P2MP fault events and the test data thereof to the monitoring system.
3. The method of claim 1, further comprising:
when the event type of the P2P fault event is not on, further judging whether the two ends of the P2P detection pair have respective P2MP fault events;
if both ends of the P2P detection pair do not have P2MP fault events, determining that public network access abnormality occurs between the P2P detection pair, adding the P2P detection pair into a blacklist, and reporting the P2P fault events and test data thereof to a monitoring system.
4. The method of claim 3, further comprising:
if at least one of the two ends of the P2P detection pair has a respective P2MP type fault event, adding all P2P detection pairs corresponding to the P2MP type fault event into a blacklist, and then judging whether a traffic congestion exists at an outlet of a CDN network node corresponding to the at least one end;
and if the traffic congestion exists, determining that the P2P fault event is generated by the traffic congestion, and reporting the P2P fault event generated by the traffic congestion to the monitoring system.
5. The method of claim 4, further comprising:
if the traffic congestion does not exist, further judging whether the at least one end has a point-to-all point P2AP fault event;
if the P2AP fault event does not exist, reporting the P2MP fault event and test data thereof to the monitoring system;
if the P2AP fault event exists, judging whether the detection result of other monitoring detectors of the CDN network node corresponding to the at least one end also has a P2AP fault event;
if the detection results of other monitoring detectors do not have the P2AP fault event, determining that the main monitoring detector has a fault, and reporting the abnormal event of the main monitoring detector to the monitoring system;
and if the detection results of other monitoring detectors have P2AP fault events, determining that the CDN network node corresponding to the at least one end is out of network, and reporting the CDN network node out-of-network events corresponding to the at least one end to the monitoring system.
6. The method of claim 1, wherein said further determining if both ends of said P2P probe pair have respective point-to-multipoint class P2MP failure events comprises;
respectively judging whether abnormality exists between other CDN network nodes and the CDN network node corresponding to each end of the P2P detection pair, wherein the judgment condition for the abnormality existence comprises: the current packet loss rate exceeds the first preset threshold; and/or the current delay value is increased by the second preset threshold value compared with the last acquired delay value;
when the abnormality exists, the current end of the P2P detection pair is determined not to have the P2MP type fault event, and when the abnormality does not exist, the current end of the P2P detection pair is determined to have the P2MP type fault event.
7. The method according to any one of claims 1-6, further comprising:
monitoring detectors are arranged in all CDN network nodes in advance, wherein detection relations exist between any two CDN network nodes, and the monitoring detectors comprise pings or tcpings.
8. A device for detecting public network quality of CDN network nodes is characterized by comprising:
a detection module for detecting whether there is a point-to-point P2P detection pair that meets a fault event condition; the fault event conditions include: the packet loss rate between the detected P2P detection pairs exceeds a first preset threshold value and lasts for a first preset time; and/or the occurrence of a delay value between the detected P2P detection pairs is increased by a second preset threshold value compared with the last acquired delay value and lasts for a second preset time period; the P2P probe pair corresponds to two CDN network nodes;
a decision module for deciding to generate a class P2P fault event if there is a P2P probe pair that meets the fault event condition;
the device also includes:
the event type determining module is used for determining the event type of the P2P fault event; the event types include: packet loss delay increase exists; alternatively, not go;
a first P2 MP-class fault event determining module, configured to further determine whether each of two ends of the P2P detection pair has a point-to-multipoint P2 MP-class fault event when the event type of the P2P-class fault event is packet loss delay increase;
and the first processing and reporting module is used for determining that the quality of the public network is deteriorated abnormally between the P2P detection pairs if both ends of the P2P detection pairs do not have respective P2MP fault events, adding the P2P detection pairs into a blacklist, and reporting the P2P fault events and test data thereof to the monitoring system.
9. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out a method for probing the public network quality of a CDN network node as set forth in any one of claims 1-7.
10. A computer device for detecting public network quality of CDN network nodes is characterized by comprising:
one or more processors;
a memory for storing one or more programs;
the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of probing CDN network node public network quality of any of claims 1-7.
CN202010273192.9A 2020-04-09 2020-04-09 Method and device for detecting public network quality of CDN node and computer equipment Active CN111585833B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010273192.9A CN111585833B (en) 2020-04-09 2020-04-09 Method and device for detecting public network quality of CDN node and computer equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010273192.9A CN111585833B (en) 2020-04-09 2020-04-09 Method and device for detecting public network quality of CDN node and computer equipment

Publications (2)

Publication Number Publication Date
CN111585833A CN111585833A (en) 2020-08-25
CN111585833B true CN111585833B (en) 2022-03-11

Family

ID=72116781

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010273192.9A Active CN111585833B (en) 2020-04-09 2020-04-09 Method and device for detecting public network quality of CDN node and computer equipment

Country Status (1)

Country Link
CN (1) CN111585833B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113300901B (en) * 2020-08-27 2024-03-12 阿里巴巴集团控股有限公司 Data stream monitoring method and device, electronic equipment and storage medium
CN113438106B (en) * 2021-06-22 2023-02-21 北京百度网讯科技有限公司 Content distribution network processing method and device and electronic equipment

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104270291B (en) * 2014-10-22 2018-05-01 网宿科技股份有限公司 CDN network quality control method
US10103945B2 (en) * 2015-04-06 2018-10-16 Level 3 Communications, Llc Server side content delivery network quality of service
US10536357B2 (en) * 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
CN106130816B (en) * 2016-06-24 2018-12-28 腾讯科技(深圳)有限公司 A kind of content distributing network monitoring method, monitoring server and system
CN106130767B (en) * 2016-09-23 2020-04-07 深圳灵动智网科技有限公司 System and method for monitoring and solving service path fault
CN107493192B (en) * 2017-08-08 2018-10-16 深圳市网心科技有限公司 Basic network method for evaluating quality and device for the transmission of video CD N business
CN109962790B (en) * 2017-12-14 2020-05-29 北京金山云网络技术有限公司 Network quality monitoring method and device, electronic equipment and storage medium

Also Published As

Publication number Publication date
CN111585833A (en) 2020-08-25

Similar Documents

Publication Publication Date Title
WO2018126645A1 (en) Communication network management method and apparatus therefor
CN111585833B (en) Method and device for detecting public network quality of CDN node and computer equipment
CN109962790B (en) Network quality monitoring method and device, electronic equipment and storage medium
CN102740112B (en) Method for controlling equipment polling based on video monitoring system
CN110716842B (en) Cluster fault detection method and device
US9823311B2 (en) System to identify potential electrical network faults combining vibration and power quality analysis
Shah et al. Disco: Fast, good, and cheap outage detection
CN112583642B (en) Abnormality detection method, abnormality detection model, electronic device, and computer-readable storage medium
WO2016033897A1 (en) Network link monitoring method and device, network system and storage medium
CN105450292A (en) Fault diagnosis analysis method, fault diagnosis device, fault analysis device and fault diagnosis analysis system
CN113542017A (en) Network fault positioning method based on network topology and multiple indexes
CN114996090A (en) Server abnormity detection method and device, electronic equipment and storage medium
CN113708956A (en) Circuit quality evaluation method
CN107154867A (en) Network fault detecting method and device
CN107370618B (en) Troubleshooting method and device and electronic equipment
CN110474821A (en) Node failure detection method and device
JP2014053658A (en) Failure site estimation system and failure site estimation program
KR100500836B1 (en) Fault management system of metro ethernet network and method thereof
CN114257414A (en) Intelligent network security duty method and system
TW201409968A (en) Information and communication service quality estimation and real-time alarming system and method
CN111585819A (en) Distribution network communication equipment fault analysis method and system
CN112835780B (en) Service detection method and device
JP6513001B2 (en) Failure detection device, failure detection method, and program
CN107426044B (en) Serial line detection method and device and operation and maintenance server
CN109688023B (en) Method for monitoring availability of CDN (content delivery network) deployed in anycast mode

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
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20230406

Address after: Room 501-502, 5/F, Sina Headquarters Scientific Research Building, Block N-1 and N-2, Zhongguancun Software Park, Dongbei Wangxi Road, Haidian District, Beijing, 100193

Patentee after: Sina Technology (China) Co.,Ltd.

Address before: 100193 7th floor, scientific research building, Sina headquarters, plot n-1, n-2, Zhongguancun Software Park, Dongbei Wangxi Road, Haidian District, Beijing, 100193

Patentee before: Sina.com Technology (China) Co.,Ltd.