Method, device and equipment for actively collecting micro-service error logs and medium

Abstract

The invention relates to a method for actively collecting a micro-service error log, which comprises the following steps: collecting a micro-service log according to pre-configured task information, the pre-configured task information comprising a micro-service name and a log path, and the micro-service log comprising log content, a link tracking ID and log context information; filtering the micro-service log according to the filtering rule to obtain a key error log, wherein the key error log is used for representing generated important error information; filling the abnormal type, the log context and the link tracking ID analyzed based on the key error log into a structure template to generate a structured log file; and sending the structured log file to the target receiving end according to the configuration information. According to the method, a rear-end collection mode is adopted, the micro-service logs are automatically collected, developers do not need to manually log in a server or query log files, and time and energy are saved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method, device, electronic device and storage medium for actively collecting microservice error logs. Background Art

[0002] In the prior art, developers usually manage and analyze the logs generated during the operation of the system through a log query system. For example, the more commonly used log query systems such as ELK (Elasticsearch, Logstash and Kibana) have powerful log storage and query capabilities. Users can actively filter and analyze error information in the logs through the web interface provided by them, so as to locate the problem and make repairs or adjustments to ensure the normal operation of the system.

[0003] However, this active query method has certain limitations. First, programmers need to manually filter a large amount of log data, which usually takes a lot of time and effort. Especially when the system generates a large amount of logs every day, the query efficiency is difficult to meet the needs of timely processing. Secondly, some system anomalies or hidden problems may not be discovered in time, which may cause user complaints or even system failures, and have a negative impact on system stability and user experience. Therefore, there is an urgent need for a tool that can automatically collect error logs and remind developers to improve the timeliness and accuracy of problem handling. Summary of the invention

[0004] In response to the above problems, the present application proposes a method for actively collecting microservice error logs, including: collecting microservice logs according to pre-configured task information, the pre-configured task information includes the microservice name and the log path, the microservice log includes the log content, the link tracking ID and the log context information; filtering the microservice log according to the filtering rules to obtain a key error log, the key error log is used to indicate the important error information that has occurred; filling the exception type, log context and link tracking ID parsed based on the key error log into the structure template to generate a structured log file; sending the structured log file to the target receiving end according to the configuration information.

[0005] In the method described above, the filtering rules include: one or more of expected information in business logic, known and low-priority error information, and repetitive information.

[0006] As described above, the microservice log includes: generating a unique link tracking ID according to each session request; adding context information to the log generated based on the session request; and binding the log with the added context information to the link tracking ID to generate a microservice log.

[0007] As described above, when the target receiving end is an email, the method further includes: obtaining email configuration information, the email configuration information includes one or more of the sender address, the recipient address, and the carbon copy address; generating email content according to the structured log file, the email content includes: one or more of the microservice name, the log summary, and the link tracking ID; sending the email content and the structured log file to the corresponding mailbox according to the email configuration information.

[0008] As described above, when the target receiving end is a social application, the method further includes: uploading the structured log file to the target social application, obtaining a file sending ID, and the file sending ID is used to upload the upload credentials of the social application; generating a file description according to the structured log file, and the file description includes one or more of the file name, file size and log summary; sending the file sending ID and the file description to a designated chat window of the social application.

[0009] The method as described above further includes: when the interval time after the structured log file is sent to the target receiving end exceeds a time threshold, the microservice log is collected again according to the pre-configured task information, and the time threshold is 1-30 minutes.

[0010] The method as described above further comprises: when the size of the structured log file exceeds a set threshold, compressing the structured log file.

[0011] According to another aspect of the present application, a device for actively collecting microservice error logs is proposed, including: a collection module, used to collect microservice logs according to pre-configured task information, the pre-configured task information includes the microservice name and the log path, the microservice log includes the log content, the link tracking ID and the log context information; a filtering module, used to filter the microservice log according to the filtering rules to obtain a key error log, the key error log is used to indicate the important error information that has occurred; a structured file generation module, used to fill in the exception type, log context and link tracking ID parsed based on the key error log into the structure template to generate a structured log file; a sending module, used to send the structured log file to the target receiving end according to the configuration information.

