Video service-oriented multi-source flow integrated monitoring system

Abstract

The invention belongs to the technical field of communication and computer networks, and discloses a video service-oriented multi-source flow integrated monitoring system, which comprises a distributed acquisition device, a processing platform and an interface service device. The acquisition device is deployed at at least two types of positions in a terminal, an edge node, a service node and network equipment, and reports an event record containing a source identifier, a timestamp, a resource identifier and a fragment identifier or a fragment sequence number. The processing platform aligns the timestamps to obtain a unified time reference, constructs a fragment closed-loop object and generates a unified closed-loop identifier, verifies and generates an inconsistent breakpoint identifier and writes the inconsistent breakpoint identifier into a low-credibility mark; therefore, a source credibility weight is formed, low credibility values are removed from index item conflicts, and fusion monitoring data are output through resolution. And the interface service device outputs the fused monitoring data and the corresponding inconsistent breakpoint identifiers.

Description

Technical Field

[0001] This invention belongs to the field of communication and computer network technology, specifically a multi-source traffic integrated monitoring system for video services. Background Technology

[0002] In video-on-demand and live streaming services, content is usually transmitted and played in video segments as the basic unit. The service side generates behaviors such as segment requests, caching and playback consumption, while the transmission side generates information such as segment delivery and connection status. In order to evaluate playback quality and support operation and maintenance troubleshooting, the above behaviors are often converted into event logs and traffic and timing statistics are performed.

[0003] Existing monitoring systems typically deploy data collection devices on the terminal side, edge node side, service node side, and network device side to collect and report event records containing source identifiers, event timestamps, resource identifiers, and fragment identifiers or fragment sequence numbers. These records are then centrally aggregated and processed by a processing platform. Event records are often divided into a business event record set and a transmission event record set. The business event record set contains fragment request event records and fragment consumption event records, while the transmission event record set contains fragment delivery event records and can carry fields such as delivery byte count, consumption byte count, and connection elements.

[0004] When data collection locations are scattered and local clock references are inconsistent, timestamp alignment errors and reporting delays can cause mismatches in fragment requests, delivery, and consumption events. In scenarios involving connection reuse and concurrent requests, aggregation based solely on connection elements or coarse-grained time intervals is more prone to fragment-level misattribution. Different data collection locations have inconsistent support for fragment identification fields, and the situation where fragment identification is missing and only fragment sequence number information is available leads to unstable cross-source association conditions. At the same time, differences in sampling rate, missing events, and field completeness can cause inconsistent values ​​for delivered byte counts and consumed byte counts, resulting in cross-source conflicts. This reduces the verifiability and traceability of fragment-level monitoring results, making it difficult to attribute anomalies and locate faults. Summary of the Invention

[0005] The purpose of this invention is to provide a multi-source traffic integrated monitoring system for video services, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a multi-source traffic integrated monitoring system for video services, used to uniformly associate and verify the consistency of multi-source events in the process of requesting, transmitting and delivering, and playing video segments, and to form traceable monitoring results. The system includes a distributed acquisition device, a processing platform, and an interface service device.

[0007] The distributed acquisition device is deployed in at least two types of locations: terminal side, edge node side, service node side, and network device side. It is used to collect and report event records. The event records include a set of business event records and a set of transmission event records. The set of business event records includes at least fragment request event records and fragment consumption event records. Each business event record includes a resource identifier, fragment identifier or fragment sequence number information, business event type, and an aligned timestamp / corrected business event timestamp under a unified time base. The fragment consumption event record further includes a consumption byte count. The set of transmission event records includes at least fragment delivery event records. Each fragment delivery event record includes connection elements, delivery byte count, and transmission event timestamp. The connection elements include a terminal identifier, an edge node identifier, a service node identifier, a connection identifier, and a five-tuple describing the connection. The five-tuple includes a source address, a destination address, a source port, a destination port, and a transport layer protocol.

[0008] The processing platform receives sets of business event records and transmission event records from different locations. It aligns the aligned / corrected timestamps of the business events and the transmission events under a unified time base to obtain a unified time base. Under the unified time base, the processing platform constructs a segment closed-loop object based on resource identifiers and segment identifiers or segment sequence numbers, and generates a unified closed-loop identifier for each segment closed-loop object. For the same unified closed-loop identifier, the processing platform uses the aligned / corrected timestamp of the segment request event record under the unified time base as the starting point of the time window and the aligned / corrected timestamp of the segment consumption event record under the unified time base as the ending point of the time window to form a segment time window. Under the condition that the connection elements are consistent, the processing platform associates the segment delivery event records whose transmission event timestamps fall within the segment time window with the corresponding segment closed-loop object, thereby forming a verifiable association between segment requests, segment delivery, and segment consumption within the same closed-loop object.

[0009] At the unified closed-loop identifier level, the processing platform performs consistency checks on associated event records and generates inconsistency breakpoint identifiers. Consistency checks include temporal consistency checks and data volume consistency checks: temporal consistency checks are used to determine whether a fragment request event record is earlier than a fragment delivery event record and whether a fragment delivery event record is earlier than a fragment consumption event record; data volume consistency checks are used to determine whether the difference between the delivered byte count and the consumed byte count does not exceed the tolerance threshold. For event records that fail the consistency checks, the processing platform generates corresponding inconsistency breakpoint identifiers and writes them into a low-confidence flag. The processing platform further forms a source credibility weight based on the consistency check results, the low-confidence flag, and the collection quality information. When inconsistent values ​​appear in the same-named count field under the same unified closed-loop identifier, this situation is identified as a cross-source conflict. After removing the values ​​with the low-confidence flag, the processing platform performs conflict resolution based on the source credibility weight and outputs fused monitoring data. The interface service device provides query and subscription interfaces for outputting fused monitoring data and the inconsistency breakpoint identifiers corresponding to the fused monitoring data.

[0010] The above technical solution binds business-side and transmission-side events under a unified time reference by using segmented closed-loop objects as organizational units, and uses inconsistency breakpoints to solidify the deviation positions of timing and data volume. This ensures that even when there are time alignment errors, missing values, or inconsistent values ​​in multi-source data, the source of the anomaly and the position of the deviation can still be clearly identified. Furthermore, by using source credibility weight constraints to resolve conflicts, it avoids the dominant influence of unreliable sources on the fusion results, thereby ensuring that the fused monitoring data maintains verifiable consistency at the segment level, providing a traceable data foundation for subsequent positioning.

[0011] In this invention, the event records reported by the distributed acquisition device are divided into a business event record set and a transmission event record set, which respectively characterize the request and consumption behavior of video segments on the business side and the delivery process on the transmission side, thereby providing a data foundation for the subsequent construction of closed-loop objects of segments and cross-source association.

[0012] The business event record set includes at least segment request event records and segment consumption event records; segment request event records are used to characterize the terminal's request behavior for the target video segment, and segment consumption event records are used to characterize the consumption behavior of the segment on the playback side; to provide comparable quantitative basis, segment consumption event records include the consumption byte count. The transmission event record set includes at least fragment delivery event records. Fragment delivery event records are used to characterize the data delivery status of the target fragment by the network side or the service side, and include the delivered byte count and connection elements. Connection elements are used to identify the connection identification information that carries the fragment delivery. Connection elements include at least one of terminal identifier, edge node identifier, service node identifier, connection identifier and a 5-tuple, wherein the 5-tuple includes source address, destination address, source port, destination port and transport layer protocol.

[0013] Through the above classification settings, the segment identifier or segment sequence information on the business side and the connection elements on the transmission side form an index condition that can be associated. The delivered byte count and the consumed byte count form verifiable comparison data, enabling event records generated at different collection locations to be included in the same analysis object at the segment level. This reduces the uncertainty of association caused by differences in data granularity and provides a clear input basis for consistency verification and conflict handling.

[0014] Furthermore, the processing platform achieves segment-level association between service-side events and transmission-side events under a unified time reference. First, under the condition of matching connection elements, the processing platform determines the segment time window of the target video segment based on the aligned / corrected service event timestamp under the unified time reference of the segment request event record and the aligned / corrected service event timestamp under the unified time reference of the segment consumption event record. Then, the processing platform determines whether the transmission event timestamp of the segment delivery event record is within the segment time window under the unified time reference, and assigns the segment delivery event records within the segment time window to the corresponding segment closed-loop object, so that segment requests, segment delivery, and segment consumption form a corresponding relationship within the same segment closed-loop object. When using the above association method, the connection element is used to limit the connection range to which the delivery event belongs, and the segment time window is used to limit the time range to which the delivery event belongs. For situations such as continuous video segment requests, concurrent connections, and reporting delays, relying solely on the connection element can easily lead to the delivery events of adjacent segments being mixed into the current segment's closed-loop object. By introducing the segment time window, the delivery event can be limited to a reasonable time interval between segment request and segment consumption, thereby reducing the probability of delivery event mismatch and providing a stable association basis for subsequent consistency verification, inconsistency breakpoint identification generation, and conflict resolution.

[0015] In this invention, to distinguish the reliability of event records from different acquisition locations and different sources, the event records include not only source identifiers, event timestamps, and identification information related to video clips, but also acquisition quality parameters. The acquisition quality parameters are used to characterize the quality status of event records during the acquisition and reporting process. They include at least event acquisition sampling rate information, event missing information, reporting cycle information, and field completeness information. Among them, the event acquisition sampling rate information is used to characterize the sampling frequency or sampling ratio of event records; the event missing information is used to characterize the missing ratio or missing count of event records within a preset statistical period; the reporting cycle information is used to characterize the time interval characteristics from the generation of an event record to its reporting; and the field completeness information is used to characterize the completeness of key fields, which can be characterized by the proportion of missing key fields or the proportion of complete fields.

[0016] When determining the source credibility weight, the processing platform statistically analyzes the collection quality parameters of each source based on a preset statistical period and calculates the proportion of low-credibility markers appearing in the segment closed-loop objects corresponding to each unified closed-loop identifier. When a source has a high proportion of low-credibility markers under multiple unified closed-loop identifiers, or its event missing information is high, field completeness information is low, or the reporting cycle information changes beyond a preset threshold within the preset statistical period, the processing platform reduces the source credibility weight of that source according to preset rules. When a source has low event missing information and high field completeness information, and the proportion of low-credibility markers is low and the reporting cycle information is stable, the processing platform increases the source credibility weight of that source according to preset rules. Through the above methods, the source credibility weight provides a weight basis for subsequent conflict handling when inconsistent values ​​of the same indicator item under the same unified closed-loop identifier occur. This enables conflict resolution to distinguish values ​​from different sources in the presence of missing information, incomplete fields, or unstable reporting, avoiding unreliable sources from having a dominant influence on the fused monitoring data.

