Website performance monitoring method and system based on big data analysis and cloud collaboration

Abstract

The application discloses a website performance monitoring method and system based on big data analysis and cloud cooperation, relates to the technical field of website performance monitoring, and comprises the following steps: collecting website performance correlation data and performing standardized processing to generate a website performance monitoring dataset; distributing monitoring tasks to monitoring nodes to generate a cross-regional cooperative monitoring sample sequence; generating a website performance monitoring object set based on the cross-regional cooperative monitoring sample sequence; constructing a website performance space-time heterogeneous graph; generating a cross-regional dynamic performance baseline based on a historical website performance space-time heterogeneous graph; comparing a current website performance space-time heterogeneous graph with the cross-regional dynamic performance baseline to generate a website performance anomaly event set; extracting a website performance anomaly correlation subgraph and inputting the same into an improved HGT anomaly attribution model to output a website performance anomaly source result and a website performance anomaly influence range result. The application can improve website performance anomaly recognition accuracy and anomaly source positioning efficiency.

Description

Technical Field

[0001] This invention relates to the field of website performance monitoring technology, and in particular to a website performance monitoring method and system based on big data analysis and cloud collaboration. Background Technology

[0002] In recent years, with the development of cloud computing, distributed deployment, content delivery networks, microservice architecture, and intelligent website operation and maintenance technologies, the website access chain has gradually transformed from a single server response to a complex process involving cross-regional node access, page resource loading, API service calls, runtime instance hosting, and user session interaction. Existing website performance monitoring technologies typically collect data on page loading time, API response time, link latency, server resource utilization, and access status through probe nodes, log collection components, or application performance management platforms, and then clean, statistically analyze, and display the collected data. Some solutions also set fixed alarm thresholds to provide alerts for response timeouts, access failures, resource overload, and link unreachability, assisting operations and maintenance personnel in assessing the website's operational status.

[0003] However, existing website performance monitoring solutions still suffer from difficulties in accurately identifying the source and scope of anomalies. On one hand, access performance data, network link data, service call data, runtime resource data, and user access behavior data are typically scattered across different collection points and operation and maintenance systems, lacking a unified approach to object identification and correlation modeling, making it difficult to establish structured relationships between monitoring nodes, access scenarios, access objects, service objects, and runtime objects. On the other hand, existing solutions often rely on fixed thresholds or single-indicator fluctuations to determine anomalies, lacking dynamic baseline generation and regional difference calibration mechanisms based on historical website performance spatiotemporal heterogeneity maps. They also fail to adequately utilize cross-regional access environment differences, interface call dependencies, resource carrying relationships, and link routing relationships, resulting in performance anomalies only manifesting as slow response, call failures, or resource anomaly alarms, making it difficult to further locate the source of the anomaly and determine the affected access scope. Summary of the Invention

[0004] One objective of this invention is to propose a website performance monitoring method and system based on big data analysis and cloud collaboration. This invention fully utilizes big data fusion analysis, cloud collaborative monitoring, and heterogeneous graph intelligent attribution technology to construct a spatiotemporal heterogeneous graph of website performance. It combines cross-regional dynamic performance baselines with an improved HGT anomaly attribution model to achieve website performance anomaly identification, source location, and impact range analysis. It has the advantages of comprehensive monitoring dimensions, accurate anomaly judgment, strong cross-regional adaptability, and high fault location efficiency.

[0005] The website performance monitoring method based on big data analysis and cloud collaboration according to embodiments of the present invention includes the following steps: Collect website performance-related data and perform standardized processing to generate a website performance monitoring dataset; The cloud assigns monitoring tasks to monitoring nodes based on regional location, network environment, and access point, receives website performance monitoring data returned by the monitoring nodes, and generates cross-regional collaborative monitoring sample sequences. Based on cross-regional collaborative monitoring sample sequences, monitoring nodes, access scenarios, access objects, service objects, and running objects are identified to generate a set of website performance monitoring objects; Based on the access dependencies, call dependencies, resource bearing relationships, and regional routing relationships in the website performance monitoring object set, construct a spatiotemporal heterogeneity graph of website performance; Based on historical website performance spatiotemporal heterogeneity graphs, benchmark selection, time-series aggregation, and regional difference calibration are performed to generate cross-regional dynamic performance baselines. The current website performance spatiotemporal heterogeneous graph is compared with the cross-regional dynamic performance baseline. The results of the deviation comparison are organized into events according to the abnormal time window, abnormal object, abnormal type and abnormal intensity, and a set of website performance abnormal events is generated. The set of website performance anomaly events is mapped to a spatiotemporal heterogeneous graph of website performance. A subgraph of website performance anomaly correlation is extracted. The subgraph of website performance anomaly correlation is input into the improved HGT anomaly attribution model to generate anomaly contribution results. Based on the anomaly contribution results, the source results and the scope of impact of website performance anomalies are determined, and the website performance monitoring results are output.

[0006] Optionally, the website performance-related data includes access performance data, network link data, service call data, runtime resource data, and user access behavior data. The standardization process includes unified timestamps, unified node identifiers, unified object numbers, unified indicator units, aligned sampling frequencies, completed missing data, removed abnormal formats, merged duplicate records, configured regional labels, and bound access sessions.

[0007] Optionally, the generation of the cross-regional collaborative monitoring sample sequence includes: The cloud acquires the regional location, network environment, access entry, node load status and available sampling frequency of each monitoring node, and generates a node monitoring task table according to the regional coverage integrity, access entry matching degree and node load balance. Based on the node monitoring task table, page access monitoring tasks, interface call monitoring tasks, and link status monitoring tasks are issued to the corresponding monitoring nodes, and task numbers, sampling time windows, sampling periods, and feedback formats are configured for each monitoring task. The monitoring nodes access the corresponding access points according to the monitoring tasks, collect website performance monitoring data, and generate node-back data packets. The cloud receives data packets transmitted back from nodes, merges the data according to task number, node identifier and sampling time window, and extracts service call data and runtime resource data within the same sampling time window from the website performance monitoring dataset for correlation, generating a cross-regional collaborative monitoring sample sequence arranged according to regional location, network environment, access point and sampling time.

[0008] Optionally, the generation of the website performance monitoring object set includes: The cross-regional collaborative monitoring sample sequences are grouped according to sampling time window, node identifier, regional location, network environment and access point, and the monitoring nodes that perform monitoring tasks are identified and monitoring node objects are generated. The system identifies access scenarios and generates access scenario objects based on a combination of regional location, network environment, access point, and sampling time window. Identify access objects and generate access object records based on page paths, resource addresses, and access status markers; Identify service objects and generate service object records based on interface addresses, call identifiers, and service identifiers; Runtime objects are identified and runtime object records are generated based on host identifier, container identifier, instance identifier, and resource indicator identifier; The monitoring node objects, access scenario objects, access object records, service object records, and running object records are merged according to object number, object type, attribution relationship, and sampling time window to generate a website performance monitoring object set.

[0009] Optionally, the construction of the website performance spatiotemporal heterogeneity graph includes: Configure the monitoring node objects, access scenario objects, access object records, service object records, and running object records in the website performance monitoring object set as different types of graph nodes, and configure the graph nodes with object number, object type, sampling time window, and performance status attributes; Establish access dependencies based on access records between monitoring node objects, access scenario objects, and access object records; Establish call dependencies based on the interface call records between access object records and service object records; Establish resource bearing relationships based on deployment records between service object records and runtime object records; Establish regional routing relationships based on link detection records between monitoring node objects, regional locations, network environments, and access points; Configure access dependencies, call dependencies, resource hosting relationships, and regional routing relationships as different types of graph edges, and configure sampling time windows, relationship types, performance metrics, and edge weights for the graph edges to construct a spatiotemporal heterogeneous graph of website performance.

