Network line quality monitoring method, device and equipment and storage medium

Abstract

The application discloses a network line quality monitoring method, device and equipment and a storage medium, and belongs to the technical field of network quality monitoring. The network line quality monitoring method comprises the following steps: acquiring a monitoring time period and a plurality of single-line monitoring task data collected by a simple network management protocol collector for a monitoring line of an access device; determining all target single-task execution time corresponding to the same opposite end interface address data and all target single-task quality index data from the plurality of single-line monitoring task data; and obtaining line continuous monitoring data of the line monitoring item in the monitoring time period based on the target single-task execution time and all the target single-task quality index data in the monitoring time period for the same opposite end interface address data. The method realizes effective monitoring of network continuous packet loss and network continuous delay exceeding a threshold and other network abnormal conditions.

Description

Technical Field

[0001] This invention relates to the field of network quality monitoring, and more particularly to methods, apparatus, equipment and storage media for monitoring network line quality. Background Technology

[0002] In the field of network quality monitoring, accurate, real-time, and stable monitoring of network line quality is required. Related technologies primarily utilize probing techniques such as RPING (Remote Ping, a technology that sends ping commands to a target host over a network and receives responses), NQA (Network Quality Analyzer), SQA (Service Quality Assurance, a technology for comprehensive management of network service quality), and IPSLA (IP Service Level Agreement, a network management technology) to collect data on network latency and packet loss rates.

[0003] However, the relevant technologies can only complete the instantaneous indicators collected in the current instance, and cannot effectively monitor abnormal network scenarios such as continuous packet loss and network latency exceeding the threshold. Summary of the Invention

[0004] The main objective of this invention is to provide a method, apparatus, device, and storage medium for monitoring network line quality, aiming to solve the technical problem that related technologies cannot effectively monitor abnormal network scenarios such as continuous packet loss and persistent network latency exceeding thresholds.

[0005] To achieve the above objectives, the present invention provides a network line quality monitoring method, which includes:

[0006] The system acquires multiple single-line monitoring task data collected by the Simple Network Management Protocol (SRM) collector for the monitoring lines of access devices during the monitoring period. The single-line monitoring task data includes the single-task execution time, the task execution sequence number, the peer interface address data connected to the access device, and the single-task quality index data.

[0007] From multiple single-line monitoring task data, determine the execution time of all target single tasks and the quality index data of all target single tasks corresponding to the same peer interface address data;

[0008] For the same peer interface address data, based on the target single task execution time and the quality index data of all target single tasks within the monitoring period, continuous line monitoring data of the line monitoring items is obtained within the monitoring period.

[0009] Optionally, from multiple single-line monitoring task data, determine the execution time of all target single tasks and the quality index data of all target single tasks corresponding to the same peer interface address data, including:

[0010] Based on data from multiple single-line monitoring tasks, peer interface address result data and single-task quality indicator result data are obtained. Among them, peer interface address result data and single-task quality indicator result data are both key-value pairs. The attribute keys of peer interface address result data and single-task quality indicator result data are object identifiers, character ASCII codes of task configuration item parameter values, character ASCII codes of single dial-up test acquisition task names, acquisition task execution sequence numbers, and acquisition result codes obtained by concatenating task types. The attribute value of peer interface address result data is peer interface address data, and the attribute value of single-task quality indicator result data is single-task quality indicator data.

[0011] Traverse the peer interface address result data to determine all target acquisition result codes corresponding to the same peer interface address data, and obtain the first key-value pair; wherein, the attribute key of the first key-value pair is the same peer interface address data, and the attribute value is the target acquisition result code;

[0012] Based on the target acquisition result encoding, query the single task quality indicator result data to determine the execution time of all target single tasks and the single task quality indicator data of all targets corresponding to the same peer interface address data.

[0013] Optionally, before acquiring the monitoring time period and multiple single-line monitoring task data collected by the Simple Network Management Protocol (SRM) collector for the monitoring lines of the access devices, the method further includes:

[0014] Obtain line monitoring item data, global configuration parameters, and alarm indicator data; global configuration parameters include probe task frequency, probe message quantity, and message sending interval; alarm indicator data is related to single task quality indicator data; line monitoring item data includes access interface address and peer interface address.

[0015] Determine the dial-up test configuration template and dial-up test task check instructions corresponding to the application technology type of the access device; the application technology type is either Network Quality Analysis (NQA), Internet Protocol Service Level Agreement (IPSLA), or Network Quality Assurance (SQA).

[0016] Based on the line monitoring item data, global dial test configuration parameters, and alarm indicator data, the dial test configuration template is filled to obtain the dial test task configuration content for the line monitoring item.

[0017] The device operation layer issues the configuration content of the single line monitoring task and the check instruction of the single line monitoring task to the access device.

[0018] Optionally, the device operation layer issues the configuration content and check instructions for a single line monitoring task to the access device, including:

[0019] The device operation layer issues a test task inspection command to the access device.

[0020] If the execution echo of the test task check command is obtained, determine whether there is a task with the same name as a single line monitoring task based on the execution echo.

[0021] If it does not exist, the device operation layer sends the test task configuration content to the access device and returns to execute the test task check command sent to the access device through the device operation layer.

[0022] If it exists, then the single dial-up test task is confirmed to have been successfully configured on the access device.

[0023] Optionally, after obtaining continuous line monitoring data for the line monitoring item within the monitoring period based on the execution time of the target single task and the quality index data of all target single tasks within the monitoring period, the method further includes:

[0024] If the packet loss rate of a single task in at least one target single task quality indicator data is 100%, a line interruption alarm event will be triggered.

[0025] If no line interruption alarm event is triggered, determine whether the average packet loss rate of multiple tasks in the continuous line monitoring data is greater than or equal to the first preset alarm threshold.

[0026] If the average packet loss rate of multiple consecutive tasks exceeds the threshold, an alarm event will be triggered if the average packet loss rate of multiple tasks exceeds the threshold.

[0027] If neither the line interruption alarm event nor the alarm event of the average packet loss rate exceeding the threshold for multiple consecutive tasks is triggered, then determine whether the packet loss rate of a single task is greater than or equal to the second preset alarm threshold.

[0028] If the packet loss rate is greater than or equal to the second preset alarm threshold, an alarm event for exceeding the packet loss rate threshold will be triggered.

[0029] Optionally, after obtaining continuous line monitoring data for the line monitoring item within the monitoring period based on the execution time of the target single task and the quality index data of all target single tasks within the monitoring period, the method further includes:

[0030] If no line interruption alarm event is triggered, determine whether the average latency of multiple tasks in the continuous line monitoring data is greater than or equal to the third preset alarm threshold.

[0031] If the average latency of multiple consecutive tasks exceeds the threshold, an alarm event will be triggered if the threshold is greater than or equal to the third preset alarm threshold.

[0032] If no line interruption alarm event or multiple consecutive task average latency exceeding threshold alarm event is triggered, then determine whether there is at least one target single task quality indicator data where the single task latency is greater than or equal to the fourth preset alarm threshold.

[0033] If present, a latency exceeding the threshold alarm event will be triggered.

[0034] Optionally, after obtaining continuous line monitoring data for the line monitoring item within the monitoring period based on the execution time of the target single task and the quality index data of all target single tasks within the monitoring period, the method further includes:

[0035] Obtain the actual and theoretical data collection quantity for a single line monitoring task by the Simple Network Management Protocol (SMLP) collector within a preset time period.

[0036] If the actual number of samples collected is less than the theoretical number of samples collected, a data loss alarm event will be triggered.

[0037] Furthermore, to achieve the above objectives, the present invention also provides a network line quality monitoring device, the device comprising:

[0038] The monitoring task data acquisition module is used to acquire multiple single-line monitoring task data collected by the Simple Network Management Protocol (SRM) collector for the monitoring lines of access devices during the monitoring period.

[0039] The first data parsing module is used to determine the execution time of all target single tasks and the quality index data of all target single tasks corresponding to the same peer interface address data from multiple single line monitoring task data.

[0040] The second data parsing module is used to obtain continuous line monitoring data for the same peer interface address data, based on the target single task execution time and the quality index data of all target single tasks within the monitoring period.

[0041] In addition, to achieve the above objectives, the present invention also provides a network line quality monitoring device, the device comprising: a memory, a processor, and a network line quality monitoring program stored in the memory and executable on the processor, the network line quality monitoring program being configured to implement the steps of the network line quality monitoring method as described above.