[0017] Furthermore, to reduce the alignment error caused by the inconsistency of local clocks in event timestamps reported from different collection locations, the processing platform generates and outputs clock drift information corresponding to each event record source while aligning the event timestamps. The clock drift information is used to characterize the clock offset of the local clock of the event record source relative to the same time base, and to characterize the change of the clock offset within a preset time period, so as to introduce quantitative parameters of alignment error in subsequent segment time window determination, timing consistency verification and tolerance threshold setting processes.

[0018] Clock drift information is formed in one of the following ways: First, based on reference clock synchronization information, the processing platform uses the synchronization offset records obtained by synchronizing each event record source with the reference clock to calculate the clock offset of the event record source relative to the unified time reference; Second, based on the round-trip transmission delay measurement of time-aligned messages, the processing platform interacts with each event record source with time-aligned messages and measures the round-trip transmission delay of the messages, and estimates the clock offset of the event record source relative to the unified time reference by combining the sending time and receiving time of the time-aligned messages.

[0019] By retaining the clock drift information of each event record source during the timestamp alignment process, the timestamp alignment error can be used as a parameter in the threshold setting and judgment process of fragment-level association and consistency judgment. This avoids directly attributing the timing offset caused by clock deviation to the fragment request, fragment delivery or fragment consumption process itself, thus making the association and verification of fragment closed-loop objects more consistent with the actual acquisition conditions.

[0020] In this invention, the processing platform introduces data consistency verification at the fragment closed-loop object dimension to check the count information of fragment delivery event records and fragment consumption event records. The processing platform reads the delivery byte count in the fragment delivery event record and the consumption byte count in the fragment consumption event record, calculates the difference between the two, and determines whether the difference exceeds the tolerance threshold. When the difference exceeds the tolerance threshold, the processing platform generates an inconsistency breakpoint identifier and writes a low-confidence flag to the event record associated with the inconsistency breakpoint identifier. The inconsistency breakpoint identifier records the count field corresponding to the unified closed-loop identifier and the difference value information, so as to distinguish the value of the corresponding source of the delivery byte count or consumption byte count in the subsequent conflict handling process.

[0021] To ensure data consistency verification adapts to differences in sampling rate, event missingness, reporting rhythm, and clock alignment deviation among different data sources, the tolerance threshold is determined by the processing platform based on event missing information, reporting cycle information, field completeness information, and clock drift information. The processing platform assesses the degree of missing data and availability of the count field based on event missing information and field completeness information, evaluates the fluctuation range caused by count accumulation and reporting delay based on the reporting cycle information, and assesses the impact of timestamp alignment deviation on fragment association and count matching based on clock drift information. In cases of high event missingness, low field completeness, ... When the reporting cycle fluctuates significantly or the clock drift is obvious, the tolerance threshold is set to a larger value to cover the counting differences introduced by the acquisition and alignment conditions. When the event missing is low, the field completeness is high, the reporting cycle is stable, and the clock drift is small, the tolerance threshold is set to a smaller value to enhance the ability to identify abnormal differences. In this way, the judgment boundary of data consistency verification is matched with the acquisition quality and timestamp alignment conditions, avoiding the direct attribution of differences caused by acquisition missing or timestamp deviation to the delivery or consumption process, thereby providing verifiable quantitative basis for the formation of subsequent integrated monitoring data.

[0022] In this invention, considering the differences in support for the fragment identifier field at different acquisition locations, the processing platform sets up a fragment replacement identifier generation mechanism when constructing a fragment closed-loop object. When a business event record contains resource identifier and fragment sequence number information but does not contain fragment identifier, the processing platform uses the combination of the resource identifier and the fragment sequence number information as a fragment index to generate a fragment replacement identifier, and constructs a fragment closed-loop object based on the fragment replacement identifier and generates a unified closed-loop identifier.

[0023] After adopting the above mechanism, even if the fragment identifier is missing, the processing platform can still limit the resource range to which the fragment belongs based on the resource identifier, and distinguish the fragments within the resource range based on the fragment sequence number information. This allows the fragment request event record, fragment delivery event record, and fragment consumption event record to be grouped into the same fragment closed-loop object according to the fragment replacement identifier. This method is used to avoid the inability to construct the fragment closed-loop object or generate a unified closed-loop identifier due to the missing fragment identifier, so that subsequent consistency verification, inconsistency breakpoint identifier generation, and conflict resolution have a continuous fragment-level index foundation.

[0024] In this invention, to ensure that the abnormal results of consistency verification have a locatable record format, the processing platform generates an inconsistency breakpoint identifier when an inconsistency occurs in the fragment closed-loop object. The inconsistency breakpoint identifier is used to record the inconsistency in a structured manner, and it includes at least a breakpoint type field, a unified closed-loop identifier field corresponding to the breakpoint, and an event record index field. The event record index is used to point to the event record entry that triggered the breakpoint, and the event record entry includes at least one of fragment request event record, fragment delivery event record, and fragment consumption event record.

[0025] Breakpoint types are used to characterize categories of inconsistencies, including at least one of the following: reverse order breakpoints, missing breakpoints, and data volume difference breakpoints. Reverse order breakpoints are used to characterize situations where fragment request event records, fragment delivery event records, and fragment consumption event records do not meet a preset sequential relationship under a unified time base. Missing breakpoints are used to characterize situations where at least one of fragment request event records, fragment delivery event records, or fragment consumption event records is missing from the fragment closed-loop object corresponding to the unified closed-loop identifier. Data volume difference breakpoints are used to characterize situations where the difference between the delivered byte count and the consumed byte count exceeds a tolerance threshold.

[0026] By using the aforementioned inconsistency breakpoint identifiers, the processing platform can locate the segment closed-loop object to which the inconsistency belongs in the unified closed-loop identifier dimension, and locate the event record entry that triggered the inconsistency based on the event record index. This provides a consistent data input basis for writing low-confidence markers, determining source confidence weights, and filtering values ​​during conflict resolution, while maintaining the traceability of fused monitoring data.

[0027] In this invention, the processing platform performs conflict resolution on multiple source values ​​of the same indicator item at the unified closed-loop identifier dimension to form fused monitoring data. The same indicator item is used to represent the value of the same name count field or the same name statistical field under the same unified closed-loop identifier. The count field or statistical field includes at least one of delivered byte count and consumed byte count. The conflict resolution adopts a hierarchical approach, including a priority selection approach and a weighted fusion approach.

[0028] The processing platform first compares the source credibility weights corresponding to each event record source, determines the source with the highest source credibility weight as the candidate priority source, and determines whether the indicator values ​​of the candidate priority source are written into the low credibility flag. When the indicator values ​​of the candidate priority source are not written into the low credibility flag, the processing platform uses the indicator values ​​of the candidate priority source to form fused monitoring data. When the indicator values ​​of the candidate priority source are written into the low credibility flag, the processing platform selects a set of available values ​​from the sources that have not been written into the low credibility flag, and performs weighted fusion based on the set of available values ​​to form fused monitoring data.

[0029] During the weighted fusion process, the processing platform uses the source credibility weight of each source as a weight parameter to perform weighted calculation on the available value set to obtain the fused value. The fused value is obtained by summing the product of each source value and its corresponding source credibility weight, and then dividing by the sum of the source credibility weights participating in the weighting. By using the low credibility mark and the source credibility weight together as the constraint condition for conflict handling, the processing platform can prioritize the value with higher credibility that has not been marked as low credibility when there are inconsistent values ​​from multiple sources. When the value is unavailable, it forms a verifiable fusion result based on the available values ​​from other sources, thus maintaining a consistent constraint relationship between the fused monitoring data and the consistency verification results.

[0030] In this invention, after the processing platform generates fused monitoring data, it performs anomaly determination on the corresponding segment closed-loop objects based on a unified closed-loop identifier, so as to provide a verifiable anomaly determination result at the segment level. The anomaly determination includes at least two types of triggering conditions: First, under the same unified closed-loop identifier, the data volume difference between the delivered byte count and the consumed byte count exceeds the tolerance threshold; Second, under the same unified closed-loop identifier, the number of inconsistent breakpoint identifiers associated with the segment closed-loop object exceeds a preset breakpoint number threshold. When either triggering condition is met, the processing platform marks the segment closed-loop object corresponding to the unified closed-loop identifier as an anomaly, and records the data volume difference value, tolerance threshold, and corresponding inconsistent breakpoint identifier set that triggered the anomaly, for the purpose of verifying the basis for anomaly triggering.

[0031] After an anomaly is marked, the processing platform generates a fault attribution object identifier, which is used to characterize the object category and object identifier associated with the anomaly. The fault attribution object identifier includes object type information and object identifier information. The value range of the object type information includes at least one of terminal, edge node, service node, and network path. The object identifier information corresponds to the object type information. When the object type is a terminal, the object identifier information is the terminal identifier; when the object type is an edge node, the object identifier information is the edge node identifier; when the object type is a service node, the object identifier information is the service node identifier; and when the object type is a network path, the object identifier information is the connection element.

[0032] The determination of object type information is based on the statistical results of the distribution of inconsistent breakpoint identifiers across different event record sources. The processing platform counts the number of inconsistent breakpoint identifiers from terminal-side, edge node-side, service node-side, and network device-side sources under the same unified closed-loop identifier, and maps the source category with the highest number to object type information. When there are multiple maximum values, the corresponding object type information can include various values. The mapping relationship between source category and object type information includes: terminal-side source corresponds to terminal, edge node-side source corresponds to edge node, service node-side source corresponds to service node, and network device-side source corresponds to network path. Object identifier information is extracted from the event record pointed to by the event record index: when the object type is terminal, edge node, or service node, the terminal identifier, edge node identifier, or service node identifier in the corresponding event record is extracted; when the object type is network path, the connection element in the corresponding event record is extracted. Through the above method, both anomaly judgment and attribution results are established on the locatable information link formed by the unified closed-loop identifier, inconsistent breakpoint identifiers, and event record index, ensuring that the data basis for maintaining consistency between the anomaly triggering conditions and the attribution object.

