CDN-based service alarm processing method and apparatus, and device and medium

Abstract

Provided in the present disclosure are a CDN-based service alarm processing method and apparatus, and a device and a medium. The method comprises: acquiring detection data and cause analysis data that correspond to a target domain name; using the detection data to determine whether to execute a service alarm corresponding to the target domain name; if it is determined that the service alarm corresponding to the target domain name is to be executed, using the cause analysis data to determine a service alarm cause; and acquiring a sending policy corresponding to the service alarm cause, and sending the service alarm cause according to the sending policy.

Description

A CDN-based service alarm processing method, device, equipment and medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of Chinese Patent Application No. 202311511663.5 filed on November 14, 2023. The entire teachings of the above application are incorporated herein by reference. Technical Field

[0003] The present disclosure relates to the field of network communications, and in particular to a CDN-based service alarm processing method, device, equipment, and medium. Background Art

[0004] Service monitoring is a crucial component of Content Delivery Network (CDN) services. Currently, when a CDN service alarm is triggered, operations and maintenance personnel can immediately intervene to address the issue, prevent losses, and ensure stable customer service. Therefore, immediate intervention by operations and maintenance personnel is crucial. With the gradual expansion of CDN services, the number of alarms has exploded. Alarms are caused by a variety of factors, with origin server issues and normal behavior triggering a high proportion. Operations and maintenance personnel only need to focus on CDN issues.

[0005] Existing solutions primarily rely on setting up automated scripts to automate alarm processing. However, alarms can arise from a wide variety of sources, and automated scripts can only handle simple functions and often fail, ultimately requiring human intervention. Furthermore, faced with a massive volume of alarms, it's impossible to distinguish the true cause.

[0006] Summary of the Invention

[0007] In view of this, the embodiments of the present disclosure provide a CDN-based service alarm processing method, device, electronic device and storage medium to solve the problem of being unable to distinguish the true cause of the alarm in the face of a massive amount of alarms.

[0008] In a first aspect, an embodiment of the present disclosure provides a CDN-based service alarm processing method, the method comprising:

[0009] Obtain detection data and cause analysis data corresponding to the target domain name, wherein the detection data is obtained based on detecting access behavior of the client corresponding to the CDN node to the target domain name, and the cause analysis data is obtained based on the access behavior and node performance data of the CDN node;

[0010] Use the detection data to determine whether to execute the business alarm corresponding to the target domain name;

[0011] If the service alarm corresponding to the target domain name is determined to be executed, the cause of the service alarm is determined using the cause analysis data;

[0012] Obtain the sending policy corresponding to the business alarm reason, and send the business alarm reason according to the sending policy.

[0013] In a second aspect, an embodiment of the present disclosure provides a CDN-based service alarm processing device, the device comprising:

[0014] An acquisition module, configured to acquire detection data and cause analysis data corresponding to a target domain name, wherein the detection data is obtained by detecting access behavior of a client corresponding to a CDN node to the target domain name, and the cause analysis data is obtained based on the access behavior and node performance data of the CDN node;

[0015] A determination module, configured to use the detection data to determine whether to execute a service alarm corresponding to the target domain name;

[0016] An analysis module, configured to determine the cause of the service alarm by using the cause analysis data if a service alarm corresponding to the target domain name is determined to be executed;

[0017] The sending module is used to obtain the target receiving device corresponding to the service alarm reason and send the service alarm reason to the target receiving device.

[0018] In a third aspect, an embodiment of the present disclosure provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, computer instructions stored in the memory, and the processor executing the method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0019] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method of the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] FIG1 is a schematic diagram of a CDN-based service alarm processing system according to some embodiments of the present disclosure;

[0022] FIG2 is a flow chart of a CDN-based service alarm processing method according to some embodiments of the present disclosure;

[0023] FIG3 is a schematic diagram of a process for sending a service alarm reason according to some embodiments of the present disclosure;

[0024] FIG4 is a structural block diagram of a CDN-based service alarm processing device according to an embodiment of the present disclosure;

[0025] FIG5 is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0026] To make the purpose, technical solutions, and advantages of the embodiments of the present disclosure more clear, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present disclosure.

