A network monitoring method, system, device, and medium for game launches.

Abstract

This application relates to the field of computer technology and provides a network monitoring method for game launches, comprising: before the game launch, predicting network load pressure at different times and in different geographical areas during the launch period based on historical launch data and user reservation data, and dynamically generating an elastic monitoring strategy based on the network load pressure; during the game launch period, performing two-dimensional network probing based on the elastic monitoring strategy to obtain probing data, wherein the two-dimensional network probing includes Ping probing and HTTP dialing; and generating diagnostic suggestion information based on the probing data and a pre-trained fault diagnosis model. This application generates an elastic monitoring strategy for two-dimensional network probing, converts the elastic monitoring strategy into a probing task plan and serial stage tasks under the corresponding probing dimensions, and introduces real-time monitoring and adjustment capabilities to ensure the sensitivity of monitoring in the game launch scenario.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a network monitoring method, system, device and medium for game launch. Background Technology

[0002] The launch of an online game is a critical moment when business traffic explodes in a very short period of time. Network quality directly determines user experience and business success or failure, so it is necessary to monitor the network during the game's launch.

[0003] Existing network monitoring technologies mainly rely on two single-dimensional monitoring methods: server-side monitoring and user-side probing. Server-side monitoring typically involves deploying monitoring points inside the game server room or on the link between the game server and the upstream platform, using tools such as ICMP Ping and TCPing to monitor link quality and identify problems with the server's outbound network or interconnection. User-side probing, on the other hand, typically involves deploying probing nodes in data centers in various locations, periodically simulating users sending HTTP / HTTPS login requests to the game server, aiming to assess service reachability and availability from the end-user's perspective to identify regional network problems.

[0004] However, in the context of a game's initial launch, the aforementioned network monitoring technologies, due to their typically fixed monitoring strategies such as detection frequency and thresholds, cannot adapt to the dramatic temporal and spatial fluctuations in traffic during the launch period. Furthermore, the monitoring data from both the server and user sides are often isolated, providing only rough conclusions such as "server network anomaly" or "abnormal user access in a certain location." When faced with complex faults, it is difficult to accurately pinpoint the root cause, relying heavily on the experience of operations and maintenance personnel for manual correlation and troubleshooting, resulting in low efficiency. Summary of the Invention

[0005] This application provides a network monitoring method, system, device, and medium for game launches, which can solve one of the above-mentioned problems in the prior art.

[0006] In a first aspect, embodiments of this application provide a network monitoring method for game launches, including: Before the game's official launch, based on historical launch data and user reservation data, the network load pressure at different times and in different geographical areas during the launch period is predicted, and elastic monitoring strategies are dynamically generated based on the network load pressure. During the game's initial launch period, based on the aforementioned elastic monitoring strategy, a two-dimensional network probe was performed to obtain probe data. The two-dimensional network probe included Ping probe and HTTP probe. Based on the detection data, and combined with a pre-trained fault diagnosis model, diagnostic suggestion information is generated.

[0007] Furthermore, the prediction of network load pressure during different time periods and in different geographical areas based on historical initial launch data and user reservation data includes: A multi-source data pool is constructed based on historical initial release data and user reservation data; Based on the aforementioned multi-source data pool, a time series analysis model is used to predict the global traffic change curve on the game's launch day. The regional learning model is used to predict the predicted pressure value of each "region-operator" unit within a preset time window; Based on the predicted pressure value and the global traffic change curve, structured tags are generated for each "region-operator" unit within different time windows during the game's initial release, and the pressure level of the structured tags is determined.

[0008] Furthermore, the step of dynamically generating elastic monitoring strategies based on the network load pressure includes: Based on the pressure level, the monitoring parameters are dynamically adjusted to generate a flexible monitoring strategy. The monitoring parameters include at least the detection frequency and depth of network detection under different pressure levels, the sampling intensity of network quality detection, and the dynamic threshold for determining network status abnormalities.

[0009] Furthermore, the two-dimensional network probing based on the elastic monitoring strategy includes: Load the elastic monitoring strategy, generate a detection task plan for each detection agent node according to the elastic monitoring strategy, and execute serial phase tasks for each detection node. Schedule and execute the detection task plan and the serial phase task, process the detection data generated by each detection agent node and the dialing node, and form a monitoring unit corresponding to each "region-operator" unit network. The real-time situation indicators of the monitoring unit are obtained and compared with the preset dynamic baseline range to determine the abnormal situation; Based on the aforementioned abnormal situation, the detection frequency and detection depth of the corresponding "region-operator" unit are adjusted to trigger the inter-server link check and / or full transaction chain simulation that it depends on.

[0010] Furthermore, the deployment of the testing nodes specifically includes: A spatial index is established for the game's initial launch area, forming a region-operator as the smallest planning unit, and attributes are deployed for the associated nodes of each planning unit; Based on the node deployment attributes, calculate the comprehensive weight of each planning unit and set constraints for each node deployment attribute; Based on the unit comprehensive weight and the constraints, the number of monitoring nodes for each planning unit is determined.

[0011] Furthermore, the detection data includes inter-server network quality data and user-side network connection status data; The preprocessing of the probe data specifically includes: receiving the raw probe logs of all probe nodes, parsing and cleaning the raw probe logs, and attaching spatial and policy tags to each data record to generate structured data. The spatial tags include at least geographical area and operator information, and the policy tags identify the probe task plan that generated the data record, as well as the elastic monitoring strategy and stress level on which it is based.

