Fault processing method and device based on multi-source log data and computer equipment

Abstract

The invention relates to a fault processing method and device based on multi-source log data, computer equipment, a storage medium and a program product. The method comprises the steps of receiving a log fault processing request, determining a target log identifier and a log collection mode corresponding to the log fault processing request, querying at least one of a log database, a log gateway and a data integration processing component according to the target log identifier, obtaining a log query result, and processing the log query result according to the log query result. Determining a log fault range according to the log query result; if it is determined that the log collection mode is real-time collection, service monitoring information is obtained, the log fault position is determined according to the log fault range and the service monitoring information, and fault removal processing is carried out based on the log fault position. By adopting the method, the link length of log troubleshooting processing can be reduced, and the efficiency of fault positioning and troubleshooting processing is improved.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a fault handling method, apparatus, computer equipment, computer-readable storage medium, and computer program product based on multi-source log data. Background Art

[0002] With the development of cloud computing technology, the expansion of business volume and the increase in business complexity in different business systems, the specific data and business information involved in the business processing process have increased accordingly. In order to ensure the security of business data and business information in the business system and locate and eliminate faults in the business processing process, it is necessary to collect and store the log data of the business system during the business processing process.

[0003] In traditional technology, since different business systems usually involve multi-terminal processing, it is necessary to set up a variety of different data collection terminals to comprehensively collect log data associated with the business system in real time or at a scheduled time. In this way, by comprehensively collecting log data and performing fault detection and processing based on log data, the system can be guaranteed to run stably and have efficient operation and maintenance.

[0004] However, since the current business system involves multi-terminal processing, different data collection terminals are required to collect their own log data respectively. The log data collection and processing link is long and complex, involving the collaborative work of multiple components and modules. When a business system fails, a large amount of manpower and material resources are required to check and troubleshoot different components and modules separately. There is still a problem of low efficiency in fault location and troubleshooting. Summary of the invention

[0005] Based on this, it is necessary to provide a fault handling method, device, computer equipment, computer-readable storage medium and computer program product based on multi-source log data, which can quickly locate the fault location, reduce detection and troubleshooting operations, and improve the efficiency of fault location and troubleshooting when a business system fails, in response to the above technical problems.

[0006] In the first aspect, the present application provides a fault handling method based on multi-source log data, including: receiving a log fault handling request, determining a target log identifier and a log collection method corresponding to the log fault handling request; according to the target log identifier, querying at least one of a log database, a log gateway, and a data integration processing component to obtain a log query result, and determining a log fault scope based on the log query result; if it is determined that the log collection method is real-time collection, obtaining business monitoring information, determining a log fault location based on the log fault scope and the business monitoring information, and performing troubleshooting based on the log fault location.

[0007] In the second aspect, the present application also provides a fault handling device based on multi-source log data, including: a log fault handling request receiving module, used to receive a log fault handling request, determine the target log identifier and log collection method corresponding to the log fault handling request; a log fault range determination module, used to query at least one of the log database, log gateway and data integration processing components according to the target log identifier, obtain the log query result, and determine the log fault range according to the log query result; a log fault location determination module, used to obtain business monitoring information if it is determined that the log collection method is real-time collection, determine the log fault location according to the log fault range and the business monitoring information, and perform troubleshooting based on the log fault location.

[0008] In the third aspect, the present application also provides a computer device, including a memory and a processor, the memory storing a computer program, and the processor implementing the following steps when executing the computer program: receiving a log fault processing request, determining a target log identifier and a log collection method corresponding to the log fault processing request; according to the target log identifier, querying at least one of a log database, a log gateway, and a data integration processing component to obtain a log query result, and determining a log fault scope according to the log query result; if it is determined that the log collection method is real-time collection, obtaining business monitoring information, determining the log fault location according to the log fault scope and the business monitoring information, and performing troubleshooting based on the log fault location.

[0009] In a fourth aspect, the present application also provides a computer-readable storage medium having a computer program stored thereon, which implements the following steps when executed by a processor: receiving a log fault processing request, determining a target log identifier and a log collection method corresponding to the log fault processing request; querying at least one of a log database, a log gateway, and a data integration processing component according to the target log identifier, obtaining a log query result, and determining a log fault scope according to the log query result; if it is determined that the log collection method is real-time collection, obtaining business monitoring information, determining a log fault location according to the log fault scope and the business monitoring information, and performing troubleshooting based on the log fault location.

[0010] In a fifth aspect, the present application also provides a computer program product, including a computer program, which implements the following steps when executed by a processor: receiving a log fault processing request, determining a target log identifier and a log collection method corresponding to the log fault processing request; querying at least one of a log database, a log gateway, and a data integration processing component according to the target log identifier, obtaining a log query result, and determining a log fault scope according to the log query result; if it is determined that the log collection method is real-time collection, obtaining business monitoring information, determining a log fault location according to the log fault scope and the business monitoring information, and performing troubleshooting based on the log fault location.

[0011] In the above-mentioned fault handling method, device, computer equipment, computer-readable storage medium and computer program product based on multi-source log data, by receiving a log fault handling request, determining the target log identifier and log collection method corresponding to the log fault handling request, and querying at least one of the log database, log gateway and data integration processing components according to the target log identifier, obtaining the log query result, and determining the log fault range according to the log query result, the components that need to be checked and checked can be reduced during the query process, the link length of the log fault troubleshooting process can be reduced, and the efficiency of fault location and troubleshooting can be improved. Further, if the log collection method is determined to be real-time collection, the business monitoring information is obtained, the log fault location is determined according to the log fault range and the business monitoring information, and the fault troubleshooting process is performed based on the log fault location, so that the business monitoring information of different dimensions and the determined log fault range can be further combined to accurately determine the log fault location, avoid missing fault problems, and perform troubleshooting on the log fault location in a timely manner to ensure the stability and availability of the business system. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0013] Figure 1 An application environment diagram of a fault handling method based on multi-source log data in one embodiment;

[0014] Figure 2 The figure is a flowchart of a fault handling method based on multi-source log data in one embodiment;

[0015] Figure 3A schematic diagram of a process of log collection and storage based on multi-source log data in one embodiment;

[0016] Figure 4 A schematic diagram of the structure of a log collection module in one embodiment;

[0017] Figure 5 A schematic diagram of a process for obtaining log query results in one embodiment;

[0018] Figure 6 A schematic diagram of a process for determining a log fault scope in one embodiment;

[0019] Figure 7 A schematic diagram of a process for determining a log fault location in an embodiment;

[0020] Figure 8 A schematic diagram of the distribution of service monitoring information in an embodiment;

[0021] Fig. 9 A flowchart of a fault handling method based on multi-source log data in another embodiment;