[0010] Optionally, the generation of the cross-regional dynamic performance baseline includes: The website performance spatiotemporal heterogeneity graph is continuously saved according to the sampling time window to form a historical website performance spatiotemporal heterogeneity graph. Based on access status, call status, instance running status, link reachability status, and edge weight, a historical website performance spatiotemporal heterogeneous graph is filtered to generate a historical benchmark graph sequence. The historical benchmark graph sequence is grouped according to object type, relationship type, regional location, network environment and access point. The performance status attributes, performance indicators and edge weights within each group are aggregated in time series to generate the group performance benchmark sequence. Regional difference calibration is performed based on the packet performance benchmark sequences of the same access point in different regional locations and network environments to generate a cross-regional dynamic performance baseline that includes the baseline center value, fluctuation boundary, regional calibration coefficient and update time stamp.

[0011] Optionally, the generation of the website performance anomaly event set includes: Perform regional calibration on the performance status attributes, performance indicators and edge weights in the current website performance spatiotemporal heterogeneity graph, and compare the deviation with the corresponding fluctuation boundary to generate a deviation comparison record. Based on the deviation comparison records, the sampling time window, graph node or graph edge, deviation source and deviation magnitude are determined, and the abnormal time window, abnormal object, abnormal type and abnormal intensity are generated respectively. By merging deviation comparison records with the same abnormal time window, the same abnormal object, or the same relationship type, a set of website performance abnormal events is generated.

[0012] Optionally, the generation of the website performance monitoring results includes: The set of website performance anomaly events is mapped to the website performance spatiotemporal heterogeneous graph according to the anomaly time window and the anomaly object. The corresponding graph nodes or graph edges are located, and the associated nodes and associated graph edges within the same sampling time window are extracted along the access dependency edge, call dependency edge, resource bearing edge and regional routing edge to generate the website performance anomaly associated subgraph. The website performance anomaly correlation subgraph is input into the improved HGT anomaly attribution model. The improved HGT anomaly attribution model includes an event mapping layer, a heterogeneous encoding layer, a relational attention propagation layer, and a contribution output layer. In the event mapping layer, anomaly intensity, performance status attributes, performance metrics, and edge weights are combined into anomaly subgraph features; In the heterogeneous coding layer, type coding is configured for different types of graph nodes and graph edges; In the relational attention propagation layer, attention is propagated according to different relation types to generate node contribution and edge contribution. In the contribution output layer, the source of website performance anomalies is determined based on node contribution, and the scope of impact of website performance anomalies is determined based on edge contribution. The combined output results are then used to monitor website performance.

[0013] A website performance monitoring system based on big data analysis and cloud collaboration according to an embodiment of the present invention includes: The data processing module is used to collect and standardize website performance-related data to generate website performance monitoring datasets. The collaborative monitoring module is used to assign monitoring tasks to monitoring nodes and generate cross-regional collaborative monitoring sample sequences; The object recognition module is used to identify monitoring nodes, access scenarios, access objects, service objects, and running objects, and generate a set of website performance monitoring objects; The heterogeneous graph construction module is used to build a spatiotemporal heterogeneous graph of website performance. The baseline generation module is used to generate dynamic performance baselines across regions; The abnormal event generation module is used to compare the deviation between the current website performance spatiotemporal heterogeneity graph and the cross-regional dynamic performance baseline to generate a set of website performance abnormal events. The attribution output module is used to generate results on the source of website performance anomalies, the scope of impact of website performance anomalies, and website performance monitoring results based on the set of website performance anomaly events and the improved HGT anomaly attribution model.

[0014] The beneficial effects of this invention are: This invention identifies monitoring nodes, access scenarios, access objects, service objects, and running objects based on cross-regional collaborative monitoring sample sequences. It constructs a spatiotemporal heterogeneity graph of website performance based on access dependencies, call dependencies, resource carrying relationships, and regional routing relationships, creating a structured relational expression between page access, interface calls, service deployment, resource carrying, and link detection. By performing benchmark screening, time-series aggregation, and regional difference calibration using historical website performance spatiotemporal heterogeneity graphs, a cross-regional dynamic performance baseline is generated. This eliminates the reliance on fixed thresholds for anomaly detection, instead combining historical operating states, regional access differences, and performance fluctuation boundaries under different relationship types for deviation comparison, thereby improving the accuracy of identifying sudden performance anomalies and gradual performance degradation.

[0015] This invention organizes deviation comparison results into a set of website performance anomaly events based on anomaly time windows, anomaly objects, anomaly types, and anomaly intensities. This set of events is then mapped to a website performance spatiotemporal heterogeneous graph to extract a subgraph of website performance anomaly relationships. This expands the anomaly analysis object from a single indicator to nodes, edges, and propagation paths related to the anomaly. By improving the HGT anomaly attribution model, relational attention propagation and contribution calculation are performed on the website performance anomaly relationship subgraph, generating anomaly contribution results. Based on these results, the source and impact range of the website performance anomaly are determined. This enables the monitoring results to output specific anomaly source objects, affected access ranges, and related propagation paths, reducing the complexity of manual troubleshooting in multi-source logs and multi-level service links for operations and maintenance personnel, and improving the efficiency of website performance anomaly location, impact assessment, and handling decisions. Attached Figure Description

[0016] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is an overall flowchart of the website performance monitoring method based on big data analysis and cloud collaboration proposed in this invention; Figure 2 This diagram illustrates the generation of website performance monitoring results using the website performance monitoring method based on big data analysis and cloud collaboration proposed in this invention. Detailed Implementation

[0017] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0018] refer to Figures 1-2 A website performance monitoring method based on big data analysis and cloud collaboration includes the following steps: Collect website performance-related data and perform standardized processing to generate a website performance monitoring dataset; The cloud assigns monitoring tasks to monitoring nodes based on regional location, network environment, and access point, receives website performance monitoring data returned by the monitoring nodes, and generates cross-regional collaborative monitoring sample sequences. Based on cross-regional collaborative monitoring sample sequences, monitoring nodes, access scenarios, access objects, service objects, and running objects are identified to generate a set of website performance monitoring objects; Based on the access dependencies, call dependencies, resource bearing relationships, and regional routing relationships in the website performance monitoring object set, construct a spatiotemporal heterogeneity graph of website performance; Based on historical website performance spatiotemporal heterogeneity graphs, benchmark selection, time-series aggregation, and regional difference calibration are performed to generate cross-regional dynamic performance baselines. The current website performance spatiotemporal heterogeneous graph is compared with the cross-regional dynamic performance baseline. The results of the deviation comparison are organized into events according to the abnormal time window, abnormal object, abnormal type and abnormal intensity, and a set of website performance abnormal events is generated. The set of website performance anomaly events is mapped to a spatiotemporal heterogeneous graph of website performance. A subgraph of website performance anomaly correlation is extracted. The subgraph of website performance anomaly correlation is input into the improved HGT anomaly attribution model to generate anomaly contribution results. Based on the anomaly contribution results, the source results and the scope of impact of website performance anomalies are determined, and the website performance monitoring results are output.

[0019] In this embodiment, the website performance-related data includes access performance data, network link data, service call data, runtime resource data, and user access behavior data. The standardization process includes unified timestamps, unified node identifiers, unified object numbers, unified indicator units, aligned sampling frequencies, complete missing data, remove abnormal formats, merge duplicate records, configure regional labels, and bind access sessions.