[0033] The beneficial effects of this invention are as follows: 1. This invention collects and reports event records at at least two types of locations, including the terminal side, edge node side, service node side, and network device side, and aligns the timestamps of events from different sources to obtain a unified time reference. Then, based on resource identifiers and fragment identifiers or fragment sequence number information, a fragment closed-loop object is constructed and a unified closed-loop identifier is generated. This enables fragment requests, fragment delivery, and fragment consumption to form a verifiable association within the same closed-loop object, thereby reducing the risk of fragment-level mismatch caused by clock deviations, reporting delays, or granularity differences in multi-source data and improving the traceability and consistency of the monitoring link.

[0034] 2. This invention performs consistency checks on associated event records under the same unified closed-loop identifier, and generates inconsistent breakpoint identifiers for cases that fail the check. At the same time, the event records associated with the inconsistent breakpoint identifiers are written into low-confidence markers. The inconsistent breakpoint identifiers include at least the breakpoint type, the unified closed-loop identifier corresponding to the breakpoint, and the event record index. This enables anomalies such as reverse order, missing data, or data volume differences to be structured and solidified at the fragment level and traced back to their location. This reduces the reliance on human experience in the location process and improves the efficiency of anomaly detection and review.

[0035] 3. This invention forms source credibility weights based on the distribution of collected quality parameters and low-confidence markers on a unified closed-loop identifier dimension. When inconsistent values ​​exist for the same indicator under the same unified closed-loop identifier, values ​​with low-confidence markers are first removed before conflict resolution is performed to output fused monitoring data. Conflict resolution can adopt a priority selection or weighted fusion method, thereby avoiding unreliable sources from having a dominant influence on the fusion result, and ensuring that the fused monitoring data remains robust even under conditions of missing data, incomplete fields, or unstable reporting. Furthermore, based on the fused monitoring data and inconsistent breakpoint markers, anomaly judgment is performed and fault attribution object markers are generated, which is beneficial for establishing verifiable correspondences between anomalies and terminals, edge nodes, service nodes, or network paths. Attached Figure Description

[0036] Figure 1 This is a flowchart of the multi-source event association and fragment closed-loop construction process of the present invention; Figure 2 This is a flowchart of the consistency verification and low-confidence marking process of the present invention; Figure 3 This is a flowchart of the conflict resolution and fusion monitoring data generation process of the present invention. Detailed Implementation

[0037] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0038] like Figures 1 to 3 As shown, in this embodiment of the invention, a multi-source traffic integrated monitoring system for video services is provided. The system includes a distributed acquisition device, a processing platform, and an interface service device.

[0039] Event collection and event logging format Distributed acquisition devices are deployed in at least two types of locations, including the terminal side, edge node side, service node side, and network device side, to collect and report event records. The event records are divided into a business event record set and a transmission event record set.

[0040] The business event record set includes at least segment request event records and segment consumption event records. Each business event record includes resource identifier, segment identifier or segment sequence number information, business event type, and aligned timestamp / corrected business event timestamp under a unified time base. Among them, the segment consumption event record includes the consumed byte count, which is used to characterize the byte consumption of the corresponding segment on the playback side.

[0041] The transmission event record set contains at least fragment delivery event records. Each fragment delivery event record contains connection elements, a delivery byte count, and a transmission event timestamp. The connection elements are used to identify the connection information carrying the fragment delivery. The connection elements include at least one of the following: terminal identifier, edge node identifier, service node identifier, connection identifier, and a 5-tuple. The 5-tuple includes the source address, destination address, source port, destination port, and transport layer protocol.

[0042] To facilitate subsequent identification of the source of inconsistency, each event record in this embodiment further carries a source identifier and an event record identifier. The event record identifier is used to uniquely point to the event record entry.

[0043] Timestamp alignment and formation of a unified time base The processing platform receives service event record sets and transmission event record sets from different locations. It performs alignment processing on the aligned / corrected service event timestamps and transmission event timestamps under a unified time base to form a unified time base. In this embodiment, the alignment processing uses any of the following methods to form the clock offset of each source relative to the unified time base, and corrects the event timestamps accordingly: Based on reference clock synchronization information: The processing platform reads the synchronization offset records obtained by synchronizing each source with the reference clock, and calculates the clock offset of the source relative to the same time base; Based on time-aligned messages: The processing platform interacts with various sources to exchange time-aligned messages, measures the round-trip transmission delay of the messages, and estimates the clock offset of the source relative to a unified time base by combining the sending and receiving times. The processing platform uses the corrected event timestamps as timestamps under a unified time base for subsequent association and verification, and retains the clock offsets from each source as clock drift information.

[0044] Fragment closed-loop object construction and fragment delivery event association Under a unified time reference, the processing platform constructs a segment closed-loop object based on the resource identifier and segment identifier or segment sequence number information, and generates a unified closed-loop identifier for each segment closed-loop object. In this embodiment, the unified closed-loop identifier is generated by the resource identifier and the segment identifier; when the segment identifier is missing and the segment replacement identifier is valid, the unified closed-loop identifier is generated by the resource identifier and the segment replacement identifier. For the same unified closed-loop identifier, the processing platform determines the segment time window based on the segment request event record and the segment consumption event record. The starting point of the segment time window is the aligned timestamp / corrected business event timestamp under the unified time base of the segment request event record, and the ending point is the aligned timestamp / corrected business event timestamp under the unified time base of the segment consumption event record. To associate fragment delivery event records with the corresponding fragment closure object, the processing platform performs deterministic matching rules on the connection elements. In this embodiment, the matching rules are executed with the following priority: If the fragment delivery event record contains a connection identifier, then the connection identifier is matched against the connection identifier in the fragment request event record or the fragment consumption event record; If a connection identifier is missing and a 5-tuple is contained, then the 5-tuple is used for matching; If the connection identifier and the quintuple are missing, the combination of the terminal identifier and the service node identifier will be used for matching. If none of the above matching conditions are met, the fragment delivery event record will not be associated and will be retained as evidence when generating missing breakpoint identifiers in the future. Provided that the connection elements are matched, the processing platform determines whether the transmission event timestamp of the fragment delivery event record is within the fragment time window. If it is within the fragment time window, the fragment delivery event record is associated with the fragment closed loop object corresponding to the unified closed loop identifier. When a fragment consumption event record is missing, making it impossible to form the end point of the fragment time window, the processing platform marks the fragment closed-loop object corresponding to the unified closed-loop identifier as a candidate for missing breakpoints, and performs subsequent verification only based on the existing fragment request event record and fragment delivery event record, while retaining the missing information for breakpoint identifier generation.

[0045] Consistency checks, inconsistency breakpoint identification, and low-confidence flags In the unified closed-loop identifier dimension, the processing platform performs consistency verification on related event records. The consistency verification includes time sequence consistency verification and data volume consistency verification.

[0046] The timing consistency check is used to determine whether the sequence of fragment request event records, fragment delivery event records and fragment consumption event records meets the preset order under a unified time base. If there is a time sequence violation, a reverse breakpoint marker is generated.

[0047] Data consistency verification is used to calculate the difference between the delivered byte count and the consumed byte count, and to determine whether the difference does not exceed the tolerance threshold. The tolerance threshold is determined by the processing platform in combination with the acquisition quality information and the clock drift information. In this embodiment, the processing platform first forms a basic tolerance based on the event missing information, the reporting cycle information and the field completeness information, and then forms a drift compensation amount based on the clock drift information. Finally, the sum of the basic tolerance and the drift compensation amount is used as the tolerance threshold.

[0048] When the difference exceeds the tolerance threshold, a data volume difference breakpoint identifier is generated.

[0049] When the consistency check fails or the necessary event is missing, the processing platform generates an inconsistency breakpoint identifier corresponding to the inconsistency situation and writes a low-trust flag to the event record that triggers the breakpoint identifier. The inconsistency breakpoint identifier includes at least the breakpoint type, the unified closed-loop identifier corresponding to the breakpoint, and the event record index. The event record index is used to point to the event record identifier that triggers the breakpoint.

[0050] Collection of quality information statistics, source credibility weighting and conflict handling The processing platform performs statistical analysis on the collection quality information from various sources within a preset statistical period. The collection quality information includes at least sampling rate information, event missing information, reporting cycle information, and field completeness information, among which: The missing event information is determined by the ratio of the number of missing events to the number of expected events within a preset statistical period; Field completeness information is determined by the ratio of the number of events with all key fields complete to the number of statistical events within a preset statistical period; The reporting cycle information is obtained by statistically analyzing the time interval between the event generation time and the reporting time, and the stability is characterized by the fluctuation range. The processing platform combines the proportion of the collected quality information and low-confidence markers on the unified closed-loop identification dimension to determine the source credibility weight. Sources with a high proportion of low-confidence markers, a high proportion of missing event information, or a low proportion of field completeness information have a smaller source credibility weight; sources with a low proportion of low-confidence markers, a low proportion of missing event information, and a high proportion of field completeness information have a larger source credibility weight. When inconsistent values ​​for the same-named count field under the same unified closed-loop identifier originate from different sources, this situation is considered a cross-source conflict. The processing platform first removes values ​​marked with low credibility, and then performs conflict processing based on the source credibility weight to form fused monitoring data. Conflict processing includes two methods: priority selection and weighted fusion. If the value corresponding to the source with the highest source credibility weight is not marked as low credibility, then that value will be used as the fusion monitoring data. If the value corresponding to the source with the highest source credibility weight is written into the low credibility tag, then the set of values ​​that are not written into the low credibility tag will be weighted according to the source credibility weight to obtain the fused monitoring data. If the set of values ​​for which the low confidence flag is not written is empty, then an empty value is output and the corresponding inconsistent breakpoint identifier is retained to indicate that the indicator item lacks a source of available values. Output Results The interface service device provides query and subscription interfaces for outputting fused monitoring data and corresponding inconsistency breakpoint identifiers.

[0051] In this embodiment, the distributed acquisition device is deployed at least two types of locations, including the terminal side, the edge node side, the service node side, and the network device side, to collect and report event records. The processing platform receives the event records and performs storage and processing. To ensure that event records across acquisition locations can be compared and verified at the same video segment granularity, this embodiment makes the following stipulations regarding the classification of event records, the meaning of fields, and the counting caliber.

[0052] Event Log Categories and Common Fields Event records are divided into a business event record set and a transmission event record set. The business event record set consists of business event record entries, and the transmission event record set consists of transmission event record entries. To support indexing and backtracking, each event record entry must include at least a source identifier, a resource identifier, a fragment identifier or fragment sequence number, and an event timestamp.