[0012] Furthermore, based on the detection data and combined with the pre-trained fault diagnosis model, diagnostic suggestion information is generated, including: Based on the detection data of the monitoring unit in an abnormal state, a fused feature vector is constructed; The fused feature vector is input into a pre-trained fault diagnosis model to obtain the probability distribution output of multiple preset fault root cause categories; Based on the output of the probability distribution, at least one root cause inference with the highest confidence is determined, and diagnostic suggestion information is generated based on the preset diagnosis-suggestion mapping rules.

[0013] Secondly, embodiments of this application provide a network monitoring system for game launches, comprising: The first processing module is used to predict the network load pressure at different times and in different geographical areas during the launch period based on historical launch data and user reservation data before the game's official launch, and to dynamically generate elastic monitoring strategies based on the network load pressure. The second processing module is used to perform two-dimensional network probing based on the elastic monitoring strategy during the game's initial launch period to obtain probing data. The two-dimensional network probing includes Ping probing and HTTP dialing. The third processing module is used to generate diagnostic suggestion information based on the detection data and a pre-trained fault diagnosis model.

[0014] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned network monitoring method for game launch.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium, including a computer program stored in the computer-readable storage medium, wherein the computer program, when executed by a processor, implements the aforementioned network monitoring method for game launch.

[0016] The beneficial effects of the embodiments in this application compared with the prior art are: This application discloses a network monitoring method for game launches. It integrates user reservation data and historical game launch data, performing a two-tiered prediction approach: a macro-level prediction of global traffic trends and a micro-level prediction of regional fine-grained pressure. This predicts network load pressure during game launches, improving prediction reliability. Furthermore, based on network load pressure, it generates an elastic monitoring strategy for dual-dimensional network probing, converting this strategy into probing task plans and sequential phased tasks for each probing dimension. Real-time monitoring and adjustment capabilities are introduced to ensure monitoring sensitivity during game launches. Additionally, probing data from monitoring units in abnormal states is used as a source for root cause inference to determine the root causes of network anomalies during game launches and generate corresponding decision-making suggestions to guide operations personnel. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a network monitoring method for game launch provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a network monitoring system for game launch provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0020] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0021] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0023] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0025] Please see Figure 1 As shown, this invention is a network monitoring method for game launches, comprising the following steps: Step S100: Before the game's official launch, based on historical launch data and user reservation data, predict the network load pressure at different times and in different geographical areas during the launch period, and dynamically generate an elastic monitoring strategy based on the network load pressure. In some embodiments, the prediction of network load pressure during different time periods and in different geographical areas based on historical initial launch data and user reservation data includes: A multi-source data pool is constructed based on historical initial release data and user reservation data; Based on the aforementioned multi-source data pool, a time series analysis model is used to predict the global traffic change curve on the game's launch day. The regional learning model is used to predict the predicted pressure value of each "region-operator" unit within a preset time window; Based on the predicted pressure value and the global traffic change curve, structured tags are generated for each "region-operator" unit within different time windows during the game's initial release, and the pressure level of the structured tags is determined.

[0026] In this embodiment, before the game's initial release, the network load pressure during the initial release period is predicted based on historical data and user reservation data, and a corresponding elastic monitoring strategy is generated to monitor the network status during the initial release period. Thus, by analyzing historical data, risk areas and time periods can be identified in advance, and monitoring strategies can be determined accordingly, providing a basis for subsequent fault diagnosis.

[0027] Specifically, the system accesses all monitoring logs from past game launches or major events to obtain time-series request volume data and network performance data aggregated by timestamp, region, and carrier. Then, the historical full monitoring logs are denoised to remove abnormal traffic points caused by system maintenance and network testing, and missing values ​​are interpolated. The historical request volume, network latency, packet loss rate, and other time-series data from each region are then re-aggregated by "region-carrier" unit, and the network performance baseline for each "region-carrier" unit at the same time period on the historical launch day is calculated. The network performance baseline serves as the basic line for performance indicators such as network latency and packet loss rate, and is used as a reference benchmark for subsequent prediction and dynamic thresholds.

[0028] Furthermore, the system accesses the user reservation data for this game's first release, analyzes the reservation user IPs in real time, maps them to the corresponding "region-operator" units through the IP geolocation database, and determines the user reservation status, such as counting the total number of reservations in each "region-operator" unit and calculating the ratio of new to old users, for subsequent analysis. In some embodiments, the regional budget and channel placement intensity in the game's marketing plan are also quantified into a numerical promotion popularity index and associated with the corresponding "region-operator" unit.

[0029] Furthermore, network architecture information, such as the location of game server clusters, CDN node distribution, and backbone network interconnection points, is transformed into a weighted directed graph network topology. This network topology records the key path nodes and links that users traverse when accessing services from various regions, providing a data foundation for subsequent correlation analysis and fault impact prediction.

[0030] Therefore, the request volume time-series data and network performance data aggregated by timestamp, region, and operator during the aforementioned historical game launch period or major event period, as well as the network performance baseline of each "region-operator" unit at the same time on the historical launch day, and the user reservation status, promotion popularity index, and network association topology map corresponding to the "region-operator" unit, are used to construct a multi-source data pool for predicting network load pressure during the game launch period.

[0031] In this embodiment, when predicting network load pressure, a two-level prediction approach is adopted, combining macroscopic prediction of global traffic trends with microscopic prediction of regional fine-grained pressure, thereby improving the reliability of the prediction. Specifically, for global traffic trend prediction, the Prophet time series prediction model is used. This model can effectively decompose the trend term, seasonal term, and holiday effect of the sequence. During the training process, the request volume time series data of multiple game launch days in history are used as the training set. The model learns the inherent traffic patterns of the launch days and outputs the global traffic change curve for the next 24 hours to grasp the overall load trend. In addition, the Prophet time series prediction model also provides confidence intervals for the predicted values. The width of the confidence interval reflects the uncertainty of the prediction.