[0042] In addition, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a network line quality monitoring program, which, when executed by a processor, implements the steps of the network line quality monitoring method described above.

[0043] This invention proposes a method for monitoring network line quality. The method includes: acquiring multiple single-time line monitoring task data collected by a Simple Network Management Protocol (SRM) collector for monitoring the access device during a monitoring period; determining the execution time of all target single tasks and the quality index data of all target single tasks corresponding to the same peer interface address data from the multiple single-time line monitoring task data; and obtaining continuous line monitoring data of the line monitoring item during the monitoring period based on the execution time of the target single tasks and the quality index data of all target single tasks within the monitoring period for the same peer interface address data.

[0044] Therefore, based on the peer interface address data in the line monitoring task data, the quality indicators and execution times of all target single tasks can be determined from multiple consecutive single line monitoring task data. Based on this, continuous line monitoring data such as the average packet loss rate and average latency within the monitoring period can be obtained, thus achieving effective monitoring of network anomalies such as continuous packet loss rate and sustained latency exceeding thresholds. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of the structure of a network line quality monitoring device for the hardware operating environment involved in the embodiments of the present invention;

[0046] Figure 2 This is a flowchart illustrating the first embodiment of the network line quality monitoring method of the present invention;

[0047] Figure 3 This is a flowchart illustrating the second embodiment of the network line quality monitoring method of the present invention;

[0048] Figure 4 This is a flowchart illustrating the third embodiment of the network line quality monitoring method of the present invention;

[0049] Figure 5 This is a flowchart illustrating the fourth embodiment of the network line quality monitoring method of the present invention;

[0050] Figure 6 This is a flowchart illustrating the fifth embodiment of the network line quality monitoring method of the present invention;

[0051] Figure 7 This is a flowchart illustrating Example 1 of the network line quality monitoring method of the present invention;

[0052] Figure 8 This is a flowchart illustrating Example 2 of the network line quality monitoring method of the present invention;

[0053] Figure 9 This is a flowchart illustrating Example 3 of the network line quality monitoring method of the present invention;

[0054] Figure 10 This is a schematic diagram of the architecture of Example 4 of the network line quality monitoring method of the present invention;

[0055] Figure 11 This is a schematic diagram of the functional modules of the first embodiment of the network line quality monitoring method of the present invention.

[0056] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0057] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0058] Analysis of relevant technologies reveals that current universal RPING monitoring methods typically rely on Telnet (Telnet Protocol, a text-based remote login protocol) or SSH (Secure Shell Protocol, a protocol for secure remote login and file transfer), AAA (Authentication, Authorization, Accounting) authentication services, or other authentication methods, as well as ICMP (Internet Control Message Protocol). This involves first logging into the network access device and then sending a certain number and size of probe packets to the peer according to the set PING parameters. The connectivity and quality of the line are determined by the number and timing of the response packets. The advantage of this method is that any network device supports the PING command, and most network devices support related protocols and authentication services for login, thus ensuring compatibility with most network devices. In this invention, the service that enables network device login, command issuance, and response reception via Telnet or SSH protocols, AAA authentication services, or other authentication methods is referred to as the device operation layer. The device operation layer can be used for remote operation and configuration acquisition of network devices.

[0059] Because RPING requires device login through the device operation layer for each command, and frequent logins consume significant device resources and performance, and may pose other potential risks, the upper limit of RPING's probe frequency is relatively low for security and device performance considerations. Typically, the upper limit for RPING data collection is around 3 minutes per attempt, sending approximately 20 probe packets per attempt. Higher frequencies and larger packet counts could impact device performance, potentially leading to security incidents or failure to complete within the probe interval. In today's high-concurrency, big data scenarios, a security configuration of 20 packets every 3 minutes is insufficient for effectively assessing line quality, and the collection frequency cannot meet emergency operation requirements. Typical RPING monitoring solutions use packet loss rate and latency metrics, setting thresholds to judge line quality, but these metrics lack flexibility. With a configuration of sending 20 probe packets per attempt, a single RPING task timeout is approximately 20 seconds. When multiple lines are interrupted, RPING collection tasks accumulate, and some RPING tasks may fail to execute within the collection period, resulting in empty data. RPING relies on the device operation layer, which in turn relies on AAA authentication services for SSH login to network devices. Failures in the device operation layer and AAA service can lead to a large number of lines failing to collect data during RPING, resulting in monitoring failure. In extreme cases, this can even affect RPING across all lines. The causes of line (network link) quality degradation may include carrier transmission equipment failure, last-mile line quality degradation, and failures in peer (partner) network equipment. Local network equipment metrics cannot directly detect line faults. Therefore, RPING, besides having low real-time performance when line monitoring is interrupted, also cannot effectively monitor line (network link) quality degradation due to insufficient data collection.

[0060] In summary, RPING monitoring cannot meet the requirements of many current scenarios for sensitivity, real-time performance, accuracy, and stability in line quality monitoring.

[0061] While all are ICMP-based PING command probes, most mainstream network devices offer periodic active probe functionality, such as NQA, IPSLA, and SQA technologies. NQA, SQA, and IPSLA can all initiate periodic PING probes by configuring parameters such as source and destination information of the probe link on the device, and all support collecting probe results via SNMP (Simple Network Management Protocol). However, due to the inconsistent technologies and functions supported by different vendors' network devices, the device configurations and parameters required to achieve the same monitoring effect vary greatly. Currently, there is no unified monitoring product or solution that is compatible with and adapts to these three mainstream probe functions (NQA, SQA, and IPSLA).

[0062] In view of the incompatibility of various testing techniques in related technologies and their inability to cope with complex scenarios such as continuous packet loss and network latency exceeding thresholds, this invention provides a method for monitoring network line quality.

[0063] The network line quality monitoring method, apparatus, device, and storage medium provided by the present invention will be described in detail below with reference to the accompanying drawings and through specific embodiments and implementation methods.

[0064] Reference Figure 1 , Figure 1 This is a schematic diagram of the network line quality monitoring device structure in the hardware operating environment involved in the embodiments of the present invention.

[0065] like Figure 1 As shown, the network line quality monitoring device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0066] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on network line quality monitoring equipment, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0067] like Figure 1 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a data storage module, a network communication module, a user interface module, and a network line quality monitoring program.

[0068] exist Figure 1 In the network line quality monitoring device shown, the network interface 1004 is mainly used for data communication with other devices; the user interface 1003 is mainly used for data interaction with users; the processor 1001 and memory 1005 in the network line quality monitoring device of the present invention can be set in the network line quality monitoring device. The network line quality monitoring device calls the network line quality monitoring program stored in the memory 1005 through the processor 1001 and executes the network line quality monitoring method provided in the embodiment of the present invention.

[0069] This invention provides a method for monitoring network line quality, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of a network line quality monitoring method according to the present invention.

[0070] In this embodiment, the network line quality monitoring method includes:

[0071] Step S500: Obtain monitoring time period and multiple single line monitoring task data collected by the Simple Network Management Protocol (SMAP) collector for the monitoring lines of the access devices.

[0072] Specifically, in the process of monitoring network line quality, each access device typically involves multiple network interfaces, and the network line corresponding to each network interface is a line monitoring item. Each time line monitoring task data is collected for a line monitoring item, a single line monitoring task data point is obtained. By continuously collecting line monitoring task data for the target line monitoring item, multiple single line monitoring task data points and monitoring time periods are obtained for subsequent analysis and processing.

[0073] The Simple Network Management Protocol (SNMP) data collector is used to periodically acquire line monitoring data according to a created scheduled task. Based on this, it iterates through the line monitoring items, initiates collection requests to the corresponding access devices, and obtains the collection results, i.e., the data for a single line monitoring task. The data collector can be any of the device data acquisition services using the SNMP protocol.

[0074] The data for a single network line monitoring task includes information such as the execution time of the single task, the execution sequence number of the collected task, the address of the peer interface connected to the access device, and the quality index data of the single task. The quality index data of the single task refers to the collected results corresponding to the network line quality monitoring indicators. In specific scenarios, the quality index data of the single task can be network quality monitoring indicators such as packet loss rate, latency, bandwidth, jitter, throughput, or network availability.

[0075] Step S600: From multiple single-line monitoring task data, determine the execution time of all target single tasks and the quality index data of all target single tasks corresponding to the same peer interface address data.

