A DNS resolution monitoring method, device, electronic device and storage medium

Abstract

The present application relates to a DNS resolution monitoring method, device, electronic device and storage medium, wherein the DNS resolution monitoring method includes: obtaining a DNS request; performing resolution processing on the DNS request, and if the resolution fails, generating a first monitoring alarm result; if the first domain name and the first address corresponding to the DNS request are resolved, then judging whether the DNS request resolution is normal based on the first record time interval of the first domain name and the query results of the first domain name and the first address in the historical resolution record; if the DNS request resolution is judged to be abnormal, then generating a second monitoring alarm result. Through this application, the problem of difficulty in quickly and accurately monitoring and alarming when the DNS resolution of microservices is abnormal in the K8s environment is solved, and the abnormality detection function of the microservice operation process is realized, which can timely discover abnormal situations in the DNS resolution process and quickly locate the problem, thereby shortening the troubleshooting time and improving the troubleshooting efficiency.

Description

Technical Field

[0001] The present application relates to the field of cloud computing, and in particular to a DNS resolution monitoring method, device, electronic device and storage medium. Background Art

[0002] As cloud computing and containerization technologies are developing rapidly, Kubernetes (K8s for short) as an open source containerized application management platform has been widely used in various business scenarios. However, with the popularization of microservice architecture, the number of microservices in the K8s environment has exploded, bringing huge challenges to operation and maintenance management. In particular, the communication between microservices depends on DNS resolution (Domain Name System). Once the DNS resolution is abnormal, it will directly affect the normal operation of the service. Therefore, how to efficiently and accurately monitor the DNS resolution status of microservices in the K8s environment and promptly discover and solve potential problems has become the focus of operation and maintenance personnel.

[0003] In the prior art, for monitoring of DNS resolution of microservices, K8s uses CoreDNS as its DNS server by default. CoreDNS can be configured with monitoring indicators, and the DNS resolution of microservices can be understood through monitoring indicators. However, CoreDNS mainly focuses on the overall performance of the DNS server, and cannot go deep into the specific microservice level, that is, for the domain name resolution stored in the NoSQL database or cache of microservices, traditional monitoring methods often cannot cover it. At this time, when DNS resolution is abnormal, the operation and maintenance personnel can only locate the problem by viewing the CoreDNS log. The log contains detailed information about DNS resolution, including the requested domain name, IP address, resolution results, etc. This method requires the operation and maintenance personnel to manually view the log, which leads to a delay in alarm. In the K8s environment with a large number of microservices, manually viewing the log is not only time-consuming and laborious, but also easy to miss important information. Therefore, the existing monitoring solutions often cannot capture the anomalies of DNS resolution in real time, nor can they provide accurate alarm information (such as specific domain names and IP addresses), which leads to the lack of sufficient information support for operation and maintenance personnel when handling faults, making it difficult to quickly locate and solve the problem.

[0004] At present, there is no effective solution to the problem that it is difficult to quickly and accurately monitor and issue alarms when DNS resolution of microservices in the K8s environment is abnormal. Summary of the invention

[0005] The embodiments of the present application provide a DNS resolution monitoring method, device, system, electronic device and storage medium to at least solve the problem in the related art that it is difficult to quickly and accurately monitor and alarm when the microservice DNS resolution is abnormal in the K8s environment.

[0006] In a first aspect, an embodiment of the present application provides a DNS resolution monitoring method, comprising:

[0007] Get DNS request;

[0008] Performing resolution processing on the DNS request, and if the resolution fails, generating a first monitoring alarm result;

[0009] If the first domain name and the first address corresponding to the DNS request are resolved, judging whether the DNS request resolution is normal based on the time interval of the first domain name being first recorded and based on the query results of the first domain name and the first address in the historical resolution records;

[0010] If it is determined that the DNS request resolution is abnormal, a second monitoring alarm result is generated.

[0011] In some embodiments, the determining whether the DNS request resolution is normal based on the first recording time interval of the first domain name and the query result of the first domain name and the first address in the historical resolution record includes:

[0012] If the time interval between the first domain name and the first address being recorded for the first time is greater than a preset threshold, obtaining a query result of the first domain name and the first address in a historical resolution record, wherein the historical resolution record includes a historical domain name and a historical address;

[0013] If the first domain name and the first address exist in the historical resolution record, the DNS request resolution is normal; if not, the DNS request resolution is abnormal;

[0014] If the time interval for the first recording of the first domain name is less than or equal to the preset threshold, the first domain name and the first address are recorded in the historical resolution record.

[0015] In some embodiments, the method further comprises:

[0016] Get HTTP request;

[0017] If the HTTP request is successfully parsed, obtaining a second domain name and a second address corresponding to the HTTP request;

[0018] Based on the time interval of the first recording of the second domain name and based on the query result of the second domain name and the second address in the historical resolution record, determining whether the HTTP request resolution is normal;

[0019] If the HTTP request is parsed abnormally, a third monitoring alarm result is generated, and the third monitoring alarm result includes the second domain name and the second address corresponding to the HTTP request parsing abnormally.

[0020] In some embodiments, obtaining a DNS request includes:

[0021] Deploy eBPF programs;

[0022] Run the eBPF program, and obtain the DNS request and HTTP request based on a preset tracing function.

[0023] In some embodiments, deploying the eBPF program includes:

[0024] Defining a DNS output event and an HTTP output event in the eBPF program;

[0025] When the DNS request data packet is obtained, the DNS output event is used to record DNS request information, where the DNS request information includes the first domain name, the first address, and the DNS request response time;

[0026] When the HTTP request data packet is acquired, the HTTP output event is used to record HTTP request information, where the HTTP request information includes the second domain name, the second address and HTTP request response time.

[0027] In some embodiments, obtaining the historical parsing record includes:

[0028] A historical domain name and a historical address resolved from a historical request are obtained, the historical resolution record is determined based on the historical domain name and the historical address, and the historical resolution record is stored in a preset storage system.

[0029] In some embodiments, the first monitoring alarm result includes the third domain name corresponding to the resolution failure, and the second monitoring alarm result includes the first domain name and the first address corresponding to the abnormal DNS request resolution.

[0030] In a second aspect, an embodiment of the present application provides a DNS resolution monitoring device, including:

[0031] Data acquisition module, used to obtain DNS requests;

[0032] A DNS resolution module, used to resolve the DNS request, and if the resolution fails, generate a first monitoring alarm result;

[0033] a resolution anomaly verification module, configured to determine whether the DNS request resolution is normal based on a time interval for the first recording of the first domain name and a query result of the first domain name and the first address in a historical resolution record if a first domain name and a first address corresponding to the DNS request are resolved;

[0034] The resolution anomaly verification module is also used to generate a second monitoring alarm result if it is determined that the DNS request resolution is abnormal.

[0035] In a third aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the DNS resolution monitoring method as described in the first aspect above is implemented.

[0036] In a fourth aspect, an embodiment of the present application provides a storage medium on which a computer program is stored, and when the program is executed by a processor, the DNS resolution monitoring method described in the first aspect above is implemented.

[0037] Compared with the related technology, the DNS resolution monitoring method provided in the embodiment of the present application efficiently obtains resolution records through eBPF technology, and makes a secondary judgment on whether the resolution is abnormal. It solves the problem that it is difficult to quickly and accurately monitor and alarm when the DNS resolution of microservices is abnormal in the K8s environment, and realizes the abnormality detection function of the microservice operation process. It can promptly discover abnormal situations in the DNS resolution process and quickly locate the problem, thereby shortening the troubleshooting time and improving the troubleshooting efficiency.

[0038] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0040] Figure 1 It is a hardware structure block diagram of a terminal of the DNS resolution monitoring method according to an embodiment of the present invention;

[0041] Figure 2 is a flowchart of a DNS resolution monitoring method according to an embodiment of the present application;

[0042] Figure 3 is a flowchart of a DNS resolution monitoring method according to a preferred embodiment of the present application;

[0043] Figure 4 It is a structural block diagram of a DNS resolution monitoring device according to an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application. In addition, it can also be understood that although the efforts made in this development process may be complex and lengthy, for ordinary technicians in the field related to the contents disclosed in the present application, some changes such as design, manufacturing or production based on the technical contents disclosed in the present application are only conventional technical means, and should not be understood as insufficient contents disclosed in the present application.

[0045] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0046] Unless otherwise defined, the technical terms or scientific terms involved in this application should be understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "a", "a", "the" and the like involved in this application do not indicate a quantity limitation, and may indicate the singular or plural. The terms "include", "comprise", "have" and any of their variations involved in this application are intended to cover non-exclusive inclusions; for example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units that are not listed, or may also include other steps or units inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application means greater than or equal to two. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, "A and / or B" can mean: A exists alone, A and B exist at the same time, and B exists alone. The terms "first", "second", "third" and the like involved in the present application are merely used to distinguish similar objects and do not represent a specific ordering of the objects.