[0032] More specifically, for fine-grained regional pressure prediction, multi-dimensional feature vectors are constructed for each "region-operator" unit as input to the regional learning model. These multi-dimensional feature vectors include historical time features, real-time reservation features, market operation features, topology correlation features, and global prediction features. Specifically, historical time features are the network performance baseline of the "region-operator" unit on multiple game launch days in the same historical period; real-time reservation features are the user reservation status of the "region-operator" unit, including the number of reserved users, reservation density, and the proportion of new users; market operation features are the promotion popularity index of the "region-operator" unit; topology correlation features are the network hops from the "region-operator" unit to the core service and the number of shared upstream nodes it relies on, calculated based on the network topology graph; and global prediction features are the predicted value and slope of the global traffic change curve based on the above global traffic trend prediction during the game launch period, enabling the regional learning model to perceive the overall business situation.

[0033] Furthermore, for the regional learning model, the Gradient Boosting Decision Tree (GBDT) model is adopted. Its training samples are the multi-dimensional feature vectors of each "region-operator" unit on the game's launch day and the actual network load pressure value. The model learns the mapping relationship from complex features to actual pressure levels. Spatiotemporal cross-validation is required during training to prevent overfitting. Finally, the model outputs the predicted pressure value for each "region-operator" unit in each future time window. This predicted pressure value is a continuous value and is a quantitative indicator of the expected network load pressure.

[0034] In practical applications, the predicted pressure values ​​of each "region-operator" unit in each time window during the game's initial launch period are obtained through a regional learning model. Then, the predicted pressure values ​​of each time window are converted into preset pressure threshold levels, such as Level S, Level A, Level B, and Level C. Based on the predicted pressure values ​​and the slope of the global traffic change curve, it is determined whether the traffic is in a period of rapid increase, and each "region-operator" unit is dynamically marked as the corresponding pressure level. Specifically, a dynamic quantile method is used to analyze the distribution of pressure values ​​for all "region-operator" units within the current time window. For example, the top 5% of units with the highest pressure values ​​are classified as Level S, the next 15% as Level A, and so on, to adapt to the different overall pressure levels at each game launch. Furthermore, for units with pressure threshold levels of A or B, the second derivative of the global traffic change curve is analyzed in real time to determine the curvature of the current time window. When the curvature is consistently positive and exceeds a preset threshold, the current time period is determined to be a "traffic surge period." For units in a traffic surge period, their pressure level is automatically upgraded by one level, such as from Level A to Level S, to cope with the uncertainty brought by the sudden increase in traffic. Finally, structured labels are generated for each "region-operator" unit in each time window of the game launch, for example: {Unit: "East China-Telecom", Time Window:} "T+30min", predicted pressure value: 0.92, pressure threshold level: S, time period type: traffic surge period, global confidence level: high}, where T represents the start time of the game's launch, indicating that in the "East China-Telecom" unit, 30 minutes after the game's launch, the predicted pressure value exceeds the S-level threshold, and the global traffic change curve is in the traffic surge period, and this pressure level is "S-level pressure - traffic surge period".

[0035] In some embodiments, the step of dynamically generating elastic monitoring strategies based on the network load pressure includes: Based on the pressure level, the monitoring parameters are dynamically adjusted to generate a flexible monitoring strategy. The monitoring parameters include at least the detection frequency and detection depth of network detection under different pressure levels, as well as a dynamic threshold for determining abnormal network status.

[0036] In this embodiment, a pre-configured policy rule base is maintained. This policy rule base is a configurable database that stores multiple policy rules in the form of "IF-THEN" to convert stress levels into executable monitoring parameters.

[0037] Specifically, each policy rule in the policy rule base defines the monitoring parameter template to be used under the corresponding pressure level. The pressure level includes a pressure threshold level and a time period type. Pressure threshold levels include S, A, B, and C levels, and time period types include traffic surge periods, stable periods, and decline periods. The monitoring parameter template is a predefined set of parameters, including at least a detection frequency template and a detection depth template. For the detection frequency template, different dimensions of network detection frequencies are defined for different pressure levels. The pressure threshold level corresponds to a baseline detection frequency, while different time period types correspond to a frequency intensity coefficient. Therefore, for different pressure levels... For different network probing frequencies, such as for the stress level (Level S, peak traffic period), the corresponding baseline probing frequency is F_base_http is 300 seconds, F_base_ping is 120 seconds, and the frequency intensity coefficient is 0.05, which means that the probing frequency is increased by 0.05 times. Then, the network probing frequency corresponding to this stress level (Level S, peak traffic period) is F_http = 300 × 0.05 = 15 seconds / time, and F_ping = 120 × 0.05 = 6 seconds / time, where F_http represents the HTTP dialing side probing frequency and F_ping represents the Ping probing frequency. Similarly, for the probe depth template, different dimensions of network probe depth are defined under different pressure levels. Among them, the pressure threshold level corresponds to the base probe depth, while the time period type corresponds to the depth intensity coefficient. For example, for the pressure level (S level, traffic surge period), the corresponding base probe depth D_base_ping is 10 packets, the depth intensity coefficient is 5.0, and the probe depth D_ping = 10 × 5.0 = 50 packets for each probe in the Ping probe process; HTTP dialing test enables full transaction chain check.