[0076] Specifically, after acquiring multiple consecutive single-line monitoring task data, the data is parsed to obtain a set of single-task quality indicator data. Based on the peer interface address in each single-line monitoring task data, the corresponding target single-task execution time and target single-task quality indicator data are retrieved from this set.

[0077] Furthermore, as one implementation method, step S600 specifically includes the following steps:

[0078] Step S610: Based on data from multiple single-line monitoring tasks, obtain the peer interface address result data and the single-task quality indicator result data;

[0079] Step S620: Traverse the peer interface address result data, determine all target acquisition result codes corresponding to the same peer interface address data, and obtain the first key-value pair;

[0080] Step S630: Based on the target acquisition result encoding, query the single task quality index result data to determine the execution time of all target single tasks and the single task quality index data of all targets corresponding to the same peer interface address data.

[0081] Specifically, in this embodiment, in order to obtain the target single task execution time and the target single task quality index data, it is necessary to first separate the peer interface address result data and the single task quality index result data from the single line monitoring task data.

[0082] Both the peer interface address result data and the single-task quality indicator result data exist in key-value pair format. The attribute keys for both data are collection result codes formed by concatenating multiple related collection result parameters using ".". These related collection result parameters can be at least one of the following: object identifier, character ASCII code of task configuration item parameter value, character ASCII code of single-dial test collection task name, collection task execution sequence number, or task type. Specifically, the attribute value for the peer interface address result data is the aforementioned peer interface address data, and the attribute value for the single-task quality indicator result data is the aforementioned single-task quality indicator data.

[0083] After separating the peer interface address result data and the single task quality indicator result data, all peer interface address result data are traversed to obtain all peer interface address data. The obtained peer interface address data is used as the attribute key, and the corresponding collection result number is used as the attribute value to construct the first key-value pair.

[0084] Traverse the first key-value pair to obtain the target acquisition result code list. Sort the target acquisition result codes in ascending order according to the acquisition task execution sequence number contained therein. Continue to traverse the sorted target acquisition result code list to obtain the target acquisition result code currently traversed. Use the target acquisition result code as the query condition to query the single task quality indicator result data and determine the execution time of all target single tasks and the quality indicator data of all target single tasks corresponding to the peer interface address data.

[0085] Step S700: For the same peer interface address data, based on the target single task execution time and the quality index data of all target single tasks within the monitoring period, obtain the continuous monitoring data of the line monitoring item during the monitoring period.

[0086] Specifically, after obtaining the execution time of all target single tasks and the quality index data of all target single tasks for the same peer interface address, the initial monitoring time of multiple consecutive tasks can be calculated based on the current system time. Then, the quality index data of all target single tasks between the initial monitoring time and the current time is obtained, and the average value is taken to obtain the corresponding continuous monitoring data of the line.

[0087] For example, in a specific application scenario, the prerequisite for this method to be executed is that all access devices have completed the SNMP protocol function, completed the configuration of the SNMP collector service IP, supported SNMP protocol version, unified SNMP community name, and completed the network communication policy between the device and the SNMP collector.

[0088] The dial-up SNMP collector creates a scheduled task according to the set SNMP collection frequency. It periodically obtains the latest dial-up configuration status of "successfully distributed" line monitoring item data, traverses the line monitoring items, and sends SNMP collection requests to the device and receives the collection results in response, based on the given OID, access device information, and SNMP community name and SNMP version number and other unified SNMP protocol configurations. Then, it encapsulates the single task execution time, the current line monitoring item data traversed, and the collection results, and finally transmits them to the dial-up data consumption service for processing through an interface or message middleware such as Kafka.

[0089] In this method, the OIDs that need to be collected for each type of device are as follows:

[0090] NQA (Category 1) requires the collection of the following OID groups:

[0091]

[0092] NQA (Category 2) requires the collection of the following OID groups:

[0093] 1.3.6.1.4.1.25506.8.3.1.11.1.3 hh3cNqaStatResIpTargetAddress Destination address 1.3.6.1.4.1.25506.8.3.1.11.1.6 hh3cNqaStatResAverageRtt Average latency 1.3.6.1.4.1.25506.8.3.1.11.1.19 hh3cNqaStatResLostPacketRatio Packet loss rate

[0094] IPSLA requires the collection of the following OID groups:

[0095]

[0096] SQA needs to collect the following OID groups:

[0097]

[0098] In addition, a data collection result database can be set up in the network line quality monitoring system to store single-task quality indicator data, such as single task execution time, line monitoring item data, task execution sequence number, latency (D), and packet loss rate (LR). The collected data is consumed through a listening interface or message middleware. After consuming the data, it is parsed to separate the line monitoring items and the collection results. Specifically, the following steps are included:

[0099] Regarding the data acquisition results from NQA (Category 1) devices:

[0100] Step 1: Extract the collection results of three metrics from the collected data: nqaResultsAddress, nqaResultsRttAvg, and nqaResultsLostPacketRatio. Each of these results is a key-value pair with the following key: OID, the ASCII encoding of the NQA task's test-instance configuration parameter value (set to "admin" in this example), the ASCII encoding of the collection task name, the collection task execution sequence number, and a collection result ID (an integer task type concatenated with "."). The value is the corresponding metric's collection result. Specifically, nqaResultsAddress uses the target interface address configured in the task as its value, nqaResultsRttAvg uses the average latency in milliseconds as its value, and nqaResultsLostPacketRatio uses the integer packet loss rate as its value.

[0101] Step 2: Iterate through the nqaResultsAddress collection results and construct a key-value pair data IP_IDS_MAP with the target interface address as the KEY and the collection result ID as the VALUE.

[0102] Step 3: Traverse the key-value pair IP_IDS_MAP to obtain the collection result ID list for each target interface address. Sort the collection result ID list from low to high according to the collection task execution sequence number contained in each ID. Continue to traverse the sorted collection result ID list, obtain the collection result ID currently traversed, and use the collection result ID as the KEY to query the two key-value pairs nqaResultsRttAvg and nqaResultsLostPacketRatio to obtain the single task quality index data.

[0103] Regarding the data collection results from NQA (Category II) devices:

[0104] Step 1: Extract the collection results of three metrics from the collected data: hh3cNqaStatResIpTargetAddress, hh3cNqaStatResAverageRtt, and hh3cNqaStatResLostPacketRatio. Each of these three results is a key-value pair with the following key: the ASCII encoding of the OID, the NQA task entry configuration parameter value (set to "admin" in this example), the ASCII encoding of the collection task name, and the collection task execution sequence number concatenated with ".". The value is the corresponding metric collection result. Among them, hh3cNqaStatResIpTargetAddress is followed by the destination address configured for the NQA task with the data type prefix "STRING:", hh3cNqaStatResAverageRtt is followed by the average latency in milliseconds with the data type prefix "Gauge32:", and hh3cNqaStatResLostPacketRatio is followed by the integer packet loss rate with the data type prefix "Gauge32:".

[0105] Step 2: Iterate through the hh3cNqaStatResIpTargetAddress collection results and construct a key-value pair data IP_IDS_MAP with the destination address as the KEY and the collection result ID list as the VALUE.

[0106] Step 3: Traverse the key-value pair IP_IDS_MAP to obtain the collection result ID list for each destination IP. Sort the collection result ID list from low to high according to the collection task execution sequence number contained in each ID. Continue to traverse the sorted collection result ID list, obtain the collection result ID currently traversed, and use the collection result ID as the KEY to query the two key-value pairs hh3cNqaStatResAverageRtt and hh3cNqaStatResLostPacketRatio to obtain the single task quality index data.

[0107] Regarding the acquisition results from the IPSLA device:

[0108] Step 1: Extract the collection results of three metrics from the collected data: rttMonHistoryCollectionAddress, rttMonHistoryCollectionCompletionTime, and ttMonHistoryCollectionSense. Each of these results is a key-value pair, with the key consisting of the OID, the collection task name (integer), the collection task execution sequence number (i.e., the number of task executions), and a fixed separator number concatenated with ".", and the value being the corresponding metric's collection result. Specifically, rttMonHistoryCollectionAddress uses the destination address configured for the IPSLA task (hexadecimal encoded and separated by colons) as its value; rttMonHistoryCollectionCompletionTime uses the average latency in milliseconds as its value; and ttMonHistoryCollectionSense uses the integer packet loss status value as its value.