[0022] Fig.10 A schematic diagram of a flow chart of a fault handling method based on multi-source log data in yet another embodiment;

[0023] Fig.11 A schematic diagram of a conventional process of troubleshooting log collection in one embodiment;

[0024] Fig.12 A schematic diagram of the overall processing process of a fault handling method based on multi-source log data in one embodiment;

[0025] Fig.13 is a structural block diagram of a fault processing device based on multi-source log data in one embodiment;

[0026] Fig.14 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0027] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail 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 used to limit the present application.

[0028] The fault handling method based on multi-source log data provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. Among them, the terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices, portable wearable devices, and aircraft, etc. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car devices, and projection devices. Portable wearable devices can be smart watches, smart bracelets, and head-mounted devices. The head-mounted device can be a virtual reality (VR) device, an augmented reality (AR) device, smart glasses, etc. The server 104 can be an independent physical server, or a server cluster composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal 102 and the server 104 may be directly or indirectly connected via wired or wireless communication, which is not limited in the embodiments of the present application.

[0029] Among them, the terminal 102 and the server 104 can be used alone to perform the fault handling method based on multi-source log data provided in the embodiment of the present application, and the terminal 102 and the server 104 can also cooperate to perform the fault handling method based on multi-source log data provided in the embodiment of the present application. For example, taking the fault handling method based on multi-source log data provided in the embodiment of the present application as an example, when the server 104 receives the log fault handling request fed back by the terminal 102, it determines the target log identification and log collection method corresponding to the log fault handling request, and according to the target log identification, queries the log database, log gateway and at least one of the data integration processing components to obtain the log query result, so as to determine the log fault range according to the log query result. Further, if the server 104 determines that the log collection method is real-time collection, it obtains business monitoring information, determines the log fault location according to the log fault range and business monitoring information, and performs troubleshooting based on the log fault location.

[0030] In an exemplary embodiment, Figure 2 As shown in the figure, a fault handling method based on multi-source log data is provided. Figure 1 The server 104 in the example is used as an example to illustrate the method, which includes the following steps 202 to 206. Among them:

[0031] Step 202: receiving a log fault processing request, and determining a target log identifier and a log collection method corresponding to the log fault processing request.

[0032] Specifically, if the user cannot query log data on the log console page, that is, when a log collection failure occurs, a log fault processing request can be triggered based on the terminal where the log console is located. After detecting the log fault processing request, the terminal will feedback the log fault processing request to the server. After receiving the log fault processing request, the server parses the log fault processing request to determine the target log identifier and log collection method corresponding to the log fault processing request.

[0033] The target log identifier can be understood as the identifier corresponding to the log data that the user needs to query, that is, the user can enter the target log identifier on the log console page to query the log data. The log collection method refers to the way the log collection module collects logs, which can specifically include real-time collection and log collector collection. Real-time collection specifically includes: API (Application Programming Interface) collection, SDK (Software Development Kit) collection, and kafka (distributed message queue based on publish / subscribe mode) protocol collection, etc.

[0034] Step 204: query at least one of the log database, the log gateway, and the data integration processing component according to the target log identifier to obtain a log query result, and determine the log fault scope according to the log query result.

[0035] Specifically, when the user uploads the log, but the log data is not displayed on the log console page, it indicates that there is a log collection failure, and diagnosis and troubleshooting are required. Among them, the components that need to be diagnosed and troubleshooted specifically include the log database, log gateway, and data integration processing components, that is, it is necessary to query at least one of the log database, log gateway, and data integration processing components, and specifically in the order of querying the log database → log gateway → data integration processing component. If the corresponding log query result can be obtained when querying the log database, then the log gateway and data integration processing components do not need to be further queried. Similarly, if the corresponding log query result is not obtained when querying the log database, but the corresponding log query result can be obtained when querying the log gateway, then the data integration processing component does not need to be further queried.

[0036] Furthermore, after querying at least one of the log database, log gateway, and data integration processing component according to the target log identifier and obtaining the log query result, the log fault scope is determined according to the log query result, for example, the log fault scope is specifically the log console or the log query link, or the collection link link. Among them, the collection link link may specifically include: the link of receiving or forwarding log data by the log gateway, the link of receiving or forwarding log data by the data integration processing component, and the link of delivering or consuming log data in the Kafka intermediate message.

[0037] Step 206: If it is determined that the log collection mode is real-time collection, then obtain the business monitoring information, determine the log fault location according to the log fault range and the business monitoring information, and perform troubleshooting based on the log fault location.

[0038] Specifically, if the log collection method is determined to be real-time collection, such as API collection, SDK collection, and kafka protocol collection, then business monitoring information is obtained, including service component monitoring information corresponding to the service component, container component monitoring information corresponding to the container component, and host node monitoring information of the host node where the container component is deployed, etc., so as to determine the location of the log fault based on the log fault scope, service component monitoring information, container component monitoring information, and host node monitoring information, whether it is a component problem, a machine resource problem, or a network transmission problem.

[0039] Exemplarily, the log fault location includes: for example, in the log console or log query link, container abnormality, host node abnormality, or service component abnormality. Another example is in the collection link link, in the log gateway receiving or forwarding log data link, or in the data integration processing component receiving or forwarding log data link, or in the log data delivery or data consumption link in the Kafka intermediate message, container abnormality, host node abnormality, or service component abnormality, etc.

[0040] Furthermore, after determining the log fault location, the server further performs troubleshooting based on the log fault location, including subsequent processing such as replacement of faulty components and resolution of fault problems based on the specific log fault location.

[0041] In an exemplary embodiment, Figure 3 As shown in the figure, a log collection and storage process based on multi-source log data is provided. Figure 3 It can be seen that the log collection and storage process involves multiple modules, including log collection module, log gateway, Kafka message middleware, data cleaning and conversion module, local column storage and remote object storage. Among them:

[0042] P1. For the log collection module: The log collection module collects logs in a variety of ways. Its collection methods are multi-source, which can include API collection, SDK collection, log collector collection, Kafka protocol collection and other collection methods.

[0043] For example, Figure 4 As shown, a log collection module is provided. Figure 4 It can be seen that the log collection module specifically includes API collection, SDK collection, log collector collection, kafka protocol collection and other collection methods. Among them, API / SDK collection adopts the method of real-time log push, which can flexibly push the logs that users need to upload, while the log collector method is to automatically push the logs that meet the collection rules. This method requires users to install the collector on the local machine and configure the collection rules. The log collector will install the collection rules to collect logs in a specific directory or in accordance with specific rules. Among them, the logs collected by API / SDK and log collector will be compressed and sent to the log gateway through https requests. Kafka protocol collection uses kafka (i.e., a distributed message queue based on publish / subscribe mode) as a transit to upload logs.