[0038] Furthermore, the policy rule base also includes dynamic threshold templates. These dynamic thresholds are used to determine network anomalies and specifically include performance indicator thresholds and availability indicator thresholds. The performance indicator thresholds are dynamic thresholds for metrics such as average HTTP latency and TCP connection latency, with different thresholds at different pressure threshold levels. Specifically, they are dynamically calculated using a baseline based on historical data statistics and a pressure coefficient related to the pressure threshold level. Specifically, the performance indicator threshold = baseline value × α, where α is the pressure coefficient, set according to the pressure level, such as α=1.5 for level S, α=1.2 for level A, α=1.1 for level B, and α=1.0 for level C. The baseline is the network performance baseline for each "region-operator" unit at the same time period on the historical launch date, calculating its percentile baseline, such as the P95 baseline, which indicates that historically 95% of requests were completed below this value, making it more tolerant of long-tail latency. The availability indicator thresholds specifically include HTTP connection success rate, DNS resolution success rate, etc., and their thresholds remain absolutely strict, such as <99.9% triggering an alarm, and do not change with the pressure threshold level, ensuring that core faults are not overwhelmed.

[0039] Before the game launch, based on the predicted stress level, the corresponding parameter templates are converted into specific elastic monitoring strategies. Then, during the game launch, each probe node loads the monitoring tasks for the launch period based on the elastic monitoring strategies to monitor the network during the launch period.

[0040] Step S200: During the game's initial launch period, based on the elastic monitoring strategy, perform dual-dimensional network probing to obtain probing data. The dual-dimensional network probing includes Ping probing and HTTP dialing. In some embodiments, performing two-dimensional network probing based on the elastic monitoring strategy includes: Load the elastic monitoring strategy, generate a detection task plan for each detection agent node according to the elastic monitoring strategy, and execute serial phase tasks for each detection node. Schedule and execute the detection task plan and the serial phase task, process the detection data generated by each detection agent node and the dialing node, and form a monitoring unit corresponding to each "region-operator" unit network. The real-time situation indicators of the monitoring unit are obtained and compared with the preset dynamic baseline range to determine the abnormal situation; Based on the aforementioned abnormal situation, the detection frequency and detection depth of the corresponding "region-operator" unit are adjusted to trigger the inter-server link check and / or full transaction chain simulation that it depends on.

[0041] In this embodiment, the elastic monitoring strategy generated in step S100 is converted into a corresponding detection task plan and serial phase tasks, and real-time monitoring and adjustment capabilities are introduced to ensure the sensitivity of monitoring during the game's initial launch. Specifically, during the game's initial launch, based on the elastic monitoring strategy, dual-dimensional network detection is adaptively scheduled and executed. This dual-dimensional network detection includes: Ping detection deployed between the game server and the user platform server, and HTTP probes deployed in different geographical regions across the country to simulate user login behavior. By collecting and aggregating network quality data between servers and network connection status data on the user side in real time, the network status during the game's initial launch is monitored.

[0042] Specifically, the configuration file of the elastic monitoring strategy generated in step S100 is loaded. This configuration file defines the detection task parameters corresponding to each region-operator unit in different time windows during the game's launch period, specifically the monitoring parameters such as detection frequency and detection depth, as well as dynamic thresholds for judging abnormal network status.

[0043] For Ping probes deployed between the game server and the user platform server, to accurately reflect the network conditions affecting game services, the Ping probes employ service-oriented path probing. Specifically, based on the network topology model in step S100, critical transmission paths for core service traffic such as game login and lobby services are identified, and probe proxies are deployed end-to-end along these paths. For example, at the egress gateway of the game server cluster and the access layer load balancer of the user account database, customized probe sessions based on TCP or UDP are established between the probe proxies. These customized probe sessions simulate the size and sending pattern of real service data packets and use the same differential service code point marking as the service to ensure that probe traffic and real service flow enjoy the same priority and processing strategy in the network device queue, thereby obtaining the most representative network quality data.

[0044] More specifically, at each probe agent node, a probe task plan is generated according to the elastic monitoring strategy. Each probe task sends a sequence of N probe packets at fixed time intervals within a duration T. The number of probe packets in the probe packet sequence corresponds to the probe depth generated by the Ping probe based on the probe depth template in the elastic monitoring strategy. For example, for (Level S, high traffic surge), D_ping=50, it means that the probe packet sequence consists of 50 probe packets. The fixed time interval corresponds to the probe frequency of the Ping probe. For example, if F_ping=15 seconds / time, it means that the probe agent executes a probe packet sequence of 50 packets every 15 seconds.

[0045] Furthermore, representative network quality data during the probing period is calculated, such as the number of probe packets that do not receive a response within a reasonable waiting time, such as twice the round-trip time. The specific formula is: Packet loss rate = (Number of packets sent - Number of successful response packets) / Number of packets sent × 100%. The round-trip time of each successful response probe packet is recorded, and the arithmetic mean, median latency, and tail latency of the round-trip times of each successful response probe packet are calculated to comprehensively assess the game's lag experience. Latency jitter is calculated. If the round-trip time of the i-th packet is D(i), then the latency difference between consecutive packet pairs (i, i-1) is J(i) = |D(i) - D(i-1)|. The final jitter value J is the statistical average of all J(i), thus quantifying the instability of latency.

[0046] For HTTP probe tests deployed in different geographical regions across the country to simulate user login behavior, in order to simulate the complete process of a real user initiating a game login from their location, the HTTP probe tests are divided into stages to achieve preliminary fault delineation. Specifically, a standardized container runs on each test node, containing a test script interpreter. This interpreter defines test behavior declaratively or codedly. Furthermore, it supports precise configuration of various aspects of HTTP / HTTPS requests, including request header simulation, session state simulation, request body construction, and result assertion. Request header simulation fully simulates the User-Agent, Accept, and Accept-Language headers of the game client. Session state simulation manages cookies and session tokens, supporting state maintenance in multi-step transactions. Request body construction correctly constructs game-specific login request bodies that may be encoded or encrypted. Result assertion parses and asserts specific fields in the response status code, response headers, and JSON / XML response body, such as {"code": 0, "message": "success"}, to determine the success or failure of business logic.