[0047] The method embodiment provided in this embodiment can be executed in a terminal, a computer or a similar computing device. Taking running on a terminal as an example, Figure 1 1 is a hardware structure diagram of a terminal of the DNS resolution monitoring method according to an embodiment of the present invention. Figure 1 As shown, the terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Optionally, the terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is for illustration only and does not limit the structure of the above terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0048] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the DNS resolution monitoring method in the embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the terminal 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 combinations thereof.

[0049] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet wirelessly.

[0050] This embodiment provides a DNS resolution monitoring method. Figure 2 is a flowchart of a DNS resolution monitoring method according to an embodiment of the present application. Figure 2 As shown, the process includes the following steps:

[0051] Step S201, obtaining a DNS request;

[0052] Among them, the eBPF program is responsible for monitoring network activities. By listening to specific system calls or events in the network protocol stack, the eBPF program captures DNS request packets in the kernel space. Specifically, the trace_udp_sendmsg function can be used to capture the DNS request packets of the UDP protocol. After the eBPF program is compiled into BPF bytecode, it runs in the kernel. When a DNS request is detected, the corresponding eBPF program is triggered to obtain the DNS request packet. The captured DNS request packet is then submitted to the user space for further processing. The DNS request packet includes the DNS request. This step can capture the DNS requests of microservices in the K8s cluster in real time and efficiently, providing basic data for subsequent analysis and processing.

[0053] Step S202: parse the DNS request, and if the parsing fails, generate a first monitoring alarm result.

[0054] Among them, in the user space, the captured DNS request data packet is parsed and processed, that is, the domain name, query type, IP address and other information in the request are extracted. If it is found during the resolution process that the DNS request cannot be successfully resolved, for example, the corresponding IP address cannot be found, the DNS server is unresponsive, etc., it is regarded as a DNS resolution failure. At this time, according to the preset alarm rules, the first monitoring alarm result is generated, and the result is communicated to the operation and maintenance personnel. The first monitoring alarm result includes the cause of the relevant error, as well as the corresponding domain name, address, etc., so that the operation and maintenance personnel can perform maintenance. This step can detect errors in the DNS resolution process in a timely manner and generate alarms by directly detecting the DNS resolution failure, thereby improving the reliability and stability of the system. In addition, the alarm result contains detailed error information, which helps the operation and maintenance personnel to quickly locate the problem and repair it.

[0055] Step S203: If the first domain name and the first address corresponding to the DNS request are resolved, whether the DNS request resolution is normal is determined based on the first record time interval of the first domain name and the query results of the first domain name and the first address in the historical resolution record.

[0056] Among them, when the DNS request is successfully resolved to the first domain name and the first address corresponding to the DNS request, the eBPF program will record the first resolution time of the domain name. The first record time interval is the interval between the current time and the time when the first domain name is first recorded. At the same time, the eBPF program will also query the historical resolution records stored in etcd (or similar distributed key-value storage) to check whether the current domain name and address exist in the historical records. The historical resolution record refers to all previously successfully resolved domain names and corresponding IP addresses, as well as resolution time and other information recorded and saved during the DNS resolution process. Based on the time interval and the query results of the historical resolution record, the eBPF program will determine whether the DNS request resolution is normal. For example, if the domain name appears for the first time within 24 hours and does not exist in the historical record, or the domain name exists but the resolved address does not match the historical record, it may be considered that the DNS request resolution is abnormal. This step can more accurately determine whether the DNS request resolution is normal by comparing the first record time interval of the domain name and the historical resolution record, reduce false positives and false negatives, and provide detailed resolution history records for operation and maintenance personnel, which is helpful for more in-depth problem analysis and troubleshooting.

[0057] Step S204: If it is determined that the DNS request resolution is abnormal, a second monitoring alarm result is generated.

[0058] Among them, when the eBPF program determines that the DNS request resolution is abnormal, it will generate a monitoring alarm result containing abnormal information. The second monitoring alarm result includes the involved DNS request information (domain name, IP address, request type, etc.), abnormal resolution time, etc. This step can promptly detect DNS resolution anomalies and generate alarms to remind operation and maintenance personnel to pay attention to and deal with related problems. The alarm result contains detailed abnormal information, which helps operation and maintenance personnel to quickly locate problems and repair them, thereby improving the availability and stability of the system.