[0053] The source identifier is used to identify the collection location and collection instance that generated the event record entry. The resource identifier is used to uniquely identify the video resource object. In this embodiment, the resource identifier is the unique resource number generated by the content management system. When the unique resource number cannot be obtained, the resource identifier is the unique string obtained after the Uniform Resource Locator is normalized.

[0054] The segment identifier is used to uniquely identify the target video segment under the resource corresponding to the resource identifier. In this embodiment, the segment identifier is the unique identifier assigned to the segment in the segment list file. If a segment identifier cannot be obtained at a certain acquisition location, the segment sequence number is used instead of the segment identifier. The segment sequence number is taken from the sequential number of the segment entry in the segment list file, and it is agreed that within the same resource identifier range, the segment sequence number is combined with the resource identifier to distinguish segments.

[0055] Event timestamps are used to record the time when an event occurs. In this embodiment, the event timestamps are reported using the original timestamps recorded locally by the acquisition device. The processing platform can perform unified benchmark correction on timestamps from different sources in subsequent processing, but the original timestamps are retained for verification.

[0056] The composition and generation of business event record sets The business event log set should contain at least fragment request event logs and fragment consumption event logs.

[0057] The fragment request event record is generated by the terminal-side acquisition device when a fragment request is initiated. Each fragment request event record includes at least a resource identifier, a fragment identifier or fragment sequence number, a service event type, and an aligned timestamp / corrected service event timestamp under a unified time base. In this embodiment, the service event type is taken as fragment request, which is used to distinguish the request from other service events.

[0058] The segment consumption event record is generated by the terminal-side acquisition device when the segment data enters the playback consumption stage. Each segment consumption event record includes at least the resource identifier, segment identifier or segment sequence number information, service event type, and aligned timestamp / corrected service event timestamp under a unified time base, and includes the consumed byte count. In this embodiment, the service event type is segment consumption.

[0059] The consumed byte count is used to characterize the actual number of bytes consumed by the terminal playback component for the segment data. In this embodiment, the consumed byte count is counted according to the following criteria: at the player data reading interface, the number of bytes read from the buffer corresponding to the segment is accumulated. The accumulated object is the effective payload bytes of the segment data, excluding protocol header bytes. The same byte is not repeatedly accumulated. The statistical points of the terminal-side acquisition device remain fixed within the same terminal-side acquisition instance to ensure consistent statistical criteria.

[0060] Composition and generation of transmission event record set The transmission event record set includes at least fragment delivery event records. These fragment delivery event records are generated by at least one acquisition device from the edge node side, service node side, or network device side, and are used to characterize the delivery status of fragments on the transmission side. Each fragment delivery event record includes at least a delivery byte count, a transmission event timestamp, and connection elements. At acquisition locations where resource and fragment information can be parsed, the fragment delivery event records further include resource identifiers and fragment identifiers or fragment sequence number information.

[0061] The delivery byte count is used to characterize the number of fragment data bytes delivered to the terminal. In this embodiment, the delivery byte count on the edge node side or the service node side is counted based on the cumulative value of the application layer response body. The count object is the effective payload bytes of the fragment data, excluding the protocol header bytes. When the network device side can identify the fragment data payload boundary, the delivery byte count is counted based on the cumulative value of the effective payload bytes of the fragment data within the corresponding connection. When the network device side cannot distinguish between the effective payload and the protocol header, the delivery byte count is counted based on the cumulative value of the transmission bytes corresponding to the fragment delivery within the connection, and this statistical caliber is marked in the source identifier for consistency verification and difference absorption during subsequent processing.

[0062] Transmission event timestamps are used to record the time when events related to the delivery of a video segment occur. In this embodiment, the transmission event timestamps on the edge node side or the service node side are taken as the time when the response body of the segment is sent and written; the transmission event timestamps on the network device side are taken as the time when the cumulative value of the transmitted bytes in the corresponding connection is observed to be updated. The transmission event timestamps are also reported in the form of raw timestamps for subsequent alignment and verification.

[0063] Connection elements are used to identify connection information for the delivery of bearer segments. Connection elements include at least one of terminal identifier, edge node identifier, service node identifier, connection identifier, and a 5-tuple. The 5-tuple includes source address, destination address, source port, destination port, and transport layer protocol. In this embodiment, the terminal identifier is the terminal application instance number; the edge node identifier is the edge node instance number; the service node identifier is the service instance number; and the connection identifier is the session identifier assigned to the connection by the server. The 5-tuple is extracted from the connection metadata by the transport stack or network device. When multiple fields can be obtained at the same collection location, the connection element includes both the connection identifier and the 5-tuple to improve the uniqueness and verifiability of connection location.

[0064] Field consistency constraints In this embodiment, the service event record set and the transmission event record set follow the following consistency constraints: Resource identifiers, fragment identifiers, or fragment sequence numbers use the same field naming and semantics in both types of sets; The consumption byte count and delivery byte count are statistical objects based on the cumulative value of fragment data bytes. The statistical scope remains fixed within the same source identifier range, and the source identifier is used to distinguish whether protocol header bytes are included. The aligned timestamps / corrected timestamps of business events and transmission events under the unified time base retain the original timestamps, which are used by the processing platform for unified time base correction and verification.

[0065] Technical Facts Regarding Implementation Results In video services, the terminal side can directly obtain segment request and segment consumption information, while the edge node side, service node side, or network device side can obtain segment delivery and connection information. By dividing event records into a business event record set and a transmission event record set, and making consistent semantic and caliber agreements on resource identifiers, segment identifiers or segment sequence number information, and byte count fields in both sets, event records generated by the same segment under the same resource identifier at different acquisition locations can have a comparable field basis. At the same time, segment delivery event records carry connection elements, enabling transmission-side records to be verified with terminal-side records in terms of connection dimension, providing a data basis for subsequent segment-level association and consistency verification.

[0066] In this embodiment, the processing platform correlates the service-side event records and the transmission-side event records at the fragment granularity under a unified time reference. In order to reduce the impact of clock deviation, reporting delay and connection reuse at different collection locations on the correlation results, this embodiment uses connection elements as connection range constraints, and uses the fragment time window determined by the fragment request event record and the fragment consumption event record as time range constraints, and associates the fragment delivery event record with the corresponding fragment closed-loop object accordingly.

[0067] Preparation of timestamps under a unified time base After the aligned timestamps / corrected service event timestamps generated by the terminal side under the unified time base, as well as the transmission event timestamps generated by the edge node side, service node side, or network device side, are reported to the processing platform, the processing platform corrects and aligns the timestamps from each source to obtain the aligned timestamps under the unified time base. The processing platform retains both the original timestamp and the aligned timestamp for each event record. The aligned timestamp, as the timestamp under the unified time base, participates in subsequent time window determination and correlation determination, while the original timestamp is used for review and backtracking.

[0068] Determining the same connection element and supplementing the connection elements of business event records. Connection elements are used to identify the connection information between the fragment request and the fragment delivery. Since the connection fields available at different acquisition locations are not completely consistent, this implementation uses a deterministic matching priority to determine the same connection element.

[0069] In this embodiment, when generating a fragment request event record, the terminal side synchronously collects a subset of connection elements and writes it into the fragment request event record. The subset of connection elements includes at least one of a connection identifier and a 5-tuple. When the connection identifier is unavailable, the 5-tuple is written. When the 5-tuple is unavailable, at least one of the terminal identifier and the service node identifier is written. Correspondingly, the fragment delivery event record is written with its available connection element fields.

[0070] The processing platform determines the matching priority of the same connected element as follows: When both the fragment request event record and the fragment delivery event record contain a connection identifier, the matching condition is that the connection identifier is the same. When a connection identifier is missing but both types of records contain a 5-tuple, the matching condition is that the 5-tuple is the same. When neither the connection identifier nor the 5-tuple is sufficient for a match, the matching condition is that the terminal identifier and the service node identifier are the same; when the edge node identifier is available, the edge node identifier is incorporated into the combination field to narrow the matching range.

[0071] When any of the above matching conditions are met, the processing platform will group the relevant event records into the same connection element group; when all conditions are not met, the fragment delivery event records will not enter the fragment association determination process, and their event record index will be retained for subsequent breakpoint location and low-confidence tag writing.

[0072] Determining the time window of a segment Within the same connection element group, the processing platform uses the resource identifier and fragment identifier or fragment sequence number information as fragment index conditions to determine the fragment request event record and fragment consumption event record corresponding to the fragment, and thereby determines the fragment time window. The starting point of the fragment time window is taken as the aligned timestamp of the fragment request event record, and the ending point of the fragment time window is taken as the aligned timestamp of the fragment consumption event record.

[0073] To mitigate the impact of timestamp alignment errors and reporting delays on time attribution determination, this implementation introduces a time window extension at the segment time window boundary: the time window extends forward from its starting point and backward from its ending point. The time window extension is determined by clock drift information; in this implementation, it is the maximum absolute clock offset of the relevant sources within the connected element group within a preset statistical period. When clock drift information is unavailable, the time window extension uses a preset fixed time margin. The time window extension is used only for time attribution determination and does not alter the timing consistency verification criteria based on the original event sequence.

[0074] Windowing determination and association of fragment delivery event records After obtaining the fragment time window, the processing platform traverses the fragment delivery event records within the same connected element group, reads its alignment timestamp, and determines whether the alignment timestamp falls within the fragment time window (including the expanded time window). When the alignment timestamp of a fragment delivery event record falls within the fragment time window, the processing platform associates the fragment delivery event record with the corresponding fragment loop object; when it does not fall within the fragment time window, it is not associated with the fragment loop object.

[0075] For cases where there are multiple segment delivery event records for the same segment, this implementation allows multiple segment delivery event records falling within the same segment time window to be simultaneously associated with the same segment closed-loop object. In subsequent data consistency verification, the summary caliber of the delivery byte count remains consistent within the same source identifier range: when the delivery byte count of the segment delivery event record is an incremental count, the delivery byte count falling within the time window is summed; when the delivery byte count of the segment delivery event record is a cumulative count, the last cumulative value falling within the time window is taken as the delivery byte count input for that segment.