[0109] Step 2: Iterate through the rttMonHistoryCollectionAddress collection results and construct a key-value pair data IP_IDS_MAP with the destination address as the KEY and the collection result ID list as the VALUE.

[0110] Step 3: Traverse the key-value pair IP_IDS_MAP to obtain the collection result ID list for each destination IP address. Sort the collection result ID list from low to high according to the collection task execution sequence number contained in each ID. Continue traversing the sorted collection result ID list, obtain the currently traversed collection result ID, and use the collection result ID as the key to query the two key-value pairs rttMonHistoryCollectionCompletionTime and ttMonHistoryCollectionSense to obtain the single task quality indicator data.

[0111] Regarding the data collected by the SQA device:

[0112] Step 1: Extract the collection results of four metrics from the collected data: sqaTestIcmpResultDesIP, sqaTestIcmpResultAvgRTT, sqaTestIcmpResultPacketLossRate, and sqaTestIcmpResultProbeTime. Each of the four results is a key-value pair, with the OID (Operation ID) and the ASCII code of the collection task name concatenated with "." as the key, and the corresponding metric's collection result as the value. Specifically, sqaTestIcmpResultDesIP uses the destination address configured in the SQA task as its value; sqaTestIcmpResultAvgRTT uses the average latency in milliseconds as its value; sqaTestIcmpResultPacketLossRate uses the integer packet loss rate followed by a % suffix as its value; and sqaTestIcmpResultProbeTime uses a date and time string in the format "yyyy-MM-dd HH:mm:ss" as its value.

[0113] Step 2: Iterate through the sqaTestIcmpResultDesIP collection results and construct a key-value pair data IP_IDS_MAP with the destination address as the KEY and the collection result ID list as the VALUE.

[0114] Step 3: Traverse the key-value pair IP_IDS_MAP to obtain the collection result ID list for each destination IP. Sort the collection result ID list from low to high according to the collection task execution sequence number contained in each ID. Continue to traverse the sorted collection result ID list, obtain the collection result ID currently traversed, and use the collection result ID as the KEY to query the three key-value pairs sqaTestIcmpResultAvgRTT, sqaTestIcmpResultPacketLossRate, and sqaTestIcmpResultProbeTime to obtain the single task quality indicator data.

[0115] The single-task quality metrics include latency (D) and packet loss rate (LR). The task configuration parameters include the probe task frequency (F) and the number of statistical tasks (C) for calculating the average packet loss rate of multiple consecutive tasks. avgloss The statistical number of tasks C with average latency of multiple consecutive tasks. avgdelay The continuous monitoring data for the line includes the average packet loss rate (LR) for multiple consecutive tasks. avg and the average latency D of multiple consecutive tasks avg .

[0116] Get the current system time T nowThe starting time T of the average packet loss rate for multiple consecutive tasks can be calculated using Formula 1. avgloss .

[0117] Formula 1 is: T avgloss =T now -F*C avgloss ;

[0118] Among them, T avgloss To calculate the start time of the average packet loss rate for multiple consecutive tasks, T now Where is the current system time, F is the frequency of the detection mission, and C is the system current time. avgloss This is the number of tasks that represent the average packet loss rate across multiple consecutive tasks.

[0119] The start time T of the average latency of multiple consecutive tasks can be calculated using Formula 2. avgdelay .

[0120] Formula 2 is: T avgdelay =T now -F*C avgdelay ;

[0121] Among them, T avgdelay To calculate the start time of the average latency of multiple consecutive tasks, T now Where is the current system time, F is the frequency of the detection mission, and C is the system current time. avgloss This represents the number of statistical tasks with the average latency of multiple consecutive tasks.

[0122] Based on the calculated T avgloss and T now Query the database of collected results to find single task execution times that fall within this time period, and obtain T. avgloss To T now The average packet loss rate (LR) for multiple consecutive tasks is obtained by averaging all packet loss rate values ​​between these values. avg .

[0123] Based on the calculated T avgdelay and T now Query the database of collected results to obtain T avgdelay To T now The average of all latency values ​​between these values ​​is taken to obtain the average latency D for multiple consecutive tasks. avg .

[0124] In this embodiment, by parsing and processing the data of multiple consecutive single-line monitoring tasks within the monitoring period, the corresponding target single-task quality index data and the execution time of the target single task are obtained. Based on this, the continuous monitoring data of the line within the monitoring period is obtained by converting it according to a preset conversion method. This allows for the monitoring of network line quality indicators such as the average packet loss rate and average latency of the network line within the continuous monitoring period, thereby achieving effective monitoring of network anomalies such as continuous packet loss rate and continuous latency exceeding the threshold.

[0125] Furthermore, a second embodiment is proposed based on the first embodiment, with reference to... Figure 3 , Figure 3 This is a flowchart illustrating a second embodiment of a network line quality monitoring method according to the present invention.

[0126] In this embodiment, before step S500, the method includes:

[0127] Step S100: Obtain the line monitoring item data, dial the global configuration parameters and alarm indicator data.

[0128] Step S200: Determine the dial-up test configuration template and dial-up test task check instruction corresponding to the application technology type of the access device.

[0129] Step S300: Based on the line monitoring item data, global dial test configuration parameters, and alarm indicator data, fill in the dial test configuration template to obtain the dial test task configuration content for the line monitoring item.

[0130] Step S400: Send the configuration content of the single line monitoring task and the check instruction of the single line monitoring task to the access device through the device operation layer.

[0131] Understandably, access devices are usually from different brands and use different technologies. In order to achieve unified monitoring of the quality of all network lines, it is necessary to select the corresponding dial-up test task configuration template for each type of device, fill the parameters of the dial-up test task configuration template according to the line monitoring item data, and obtain the respective dial-up test task configuration content for subsequent dial-up test task configuration content distribution operations.

[0132] Therefore, it can be seen that by generating dial-up test task configuration content based on the corresponding dial-up test configuration template for access devices that use different technologies, the underlying differences between the different technologies can be masked, and unified monitoring of different access devices can be achieved.

[0133] For example, in a specific application scenario, the line monitoring data includes the line's unique identifier, line description, access device IP, access device brand and model, access interface IP, peer interface IP, and interface VPN instance name. The global configuration parameters for dialing include the probe task frequency F (including task execution time, default value 60 seconds), the number of probe packets N (i.e. the number of PING packets sent, default value 50), and the packet sending interval T (default value 1 second). The alarm indicator data includes single task packet loss rate, single task latency, average packet loss rate of multiple consecutive tasks, average latency of multiple consecutive tasks, and whether the line is interrupted.

[0134] The configuration templates for the testing tasks involved include:

[0135] NQA (Category 1) Configuration Template:

[0136] nqa test-instance admin [Task Name] test-type icmp Records result 10 destination-address ipv4 [peer interface IP] source-address ipv4 [interface IP] interval seconds [NQA packet sending interval] timeout [NQA packet sending interval] probe-count [NQA probe packet count] [vpn-instance [VPN instance name]] frequency [NQA probe frequency] Start now commit quit quit save Y

[0137] NQA (Category 2) Configuration Template:

[0138] nqa entry admin [Task Name] type icmp-echo destination ip [peer interface IP] Source IP [Interface IP] probe count [NQA probe packet count] probe timeout [NQA packet sending interval] frequency [NQA probe frequency] system-view history-record enable history-record number 10 [vpn-instance [VPN instance name]] quit nqa schedule admin [Task Name] start-time now lifetime forever return save force

[0139] IPSLA (IOS-XR) configuration template:

[0140]

[0141]

[0142] IPSLA (IOS-XE) configuration template:

[0143] IP SLA [Task Name] icmp-echo [peer interface IP] source-ip [interface IP] icmp-echo [peer interface IP] source-ip [interface IP] [vrf [VPN instance name]] threshold [IPSLA packet sending interval] timeout [IPSLA packet sending interval] frequency [IPSLA packet interval] history lives-kept 1 history buckets-kept [IPSLA probe packet count] history filter all IP SLA Schedule [Task Name] Life Forever Start-Time Now end write

[0144] SQA configuration template:

[0145]

[0146]

[0147] The placeholder parameters are marked with 【】 and need to be completed based on the data from the line monitoring items. The optional configuration items are marked with []. The configuration content of [] is generated only when the placeholder parameter in [] exists; otherwise, the entire configuration item in [] is an empty string.