[0020] In this embodiment, the generation of cross-regional collaborative monitoring sample sequences includes: The cloud acquires the regional location, network environment, access entry, node load status and available sampling frequency of each monitoring node, and generates a node monitoring task table according to the regional coverage integrity, access entry matching degree and node load balance. The generation of the node monitoring task table is as follows: A monitoring node registry is established in the cloud, recording the node identifier, regional location, network environment, accessible access points, CPU utilization, memory utilization, current task quantity, and available sampling frequency of each monitoring node; the cloud uses a 5-minute task allocation cycle to summarize the node load status and network environment status of each monitoring node in the most recent 3 sampling cycles, calculates the regional coverage completeness based on the number of monitored nodes covered in each region, calculates the access point matching degree based on the consistency between the access protocols, service domain names, and access point types supported by the monitoring nodes and the access points to be monitored, and calculates the node load balancing degree based on CPU utilization, memory utilization, and current task quantity; the cloud performs a weighted sorting of regional coverage completeness, access point matching degree, and node load balancing degree, selects the monitoring nodes with the highest ranking results to establish task binding relationships with access points, and generates a node monitoring task table containing task number, node identifier, regional location, network environment, access point, task type, sampling time window, sampling cycle, return format, and task status; Based on the node monitoring task table, page access monitoring tasks, interface call monitoring tasks, and link status monitoring tasks are issued to the corresponding monitoring nodes. Each monitoring task is configured with a task number, sampling time window, sampling period, and return format. Specifically, the cloud reads the node identifier, access entry point, task type, sampling time window, sampling period, and return format from the node monitoring task table, encapsulates the page access monitoring task, interface call monitoring task, and link status monitoring task into task issuance instructions, and sends them to the corresponding monitoring nodes according to the node identifier. The page access monitoring task includes the access entry address, page path, loading stage marker, and page performance collection fields; the interface call monitoring task includes the interface address, request method, call parameter identifier, and interface performance collection fields; and the link status monitoring task includes the target address, probe protocol, number of probes, and link performance collection fields. Each monitoring task is configured with a unified task number, a 5-minute sampling time window, and a sampling period configured as 10 seconds, 30 seconds, or 60 seconds according to the node monitoring task table. The return format uses a structured data format containing the task number, node identifier, sampling time, access entry point, performance indicator fields, and anomaly marker fields. The monitoring nodes access the corresponding access points according to the monitoring tasks, collect website performance monitoring data, and generate node-back data packets. The generation of node return data packets is as follows: After receiving a monitoring task, the monitoring node establishes a local sampling queue according to the task number, and accesses the corresponding access entry point according to the sampling period within the sampling time window; for page access monitoring tasks, the monitoring node records DNS resolution time, TCP connection time, TLS handshake time, first byte response time, total page loading time, number of resource loading failures, and page status code; for interface call monitoring tasks, the monitoring node records interface response time, interface status code, request body size, response body size, interface timeout flag, and number of retries; for link status monitoring tasks, the monitoring node records link round-trip latency, packet loss rate, jitter value, route hop count, and target reachability status; the monitoring node sorts the sampling results under the same task number according to the sampling time, binds the node identifier, regional location, network environment, and access entry point, and generates node return data packets containing page access monitoring data, interface call monitoring data, and link status monitoring data; The cloud receives data packets transmitted back from nodes, merges the data according to task number, node identifier and sampling time window, and extracts service call data and runtime resource data within the same sampling time window from the website performance monitoring dataset for correlation, generating a cross-regional collaborative monitoring sample sequence arranged according to regional location, network environment, access point and sampling time.

[0021] In this embodiment, the generation of the website performance monitoring object set includes: The cross-regional collaborative monitoring sample sequences are grouped according to sampling time window, node identifier, regional location, network environment and access point, and the monitoring nodes that perform monitoring tasks are identified and monitoring node objects are generated. The generation of monitoring node objects is specifically as follows: sampling times are merged according to a 5-minute sampling time window, and a group index is established according to node identifier, regional location, network environment, and access entry point; for samples under the same group index, the number of page access monitoring tasks, interface call monitoring tasks, and link status monitoring tasks executed by the monitoring node within the sampling time window is counted, and the number of task return times, return latency, task completion status, and effective sampling quantity are recorded; the cloud associates the monitoring node registry with the node identifier, supplements the node operator type, outbound bandwidth, available sampling frequency, and node load status, and generates a monitoring node object containing node identifier, regional location, network environment, access entry point, sampling time window, task execution status, and effective sampling quantity; The system identifies access scenarios and generates access scenario objects based on a combination of regional location, network environment, access point, and sampling time window. The generation of access scenario objects is as follows: Regional location, network environment, access entry point, and sampling time window are extracted from the cross-regional collaborative monitoring sample sequence. Country, province, city, and operator type are used as scenario spatial attributes; access method, bandwidth range, average network latency, and packet loss rate are used as scenario network attributes; access entry address, entry type, service domain name, and access protocol are used as scenario entry attributes; and a 5-minute sampling time window is used as scenario time attributes. The cloud generates scenario combination keys based on scenario spatial attributes, scenario network attributes, scenario entry attributes, and scenario time attributes. Samples with the same scenario combination key are merged, and the number of page visits, interface calls, link probes, successful accesses, and failed accesses are counted. This generates access scenario objects containing scenario number, regional location, network environment, access entry point, sampling time window, number of samples, number of successful accesses, and number of failed accesses. Identify access objects and generate access object records based on page paths, resource addresses, and access status markers; The generation of access object records includes: extracting page path, resource address, page status code, loading stage marker, number of resource loading failures, and total page loading time from page access monitoring data of cross-regional collaborative monitoring sample sequences; using the page path as the page-level access object identifier, the resource address as the resource-level access object identifier, and the page status code, loading stage marker, and number of resource loading failures as access status markers; merging page access monitoring data in the cloud according to the page-level and resource-level access object identifiers, and statistically analyzing the number of accesses, average total page loading time, number of resource loading failures, and number of abnormal accesses for the same access object within the sampling time window, generating access object records containing object number, page path, resource address, access status marker, number of accesses, average total page loading time, and number of abnormal accesses; Identify service objects and generate service object records based on interface addresses, call identifiers, and service identifiers; The generation of service object records is specifically as follows: Interface call monitoring data and service call data are extracted from the cross-regional collaborative monitoring sample sequence. Interface call monitoring data includes interface address, request method, interface status code, interface response time, interface timeout flag, and number of retries. Service call data includes call identifier, service identifier, upstream service identifier, downstream service identifier, and call result flag. The cloud combines the interface address and request method to generate an interface object identifier. The call identifier is used as a service call chain identifier, and the service identifier is used as a service attribution identifier. The interface call monitoring data and service call data are merged according to the interface object identifier, call identifier, and service identifier. The number of interface calls, average interface response time, number of interface timeouts, number of retries, and number of call failures for the same service object within the sampling time window are counted. This generates a service object record containing the object number, interface address, request method, call identifier, service identifier, number of interface calls, average interface response time, number of interface timeouts, and number of call failures. Runtime objects are identified and runtime object records are generated based on host identifier, container identifier, instance identifier, and resource indicator identifier; The generation of runtime object records is specifically as follows: From the runtime resource data associated with the cross-regional collaborative monitoring sample sequence, the following are extracted: host identifier, container identifier, instance identifier, resource indicator identifier, CPU utilization, memory utilization, disk read / write speed, network throughput, number of connections, and resource collection time. The host identifier is used as the host-level runtime object identifier, the container identifier as the container-level runtime object identifier, the instance identifier as the service instance-level runtime object identifier, and the resource indicator identifier as the runtime status field marker. The cloud merges the runtime resource data according to the host identifier, container identifier, instance identifier, and sampling time window, and calculates the average CPU utilization, average memory utilization, maximum network throughput, maximum number of connections, and number of resource anomalies for the same runtime object within the sampling time window. This generates a runtime object record containing the object number, host identifier, container identifier, instance identifier, resource indicator identifier, sampling time window, resource occupancy status, and resource anomaly status. The monitoring node objects, access scenario objects, access object records, service object records, and running object records are merged according to object number, object type, attribution relationship, and sampling time window to generate a website performance monitoring object set.