[0012] According to another aspect of the present application, an electronic device is proposed, comprising a processor and a memory, wherein a computer program instruction set is stored on the memory, and when the processor executes the computer program instruction set on the memory, the method for actively collecting microservice error logs as described above is implemented.

[0013] According to another aspect of the present application, a computer-readable storage medium is provided, wherein a computer program instruction set is stored on the computer-readable storage medium, and when the computer program instruction set is executed by a processor, the method for actively collecting microservice error logs as described above is implemented.

[0014] Under the microservice architecture, a large number of logs generated by multiple services can be collected and processed automatically, which can easily cope with complex scenarios and improve log management capabilities. This method uses the back-end collection method to automatically collect microservice logs. Developers do not need to manually log in to the server or query log files, saving time and energy. Non-critical logs are eliminated through filtering rules, and only error information that is critical to troubleshooting is sent to avoid developers being disturbed by irrelevant information. Finally, the filtered critical error logs can be sent to the target receiving end specified by the developer as soon as possible, ensuring that developers can quickly receive important problem reminders and handle them in a timely manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The preferred embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, wherein:

[0016] Figure 1 It is a flow chart of a method for actively collecting microservice error logs according to an embodiment of the present application.

[0017] Figure 2 This is a flow chart of a method for generating a microservice log according to an embodiment of the present application.

[0018] Figure 3 It is a flow chart of a sending method when the target receiving end is an email according to an embodiment of the present application.

[0019] Figure 4 It is a flow chart of a sending method when the target receiving end is a social application according to an embodiment of the present application.

[0020] Figure 5 This is a working diagram of actively warning multi-microservice error logs according to an embodiment of the present application.

[0021] Figure 6 It is a schematic diagram of a configuration task information interface according to an embodiment of the present application.

[0022] Figure 7 This is a schematic diagram of a social application group chat interface according to an embodiment of the present application.

[0023] Figure 8 This is a schematic diagram of an email interface according to an embodiment of the present application.

[0024] Fig. 9It is a structural diagram of a device for actively collecting microservice error logs according to an embodiment of the present application.

[0025] Fig.10 It is a schematic diagram of the hardware structure principle of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0026] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0027] In the following detailed description, reference may be made to the various specification drawings that are part of the present application and are used to illustrate specific embodiments of the present application. In the accompanying drawings, similar reference numerals describe substantially similar components in different figures. The various specific embodiments of the present application are described below in sufficient detail so that a person of ordinary skill in the art with relevant knowledge and skills in the art can implement the technical solutions of the present application. It should be understood that other embodiments may also be used or structural, logical or electrical changes may be made to the embodiments of the present application.

[0028] Microservices in this application is a software architecture style that splits a large monolithic application into a set of small, independently deployed services. Each microservice is built around a specific business function and can be independently developed, tested, deployed, and expanded. Microservices collaborate through lightweight communication mechanisms (usually HTTP-based REST APIs).

[0029] Figure 1 1 is a flow chart of a method for actively collecting microservice error logs according to an embodiment of the present application. Figure 1 As shown, the method includes:

[0030] Step S110, collecting microservice logs according to pre-configured task information, the pre-configured task information includes the microservice name and log path, and the microservice log includes log content, link tracking ID and log context information;

[0031] Step S120, filtering the microservice log according to the filtering rule to obtain a key error log, where the key error log is used to indicate important error information that has occurred;

[0032] Step S130, filling the exception type, log context and link tracking ID parsed based on the key error log into the structure template to generate a structured log file;

[0033] Step S140, sending the structured log file to a target receiving end according to the configuration information;

[0034] Step S150: When the interval time after the structured log file is sent to the target receiving end exceeds the time threshold, step S110 is executed again.