[0148] Specifically: [Task Name] retrieves the value of the "Task Name" field from the line monitoring item; [Peer Interface IP] retrieves the value of the "Peer Interface IP" field from the line monitoring item; [Interface IP] retrieves the value of the "Access Interface IP" field from the line monitoring item; [VPN Instance Name] retrieves the value of the "VPN Instance Name" field from the line monitoring item; [NQA Packet Sending Interval] retrieves the packet sending interval parameter T from the line monitoring item's testing configuration and alarm parameter group; [NQA Probe Task Frequency] retrieves the probe task frequency parameter F from the line monitoring item's testing configuration and alarm parameter group; [NQA Probe Packet Count] retrieves the number of probe packets N from the line monitoring item's testing configuration and alarm parameter group; [NQA Packet Sending Interval] retrieves the packet sending interval parameter T*1000 from the line monitoring item's testing configuration and alarm parameter group; [NQA Probe Task Frequency]... The parameters are: [F*1000] (probe frequency parameter in the line monitoring item test configuration and alarm parameter group); [NQA probe packet count] (probe packet count parameter N in the line monitoring item test configuration and alarm parameter group); [IPSLA packet interval] (transmit packet interval parameter T in the line monitoring item test configuration and alarm parameter group); [IPSLA probe packet count] (probe packet count parameter N in the line monitoring item test configuration and alarm parameter group); [SQA packet interval] (transmit packet interval parameter T*1000 in the line monitoring item test configuration and alarm parameter group); [SQA probe task frequency] (probe task frequency parameter F in the line monitoring item test configuration and alarm parameter group); [SQA probe packet count] (probe packet count parameter N in the line monitoring item test configuration and alarm parameter group).

[0149] Each line monitoring item has a configuration template determined based on the equipment brand and model. Then, the configuration parameters are filled in according to the above value relationships, thus generating the configuration content for that monitoring item.

[0150] Similarly, after the configuration content is generated, select the corresponding dial-up test task check command based on the device brand and model. The dial-up test task check command and the method for determining whether the task exists include the following:

[0151] NQA (Type 1) inspection commands:

[0152] The command to check is: "display nqa result test-instance admin [task name]", where [task name] is the value of the test task name field in the line monitoring item.

[0153] Method to determine if a task exists: Parse the command execution echo and check if it contains the string "testflagis active". If it does, the task already exists.

[0154] NQA (Category 2) inspection commands:

[0155] The command to check is: "display nqa result admin [task name]", where [task name] is the value of the "task name" field in the line monitoring item.

[0156] Method to determine if a task exists: Parse the command execution echo and check if it contains the string "Lastsucceeded probe time". If it does, the task already exists.

[0157] IPSLA (IOS-XR) inspection command:

[0158] The command to check is: "show ipsla statistics".

[0159] Method for determining if a task exists: Parse the command execution echo and check if it contains the string "Entrynumber: [Task Name]". If it does, the task already exists, where [Task Name] is the value of the "Dial Test Task Name" field in the line monitoring item.

[0160] IPSLA (IOS-XE) check command:

[0161] The command to check is: "show ip sla summary".

[0162] Method for determining if a task exists: Parse the command execution echo and check if it contains the string "*[task name]". If it does, the task already exists, where [task name] is taken from the value of the line monitoring item dial test task name field.

[0163] SQA check command:

[0164] The command to check is: "show running-config sqa".

[0165] The method for determining whether a task exists is as follows: Parse the command execution echo and check if it contains the string "sqa-test [task name]". If it does, the task already exists, where [task name] is taken from the value of the "Dial Test Task Name" field of the line monitoring item.

[0166] The different testing technologies correspond to the following OID groups, different testing task configuration templates, and different testing task check commands:

[0167] The NQA (Category 1) probing technology corresponds to the OID groups that NQA (Category 1) needs to collect, the NQA (Category 1) configuration template, and the NQA (Category 1) check commands.

[0168] The NQA (Category 2) probing technology corresponds to the OID groups that NQA (Category 2) needs to collect, the NQA (Category 2) configuration template, and the NQA (Category 2) check commands.

[0169] The IPSLA (IOS-XR) probing technology corresponds to the OID groups that IPSLA needs to collect, the IPSLA (IOS-XR) configuration template, and the IPSLA (IOS-XR) check commands.

[0170] The IPSLA (IOS-XE) probing technology corresponds to the OID groups that IPSLA needs to collect, the IPSLA (IOS-XE) configuration template, and the IPSLA (IOS-XE) check commands.

[0171] SQA testing technology includes the OID groups that SQA needs to collect, SQA configuration templates, and SQA check commands.

[0172] Furthermore, step S400 specifically includes:

[0173] Step S410: Send a test task check command to the access device through the device operation layer.

[0174] Step S420: If the execution echo of the dial test task check command is obtained, determine whether there is a task with the same name as a single line monitoring task based on the execution echo.

[0175] Step S430: If it does not exist, the test task configuration content is sent to the access device through the device operation layer, and the process returns to step S410.

[0176] Step S440: If it exists, then it is confirmed that the single dial test task was successfully configured on the access device.

[0177] Specifically, the corresponding test task configuration content is sent to each access device one by one until all test task configuration content has been sent. During the sending process, a test task check command needs to be sent. The execution echo of the command is used to verify whether a task with the same name as a single line monitoring task exists in the access device. If it exists, it means that the corresponding test task configuration content has been sent successfully. The device operation layer uses Telnet or SSH protocols, AAA authentication service, or other authentication methods to achieve network device login, command sending, and echo reception.

[0178] Therefore, by verifying the existence of a single line monitoring task with the same name in the access device through the execution echo of the dial test task check command, the distribution status of the dial test task configuration content is determined and returned, thus realizing the automatic distribution of the dial test task configuration content.

[0179] In a specific application scenario, the process of generating and automatically distributing test configurations is as follows: Figure 7 As shown. The specific distribution and verification steps are as follows:

[0180] Step 1: Obtain the line monitoring item information and the generated dial test configuration content and dial test task check commands based on it.

[0181] Step 2: Send a test task check command to the access device through the device operation layer. If the sending fails, terminate and return the error content and "sending failed" status value to the device operation layer. If the sending is successful, obtain the command execution echo content, parse and determine whether the device already has a running task with the same name as the monitoring task. If it exists, terminate the sending and return the "sending successful" status value. If it does not exist, continue.

[0182] Step 3: Send the test task configuration content to the access device through the device operation layer. If the sending fails, the process will terminate and return the error message and "sending failed" status value to the device operation layer. If the sending is successful, the process will continue.

[0183] Step 4: Send a task check command to the access device through the device operation layer. If the sending fails, terminate the process and return the error message and "successful sending" status value to the device operation layer. If the sending is successful, obtain the command execution echo content, parse and determine whether the device already has a running task with the same name as the monitoring task. If it exists, terminate the sending and return the "successful sending" status value. If it does not exist, return the "successful sending" status value.

[0184] Step 5: For line monitoring items that have obtained the "successful delivery" status value, update their dial-up test configuration status to "successful delivery". For line monitoring items that have obtained the "failed delivery" status value, update their dial-up test configuration status to "failed delivery".

[0185] Step 6: Check the dial-up configuration content generated by the line monitoring item and the status of the access device when the dial-up configuration status is "failed to be sent". Retry automatic sending or manual configuration.

[0186] Furthermore, a third embodiment is proposed based on the first embodiment, with reference to... Figure 4 , Figure 4 This is a flowchart illustrating a third embodiment of a network line quality monitoring method according to the present invention.

[0187] In this embodiment, after step S700, the method further includes:

[0188] Step a1: If the packet loss rate of a single task in at least one target single task quality indicator data is 100%, then a line interruption alarm event is triggered.

[0189] Step a2: If no line interruption alarm event is triggered, determine whether the average packet loss rate of multiple tasks in the continuous line monitoring data is greater than or equal to the first preset alarm threshold.

[0190] Step a3: If the value is greater than or equal to the first preset alarm threshold, then trigger an alarm event where the average packet loss rate of multiple consecutive tasks exceeds the threshold.

[0191] Step a4: If no line interruption alarm event or multiple consecutive tasks average packet loss rate exceeding threshold alarm event is triggered, determine whether the packet loss rate of a single task is greater than or equal to the second preset alarm threshold.