[0044] P2. Log Gateway: The log gateway extracts some fields and identifiers in the https request for log upload for subsequent authentication and packaging. The log gateway authenticates the accessKey field (access key) and the temporary credential token. It usually needs to call other modules to obtain user information. If it matches and the status is correct, the authentication is successful. Otherwise, the authentication fails and an error message is returned to the log collection module. If the authentication is successful, the log gateway will further package the log package, add some key information and identifiers of the log gateway, and then send the log package to the Kafka message middleware.

[0045] P3, Kafka message middleware: Kafka message middleware will store the log package in the message queue or partition of a specific topic, waiting for the etl (Extract Transform Load, understood as data cleaning and transformation) module to consume the log package.

[0046] P4, etl (data cleaning and conversion) module: The data cleaning and conversion module processes the log package uploaded by the kafka message middleware. After obtaining the log package, the data cleaning and conversion module will unpack it, obtain the original log in the package, and further verify and convert the original log to verify whether the log format is correct and whether the md5 value of the log is consistent. If the verification passes, it will be converted into the original log and some predefined fields will be added to display the log information on the log console page later. The original log with predefined fields added will be sent to the database for storage.

[0047] P5. Local column storage and remote object storage: The database uses column storage, and clickhouse and byconity are commonly used. The data is stored in the column database and then stored in the remote object storage. Among them, the log console queries whether the log is uploaded successfully, usually first querying the local column storage database. If the log data cannot be found in the local column storage database, the data will be pulled from the remote object storage. If the log data cannot be found in the remote object storage, the log console will be fed back with a prompt message that the log data cannot be successfully queried, and the system will be reported to diagnose and troubleshoot the last location of the log and the cause of the collection failure. The collection failure problem is diagnosed and checked, and the key node indicators of the entire log collection system are monitored.

[0048] In the above-mentioned fault handling method based on multi-source log data, by receiving a log fault handling request, determining the target log identifier and log collection method corresponding to the log fault handling request, and querying at least one of the log database, log gateway, and data integration processing components according to the target log identifier, obtaining the log query result, and determining the log fault range according to the log query result, the components that need to be checked and checked can be reduced during the query process, the link length of the log fault troubleshooting process can be reduced, and the efficiency of fault location and troubleshooting can be improved. Further, if the log collection method is determined to be real-time collection, the business monitoring information is obtained, the log fault location is determined according to the log fault range and the business monitoring information, and the troubleshooting process is performed based on the log fault location, so that the business monitoring information of different dimensions and the determined log fault range can be further combined to accurately determine the log fault location, avoid missing fault problems, and perform troubleshooting on the log fault location in a timely manner to ensure the stability and availability of the business system.

[0049] In an exemplary embodiment, Figure 5 As shown, the step of obtaining the log query result, that is, querying at least one of the log database, log gateway and data integration processing component according to the target log identifier to obtain the log query result, specifically includes the following steps 502 to 512. Among them:

[0050] Step 502: query the log database according to the target log identifier.

[0051] Among them, if the user cannot query log data according to the target log identifier on the log console page, a log fault handling request is triggered based on the terminal where the log console is located. The terminal feeds back the log fault handling request to the server, and the server parses the log fault handling request to determine the target log identifier corresponding to the log fault handling request.

[0052] Specifically, after obtaining the target log identifier, the server performs a log query in the query order of log database → log gateway → data integration processing component. Specifically, it is necessary to first query the log database according to the target log identifier to determine whether there is target log data matching the target log identifier in the log database. Among them, by querying the log database, it can be located whether it is a collection problem of the log system or a log query problem of the log console. Specifically, if the log database contains the target log data, that is, the query result corresponding to the log database is a successful query, it means that there is no fault in the log database, and the scope of the log fault can be located to the log console or the log query link. Among them, if the target log data does not exist in the database, it means that there is a problem in the collection link of the log system, and the scope of the log fault can be located to the log collection link.

[0053] Step 504: If it is determined that there is target log data matching the target log identifier in the log database, a log display query is performed on the log console according to the target log identifier to obtain a log query result.

[0054] Specifically, if it is determined that there is target log data matching the target log identifier in the log database, that is, the query result corresponding to the log database is a successful query on the log database, then it indicates that there is no failure in the log database. The server needs to further perform a log display query on the log console based on the target log identifier to determine whether there is a problem with the log display of the log console and obtain the corresponding log query result.

[0055] When the server performs a log display query on the log console, the log display result and the log query logic can be specifically queried. If the log display result is a successful log display, it indicates that there is no problem with the log display of the log console, and the log query logic can be further queried to determine whether the log query logic is incorrect. If the log display result is determined to be a failed log display, it indicates that there is a problem with the log display of the log console.

[0056] After executing step 502, step 506 is executed. If it is determined that there is no target log data matching the target log identifier in the log database, the log gateway is queried according to the target log identifier to determine the first forwarding state of the log gateway for the target log data.

[0057] Specifically, if the server determines that there is no target log data matching the target log identifier in the log database, that is, the log data is not stored in the log data block, that is, when it is determined that there is a problem in the collection link of the log system, it is necessary to further query the log gateway based on the target log identifier to determine the first forwarding status of the log gateway for the target log data.

[0058] The first forwarding status of the log gateway for the target log data specifically includes that the log gateway successfully forwards the target log data, and that the log gateway fails to successfully forward the target log data.

[0059] Step 508: If the first forwarding status is that the log gateway fails to forward the target log data, then determine the first receiving status of the log gateway for the target log data, and determine the log query result according to the first receiving status.

[0060] Specifically, if the server determines that the first forwarding state is that the log gateway fails to forward the target log data, then the first receiving state of the log gateway for the target log data is determined, that is, whether the log gateway successfully receives the target log data. The first receiving state of the log gateway for the target log data specifically includes that the log gateway successfully receives the target log data and that the log gateway fails to successfully receive the target log data.

[0061] Furthermore, when determining the log query result based on the first receiving status, if the first receiving status of the log gateway for the target log data is determined to be that the log gateway successfully receives the target log data, then it can be determined that the log query result is that the log gateway query is successful, but the log gateway fails to successfully forward the target log data, thereby determining that there is a fault in the log gateway.

[0062] On the contrary, if it is determined that the first receiving status of the log gateway for the target log data is that the log gateway failed to successfully receive the target log data, then it can be determined that the log query result is a log gateway query failure, that is, the log gateway did not receive the target log data, and thus it can be determined that there is a fault in the log collection module, which may be a fault when collecting log data using the API collection method, or a fault when using the log collector to collect log data, etc.

