Check Alert Log. Most of the triggers for Alert are Availability Alert. The Error that affects the available Alert is: task timeout Error.
2. Check the common features of error reports (1) Time: Error reports began to increase after January 9th (2) City operators with concentrated error reports: Taiyuan China Unicom, Lanzhou China Unicom, Xining China Mobile, Hangzhou China Unicom, Zhengzhou China Mobile, etc.; (3) The error Host is mainly concentrated in: 2408:872XXX0:fff5::2e (Yangquan China Unicom), 2408:80XXXX::5d (Gansu China Unicom), 2409:8c74:XXXXX38 (Gansu Mobile). 3. View scatter point detailed data, (1) Viewing takes time at "Connection Establishment Time". (2) Check the "SSL Handshake Time" time. 4. Packet capture details: (1) Connection establishment problem: Through packet capture, we can see that the client sent a SYN packet to the server, but did not receive the SYN ACK confirmation packet from the server. (2) SSL Handshake Time problem: The client sent a client hello, but no server hello. The client did not know whether the server responded, and checked the supported version. The TLS1.2 version was used. 5. Recurrence (1) Use the error Probe to access https://wwwXXXXcom/ with IPv6 specified; no task timeout occurs. (2) Use the error Probe to access https://www.XXXX.com/ with any IP protocol; no task timeout occurs, and both IPv4 and IPv6 data are produced. (3) Use the error message Probe to access Baidu, and the data is normal.
Through the above summary (1) There is no problem with Probe; (2) It is suspected that it is a Host problem with a high error rate. The customer needs to assist in checking the Log corresponding to the server to see whether the Request from the client has been received and whether feedback has been provided;The above feedback: Customer feedback said that it is not a server-side problem.
If it is not a client problem or a server problem, it is a problem with the operator. The connection establishment or SSL Handshake Time was unsuccessful due to the poor Network environment. Two preliminary temporary solutions: Option one: Filter out the Probe that have problems, and Probe Group forces these Probe to use the IPv4 protocol; After the Probe Group operation, the report data has been restored, but the phenomenon still occurs occasionally. Option two: Since the popularity rate of v6Network is not as high as v4, in order to ensure the stability of Synthetic data, you can filter in task Probe, force the use of v4Probe for Synthetic, and set the selection bandwidth of more than 50 for Probe for Synthetic.