[0192] Step a5: If the packet loss rate is greater than or equal to the second preset alarm threshold, then trigger the packet loss rate exceeding the threshold alarm event.

[0193] Understandably, network line quality issues typically include line outages, single-task packet loss, and continuous task packet loss. In this embodiment, a line outage is determined by checking if the single-task packet loss rate is 100%. If the line is not outage, the calculated multi-task average packet loss rate is compared with a first preset alarm threshold to determine if a continuous multi-task average packet loss rate exceeding the threshold alarm event is triggered. If neither of the above occurs, the single-task packet loss rate is compared with a second preset alarm threshold to determine if a packet loss rate exceeding the threshold alarm event is triggered.

[0194] Therefore, by using the first preset alarm threshold and the second preset alarm threshold as the judgment criteria, and analyzing and comparing the packet loss rate of a single task and the average packet loss rate of multiple tasks, it is possible to effectively monitor network line quality problems such as line interruption, single-task packet loss, and continuous task packet loss.

[0195] Furthermore, a fourth embodiment is proposed based on the first embodiment, with reference to... Figure 5 , Figure 5 This is a flowchart illustrating the fourth embodiment of a network line quality monitoring method according to the present invention.

[0196] In this embodiment, after step S700, the method includes:

[0197] Step b1: If no line interruption alarm event is triggered, determine whether the average delay of multiple tasks in the continuous line monitoring data is greater than or equal to the third preset alarm threshold.

[0198] Step b2: If the value is greater than or equal to the third preset alarm threshold, then trigger an alarm event where the average latency of multiple consecutive tasks exceeds the threshold.

[0199] Step b3: If no line interruption alarm event or multiple consecutive task average latency exceeding threshold alarm event is triggered, determine whether there is at least one target single task quality indicator data where the single task latency is greater than or equal to the fourth preset alarm threshold.

[0200] Step b4: If it exists, trigger a latency exceeding the threshold alarm event.

[0201] Understandably, network line quality issues, in addition to the aforementioned problems, typically include single-task latency and continuous-task latency. In this embodiment, if the line is not interrupted, the calculated average latency of multiple tasks is compared with a third preset alarm threshold to determine whether a continuous multiple-task average latency exceeding the threshold alarm event is triggered. If the line is not interrupted and no continuous multiple-task average latency exceeding the threshold alarm event is triggered, the latency of a single task is compared with a fourth preset alarm threshold to determine whether a latency exceeding the threshold alarm event is triggered.

[0202] Therefore, by using the third and fourth preset alarm thresholds as judgment criteria, and analyzing and comparing the latency of a single task and the average latency of multiple tasks, effective monitoring of network line quality issues such as latency of a single task and latency of continuous tasks can be achieved.

[0203] In a specific application scenario, the alarm and recovery logic process for line quality monitoring indicators is as follows: Figure 8 As shown. The specific event alerting steps are as follows:

[0204] Retrieve the parameters from the current line monitoring item dial test configuration parameter group: single task packet loss rate alarm threshold TH loss and over-threshold alarm level L loss Single-task latency alarm threshold TH delay and over-threshold alarm level L delay The number of tasks C that calculate the average packet loss rate across multiple consecutive tasks. avgloss Alarm threshold TH avgloss and over-threshold alarm level L avgloss The number of tasks C with average latency across multiple consecutive tasks. avgdelay Alarm threshold TH avgdelay and over-threshold alarm level L avgdelay Line interruption alarm level L down Among them, the alarm threshold TH for the average packet loss rate of multiple consecutive tasks. avgloss This is the first preset alarm threshold, the single-task packet loss rate alarm threshold TH. loss This is the second preset alarm threshold, the average latency alarm threshold TH for multiple consecutive tasks. avgdelay This is the third preset alarm threshold.

[0205] Determine if the packet loss rate is 100%. If so, encapsulate the single task execution time, line monitoring data, and packet loss rate (LR) and push it to L. downThe system detects line outage alarm events and records the event information in the event cache database. The data item is set to time out after 24 hours, or automatically cleared via a scheduled task after 24 hours. If not, the system queries the event cache database for all historical line outage alarm events for that line monitoring item. If the query result is not empty, these cached historical line outage alarm events are cleared. The system then encapsulates the single task execution time, line monitoring item data, and packet loss rate (LR) before pushing the line outage recovery event.

[0206] If no line interruption alarm event is triggered, then the average packet loss rate (LR) of multiple consecutive tasks is determined. avg Does it exceed the threshold TH? avgloss If so, then the single task execution time, line monitoring data, and average packet loss rate (LR) of multiple consecutive tasks will be included. avg Push L after encapsulation avgloss An alarm event indicating that the average packet loss rate of multiple consecutive tasks exceeds a threshold is triggered. This event information is recorded in the event cache database, and the data item is set to time out after 24 hours, or automatically cleared after 24 hours via a scheduled task. If not, the event cache database is queried for all historical alarm events related to the average packet loss rate of multiple consecutive tasks for this line monitoring item. If the query result is not empty, these cached historical alarm events are cleared, and the single task execution time, line monitoring item data, and average packet loss rate (LR) of multiple consecutive tasks are updated. avg After encapsulation, push the recovery event when the average packet loss rate of multiple consecutive tasks exceeds the threshold.

[0207] If no line interruption alarm event or multiple consecutive tasks' average packet loss rate exceeding the threshold alarm event is triggered, then determine whether the packet loss rate LR exceeds the threshold TH. loss If so, the single task execution time, line monitoring data, and packet loss rate (LR) will be encapsulated and pushed to L. loss The system will generate a packet loss rate exceeding the threshold alarm event. Simultaneously, this event information will be recorded in the event cache database, and the data item will be set to time out after 24 hours or automatically cleared after 24 hours via a scheduled task. If not, the system will query the event cache database for all historical packet loss rate exceeding the threshold alarm events for this line monitoring item. If the query result is not empty, these cached historical alarm events will be cleared, and the single task execution time, line monitoring item data, and packet loss rate LR will be encapsulated and pushed as a packet loss rate exceeding the threshold recovery event.

[0208] If no line interruption alarm event is triggered, then the average delay D of multiple consecutive tasks is determined. avg Does it exceed the threshold TH? avgdelay If so, then the single task execution time, line monitoring data, and average latency D of multiple consecutive tasks will be included. avg Push L after encapsulation avgdelayThe system detects alarm events where the average latency of multiple consecutive tasks exceeds a threshold and records the alarm information in the event cache database. If not, it queries the event cache database for all historical alarm events with average latency of multiple consecutive tasks for that line monitoring item. If the query result is not empty, it clears these cached historical alarm events and records the single task execution time, line monitoring item data, and average latency of multiple consecutive tasks (D). avg After encapsulation, push the recovery event when the average latency of multiple consecutive tasks exceeds the threshold.

[0209] If neither the line interruption alarm event nor the average latency alarm event for multiple consecutive tasks is triggered, then determine whether the latency D exceeds the threshold TH. delay If so, the single task execution time, line monitoring data, and latency D will be encapsulated and pushed to L. delay The system will detect latency exceeding the threshold alarm event and record the event information in the event cache database. The data item will be set to time out after 24 hours or be automatically cleared after 24 hours via a scheduled task. If not, the system will query the event cache database for all historical latency exceeding the threshold alarm events for this line monitoring item. If the query result is not empty, the system will clear these cached historical alarm events and encapsulate the single task execution time, line monitoring item data, and latency D before pushing the latency exceeding the threshold recovery event.

[0210] Furthermore, a fifth embodiment is proposed based on the first embodiment, with reference to... Figure 6 , Figure 6 This is a flowchart illustrating the fifth embodiment of a network line quality monitoring method according to the present invention.

[0211] In this embodiment, after step S700, the method includes:

[0212] Step S800: Obtain the actual and theoretical number of data collected by the Simple Network Management Protocol (SMMP) collector for a single line monitoring task within a preset time period.

[0213] Step S900: If the actual number of samples collected is less than the theoretical number of samples collected, a data loss alarm event is triggered.

[0214] It is understandable that, in the process of monitoring network line quality, in addition to the aforementioned quality issues, there may also be cases of lost data collection. In this embodiment, the theoretical number of data collected in a single line monitoring task within the monitoring period can be calculated based on the frequency of the detection task. By comparing the theoretical number of data collected with the actual number of data collected, it can be determined whether there are any cases of lost data collection, thereby triggering an alarm event for missing data collected during dial-up testing. This achieves effective monitoring of scenarios where dial-up testing data collection is missing.

