Log output control method and device
By obtaining and generating the output request identifier of custom log output parameters and encapsulating it in the request header, dynamically controlling the log output, the problem of manual operation of log-level modification in the prior art is solved, and fine control of log output and optimization of system performance is achieved.
Patent Information
- Application Number
- CN202411541968.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-31
- Publication Date
- 2025-03-14
AI Technical Summary
Modification of service log level in the prior art usually requires manual operation, resulting in a surge in log volume, which in turn affects system performance and even leads to system downtime or service fake death.
By obtaining the custom log output parameters of the target service, including range parameters and level parameters, an output request identifier is generated, and encapsulated in the request header of the target service to dynamically control the log output.
It realizes fine control of log output, avoids the impact of a large number of log output on system performance, optimizes system performance, and improves the efficiency of problem diagnosis.
Smart Images
Figure CN119621500A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of log management, and in particular to a log output control method and device. Background Art
[0002] With the popularization and development of cloud computing, big data, and microservice architecture, system logs, as the core data source for recording system operation status, monitoring business processes, and assisting fault diagnosis, are crucial for quickly locating and resolving service problems.
[0003] At present, in the prior art, the modification of service log levels usually requires manual operations, such as modifying configuration files or using the service's built-in log level modification interface. However, the above methods can usually only modify the service's log level globally, which will cause a surge in log volume, leading to a decrease in system performance, and in extreme cases, it will cause system downtime or service pseudo-death. Summary of the invention
[0004] In view of the above problems, the present application provides a log output control method and device, the main purpose of which is to dynamically control log output to ensure system performance balance.
[0005] In order to solve the above technical problems, this application proposes the following solutions:
[0006] In a first aspect, the present application provides a log output control method, the method comprising:
[0007] Obtaining the custom log output parameters of the target business, wherein the custom log output parameters include a range parameter and a level parameter, wherein the range parameter is used to limit the service scope of the output log, and the level parameter is used to limit the detail level of the output log;
[0008] Generate an output request identifier corresponding to the target service based on the range parameter and the level parameter;
[0009] The output request identifier is encapsulated in a request header corresponding to the target business, so that a designated service in the target business outputs a corresponding log at a designated level during request processing.
[0010] In a second aspect, the present application provides a log output control device, the device comprising:
[0011] An acquisition unit, used to acquire a custom log output parameter of a target business, wherein the custom log output parameter includes a range parameter and a level parameter, wherein the range parameter is used to limit a service scope of the output log, and the level parameter is used to limit a detail level of the output log;
[0012] A generating unit, configured to generate an output request identifier corresponding to the target service based on the range parameter and the level parameter obtained by the acquiring unit;
[0013] The processing unit is used to encapsulate the output request identifier obtained by the generating unit in a request header corresponding to the target business, so that the specified service in the target business outputs the corresponding log at a specified level during the request processing.
[0014] In order to achieve the above-mentioned purpose, according to the third aspect of the present application, a storage medium is provided, wherein the storage medium includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the log output control method of the above-mentioned first aspect.
[0015] In order to achieve the above-mentioned purpose, according to a fourth aspect of the present application, a processor is provided, wherein the processor is used to run a program, wherein the log output control method of the above-mentioned first aspect is executed when the program is running.
[0016] By means of the above technical scheme, a log output control method and device provided by the present application is that when it is necessary to control the output of the log, the custom log output parameters of the target business are first obtained, and the custom log output parameters include a range parameter and a level parameter. The range parameter is used to limit the service scope of the output log, and the level parameter is used to limit the detail of the output log. Then, the output request identifier corresponding to the target business is generated based on the range parameter and the level parameter, and finally the output request identifier is encapsulated in the request header corresponding to the target business, so that the specified service in the target business outputs the corresponding log at a specified level during the request processing. Through the technical scheme provided by the present application, the output request identifier generated according to the range parameter and the level parameter can be used to realize fine control of the log output, making the log management more flexible, and the log output can be quickly adjusted as needed, and the influence of a large number of log outputs on the system performance is avoided, and the system performance is optimized. In addition, the log output can also be controlled for certain requests, so that the problem can be quickly located through the corresponding log, and the efficiency of problem diagnosis is improved.
[0017] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present application. Also, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:
[0019] Figure 1 A flow chart of a log output control method provided by an embodiment of the present application is shown;
[0020] Figure 2 Another flow chart of a log output control method provided by an embodiment of the present application is shown;
[0021] Figure 3 A block diagram of a log output control device provided in an embodiment of the present application is shown;
[0022] Figure 4 A block diagram of another log output control device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION
[0023] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.
[0024] At present, the modification of service log level in the prior art usually requires manual operation, such as modifying the configuration file or using the log level modification interface embedded in the service. However, the above method can usually only modify the log level of the service globally, so that the service can only output logs according to the modified log level in the future. For example, in the development stage, it may be necessary to enable Debug level logs to help debugging, and the Debug level itself is the most detailed log level. If it is enabled globally, a large amount of data will be generated, which will cause a surge in the amount of logs, which will in turn lead to a decline in system performance. In extreme cases, it will also cause system downtime or service pseudo-death.
[0025] After research, the inventor found that a dynamic log output component can be set up, combined with customized log output parameters, such as customized service scope and customized log level, etc., to intelligently generate a request identifier and deploy it to the service request header corresponding to the target business, so that when the target business processes the request, the services included in the customized service scope can output logs at a customized log level. In this way, fine control of log output can be achieved, making log management more flexible, log output can be quickly adjusted as needed, and the impact of a large amount of log output on system performance is avoided, thereby optimizing system performance.
[0026] Based on the above considerations, the embodiment of the present application provides a log output control method, through which the log output can be dynamically controlled to ensure the balance of system performance. The execution subject of the embodiment of the present application can be a system component, platform or service responsible for managing and regulating the log output of the business system, such as a dynamic log output component that can be deployed in multiple different businesses. The specific execution steps are as follows: Figure 1 As shown, including 101-103.
[0027] 101. Obtain custom log output parameters of the target business.
[0028] It should be noted that in this embodiment, the target business is a business that an enterprise or organization focuses on, optimizes or expands. It can be a single clear business unit, product line, service project, or a combination of multiple related or unrelated businesses. This embodiment does not limit this.
[0029] Customized log output parameters include range parameters and level parameters. The range parameter is used to limit the service scope of the output log, and the level parameter is used to limit the detail level of the output log. The service scope refers to the services that output logs at the detail level defined by the level parameter, and since the detail levels of different log levels are different, the detail level refers to the log level at which the log is output.
[0030] Since in the microservice architecture, a business is usually composed of multiple services with different functional characteristics, and these services communicate through the network to form a complex request processing link. In this process, the request may pass through multiple services, and each service may process, modify or forward the request. The process from the beginning to the end of the request refers to the request life cycle of the target business. Therefore, the scope parameter can be set according to the request life cycle of the target business, such as setting the full link corresponding to the target business, specifying services or excluding services of specified services according to the request life cycle, or can be set according to functional characteristics, such as setting user management, order processing and other services included in the target business according to functional characteristics, which is not limited in this embodiment. The level parameters include but are not limited to Debug, Info, Warn, Error, etc., which are used to help developers and operation and maintenance personnel track the status of program execution and diagnose problems. Among them, Debug is the lowest level of log information, mainly used for debugging purposes in the development stage, and contains the most detailed execution information in the program, such as variable values, function call processes, etc. Info is a medium-level log level, which records the general situation of program operation, such as initialization information, startup completion information, etc., and is used to monitor the health status and basic operation status of the system. Warn is a warning-level log, indicating that the program can still continue to run, but there are potential problems that may cause program instability or errors in the future. Error is the highest level of log information, which specifically refers to the error-level log, indicating that a serious error has occurred and some functions of the program may not work properly. There is a clear priority order between these levels, namely Error>Warn>Info>Debug. That is, if the log level is set to Error, only Error-level logs will be recorded. If it is set to Warn, both Warn and Error-level logs will be recorded, and so on.
[0031] For example, taking the full link as an example, since the control of log output is linked to the entire process of the business request from the beginning to the end, this process is the request life cycle. The full link refers to the entire path from the client initiating the request, passing through all intermediate services, until the response is returned to the client. In other words, "full link" is actually a synonym for the entire request life cycle, which covers all stages of the request from the starting point to the end point. Therefore, when customizing "full link to enable debug-level logs", it actually means that during the entire request life cycle, no matter which services the request passes through, these services will output debug-level logs.
[0032] The scope and level parameters can be used together to determine the scope and level of log output. Log output parameters allow operation and maintenance personnel or development teams to fine-tune the scope and level of log collection through configuration files or user interfaces.
[0033] 102. Generate an output request identifier corresponding to the target business based on the range parameter and the level parameter.
[0034] Based on the log output parameters obtained in step 101, one or a group of unique output request identifiers can be generated according to the current execution context (such as the target business name, etc.), and the identifier encapsulates the output range, output level and other information of the log, which is used to indicate how the corresponding service in the target business outputs the log. It can be a string or an object, and this embodiment does not limit it. Specifically, it can be completed by an algorithm or a rule engine to ensure that each configuration update can be reflected in the identifier in real time, such as setting the change of the monitoring configuration such as a monitor, a listener or a configuration management tool, and defining a function or rule for generating an identifier in a preset identification format, the input of this function or rule is the business name, range parameter, and level parameter, and the output is an identifier in the form of a string or an object. When it is detected that the configuration has changed, the business name, range parameter and level parameter are extracted from the changed configuration, and a new output request identifier is generated according to the preset identification format.
[0035] Example based on the request lifecycle:
[0036] When the target business is brh, if the user needs to enable Debug-level logs on the entire link, the output request identifier can be: brh-debug=true, where debug=true is used to indicate that the entire link is enabled, true is the scope parameter (referring to the entire request life cycle, that is, the entire link), and debug is the level parameter; if the user needs to exclude a specified service from enabling Debug-level logs, the output request identifier can be: brh-debug-${appName}=false, where debug-${appName}=false is used to indicate that the specified service is intentionally excluded when the target business full-link log is enabled. The service {appName} enables Debug-level logs, ${appName}=false is the scope parameter (referring to excluding the request lifecycle of a certain service), and debug is the level parameter. If the user only needs to output debug logs for a specified service, the output request identifier can be brh-debug-${appName}=true, where debug-${appName}=true is used to indicate that when the full-link log of the target business is enabled, you only need to specify the service {appName} to enable Debug-level logs, ${appName}=true is the scope parameter, and debug is the level parameter.
[0037] Example based on feature:
[0038] When the target business is brh, if the user needs to enable Debug-level logs in the registration function process, the output request identifier can be brh-debug-um-register=true, where um (User Management) represents user management, register indicates the registration function, debug-um-register=true is used to indicate that Debug-level logs are enabled in the entire registration function process, um-register=true is the scope parameter, and debug is the level parameter; if the user needs to exclude a specified service as the authentication service in the registration function process of the target business brh and enable Debug-level logs, then the output request identifier can be brh debug-um-register-authService=false, where authService represents the authentication service. debug-um-register-authService=false is used to indicate that when the full-link log is enabled in the registration function process, the authentication service is deliberately excluded from enabling the Debug-level log. um-register-authService=false is the scope parameter, and debug is the level parameter. If the user needs to enable the Debug-level log for only a specified service as the login service in the registration function process with the target business being brh, then the output request identifier can be brh-debug-um-register-login=true, where login is the login service. debug-um-register-login=true is used to indicate that when the full-link log is enabled in the registration function process, only the login service needs to enable the Debug-level log. um-register-login=true is the scope parameter, and debug is the level parameter.
[0039] 103. Encapsulate the output request identifier in a request header corresponding to the target business, so that the specified service in the target business outputs the corresponding log at the specified level during the request processing.
[0040] It should be noted that the designated service is one or more services corresponding to the range parameter, and the designated level is the log level corresponding to the level parameter. Since the output request identifier contains information such as the output range and output level of the log, in this step, the designated service and the designated level can be determined by identifying this information. After determining the designated service and the designated level, when receiving a request initiated by the client to the target business, the dynamic log output component can dynamically add the output request identifier to the request header during the target business processing request, so that the designated service outputs the corresponding log at the specified level.
[0041] Specifically, multiple custom fields can be set in advance in the request header of the target business, such as custom fields corresponding to the service scope, custom fields corresponding to the log level, etc. The custom fields are used to insert the specified service and the specified level corresponding to the output request identifier, and the key-value pairs to be added are generated by taking the scope parameter as the specified service and the level parameter as the specified level, and the key-value pairs are added to the custom fields in the request header, thereby encapsulating a new request header containing the specified service and the specified level. Subsequently, according to the service link corresponding to the target business set according to the request life cycle, the request including the request header passes through the services included in the service link in sequence. When the request passes through any service, the service can determine whether it is the specified service encapsulated in the request header based on the information in the request header. If so, the service performs log output control at the specified level in the request header. If not, this control process is ignored.
[0042] For example,
[0043] Assume, business name: brh;
[0044] scope parameter:orderService;
[0045] Level parameter: debug.
[0046] Then, the corresponding output request identifier is:
[0047] brh-debug-${orderService}=true.
[0048] By identifying the output request identifier, we can know that:
[0049] Specify the service as orderService and the level as debug.
[0050] The key-value pairs generated based on the specified service and the specified level are:
[0051] X-Log-Level: debug;
[0052] X-Log-Scope:orderService.
[0053] Encapsulate X-Log-Level: debug and X-Log-Scope: orderService in the request header corresponding to the brh service (e.g., Host: api.example.com; Content-Type: application / json; User-Agent: MyApp / 1.0) to obtain a new request header containing the specified service and the specified level (e.g., Host: api.example.com; Content-Type: application / json; User-Agent: MyApp / 1.0; X-Log-Level: debug; X-Log-Scope: orderService).
[0054] When the target business processes the request, orderService receives the request and reads the request header to obtain X-Log-Scope:orderService (matches the current service, executes); X-Log-Level:debug (matches the current service, executes). At this time, orderService records all logs at the debug level. When other services (such as authService and userService) receive the request, they read the request header to obtain X-Log-Scope:orderService (does not match the current service, ignores); X-Log-Level:debug (does not match the current service, ignores), and these services will not change their log levels due to this request identifier. It should be understood that in addition to using a certain service as the service scope and debug as the log level as mentioned above, this example can also use the entire link or exclude a certain service as the service scope or use any one of info, warn and error as the log level, and execute the above steps.
[0055] In addition, the dynamic log output component can also embed the generated output request identifier into the logging logic of the target business system, such as through the framework level (such as Spring Boot's AOP aspect-oriented programming), middleware (such as API gateway) or container configuration (such as Docker, Kubernetes annotations) to achieve that when the business service processes the request, the corresponding level of log is automatically output according to the configuration in the identifier. Taking Spring Boot's AOP aspect-oriented programming as an example, a facet class can be created to intercept requests and process log configurations, extract the output request identifier in the request header in the facet, and dynamically configure the scope and level of the log according to the information in the output request identifier. Taking the API gateway as an example, the scope and level of the log can be dynamically configured by the output request identifier before the request enters the business system, which can be achieved by using gateways such as Spring CloudGateway or Zuul. Taking Docker and Kubernetes as examples, environment variables or annotations can be set in Docker and Kubernetes with the output request identifier, and the log configuration information can be passed through the environment variables or annotations, so that the scope and level of the log can be dynamically configured when starting Docker and Kubernetes.
[0056] Based on the above Figure 1 It can be seen from the implementation method that a log output control method provided by the present application is that when the log output control is needed, the log output parameters customized for the target business are first obtained, and the log output parameters include range parameters and level parameters. The range parameters are used to limit the service scope of the output log, and the level parameters are used to limit the detail of the output log. Then, the output request identifier corresponding to the target business is generated based on the range parameters and the level parameters, and finally the output request identifier is deployed in the target business, so that the specified service in the target business outputs the corresponding log at the specified level during the request processing. Through the technical solution provided by the present application, the output request identifier generated according to the range parameters and the level parameters can be used to achieve fine control of the log output, making the log management more flexible, and the log output can be quickly adjusted as needed, and the influence of a large number of log outputs on the system performance is avoided, and the system performance is optimized. In addition, the log output can also be controlled for certain requests, so that the problem can be quickly located through the corresponding log, and the efficiency of problem diagnosis is improved.
[0057] like Figure 2 As shown, some embodiments of the present application are in the above Figure 1 Based on the above, a detailed description of the process of log output control is given, and its specific steps include at least 201-206.
[0058] 201. Obtain log output parameters customized for the target business.
[0059] This step is combined with the description of step 101 in the above method, and the same content is not repeated here. It should be noted that in this step, the log output parameter includes not only the range parameter and the level parameter, but also the filter parameter, which is used to limit the filter condition of the output log, and is used to help developers or operation and maintenance personnel to filter out the log information that matches the filter condition. It can be specifically a file prefix (such as logs / api / , only outputting the log file containing this prefix), a time range (such as last hour or today, only outputting the log within a specific time range), an error type (such as only outputting the log with HTTP status code 404), a user session (such as only outputting the log with user ID 123) or a service module (such as only outputting the log of the com.example.order service module), etc., and this is not limited in this embodiment. And the filter parameter, as a kind of log output parameter, can also allow the operation and maintenance personnel or the development team to perform fine settings through the configuration file or provide a user interface.
[0060] In order to improve the flexibility and convenience of obtaining log output parameters, the specific execution process for obtaining log output parameters customized for the target business is: obtain the target service range selected by the user from at least one preset service range as a range parameter; obtain the target log level selected by the user from at least one preset log level as a level parameter; obtain the target filtering rule selected by the user from at least one preset filtering rule as a filtering parameter.
[0061] Among them, the preset service scope is pre-customized and configured based on the user's service monitoring requirements for the target business. Service monitoring requirements refer to the need to monitor one or more services in real time or regularly to ensure the normal operation of each service in the target business, so as to timely discover and solve potential problems. In the microservice architecture, a business is usually composed of multiple services with different functional characteristics, and these services communicate through the network to form a complex request processing link. In this process, the request may pass through multiple services, and each service may process, modify or forward the request. This process from the beginning to the end of the request refers to the request life cycle of the target business. Therefore, the scope parameter can be set according to the request life cycle of the target business, such as setting the full link corresponding to the target business, specifying services, or excluding services of specified services according to the request life cycle, or it can be set according to functional characteristics, such as setting the user management, order processing and other services included in the target business according to functional characteristics. Specifically, a series of service scope templates covering common service categories in the target business can be predefined by system administrators or advanced users, such as API Gateway, User Authentication, etc. Each service scope template describes one or a group of related services, and users can select the applicable service scope according to their own needs.
[0062] The preset log levels include at least four common log level options, namely, Debug, Info, Warn, and Error. For example, if errors frequently occur in a service, the user can set the log level of the service to Debug after selecting the service as the scope parameter to locate the problem.
[0063] Preset filtering rules are pre-configured filtering / screening logic based on the user's log location requirements for the target business. Log location requirements refer to the need to quickly find the root cause of the problem through log information within the selected service scope. Through the preset filtering rules, the log information corresponding to the log location requirements can be quickly located. The preset filtering rules can be file prefixes, time ranges, error types, user sessions or service modules as described above. Similarly, a series of filtering rule templates covering common service categories in the target business can be pre-defined by the system administrator or advanced users, such as excluding access logs of a certain IP address, transaction logs recording successful / failed payments, log records containing keywords, etc. Based on the above customization of scope parameters, level parameters and filtering parameters, an intuitive user interface can be pre-set when selecting, allowing users to easily select the required service scope by checking, dragging, etc. The interface can also pre-configure a brief description of each service scope, applicable scenarios and recommended log levels so that users can make appropriate choices. Similarly, each log level can also be pre-set with clear definition instructions to guide users to make choices based on the importance and detail of the log.
[0064] 202. Obtain a preset identification format of the target business.
[0065] In this step, the preset identification format can be pre-customized according to the management specifications of different businesses, such as creating one or more configurable identification format templates, and maintaining a correspondence table between business names and identification format templates to determine by looking up the table.
[0066] The logo format template can be a dynamic parameterized format:
[0067] For example, brh-debug-${appName}-file-prefix-${prefix}=true / false;
[0068] It can also be a composite structured format:
[0069] For example, brh-debug-${appName}-file-prefix-${prefix}=true / false;
[0070] It can also be a conditional expression format:
[0071] For example, brh-debug-${appName}-if(file-prefix-${prefix})=true / false.
[0072] Among them, ${appName} is used as a placeholder. After the corresponding service name is automatically obtained, its corresponding service name is inserted. ${appName} is the range parameter to refer to the service scope of the output log. debug is the level parameter to indicate whether to enable debug level logs. file-prefix-${prefix} (file prefix) is the filter parameter to indicate which file prefix logs the service scope outputs. The filter parameter can also replace or add time-range-${range} (time range), error-type-${type} (error type), user-session-${userId} (user session), service-module-${module} (service module), etc.
[0073] In order to ensure the configuration flexibility and adaptability of the identification format, another user interface or API dynamic configuration may be pre-set to update or add or delete the identification format.
[0074] 203. Process the filter parameter, the range parameter, and the level parameter according to the identification format to obtain an output request identification.
[0075] In this step, the parameter values of the filter parameter, the range parameter and the level parameter can be extracted in advance, and then the parameter values are converted into the format required by the identification format in the above step 202, such as converting the service range and the log level into specified fields. Then, according to the preset format template, the processed parameter values are filled in to form a complete output request identification.
[0076] 204. Determine whether the target service is in a traffic peak period.
[0077] In this step, a standard for a peak traffic period can be predefined, such as a request volume per minute exceeding twice the average value is considered a peak period, etc. This standard can be adjusted according to actual conditions, and this application is not limited. Then, the real-time traffic data of the target business is collected through a preset monitoring tool. The monitoring tool can be Prometheus, Grafana, etc. The real-time traffic data includes but is not limited to the request volume, response time, etc. Finally, by writing a script or using the alarm function of the ready-made monitoring system, it is calculated and judged in real time whether the real-time traffic data reaches the peak standard, that is, whether the target business is in the peak traffic period. If not, it means that the impact of the target business on the system performance by log output control is small at this time, so step 205 is executed. Otherwise, the impact of the target business on the system performance by log output control is large at this time, so step 206 is executed.
[0078] 205. Encapsulate the output request identifier in a request header corresponding to the target business, so that the specified service in the target business outputs the corresponding log at the specified level during the request processing.
[0079] This step is combined with the description of step 103 in the above method, and the same content is not repeated here. It should be noted that the specific execution process of encapsulating the output request identifier in the request header corresponding to the target business so that the specified service in the target business outputs the corresponding log at the specified level during the request processing is: determine the service scope corresponding to the scope parameter in the output request identifier, the log level corresponding to the level parameter, and the filtering rule corresponding to the filtering parameter; take the service included in the service scope as the specified service, the log level as the specified level, and the filtering rule as the output restriction, and generate the key-value pair to be added; in the process of processing the request of the target business, dynamically add the key-value pair to the preset custom field of the request header, and encapsulate the request header containing the specified service, the specified level, and the output restriction, so that the specified service outputs the corresponding log that meets the output restriction at the specified level. Since the target business has pre-set the identification format of the output request identifier that can be recognized and responded to, the obtained output request identifier contains information such as service scope, log level, and filtering rules. Therefore, in this step, the output request identifier can be directly parsed, key information such as service scope, log level, and filtering rules can be extracted, and the key-value pairs to be added are generated based on these key information. For example, X-Log-Scope:orderService; X-Log-Level:debug; X-Log-Filter:file-prefix-payment, etc. In the process of processing the request of the target business, the key-value pairs to be added based on the specified service, the specified level and the output restriction are dynamically added to the preset custom field of the request header, and the encapsulation processing is performed to obtain a new request header containing the specified service, the specified level and the output restriction. Subsequently, the service link corresponding to the target business set according to the request life cycle, including the request header, passes through the services included in the service link in sequence. When the request passes through any service, the any service can determine whether it is the specified service encapsulated in the request header based on the information in the request header. This embodiment enables the request header to be passed along with the request during the entire request life cycle of the target business and between the services included in the request life cycle.
[0080] For example,
[0081] Assume, business name: brh;
[0082] scope parameter:orderService;
[0083] Level parameter: debug;
[0084] Filter parameter: file-prefix-${prefix} (file prefix).
[0085] Then, the corresponding output request identifier is:
[0086] brh-debug-${orderService}-file-prefix-${prefix}=true.
[0087] By identifying the output request identifier, we can know that:
[0088] Specify the service as orderService, the level as debug, and the output limit as file-prefix-${prefix}.
[0089] The key-value pairs generated based on the specified service, specified level, and output restrictions are:
[0090] X-Log-Level: debug;
[0091] X-Log-Scope:orderService;
[0092] X-Log-Filter:file-prefix-payment.
[0093] Encapsulate X-Log-Level: debug, X-Log-Scope: orderService, and X-Log-Filter: file-prefix-payment in the request header corresponding to the brh service (e.g., Host: api.example.com; Content-Type: application / json; User-Agent: MyApp / 1.0), and obtain a new request header containing the specified service and the specified level (e.g., Host: api.example.com; Content-Type: application / json; User-Agent: MyApp / 1; X-Log-Level: debug; X-Log-Scope: orderService; X-Log-Filter: file-prefix-payment).
[0094] When the target business processes the request, orderService receives the request and reads the request header to obtain X-Log-Scope:orderService (matches the current service, executes); X-Log-Level:debug (matches the current service, executes); X-Log-Filter:file-prefix-payment (matches the current service, executes). At this time, orderService records logs with the file prefix payment at the debug level. When other services (such as authService and userService) receive the request, they read the request header to obtain X-Log-Scope:orderService (does not match the current service, ignores); X-Log-Level:debug (does not match the current service, ignores); file-prefix-payment (does not match the current service, ignores). It should be understood that in addition to using a certain service as a scope parameter, debug as a level parameter, and file prefix as a filter parameter as described above, this example can also choose to use the entire link or exclude a certain service as a scope parameter, use any one of info, warn, and error as a level parameter, or use any one or more of the time range, error type user session, and service module as filter parameters, and execute the above steps.
[0095] 206. After the traffic peak period, encapsulate the output request identifier in the request header corresponding to the target business according to the progressive activation rule or the delayed activation rule, so that the specified service in the target business outputs the corresponding log at the specified level during the request processing.
[0096] Due to the peak traffic period, the target business log output control has a greater impact on system performance. Therefore, in order to reduce the immediate impact on system performance and ensure a smooth transition. In this step, the output request identifier can be deployed according to the gradual activation rule or the delayed activation rule. Among them, the gradual activation rule can be to gradually enable the specified service according to the preset number or gradually start the specified service according to the preset time period, that is, to gradually increase the service scope of the output request identifier after the peak traffic period ends. For example, when the number of specified services is large, a one-minute time gradient can be set, and one or more specified services can be enabled gradually every minute. The delayed activation rule refers to enabling the specified service after setting the delay time or enabling the specified service in the specified time period, that is, setting a delay time after the peak traffic period ends, and not enabling the output request identifier during the delay time. It should be noted that both the gradual activation rule and the delayed activation rule need to be set in combination with the system performance to find the best startup logic. In addition, a new activation rule can also be set in combination with the gradual activation and delayed activation, which is not limited in this embodiment.
[0097] As the above Figure 1-2 The implementation of the method embodiment shown in the figure, the embodiment of the present application provides a log output control device, which is used to dynamically control log output to ensure the balance of system performance. The embodiment of the device corresponds to the aforementioned method embodiment. For ease of reading, this embodiment will no longer repeat the details of the aforementioned method embodiment one by one, but it should be clear that the device in this embodiment can correspond to all the contents of the aforementioned method embodiment. Figure 3 As shown, the device comprises:
[0098] An acquisition unit 31 is used to acquire a custom log output parameter of a target business, wherein the custom log output parameter includes a range parameter and a level parameter, wherein the range parameter is used to limit the service scope of the output log, and the level parameter is used to limit the detail level of the output log;
[0099] A generating unit 32, configured to generate an output request identifier corresponding to the target service based on the range parameter and the level parameter obtained by the acquiring unit 31;
[0100] The processing unit 33 is used to encapsulate the output request identifier obtained by the generating unit 32 in the request header corresponding to the target business, so that the specified service in the target business outputs the corresponding log at a specified level during the request processing.
[0101] Further, such as Figure 4 As shown, the log output parameters also include filtering parameters, and the filtering parameters are used to limit the filtering conditions of the output logs; the generating unit 32 is specifically used to:
[0102] An output request identifier corresponding to the target service is generated based on the filter parameter, the range parameter and the level parameter.
[0103] Further, such as Figure 4 As shown, the generating unit 32 includes:
[0104] The acquisition module 321 is used to acquire the identification format preset by the target service;
[0105] The first processing module 322 is used to process the filter parameter, the range parameter and the level parameter according to the identification format obtained by the acquisition module 321 to obtain the output request identification.
[0106] Further, such as Figure 4 As shown, the processing unit 33 includes:
[0107] A determination module 331, used to determine the service scope corresponding to the scope parameter in the output request identifier, the log level corresponding to the level parameter, and the filtering rule corresponding to the filtering parameter;
[0108] A generating module 332, configured to generate a key-value pair to be added by taking the service included in the service scope obtained by the determining module 331 as the designated service, taking the log level as the designated level, and taking the filtering rule as the output restriction;
[0109] The second processing module 333 is used to dynamically add the key-value pair obtained by the generation module 332 to the preset custom field of the request header during the target business processing request, and encapsulate the request header including the specified service, the specified level and the output restriction, so that the specified service outputs the corresponding log that complies with the output restriction at the specified level.
[0110] Further, such as Figure 4 As shown, the acquisition unit 31 includes:
[0111] A first acquisition module 311 is used to acquire a target service range selected by a user from at least one preset service range as a range parameter, wherein the preset service range is pre-customized and configured based on the user's service monitoring requirements for the target service;
[0112] The second acquisition module 312 is used to acquire a target log level selected by a user from at least one preset log level as a level parameter.
[0113] Further, such as Figure 4 As shown, the device also includes:
[0114] The third acquisition module 313 is used to acquire a target filtering rule selected by a user from at least one preset filtering rule as a filtering parameter, wherein the preset filtering rule is pre-customized and configured based on the user's log location requirement for the target service.
[0115] Further, such as Figure 4 As shown, the device also includes:
[0116] A judging unit 34, configured to judge whether the target service is in a traffic peak period before the processing unit 33;
[0117] The processing unit 33 is used to encapsulate the output request identifier in the request header corresponding to the target business if the judging unit 34 judges that the target business is not in the traffic peak period, so that the specified service in the target business outputs the corresponding log at the specified level during the request processing;
[0118] The processing unit 33 is also used to encapsulate the output request identifier in the request header corresponding to the target business according to the progressive activation rule or the delayed activation rule after the peak traffic period if the judgment unit 34 determines that the target business is not in the peak traffic period, so that the specified service in the target business can output the corresponding log at a specified level during the request processing process.
[0119] Furthermore, the embodiment of the present application also provides a storage medium, the storage medium is used to store a log management program, wherein when the log management program is running, the device where the storage medium is located is controlled to execute the above Figure 1-2 The log output control method described in .
[0120] Furthermore, the embodiment of the present application also provides a processor, the processor is used to run a program, wherein the program executes the above Figure 1-2 The log output control method described in .
[0121] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.
[0122] It is understandable that the related features in the above methods and devices can be referenced to each other. In addition, the "first", "second" and the like in the above embodiments are used to distinguish the embodiments, and do not represent the advantages and disadvantages of the embodiments.
[0123] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0124] The algorithms and displays provided herein are not inherently related to any specific log management, virtual system or other device. Various general systems can also be used together with the teachings based on this. According to the above description, it is obvious that the structure required for constructing such systems. In addition, the application is not directed to any specific programming language. It should be understood that the content of the application described herein can be realized using various programming languages, and the description of the specific language above is to disclose the best mode of implementation of the application.
[0125] In addition, the memory may include non-permanent memory in a log management readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one storage chip.
[0126] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or log management program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a log management program product implemented on one or more log management available storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include log management available program codes.
[0127] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and log management program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by log management program instructions. These log management program instructions can be provided to a processor of a general log management, a dedicated log management, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the log management or other programmable data processing device generate instructions for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0128] These log management program instructions can also be stored in a log management readable memory that can guide the log management or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the log management readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0129] These log management program instructions can also be loaded onto a log management or other programmable data processing device, so that a series of operating steps are executed on the log management or other programmable device to produce the processing implemented by the log management, so that the instructions executed on the log management or other programmable device provide for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.
[0130] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0131] The memory may include non-permanent memory in a log management readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a log management readable medium.
[0132] Log management readable media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. The information can be log management readable instructions, data structures, program modules or other data. Examples of log management storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, log management readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.
[0133] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.
[0134] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or log management program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a log management program product implemented on one or more log management available storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain log management available program codes.
[0135] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included within the scope of the claims of the present application.
Claims
1. A log output control method, characterized in that: The method comprises: Obtaining a custom log output parameter of the target business, wherein the custom log output parameter includes a range parameter and a level parameter, wherein the range parameter is used to limit the service scope of the output log, and the level parameter is used to limit the detail level of the output log; Generate an output request identifier corresponding to the target service based on the range parameter and the level parameter; The output request identifier is encapsulated in a request header corresponding to the target business, so that a designated service in the target business outputs a corresponding log at a designated level during request processing.
2. The method according to claim 1, characterized in that The custom log output parameter also includes a filter parameter, which is used to limit the screening conditions of the output log; generating an output request identifier corresponding to the target business based on the range parameter and the level parameter, including: An output request identifier corresponding to the target service is generated based on the filter parameter, the range parameter and the level parameter.
3. The method according to claim 2, characterized in that Generating an output request identifier corresponding to the target service based on the filter parameter, the range parameter, and the level parameter includes: Obtaining a preset identification format of the target service; The filter parameter, the range parameter and the level parameter are processed according to the identification format to obtain the output request identification.
4. The method according to claim 1, characterized in that: Encapsulating the output request identifier in a request header corresponding to the target service, so that a specified service in the target service outputs a corresponding log at a specified level during request processing, including: Determine the service scope corresponding to the scope parameter in the output request identifier, the log level corresponding to the level parameter, and the filtering rule corresponding to the filtering parameter; The services included in the service scope are taken as the designated services, the log level is taken as the designated level, and the filtering rule is taken as the output restriction, to generate a key-value pair to be added; During the target business processing request, the key-value pair is dynamically added to the preset custom field of the request header, and the request header containing the specified service, the specified level and the output restriction is encapsulated, so that the specified service outputs the corresponding log that complies with the output restriction at the specified level.
5. The method according to claim 1, characterized in that Get the custom log output parameters of the target business, including: Acquire a target service range selected by a user from at least one preset service range as a range parameter, wherein the preset service range is pre-customized and configured based on a service monitoring requirement of the user for the target service; Gets the target log level selected by the user from at least one preset log level as the level parameter.
6. The method according to claim 5, characterized in that The method further comprises: A target filtering rule selected by a user from at least one preset filtering rule is obtained as a filtering parameter, wherein the preset filtering rule is pre-customized and configured based on a log location requirement of the user for the target service.
7. The method according to any one of claims 1 to 6, characterized in that Before encapsulating the output request identifier in a request header corresponding to the target service so that a specified service in the target service outputs a corresponding log at a specified level during request processing, the method further includes: If the target service is not in a traffic peak period, encapsulate the output request identifier in a request header corresponding to the target service, so that the specified service in the target service outputs the corresponding log at a specified level during the request processing; If the target business is in a peak traffic period, the output request identifier will be encapsulated in the request header corresponding to the target business according to the progressive activation rule or the delayed activation rule after the peak traffic period, so that the specified service in the target business can output the corresponding log at a specified level during the request processing.
8. A log output control device, characterized in that: The device comprises: An acquisition unit, used to acquire a custom log output parameter of a target business, wherein the custom log output parameter includes a range parameter and a level parameter, wherein the range parameter is used to limit a service scope of the output log, and the level parameter is used to limit a detail level of the output log; A generating unit, configured to generate an output request identifier corresponding to the target service based on the range parameter and the level parameter obtained by the acquiring unit; The processing unit is used to encapsulate the output request identifier obtained by the generating unit in a request header corresponding to the target business, so that the specified service in the target business outputs the corresponding log at a specified level during the request processing.
9. A storage medium, characterized in that: The storage medium includes a stored program, wherein when the program is executed, the device where the storage medium is located is controlled to execute the log output control method according to any one of claims 1 to 7.
10. A processor, characterized in that: The processor is used to run a program, wherein the program executes the log output control method according to any one of claims 1 to 7 when running.