[0063] After executing step 506, execute step 510. If the first forwarding status is that the log gateway successfully forwards the target log data, query the data integration processing component according to the target log identifier to determine the second forwarding status of the data integration processing component for the target log data.

[0064] Specifically, if the server determines that the first forwarding state is that the log gateway successfully forwards the target log data, it further queries the data integration processing component to determine whether the data integration processing component successfully forwards the target log data.

[0065] Furthermore, if the server determines that the log gateway successfully forwards the target log data, that is, the log gateway successfully receives and successfully forwards the target log data, and the log gateway and the components associated with the log gateway are not faulty, the data integration processing component is further queried according to the target log identifier to determine the second forwarding state of the data integration processing component for the target log data, that is, to determine whether the data integration processing component successfully forwards the target log data. Among them, the second forwarding state of the data integration processing component for the target log data specifically includes that the data integration processing component fails to successfully forward the target log data, and that the data integration processing component successfully forwards the target log data.

[0066] Among them, if the server determines that the second forwarding state is that the data integration processing component successfully forwards the target log data, it means that the data integration processing component successfully receives and successfully forwards the target log data. It can be determined that there is no fault in the data integration processing component and the components associated with the data integration processing component, and thus it can be determined that there is a fault in the log storage.

[0067] Step 512: if the second forwarding status is that the data integration processing component fails to forward the target log data, determine the second receiving status of the data integration processing component for the target log data, and determine the log query result according to the second receiving status.

[0068] Specifically, if the server determines that the second forwarding state is that the data integration processing component fails to forward the target log data, then the second receiving state of the target log data by the data integration processing component is determined, that is, whether the data integration processing component successfully receives the target log data. The second receiving state of the target log data by the data integration processing component specifically includes that the data integration processing component successfully receives the target log data and that the data integration processing component fails to successfully receive the target log data.

[0069] Further, when determining the log query result according to the second receiving state, if the server determines that the data integration processing component successfully receives the target log data, it can be determined that the query result is that the data integration processing component query is successful, but the data integration processing component fails to forward the target log data, then it can be determined that the data integration processing component has a fault.

[0070] On the contrary, if the server determines that the data integration processing component has not successfully received the target log data, it determines that the query result is that the data integration processing component query failed, and the Kafka message middleware has not successfully forwarded the target log data to the data integration processing component, then it can be determined that there is a fault in the Kafka message middleware.

[0071] In an exemplary embodiment, Figure 6 As shown, a process for determining the scope of log failure is provided. Figure 6 It can be seen that the process of determining the scope of log failure specifically includes:

[0072] 1) Determine whether there is target log data matching the target log identifier in the log database. 2) If it is determined that there is target log data matching the target log identifier in the log database, perform a log display query on the log console to obtain the log query result. 3) If the log query result of the log console is abnormal, locate the log console or log query failure. 4) If it is determined that there is no target log data matching the target log identifier in the log database, query the log gateway to determine whether the log gateway successfully forwards the target log data. 5) If it is determined that the log gateway does not successfully forward the target log data, determine whether the log gateway successfully receives the target log data. 6) If the log gateway successfully receives the target log data, locate the log gateway failure. Among them, the log gateway successfully receives the target log data, but the log gateway does not successfully forward the log data, that is, when the log gateway fails, it may be due to reasons such as request parameters not meeting the specifications or authentication failure, resulting in the log gateway not forwarding the next step. 7) If the log gateway does not successfully receive the target log data, locate the log collection module failure. Among them, if the log gateway fails to successfully receive the target log data and fails to successfully forward the target log data, it can be located that there is a problem with the log collection environment, resulting in the failure of the log to be successfully transmitted. 8) If it is determined that the log gateway successfully forwards the target log data, query the data integration processing component to determine whether the data integration processing component successfully forwards the target log data. 9) If it is determined that the data integration processing component fails to successfully forward the target log data, determine whether the data integration processing component successfully receives the target log data. 10) If it is determined that the data integration processing component successfully receives the target log data, the data integration processing component is located to have a fault. Among them, if it is determined that the data integration processing component successfully receives the target log data but fails to successfully forward the target log data, that is, when the data integration processing component fails, it can be specifically that the data integration processing component fails to unpack the log, or the log does not meet the specifications, etc., resulting in the log being discarded, so the next step of forwarding is not performed. 11) If it is determined that the data integration processing component fails to successfully receive the target log data, the kafka message middleware is located to have a fault. If it is determined that the data integration processing component has not successfully received the target log data and has not successfully forwarded the target log data, the kafka message middleware is located to have a fault. When the kafka message middleware fails, it may be that the kafka cluster is abnormal or there is a problem with the kafka data delivery and consumption environment. 12) If it is determined that the data integration processing component has successfully forwarded the target log data, the log storage is located to have a fault. If it is determined that the data integration processing component has successfully received and successfully forwarded the target log data, but the target log data cannot be queried, the log storage can be located to have a fault.The log storage failure may specifically include: database write failure, network anomaly, etc., which result in the target log data not being correctly written into the database, resulting in the log console being unable to query the target log data.

[0073] In this embodiment, the log database is queried according to the target log identifier. If it is determined that there is target log data matching the target log identifier in the log database, a log display query is performed on the log console according to the target log identifier to obtain the log query result. If it is determined that there is no target log data matching the target log identifier in the log database, the log gateway is queried according to the target log identifier to determine the first forwarding state of the log gateway for the target log data, and when it is determined that the first forwarding state is that the log gateway has not successfully forwarded the target log data, the first receiving state of the log gateway for the target log data is determined, so as to determine the log query result according to the first receiving state. If the first forwarding state is that the log gateway successfully forwards the target log data, the data integration processing component is queried according to the target log identifier to determine the second forwarding state of the data integration processing component for the target log data, and when the second forwarding state is that the data integration processing component fails to forward the target log data, the second receiving state of the data integration processing component for the target log data is determined, so as to determine the log query result according to the second receiving state, thereby realizing log data query on at least one of the log database, log gateway and data integration processing component according to the target log identifier, and gradually determining whether there are faults in different components according to the query results, instead of adopting a unified query and troubleshooting method for all components, so that targeted and orderly troubleshooting can be carried out, the fault location can be quickly located, and the fault can be solved in time, thereby improving the stability and availability of the system.

[0074] In an exemplary embodiment, Figure 7 As shown, the step of determining the log fault location, that is, obtaining the business monitoring information, and determining the log fault location according to the log fault range and the business monitoring information, specifically includes the following steps 702 to 706. Among them:

[0075] Step 702: Obtain service component monitoring information corresponding to the service component, container component monitoring information corresponding to the container component, and host node monitoring information of a host node on which the container component is deployed.