[0022] In this embodiment, the construction of the website performance spatiotemporal heterogeneity graph includes: Configure the monitoring node objects, access scenario objects, access object records, service object records, and running object records in the website performance monitoring object set as different types of graph nodes, and configure the graph nodes with object number, object type, sampling time window, and performance status attributes; Establish access dependencies based on access records between monitoring node objects, access scenario objects, and access object records; The establishment of access dependencies is specifically as follows: read monitoring node objects, access scenario objects, and access object records from the website performance monitoring object set, match them according to the sampling time window and access entry point, and determine the access records where the same monitoring node object accesses the same access object record under the same access scenario object; establish node scenario access edges from monitoring node objects to access scenario objects based on the access records, and establish scenario object access edges from access scenario objects to access object records, and write access time, access count, and access status into the corresponding edge attributes to form access dependencies; Establish call dependencies based on the interface call records between access object records and service object records; The establishment of call dependencies is as follows: Access object records and service object records are read from the website performance monitoring object set. Matching is performed according to the sampling time window, access entry point, and interface call marker to determine the interface call records that trigger the same service object record for the same access object record. Based on the interface call records, access service call edges are established from the access object record to the service object record, and the call duration, number of calls, and call status are written into the corresponding edge attributes. For cases where the same access object record triggers multiple service object records within the same sampling time window, access service call edges are established separately according to the interface call order, and the interface call order is written into the corresponding edge attributes to form a call dependency relationship. Establish resource bearing relationships based on deployment records between service object records and runtime object records; The establishment of resource carrying relationships is specifically as follows: Service object records and running object records are read from the website performance monitoring object set. Matching is performed according to the sampling time window, service attribution marker, and instance identifier to determine the deployment record on the corresponding running object record for the same service object record. A service resource carrying edge is established from the service object record to the running object record based on the deployment record, and the resource occupancy status, instance running status, and deployment time window are written into the corresponding edge attributes. For cases where the same service object record corresponds to multiple running object records, service resource carrying edges are established separately according to the instance identifier, and the carrying ratio is written into the corresponding edge attributes to form a resource carrying relationship. Establish regional routing relationships based on link detection records between monitoring node objects, regional locations, network environments, and access points; The establishment of regional routing relationships is specifically as follows: Monitoring node objects and access scenario objects are read from the website performance monitoring object set. Matching is performed according to regional location, network environment, access entry point, and sampling time window to determine the link detection records of the same monitoring node object accessing the same access entry point in the corresponding region and network environment. Regional routing edges are established from the monitoring node object to the access scenario object based on the link detection records, and link latency, packet loss status, and reachability status are written to the corresponding edge attributes. For cases where the same monitoring node object corresponds to multiple access entry points within the same sampling time window, the cloud establishes regional routing edges according to each access entry point, forming regional routing relationships. Access dependencies, call dependencies, resource carrying relationships, and region routing relationships are configured as different types of graph edges. Sampling time windows, relationship types, performance metrics, and edge weights are assigned to each graph edge to construct a spatiotemporal heterogeneous graph of website performance. Specifically, access dependencies, call dependencies, resource carrying relationships, and region routing relationships are configured as access dependency edges, call dependency edges, resource carrying edges, and region routing edges, respectively, and edge weights are calculated within each sampling time window. For access dependency edges, the number of accesses, average access time, and number of successful accesses are counted. The number of accesses is divided by the maximum number of accesses for the same type of graph edge within the same sampling time window to obtain the access intensity value. The average access time is divided by the maximum access time for the same type of graph edge within the same sampling time window to obtain the access pressure value. The number of successful accesses is divided by the number of accesses to obtain the access stability value. For call dependency edges, the number of calls, average call time, and number of successful calls are counted. These are converted into call intensity values ​​and call pressure values ​​according to the maximum number of calls and maximum call time for the same type of graph edge, respectively. The number of successful calls is divided by the number of calls to obtain the call stability value. For resource-bearing edges, the service request volume carried by the running object is divided by the total request volume of the same service object to obtain the bearing strength value. The CPU utilization, memory utilization, and connection utilization are converted to the range of 0 to 1 and the average value is taken to obtain the resource pressure value. The number of normal operation samplings is divided by the total number of samplings to obtain the operation stability value. For area routing edges, the number of link probes is divided by the maximum number of link probes of the same type of graph edge to obtain the routing strength value. The link latency and packet loss rate are converted to the range of 0 to 1 and the average value is taken to obtain the routing pressure value. The number of link reachables is divided by the number of link probes to obtain the routing stability value. The strength value, pressure value, and stability value of each type of graph edge are added together with weight coefficients of 0.3, 0.5, and 0.2 to obtain the edge weight of the corresponding graph edge. Edge weights greater than 1 are truncated to 1, and edge weights less than 0 are truncated to 0. The edge weights are then written into the corresponding graph edge attributes.

[0023] In this embodiment, the generation of cross-regional dynamic performance baselines includes: The website performance spatiotemporal heterogeneity graph is continuously saved according to the sampling time window to form a historical website performance spatiotemporal heterogeneity graph. Based on access status, call status, instance running status, link reachability status, and edge weight, a historical website performance spatiotemporal heterogeneous graph is filtered to generate a historical benchmark graph sequence. The generation of the historical benchmark graph sequence is as follows: Traverse the historical website performance spatiotemporal heterogeneous graph according to the sampling time window, and calculate the access success rate, call success rate, instance running rate, and link reachability rate within each sampling time window. Specifically, the access success rate is the proportion of samples with a successful access status to the total number of access samples; the call success rate is the proportion of samples with a successful call status to the total number of call samples; the instance running rate is the proportion of samples with a running instance status to the total number of running instances; and the link reachability rate is the proportion of samples with a reachable link status to the total number of link samples. Sampling time windows with an access success rate of at least 98%, a call success rate of at least 97%, an instance running rate of at least 99%, and a link reachability rate of at least 98% are retained, while sampling time windows with edge weights falling within the highest 5% range under the same object type and the same relation type are removed. The remaining website performance spatiotemporal heterogeneous graphs within the sampling time windows are arranged in order of sampling time to generate the historical benchmark graph sequence. The historical benchmark graph sequence is grouped according to object type, relationship type, regional location, network environment and access point. The performance status attributes, performance indicators and edge weights within each group are aggregated in time series to generate the group performance benchmark sequence. The generation of the group performance benchmark sequence is as follows: Group keys are generated based on object type, relationship type, region location, network environment, and access point; graph nodes and edges from the historical benchmark graph sequence are written into the corresponding groups; for groups containing only graph nodes, the stability ratio and number of state changes of performance status attributes are statistically analyzed according to the sampling time window; for groups containing graph edges, the average, median, maximum, and minimum values ​​of performance indicators are statistically analyzed according to the sampling time window, and the average and peak values ​​of edge weights are also statistically analyzed; using a 5-minute base sampling time window and a 1-hour aggregation window, data from 12 consecutive sampling time windows within the same group are merged in chronological order, and aggregation windows with fewer than 8 sampling time windows are removed; group time-series records are generated for the retained aggregation windows, including the group key, aggregation window start and end times, performance status aggregation value, performance indicator aggregation value, edge weight aggregation value, and sample count; the group time-series records are arranged in chronological order according to the aggregation window to generate the group performance benchmark sequence. Regional difference calibration is performed based on the packet performance benchmark sequences of the same access point in different regional locations and network environments to generate a cross-regional dynamic performance baseline that includes the baseline center value, fluctuation boundary, regional calibration coefficient and update time stamp.

[0024] The regional difference calibration specifically involves: reading packet performance benchmark sequences from different regional locations and network environments, using the access point as the unit; statistically analyzing the number of aggregation windows, the number of consecutive aggregation windows, and the performance index fluctuation range of each packet performance benchmark sequence; retaining packet performance benchmark sequences with at least 24 aggregation windows, at least 12 consecutive aggregation windows, and performance index fluctuation ranges not exceeding 1.2 times the average fluctuation range of all packets under the same access point; selecting the packet performance benchmark sequence with the lowest performance index fluctuation range from the retained packet performance benchmark sequences as the reference sequence for the same access point; aligning the remaining packet performance benchmark sequences with the reference sequence using the same aggregation window, and then... Calculate the differences in performance index center, state ratio, and edge weight, and generate regional calibration coefficients for the corresponding regional locations and network environments with weights of 0.5, 0.3, and 0.2, respectively. The regional calibration coefficients are limited to between 0.7 and 1.3 and are used to correct the basic performance differences caused by different regional locations and network environments under the same access point. The regional calibration coefficients are used to calibrate the aggregated values ​​of performance indices and edge weights in the corresponding group performance benchmark sequence. The median value of the continuous aggregation window after calibration is taken as the baseline center value, and the interval between the 5th percentile and the 95th percentile is taken as the fluctuation boundary. The time of calibration completion is recorded as the update time marker to generate a cross-regional dynamic performance baseline.