[0027] According to an embodiment of the present disclosure, a CDN-based service alarm processing method, apparatus, electronic device, and storage medium are provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0028] Figure 1 is a schematic diagram of a CDN-based service alarm processing system according to an embodiment of the present disclosure. As shown in Figure 1 , the system includes a big data platform and multiple CDN nodes. CDN nodes can be understood as CDN servers and alarm processing terminals. The big data platform is connected to multiple CDN nodes, and the big data platform is connected to the alarm processing terminals. The big data platform is a comprehensive software and hardware infrastructure for managing, processing, and analyzing large-scale data sets. The big data platform can be understood as a system composed of multiple components and services.

[0029] The CDN node 100 is used to detect the client's access to the domain name and record the access log of the domain name. The CDN node sends the access log and the node performance data of the CDN node itself to the big data platform at the preset time. The access log mainly includes time, domain name, status code, client IP, abnormal status code and the source of the abnormal status code, etc. The node performance data mainly includes: the load of the CDN node, retransmission rate, memory, packet loss rate, etc. In addition, the source of the abnormal status code can be recorded by the cache service component in the CDN node. The cache service component can be used as a client to request the source station. When the source station directly returns an abnormal status code (4XX or 5XX), the source of the abnormal status code is recorded. When the source station is abnormally inaccessible, the cache service component records the cause of the abnormality, such as TCP link failure, HTTP no response, etc.

[0030] The big data platform 200 is used to receive access logs and node performance data from each CDN node. It aggregates and cleans the access logs and node performance data to obtain detection data and cause analysis data corresponding to each domain name accessed by the client. Specifically, the big data platform cleans the access logs to obtain detection data, which includes time, domain name, status code, and bandwidth. Cause analysis data includes domain name, UA / referrer / client IP distribution, the source of abnormal status codes, and the CDN node's CPU load, memory utilization, and disk I / O.

[0031] Specifically, first, access logs and node performance data are collected from each CDN node and sent to the big data platform. On the big data platform, appropriate tools (such as Flume or Kafka) are used to aggregate this data to ensure data integrity and consistency.

[0032] Secondly, the aggregated access log data is cleaned, which mainly includes the following steps:

[0033] Parse each field in the access log, such as time, domain name, status code, and bandwidth. Filter out invalid data, such as abnormal status codes or invalid domain names, based on predefined rules or patterns. Standardize the parsed data to conform to a unified data format and structure. For example, convert the time field to a unified time format and the status code to a standard status code. Perform anomaly detection on the data to identify potentially problematic data points. For example, detect data points with unusually high or low access frequencies.

[0034] Cleaning node performance data: Cleaning the aggregated node performance data mainly includes the following steps: Parsing each field in the node performance data, such as CPU load, memory usage, disk IO, etc. Filter out invalid data, such as abnormal node status or invalid performance indicators, based on predefined rules or patterns. Standardize the parsed data to conform to a unified data format and structure. For example, convert the node status into a standard status description, and convert the performance indicator into a standard indicator name. Perform anomaly detection on the data to identify data that may have problems. For example, detect data with abnormally high CPU load or abnormally low memory usage.

[0035] Finally, detection data is obtained based on the cleaned access logs, and cause analysis data is obtained based on the cleaned access logs and node performance data.

[0036] The alarm processing terminal 300 receives detection data and cause analysis data from the big data platform. It then uses the detection data to determine whether to execute the service alarm corresponding to the target domain name. If the service alarm corresponding to the target domain name is to be executed, it uses the cause analysis data to determine the cause of the service alarm. Finally, it obtains the delivery policy corresponding to the service alarm cause and delivers the service alarm cause according to the delivery policy.

[0037] The disclosed embodiment detects the client's access behavior to the target domain name to obtain corresponding detection data. This detection data is used to determine whether to execute a service alarm for the target domain name. If a service alarm is executed, the problem is directly located and analyzed using the cause analysis data to determine the cause of the service alarm. Even when faced with a large number of service alarms, the true cause of the alarm can be determined and promptly transmitted to the receiving device. This helps operation and maintenance personnel quickly respond to and handle access anomalies, improving the processing rate of service alarms. This also improves the stability and accuracy of the system.

[0038] In an embodiment of the present disclosure, a CDN-based service alarm processing method is provided. FIG2 is a flow chart of a CDN-based service alarm processing method according to an embodiment of the present disclosure. As shown in FIG2 , the flow chart includes the following steps:

[0039] Step S11, obtain detection data and cause analysis data corresponding to the target domain name. The detection data is obtained by detecting the access behavior of the client corresponding to the CDN node to the target domain name, and the cause analysis data is obtained based on the access behavior and node performance data of the CDN node.