[0076] Specifically, when the server monitors the information of the business system and obtains the business monitoring information, it needs to monitor the host node, the container component deployed on the host node, and the service component corresponding to the underlying resources, and obtain the service component monitoring information corresponding to the service component, the container component monitoring information corresponding to the container component, and the host node monitoring information of the host node on which the container component is deployed.

[0077] For host nodes, node-exporter (i.e., the indicator collector in the service monitoring system, which is used to collect and expose hardware and system indicators of operating systems, runs through HTTP servers, and provides various system monitoring parameters, such as CPU load, memory usage, network status, etc. These data can be actively captured by the indicator collector for monitoring and alarming) is used to collect the operating status of host nodes. Among them, the indicators that need to be monitored by host nodes include: CPU, memory and disk usage, network socket usage status, and disk and network read and write rates and read and write volumes. The indicators that need to be monitored by host nodes reflect the underlying status of the entire system. If these indicators are abnormal, they will affect other upper-level services.

[0078] For example, for container components, the container performance monitoring component corresponding to the container orchestration platform is used, which can monitor the indicators of the container's operating status, including container CPU and memory usage, disk partition usage, and network read and write IO, etc. Among them, since containers are prone to turbulence during expansion and contraction periods or updates and iterations, and when the resources in the container are almost exhausted, various abnormal events are prone to occur that affect internal services, so it is necessary to monitor the container that carries the service itself to determine whether there is a fault.

[0079] Optionally, for service components, by adopting the service monitoring components corresponding to the container orchestration platform, major internal events and current operating status of the service are monitored. The monitoring indicators corresponding to the service components include: network data inbound and outbound traffic, number of network requests, number of request errors, abnormal events, etc.

[0080] Step 704: Determine target business monitoring information that matches the log fault range from the service component monitoring information, the container component monitoring information, and the host node monitoring information.

[0081] Specifically, according to the scope of the log fault, for example, from the service component monitoring information, the container component monitoring information, and the host node monitoring information, the target business monitoring information that matches the scope of the log fault is determined. Among them, the scope of the log fault may specifically include the log console or the log query link, or the collection link link, wherein the collection link link may specifically include: the log gateway receives or forwards the log data link, the data integration processing component receives or forwards the log data link, the log data delivery or consumption link in the kafka intermediate message, etc., then according to the scope of the log fault, the service component monitoring information, the container component monitoring information, and the host node monitoring information, etc., when the location of the log fault is determined, it is specifically a component problem, a machine resource problem, or a network transmission problem.

[0082] Exemplarily, the target business monitoring information that matches the log fault scope can specifically be the container component monitoring information that matches the log console or log query link. For example, in the collection link link, it can be the service component monitoring information that matches the log gateway receiving or forwarding log data link, or the container component monitoring information that matches the data integration processing component receiving or forwarding log data link.

[0083] Step 706: Determine the log fault location according to the log fault range and target business monitoring information.

[0084] Specifically, when the server determines the log fault location based on the log fault scope and target business monitoring information, it needs to determine the location of the possible fault in the corresponding environment for the specific log fault scope, including the log console or log query link, or the collection link link. For example, if the log database contains the target log data, that is, the log database has not failed, the log fault scope can be located to the log console or log query link. If the target log data does not exist in the database, it indicates that there is a problem in the collection link of the log system, and the log fault scope can be located to the log collection link.

[0085] Exemplarily, if the target log data does not exist in the database, that is, when there is a fault in the collection link environment, the log gateway is queried to determine whether the log gateway has successfully forwarded the target log data. If it is determined that the log gateway has not successfully forwarded the target log data, it is further determined whether the log gateway has successfully received the target log data. If the log gateway has not successfully received the target log data, the log gateway is located to have a fault. If the log gateway has successfully received the target log data, the log collection module is located to have a fault.

[0086] Furthermore, if it is determined that the log gateway successfully forwards the target log data, the data integration processing component is queried according to the target log identifier to determine whether the data integration processing component successfully forwards the target log data. Among them, if it is determined that the data integration processing component does not successfully forward the target log data, then the data integration processing component is further checked to determine whether it successfully receives the target log data. If it is determined that the data integration processing component successfully receives the target log data, the data integration processing component is located to have a fault. If it is determined that the data integration processing component does not successfully receive the target log data, the kafka message middleware is located to have a fault. Among them, if it is determined that the data integration processing component successfully forwards the target log data, the log storage is located to have a fault.

[0087] It can be understood that by querying and locating the log database, log gateway, data integration processing component and other components in the collection link in turn, it can be determined which component of the log database, log gateway and data integration processing component may have a fault. That is, based on the faulty components in the log database, log gateway and data integration processing component, the scope of the log fault can be determined. By combining the service component monitoring information, container component monitoring information and host node monitoring information, the actual log fault location can be further determined.

[0088] In an exemplary embodiment, Figure 8 As shown, a distribution diagram of business monitoring information is provided. Figure 8 It can be seen that the business monitoring information specifically includes: service component monitoring information, container component monitoring information and host node monitoring information. Among them, the business monitoring information can be stored in the time series database through the service monitoring system, and the specific business monitoring information can be viewed through the monitoring panel of the service monitoring system.

[0089] Specifically, refer to Figure 8 It can be seen that the host node monitoring information is obtained by using node-exporter (i.e., the indicator collector in the service monitoring system) to collect the running status of the host node, and the specific indicator information includes CPU, memory and disk usage, network socket usage status, and disk and network read and write rates and read and write volumes. The container component specifically uses the container performance monitoring component corresponding to the container orchestration platform to monitor the indicators of the container's running status, including container CPU and memory usage, disk partition usage, and network read and write IO. Among them, for the service component, by using the service monitoring component corresponding to the container orchestration platform, the internal major events and current running status of the service are monitored. The monitoring indicators corresponding to the service component include: network data in and out traffic, number of network requests, number of request errors, abnormal events, etc.

[0090] Exemplarily, when monitoring a service component, for example, after the log package is transmitted to the etl module (i.e., the data cleaning and conversion module), the decompression of the log package is abnormal. This may be caused by an error in the log compression method or the inability to parse the log package. At this time, the data cleaning and conversion module will discard the log package and generate an indicator to represent the basic information of the discarded log package. At this time, the number of network requests, number of request errors, abnormal events and other indicators in the service component monitoring information can be used to determine whether the log package is discarded in the data cleaning and conversion module.