[0059] Through the above steps, a component capable of capturing DNS request packets is deployed in the K8s cluster using eBPF technology to monitor these DNS requests. By compiling BPF bytecode and running it in the kernel, the DNS request data packet is captured and parsed. The goal of the parsing process is to extract the domain name in the DNS request and the expected IP address to be parsed, so as to achieve efficient acquisition of DNS resolution records, thereby realizing accurate monitoring of the DNS resolution of microservices. If it is found during the parsing process that the domain name cannot be parsed into a valid IP address (i.e., parsing failure), it means that there may be a DNS resolution anomaly. At this time, the first monitoring alarm result is generated to notify the operation and maintenance personnel that the DNS resolution failure has occurred. If the DNS request successfully parses the domain name and the corresponding IP address (i.e., the first domain name and the first address), the next step of judgment is entered. After obtaining the first record time interval of the first domain name, it is necessary to query the historical resolution record based on the first domain name and the first address. The historical resolution record can be stored in a distributed key-value storage system such as etcd. According to the first record time interval and the historical resolution record, it is confirmed whether the resolution is abnormal. If the first record time interval exceeds the preset threshold (such as 24 hours), and the corresponding resolution record cannot be queried in the historical record at the current time point, it is determined that the DNS request resolution is abnormal, and the second alarm result is generated at the same time, which helps the operation and maintenance personnel to quickly understand the specific situation of the DNS resolution anomaly and perform targeted troubleshooting operations.

[0060] By storing the acquired DNS data in the distributed key-value storage etcd and reconfirming whether the resolution is normal based on historical resolution records, it is possible to more accurately determine whether there is an abnormality in DNS resolution. Operation and maintenance personnel can quickly locate the problem based on the detailed abnormal resolution information provided in the alarm information, thereby shortening the troubleshooting time and improving the troubleshooting efficiency. This solves the problem of difficulty in quickly and accurately monitoring alarms when microservice DNS resolution is abnormal in the K8s environment.

[0061] In some embodiments, judging whether the DNS request resolution is normal based on the time interval of the first recording of the first domain name and the query result of the first domain name and the first address in the historical resolution record includes:

[0062] If the time interval between the first recording of the first domain name is greater than a preset threshold, obtaining a query result of the first domain name and the first address in a historical resolution record, where the historical resolution record includes a historical domain name and a historical address;

[0063] If the first domain name and the first address exist in the historical resolution record, the DNS request resolution is normal; if not, the DNS request resolution is abnormal;

[0064] If the time interval for the first recording of the first domain name is less than or equal to the preset threshold, the first domain name and the first address are recorded in the historical resolution record.

[0065] The system records the time when each domain name is resolved each time. When a new DNS request is successfully resolved, the resolved domain name (first domain name) and the corresponding IP address (first address) are extracted, and the interval between the current time and the first record time of the first domain name, that is, the first record time interval, is calculated. If the first record time interval is greater than the preset threshold (such as 24 hours), etcd (or similar distributed key-value storage) is queried to see whether there is a historical resolution record matching the first domain name and the first address to determine whether the resolution is abnormal. If a historical record matching the first domain name and the first address is found in the historical resolution record, the DNS request resolution is judged to be normal; if no matching historical record is found in the historical resolution record, the DNS request resolution is judged to be abnormal, and the corresponding monitoring alarm result is generated. If the first record time interval of the first domain name is less than or equal to the preset threshold, it is considered to be a new or recent DNS resolution request. In this case, the record of the first domain name and the first address is added to the etcd storage for similar queries and judgments in the future. Specifically, the paths stored in etcd are / DNS / servie / ip / id and / DNS / servie / time / id. The storage path examples are as follows:

[0066] / dns / service1 / ip / 0 ->192.168.1.1

[0067] / dns / service1 / time / 0 ->2024-07-22T12:34:56Z

[0068] / dns / service1 / ip / 1 ->192.168.1.2

[0069] / dns / service1 / time / 1 ->2024-07-22T12:34:57Z

[0070] Among them, service1 is the domain name; ip is the IP address; 0 is the id number; time is the resolution time.

[0071] This embodiment combines the query results of the first record time interval and the historical resolution record to more accurately determine whether the DNS request resolution is normal, thereby improving the stability and reliability of the overall system; when the DNS request resolution is abnormal, the system can provide detailed abnormal information, including domain name, IP address, first record time interval, historical resolution record, etc., which helps operation and maintenance personnel to quickly locate the problem and perform targeted troubleshooting operations; by recording and maintaining historical resolution records, repeated query and processing of frequently resolved domain names can be avoided, reducing the processing burden of the system and improving the performance and response speed of the overall system.

[0072] In some embodiments, the method further comprises:

[0073] Get HTTP request;

[0074] When the HTTP request is successfully parsed, obtain the second domain name and the second address corresponding to the HTTP request;

[0075] Based on the time interval of the first recording of the second domain name and the query result of the second domain name and the second address in the historical resolution record, determining whether the HTTP request resolution is normal;