[0047] Furthermore, based on the HTTP probe frequency in the elastic monitoring strategy, corresponding probe requests, such as login requests, are sent to the probe nodes according to their probe frequency. It's worth noting that the standardized container also has a staged probe collector that decomposes each probe request into multiple serial stage tasks, and performs independent timing and status recording. Specifically, a login request is decomposed into DNS resolution, TCP connection, TLS / SSL handshake, and HTTP transaction stages. In the DNS resolution stage, the total resolution time, the list of resolved IP addresses, the local DNS server address, and whether CNAME redirection occurred are recorded. Timeouts or failures are attributed to local DNS failures or authoritative DNS issues; resolving uncommon IPs may indicate DNS hijacking or poisoning. For the TCP connection stage, the TCP three-way handshake time is obtained, whether SYN-ACK (success), RST (rejection), or timeout is received, and the target IP and port are recorded. An abnormally long handshake time indicates network congestion; receiving an RST explicitly indicates firewall or service port blocking; a timeout indicates network unreachability. For the TLS / SSL handshake phase, obtain the complete TLS handshake time, the negotiated protocol version, the cipher suite used, and the certificate verification result. A slow handshake indicates server performance issues or decryption bottlenecks in intermediate devices; certificate errors directly indicate security configuration failures. For the HTTP transaction phase, collect TTFB (Time to First Byte), which is the time from sending the request header to receiving the first byte of the response, reflecting server processing latency; the time to receive the complete response body; the total time from sending the request to receiving the response; HTTP status codes such as 200, 302, 403, 502, and 504; and the response body verification result: use script assertions to determine whether the business logic succeeded. A high TTFB usually indicates slow server application processing; and specific HTTP status codes are directly associated with specific errors in the web server, application gateway, or backend service.

[0048] Furthermore, network connection status data is obtained, specifically the execution results of each sequential stage, such as DNS resolution failure rate, TCP connection anomaly rate (rejection / timeout / reset), HTTP error code ratio, HTTP response latency (P95), login success rate, etc. Simultaneously, the public IP address, geographical location, ISP, and the corresponding probe frequency and depth in the elastic monitoring policy at the time of each test are recorded for the source node.

[0049] In some embodiments, the deployment of the probe node specifically includes: A spatial index is established for the game's initial launch area, forming a region-operator as the smallest planning unit, and attributes are deployed for the associated nodes of each planning unit; Based on the node deployment attributes, calculate the comprehensive weight of each planning unit and set constraints for each node deployment attribute; Based on the unit comprehensive weight and the constraints, the number of monitoring nodes for each planning unit is determined.

[0050] Furthermore, for determining the HTTP testing nodes, a spatial index is established for the initial region, such as a nationwide gridded spatial index, using prefecture-level administrative regions as the basic unit. Simultaneously, considering operator network affiliation, (region, operator) tuples are formed as the smallest planning unit. For example: (Hangzhou, China Telecom), (Hangzhou, China Mobile). Then, attributes are deployed for each planning unit's associated nodes, specifically including user reservation density, historical fault frequency, operator diversity coefficient, topology criticality weight, and deployment cost. User reservation density corresponds to user reservations in the multi-source data pool. User reservation data is converted into a geographical distribution heatmap of reserved users and normalized to the [0, 100] interval as the attribute value of user reservation density. Historical fault frequency corresponds to the number of times network faults occurred in the initial planning unit in past games, normalized to [0, 100]. The operator diversity coefficient is calculated based on the broadband / mobile user market share of each operator in the region, using the reciprocal of the Herfindahl-Hirschman index to quantify operator diversity in each region. The specific formula is: Where, s_i represents the user share of operator i in the region, M is the number of operators, and the higher the D value, the more balanced the operator distribution, requiring the deployment of more diverse testing nodes; topology criticality weight, based on whether CDN edge nodes, provincial backbone network exits, IXP exchange centers, etc. are deployed in the region, is output by the network topology model as a weighted value; deployment cost, obtained from the cloud service provider's API, is the hourly unit price of on-demand instances in the region, combined with quota restrictions to calculate the cost coefficient.

[0051] Furthermore, based on the node deployment attributes of each planning unit, the deployment problem of the testing node is transformed into a multi-objective decision-making process. Specifically, let x_{ij}∈{0,1} represent whether to deploy the testing node in the j-th operator unit of the i-th region. For each planning unit, its unit comprehensive weight is calculated. Specifically, W_{ij} =α·user_density_{ij}+β·history_fault_freq_{ij}+γ·isp_share_entropy_{ij}+δ·topology_weight_{ij}, where α, β, γ, and δ are hyperparameters, whose initial values ​​are determined through expert experience and can be optimized and adjusted subsequently. In addition, user_density represents user reservation density, history_fault_freq represents historical fault frequency, isp_share_entropy represents operator diversity coefficient, and topology_weight represents topology criticality weight.