[0091] In this embodiment, by obtaining service component monitoring information corresponding to the service component, container component monitoring information corresponding to the container component, and host node monitoring information of the host node on which the container component is deployed, target business monitoring information matching the log fault range is determined from the service component monitoring information, the container component monitoring information, and the host node monitoring information. Thus, the log fault location can be determined based on the log fault range and the target business monitoring information, thereby achieving the goal of troubleshooting the problem in a shorter time. At the same time, combined with the monitoring of service components, container components, and host nodes, the system operation status can be monitored in all directions, which can effectively reduce the fault operation and maintenance time, improve the fault diagnosis efficiency, and help maintain the stability of the log collection system.

[0092] In an exemplary embodiment, Fig. 9 As shown in the figure, a fault handling method based on multi-source log data is provided. Figure 1 The server 104 in the example is used as an example to illustrate, including the following steps 902 to 908. Among them:

[0093] Step 902: If it is determined that the log collection mode is log collection by a log collector, a collector state corresponding to the log collector is obtained.

[0094] When determining the scope of log failure, if it is determined that a problem with the log collection module caused the log upload failure, further analysis is required for different collection sources. If it is an API / SDK collection method, error information will usually be fed back, and users can judge whether the log upload method is correct based on the error information. If it is a log collector collection method, it is necessary to determine the operation evaluation results of the log collector to determine the scope of the log failure based on the operation evaluation results of the log collector.

[0095] Specifically, if the log collection method is determined to be log collector collection, it is necessary to check the survival status of the log collector. The log collector number corresponding to the log collector can be obtained to query the monitoring and determine the collector status of the log collector according to the log collector number. Among them, if the log collector is in a downtime state, log collection will not be performed. If the collector status of the log collector is a survival state, it is necessary to further determine whether the collector heartbeat is normal.

[0096] Step 904: If the collector state is a live state, determine the collector heartbeat data corresponding to the log collector.

[0097] Specifically, if it is determined that the collector state of the log collector is a survival state, the collector heartbeat data corresponding to the log collector is further obtained to determine whether the collector heartbeat of the log collector is normal.

[0098] Among them, if the scheduled heartbeat of the log collector is abnormal or the time is too long, it can be determined that the log collector is in an abnormal state based on the collector heartbeat data.

[0099] Step 906: If it is determined based on the heartbeat data of the log collector that the log collector is in a normal operating state, the delivery state of the log collection rule is determined.

[0100] Specifically, if the log collector is determined to be in normal operation based on the heartbeat data of the collector, the log collection rule issuance status is further determined based on the log console, that is, whether the issuance status of the log collection rule is issued normally. Among them, whether the collection rule is correct, if the collection rule issued by the log console is wrong, the target log data to be uploaded may not be successfully collected.

[0101] Step 908: Determine the operation evaluation result of the log collector according to the delivery status of the log collection rule, so as to determine the log fault scope according to the operation evaluation result of the log collector.

[0102] Specifically, the server determines the operation evaluation result of the log collector according to the delivery status of the log collection rule, including whether the collection directory in the log collector exists, whether the regular expression of the collection rule matches, whether the number of collected files meets the requirements (that is, the number of collected files cannot exceed the quantity threshold), etc., and obtains the operation evaluation result of the log collector, so as to further determine the scope of the log fault according to the operation evaluation result of the log collector, that is, determine whether the log collector fails, as well as the stage and cause of the log collector failure.

[0103] In the above-mentioned fault handling method based on multi-source log data, if it is determined that the log collection method is log collector collection, then the collector state corresponding to the log collector is obtained, and when the collector state is determined to be a survival state, the collector heartbeat data corresponding to the log collector is further obtained. Among them, if it is determined that the log collector is in a normal operating state according to the collector heartbeat data, the issuance state of the log collection rule is determined, and according to the issuance state of the log collection rule, the operation evaluation result of the log collector is determined, so as to determine the scope of the log fault according to the operation evaluation result of the log collector, so that according to different log collection methods, targeted query and troubleshooting methods can be adopted, and fault troubleshooting can be carried out in a targeted and orderly manner, and the fault location can be quickly located to solve the fault in time, thereby improving the stability and availability of the system.

[0104] In an exemplary embodiment, Fig.10 As shown in the figure, a fault handling method based on multi-source log data is provided. Figure 1 The server 104 in the example is used as an example to illustrate the method, which includes the following steps 1001 to 1015. Among them:

[0105] Step 1001: receive a log fault processing request, and determine a target log identifier and a log collection method corresponding to the log fault processing request.

[0106] Specifically, after receiving the log fault processing request, the server parses the log fault processing request to determine the target log identifier and the log collection method corresponding to the log fault processing request.

[0107] Step 1002: query the log database according to the target log identifier.

[0108] Specifically, after obtaining the target log identifier, the server performs log query in the query order of log database → log gateway → data integration processing component. Specifically, it is necessary to first query the log database according to the target log identifier to determine whether there is target log data matching the target log identifier in the log database.

[0109] Step 1003: If it is determined that there is target log data matching the target log identifier in the log database, a log display query is performed on the log console according to the target log identifier to obtain a log query result.

[0110] Specifically, if it is determined that there is target log data matching the target log identifier in the log database, that is, the query result corresponding to the log database is a successful query on the log database, the server needs to further perform a log display query on the log console based on the target log identifier to determine whether there is a problem with the log display of the log console and obtain the corresponding log query result.

[0111] After executing step 1002, step 1004 is executed. If it is determined that there is no target log data matching the target log identifier in the log database, the log gateway is queried according to the target log identifier to determine the first forwarding state of the log gateway for the target log data.

[0112] Specifically, if the server determines that there is no target log data matching the target log identifier in the log database, it further queries the log gateway based on the target log identifier to determine the first forwarding status of the log gateway for the target log data, including the log gateway successfully forwarding the target log data and the log gateway failing to successfully forward the target log data.

[0113] Step 1005: If the first forwarding status is that the log gateway fails to forward the target log data, then determine the first receiving status of the log gateway for the target log data, and determine the log query result according to the first receiving status.

[0114] Specifically, if the server determines that the first forwarding state is that the log gateway fails to forward the target log data, then the first receiving state of the log gateway for the target log data is further determined, that is, whether the log gateway successfully receives the target log data. Among them, if the first receiving state of the log gateway for the target log data is determined to be that the log gateway successfully receives the target log data, it can be determined that there is a fault in the log gateway. If the first receiving state of the log gateway for the target log data is determined to be that the log gateway fails to successfully receive the target log data, it can be determined that the log gateway has not received the target log data, that is, it is determined that there is a fault in the log collection module.

[0115] After executing step 1004, execute step 1006. If the first forwarding status is that the log gateway successfully forwards the target log data, query the data integration processing component according to the target log identifier to determine the second forwarding status of the data integration processing component for the target log data.