[0076] Boundary Case Handling When there is a fragment request event record but a fragment consumption event record is missing, the processing platform cannot form the end point of the time window. In this embodiment, the processing platform does not perform fragment delivery event association determination for the fragment, and records the missing event type and the index of the existing event record for subsequent generation of missing breakpoint identifiers.

[0077] When a fragment request event record is missing but a fragment delivery event record exists, the processing platform does not establish a time window start point, does not associate the event records, and retains the fragment delivery event record index for subsequent breakpoint location.

[0078] When the number of connection feature fields is insufficient to complete the matching of the same connection feature, no association is performed, and the relevant event record index is retained for subsequent breakpoint and low-confidence tag writing.

[0079] In video services, segment requests and segment consumption are usually obtained from the terminal side, while segment delivery and connection metadata are usually obtained from the edge node side, service node side, or network device side. Aggregating transmission side events only based on connection information, or splicing multi-source events only based on coarse-grained time intervals, can easily lead to segment-level misattribution when connection reuse, concurrent requests, and reporting delays exist. This implementation introduces both connection element grouping and segment time windows formed by segment request alignment timestamps to segment consumption alignment timestamps under a unified time base, and sets the time window expansion amount in conjunction with clock drift information, so that the attribution determination of delivery events simultaneously satisfies connection constraints and time constraints, providing a verifiable association basis for subsequent consistency verification and breakpoint location of segment closed-loop objects.

[0080] In this embodiment, in order to improve the verifiability of multi-source fusion monitoring data, the processing platform, in addition to performing consistency verification on event records and writing low-confidence flags, also determines the source confidence weight based on the acquisition quality parameters carried by the event records and the distribution of low-confidence flags on the unified closed-loop identifier dimension. The source confidence weight is used to provide a basis for conflict handling when cross-source conflicts occur under the same unified closed-loop identifier.

[0081] Inputting Quality Parameters and Field Definitions In addition to resource identifier, fragment identifier or fragment sequence number information, event timestamp, source identifier, and business fields corresponding to the event type, each event record also includes collection quality parameters. The collection quality parameters are generated locally by the collection device that generates the event record and written into the event record, and are reported to the processing platform along with the event record. The collection quality parameters include sampling rate information, event missing information, reporting cycle information, and field completeness information.

[0082] To ensure consistent interpretation of the same parameter across different data acquisition locations, this implementation method adopts the following definitions for the four types of parameters: Sampling rate information The sampling rate information is used to characterize the collection coverage level of the acquisition device for the target event type. The acquisition device maintains a collection strategy configuration item for each event type. The collection strategy configuration item includes at least a full collection flag or sampling ratio, and a trigger counter for the event type. The acquisition device counts the actual number of events collected within a preset statistical time period, and uses the actual number of events collected or the number that should be collected as the sampling rate information. The number that should be collected is determined by trigger count × sampling ratio. When it is full collection, the sampling ratio is 1.

[0083] Missing event information Event missing information is used to characterize the degree of missing event record entries. The acquisition device generates monotonically increasing event numbers for the same event type and writes the event number into the event record. The processing platform aggregates the event numbers by source identifier and event type within a preset statistical time period, performs a continuity check on the event numbers, and sums the missing number by subtracting one from the interval between adjacent event numbers. The number of expected events is calculated by subtracting the minimum value from the maximum value of the event sequence number within the statistical period and then adding one; the number of missing events is calculated by dividing the number of missing events by the number of expected events. When an event sequence number cannot be provided at a certain collection location, the processing platform uses the reporting cycle information of the source identifier to estimate the number of batches that should be reported within the statistical period, and determines the missing quantity by the difference between the actual number of received batches and the number of batches that should be received.

[0084] Reporting periodic information The reporting cycle information is used to characterize the reporting rhythm and stability of the acquisition device. The acquisition device writes the reporting time for each report and counts the time interval between two adjacent reporting times according to the source identifier on the processing platform side. The reporting cycle information includes at least the average reporting cycle and the fluctuation range of the reporting cycle. The average reporting cycle is the arithmetic mean of the time intervals, and the fluctuation range of the reporting cycle is the difference between the maximum and minimum values ​​of the time intervals. The average reporting cycle is used to characterize the reporting rhythm, and the fluctuation range of the reporting cycle is used to characterize the stability. Field completeness information Field completeness information is used to characterize the completeness of key fields in event records. A set of key fields is predefined for each event type. The set of key fields includes at least resource identifier, fragment identifier or fragment sequence number information, event timestamp, source identifier, and the count field corresponding to the event type. When generating event logs, the data acquisition device performs a completeness check on the set of key fields. The field completeness information is taken as the number of valid fields or the total number of key fields. Valid fields refer to fields that exist and meet preset format constraints. Preset format constraints include at least field non-empty, field type matching, and valid value range.

[0085] In this embodiment, the aforementioned preset statistical time period is implemented using a sliding statistical method. The length of the statistical time period and the sliding step size are configurable parameters that are sent from the processing platform to the acquisition device or uniformly configured on the processing platform side, and remain consistent within the same source identifier range to ensure the comparability of the acquisition quality parameters.

[0086] Distribution statistics of low-trust tags on the unified closed-loop identifier dimension The processing platform performs consistency checks on event records within a segmented closed-loop object at the unified closed-loop identifier dimension. When an event record triggers a reverse order breakpoint, a missing breakpoint, or a data volume difference breakpoint, the processing platform writes a low-confidence flag to the event record pointed to by the event record index and generates a corresponding inconsistent breakpoint identifier.

[0087] The processing platform statistically analyzes the distribution of low-trust markers based on the source identifier for the same unified closed-loop identifier. This implementation method uses event records participating in the consistency verification of the unified closed-loop identifier as the statistical object, and the statistical indicators include: Low Trust Count: The number of event records under this source identifier that have been marked with a low trust tag; Participation count: The total number of event records that participated in the consistency check under this source identifier; Low confidence ratio: The ratio of low confidence counts to the number of counts that participated.

[0088] The event records participating in the consistency verification include at least the fragment request event records, fragment delivery event records, and fragment consumption event records that are associated with the unified closed-loop identifier; by using fixed statistical objects, the low-confidence ratio is comparable among different unified closed-loop identifiers, and can be backtracked and verified through the event record index.

[0089] Calculation and boundary handling of source credibility weight The processing platform calculates the source credibility weight for each source identifier in a unified closed-loop identifier dimension. The source credibility weight is determined by the quality base weight and the low credibility penalty factor, and is limited to a preset value range. Quality Basic Weights The processing platform normalizes sampling rate information, event missing information, reporting cycle fluctuation range, and field completeness information to obtain four quality sub-scores, each mapped to the range of 0 to 1. Normalization is implemented using a threshold truncation method: values ​​exceeding the upper threshold are calculated using the upper threshold, and values ​​below the lower threshold are calculated using the lower threshold, to avoid outliers causing drastic weight fluctuations. The basic quality weight is determined by a weighted sum of the quality sub-scores, with the weighting coefficients being configurable parameters and fixed throughout the system deployment.

[0090] Low credibility penalty factor The low-confidence penalty factor is determined by the low-confidence ratio; the larger the low-confidence ratio, the smaller the penalty factor. In this implementation, a monotonically decreasing penalty function is used to implement the penalty factor, and the intensity parameter of the penalty function is a configurable parameter. The processing platform obtains the source confidence weight of the source identifier under the unified closed-loop identifier by multiplying the quality base weight by the low-confidence penalty factor.

[0091] Cold start and non-convergence handling When the number of participants in a source identifier is less than the minimum sample size threshold within a preset statistical time period, the processing platform marks the source identifier as non-converged and uses a preset initial weight for conflict resolution. When the number of participants reaches the minimum sample size threshold, the processing platform calculates and replaces the weight with a convergence weight according to the above rules. The processing platform retains the quality sub-score, low confidence ratio and penalty factor values ​​used in the weight calculation for subsequent review and auditing.

[0092] Factual basis of the specification used for novelty and inventiveness arguments In video service monitoring with multiple acquisition locations, different sources exhibit objective differences in sampling strategies, field availability, reporting stability, and missing data. Furthermore, the consistency performance of the same source may vary across different closed-loop objects. This implementation method solidifies acquisition quality parameters into event log entries and statistically distributes low-confidence markers at the unified closed-loop identifier dimension. This allows the source confidence weight to simultaneously reflect the acquisition quality of the source and its consistency performance across the closed-loop object of that segment. This avoids misjudgment of local segments caused by relying solely on static source priority or a single quality indicator. It also provides a traceable data link for handling cross-source conflicts. This link is supported by event logs, low-confidence markers, inconsistency breakpoint markers, and intermediate quantities for weight calculation, facilitating review and implementation verification.

[0093] In this embodiment, the processing platform receives service event records and transmission event records from different acquisition locations. Since the local clocks at different acquisition locations are offset relative to a unified time base and the offset changes over time, the processing platform generates and outputs corresponding clock drift information for each source identifier while performing timestamp alignment processing. The clock drift information is used to record the offset state and changing trend of the source local clock relative to the same time base, and is used for subsequent segment time window expansion, tolerance threshold determination, and correlation verification.

[0094] Field definition and logging method for clock drift information The processing platform maintains a clock drift information record for each source identifier. To ensure that the alignment results are verifiable, this implementation method makes the following stipulations for the fields of the clock drift information record: Source identifier: Indicates the collection location or collection instance corresponding to this record; Reference time: Indicates the unified time reference anchor time corresponding to this record. The reference time is taken as the unified time reference time of the latest sample in the valid samples used to estimate the clock offset. Clock offset: This indicates the offset of the local clock relative to the unified time base at the reference time. The offset is calculated according to the sign convention of subtracting the unified time base timestamp from the local timestamp. A positive offset indicates that the local clock is ahead. Drift rate: Represents the rate at which the clock offset changes over time. The drift rate is determined by the change in offset per unit time. Measurement method identifier: This record is distinguished by whether it is determined by reference clock synchronization information or by the round-trip delay measurement result of the alignment message; Measurement uncertainty: The error limits of clock offset and drift rate are given. In this embodiment, the offset uncertainty is determined by the upper limit of the absolute value of the residual estimated by offset and the round-trip delay fluctuation range, and the drift rate uncertainty is determined by the upper limit of the fitted residual. Applicable Time Period: Indicates the effective time range for alignment correction of this record. The applicable time period starts from the reference time and ends at the effective time of the next drift record with the same source identifier. Record sequence number: Used to identify the update order of clock drift information records. The processing platform increments the record sequence number each time it updates a drift record from this source. When generating the alignment timestamp, the processing platform, in addition to outputting the alignment timestamp, also writes the source identifier, record number and reference time used in the alignment processing metadata of the event record, so as to verify the consistency between the alignment result and the drift information in the future. Determination method based on reference clock synchronization information In the first determination method, each acquisition device keeps synchronized with the reference clock corresponding to the unified time base and reports the reference clock synchronization information. The reference clock synchronization information includes at least the synchronization reference time, the synchronization offset, and the synchronization quality index. The synchronization offset is the offset of the local clock of the acquisition device relative to the reference clock, and the synchronization quality index is used to characterize the error limit or stability level of the offset.