[0215] In a specific application scenario, the logic flow for continuous detection alarm acquisition is as follows: Figure 9 As shown, a scheduled task is created to retrieve the latest monitoring data for lines with a "successfully deployed" configuration status every 5 minutes. For each line monitoring item, the task iterates through the database and queries the number N of data collection results actually recorded for that item within the last five minutes. record Obtain the detection task frequency F from the line monitoring item dialing configuration parameter group, calculate (5*60) / F and round up to obtain the number N of data collection results to be recorded. th Calculate N th -N record The number of missing results N is obtained. loss If N loss If the value is greater than 0, it indicates that there is missing data. The current time, the data for the line monitoring items, and the actual number of recorded data points N should be considered. record The number of data collection results N to be recorded th and the number of missing results N loss After encapsulation, push ALERT-level alarm events for missing test data collection.

[0216] In addition, to achieve high availability of the entire network line quality monitoring method, the collectors are deployed in a multi-active deployment, with each collector serving as a backup for the others; the collection results are transmitted in a distributed manner, with each transmission path serving as a backup for the others; and the dial-up test data consumption service is deployed in a multi-active deployment, with each dial-up test data consumption service serving as a backup for the others.

[0217] In a specific application scenario, the architecture of a high-availability line quality monitoring system is as follows: Figure 10 As shown. Specifically, high availability deployment includes the following aspects:

[0218] The SNMP collectors employ a server cluster for multi-active deployment, enabling the creation and execution of collection tasks for each monitored line item at a set collection task frequency (1 minute by default in this example). Before creating a collection task, each collector queries a Redis database for existing collection task records, then creates a new collection task not already in the record, records it in the Redis database, and sets a timeout equal to the collection task frequency (1 minute by default in this example). This allows for preemptive load balancing within the multi-active cluster, ensuring that the creation and collection of tasks are not affected if any service becomes unavailable.

[0219] For high availability, distributed Kafka is used to transmit the collected results. During transmission, each SNMP collector creates a producer to produce data to the same Kafka topic. During consumption, all data consumption and processing services use the same group ID to consume data from the aforementioned topic, and the Kafka server handles the load balancing of the data.

[0220] The data consumption and processing service is deployed in a multi-active manner in containers or server clusters. When any one service is unavailable, the other services can still consume data for analysis and processing.

[0221] The MySQL, Elasticsearch, and Redis database middleware used all support high availability by building a distributed cluster.

[0222] To enable those skilled in the art to better understand the scope of protection of the claims of this application, specific implementation examples in specific application scenarios are used to explain and illustrate the technical solutions described in the claims of this application. It should be understood that the following examples are only used to explain this application and are not intended to limit the scope of protection of the claims of this application.

[0223] In a network line quality monitoring scenario, the network access devices include device A and device B. Searching for relevant information based on the brand and model of device A and device B reveals that device A uses NQA technology, while device B uses SQA technology. By filling in configuration parameters based on the NQA configuration template, the test task configuration for each line monitoring item of device A is obtained; similarly, by filling in configuration parameters based on the SQA configuration template, the test task configuration for each line monitoring item of device B is obtained. Therefore, the underlying technical differences between device A and device B can be masked, achieving unified configuration and equivalent monitoring results.

[0224] For devices A and B, select the corresponding test task check commands and send them to both devices. Devices A and B execute the commands and return the execution results. Based on the results, determine if a test task with the same name as the configured test task exists on devices A and B. If not, send the corresponding test task configuration to both devices. Then, send the test task check commands to devices A and B again to verify if a test task with the same name exists. If it exists, the test task configuration has been successfully sent. This allows for the automatic generation and sending of test task configurations.

[0225] The system utilizes clustered data collectors to send collection requests to devices A and B based on collection needs, acquiring multiple single-task network line monitoring data. These data are then packaged using distributed middleware and sent to a clustered test data consumption service for processing. This process determines the packet loss rate, latency, and execution time of all target single tasks corresponding to the same peer interface address in either device A or device B. Simultaneously, all acquired single-task data is stored in the collection results database. Finally, the average packet loss rate and latency of consecutive tasks are calculated based on the packet loss rate, latency, and execution time of all target single tasks. By employing clustered data collectors, a clustered test data consumption service, and distributed middleware, the reliability of these components is improved, thereby achieving high availability for the network line quality monitoring system.

[0226] The single-task packet loss rate, single-task latency, average packet loss rate of multiple consecutive tasks, and average latency of multiple consecutive tasks are packaged and sent to the event alarm system. The event alarm system includes an event cache database to store historical alarm events. If an alarm event is stored for more than a preset time, the corresponding alarm event will be deleted from the event cache database. The single-task packet loss rate, single-task latency, average packet loss rate of multiple consecutive tasks, and average latency of multiple consecutive tasks are compared with corresponding set thresholds. If the average packet loss rate of multiple consecutive tasks for line monitoring item M is greater than the average packet loss rate alarm threshold for multiple consecutive tasks, a "multiple-task average packet loss rate exceeding threshold" event is pushed. If the average packet loss rate of multiple consecutive tasks for line monitoring item M is less than or equal to the average packet loss rate alarm threshold for multiple consecutive tasks, all "multiple-task average packet loss rate exceeding threshold" events for line monitoring item M are queried and cleared from the event cache database, and a "multiple-task average packet loss rate exceeding threshold recovery" event is pushed. Similarly, there are also situations such as single-task packet loss rate, single-task latency, average latency exceeding the threshold for multiple consecutive tasks, and line interruption. The corresponding event push methods are the same as above, and will not be elaborated here. Thus, monitoring and alarms can be implemented for various scenarios such as latency exceeding the threshold, packet loss rate exceeding the threshold, continuous packet loss, continuous latency exceeding the threshold, and line interruption.

[0227] At the same time, the theoretical number of data collection results for device A and device B within the monitoring period is calculated based on the set collection frequency. The corresponding actual number of data collection results is then queried from the data collection result database. If the theoretical number of data collection results is less than the actual number of data collection results, a data collection missing alarm event is pushed, thereby enabling self-monitoring of data collection continuity.

[0228] Ultimately, unified monitoring of the line quality of device A, which uses NQA technology, and device B, which uses SQA technology, was achieved.

[0229] Furthermore, to achieve the above objectives, the present invention also provides a network line quality monitoring device, which may include:

[0230] The monitoring task data acquisition module is used to acquire multiple single-line monitoring task data collected by the Simple Network Management Protocol (SRM) collector for the monitoring lines of access devices during the monitoring period.

[0231] The first data parsing module is used to determine the execution time of all target single tasks and the quality index data of all target single tasks corresponding to the same peer interface address data from multiple single line monitoring task data.

[0232] The second data parsing module is used to obtain continuous line monitoring data for the same peer interface address data, based on the target single task execution time and the quality index data of all target single tasks within the monitoring period.

[0233] It should be noted that the functions and corresponding technical effects of each module in the network line quality monitoring device provided in this embodiment can be referred to the description of the specific implementation methods in the various embodiments of the network line quality monitoring method of this invention. For the sake of brevity, they will not be repeated here.