[0116] Specifically, if the server determines that the first forwarding status is that the log gateway successfully forwards the target log data, it further queries the data integration processing component to determine the second forwarding status of the data integration processing component for the target log data, including that the data integration processing component fails to forward the target log data successfully, and that the data integration processing component successfully forwards the target log data.

[0117] Step 1007: if the second forwarding status is that the data integration processing component fails to forward the target log data, determine the second receiving status of the data integration processing component for the target log data, and determine the log query result according to the second receiving status.

[0118] Specifically, if the server determines that the second forwarding state is that the data integration processing component has not successfully forwarded the target log data, then the second receiving state of the data integration processing component for the target log data is determined, that is, whether the data integration processing component has successfully received the target log data. Among them, if the server determines that the data integration processing component has successfully received the target log data, but the data integration processing component has not successfully forwarded the target log data, it can be determined that the data integration processing component has a fault. If it is determined that the data integration processing component has not successfully received the target log data, that is, the kafka message middleware has not successfully forwarded the target log data to the data integration processing component, it can be determined that the kafka message middleware has a fault.

[0119] After executing step 1003, step 1005, and step 1007, step 1008 is executed to determine the log fault range according to the log query result.

[0120] After executing step 1001, execute step 1009. If it is determined that the log collection mode is log collector collection, obtain the collector state corresponding to the log collector.

[0121] Specifically, if it is determined that the log collection method is log collector collection, it is necessary to check the survival status of the log collector. The log collector number corresponding to the log collector can be obtained to query and monitor the collector status of the log collector according to the log collector number.

[0122] Step 1010: If the collector state is a survival state, determine the collector heartbeat data corresponding to the log collector.

[0123] Specifically, if it is determined that the collector state of the log collector is a survival state, the collector heartbeat data corresponding to the log collector is further obtained to determine whether the collector heartbeat of the log collector is normal.

[0124] Step 1011: If it is determined based on the heartbeat data of the log collector that the log collector is in normal operation, the delivery status of the log collection rule is determined.

[0125] Specifically, if the log collector is determined to be in normal operation based on the collector heartbeat data, the issuance status of the log collection rule is further determined based on the log console, that is, it is determined whether the issuance status of the log collection rule is normally issued.

[0126] Step 1012: Determine the operation evaluation result of the log collector according to the delivery status of the log collection rule, so as to determine the log fault scope according to the operation evaluation result of the log collector.

[0127] Specifically, after the server determines the operation evaluation result of the log collector according to the delivery status of the log collection rule, it further determines the scope of the log fault according to the operation evaluation result of the log collector, that is, determines whether the log collector fails, and the stage and cause of the log collector failure.

[0128] After executing step 1008 or step 1012, execute step 1013 to obtain service component monitoring information corresponding to the service component, container component monitoring information corresponding to the container component, and host node monitoring information of the host node on which the container component is deployed.

[0129] Step 1014: Determine target business monitoring information that matches the log fault range from the service component monitoring information, the container component monitoring information, and the host node monitoring information.

[0130] Step 1015: determine the log fault location according to the log fault range and the target business monitoring information, and perform troubleshooting based on the log fault location.

[0131] In an exemplary embodiment, Fig.11As shown in the figure, a traditional process of troubleshooting log collection is provided. Fig.11 It can be seen that the traditional troubleshooting process for log collection includes: user log collection failure → query log database → eliminate various intermediate modules → query transmission network → query log or simple monitoring → determine the scope of the problem → view the problem log → find the cause of the problem. It is understandable that the traditional log collection troubleshooting process has a long troubleshooting link, and there are many intermediate modules that need to be checked, including log gateway, kafka message middleware, etl data cleaning and conversion module, log storage, and multiple collection terminals at different collection times. If you check in sequence, the cycle is very long, and you may need to check component logs, etc., which is single and incomplete. If you only check simple monitoring, it is easy to ignore the real cause, which ultimately leads to low troubleshooting efficiency.

[0132] Furthermore, if Fig.12 As shown in the figure, a comprehensive processing method for troubleshooting based on multi-source log data is provided. Fig.12 It can be seen that the processing process of the fault handling method based on multi-source log data includes: user log collection failure → query log database → query log gateway → query etl data cleaning and conversion module → determine the scope of the problem → query multi-dimensional monitoring → obtain the cause of the problem. In other words, compared with the traditional log collection troubleshooting method, the fault handling method based on multi-source log data in the embodiment of the present application can change the original investigation of each component to a three-step investigation method. Only the three components of log database, log gateway and data cleaning and conversion module need to be investigated to determine the scope of the problem, and multi-dimensional monitoring includes monitoring of three dimensions of host, container and service components, which can effectively monitor the system and locate and diagnose problems more comprehensively and accurately.

[0133] In the above-mentioned fault handling method based on multi-source log data, by receiving a log fault handling request, determining the target log identifier and log collection method corresponding to the log fault handling request, and querying at least one of the log database, log gateway, and data integration processing components according to the target log identifier, obtaining the log query result, and determining the log fault range according to the log query result, the components that need to be checked and checked can be reduced during the query process, the link length of the log fault troubleshooting process can be reduced, and the efficiency of fault location and troubleshooting can be improved. Further, if the log collection method is determined to be real-time collection, the business monitoring information is obtained, the log fault location is determined according to the log fault range and the business monitoring information, and the troubleshooting process is performed based on the log fault location, so that the business monitoring information of different dimensions and the determined log fault range can be further combined to accurately determine the log fault location, avoid missing fault problems, and perform troubleshooting on the log fault location in a timely manner to ensure the stability and availability of the business system.

[0134] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0135] Based on the same inventive concept, the embodiment of the present application also provides a multi-source log data-based fault handling device for implementing the multi-source log data-based fault handling method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more multi-source log data-based fault handling device embodiments provided below can refer to the above limitations on the multi-source log data-based fault handling method, which will not be repeated here.

[0136] In an exemplary embodiment, Fig.13 As shown, a fault processing device based on multi-source log data is provided, including: a log fault processing request receiving module 1302, a log fault range determining module 1304 and a log fault location determining module 1306, wherein:

[0137] The log fault processing request receiving module 1302 is used to receive the log fault processing request and determine the target log identifier and log collection method corresponding to the log fault processing request; the log fault range determination module 1304 is used to query at least one of the log database, log gateway and data integration processing components according to the target log identifier, obtain the log query result, and determine the log fault range according to the log query result; the log fault location determination module 1306 is used to obtain the business monitoring information if it is determined that the log collection method is real-time collection, determine the log fault location according to the log fault range and the business monitoring information, and perform troubleshooting based on the log fault location.