[0076] If the HTTP request parsing is abnormal, a third monitoring alarm result is generated, and the third monitoring alarm result includes the second domain name and the second address corresponding to the HTTP request parsing abnormality.

[0077] In the same way as capturing DNS request packets, HTTP request packets are captured in kernel space through eBPF programs. Specifically, the trace_tcp_sendmsg function can be used to capture HTTP request packets of the TCP protocol. Parse the HTTP request packet and extract the key information in the request, including the requested domain name (second domain name) and the requested server IP address (second address). After each HTTP request is successfully resolved, the corresponding second domain name and second address are recorded and saved in etcd, and the resolution time of each time is recorded. Specifically, the storage path example is as follows:

[0078] / https / service2 / ip / 0 ->192.168.2.1

[0079] / https / service2 / time / 0 ->2024-07-22T12:35:00Z

[0080] Among them, service2 is the domain name; ip is the IP address; 0 is the id number; time is the resolution time.

[0081] The judgment is made based on the time interval of the first record of the second domain name. If the time interval of the first record is greater than the preset threshold (such as 24 hours), the historical resolution record is queried to see whether there is a historical record matching the second domain name and the second address. If a matching historical record is found, the HTTP request resolution is judged to be normal; if a matching historical record is not found, the HTTP request resolution is judged to be abnormal, and the third monitoring alarm result is generated for the abnormal resolution. The third monitoring alarm result includes the second domain name and the second address corresponding to the HTTP request resolution abnormality, as well as the error code and resolution time of the failed resolution. This step expands the monitoring scope of request anomalies, so that not only can the DNS request resolution of the microservice be detected, but also the HTTP request resolution of the microservice can be detected. It realizes comprehensive monitoring of request resolution anomalies in microservices in the K8s environment and improves the performance of the overall system.

[0082] In some embodiments, obtaining a DNS request includes:

[0083] Deploy eBPF programs;

[0084] Run the eBPF program to obtain DNS requests and HTTP requests based on the preset tracing function.

[0085] The eBPF program is deployed in the K8s cluster in the form of DaemonSet to ensure that a copy of the eBPF program is running on each node, thereby achieving comprehensive monitoring of the entire cluster. The Go language library includes the github.com / iovisor / gobpf package, which is specifically used to interact with eBPF. These packages can provide a rich set of APIs that enable loading, compiling, and running eBPF programs in the Go language environment. The github.com / iovisor / gobpf package also supports reading and writing the memory space required for eBPF programs, as well as data transmission with user space.

[0086] For example, during the deployment process, the Go language API provided by the gobpf library is used to load and run eBPF programs. These APIs include functions such as compiling eBPF bytecode, loading eBPF programs into kernel space, and interacting with user space. In order to monitor low-level operations such as network requests, it is necessary to load and run eBPF programs into the kernel. BPF bytecode is the machine code representation of eBPF programs and is used for execution in the kernel. Therefore, the clang / llvm compiler is needed to compile the eBPF source code into BPF bytecode. The compiled BPF bytecode needs to be loaded into the kernel so that the eBPF program can be executed and various events can be captured and processed in kernel space. eBPF programs usually also need to interact with user space to obtain data or send notifications. This can be achieved through the Map mechanism or other mechanisms introduced by eBPF. The bpf program puts the data obtained by kernel tracing into the Map space. Since the Map space is shared by user space and kernel space, programs in user space can obtain kernel tracing data from the map, so that the kernel can interact with user space. When deploying the eBPF program, you also need to define two macros BPF_PERF_OUTPUT(DNS_events) and BPF_PERF_OUTPUT(http_events).

[0087] When the eBPF program is running, it will capture DNS request and HTTP request packets based on the preset tracing function. For DNS requests, the eBPF program uses the trace_udp_sendmsg function to capture DNS request packets under the UDP protocol, and uses the BPF_PERF_OUTPUT(DNS_events) macro to submit the data to the user space for subsequent processing; for HTTP requests, the trace_tcp_sendmsg function is used to capture HTTP request packets under the TCP protocol, and the BPF_PERF_OUTPUT(http_events) macro is used to submit the data to the user space.

[0088] This embodiment can realize real-time capture and processing of DNS requests and HTTP requests by running the eBPF program at the kernel level, avoiding the delay and underreporting problems that may exist in traditional monitoring methods, and improving the real-time and accuracy of monitoring; since the eBPF program runs directly at the kernel level, no additional hardware or software resources are required to support the monitoring function, which also reduces the monitoring cost and improves the operation and maintenance efficiency; at the same time, since the eBPF program is highly scalable and flexible, the monitoring requirements of different protocols or applications can be easily realized by modifying or extending the logic of the eBPF program, which enables the technical solution to adapt to changing application scenarios and requirements.