[0095] The processing platform collects multiple synchronization offset samples for the same source identifier within a sliding statistical time period, and estimates the clock offset and drift rate accordingly: The clock offset is taken as the representative value of the synchronization offset sample within the sliding statistical time period. In this implementation, the median is used as the representative value to reduce the impact of abnormal samples. The drift rate is determined by the trend of the offset sample changing over time within the sliding statistical time period. In this implementation, the drift rate is obtained by linear fitting. Measurement uncertainty is determined by both the synchronous quality index and the fitting residual; the larger the fitting residual, the greater the uncertainty. When the number of samples within the sliding statistical time period is insufficient to form a fit, the processing platform only outputs the clock offset and sets the drift rate to zero, while marking the drift record of that source as non-converged; when the number of samples meets the fitting requirements, it is updated to a converged state and the drift rate is output. Determination method based on the round-trip delay measurement results of aligned messages In the second determination method, the processing platform and the acquisition device exchange alignment messages to measure round-trip time and estimate clock offset and drift rate accordingly. The alignment message exchange includes at least one request and one response, and the following four moments are recorded: The unified time reference for the platform to send requests; The local time at which the data acquisition device receives the request; The local time at which the acquisition device sends its response; The unified time reference moment for the processing platform to receive responses; The processing platform calculates the round-trip time based on the above four time points and estimates the clock offset under the premise that the link propagation delay is approximately symmetrical. In this embodiment, the processing platform performs multiple alignment message interactions within the sliding statistical time period and selects valid samples and calculates the offset according to the following rules: Calculate the round-trip latency for each interaction and select the top K interactions with the smallest round-trip latency as valid samples, where K is the processing platform configuration parameter; For each valid sample, calculate the estimated clock offset and take the median of the estimated clock offsets for that sliding statistical period as the clock offset. The fluctuation range of the round-trip time delay of the effective sample is written into the drift information record as a component of the offset uncertainty; After obtaining multiple offset estimates from the same source identifier, the processing platform estimates the drift rate according to the time series. In this embodiment, the drift rate is obtained by sliding fitting, which is consistent with the synchronization information of the reference clock. When the alignment message is lost or the round-trip delay deviates significantly, the processing platform determines the sample as an abnormal sample and removes it. The criteria for determining an abnormal sample are that the round-trip delay exceeds the preset upper limit threshold or exceeds the median round-trip delay plus the preset margin in the sliding statistical time period.

[0096] Alignment timestamp generation and drift information in subsequent stages When the processing platform generates an aligned timestamp for each event record, it reads the clock drift information record of the source identifier corresponding to the event record and performs correction on the original timestamp with the reference time as the anchor point. The correction includes offset correction and further includes drift correction when the drift rate converges, so that the aligned timestamp falls into a unified time base. The processing platform records the record number and reference time used when generating the aligned timestamp so that the alignment result can be verified.

[0097] In the subsequent process of determining the time window of a segment and associating it with the segment delivery event, the processing platform uses the offset uncertainty in the clock drift information to determine the time window expansion amount; in the process of data consistency verification and tolerance threshold determination, the processing platform uses the drift uncertainty as one of the inputs to the tolerance threshold to absorb the counting assignment deviation caused by the time alignment error.

[0098] The factual basis of the specification used for subsequent novelty and inventiveness arguments In video service monitoring with multiple acquisition locations, service events and transmission events are generated from different sources. The source clock offset and drift change over time, and the link delay fluctuates. If only a one-time offset correction is performed and the measurement process is discarded, it is difficult to stably support segment-level correlation and consistency verification under conditions of connection reuse, reporting delay fluctuations, and drift changes. This implementation outputs clock drift information oriented towards the source identifier during the timestamp alignment process, and records the offset, drift rate, uncertainty, applicable time period, and record number. This makes the alignment process and subsequent time window expansion and tolerance threshold determination form a traceable data link, thereby improving the verifiability of multi-source fusion monitoring results.

[0099] In this embodiment, the processing platform performs consistency checks on event records within the segment closed-loop object at the unified closed-loop identifier dimension. In addition to timing consistency checks, it also performs data volume consistency checks to determine whether the delivered byte count reflected by the transmission side and the consumed byte count reflected by the terminal side are consistent within the allowable error range. When the data volume consistency check fails, the processing platform generates a data volume difference breakpoint identifier and writes a low-confidence flag to the event record associated with the breakpoint identifier for use in subsequent conflict handling and attribution analysis.

[0100] To avoid misjudgments caused by differences in counting standards at different collection locations, this implementation method imposes unified constraints on the statistical objects of delivery byte count and consumption byte count, using the fragment payload bytes as the statistical object. Before performing data consistency verification, the processing platform first summarizes the delivery byte count within the same unified closed-loop identifier according to the source identifier, and the summary standard is consistent with the counting type of the source identifier. When the delivery byte count of the fragment delivery event record is an incremental count, the delivery byte count falling within the time window of that fragment is summed to obtain the summary value of the delivery byte count. When the delivery byte count is a cumulative count, the last cumulative value falling within the time window of that fragment is taken as the summary value of the delivery byte count. The consumption byte count is taken from the consumption byte count in the fragment consumption event record corresponding to the unified closed-loop identifier.

[0101] The processing platform uses the absolute difference between the sum of delivered byte counts and consumed byte counts as the data volume difference, and compares the data volume difference with the tolerance threshold. When the data volume difference does not exceed the tolerance threshold, the data volume consistency check is deemed to have passed. When the data volume difference exceeds the tolerance threshold, the data volume consistency check is deemed to have failed, a data volume difference breakpoint identifier is generated, and a low-confidence flag is written.

[0102] The tolerance threshold is determined by the processing platform based on the acquisition quality parameters and clock drift information. The acquisition quality parameters include event missing information, reporting cycle information, and field completeness information. The clock drift information includes offset uncertainty or round-trip delay fluctuation range. To ensure that the threshold determination process is verifiable, this implementation uses the source identifier as the statistical dimension. Within a preset statistical time period, the missing proportion, average reporting cycle, reporting cycle fluctuation range, and representative value of field completeness for the source identifier are generated. The clock drift information and uncertainty index corresponding to the source identifier are read. The processing platform uses the above inputs as the threshold calculation inputs and records a snapshot and calculation version number for each threshold calculation. The input snapshot includes at least the statistical time period identifier and the number of samples.

[0103] Regarding the threshold calculation rules, this implementation decomposes the tolerance threshold into the sum of a basic tolerance and a threshold increment. The basic tolerance is used to cover stable factors such as differences in encoding and encapsulation overhead, acquisition boundary differences, and player statistical boundary differences. The basic tolerance is determined by the processing platform during system deployment according to the encoding level configuration corresponding to the resource identifier. The encoding level configuration comes from the existing encoding parameter configuration or playlist metadata of the video service and remains fixed under the same resource type or the same bitrate level. The threshold increment is used to cover uncertainties introduced by missing values, unstable reporting, incomplete fields, and time alignment errors. The threshold increment is obtained by mapping four types of inputs. The mapped increments are all non-negative values ​​and are subject to upper and lower limits. The larger the missing ratio, the larger the corresponding missing increment; the larger the reporting cycle fluctuation range, the larger the corresponding fluctuation increment; the lower the field completeness, the larger the corresponding completeness increment; the greater the clock drift uncertainty, the larger the corresponding drift increment. The processing platform uses amplitude limiting processing for each increment to avoid abnormal inputs causing unreasonable amplification or excessive tightening of the threshold, and the amplitude limiting threshold is fixed as a configuration parameter.

[0104] When the number of samples for a certain source identifier is insufficient to stably calculate the missing proportion or the representative value of field completeness within a preset statistical time period, the processing platform marks the source identifier as non-converged and takes the upper limit value of the corresponding incremental item in the threshold calculation until the number of samples meets the minimum sample number threshold before switching to converged calculation results. In this way, the tolerance threshold can be adaptively adjusted according to the changes in source quality and alignment uncertainty, while keeping the threshold calculation process traceable and verifiable.

[0105] To differentiate itself substantially from existing technologies, this implementation does not employ a fixed threshold or a single indicator threshold. Instead, it incorporates event missing information, reporting cycle information, field completeness information, and clock drift information into the tolerance threshold determination link. This ensures that the threshold can stably support data consistency verification at the fragment granularity under conditions of changes in source quality and alignment error, and forms a consistent data basis link with breakpoint location and low-confidence marker writing.

[0106] In this embodiment, the processing platform uniformly associates the service event record set and the transmission event record set at the fragment granularity, and constructs a fragment closed-loop object and a unified closed-loop identifier under a unified time reference. The service event record usually contains a resource identifier and a fragment identifier used to point to the fragment. In some terminal-side acquisition scenarios, the service event record may lack a fragment identifier, but still contains fragment sequence number information used to indicate the sequential position of the fragment. In order to enable such service event records to still enter the fragment closed-loop object construction process, the processing platform generates a fragment replacement identifier under the condition that the fragment identifier is missing but the fragment sequence number information is valid, and uses the fragment replacement identifier to participate in the construction of the fragment closed-loop object and the generation of the unified closed-loop identifier.