[0052] Furthermore, the unit comprehensive weight setting for each planning unit maximizes the total coverage weight, specifically as follows: In addition, corresponding constraints need to be set for the deployment attributes of each node, such as total budget constraint, ∑_{i,j}x_{ij}·cost_{ij}≤B, where B is the preset total budget for node deployment, and cost_{ij} represents the deployment cost of the j-th operator unit in the i-th region; operator coverage constraint, for each major operator j, such as China Telecom, China Unicom, and China Mobile, constrain ∑_{i}x_{ij}≥N_{min} to ensure that each operator has at least N_{min} nodes nationwide; and regional minimum coverage constraint, mainly for key areas, such as East China and South China, which mandates that at least R_{min} nodes be deployed.

[0053] Furthermore, all candidate planning units are sorted in descending order by unit cost weight, and units are selected sequentially until the lower limit of the operator coverage constraint is met, generating an initial feasible solution, where unit cost weight = W_{ij} / cost_{ij}. Then, the initial feasible solution is used as a hot start, and the branch and bound method or heuristic search is called to optimize the global solution under the total budget constraint. Finally, a node deployment list is output, which contains the number of test nodes to be deployed for each planning unit.

[0054] Furthermore, T hours before the game's launch (typically T=24), the multi-cloud management interface, such as Terraform, AWS CloudFormation, and Alibaba Cloud ROS, is called based on the node deployment list to instantiate the nodes. Then, during the game's launch, the corresponding nodes are started, and the probing agent running on them, i.e., the standardized container, actively initiates a registration request to the node management service, reporting metadata such as the globally unique identifier node_id, geographical location, carrier, IP address, and resource specifications. At the same time, the node management service periodically performs heartbeat detection on the registered nodes, maintains the node status table, and marks them as online / offline / busy / awaiting reclamation.

[0055] In addition, each testing node, upon registration, includes not only static metadata such as the globally unique identifier `node_id`, geographical location, carrier, IP address, and resource specifications, but also dynamic tags corresponding to the stress level. The deployed nodes form a testing resource pool. When executing a probe task, the corresponding testing node is triggered only if it meets the stress level of its corresponding region-carrier unit. Specifically, the elastic monitoring strategy includes, in addition to probe frequency, probe depth, and dynamic thresholds, selection criteria for HTTP testing nodes. Based on these criteria, a set of testing nodes meeting the conditions is selected from the testing resource pool for HTTP testing. These selection criteria include at least geographical conditions, carrier conditions, and stress threshold level conditions. For the selected testing nodes, during the game's initial launch period, corresponding probe tasks are executed based on the HTTP testing probe frequency and probe requests of the elastic monitoring strategy.

[0056] In some embodiments, the probe data includes inter-server network quality data and user-side network connection status data; The preprocessing of the probe data specifically includes: receiving the raw probe logs of all probe nodes, parsing and cleaning the raw probe logs, and attaching spatial and policy tags to each data record to generate structured data. The spatial tags include at least geographical area and operator information, and the policy tags identify the probe task plan that generated the data record, as well as the elastic monitoring strategy and stress level on which it is based.

[0057] Specifically, the network quality data between servers corresponds to Ping probes deployed between the game server and the user platform server, while the network connection status data on the user side corresponds to HTTP probes deployed in different geographical regions across the country, simulating user login behavior. The raw probe logs generated during Ping probes and HTTP probes are parsed and cleaned, and spatial and policy tags are attached to them for use as data sources for subsequent real-time situation indicators and fault diagnosis. The spatial tag must at least include the "region-operator" unit that generated the data record, corresponding to the geographical region and operator information, while the policy tag is the elastic monitoring policy and stress level generated by the data record. In addition, it must also include the probe type corresponding to the data record, namely Ping probes and HTTP probes.

[0058] Furthermore, for each "region-carrier" unit, a monitoring unit corresponding to Ping probes and HTTP probes is defined. Specifically, for Ping probes, the monitoring unit includes the start and end points of the inter-server probe proxy, as well as probe indicators, which correspond to network quality data such as packet loss rate and latency. For HTTP probes, the monitoring unit includes the corresponding geographical region, carrier information, probe requests, and probe indicators for each probe request at each serial stage, such as the failure rate of the DNS resolution stage and the connection failure rate of the TCP connection stage.

[0059] Furthermore, the detection and testing indicators of each monitoring unit are aggregated and categorized into performance indicators and availability indicators. Performance indicators specifically include values ​​reflecting network performance such as average HTTP latency, TCP connection latency, and packet loss rate. Availability indicators specifically include indicators reflecting successful execution such as HTTP connection success rate, DNS resolution success rate, and login success rate. In addition, to avoid a large number of false alarms during peak business periods at the game's launch and during normal fluctuations, a dynamic baseline range is maintained for each indicator. This range adjusts adaptively over time. Specifically, the dynamic baseline for performance indicators includes a mean baseline μ_t and a variance baseline σ_t. Specifically, the mean baseline μ_t = a × x_t + (1-a) × μ_{t-1}, and the variance baseline... Where 'a' is a smoothing factor, typically ranging from 0.1 to 0.3, controlling the decay rate of historical data; 'x_t' represents the real-time situation indicator at the current time 't'; and the initial value of 'μ_{t-1} is the performance indicator threshold set by the elastic monitoring strategy for each indicator in the corresponding 'region-operator' unit based on the dynamic threshold template. The dynamic baseline of the availability indicator class corresponds to the availability indicator threshold set by the elastic monitoring strategy for each indicator in the corresponding 'region-operator' unit based on the dynamic threshold template.