[0035] In step 110, the microservice log is obtained according to the preconfigured task information. The preconfigured task information includes the microservice name and the log path. The log path points to the location where the microservice log is stored. The microservice log contains log content, link tracking ID, and log context information. The link tracking ID is used to identify the path of the request through different microservices, and the log context information includes relevant metadata of the request, such as request time, request parameters, etc. The link tracking ID can call the interface of other services through the feign method, and the logs of other services will also obtain the ID, thereby achieving the effect of link tracking. When a problem occurs, the link tracking ID can be used to directly locate the service and specific operation where the problem is located, thereby shortening the troubleshooting time. Especially in multi-service collaboration scenarios, the complex process of manually checking each service is avoided.

[0036] In step S120, after collecting the microservice log, the system filters the log content according to the preset filtering rules to obtain the key error log. The filtering rules include: expected information in business logic, which means the log information generated by the system according to the expected behavior, which is usually used to track normal business processes; known and low-priority error information, which means errors known to the system and have little impact on the business, which can be ignored; repetitive information, which refers to information that appears frequently in the log and is not actually helpful for troubleshooting. Through these rules, the system can filter out key error logs that are crucial to troubleshooting. Key error logs are usually directly related to system anomalies or problems. Filtering out these logs can help quickly locate the source of the problem and shorten the time for troubleshooting and solving the problem.

[0037] In step S130, the exception type, log context information and link tracking ID are parsed according to the filtered key error log, and filled into a predefined structure template to generate a structured log file. The structure template may include fields such as exception type, error information, request ID, timestamp, link tracking ID, etc. to ensure a unified log format for subsequent processing.

[0038] In step S140, the generated structured log file is sent to the target receiving end according to the pre-configured configuration information. The receiving end can be a log storage system, a monitoring platform or a troubleshooting tool, etc. The target receiving end is used to remind and further analyze and process the log data to help developers or operation and maintenance personnel to promptly discover and solve problems in the system.

[0039] In step S150, when the log is sent, the system records the current time as the end time of this log processing. Then, a time interval monitoring mechanism is started to regularly detect the time difference between the current time and the end time of the last log processing. When it is detected that the time difference exceeds the set time threshold, the next log processing process is triggered. The time threshold can be flexibly configured between 1-30 minutes. For example: in a scenario where high-frequency errors may occur, the time threshold can be set to 1-5 minutes to achieve more real-time error monitoring. In general monitoring requirements, the time threshold can be set to 10-30 minutes to balance performance and resource consumption.

[0040] Under the microservice architecture, a large number of logs generated by multiple services can be collected and processed automatically, which can easily cope with complex scenarios and improve log management capabilities. This method uses the back-end collection method to automatically collect microservice logs. Developers do not need to manually log in to the server or query log files, saving time and energy. Non-critical logs are eliminated through filtering rules, and only error information that is critical to troubleshooting is sent to avoid developers being disturbed by irrelevant information. Finally, the filtered critical error logs can be sent to the target receiver specified by the developer (such as email, message push tools or monitoring platforms) as soon as possible to ensure that developers can quickly receive important problem reminders and handle them in a timely manner.

[0041] Figure 2 FIG. 1 is a flow chart of a method for generating a microservice log according to an embodiment of the present application. Figure 2 As shown, the method includes:

[0042] Step S210, generating a unique link tracking ID according to each session request;

[0043] Step S220, adding context information to the log generated based on the session request;

[0044] Step S230: Bind the log with the context information added to the link tracking ID to generate a microservice log.

[0045] In step S210, when each session request arrives at the microservice system, the system generates a unique link tracking ID for the request. The link tracking ID is used to identify the path of a single request in the microservice architecture, from the initiation of the request to the processing of all microservices and then to the return of the response.

[0046] The link tracking ID can use UUID (Universal Unique Identifier) ​​or combine timestamp, service identifier and other information to generate a unique ID. The link tracking ID of each request will run through all log information during the request processing process, making it easier to track the request processing process and diagnose problems.

[0047] In step S220, in the logs generated based on the session request, the system associates context information with each log. The context information includes, but is not limited to, the following: request metadata: such as request timestamp, request parameters, request source IP, etc.; session status: such as user identity, session ID, authentication information, etc.; microservice identifier: the name, version number or instance identifier of the current microservice, etc. This context information helps to understand the background and context of the log, and helps developers and operation and maintenance personnel quickly understand the system status when the log is recorded.