[0025] In this embodiment, the generation of the website performance anomaly event set includes: The current website performance spatiotemporal heterogeneity graph is matched with cross-regional dynamic performance baselines according to object type, relationship type, regional location, network environment, and access point to obtain the corresponding baseline center value, fluctuation boundary, and regional calibration coefficient. Specifically, group performance benchmark sequences are read from different regional locations and network environments, taking access points as units, and the aggregated values ​​of performance indicators, edge weights, and state stability ratios in each group performance benchmark sequence are statistically analyzed. The group performance benchmark sequences under the same access point are time-aligned according to aggregation windows, with at least 24 aggregation windows and at least 12 consecutive aggregation windows selected. The performance benchmark sequence with the lowest performance index fluctuation is used as the reference sequence. The remaining performance benchmark sequences are compared with the reference sequence window by window to calculate the difference in performance index aggregate value, the difference in the proportion of stable states, and the difference in edge weight aggregate value. Regional calibration coefficients are generated according to weights of 0.5, 0.3, and 0.2. The performance index aggregate value and edge weight aggregate value in the corresponding group performance benchmark sequence are corrected using the regional calibration coefficients. The median value of the corrected continuous aggregation window is taken as the baseline center value, and the value range between the 5th percentile and the 95th percentile in the corrected continuous aggregation window is taken as the fluctuation boundary. Perform regional calibration on the performance status attributes, performance indicators and edge weights in the current website performance spatiotemporal heterogeneity graph, and compare the deviation with the corresponding fluctuation boundary to generate a deviation comparison record. The generation of deviation comparison records is specifically as follows: Read the graph nodes, edges, performance status attributes, performance metrics, and edge weights from the current website performance spatiotemporal heterogeneous graph; obtain the corresponding regional calibration coefficients and fluctuation boundaries from the cross-regional dynamic performance baseline; recalculate the current performance metrics and edge weights according to the regional calibration coefficients to obtain calibrated performance metrics and calibrated edge weights; convert the access status, call status, instance running status, and link reachability status in the performance status attributes into status comparison values; compare the calibrated performance metrics, calibrated weights, and status comparison values ​​with the corresponding fluctuation boundaries, and generate deviation records for graph nodes or edges that exceed the fluctuation boundaries; write the abnormal object, sampling time window, deviation index, deviation direction, and deviation amplitude into the deviation record, and generate a deviation comparison record after summarizing according to the sampling time window and abnormal object. Based on the deviation comparison records, the sampling time window, graph node or graph edge, deviation source and deviation magnitude are determined, and the abnormal time window, abnormal object, abnormal type and abnormal intensity are generated respectively. The generation of abnormal time windows, abnormal objects, abnormal types, and abnormal intensity is as follows: The sampling time window containing deviation records is directly used as the abnormal time window; the graph node number or graph edge number corresponding to the deviation record is used as the abnormal object. For numerical deviation indicators, a single deviation score is calculated. When the calibrated value is greater than the upper limit of the fluctuation boundary, the excess value is obtained by subtracting the upper limit of the fluctuation boundary from the calibrated value. When the calibrated value is less than the lower limit of the fluctuation boundary, the excess value is obtained by subtracting the calibrated value from the lower limit of the fluctuation boundary. The single deviation score is then obtained by dividing the excess value by the difference between the upper and lower limits of the fluctuation boundary. A single deviation score exceeding 1 is recorded as 1. For status-type deviation indicators, a status deviation score is calculated. Access status is failure, call status is failure, and instance running status is abnormal. When a link is unreachable, it is recorded as 1; otherwise, it is recorded as 0. Anomaly types are generated according to the object to which the deviation index belongs. Among them, access time and access status correspond to access performance anomalies, call time and call status correspond to service call anomalies, resource occupancy status and instance running status correspond to running resource anomalies, link latency and link reachability correspond to regional link anomalies, and edge weight corresponds to associated pressure anomalies. The individual deviation scores and status deviation scores under the same anomaly time window and the same anomaly object are merged, and the maximum value is taken as the main deviation score. The average of all deviation scores is taken as the average deviation score. The anomaly intensity is calculated according to the ratio of 70% for the main deviation score and 30% for the average deviation score, and the anomaly intensity is converted into a value from 0 to 100. By merging deviation comparison records with the same abnormal time window, the same abnormal object, or the same relationship type, a set of website performance abnormal events is generated.