[0060] Furthermore, on the game's launch day, real-time situation indicators x_t from each monitoring unit are acquired and compared with the corresponding dynamic baseline. Specifically, for performance indicators, anomaly detection is based on x_t > μ_t + k × σ_t or x_t < μ_t - k × σ_t, where k is a sensitivity coefficient, defaulting to 2.0, which can be dynamically adjusted according to the pressure threshold level (e.g., k = 2.5 under S-level pressure threshold to reduce false alarms). For availability indicators, if the availability indicator threshold is not met, it is considered abnormal. In addition, since a single deviation may be a momentary spike, the judgment process can involve continuous deviations over multiple windows before confirming an "abnormal situation." For example, in one embodiment, a continuous anomaly count threshold N = 3 is set.

[0061] Furthermore, when a monitoring unit enters an "abnormal state," the detection frequency of the HTTP probe node or probe proxy node to which that monitoring unit belongs is temporarily increased to the diagnostic frequency. The increase is determined by the severity of the anomaly; that is, the greater the deviation, the higher the frequency. For HTTP probes, full transaction chain simulation is enabled, expanding the probe depth from only requiring login requests to full transaction service chain requests such as "login → store browsing → item purchase," in order to expose deep-seated problems in the service chain. For Ping probes, based on the network topology diagram, the upstream server links relied upon by the user access path of the abnormal monitoring unit are queried, such as CDN edge node → origin server, data center egress gateway → core switch, etc. Real-time probe tasks are immediately sent to the Ping probe proxies of these links, such as continuously sending 100 packets at 10ms intervals to obtain real-time packet loss rate, jitter, and latency.

[0062] Step S300: Based on the detection data and combined with the pre-trained fault diagnosis model, generate diagnostic suggestion information.

[0063] In some embodiments, step S300 above includes: Based on the detection data of the monitoring unit in an abnormal state, a fused feature vector is constructed; The fused feature vector is input into a pre-trained fault diagnosis model to obtain the probability distribution output of multiple preset fault root cause categories; Based on the output of the probability distribution, at least one root cause inference with the highest confidence is determined, and diagnostic suggestion information is generated based on the preset diagnosis-suggestion mapping rules.

[0064] In this embodiment, the detection data during the detection process of the monitoring unit in an abnormal state is used as the data source for root cause inference to determine the root cause of network anomalies during the game's initial release and generate corresponding decision suggestions to provide guidance for operation and maintenance personnel.

[0065] Specifically, based on the probe data, a fused feature vector is constructed. This fused feature vector includes at least three data feature layers. The first layer is the network performance feature layer. By standardizing the probe data of the monitoring unit in an abnormal state, such as for Ping probe data, the inter-server network features such as packet loss rate, latency jitter, and average latency are obtained. In addition, it also includes the inter-server network features between the upstream inter-server links on which the access path depends during the inter-server link inspection process, based on the diagnostic frequency. For HTTP probe testing, user-side probe testing features such as DNS resolution failure rate, TCP connection rejection / timeout rate, TCP connection reset rate, HTTP 4xx / 5xx status code ratio, HTTP average response latency, and login success rate are obtained. Similarly, it also includes the user-side probe testing features generated during the full transaction chain simulation process, based on the diagnostic frequency, where the probe depth is expanded from only requiring login requests to requiring requests across the entire transaction service chain. The second layer, specifically the business context feature layer, provides background information for model diagnosis. This typically includes geographic region coding, carrier coding, relative time points, and predicted stress levels. The relative time point is the number of minutes since the game's initial release, used to identify patterns related to specific time periods. The third layer, the derived feature layer, provides deeper insights, including correlation between indicators, the spread of impact, and topological correlation features. Correlation between indicators calculates the correlation coefficient between anomalies in various indicators; for example, calculating the correlation coefficient between increased HTTP latency and increased TCP reset rate within a short time window. The spread of impact calculates the number of "region-carrier" units exhibiting similar anomalies and their geographical concentration, used to distinguish between localized failures and global events. Topological correlation features, based on network topology data, calculate whether upstream servers or links commonly relied upon by the anomaly units also experience performance degradation.

[0066] More specifically, gradient boosting decision trees are preferred as the core classifier of the fault diagnosis model. Specifically, gradient boosting decision trees have excellent feature combination capabilities, robustness to missing values, and can provide feature importance ranking, thus enhancing the interpretability of the diagnosis.

[0067] In the fault diagnosis model process, a historically accumulated confirmed case library is used for supervised training. Each case in the confirmed case library contains all the features of the above-mentioned fused feature vector when the fault occurred on the game's launch day, as well as standardized root cause labels that have been finally confirmed by humans. The root cause labels are a predefined set of mutually exclusive fault categories, including edge service node resource overload, regional operator network link failure, global DNS resolution anomaly, data center egress bandwidth congestion, and firewall policy misinterpretation.

[0068] Specifically, through training, the fault diagnosis model can output probability distribution vectors corresponding to each fault root cause category in the fused feature vector. It selects 1 to 3 root cause categories with higher confidence as the root cause inference results. Then, based on the root cause inference results and specific feature values, it generates natural language-described alarms and remediation suggestions from a diagnosis-suggestion mapping library, generating diagnostic suggestion information. Specifically, the diagnostic suggestion information includes core conclusions, key features, contextual information, and action suggestions. The core conclusions specifically include root cause inference and confidence levels, such as: [edge node overload], and confidence level... 92%; Key evidence includes listing 2-3 of the most significant characteristic indicators and their outliers supporting each root cause inference. For example, for the root cause inference of "edge node overload" mentioned above, the evidence is an increase of 300ms in HTTP latency P95, an 8% TCP connection timeout rate, and normal data center-side link indicators; Contextual information includes the pressure level associated with the affected "region-carrier" machines; Action recommendations are specific and actionable suggestions, such as: 1. Check and elastically expand the CPU / connection limit configuration of the 'East China-Shanghai' edge node cluster; 2. Verify the CDN origin bandwidth in this region, etc.