[0107] Determining the validity of missing fragment identifiers and fragment sequence information. The processing platform performs field validity checks on business event records to determine whether a fragment identifier is missing. The processing platform determines that a fragment identifier is missing if any of the following conditions are met: The business event log does not contain a fragment identifier field; The fragment identifier field is empty or contains only whitespace characters; The fragment identifier field does not meet the preset format constraints, which include at least character set constraints and length constraints. The processing platform performs a numerical validity check on the segment number information to determine whether the segment number information is valid. The segment number information is considered valid if it meets the following conditions: The segment number information can be parsed into a non-negative integer; Within the sliding statistical time period within the same resource identifier range, the segment sequence information does not repeatedly roll back. Repeated rollback means that the difference between the segment sequence information of two adjacent business event records is less than zero and the absolute value exceeds the first threshold. The first threshold is a preset value of the processing platform. When a fragment identifier is missing and the fragment sequence number information is invalid, the processing platform does not generate a fragment replacement identifier and marks the business event record as having incomplete fields, so that it can be used as a candidate input for low-confidence marking in the subsequent consistency verification and credibility processing process; Standardization of resource identification and fragment number information When a fragment identifier is missing but the fragment sequence number information is valid, the processing platform reads the resource identifier and fragment sequence number information from the business event record and performs standardized processing on them to ensure that different sources represent the same resource and the same fragment sequence number in a consistent manner.

[0108] The standardization of resource identification in this embodiment includes at least the following: Perform whitespace removal on the resource identifier; Normalize the path separators in the resource identifiers to make them adopt a uniform separator format; The resource identifier is processed using a unified character set encoding, and case-sensitive fields are uniformly converted to the same uppercase and lowercase form according to preset rules.

[0109] In this embodiment, the standardization of fragment sequence information includes converting the fragment sequence information into a decimal string and removing leading zeros to obtain a standard value for the fragment sequence number.

[0110] Generation and writing of fragment substitution identifiers The processing platform generates fragment replacement identifiers according to deterministic combination rules. In this embodiment, the deterministic combination rules are implemented by string concatenation, that is, the resource identifier standard value and the fragment sequence number standard value are connected by a preset separator to generate fragment replacement identifiers. The preset separator is fixedly configured by the processing platform during deployment and remains consistent across all data collection sources.

[0111] The processing platform writes the generated fragment replacement identifier into the alignment processing metadata of the business event record and uses it as one of the fragment index fields in the subsequent fragment closure object construction, while retaining the standard value of the fragment sequence number for retrospective verification.

[0112] Fragment closed-loop object construction and unified closed-loop identifier generation When constructing a fragment closed-loop object, the processing platform uses the resource identifier and fragment identifier or fragment substitution identifier as the fragment indexing condition: When the fragment identifier is valid, the fragment closure object is determined by the resource identifier and the fragment identifier; When a fragment identifier is missing but a fragment substitution identifier is valid, the fragment loop object is determined by the resource identifier and the fragment substitution identifier, and the standard value of the fragment sequence number is recorded within the loop object.

[0113] When generating a unified closed-loop identifier for a fragment closed-loop object, the processing platform uses a set of fields consistent with the fragment index conditions: when the fragment closed-loop object is determined by the resource identifier and the fragment identifier, the unified closed-loop identifier is generated from the resource identifier and the fragment identifier; when the fragment closed-loop object is determined by the resource identifier and the fragment substitution identifier, the unified closed-loop identifier is generated from the resource identifier and the fragment substitution identifier. The processing platform establishes a mapping relationship between the unified closed-loop identifier and its generation input fields, and retains the mapping record sequence number so as to verify the generation basis of the unified closed-loop identifier in subsequent consistency verification and breakpoint location.

[0114] Division handling and record keeping in conflict situations To mitigate the risk of misattribution caused by resource updates, playlist changes, or replays, this implementation introduces conflict splitting rules for segment replacement identifiers. Under the condition of the same resource identifier and the same segment replacement identifier, the processing platform checks whether the segment time windows of business event records overlap by grouping them according to connection elements. When more than two segment request event records appear within the same connection element group, and the corresponding segment time windows overlap, the processing platform does not merge them into the same segment closed-loop object, but splits them into different segment closed-loop objects according to the segment time windows, and writes a conflict trace mark to the index of the event record that triggered the split. When generating inconsistent breakpoint identifiers in the future, the processing platform uses the event record index corresponding to the conflict trace mark as one of the inputs for breakpoint location to ensure that the source of the anomaly is traceable and to avoid erroneous merging from expanding the scope of impact.

[0115] Through the aforementioned fragment substitution identifier mechanism, when the terminal cannot stably provide fragment identifiers but can provide fragment sequence number information, the processing platform can still construct a deterministic fragment index under resource identifier constraints, and maintain consistency between the fragment closed-loop object construction rules and the unified closed-loop identifier generation rules. This enables such business event records to enter the fragment-level closed-loop association, consistency verification, and breakpoint location processes, thereby providing a verifiable data foundation for the subsequent generation of integrated monitoring data.

[0116] In this embodiment, after completing timestamp alignment, fragment closed-loop object construction, and consistency verification, the processing platform generates inconsistency breakpoint identifiers for cases where verification fails, and associates and saves the inconsistency breakpoint identifiers with the unified closed-loop identifier. Based on low-trust flags and source trust weights, the processing platform performs conflict resolution on cross-source conflicts occurring under the same unified closed-loop identifier to obtain fused monitoring data. Subsequently, the processing platform performs anomaly determination based on the fused monitoring data and inconsistency breakpoint identifiers, and generates fault attribution object identifiers when an anomaly is determined, enabling the anomaly to be traced back, located, and attributed at the unified closed-loop identifier dimension.

[0117] Event record index generation and referencing criteria When the processing platform receives an event record reported from any collection location, it assigns an event record index to that event record. The event record index is a unique identifier generated internally by the processing platform, used to point to a specific entry in the event storage and supporting backtracking. To ensure that the index is verifiable, the event record index is associated with and stored together with at least the following metadata: source identifier, reception time, reception sequence number, event type, alignment timestamp, and unified closed-loop identifier (if it has been generated at that time). When duplicate or delayed reporting occurs, the processing platform deduplicates or aggregates the event records based on the source identifier and reception sequence number, and retains the index mapping relationship before and after deduplication for verification of breakpoint basis.

[0118] Data structure and generation rules for inconsistent breakpoint identifiers The processing platform performs consistency checks on related event records at the unified closed-loop identifier dimension. When the consistency check fails, the processing platform generates an inconsistent breakpoint identifier and writes it to the breakpoint storage. Each inconsistent breakpoint identifier includes at least: breakpoint type, unified closed-loop identifier corresponding to the breakpoint, event record index set, and breakpoint generation time. The event record index set includes at least the event record indexes necessary to trigger the breakpoint determination, and may include related event record indexes for comparison and verification.

[0119] In this implementation, breakpoint types include reverse order breakpoints, missing breakpoints, and data volume difference breakpoints. The triggering conditions and index filling rules are as follows: Reverse breakpoints Under the same unified closed-loop identifier, the processing platform reads the alignment timestamps of fragment request event records, fragment delivery event records, and fragment consumption event records, and performs timing judgment according to the following criteria: the alignment timestamp of the fragment request event record should not be later than the minimum alignment timestamp in the fragment delivery event record set, and the maximum alignment timestamp in the fragment delivery event record set should not be later than the alignment timestamp of the fragment consumption event record. If any condition is not met, the processing platform generates a reverse breakpoint. The event record index set for reverse breakpoints includes at least the fragment request event record index, the fragment consumption event record index, and the event record index corresponding to the minimum and maximum aligned timestamp values ​​in the fragment delivery event record set. The processing platform also writes the minimum and maximum aligned timestamps for judgment into the breakpoint attachment fields for verification.

[0120] Missing breakpoints Under the same unified closed-loop identifier, when at least one of the necessary event types in the missing fragment request event record, missing fragment delivery event record, or missing fragment consumption event record is detected, the processing platform generates a missing breakpoint. To avoid misjudgment caused by reporting delay, the processing platform sets a waiting window before missing determination and generates a missing breakpoint if the missing event is still detected after the waiting window ends. The waiting window is determined by the processing platform based on the reporting cycle information and clock drift information of the source identifier, and at least meets the following criteria: the waiting window is not less than the sum of the average value of the reporting cycle and the fluctuation range of the reporting cycle, and is superimposed with the time margin corresponding to the clock drift uncertainty; the minimum and maximum values ​​of the waiting window are configured and fixed by the processing platform; the event record index set of the missing breakpoint contains the existing adjacent related event record index, and the missing event type identifier and the waiting window parameters used are written in the breakpoint attachment field to verify the basis for the formation of the missing breakpoint.

[0121] Data volume difference breakpoint Under the same unified closed-loop identifier, the processing platform obtains the delivered byte count and consumed byte count according to the established statistical caliber, and calculates the data volume difference value as the absolute value of the difference between the two; when the data volume difference value exceeds the tolerance threshold, the processing platform generates a data volume difference breakpoint; the event record index set of the data volume difference breakpoint includes at least the fragment delivery event record index set and the fragment consumption event record index used to form the delivered byte count, and writes the data volume difference value, tolerance threshold, and tolerance threshold version number into the breakpoint attachment field, so as to verify the impact of the threshold convergence state change on the breakpoint result; Once any breakpoint is generated, the processing platform writes a low-trust flag to the event record pointed to by the event record index corresponding to the breakpoint. The low-trust flag is associated with at least the breakpoint type, the unified closed-loop identifier, and the event record index, and records the writing time and the type of writing reason, so that subsequent conflict resolution can filter or reduce the weight of the value source based on the low-trust flag.

[0122] Cross-source conflict identification and resolution process In this embodiment, cross-source conflict refers to the occurrence of multiple inconsistent values ​​for the same indicator item from different sources under the same unified closed-loop identifier. The indicator item includes at least the delivered byte count, consumed byte count, and data volume difference value. The processing platform collects the values ​​of the same indicator item from each source at the unified closed-loop identifier dimension, and simultaneously reads whether the event record corresponding to the value has a low-trust mark and the source trust weight of the source, forming a conflict processing input set.

[0123] Conflict resolution includes two strategies: prioritization and weighted fusion, and is carried out according to the following deterministic rules.

[0124] Low-confidence screening If there are values ​​without low-confidence tags in the conflict processing input set, the values ​​with low-confidence tags are removed, and only the values ​​without low-confidence tags are retained for subsequent processing; if all values ​​have low-confidence tags, all values ​​are retained for subsequent processing, and an overall low-confidence tag is written into the fused monitoring data to indicate that the overall credibility of the data under the unified closed-loop identifier is insufficient.

[0125] Priority selection rules Within the retained set of values, the processing platform searches for the maximum value of the source credibility weight. If the maximum value is unique, the value of the source corresponding to the maximum weight is selected as the fusion value. The selected source identifier, source credibility weight, and conflict resolution strategy type are recorded. If there are ties in the maximum values, the fusion value is selected according to the preset source priority order, which is configured and fixed by the processing platform. At the same time, the tie information is written into the fusion monitoring data for verification.