[0048] In step S230, in the generated log entry, the link tracking ID generated in step S210 is bound to the context information added in step S220 to form a complete microservice log.

[0049] The log format usually adopts a structured method, such as JSON or XML, to ensure that each log contains a link tracking ID, context information, and log content. Binding method: When recording each log, the system uses the link tracking ID as part of the log to ensure that the ID is tightly bound to the log data of the session request. Each session request generates a unique link tracking ID, which can track the flow of requests in microservices, making it easier to trace and diagnose cross-service problems. By adding context information to the log, it can help developers and operations personnel better understand the context of the log records and improve the accuracy of problem analysis. The link tracking ID enables log information across multiple microservices to be aggregated, providing strong support for troubleshooting in distributed systems.

[0050] According to one embodiment of the present application, when the size of a structured log file exceeds a set threshold, the structured log file is compressed. The set threshold can be configured as a specific value according to system requirements, such as 5MB, 100MB or other reasonable ranges. If the length of the log content of a service exceeds the configured size threshold, the log content of the service is compressed. The compression method uses the ZIP algorithm to generate a compressed log file. Whether to compress is dynamically determined based on the size of the log content, without manual intervention, and the size of the log file is significantly reduced after compression, reducing storage and network loads.

[0051] Figure 3 1 is a flow chart of a sending method when the target receiving end is an email according to an embodiment of the present application. Figure 3 As shown, the method includes:

[0052] Step S310, obtaining mail configuration information, wherein the mail configuration information includes one or more of a sender address, a recipient address, and a carbon copy address;

[0053] Step S320, generating email content according to the structured log file, wherein the email content includes: one or more of the microservice name, the log summary, and the link tracking ID;

[0054] Step S330: Send the email content and the structured log file to the corresponding mailbox according to the email configuration information.

[0055] In step S310, the preset email configuration information is read from the configuration file or database, and the email configuration information includes: the sender address is used to identify the email address from which the email is sent, such as error-logs@company.com; the recipient address is used to identify the target email address for receiving emails, which can be a single email address or multiple email addresses; the cc address (optional) is used for additional email addresses to which the email is copied, to ensure that relevant personnel obtain information synchronously; the email server parameters include the SMTP server address, port number, identity authentication information, etc., which are used to complete email sending.

[0056] In step S320, key fields are extracted from the structured log file to generate email content, including: microservice name: identifies the service source to which the error log belongs; log summary: extracts the exception type, error code or descriptive information in the log content to provide a summary of the problem; link tracking ID: associates the call link of the request to quickly locate the specific link where the problem occurs. Then, the above key information is combined into the email body according to the preset format, and the complete structured log file is attached to the email as an attachment.

[0057] In step S330, according to the obtained email configuration information, an email object is constructed, the sender, recipient, cc address, email body and attachments are filled, and the constructed email is sent to the target receiving mailbox through the email server (SMTP protocol). The system records the sending result (success or failure). If the sending fails, a retry mechanism is triggered or an error log is recorded for subsequent investigation.

[0058] Through the above method, the automatic construction and sending of emails can be realized according to the configuration information, reducing manual intervention. In addition, multiple email configuration parameters (sender, recipient, and copy recipient) are supported to meet complex distribution needs.

[0059] Figure 4 1 is a flow chart of a sending method when the target receiving end is a social application according to an embodiment of the present application. Figure 4 As shown, the method includes:

[0060] Step S410, uploading the structured log file to the target social application, obtaining a file sending ID, where the file sending ID is used to upload the upload credentials of the social application;

[0061] Step S420, generating a file description according to the structured log file, wherein the file description includes one or more of a file name, a file size, and a log summary;

[0062] Step S430: Send the file sending ID and the file description to a designated chat window of the social application.

[0063] In step S410, the generated structured log file is uploaded to the file storage service of the social application through the upload interface provided by the social application. After the upload is successful, the social application returns a unique file sending ID (such as file-12345-abcde) as a file upload credential for subsequent sending operations.