[0069] Please see Figure 2 As shown, the present invention also provides a network monitoring system for game launches, the system comprising: First processing module 201: Used to predict the network load pressure at different times and in different geographical areas during the launch period based on historical launch data and user reservation data before the game's launch, and dynamically generate elastic monitoring strategies based on the network load pressure. The second processing module 202 is used to perform two-dimensional network probing based on the elastic monitoring strategy during the game's initial launch period to obtain probing data. The two-dimensional network probing includes Ping probing and HTTP dialing probing. The third processing module 203 is used to generate diagnostic suggestion information based on the detection data and in combination with a pre-trained fault diagnosis model.

[0070] It is understandable that, such as Figure 1 The content of the network monitoring method embodiment for game launch shown is applicable to the network monitoring system embodiment for game launch shown here. The specific functions implemented by the network monitoring system embodiment for game launch shown here are the same as those shown below. Figure 1 The network monitoring method for game launch shown is the same as the embodiment described above, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the network monitoring method embodiment shown for game launch are also the same.

[0071] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0072] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0073] Please see Figure 3 As shown, this embodiment of the invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the network monitoring method for game launch as described in any of the above methods.

[0074] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0075] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0076] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0077] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the network monitoring method for game launch as described in any of the above methods.

[0078] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / computer device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0079] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A network monitoring method for game launches, characterized in that, include: Before the game's official launch, based on historical launch data and user reservation data, the network load pressure during different time periods and in different geographical areas is predicted, and elastic monitoring strategies are dynamically generated based on the network load pressure. During the game's initial launch period, based on the aforementioned elastic monitoring strategy, a two-dimensional network probe was performed to obtain probe data. The two-dimensional network probe included Ping probe and HTTP probe. Based on the detection data, and combined with a pre-trained fault diagnosis model, diagnostic suggestion information is generated.

2. The method as described in claim 1, characterized in that, The prediction of network load pressure during different time periods and geographical areas during the initial launch period, based on historical launch data and user reservation data, includes: A multi-source data pool is constructed based on historical initial release data and user reservation data; Based on the aforementioned multi-source data pool, a time series analysis model is used to predict the global traffic change curve on the game's launch day. The regional learning model is used to predict the predicted pressure value of each "region-operator" unit within a preset time window; Based on the predicted pressure value and combined with the global traffic change curve, structured tags are generated for each "region-operator" unit within different time windows during the game's initial release, and the pressure level of the structured tags is determined.

3. The method as described in claim 2, characterized in that, The step of dynamically generating elastic monitoring strategies based on the network load pressure includes: Based on the pressure level, the monitoring parameters are dynamically adjusted to generate a flexible monitoring strategy. The monitoring parameters include at least the detection frequency and depth of network detection under different pressure levels, the sampling intensity of network quality detection, and the dynamic threshold for determining network status abnormalities.

4. The method as described in claim 1, characterized in that, The two-dimensional network probing based on the elastic monitoring strategy includes: Load the elastic monitoring strategy, generate a detection task plan for each detection agent node according to the elastic monitoring strategy, and execute serial phase tasks for each detection node. Schedule and execute the detection task plan and the serial phase task, process the detection data generated by each detection agent node and the dialing node, and form a monitoring unit corresponding to each "region-operator" unit network. The real-time situation indicators of the monitoring unit are obtained and compared with the preset dynamic baseline range to determine the abnormal situation; Based on the aforementioned abnormal situation, the detection frequency and detection depth of the corresponding "region-operator" unit are adjusted to trigger the inter-server link check and / or full transaction chain simulation that it depends on.

5. The method as described in claim 4, characterized in that, The deployment of the aforementioned test nodes specifically includes: A spatial index is established for the game's initial launch area, forming a region-operator as the smallest planning unit, and attributes are deployed for the associated nodes of each planning unit; Based on the node deployment attributes, calculate the comprehensive weight of each planning unit and set constraints for each node deployment attribute; Based on the unit comprehensive weight and the constraints, the number of monitoring nodes for each planning unit is determined.

6. The method as described in claim 4, characterized in that, The detection data includes inter-server network quality data and user-side network connection status data. The preprocessing of the probe data specifically includes: receiving the raw probe logs of all probe nodes, parsing and cleaning the raw probe logs, and attaching spatial and policy tags to each data record to generate structured data. The spatial tags include at least geographical area and operator information, and the policy tags identify the probe task plan that generated the data record, as well as the elastic monitoring strategy and stress level on which it is based.

7. The method as described in claim 1, characterized in that, Based on the detected data and combined with a pre-trained fault diagnosis model, diagnostic suggestion information is generated, including: Based on the detection data of the monitoring unit in an abnormal state, a fused feature vector is constructed; The fused feature vector is input into a pre-trained fault diagnosis model to obtain the probability distribution output of multiple preset fault root cause categories; Based on the output of the probability distribution, at least one root cause inference with the highest confidence is determined, and diagnostic suggestion information is generated based on the preset diagnosis-suggestion mapping rules.

8. A network monitoring system for game launches, characterized in that, include: The first processing module is used to predict the network load pressure at different times and in different geographical areas during the launch period based on historical launch data and user reservation data before the game's official launch, and to dynamically generate elastic monitoring strategies based on the network load pressure. The second processing module is used to perform two-dimensional network probing based on the elastic monitoring strategy during the game's initial launch period to obtain probing data. The two-dimensional network probing includes Ping probing and HTTP dialing. The third processing module is used to generate diagnostic suggestion information based on the detection data and a pre-trained fault diagnosis model.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images