[0089] In some embodiments, deploying an eBPF program includes:

[0090] Define DNS output events and HTTP output events in the eBPF program;

[0091] When a DNS request data packet is obtained, the DNS output event is used to record DNS request information, where the DNS request information includes the first domain name, the first address, and the DNS request response time;

[0092] When the HTTP request data packet is obtained, the HTTP output event is used to record the HTTP request information, where the HTTP request information includes the second domain name, the second address, and the HTTP request response time.

[0093] Among them, in the process of writing eBPF programs, the BPF_PERF_OUTPUT macro is used to define DNS output events DNS_events (such as BPF_PERF_OUTPUT) and HTTP output events http_events (such as BPF_PERF_OUTPUT). These two events are used to process DNS request packets and HTTP request packets respectively, and transmit relevant information from kernel space to user space. When the eBPF program captures a DNS request packet, the DNS request information is recorded through the DNS output event. The DNS request information includes the first domain name (i.e., the requested domain name), the first address (i.e., the IP address obtained by domain name resolution), and the DNS request response time (i.e., the time from the request to the response); similarly, when the eBPF program captures an HTTP request packet, the HTTP request information is recorded through the HTTP output event. The HTTP request information includes the second domain name (i.e., the domain name specified in the HTTP request), the second address (i.e., the IP address associated with the domain name), and the HTTP request response time (i.e., the time from the request to the server response).

[0094] This embodiment defines DNS output events and HTTP output events in the eBPF program, and records DNS request information and HTTP request information respectively, so as to achieve detailed monitoring of DNS and HTTP requests, which helps operation and maintenance personnel to understand the status of network requests more accurately; the detailed DNS and HTTP request information provides strong support for troubleshooting. When there is a problem with the network request, the operation and maintenance personnel can quickly locate the problem based on this information, monitor the status of the network request in real time, and promptly discover and handle potential or existing problems. This information can also be used for performance optimization, helping operation and maintenance personnel to find the bottleneck of network requests and take targeted optimization measures, thereby improving the stability and reliability of the system.

[0095] In some embodiments, obtaining historical parsing records includes:

[0096] The historical domain name and historical address resolved by the historical request are obtained, the historical resolution record is determined based on the historical domain name and historical address, and the historical resolution record is stored in a preset storage system.

[0097] Each time a DNS request is resolved, the eBPF program records the resolved IP address and forms a resolution record together with the requested domain name. New resolution records can be distinguished from existing historical records by determining whether the domain name and IP of the current record have been recorded at a previous point in time. This can be achieved by comparing the timestamp and specific content of the current record with those of the existing records in the storage system. If the domain name and IP of the current record match a record in the storage system, and the time interval is within the set threshold (such as 24 hours), it is considered a historical resolution record. For new or updated resolution records, the system will store them in a preset storage system (such as etcd, or similar distributed key-value storage), recording key information such as domain name, IP address, and resolution time during storage.

[0098] This embodiment records and stores historical resolution records, so it can more accurately determine whether the current DNS resolution is abnormal. When a new DNS resolution request appears, the system can quickly compare it with the historical records, so that it can trigger alarms more intelligently, making the alarm mechanism more accurate and timely, which helps to improve operation and maintenance efficiency. By storing historical resolution records, it can better cope with abnormal situations such as network fluctuations and DNS server failures. When these abnormalities occur, troubleshooting and recovery operations can be performed based on historical records, so as to ensure the continuity and stability of the service.

[0099] In some embodiments, the first monitoring alarm result includes a third domain name corresponding to the resolution failure, and the second monitoring alarm result includes a first domain name and a first address corresponding to the DNS request resolution exception.

[0100] The embodiments of the present application are described and illustrated below through preferred embodiments. Figure 3 is a flowchart of a DNS resolution monitoring method according to a preferred embodiment of the present application. Figure 3 As shown, the DNS resolution monitoring method includes the following steps:

[0101] Step S301, the eBPF program is deployed in the K8s cluster in the form of daemonset. When the microservice DNS resolution exception is monitored, an alarm is triggered. The github.com / iovisor / gobpf package is used to load and run the eBPF program. The eBPF program defines two macros BPF_PERF_OUTPUT (DNS_events) and BPF_PERF_OUTPUT (http_events).

[0102] Step S302, entering the kernel space, the eBPF program compiles the BPF bytecode through the compiler clang / llvm, so that the eBPF program runs in the kernel.