[0040] The method provided by the embodiment of the present disclosure is applied to the alarm processing terminal, which receives the detection data and cause analysis data corresponding to each CDN node sent by the big data platform. The detection data is obtained based on the access log. The access log is obtained by the CDN node detecting the access behavior of the client for the client. The detection data includes: time, target domain name, status code, bandwidth, network delay, etc. The cause analysis data is obtained based on the access log and the node performance data of the CDN node. The cause analysis data includes: target domain name, UA / referer / client IP distribution, the source of the abnormal status code, the CPU load, memory, disk IO, etc. of the CDN node.

[0041] Step S12: Determine whether to execute a service alarm corresponding to the target domain name using the detection data.

[0042] In some optional implementations, determining whether to execute a service alarm corresponding to the target domain name using the detection data includes the following steps A1-A4:

[0043] Step A1: Query the domain name blocking list.

[0044] In some optional implementations, when using detection data to determine whether to execute a service alert corresponding to a target domain name, the alert processing terminal first queries a pre-configured domain name blocking list. The domain name blocking list includes multiple domain names for which alert determination is not required. Specifically, when certain domain names frequently generate invalid service alerts, to reduce the interference of invalid alerts, embodiments of the present disclosure configure a domain name blocking list. By configuring the domain name blocking list, domain names that frequently generate invalid service alerts can be blocked. Blocked domain names will not be subject to the subsequent service alert determination process.

[0045] Step A2: If the target domain name does not belong to the domain name blocking list, access behavior data corresponding to each preset indicator is extracted from the detection data.

[0046] In some optional implementations, if the target domain name does not belong to or does not exist in the domain name block list, the alarm processing terminal can extract access behavior data corresponding to various preset indicators from the detection data. The preset indicators can be bandwidth, network latency, status code, etc. The access behavior data corresponding to bandwidth can include bandwidth utilization, bandwidth flow, and bandwidth error rate, etc. The access behavior data corresponding to network latency can include network latency level and latency time, etc. The access behavior data corresponding to the status code can include the key code segment of the status code.

[0047] Step A3: Obtain an alarm detection strategy corresponding to the target domain name. The alarm detection strategy includes alarm conditions corresponding to various preset indicators.

[0048] In some optional implementations, each domain name corresponds to a different alarm detection strategy. The alarm detection strategy for a domain name can be configured based on the service type corresponding to the domain name. For example, for each service type, the indicators to be detected are determined. Depending on the characteristics and needs of the service type, different indicators such as bandwidth, network latency, and status code can be selected for detection. The alarm detection strategy includes the alarm conditions corresponding to each preset indicator.

[0049] For example, taking bandwidth as an example, the alarm conditions for bandwidth include: triggering an alarm when bandwidth utilization reaches or exceeds a preset utilization threshold. For example, you can set an alarm to trigger when bandwidth utilization exceeds 80%. triggering an alarm when bandwidth traffic reaches or exceeds a preset threshold. For example, you can set an alarm to trigger when bandwidth traffic exceeds 1GB / s. triggering an alarm when the bandwidth error rate reaches or exceeds a preset threshold. For example, you can set an alarm to trigger when the bandwidth error rate exceeds 0.5%.

[0050] Step A4: Match the access behavior data corresponding to the preset indicator with the alarm condition to determine whether to execute the service alarm corresponding to the target domain name.

[0051] In some optional implementations, the access behavior data corresponding to the preset indicators are matched with the alarm conditions to determine whether to execute the business alarm corresponding to the target domain name, including: if the access behavior data corresponding to the preset indicators hits the alarm conditions, then it is determined that the business alarm corresponding to the target domain name is executed; or, if the access behavior data corresponding to the preset indicators does not hit the alarm conditions, then it is determined that the business alarm corresponding to the target domain name is not executed.

[0052] For example, if bandwidth utilization exceeds the utilization threshold of 80%, an alarm condition is determined to have been triggered, and a service alarm is triggered. If bandwidth traffic exceeds the traffic threshold of 1 GB / s, an alarm condition is determined to have been triggered, and a service alarm is triggered. If the bandwidth error rate exceeds the bandwidth error rate threshold of 0.5%, an alarm condition is determined to have been triggered, and a service alarm is triggered.

[0053] Step S13: If it is determined that the service alarm corresponding to the target domain name is to be executed, the cause of the service alarm is determined using the cause analysis data.