[0026] In this embodiment, the generation of website performance monitoring results includes: The set of website performance anomaly events is mapped to the website performance spatiotemporal heterogeneous graph according to the anomaly time window and the anomaly object. The corresponding graph nodes or graph edges are located, and the associated nodes and associated graph edges within the same sampling time window are extracted along the access dependency edge, call dependency edge, resource bearing edge and regional routing edge to generate the website performance anomaly associated subgraph. The website performance anomaly correlation subgraph is input into the improved HGT anomaly attribution model. The improved HGT anomaly attribution model includes an event mapping layer, a heterogeneous encoding layer, a relational attention propagation layer, and a contribution output layer. The improvements to the HGT anomaly attribution model are specifically reflected in the following aspects: First, a website performance type encoding mechanism is added, configuring node type encoding for monitoring node objects, access scenario objects, access object records, service object records, and running object records respectively. Second, relationship type encoding is configured for access dependency edges, call dependency edges, resource bearing edges, and regional routing edges, ensuring that different performance objects and different dependencies have independent representations in attention propagation. Third, a baseline deviation fusion mechanism is added, jointly incorporating calibrated performance indicators, calibrated edge weights, anomaly intensity, and fluctuation boundary exceedance into the anomaly subgraph features, making attention weights simultaneously affected by object type, relationship type, and baseline deviation. Fourth, a contribution decomposition output mechanism is added, mapping the relationship attention propagation results to node contribution, edge contribution, and influence propagation contribution respectively. Node contribution is used to determine the source of website performance anomalies, while edge contribution and influence propagation contribution are used to determine the scope of impact of website performance anomalies. The training data comes from continuously stored spatiotemporal heterogeneous graphs of website performance, sets of website performance anomaly events, website performance anomaly correlation subgraphs, and corresponding operation and maintenance records. The operation and maintenance records include the source object of the anomaly, the affected access objects, the affected access scenarios, and the anomaly handling time. Using a 5-minute sampling time window as the basic unit, website performance anomaly correlation subgraphs are extracted from the historical data of the past 30 days as training samples. The source object of the anomaly is used as the source supervision label, the affected access objects and affected access scenarios are used as the scope of influence supervision labels, the anomaly type is used as the type supervision label, and the anomaly intensity is used as the intensity supervision label. The training samples are divided into training set, validation set, and test set in a 7:2:1 ratio. Each training sample retains the graph nodes and graph edges within two hops of the anomaly object. The number of graph nodes in a single training sample is limited to 200, and the number of graph edges is limited to 600. During training, the AdamW optimizer was used with a learning rate of 0.0005, weight decay of 0.0001, batch size of 32, 100 training epochs, 128 hidden feature dimensions, 4 attention heads, 3 relational attention propagation layers, and a Dropout ratio of 0.2. Training was stopped when the validation set showed no decrease in weight for 10 consecutive epochs. The loss function consisted of anomaly source classification loss, multi-label impact range loss, anomaly type classification loss, anomaly intensity regression loss, and contribution sparsity constraint loss. The weights for anomaly source classification loss, impact range multi-label loss, anomaly type classification loss, anomaly intensity regression loss, and contribution sparsity constraint loss were set to 0.10. After training, the model parameters with the highest anomaly source identification accuracy on the validation set were saved, and these saved model parameters were used to calculate the anomaly contribution of the website performance anomaly association subgraph. In the event mapping layer, anomaly intensity, performance status attributes, performance metrics, and edge weights are combined into anomaly subgraph features; The event mapping layer specifically processes the following: It organizes the graph node features, edge features, and edge weights in the website performance anomaly association subgraph into a subgraph input tensor; it organizes the anomaly time window, anomaly object, anomaly type, and anomaly intensity in the website performance anomaly event set into an event input vector; it performs embedding encoding on the anomaly type to generate an anomaly type embedding vector; it performs linear projection on the anomaly intensity to generate an anomaly intensity embedding vector; it performs time position encoding on the anomaly time window to generate a time window embedding vector; it locates the corresponding graph node or edge in the website performance anomaly association subgraph based on the anomaly object number, and configures a center marker for the event center object, linking it to the event... The objects connected to the center object are configured with association tags; the graph node features, performance status attributes, performance index deviation features, center tags, anomaly type embedding vectors, anomaly strength embedding vectors, and time window embedding vectors are concatenated and converted into node anomaly features through a node linear mapping layer; the graph edge features, edge weights, performance index deviation features, association tags, anomaly type embedding vectors, anomaly strength embedding vectors, and time window embedding vectors are concatenated and converted into edge anomaly features through an edge linear mapping layer; layer normalization and ReLU activation are performed on the node anomaly features and edge anomaly features respectively to generate anomaly subgraph features for input to the heterogeneous coding layer; In the heterogeneous coding layer, type coding is configured for different types of graph nodes and graph edges; The heterogeneous coding layer specifically handles the following: It decomposes the anomaly subgraph features into node anomaly features and edge anomaly features; based on the determined object types in the website performance monitoring object set, it configures fixed node type codes for monitoring node objects, access scenario objects, access object records, service object records, and running object records. The fixed node type codes use five-dimensional binary encoding: monitoring node object code is 10000, access scenario object code is 01000, access object record code is 00100, service object record code is 00010, and running object record code is 00001; based on the determined relationship types in the website performance spatiotemporal heterogeneous graph, it assigns access dependency edges and call... Dependency edges, resource-bearing edges, and regional routing edges are each configured with fixed relationship type codes. These fixed relationship type codes use four-dimensional binary encoding: access dependency edges are encoded as 1000, call dependency edges as 0100, resource-bearing edges as 0010, and regional routing edges as 0001. Node anomaly features are concatenated with their corresponding fixed node type codes and input into the node feature mapping layer to generate heterogeneous node representations. Edge anomaly features are concatenated with their corresponding fixed relationship type codes and input into the edge feature mapping layer to generate heterogeneous edge representations. Layer normalization and activation processing are performed on both the heterogeneous node and edge representations to generate heterogeneous encoded features for input to the relationship attention propagation layer. In the relational attention propagation layer, attention is propagated according to different relation types to generate node contribution and edge contribution. The specific processing of the relation attention propagation layer is as follows: Heterogeneous node and edge representations in the heterogeneous encoded features are grouped according to access dependency edges, call dependency edges, resource-bearing edges, and region routing edges; for each relation type, the target graph node representation is input into the query mapping layer, and the source graph node representation and corresponding heterogeneous edge representation are input into the key mapping layer and value mapping layer to generate query features, key features, and value features; an initial attention score is generated based on the similarity between the query features and key features, and this initial attention score is fused with the corresponding edge weights and anomaly strength embedding vectors to obtain the relation attention score; Softmax is applied to graph edges of the same relation type connected to the same target graph node. Normalization is performed to generate relational attention weights. These weights are multiplied by the value features and aggregated to the target graph nodes. After residual connection, layer normalization, and ReLU activation, a propagation node representation is generated. The relational attention propagation layer repeats the above process according to the 3-layer propagation structure to obtain the final propagation node representation. The final propagation node representation is input to the node contribution mapping layer and converted to a node contribution between 0 and 1 using the Sigmoid function. The heterogeneous edge representation, edge weights, relational attention weights, and the final propagation node representations of the corresponding two-end graph nodes are concatenated and input to the edge contribution mapping layer, which is then converted to an edge contribution between 0 and 1 using the Sigmoid function. In the contribution output layer, the source of website performance anomalies is determined based on node contribution, and the scope of impact of website performance anomalies is determined based on edge contribution. The combined output results are then used to monitor website performance.

[0027] The specific processing of the contribution output layer is as follows: Graph nodes and edges in the website performance anomaly correlation subgraph are sorted according to the anomaly time window; graph nodes with a contribution score of not less than 0.60 are selected as candidate anomaly sources, and the top 5 candidate anomaly sources are retained from highest to lowest contribution score. The website performance anomaly source result is determined by combining the association path length between the anomaly object and the candidate anomaly source, the average edge contribution score within the path, and the anomaly type matching status; graph edges with an edge contribution score of not less than 0.40 are selected as candidate edges for impact propagation. Starting from the graph node corresponding to the website performance anomaly source result, propagation is filtered within a three-hop range along access dependency edges, call dependency edges, resource bearing edges, and regional routing edges. Access scenario objects, access object records, service object records, and running object records traversed by the propagation path are extracted to generate the website performance anomaly impact range result; the website performance anomaly source result, website performance anomaly impact range result, anomaly time window, anomaly type, anomaly intensity, node contribution score sorting result, and edge contribution score sorting result are merged to generate the website performance monitoring result.

[0028] A website performance monitoring system based on big data analytics and cloud collaboration includes: The data processing module is used to collect and standardize website performance-related data to generate website performance monitoring datasets. The collaborative monitoring module is used to assign monitoring tasks to monitoring nodes and generate cross-regional collaborative monitoring sample sequences; The object recognition module is used to identify monitoring nodes, access scenarios, access objects, service objects, and running objects, and generate a set of website performance monitoring objects; The heterogeneous graph construction module is used to build a spatiotemporal heterogeneous graph of website performance. The baseline generation module is used to generate dynamic performance baselines across regions; The abnormal event generation module is used to compare the deviation between the current website performance spatiotemporal heterogeneity graph and the cross-regional dynamic performance baseline to generate a set of website performance abnormal events. The attribution output module is used to generate results on the source of website performance anomalies, the scope of impact of website performance anomalies, and website performance monitoring results based on the set of website performance anomaly events and the improved HGT anomaly attribution model.

[0029] Example 1: To verify the feasibility of this invention in practice, it was applied to a performance monitoring scenario of a large e-commerce website. This website includes a homepage access point, a product details page entry point, an order submission page entry point, a payment callback page entry point, and a static resource entry point. The backend service is deployed in a containerized manner, and page access, API calls, runtime resource, and user session data are collected by different operation and maintenance components. The original monitoring method primarily used threshold alarms based on page loading time, average API response time, and server resource utilization. When business traffic increased, it frequently resulted in slower order submission page responses, increased retries for some APIs, and short-term spikes in server-side resource metrics under certain access networks. Because access performance data, link detection data, service call data, and runtime resource data were stored in a scattered manner, the original monitoring method could only output alarms for "slow response" or "API anomaly," making it difficult to determine whether the anomaly originated from the access link, page resources, API call relationships, or service instance load. Operation and maintenance personnel had to manually switch between multiple types of logs for troubleshooting, making the anomaly source location process lengthy.