[0138] In the above-mentioned fault handling device based on multi-source log data, according to the target log identifier, at least one of the log database, log gateway and data integration processing components is queried to obtain the log query result, so as to determine the log fault range according to the log query result, which can reduce the components that need to be checked and checked during the query process, reduce the link length of the log fault troubleshooting process, and improve the efficiency of fault location and troubleshooting. Furthermore, after determining the log fault location according to the log fault range and business monitoring information, the fault troubleshooting process is performed based on the log fault location, so that the log fault location can be further accurately determined by combining the business monitoring information of different dimensions and the determined log fault range, avoiding the omission of fault problems, and timely troubleshooting the log fault location to ensure the stability and availability of the business system.

[0139] In an exemplary embodiment, the log fault range determination module is also used to: query the log database according to the target log identifier; if it is determined that there is no target log data matching the target log identifier in the log database, query the log gateway according to the target log identifier to determine the first forwarding status of the log gateway for the target log data; if the first forwarding status is that the log gateway fails to forward the target log data successfully, determine the first receiving status of the log gateway for the target log data, and determine the log query result according to the first receiving status.

[0140] In an exemplary embodiment, the log fault range determination module is also used to: if the first forwarding status is that the log gateway successfully forwards the target log data, then query the data integration processing component according to the target log identifier to determine the second forwarding status of the data integration processing component for the target log data; if the second forwarding status is that the data integration processing component fails to forward the target log data, then determine the second receiving status of the data integration processing component for the target log data, and determine the log query result based on the second receiving status.

[0141] In an exemplary embodiment, the log fault range determination module is also used to: if it is determined that there is target log data matching the target log identifier in the log database, perform a log display query on the log console according to the target log identifier to obtain a log query result.

[0142] In an exemplary embodiment, the log fault range determination module is also used to: obtain service component monitoring information corresponding to the service component, container component monitoring information corresponding to the container component, and host node monitoring information of the host node on which the container component is deployed; determine the target business monitoring information that matches the log fault range from the service component monitoring information, the container component monitoring information, and the host node monitoring information; and determine the log fault location based on the log fault range and the target business monitoring information.

[0143] In an exemplary embodiment, a fault handling device based on multi-source log data is provided, including a log collector operation evaluation module, which is used to: if it is determined that the log collection mode is log collector collection, then obtain the collector state corresponding to the log collector; if the collector state is a survival state, then determine the collector heartbeat data corresponding to the log collector; if it is determined that the log collector is in a normal operating state based on the collector heartbeat data, then determine the sending state of the log collection rule; according to the sending state of the log collection rule, determine the operation evaluation result of the log collector, so as to determine the scope of the log fault according to the operation evaluation result of the log collector.

[0144] Each module in the above-mentioned fault handling device based on multi-source log data can be implemented in whole or in part by software, hardware and a combination thereof. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0145] In an exemplary embodiment, a computer device is provided. The computer device may be a server or a terminal. Taking the computer device as a server as an example, its internal structure diagram may be as follows: Fig.14 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as target log identification, log collection method, log database, log gateway, log fault range, data integration processing component, log query results, real-time collection, business monitoring information, and log fault location. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a fault handling method based on multi-source log data is implemented.

[0146] Those skilled in the art will understand that Fig.14The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0147] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0148] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0149] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0150] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0151] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0152] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not 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 the present application. The above embodiments only express several implementation methods of the present application, and the description is relatively specific and detailed, but it cannot be understood as a limitation on the scope of the patent of the present application. It should be pointed out that for ordinary technicians in this field, without departing from the concept of the present application, several deformations and improvements can be made, which all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the attached claims.

Claims

1. A fault handling method based on multi-source log data, characterized in that: The method comprises: Receive a log fault processing request, and determine a target log identifier and a log collection method corresponding to the log fault processing request; According to the target log identifier, query at least one of the log database, the log gateway, and the data integration processing component to obtain a log query result, and determine the log fault scope according to the log query result; If it is determined that the log collection method is real-time collection, business monitoring information is obtained, the log fault location is determined according to the log fault range and the business monitoring information, and troubleshooting is performed based on the log fault location.

2. The method according to claim 1, characterized in that The step of querying at least one of a log database, a log gateway, and a data integration processing component according to the target log identifier to obtain a log query result includes: According to the target log identifier, query the log database; If it is determined that there is no target log data matching the target log identifier in the log database, querying a log gateway according to the target log identifier to determine a first forwarding state of the log gateway for the target log data; If the first forwarding status is that the log gateway fails to forward the target log data, a first receiving status of the log gateway for the target log data is determined, and the log query result is determined according to the first receiving status.

3. The method according to claim 2, characterized in that The method further comprises: If the first forwarding status is that the log gateway successfully forwards the target log data, querying the data integration processing component according to the target log identifier to determine the second forwarding status of the data integration processing component for the target log data; If the second forwarding status is that the data integration processing component fails to forward the target log data, a second receiving status of the target log data by the data integration processing component is determined, and a log query result is determined according to the second receiving status.

4. The method according to claim 2, characterized in that: The method further comprises: If it is determined that there is target log data matching the target log identifier in the log database, a log display query is performed on the log console according to the target log identifier to obtain a log query result.

5. The method according to any one of claims 1 to 4, characterized in that: The obtaining of the business monitoring information and determining the log fault location according to the log fault range and the business monitoring information includes: Acquire service component monitoring information corresponding to the service component, container component monitoring information corresponding to the container component, and host node monitoring information of a host node on which the container component is deployed; Determine target business monitoring information matching the log fault range from the service component monitoring information, the container component monitoring information, and the host node monitoring information; The log fault location is determined according to the log fault range and the target business monitoring information.

6. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: If it is determined that the log collection method is log collection by a log collector, obtaining a collector state corresponding to the log collector; If the collector state is a live state, determining the collector heartbeat data corresponding to the log collector; If it is determined that the log collector is in a normal operating state according to the collector heartbeat data, then the issuing state of the log collection rule is determined; According to the delivery status of the log collection rule, an operation evaluation result of the log collector is determined, so as to determine the log fault scope according to the operation evaluation result of the log collector.

7. A fault handling device based on multi-source log data, characterized in that: The device comprises: A log fault processing request receiving module, used to receive a log fault processing request, and determine a target log identifier and a log collection method corresponding to the log fault processing request; A log fault range determination module, configured to query at least one of a log database, a log gateway, and a data integration processing component according to the target log identifier, obtain a log query result, and determine a log fault range according to the log query result; The log fault location determination module is used to obtain business monitoring information if it is determined that the log collection method is real-time collection, determine the log fault location according to the log fault range and the business monitoring information, and perform troubleshooting based on the log fault location.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images