[0054] In some optional implementations, if it is determined to execute the business alarm corresponding to the target domain name, it is determined whether the target domain name is configured with a corresponding alarm diagnosis mechanism. If the domain name is configured with an alarm diagnosis mechanism, the alarm diagnosis mechanism is triggered to take effect. If the target domain name is not configured with a corresponding alarm diagnosis mechanism, the default alarm policy is obtained and an alarm message is sent to the processing terminal configured by the default alarm policy. The alarm message can be understood as an alarm prompt message.

[0055] For example, the domain name www.example.com corresponds to the target business, and there are multiple subdomains under this domain name, such as video.example.com and music.example.com. video.example.com corresponds to the video business under the target business. music.example.com corresponds to the music business under the target business. Among them, video.example.com is configured with an alarm diagnosis mechanism, and music.example.com is not configured with an alarm diagnosis mechanism. When the alarm processing terminal processes the business alarm of a domain name, if the domain name is configured with an alarm diagnosis mechanism, the cause analysis data is used to diagnose the business alarm to determine the cause of the business alarm. If the alarm diagnosis mechanism is not configured, the alarm is directly executed according to the default alarm policy.

[0056] In some optional implementations, determining the cause of the service alarm using the cause analysis data includes the following steps B1-B6:

[0057] Step B1: extracting indicator changes corresponding to preset indicators from the cause analysis data.

[0058] In some optional implementations, the indicator change corresponding to the preset indicator may be a sudden drop in bandwidth, a sudden increase in bandwidth, a sudden increase in status code, a sudden drop in status code, and the like.

[0059] Step B2: Obtain an alarm analysis strategy corresponding to the target domain name. The alarm analysis strategy includes multiple alarm types and multiple determination conditions associated with the alarm types. Each preset indicator corresponds to at least one determination condition.

[0060] In some optional implementations, each target domain name corresponds to an alarm analysis strategy, the alarm analysis strategy includes multiple alarm types and judgment conditions associated with each alarm type, and the alarm types include: normal alarm type, CDN type, and source station type.

[0061] Specifically, the judgment conditions corresponding to normal alarm types are as follows:

[0062] ① Bandwidth changes: The bandwidth and request counts suddenly drop, but there is no sudden increase in 4XX or 5XX status codes, and the external dial test request results are normal.

[0063] ② Changes in 4XX status codes: A sudden increase in status codes. The source of the status codes is the origin server or triggers the CDN authentication logic, and the client IP, UA, or referer is concentrated.

[0064] The criteria for determining the CDN type are as follows:

[0065] ①Bandwidth change: One of the following two conditions will suffice:

[0066] 1. The bandwidth suddenly drops, the number of requests is normal, and abnormal status codes such as 4XX and 5XX suddenly increase. The abnormal status codes come from non-origin sites.

[0067] 2. A sudden drop in bandwidth and request counts caused external detection failure. External detection failure can be understood as a failure to simulate client access requests.

[0068] ② Changes in 5XX status codes: A sudden increase in abnormal status codes may be caused by a non-origin server, non-CDN logic triggering, machine performance indicator overload, or node packet loss.

[0069] ③ Changes in 4XX status codes: A sudden increase in abnormal status codes, the source is not the origin server, the CDN logic is not triggered, and user indicators such as client IP, referer, and UA are not concentrated.

[0070] The criteria for determining the source station type are as follows:

[0071] ① Bandwidth changes: The bandwidth suddenly drops, the number of requests is normal, and the abnormal status code suddenly increases. The source of the abnormal status code is the origin station.

[0072] ②Changes in 4XX status codes: The status code increases suddenly, and the status code is abnormal. The source of the abnormal status code is the origin station.

[0073] ③Changes in 5XX status codes: Abnormal status codes increase suddenly, and the source of abnormal status codes is the origin station.

[0074] Step B3: Match the indicator change corresponding to the preset indicator with the corresponding judgment condition.

[0075] In some optional implementations, the indicator change conditions corresponding to each preset indicator in the current cause analysis data are matched with the judgment conditions corresponding to each alarm type, thereby determining the judgment conditions hit by the indicator change conditions.

[0076] Step B4: If the indicator change corresponding to the preset indicator meets the corresponding judgment condition, the met judgment condition is determined as the target judgment condition.