[0103] Step S303, capture the DNS request data packet through the trace_udp_sendmsg function, and submit the data to the user space through DNS_events; capture the HTTP request data packet through the trace_tcp_sendmsg function, and submit the data to the user space through http_events.

[0104] Step S304: if a DNS resolution failure is detected, a monitoring alarm is directly initiated.

[0105] Step S305, obtain the DNS request. For the domain name corresponding to this DNS request, if the interval between the current time and the first record time of this domain name is less than 24 hours, and the record of this domain name and IP does not exist, it will be stored in etcd.

[0106] Step S306: If the interval between the current time and the first recorded time of this domain name is greater than 24 hours, query whether it exists in etcd. If it does, the resolution is normal. If the resolution record does not exist, the resolution is abnormal and a monitoring alarm is initiated.

[0107] This embodiment also provides a DNS resolution monitoring device, which is used to implement the above-mentioned embodiments and preferred implementation modes, and will not be repeated here. As used below, the terms "module", "unit", "subunit", etc. can implement a combination of software and / or hardware for a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0108] Figure 4 is a structural block diagram of a DNS resolution monitoring device according to an embodiment of the present application, such as Figure 4 As shown, the device comprises:

[0109] A data acquisition module 10 is used to acquire a DNS request;

[0110] The DNS resolution module 20 is used to resolve the DNS request and generate a first monitoring alarm result if the resolution fails;

[0111] The resolution abnormality verification module 30 is used to determine whether the DNS request resolution is normal based on the first record time interval of the first domain name and the query result of the first domain name and the first address in the historical resolution record if the first domain name and the first address corresponding to the DNS request are resolved;

[0112] The resolution anomaly verification module 30 is further configured to generate a second monitoring alarm result if it is determined that the DNS request resolution is abnormal.

[0113] The above-mentioned resolution anomaly verification module 30 is also used to obtain the query result of the first domain name and the first address in the historical resolution record if the time interval of the first record of the first domain name is greater than a preset threshold, and the historical resolution record includes the historical domain name and the historical address;

[0114] If the first domain name and the first address exist in the historical resolution record, the DNS request resolution is normal; if not, the DNS request resolution is abnormal;

[0115] If the time interval for the first recording of the first domain name is less than or equal to the preset threshold, the first domain name and the first address are recorded in the historical resolution record.

[0116] The above parsing exception verification module 30 is also used to obtain HTTP requests;

[0117] When the HTTP request is successfully parsed, obtain the second domain name and the second address corresponding to the HTTP request;

[0118] Based on the time interval of the first recording of the second domain name and the query result of the second domain name and the second address in the historical resolution record, determining whether the HTTP request resolution is normal;

[0119] If the HTTP request parsing is abnormal, a third monitoring alarm result is generated, and the third monitoring alarm result includes the second domain name and the second address corresponding to the HTTP request parsing abnormality.

[0120] The above-mentioned data acquisition module 10 is also used to deploy eBPF programs;

[0121] Run the eBPF program to obtain DNS requests and HTTP requests based on the preset tracing function.

[0122] The above-mentioned data acquisition module 10 is also used to define DNS output events and HTTP output events in the eBPF program;

[0123] When a DNS request data packet is obtained, the DNS output event is used to record DNS request information, where the DNS request information includes the first domain name, the first address, and the DNS request response time;

[0124] When the HTTP request data packet is obtained, the HTTP output event is used to record the HTTP request information, where the HTTP request information includes the second domain name, the second address, and the HTTP request response time.

[0125] The above-mentioned resolution anomaly verification module 30 is also used to obtain the historical domain name and historical address resolved to the historical request, determine the historical resolution record based on the historical domain name and historical address, and store the historical resolution record in a preset storage system.

[0126] The above-mentioned resolution anomaly verification module 30 is also used for the first monitoring alarm result including the third domain name corresponding to the resolution failure, and the second monitoring alarm result including the first domain name and the first address corresponding to the DNS request resolution anomaly.

[0127] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0128] This embodiment further provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0129] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0130] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0131] S1, obtain DNS request.

[0132] S2: parse the DNS request, and if the parsing fails, generate a first monitoring alarm result.

[0133] S3: If the first domain name and the first address corresponding to the DNS request are resolved, whether the DNS request resolution is normal is determined based on the time interval for the first record of the first domain name and the query results of the first domain name and the first address in the historical resolution records.

[0134] S4: If it is determined that the DNS request resolution is abnormal, a second monitoring alarm result is generated.