[0234] Furthermore, embodiments of the present invention also propose a computer-readable storage medium storing a network line quality monitoring program. When executed by a processor, the network line quality monitoring program implements the steps of the network line quality monitoring method described above. Therefore, it will not be repeated here. Additionally, the beneficial effects of using the same method will not be repeated here either. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in the present invention, please refer to the description of the method embodiments of the present invention. As an example, program instructions can be deployed to execute on a single computing device, or on multiple computing devices located at one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0235] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising a network line quality monitor" does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0236] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0237] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0238] The above are merely preferred embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for monitoring network line quality, characterized in that, The network line quality monitoring method includes: The system acquires line monitoring item data, global configuration parameters for dialing, and alarm indicator data. The global configuration parameters for dialing include the probe task frequency, the number of probe messages, and the message sending interval. The alarm indicator data is related to the single task quality indicator data. The line monitoring item data includes the access interface address and the peer interface address. Determine the dial-up test configuration template and dial-up test task check instructions corresponding to the application technology type of the access device; the application technology type is network quality analysis type, Internet Protocol Service Level Protocol type, or network line quality assurance type. Based on the line monitoring item data, the dial-up test global configuration parameters, and the alarm indicator data, the dial-up test configuration template is filled to obtain the dial-up test task configuration content of the line monitoring item. The device operation layer issues the configuration content of the dial-up test task and the dial-up test task check instruction for a single line monitoring task to the access device. The system acquires monitoring time periods and multiple single-line monitoring task data collected by the Simple Network Management Protocol (SRM) collector for the monitoring lines of access devices; wherein, the single-line monitoring task data includes single-task execution time, collection task execution sequence number, peer interface address data connected to the access device, and single-task quality index data; Based on multiple single-line monitoring task data, peer interface address result data and single-task quality indicator result data are obtained; wherein, the peer interface address result data and the single-task quality indicator result data are both key-value pairs, and the attribute keys of the peer interface address result data and the single-task quality indicator result data are all object identifiers, character ASCII codes of task configuration item parameter values, character ASCII codes of single dial-up test acquisition task names, acquisition task execution sequence numbers, and acquisition result codes obtained by concatenating task types; the attribute value of the peer interface address result data is the peer interface address data, and the attribute value of the single-task quality indicator result data is the single-task quality indicator data; Traverse the peer interface address result data to determine all target acquisition result codes corresponding to the same peer interface address data, and obtain a first key-value pair; wherein, the attribute key of the first key-value pair is the same peer interface address data, and the attribute value is the target acquisition result code; Based on the target acquisition result encoding, query the single task quality indicator result data to determine the execution time of all target single tasks and the quality indicator data of all target single tasks corresponding to the same peer interface address data. For the same peer interface address data, based on the execution time of the target single task and the quality index data of all the target single tasks within the monitoring time period, continuous line monitoring data of the line monitoring item during the monitoring time period is obtained. The continuous line monitoring data includes the average packet loss rate of multiple consecutive tasks and the average latency of multiple consecutive tasks. The average packet loss rate of multiple consecutive tasks is obtained by averaging all packet loss rate values ​​between the start time of the average packet loss rate of multiple consecutive tasks and the current system time. The start time of the average packet loss rate of multiple consecutive tasks is calculated by the current system time, the frequency of detection tasks, and the number of statistical tasks for the average packet loss rate of multiple consecutive tasks.

2. The network line quality monitoring method as described in claim 1, characterized in that, The step of sending the configuration content of the dial-up test task and the dial-up test task check instruction for a single line monitoring task to the access device through the device operation layer includes: The device operation layer sends the dial-up test task inspection command to the access device. If the execution echo of the test task inspection instruction is obtained, then it is determined whether there is a task with the same name as the single line monitoring task based on the execution echo. If it does not exist, the device operation layer sends the test task configuration content to the access device, and returns to execute the instruction to send the test task to the access device through the device operation layer. If it exists, then the single dial-up test task is determined to have been successfully configured on the access device.

3. The network line quality monitoring method as described in any one of claims 1 to 2, characterized in that, After obtaining the continuous line monitoring data of the line monitoring item during the monitoring period based on the execution time of the target single task and the quality index data of all the target single tasks within the monitoring period, the method further includes: If the packet loss rate of a single task in at least one of the target single task quality index data is 100%, a line interruption alarm event is triggered. If the line interruption alarm event is not triggered, then determine whether the average packet loss rate of the multi-task in the continuous monitoring data of the line is greater than or equal to the first preset alarm threshold. If the average packet loss rate of multiple consecutive tasks exceeds the threshold, an alarm event will be triggered if the average packet loss rate of multiple tasks exceeds the threshold. If neither a line interruption alarm event nor a multi-task average packet loss rate exceeding the threshold alarm event is triggered, then determine whether the single-task packet loss rate is greater than or equal to the second preset alarm threshold. If the packet loss rate is greater than or equal to the second preset alarm threshold, an alarm event for exceeding the packet loss rate threshold will be triggered.

4. The network line quality monitoring method as described in claim 3, characterized in that, After obtaining the continuous line monitoring data of the line monitoring item during the monitoring period based on the execution time of the target single task and the quality index data of all the target single tasks within the monitoring period, the method further includes: If no line interruption alarm event is triggered, determine whether the average multi-task latency in the continuous line monitoring data is greater than or equal to the third preset alarm threshold. If the average latency of multiple consecutive tasks exceeds the threshold, an alarm event will be triggered if the threshold is greater than or equal to the third preset alarm threshold. If no line interruption alarm event or multiple consecutive task average latency exceeding threshold alarm event is triggered, then determine whether there is at least one single task latency in the target single task quality index data that is greater than or equal to the fourth preset alarm threshold. If present, a latency exceeding the threshold alarm event will be triggered.

5. The network line quality monitoring method as described in claim 3, characterized in that, After obtaining the continuous line monitoring data of the line monitoring item during the monitoring period based on the execution time of the target single task and the quality index data of all the target single tasks within the monitoring period, the method further includes: Obtain the actual and theoretical number of data collected by the Simple Network Management Protocol (SMMP) collector for a single line monitoring task within a preset time period for the monitored line. If the actual number of samples collected is less than the theoretical number of samples collected, a data loss alarm event will be triggered.

6. A network line quality monitoring device, characterized in that, The device includes: The monitoring task data acquisition module is used to acquire multiple single-line monitoring task data collected by the Simple Network Management Protocol (SRM) collector for the monitoring lines of the access device during the monitoring period. The single-line monitoring task data includes the single-task execution time, the acquisition task execution sequence number, the peer interface address data connected to the access device, and the single-task quality index data. The first data parsing module is used to determine, from the multiple single-line monitoring task data, the execution time of all target single tasks and the quality index data of all target single tasks corresponding to the same peer interface address data. The second data parsing module is used to obtain continuous line monitoring data for the line monitoring item during the monitoring period based on the execution time of the target single task and the quality index data of all the target single tasks within the monitoring period, for the same peer interface address data. The continuous line monitoring data includes the average packet loss rate of multiple consecutive tasks and the average latency of multiple consecutive tasks. The average packet loss rate of multiple consecutive tasks is obtained by averaging all packet loss rate values ​​between the start time of the average packet loss rate of multiple consecutive tasks and the current system time. The start time of the average packet loss rate of multiple consecutive tasks is calculated by the current system time, the detection task frequency, and the number of statistical tasks for the average packet loss rate of multiple consecutive tasks. The first data parsing module is further configured to obtain peer interface address result data and single task quality indicator result data based on multiple single-line monitoring task data; wherein, the peer interface address result data and the single task quality indicator result data are both key-value pairs, and the attribute keys of the peer interface address result data and the single task quality indicator result data are object identifiers, character ASCII codes of task configuration item parameter values, character ASCII codes of single dial-up acquisition task names, acquisition task execution sequence numbers, and acquisition result codes obtained by concatenating task types; the attribute value of the peer interface address result data is the peer interface address data, and the attribute value of the single task quality indicator result data is the single task quality indicator data; traversing the peer interface address result data, determining all target acquisition result codes corresponding to the same peer interface address data, and obtaining a first key-value pair; wherein, the attribute key of the first key-value pair is the same peer interface address data, and the attribute value is the target acquisition result code; based on the target acquisition result code, querying the single task quality indicator result data, and determining all target single task execution times and all target single task quality indicator data corresponding to the same peer interface address data. The device is further configured to acquire line monitoring item data, global test configuration parameters, and alarm indicator data of the line monitoring item; the global test configuration parameters include probe task frequency, probe packet quantity, and packet transmission interval; the alarm indicator data is related to the single task quality indicator data; the line monitoring item data includes access interface address and peer interface address; determine a test configuration template and test task check instruction corresponding to the application technology type of the access device; the application technology type is network quality analysis type, Internet Protocol Service Level Protocol type, or network line quality assurance type; based on the line monitoring item data, the global test configuration parameters, and the alarm indicator data, fill the test configuration template to obtain the test task configuration content of the line monitoring item; and issue the test task configuration content and test task check instruction for a single line monitoring task to the access device through the device operation layer.

7. A network line quality monitoring device, characterized in that, The device includes: a memory, a processor, and a network line quality monitoring program stored in the memory and executable on the processor, the network line quality monitoring program being configured to implement the steps of the network line quality monitoring method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a network line quality monitoring program, which, when executed by a processor, implements the steps of the network line quality monitoring method as described in any one of claims 1 to 5.

Images