[0077] In some optional implementations, if the indicator change corresponding to the preset indicator meets the corresponding judgment condition, the met judgment condition is marked as the target judgment condition. Because different alarm types correspond to the same judgment condition, for example, the bandwidth change of CDN type and origin type is a sudden bandwidth drop, marking the judgment condition that the indicator change meets facilitates the subsequent determination of the final alarm type.

[0078] Step B5: Obtain the target alarm type corresponding to the target determination condition from the alarm analysis strategy, and obtain the abnormal problem that generates the target alarm type.

[0079] In some optional implementations, target determination conditions corresponding to various preset indicators are obtained, and then the alarm type corresponding to the target determination conditions is determined as the target alarm type. The abnormality corresponding to the target alarm type is also obtained. For example, when the target alarm type is a CDN type, the corresponding abnormality includes: the top 3 abnormal IP addresses, the abnormal Uniform Resource Locator (URL), and the cause of the abnormality (e.g., node packet loss, CPU overload, etc.).

[0080] Step B6: Generate a business alarm reason based on the target alarm type and the abnormal problem.

[0081] The method provided by the disclosed embodiments allows for flexible configuration and adjustment based on specific business needs, adapting to different business scenarios, by setting corresponding judgment conditions based on preset indicators in the alarm analysis strategy. Secondly, by matching the changes in the preset indicators with the judgment conditions, the target judgment conditions can be determined, and the corresponding target alarm type and abnormal problem can be obtained from the alarm analysis strategy, thereby generating a precise business alarm cause.

[0082] In some optional embodiments, after obtaining the target alarm type corresponding to the target judgment condition from the alarm analysis strategy, the method also includes: detecting whether the target alarm type belongs to a normal alarm type; if the target alarm type belongs to a normal alarm type, querying historical alarm records; obtaining the number of alarms of the normal alarm type corresponding to the target domain name from the historical alarm records; if the number of alarms is greater than or equal to the preset number, updating the target domain name to the domain name blocking list.

[0083] By querying historical alarm records, the disclosed embodiments can obtain the number of normal alarm type alarms corresponding to the target domain name, thereby making a more accurate judgment on the alarm type. If the number of normal alarm type alarms is greater than or equal to a preset number, it can be said that the target domain name has repeatedly triggered normal alarms. To reduce the domain name's resource usage on the alarm processing terminal and avoid invalid alarms, the target domain name is updated to the domain name blocking list, thereby reducing false alarms and improving alarm accuracy. At the same time, blocking alarms for this domain name can also prevent the alarms from interfering with normal business operations.

[0084] Step S14: Obtain a sending policy corresponding to the service alarm reason, and send the service alarm reason according to the sending policy.

[0085] In some optional implementations, obtaining a sending policy corresponding to a service alarm cause and sending the service alarm cause according to the sending policy includes: detecting whether a target alarm type carried in the service alarm cause is an abnormal alarm type, where abnormal alarm types include CDN type and origin server type. If the target alarm type is an abnormal alarm type, determining a target receiving device corresponding to the target alarm type based on a mapping relationship between abnormal alarm types and receiving devices, and sending the service alarm cause to the target receiving device.

[0086] For example, the mapping relationship between abnormal alarm types and receiving devices can be as follows: As shown in Figure 3, the alarm type is CDN type, the service alarm cause is X1, and the receiving device is Y1. The alarm type is CDN type, the service alarm cause is X2, and the receiving device is Y2. The alarm type is source station type, the service alarm cause is M1, and the receiving device is N1. The alarm type is CDN type, the service alarm cause is M2, and the receiving device is N2.

[0087] The disclosed embodiments automatically determine the target recipient device by detecting the alarm type and mapping relationship, eliminating the need for manual intervention and reducing the time and errors associated with manual operations. Furthermore, based on the alarm type and mapping relationship, the target recipient device is precisely determined, ensuring that alarm information is promptly delivered to the correct device, thereby improving the accuracy of alarm processing. Furthermore, by automatically determining the target recipient device and sending the alarm, alarm information can be quickly communicated to the corresponding device, enabling rapid response and processing, and improving the efficiency of troubleshooting and repair.

[0088] The disclosed embodiments utilize detection data to monitor service status in real time, enabling rapid determination of whether service alerts are necessary. Cause analysis data can accurately identify the cause of service alerts, facilitating rapid problem location and improving troubleshooting efficiency. Even when faced with a massive volume of service alerts, the true cause of the alert can be accurately identified, avoiding false positives and missed alerts, and improving the processing rate and accuracy of service alerts. Furthermore, the delivery of service alert causes according to the delivery strategy helps ensure the stability of service operations.