[0135] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0136] In addition, in combination with the DNS resolution monitoring method in the above embodiment, the embodiment of the present application can provide a storage medium for implementation. The storage medium stores a computer program; when the computer program is executed by a processor, any one of the DNS resolution monitoring methods in the above embodiment is implemented.

[0137] Those skilled in the art should understand that the technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0138] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A DNS resolution monitoring method, characterized in that: include: Get DNS requests, including: Deploy eBPF programs; Run the eBPF program, and obtain the DNS request and HTTP request based on a preset tracing function; Performing resolution processing on the DNS request, and if the resolution fails, generating a first monitoring alarm result; If the first domain name and the first address corresponding to the DNS request are resolved, judging whether the DNS request resolution is normal based on the first recording time interval of the first domain name and the query results of the first domain name and the first address in the historical resolution record, including: If the first record time interval of the first domain name is greater than a preset threshold, obtaining a query result of the first domain name and the first address in the historical resolution record, the historical resolution record including a historical domain name and a historical address; wherein the first record time interval is an interval between the current time and the time when the first domain name is first recorded; If the first domain name and the first address exist in the historical resolution record, the DNS request resolution is normal; if not, the DNS request resolution is abnormal; If the first recording time interval of the first domain name is less than or equal to the preset threshold, recording the first domain name and the first address in the historical resolution record; If it is determined that the DNS request resolution is abnormal, a second monitoring alarm result is generated; Get HTTP request; If the HTTP request is successfully parsed, obtaining a second domain name and a second address corresponding to the HTTP request; Based on the time interval of the first recording of the second domain name and based on the query result of the second domain name and the second address in the historical resolution record, determining whether the HTTP request resolution is normal; If the HTTP request is parsed abnormally, a third monitoring alarm result is generated, and the third monitoring alarm result includes the second domain name and the second address corresponding to the HTTP request parsing abnormally.

2. The DNS resolution monitoring method according to claim 1, characterized in that: The deployment of the eBPF program includes: Defining a DNS output event and an HTTP output event in the eBPF program; When the DNS request data packet is obtained, the DNS output event is used to record DNS request information, where the DNS request information includes the first domain name, the first address, and the DNS request response time; When the HTTP request data packet is acquired, the HTTP output event is used to record HTTP request information, where the HTTP request information includes the second domain name, the second address and HTTP request response time.

3. The DNS resolution monitoring method according to claim 1, characterized in that: Obtaining the historical analysis record includes: A historical domain name and a historical address resolved from a historical request are obtained, the historical resolution record is determined based on the historical domain name and the historical address, and the historical resolution record is stored in a preset storage system.

4. The DNS resolution monitoring method according to any one of claims 1 to 3, characterized in that: The first monitoring alarm result includes the third domain name corresponding to the resolution failure, and the second monitoring alarm result includes the first domain name and the first address corresponding to the abnormal DNS request resolution.

5. A DNS resolution monitoring device, characterized in that: include: The data acquisition module is used to obtain DNS requests, including: Deploy eBPF programs; Run the eBPF program, and obtain the DNS request and HTTP request based on a preset tracing function; A DNS resolution module, used to resolve the DNS request, and if the resolution fails, generate a first monitoring alarm result; A resolution abnormality verification module, for determining whether the DNS request resolution is normal based on a time interval for the first recording of the first domain name and a query result of the first domain name and the first address in a historical resolution record if the first domain name and the first address corresponding to the DNS request are resolved, including: If the first record time interval of the first domain name is greater than a preset threshold, obtaining a query result of the first domain name and the first address in the historical resolution record, the historical resolution record including a historical domain name and a historical address; wherein the first record time interval is an interval between the current time and the time when the first domain name is first recorded; If the first domain name and the first address exist in the historical resolution record, the DNS request resolution is normal; if not, the DNS request resolution is abnormal; If the first recording time interval of the first domain name is less than or equal to the preset threshold, recording the first domain name and the first address in the historical resolution record; The resolution anomaly verification module is further configured to generate a second monitoring alarm result if it is determined that the DNS request resolution is abnormal; Get HTTP request; If the HTTP request is successfully parsed, obtaining a second domain name and a second address corresponding to the HTTP request; Based on the time interval of the first recording of the second domain name and based on the query result of the second domain name and the second address in the historical resolution record, determining whether the HTTP request resolution is normal; If the HTTP request is parsed abnormally, a third monitoring alarm result is generated, and the third monitoring alarm result includes the second domain name and the second address corresponding to the HTTP request parsing abnormally.

6. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to execute the DNS resolution monitoring method according to any one of claims 1 to 4.

7. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the DNS resolution monitoring method according to any one of claims 1 to 4 when running.

Images