[0064] In step S420, basic attributes of the file are extracted from the structured log file, including: file name: such as Service-A-Logs.zip, used to identify the source of the file content; file size: such as 2.5MB, used to indicate the file volume; log summary: such as 2024-09-01NullPointerException at line 45, used to summarize key information of the file content.

[0065] In step S430, the unique identifier of the target chat window (such as the webhook address or ID of the social application group chat) is obtained from the system configuration. The message content sent to the social application is constructed by combining the file sending ID and the file description. The message sending interface of the social application is called to send the above content to the target chat window.

[0066] By using the above method, error logs can be uploaded and notified to relevant personnel in a timely manner, shortening the problem response time. Key log information is provided through file description, making it easier for the recipient to quickly understand the problem content.

[0067] The above describes the implementation methods and advantages of the embodiments of the present application through multiple embodiments. The following describes the specific processing process of the embodiments of the present application in detail with reference to specific examples.

[0068] Figure 5 This is a schematic diagram of the work of actively warning multiple microservice error logs according to an embodiment of the present application. Figure 5As shown, the tool for actively collecting microservice logs in this application can be the XXL-JOB task plug-in. This application can monitor and warn in a distributed multi-microservice architecture in the form of a plug-in. It has the advantages of small file size, light weight and easy reference. The process of collecting error logs and issuing warnings is roughly as follows:

[0069] 1. Collection of microservice logs

[0070] Figure 6 FIG. 1 is a schematic diagram of a configuration task information interface according to an embodiment of the present application. Before collecting, task information can be configured. Figure 6 As shown in the figure, the configuration task information includes: executor, which is the service module for selecting task execution. In this example, the executor is "data verification service", which means that the task will be run in this service module. Routing strategy defines the routing method of the task. In this example, "shard broadcast" is selected, indicating that the task will be distributed according to the shard strategy. Running mode is the running mode of the task. In this example, the running mode is "BEAN", which means that the task is executed in the form of Spring Bean. Blocking processing strategy defines the blocking strategy of the task. When a new trigger request is encountered when the task is not completed, choose how to handle it according to the strategy. In this example, "single machine serial" is selected, which means that the tasks are executed one by one in sequence and concurrency is not allowed. Task classification is the classification label of the task, which is used for classification management of tasks. Task description is a brief description of the task function. In this example, the description is "send error email". Cron expression is the scheduling period configuration of the task, which is defined using Cron expression. In this example, the expression is 0 / 5****?, which means that the task is triggered every 5 seconds. Task parameters are custom parameters required for task operation, which are defined in JSON format. In this example, the parameter examples are: serviceName: service name, used to identify the log source service. logPath: list of log file paths. to: list of email recipients. cc: list of email carbon copies. subject: email title. After the configuration is completed, the microservice logs will be collected according to the configuration information.

[0071] Send the scan log task to the XXL-JOB scheduling framework regularly through the task handle sendErrorLogMail in the configuration information. Read the scan range (preset configuration item) and use regular expressions to match the log text range, and splice each paragraph into a complete text. Figure 6 By referencing the exlog component, the logs from multiple spring microservices are automatically stored in the log file. The code for the scan range is as follows:

[0072] scanpath:

[0073] flexible-work-miniapp-service:

[0074] - / www / logs / flexible-work-miniapp-service / error.log

[0075] flexible-work-service:

[0076] - / www / logs / flexible-work-service / error.log

[0077] seal-service:

[0078] - / www / logs / seal-service / error.log

[0079] mc-provider:

[0080] - / www / logs / mc-provider / error.log

[0081] hroopenapi-service:

[0082] - / www / logs / hroopenapi-service / error.log

[0083] 2. Log filtering

[0084] The log paragraphs are filtered according to the filtering rules. If the paragraph content meets the filtering conditions, the paragraph will not be spliced. The text paragraphs that are finally retained constitute the key error log and serve as the core data for subsequent processing. The code of the filtering rules is as follows:

[0085] common-filter:

[0086] om.xxl.job.core.util.XxlJobRemotingUtil.postBody

[0087] Connection reset by peer

[0088] xxl-job provider netty http server caught exception

[0089] Hellocontroller

[0090] unexpected decrypt error

[0091] Transaction is still being processed

[0092] 3. Generation of structured log files

[0093] The system stores the log information of each service in a Map object, where the service name is the key and the log content is the value. The length of the log content is counted. If the length of the log content of a service exceeds the threshold of the configuration item errorlog.logscaner.size-to-zip, it is compressed by ZIP. The compressed log file generates a structured format for subsequent distribution.

[0094] 4. Sending logs

[0095] There are generally two ways to send warnings for error logs: one is to send them through social applications (corporate WeChat), and the other is to send them through email.

[0096] When the target receiving end is an enterprise social application:

[0097] The system reads the configuration of enterprise social networking (such as enterprise WeChat robot) and calls the file-uploader interface to upload log files.

[0098] After successful upload, the WeChat interface returns a unique file ID.

[0099] Call the webhook address and send the file and file title to the specified WeChat group chat through the enterprise WeChat robot. The WeChat group chat interface is as follows: Figure 7 shown.

[0100] When the destination is email:

[0101] Read the email sending configuration, including the sender (from), recipient (to), carbon copy (cc), and email title (subject).

[0102] Configure email sending items for the log content of each microservice separately.

[0103] Send the log content to the corresponding mailbox, and the content interface received by the email Figure 8 shown.

[0104] Through the above method, efficient collection and analysis of microservice logs, accurate extraction of key error logs, and multi-terminal distribution of log files can be achieved. The system effectively reduces the labor cost of log management and improves operation and maintenance efficiency.

[0105] Fig. 9 1 is a schematic diagram of the structure of a device for actively collecting microservice error logs according to an embodiment of the present application. Fig. 9 As shown, the device 100 includes:

[0106] A collection module 110 is used to collect microservice logs according to pre-configured task information, where the pre-configured task information includes a microservice name and a log path, and the microservice log includes log content, a link tracking ID, and log context information;

[0107] A filtering module 120 is used to filter the microservice log according to the filtering rules to obtain a key error log, where the key error log is used to indicate important error information that has occurred;

[0108] The structured file generation module 130 is used to fill in the exception type, log context and link tracking ID parsed based on the key error log into the structure template to generate a structured log file;

[0109] The sending module 140 is used to send the structured log file to a target receiving end according to the configuration information.

[0110] Fig.10 6 is a schematic diagram of the hardware structure principle of an electronic device according to an embodiment of the present invention. The electronic device can be implemented as a server or other terminal devices, such as a desktop personal computer, a tablet computer, a laptop computer, a mobile phone, etc., including a processor 601 and a memory 602. The memory 602 stores a program instruction set. When the processor 601 executes the program instruction set on the memory 602, any of the aforementioned methods for actively collecting microservice error logs is implemented.

[0111] Specifically, the processor 601 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiment of the present invention.

[0112] The memory 602 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 602 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, the memory 602 may include a removable or non-removable (or fixed) medium. In appropriate cases, the memory 602 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 602 is a non-volatile solid-state memory.

[0113] The memory may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical or other physical / tangible memory storage device. Therefore, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the recommendation information generation method provided by the present invention.

[0114] In one example, the electronic device may further include a communication interface 603 and a bus 604. The processor 601, the memory 602, and the communication interface 603 are connected via the bus 604 and communicate with each other.

[0115] The communication interface 603 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiment of the present invention.

[0116] Bus 604 includes hardware, software or both, and the components of online data flow billing equipment are coupled to each other. For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 604 may include one or more buses. Although the embodiment of the present invention describes and shows a specific bus, the present invention considers any suitable bus or interconnection.