[0030] In this embodiment, 12 monitoring nodes are deployed across multiple regional access networks, covering four types of network environments, and five access points are included in unified monitoring. The system collects website performance-related data and performs standardized processing to generate a website performance monitoring dataset. The cloud distributes page access monitoring tasks, interface call monitoring tasks, and link status monitoring tasks to the monitoring nodes according to regional location, network environment, and access point. The sampling time window is set to 5 minutes, with a sampling period of 30 seconds for page access monitoring tasks, 10 seconds for interface call monitoring tasks, and 30 seconds for link status monitoring tasks. The monitoring nodes return total page loading time, first byte response time, interface response time, link round-trip latency, packet loss rate, and target reachability status. The cloud then correlates service call data and runtime resource data within the same sampling time window to generate a cross-regional collaborative monitoring sample sequence. Based on this sequence, the system identifies monitoring nodes, access scenarios, access objects, service objects, and runtime objects, further establishing access dependencies, call dependencies, resource carrying relationships, and regional routing relationships. It constructs a website performance spatiotemporal heterogeneity graph and uses historical website performance spatiotemporal heterogeneity graphs to generate a cross-regional dynamic performance baseline.

[0031] During a period of continuous peak business operation, the total page loading time for the order submission entry on a certain type of mobile network increased from the baseline center value of 1.42 seconds to 3.86 seconds, the interface response time between the order service and the inventory service increased from the baseline center value of 312 milliseconds to 948 milliseconds, and the weight of the call dependency edge increased from 0.34 to 0.86. Meanwhile, the weight of the regional routing edge corresponding to this access scenario remained between 0.21 and 0.26, and the link packet loss rate was less than 0.3%, indicating that the anomaly was not caused by network unavailability or link congestion. The system compares the deviation between the current website performance spatiotemporal heterogeneous graph and the cross-regional dynamic performance baseline, generates a set of website performance anomaly events, maps these events to the website performance spatiotemporal heterogeneous graph, and extracts a website performance anomaly association subgraph containing the order submission page, order service, inventory service, inventory service instance, and corresponding call dependency edge. After the improved HGT anomaly attribution model processes the anomaly association subgraph, the node contribution of the inventory service instance is 0.88, the contribution of the call dependency edge from the order service to the inventory service is 0.83, the contribution of the regional routing edge is less than 0.20, and the contribution of the static resource access dependency edge is less than 0.24.

[0032] Based on the above output, the source of the website performance anomaly was determined to be increased pressure on the inventory service instance. The impact of the website performance anomaly was limited to the order submission portal, order service, inventory service, and corresponding access scenarios, without extending to the homepage portal, product details portal, and static resource portal. Based on this, the operations and maintenance personnel expanded the capacity of the inventory service instance and adjusted the call rate limiting parameters of the order submission link. Subsequent operation records showed that the average interface response time of the order submission portal dropped to 365 milliseconds, the call failure rate decreased from 3.6% to 0.7%, the percentage of affected user access sessions decreased from 11.8% to 2.1%, and the data scope involved in manual investigation was narrowed from four categories—access logs, link logs, service logs, and resource monitoring—to inventory service instance logs and order call chain logs, reducing the time spent on anomaly localization by approximately 70%. Therefore, this invention can transform website performance anomalies from single-indicator alerts into source localization and impact range analysis based on heterogeneous graph relationships and anomaly contribution in scenarios with dispersed multi-source performance data and significant differences in access status across regions, improving the accuracy and usability of website performance monitoring results.

[0033] Table 1 Comparison of Website Performance Anomaly Monitoring Methods

[0034] As shown in Table 1, this invention improves the accuracy of anomaly detection from 82.6% to 89.4% compared to traditional threshold monitoring methods. Traditional threshold monitoring methods primarily rely on single-indicator judgments such as page load time, interface response time, and server resource utilization. In situations with multiple access points, significant network environment differences, and complex backend service call chains, performance fluctuations are easily fragmented into multiple independent alarms. This invention, by collecting access performance data, network link data, service call data, runtime resource data, and user access behavior data, forms a website performance monitoring dataset. Furthermore, it identifies monitoring nodes, access scenarios, access objects, service objects, and runtime objects, enabling anomaly detection to comprehensively analyze access dependencies, call dependencies, resource carrying relationships, and regional routing relationships among multiple object types. Therefore, the accuracy of anomaly detection is improved.

[0035] Regarding the false positive and false negative rates, traditional threshold monitoring methods have a false positive rate of 14.8% and a false negative rate of 11.5%, respectively. This invention reduces these rates to 9.7% and 7.2%, respectively. Traditional threshold monitoring methods typically use a uniform or static threshold, making it easy to misjudge normal performance differences under different regional locations, network environments, and access points as anomalies. Furthermore, when anomalies manifest as gradual degradation or occur only in a localized part of the call chain, a single threshold can easily miss detections. This invention uses historical website performance spatiotemporal heterogeneous graphs for benchmark screening, time-series aggregation, and regional difference calibration to generate cross-regional dynamic performance baselines. This allows the current website performance spatiotemporal heterogeneous graph to be compared with the baseline center value and fluctuation boundaries under the corresponding access scenario, thereby reducing false positives caused by normal fluctuations and also reducing false negatives caused by local anomalies being masked.

[0036] In terms of anomaly detection and localization efficiency, the average anomaly detection delay of traditional threshold monitoring methods is 4.9 minutes, while that of this invention is 3.4 minutes; the average anomaly source localization time of traditional threshold monitoring methods is 38.5 minutes, while that of this invention is 25.7 minutes. These results demonstrate that this invention does not simply improve alarm sensitivity, but rather, through cross-regional collaborative monitoring of sample sequences and website performance spatiotemporal heterogeneity graphs, enables rapid association of corresponding access scenarios, access objects, service objects, and running objects after anomalies occur. After the set of website performance anomaly events is generated, this invention maps it to the website performance spatiotemporal heterogeneity graph and extracts the website performance anomaly association subgraph, allowing subsequent attribution analysis to focus on relevant nodes and graph edges within the anomaly time window, thus significantly shortening the anomaly source localization time.

[0037] Regarding the accuracy of anomaly source localization, traditional threshold monitoring methods achieve 70.4%, while this invention improves it to 82.1%. Traditional threshold monitoring methods can detect slow pages, slow interfaces, or increased resource consumption, but they struggle to determine the sequence and dependencies between these anomalies. For example, slow page loading could stem from regional link fluctuations, abnormal interface calls, or increased load on running instances. This invention utilizes a website performance spatiotemporal heterogeneous graph to uniformly model access dependencies, call dependencies, resource load relationships, and regional routing relationships. Furthermore, by improving the HGT anomaly attribution model to calculate node and edge contributions, the anomaly source can be located to a specific accessed object, service object, running object, or corresponding edge, thus improving the accuracy of anomaly source localization.

[0038] Regarding the accuracy of impact scope determination, traditional threshold monitoring methods achieve 65.8%, while this invention improves it to 78.6%. Traditional threshold monitoring methods typically rely on alarm indicators and human experience to determine the impact scope, which can easily lead to local anomalies being expanded into site-wide anomalies, or to overlook affected access points and service objects within the same call chain. This invention, after generating a set of website performance anomaly events, extracts a website performance anomaly correlation subgraph based on the anomaly time window and anomaly objects. Furthermore, in the improved HGT anomaly attribution model, attention propagation is performed according to different relationship types, enabling the impact scope to be determined along access dependency edges, call dependency edges, resource bearing edges, and regional routing edges.