[0089] In some optional implementations, the method further includes: if the service alarm reason does not carry the alarm type and the alarm reason, obtaining a preset receiver device; and sending an alarm prompt message to the preset receiver device.

[0090] In the embodiment of the present disclosure, if the business alarm reason does not carry the alarm type and alarm reason, it means that the business alarm reason analysis has timed out. At this time, the alarm information is sent to the preset receiving device according to the default configuration, thereby ensuring that the operation and maintenance personnel can handle it quickly.

[0091] This embodiment also provides a CDN-based service alarm processing device, which is used to implement the above-mentioned embodiments and preferred implementations. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0092] This embodiment provides a CDN-based service alarm processing device, as shown in FIG4 , including:

[0093] An acquisition module 41 is configured to acquire detection data and cause analysis data corresponding to a target domain name. The detection data is obtained by detecting access behavior of a client corresponding to a CDN node to the target domain name. The cause analysis data is obtained based on the access behavior and node performance data of the CDN node.

[0094] A determination module 42 is configured to determine whether to execute a service alarm corresponding to a target domain name using the detection data;

[0095] The analysis module 43 is configured to determine the cause of the service alarm by using the cause analysis data if it is determined that the service alarm corresponding to the target domain name is executed;

[0096] The sending module 44 is configured to obtain a target receiving device corresponding to the service alarm reason and send the service alarm reason to the target receiving device.

[0097] In some optional implementations, a determination module 42 is used to query a domain name blocking list; if the target domain name does not belong to the domain name blocking list, access behavior data corresponding to each preset indicator is extracted from the detection data; an alarm detection strategy corresponding to the target domain name is obtained, and the alarm detection strategy includes alarm conditions corresponding to each preset indicator; the access behavior data corresponding to the preset indicator is matched with the alarm conditions to determine whether to execute the business alarm corresponding to the target domain name.

[0098] In some optional implementations, the determination module 42 is used to determine whether to execute the business alarm corresponding to the target domain name if the access behavior data corresponding to the preset indicator hits the alarm condition; or, if the access behavior data corresponding to the preset indicator does not hit the alarm condition, determine not to execute the business alarm corresponding to the target domain name.

[0099] In some optional implementations, the analysis module 43 is used to extract the indicator changes corresponding to the preset indicators from the cause analysis data; obtain the alarm analysis strategy corresponding to the target domain name, the alarm analysis strategy includes multiple alarm types and multiple judgment conditions associated with the alarm types, and each preset indicator corresponds to at least one judgment condition; match the indicator changes corresponding to the preset indicators with the corresponding judgment conditions; if the indicator changes corresponding to the preset indicators hit the corresponding judgment conditions, the hit judgment conditions are determined as the target judgment conditions; obtain the target alarm type corresponding to the target judgment condition from the alarm analysis strategy, and obtain the abnormal problem that generates the target alarm type; generate the business alarm cause based on the target alarm type and the abnormal problem.

[0100] In some optional implementations, the processing of business alarms also includes: an update module for detecting whether the target alarm type belongs to a normal alarm type; if the target alarm type belongs to a normal alarm type, querying historical alarm records; obtaining the number of alarms of the normal alarm type corresponding to the target domain name from the historical alarm records; if the number of alarms is greater than or equal to the preset number, updating the target domain name to the domain name blocking list.

[0101] In some optional implementations, the sending module 44 is used to detect whether the target alarm type carried by the business alarm reason belongs to the abnormal alarm type, and the abnormal alarm type includes the CDN type and the source station type; if the target alarm type belongs to the abnormal alarm type, then based on the mapping relationship between the abnormal alarm type and the receiving device, the target receiving device corresponding to the target alarm type is determined; and the business alarm reason is sent to the target receiving device.

[0102] In some optional implementations, the apparatus further includes: a prompt module configured to obtain a preset recipient device if the service alarm reason does not carry the alarm type and the alarm reason; and send an alarm prompt message to the preset recipient device.

[0103] Please refer to Figure 5, which is a structural diagram of a computer device provided by an optional embodiment of the present disclosure. As shown in Figure 5, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed in the computer device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system).

[0104] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