[0117] The present invention also provides a computer-readable storage medium having computer program instructions stored thereon, and the computer program instructions can be executed by a processor to implement any of the methods for actively collecting microservice error logs in the aforementioned embodiments. The computer-readable storage medium can be any medium that can tangibly contain or store computer-executable instructions for use by or in combination with instruction execution systems, devices and equipment. The storage medium can be a transient computer-readable storage medium or a non-transient computer-readable storage medium. Non-transient computer-readable storage media may include, but are not limited to, magnetic storage devices, optical storage devices and / or semiconductor storage devices. Embodiments corresponding to such storage devices include, for example, magnetic disks, optical disks based on CD, DVD or Blu-ray technology, and persistent solid-state memories such as flash memory, solid-state drives, and the like.

[0118] The present invention also provides a computer program product, which includes a set of computer program instructions, and when the computer program instruction set is executed by a processor, it implements any of the methods for actively collecting microservice error logs in the aforementioned embodiments. The computer program product includes but is not limited to application installation packages published on websites and application stores, application plug-ins, and small programs that can be run in certain applications.

[0119] It should be clear that the present invention is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present invention.

[0120] The above embodiments are only used to illustrate the present invention, but not to limit the present invention. Ordinary technicians in the relevant technical field can make various changes and modifications without departing from the scope of the present invention. Therefore, all equivalent technical solutions should also fall within the scope of the present invention.

Claims

1. A method for actively collecting microservice error logs, characterized in that: include: Collect microservice logs according to pre-configured task information, where the pre-configured task information includes the microservice name and log path, and the microservice log includes log content, link tracking ID, and log context information; Filter the microservice log according to the filtering rules to obtain a key error log, where the key error log is used to indicate important error information that has occurred; Fill the exception type, log context and link tracking ID parsed from the key error log into the structure template to generate a structured log file; The structured log file is sent to a target receiving end according to the configuration information.

2. The method according to claim 1, characterized in that The filtering rules include: one or more of expected information in business logic, known and low-priority error information, and repetitive information.

3. The method according to claim 1, characterized in that The microservice log includes: Generate a unique link tracking ID for each session request; Add context information to the logs generated based on session requests; Bind the log with context information added to the link tracking ID to generate a microservice log.

4. The method according to claim 1, characterized in that: When the target receiving end is an email, the method further comprises: Acquire email configuration information, where the email configuration information includes one or more of a sender address, a recipient address, and a carbon copy address; Generate email content according to the structured log file, where the email content includes: one or more of a microservice name, a log summary, and a link tracking ID; Send email content and structured log files to the corresponding mailbox according to the email configuration information.

5. The method according to claim 1, characterized in that When the target receiving end is a social application, the method further includes: Upload the structured log file to the target social application and obtain a file sending ID, where the file sending ID is used to upload the upload credentials of the social application; Generate a file description according to the structured log file, wherein the file description includes one or more of a file name, a file size, and a log summary; The file sending ID and file description are sent to a specified chat window of the social application.

6. The method according to claim 1, characterized in that Further including: When the interval time after the structured log file is sent to the target receiving end exceeds the time threshold, the microservice log is collected again according to the pre-configured task information, and the time threshold is 1-30 minutes.

7. The method according to claim 1, characterized in that Further including: When the size of a structured log file exceeds a set threshold, the structured log file is compressed.

8. A device for actively collecting microservice error logs, characterized in that: include: A collection module is used to collect microservice logs according to pre-configured task information, where the pre-configured task information includes the microservice name and log path, and the microservice log includes log content, link tracking ID and log context information; A filtering module, used to filter the microservice log according to the filtering rules to obtain a key error log, where the key error log is used to indicate important error information that has occurred; A structured file generation module is used to fill in the exception type, log context and link tracking ID parsed based on the key error log into the structure template to generate a structured log file; The sending module is used to send the structured log file to the target receiving end according to the configuration information.

9. An electronic device, characterized in that: It includes a processor and a memory, wherein a computer program instruction set is stored in the memory, and when the processor executes the computer program instruction set in the memory, the method for actively collecting microservice error logs described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program instruction set, and when the computer program instruction set is executed by the processor, the method for actively collecting microservice error logs according to any one of claims 1 to 7 is implemented.

Images