[0039] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A website performance monitoring method based on big data analysis and cloud collaboration, characterized in that, Includes the following steps: Collect website performance-related data and perform standardized processing to generate a website performance monitoring dataset; The cloud assigns monitoring tasks to monitoring nodes based on regional location, network environment, and access point, receives website performance monitoring data returned by the monitoring nodes, and generates cross-regional collaborative monitoring sample sequences. Based on cross-regional collaborative monitoring sample sequences, monitoring nodes, access scenarios, access objects, service objects, and running objects are identified to generate a set of website performance monitoring objects; Based on the access dependencies, call dependencies, resource bearing relationships, and regional routing relationships in the website performance monitoring object set, construct a spatiotemporal heterogeneity graph of website performance; Based on historical website performance spatiotemporal heterogeneity graphs, benchmark selection, time-series aggregation, and regional difference calibration are performed to generate cross-regional dynamic performance baselines. The current website performance spatiotemporal heterogeneous graph is compared with the cross-regional dynamic performance baseline. The results of the deviation comparison are organized into events according to the abnormal time window, abnormal object, abnormal type and abnormal intensity, and a set of website performance abnormal events is generated. The set of website performance anomaly events is mapped to a spatiotemporal heterogeneous graph of website performance. A subgraph of website performance anomaly correlation is extracted. The subgraph of website performance anomaly correlation is input into the improved HGT anomaly attribution model to generate anomaly contribution results. Based on the anomaly contribution results, the source results and the scope of impact of website performance anomalies are determined, and the website performance monitoring results are output.

2. The website performance monitoring method based on big data analysis and cloud collaboration according to claim 1, characterized in that, The website performance-related data includes access performance data, network link data, service call data, runtime resource data, and user access behavior data. The standardization process includes unified timestamps, unified node identifiers, unified object numbers, unified indicator units, aligned sampling frequencies, missing data completion, abnormal format removal, duplicate record merging, regional label configuration, and access session binding.

3. The website performance monitoring method based on big data analysis and cloud collaboration according to claim 1, characterized in that, The generation of the cross-regional collaborative monitoring sample sequence includes: The cloud acquires the regional location, network environment, access entry, node load status and available sampling frequency of each monitoring node, and generates a node monitoring task table according to the regional coverage integrity, access entry matching degree and node load balance. Based on the node monitoring task table, page access monitoring tasks, interface call monitoring tasks, and link status monitoring tasks are issued to the corresponding monitoring nodes, and task numbers, sampling time windows, sampling periods, and feedback formats are configured for each monitoring task. The monitoring nodes access the corresponding access points according to the monitoring tasks, collect website performance monitoring data, and generate node-back data packets. The cloud receives data packets transmitted back from nodes, merges the data according to task number, node identifier and sampling time window, and extracts service call data and runtime resource data within the same sampling time window from the website performance monitoring dataset for correlation, generating a cross-regional collaborative monitoring sample sequence arranged according to regional location, network environment, access point and sampling time.

4. The website performance monitoring method based on big data analysis and cloud collaboration according to claim 1, characterized in that, The generation of the website performance monitoring object set includes: The cross-regional collaborative monitoring sample sequences are grouped according to sampling time window, node identifier, regional location, network environment and access point, and the monitoring nodes that perform monitoring tasks are identified and monitoring node objects are generated. The system identifies access scenarios and generates access scenario objects based on a combination of regional location, network environment, access point, and sampling time window. Identify access objects and generate access object records based on page paths, resource addresses, and access status markers; Identify service objects and generate service object records based on interface addresses, call identifiers, and service identifiers; Runtime objects are identified and runtime object records are generated based on host identifier, container identifier, instance identifier, and resource indicator identifier; The monitoring node objects, access scenario objects, access object records, service object records, and running object records are merged according to object number, object type, attribution relationship, and sampling time window to generate a website performance monitoring object set.

5. The website performance monitoring method based on big data analysis and cloud collaboration according to claim 1, characterized in that, The construction of the website performance spatiotemporal heterogeneity graph includes: Configure the monitoring node objects, access scenario objects, access object records, service object records, and running object records in the website performance monitoring object set as different types of graph nodes, and configure the graph nodes with object number, object type, sampling time window, and performance status attributes; Establish access dependencies based on access records between monitoring node objects, access scenario objects, and access object records; Establish call dependencies based on the interface call records between access object records and service object records; Establish resource bearing relationships based on deployment records between service object records and runtime object records; Establish regional routing relationships based on link detection records between monitoring node objects, regional locations, network environments, and access points; Configure access dependencies, call dependencies, resource hosting relationships, and regional routing relationships as different types of graph edges, and configure sampling time windows, relationship types, performance metrics, and edge weights for the graph edges to construct a spatiotemporal heterogeneous graph of website performance.

6. The website performance monitoring method based on big data analysis and cloud collaboration according to claim 1, characterized in that, The generation of the cross-regional dynamic performance baseline includes: The website performance spatiotemporal heterogeneity graph is continuously saved according to the sampling time window to form a historical website performance spatiotemporal heterogeneity graph. Based on access status, call status, instance running status, link reachability status, and edge weight, a historical website performance spatiotemporal heterogeneous graph is filtered to generate a historical benchmark graph sequence. The historical benchmark graph sequence is grouped according to object type, relationship type, regional location, network environment and access point. The performance status attributes, performance indicators and edge weights within each group are aggregated in time series to generate the group performance benchmark sequence. Regional difference calibration is performed based on the packet performance benchmark sequences of the same access point in different regional locations and network environments to generate a cross-regional dynamic performance baseline that includes the baseline center value, fluctuation boundary, regional calibration coefficient and update time stamp.

7. The website performance monitoring method based on big data analysis and cloud collaboration according to claim 1, characterized in that, The generation of the website performance anomaly event set includes: Perform regional calibration on the performance status attributes, performance indicators and edge weights in the current website performance spatiotemporal heterogeneity graph, and compare the deviation with the corresponding fluctuation boundary to generate a deviation comparison record. Based on the deviation comparison records, the sampling time window, graph node or graph edge, deviation source and deviation magnitude are determined, and the abnormal time window, abnormal object, abnormal type and abnormal intensity are generated respectively. By merging deviation comparison records with the same abnormal time window, the same abnormal object, or the same relationship type, a set of website performance abnormal events is generated.

8. The website performance monitoring method based on big data analysis and cloud collaboration according to claim 1, characterized in that, The generation of the website performance monitoring results includes: The set of website performance anomaly events is mapped to the website performance spatiotemporal heterogeneous graph according to the anomaly time window and the anomaly object. The corresponding graph nodes or graph edges are located, and the associated nodes and associated graph edges within the same sampling time window are extracted along the access dependency edge, call dependency edge, resource bearing edge and regional routing edge to generate the website performance anomaly associated subgraph. The website performance anomaly correlation subgraph is input into the improved HGT anomaly attribution model. The improved HGT anomaly attribution model includes an event mapping layer, a heterogeneous encoding layer, a relational attention propagation layer, and a contribution output layer. In the event mapping layer, anomaly intensity, performance status attributes, performance metrics, and edge weights are combined into anomaly subgraph features; In the heterogeneous coding layer, type coding is configured for different types of graph nodes and graph edges; In the relational attention propagation layer, attention is propagated according to different relation types to generate node contribution and edge contribution. In the contribution output layer, the source of website performance anomalies is determined based on node contribution, and the scope of impact of website performance anomalies is determined based on edge contribution. The combined output results are then used to monitor website performance.

9. A website performance monitoring system based on big data analysis and cloud collaboration, executing the website performance monitoring method based on big data analysis and cloud collaboration as described in any one of claims 1 to 8, characterized in that, include: The data processing module is used to collect and standardize website performance-related data to generate website performance monitoring datasets. The collaborative monitoring module is used to assign monitoring tasks to monitoring nodes and generate cross-regional collaborative monitoring sample sequences; The object recognition module is used to identify monitoring nodes, access scenarios, access objects, service objects, and running objects, and generate a set of website performance monitoring objects; The heterogeneous graph construction module is used to build a spatiotemporal heterogeneous graph of website performance. The baseline generation module is used to generate dynamic performance baselines across regions; The abnormal event generation module is used to compare the deviation between the current website performance spatiotemporal heterogeneity graph and the cross-regional dynamic performance baseline, and generate a set of website performance abnormal events. The attribution output module is used to generate results on the source of website performance anomalies, the scope of impact of website performance anomalies, and website performance monitoring results based on the set of website performance anomaly events and the improved HGT anomaly attribution model.

Images