[0126] Weighted fusion rules The processing platform adopts weighted fusion when any of the following conditions are met: there are no available priority selection results in the retained value set, or the source credibility weights of the retained values ​​are all zero, or the weights are missing, making it impossible to form a unique maximum value and no source priority is configured. During weighted fusion, the processing platform performs non-negation and normalization processing on the source credibility weights participating in the fusion, so that the sum of the weights is one, and uses the weighted average of each source value and its normalized weight as the fusion value. For missing values ​​or unparseable values, the processing platform removes them and re-normalizes the remaining weights. If the input set is empty after removal, the fusion value of the indicator item is set to an invalid value and written to the fusion failure flag and the corresponding unified closed loop identifier.

[0127] Through the above rules, conflict resolution forms a deterministic output in the unified closed-loop identifier dimension, while retaining the strategy type, selected source, weight and parallel information, so that the fusion result can be verified for its formation basis.

[0128] Anomaly detection based on fused monitoring data After obtaining the fusion monitoring data, the processing platform performs anomaly detection at the unified closed-loop identifier dimension. The fusion monitoring data includes at least the fusion value of the delivered byte count and the fusion value of the consumed byte count. Based on this, the processing platform calculates the difference in the amount of fusion data as the absolute value of the difference between the two, and uses it for anomaly detection.

[0129] Anomaly detection includes at least two types of conditions: Data volume difference condition: When the difference in the amount of fused data exceeds the tolerance threshold, the segment closed loop object corresponding to the unified closed loop identifier is determined to be abnormal, and the tolerance threshold and threshold version number used at that time are written into the abnormal record.

[0130] Breakpoint Quantity Condition: The processing platform counts the number of inconsistent breakpoint identifiers generated under this unified closed-loop identifier and compares it with the breakpoint threshold. When the number of inconsistent breakpoint identifiers exceeds the breakpoint threshold, it is determined to be an anomaly. The breakpoint threshold is a configuration parameter of the processing platform and can be configured hierarchically according to resource type or source category. To ensure consistency in verification, the processing platform writes the breakpoint threshold version number into the anomaly record.

[0131] When any condition is met, the processing platform generates an anomaly marker and associates and saves the anomaly marker with the unified closed-loop identifier, the set of inconsistent breakpoint identifiers, and the snapshot of the fused monitoring data.

[0132] Rules for generating and determining fault attribution object identifiers When the processing platform determines an anomaly in the unified closed-loop identification dimension, it generates a fault attribution object identifier. The fault attribution object identifier includes at least an object type field and an object identifier field. The object type field can take one of the following values: terminal, edge node, service node, and network path. The object identifier field corresponds to the object type field and can take the terminal identifier, edge node identifier, service node identifier, or connection element, respectively.

[0133] The object type field is determined by comparing the number of inconsistent breakpoint identifiers from different source categories. The processing platform groups the inconsistent breakpoint identifiers under the unified closed-loop identifier by source category and counts the number of breakpoints. The source category corresponds to the collection location and includes at least terminal-side source, edge node-side source, service node-side source, and network device-side source. The processing platform selects the source category with the largest number of breakpoints as the dominant source category and maps it to the value of the object type field. Specifically, terminal-side source is mapped to terminal, edge node-side source is mapped to edge node, service node-side source is mapped to service node, and network device-side source is mapped to network path. If there are source categories with the same number of breakpoints, the value of the object type field is determined according to a preset priority rule. The priority rule is configured and fixed by the processing platform, and the tied information is written into the attribution record for verification.

[0134] The object identifier field is taken from the event record pointed to by the event record index corresponding to the object type field. After determining the object type field, the processing platform selects the attribution index from the set of breakpoints belonging to the dominant source category. The selection rules for the attribution index are as follows: priority is given to the event record index that triggers the data volume difference breakpoint; if there is no data volume difference breakpoint, then the event record index that triggers the reverse order breakpoint is selected; if it still does not exist, then the event record index that triggers the missing breakpoint is selected. The processing platform reads the event record pointed to by the attribution index and extracts the object identifier field: when the object type field is a terminal, the terminal identifier is extracted; when the object type field is an edge node, the edge node identifier is extracted; when the object type field is a service node, the service node identifier is extracted; when the object type field is a network path, the connection element is extracted. The connection elements include terminal identifier, edge node identifier, service node identifier, connection identifier, and at least one of the following five-tuples: source address, destination address, source port, destination port, and transport layer protocol. The processing platform writes the object identifier field into the fault attribution object identifier and saves the attribution index, breakpoint distribution statistics, and priority rule version number in the attribution record for subsequent verification of the attribution basis.

[0135] Factual basis of the specification used for novelty and inventiveness arguments In multi-source video monitoring scenarios, missing events, disordered timing, and inconsistent counting often occur in an intertwined manner. Simply outputting the fusion results without providing breakpoint type representations and event record index-level traceability makes it difficult to support traceable positioning at the segment level. This implementation method generates an inconsistent breakpoint identifier that includes breakpoint type, unified closed-loop identifier, and event record index during the consistency verification stage. It also binds the low-confidence marker to the breakpoint index, enabling conflict resolution to form a deterministic output by combining the source confidence weight at the unified closed-loop identifier dimension. At the same time, it generates a fault attribution object identifier based on the breakpoint distribution when an anomaly occurs, thereby connecting verification, fusion, and attribution into a verifiable data basis link.

[0136] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0137] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A multi-source traffic integrated monitoring system for video services, characterized in that: This includes distributed acquisition devices, processing platforms, and interface service devices; The distributed acquisition device is deployed in at least two of the following locations: terminal side, edge node side, service node side, and network device side, and is used to generate and report event records. The event log shall at least include a source identifier, an event timestamp, a resource identifier, and a fragment identifier or fragment sequence number; The processing platform aligns event timestamps from different sources to obtain a unified time base, and constructs a segment closed-loop object based on the resource identifier and the segment identifier or segment sequence number information. It generates a unified closed-loop identifier for each segment closed-loop object and associates it with event records from different sources. The processing platform performs consistency checks on associated event records under the same unified closed-loop identifier, generates inconsistency breakpoint identifiers, and writes low-confidence tags to event records associated with inconsistency breakpoint identifiers. The processing platform forms source credibility weights based on the low-credibility markers, and when there are inconsistent values ​​for the same indicator under the same unified closed-loop identifier, it removes the values ​​with low-credibility markers, performs conflict resolution, and outputs fused monitoring data. The interface service device outputs the fusion monitoring data and the inconsistency breakpoint identifiers corresponding to the fusion monitoring data.

2. The multi-source traffic integration monitoring system for video services according to claim 1, characterized in that: The event logs include a set of business event logs and a set of transmission event logs; The business event record set includes at least fragment request event records and fragment consumption event records, and the fragment consumption event records include the consumed byte count; The transmission event record set includes at least fragment delivery event records, which include a delivered byte count and connection elements. The connection elements include at least one of terminal identifier, edge node identifier, service node identifier, connection identifier, and quintuple.

3. The multi-source traffic integration monitoring system for video services according to claim 2, characterized in that: The processing platform determines the segment time window under the same connection element and associates the segment delivery event records whose timestamps fall into the segment time window under the unified time base with the corresponding segment closed loop object.

4. The multi-source traffic integration monitoring system for video services according to claim 3, characterized in that: Each event record also includes collection quality parameters, which include sampling rate information, event missing information, reporting cycle information, and field completeness information; the source credibility weight is determined based on the collection quality parameters and the distribution of the low credibility markers on the unified closed-loop identifier dimension.

5. A multi-source traffic integration monitoring system for video services according to claim 4, characterized in that: The processing platform outputs clock drift information corresponding to each source during the timestamp alignment process. The clock drift information is determined by the round-trip delay measurement results of the reference clock synchronization information or alignment message.

6. A multi-source traffic integration monitoring system for video services according to claim 5, characterized in that: The consistency check includes a data volume consistency check, which is used to compare whether the difference between the delivered byte count and the consumed byte count does not exceed a tolerance threshold. The tolerance threshold is determined by the processing platform based on event missing information, reporting cycle information, field completeness information, and clock drift information.

7. A multi-source traffic integration monitoring system for video services according to claim 6, characterized in that: When a fragment identifier is missing in a business event record but fragment sequence number information exists, the processing platform combines the resource identifier and fragment sequence number information to generate a fragment replacement identifier, and uses the fragment replacement identifier to participate in the construction of the fragment closed-loop object and the generation of the unified closed-loop identifier.

8. A multi-source traffic integration monitoring system for video services according to claim 7, characterized in that: The inconsistent breakpoint identifier includes the breakpoint type, the unified closed-loop identifier corresponding to the breakpoint, and the event record index corresponding to the breakpoint. The event record index includes the event record index necessary to trigger the breakpoint determination, and may include the associated event record index for comparison and verification. The breakpoint type includes at least one of reverse order breakpoint, missing breakpoint, and data volume difference breakpoint.

9. A multi-source traffic integration monitoring system for video services according to claim 8, characterized in that: The conflict resolution includes priority selection and weighted fusion; when the value of the source corresponding to the highest source confidence weight of the corresponding indicator item under the same unified closed loop identifier does not have a low confidence mark, priority selection is used to output the fused monitoring data. Otherwise, the fused monitoring data is output using weighted fusion, where the fused value is a weighted average of the values ​​from each source and their source credibility weights.

10. A multi-source traffic integration monitoring system for video services according to claim 9, characterized in that: The processing platform performs anomaly determination based on the fused monitoring data. The anomaly determination includes: when the data volume difference exceeds the tolerance threshold or the number of inconsistent breakpoints exceeds the breakpoint threshold under the same unified closed-loop identifier, it is determined to be an anomaly. When an anomaly is detected, a fault attribution object identifier is generated. The fault attribution object identifier includes an object type field and an object identifier field. The object type field takes the value of one of the following: terminal, edge node, service node, and network path. The object identifier field takes the value of the terminal identifier, edge node identifier, service node identifier, or connection element corresponding to the object type field. The object type field is determined by comparing the number of inconsistent breakpoint identifiers from different sources. The object identifier field is taken from the event record pointed to by the event record index corresponding to the object type field.

Images