[0105] The memory 20 stores instructions that can be executed by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0106] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created based on the use of a computer device for displaying a small program landing page, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0107] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0108] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0109] The embodiments of the present disclosure also provide a computer-readable storage medium. The above-mentioned method according to the embodiments of the present disclosure can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0110] Although the embodiments of the present disclosure have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A CDN-based service alarm processing method, wherein: The method comprises: Acquire detection data and cause analysis data corresponding to the target domain name, wherein the detection data is obtained by detecting access behavior of the client corresponding to the CDN node to the target domain name, and the cause analysis data is obtained based on the access behavior and node performance data of the CDN node; Determining whether to execute a service alarm corresponding to the target domain name using the detection data; If it is determined to execute the service alarm corresponding to the target domain name, the cause of the service alarm is determined using the cause analysis data; Acquire a sending strategy corresponding to the service alarm reason, and send the service alarm reason according to the sending strategy.

2. The method according to claim 1, wherein: The using the detection data to determine whether to execute the service alarm corresponding to the target domain name includes: Query the domain name blocking list; If the target domain name does not belong to the domain name blocking list, extracting access behavior data corresponding to each preset indicator from the detection data; Obtaining an alarm detection strategy corresponding to the target domain name, wherein the alarm detection strategy includes alarm conditions corresponding to various preset indicators; The access behavior data corresponding to the preset indicator is matched with the alarm condition to determine whether to execute the service alarm corresponding to the target domain name.

3. The method according to claim 2, wherein: The matching of the access behavior data corresponding to the preset indicator with the alarm condition to determine whether to execute the service alarm corresponding to the target domain name includes: If the access behavior data corresponding to the preset indicator matches the alarm condition, it is determined to execute the service alarm corresponding to the target domain name; or, If the access behavior data corresponding to the preset indicator does not match the alarm condition, it is determined that the service alarm corresponding to the target domain name will not be executed.

4. The method according to claim 2, wherein: The using the cause analysis data to determine the cause of the service alarm includes: Extracting the indicator change situation corresponding to the preset indicator from the cause analysis data; Obtaining an alarm analysis strategy corresponding to the target domain name, wherein the alarm analysis strategy includes multiple alarm types and multiple determination conditions associated with the alarm types, and each preset indicator corresponds to at least one determination condition; Matching the indicator change corresponding to the preset indicator with the corresponding judgment condition; If the indicator change corresponding to the preset indicator hits the corresponding determination condition, the hit determination condition is determined as the target determination condition; Obtaining a target alarm type corresponding to the target determination condition from the alarm analysis strategy, and obtaining an abnormal problem that generates the target alarm type; The business alarm reason is generated based on the target alarm type and the abnormal problem.

5. The method according to claim 4, wherein: After obtaining the target alarm type corresponding to the target determination condition from the alarm analysis strategy, the method further includes: Detecting whether the target alarm type belongs to a normal alarm type; If the target alarm type belongs to a normal alarm type, query the historical alarm records; Acquire the alarm number of the normal alarm type corresponding to the target domain name from the historical alarm record; If the number of alarms is greater than or equal to a preset number, the target domain name is updated to the domain name blocking list.

6. The method according to claim 1, wherein: The acquiring a sending strategy corresponding to the service alarm reason, and sending the service alarm reason according to the sending strategy, includes: Detect whether the target alarm type carried by the service alarm reason belongs to an abnormal alarm type, and the abnormal alarm type includes a CDN type and an origin station type; If the target alarm type belongs to the abnormal alarm type, determining the target receiving device corresponding to the target alarm type based on the mapping relationship between the abnormal alarm type and the receiving device; Send the service alarm reason to the target receiving device.

7. The method according to claim 6, wherein: The method further comprises: If the service alarm reason does not carry the alarm type and the alarm reason, obtaining a preset receiver device; Send the warning information to the preset recipient device.

8. A CDN-based service alarm processing device, wherein: The device comprises: An acquisition module, used to acquire detection data and cause analysis data corresponding to a target domain name, wherein the detection data is obtained by detecting access behavior of a client corresponding to a CDN node to the target domain name, and the cause analysis data is obtained based on the access behavior and node performance data of the CDN node; A determination module, used to determine whether to execute a service alarm corresponding to the target domain name using the detection data; An analysis module, configured to determine the cause of the service alarm by using the cause analysis data if it is determined that the service alarm corresponding to the target domain name is to be executed; The sending module is used to obtain the target receiving device corresponding to the service alarm reason and send the service alarm reason to the target receiving device.

9. A computer device, wherein: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, wherein: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images