Log uploading method and device

Abstract

The application provides a log uploading method and device, the method comprising: multi-terminal access with an H5 terminal and an RN terminal in a business scenario; obtaining a log type set and a log template set matched with the log type set; performing standardized configuration of the multi-terminal access according to the log type set and the log template set; receiving target log data of the multi-terminal access; performing standardized processing on the target log data according to the log type set and the log template set to obtain target standardized log; and uploading the target standardized log. It can be seen that the method and device can be compatible with multiple terminals, avoid missing transmission, and thus reduce the development and maintenance cost of financial service functions.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a log uploading method and apparatus. Background Technology

[0002] Currently, with the continuous development of the internet, online financial services are becoming increasingly widespread. The financial sector can provide corresponding financial content displays via the web, such as bank service interfaces. In the web front-end community, log upload technology for React Native (RN) applications mainly focuses on how platform providers build log platforms and monitoring systems, rarely addressing how business users can integrate the platform's log upload capabilities. In practice, RN development typically involves both H5 and RN clients, and the log access methods for these two ends differ, leading to developers adding duplicate logs on both ends, essentially wasting manpower. Furthermore, the log content uploaded from both ends is often inconsistent, lacks semantic meaning, and may even be missed, increasing development and maintenance costs. Therefore, existing log upload methods are incompatible with multiple platforms, prone to omissions, and thus increase the development and maintenance costs of financial service functions. Summary of the Invention

[0003] The purpose of this application is to provide a log uploading method and apparatus that is compatible with multiple terminals, avoids missed transmissions, and thus reduces the development and maintenance costs of financial service functions.

[0004] The first aspect of this application provides a log uploading method, including:

[0005] Enables multi-platform access with H5 and RN clients in business scenarios;

[0006] Obtain the set of log types and the set of log templates that match the set of log types;

[0007] Standardized configuration for multi-terminal access is performed based on the set of log types and the set of log templates;

[0008] Receive target log data from multiple access points;

[0009] The target log data is normalized according to the set of log types and the set of log templates to obtain the target normalized log;

[0010] Upload the target normalized log.

[0011] In the above implementation process, this method can prioritize multi-terminal access through H5 and RN terminals in the business scenario; obtain a set of log types and a set of log templates matching the log type set; then, perform standardized configuration for multi-terminal access based on the log type set and log template set; next, receive target log data from multi-terminal access; finally, perform standardized processing on the target log data based on the log type set and log template set to obtain the target standardized log, and upload the target standardized log. It is evident that this method is compatible with multiple terminals, avoids missed transmissions, and thus reduces the development and maintenance costs of financial service functions.

[0012] Further, obtaining the log type set and the log template set matching the log type set includes:

[0013] Obtain raw log data from multiple access points;

[0014] The raw log data is statistically processed and categorized to obtain a set of log types;

[0015] Obtain the log template that matches each log type in the set of log types;

[0016] The log templates are aggregated to obtain a set of log templates that match the set of log types.

[0017] Furthermore, the set of log types includes at least interface input parameter logs, interface output parameter logs, interface exception logs, or interface request method error logs.

[0018] Further, the step of normalizing the target log data according to the log type set and the log template set to obtain the target normalized log includes:

[0019] The log type of the target log data is determined based on the set of log types.

[0020] Obtain the target log template that matches the log type based on the set of log types;

[0021] The target log data is normalized according to the target log template to obtain the target normalized log.

[0022] Further, the step of normalizing the target log data according to the target log template to obtain the target normalized log includes:

[0023] Extract the module name, page name, and page URL from the target log data;

[0024] Generate a target normalized log based on the module name, the page name, the page URL, and the target log template.

[0025] A second aspect of this application provides a log uploading device, the log uploading device comprising:

[0026] The access unit is used for multi-terminal access with H5 and RN terminals in business scenarios;

[0027] The acquisition unit is used to acquire a set of log types and a set of log templates that match the set of log types;

[0028] A configuration unit is used to perform standardized configuration for multi-terminal access based on the log type set and the log template set;

[0029] The receiving unit is used to receive target log data from multiple access points;

[0030] A normalization unit is used to normalize the target log data according to the log type set and the log template set to obtain the target normalized log;

[0031] The upload unit is used to upload the target normalized log.

[0032] In the above implementation process, the device can achieve multi-terminal access with H5 and RN terminals in the business scenario through the access unit; acquire a set of log types and a set of log templates matching the log type set through the acquisition unit; perform standardized configuration for multi-terminal access through the configuration unit based on the log type set and log template set; receive target log data from multi-terminal access through the receiving unit; perform standardized processing of the target log data based on the log type set and log template set through the standardization unit to obtain the target standardized log; and finally upload the target standardized log through the upload unit. It is evident that the device is compatible with multiple terminals, avoiding missed transmissions, thereby reducing the development and maintenance costs of financial service functions.

[0033] Furthermore, the acquisition unit includes:

[0034] The first acquisition subunit is used to acquire raw log data from multiple access points;

[0035] The sorting and classification subunit is used to statistically sort and classify the original log data to obtain a set of log types.

[0036] The second acquisition subunit is used to acquire a log template that matches each log type in the log type set;

[0037] The summary subunit is used to summarize the log templates to obtain a set of log templates that match the set of log types.

[0038] Furthermore, the set of log types includes at least interface input parameter logs, interface output parameter logs, interface exception logs, or interface request method error logs.

[0039] Furthermore, the normalization unit includes:

[0040] A sub-unit is defined to determine the log type of the target log data based on the log type set.

[0041] The third acquisition subunit is used to acquire a target log template that matches the log type according to the log type set;

[0042] The processing subunit is used to perform normalization processing on the target log data according to the target log template to obtain the target normalized log.

[0043] Furthermore, the processing subunit includes:

[0044] The extraction module is used to extract the module name, page name, and page URL from the target log data.

[0045] The generation module is used to generate a target normalized log based on the module name, the page name, the page URL, and the target log template.

[0046] A third aspect of this application provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor runs the computer program to cause the electronic device to perform the log uploading method described in any one of the first aspects of this application.

[0047] A fourth aspect of this application provides a computer-readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the log upload method described in any one of the first aspects of this application. Attached Figure Description

[0048] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 A flowchart illustrating a log upload method provided in an embodiment of this application;

[0050] Figure 2 A flowchart illustrating another log upload method provided in an embodiment of this application;

[0051] Figure 3 This is a schematic diagram of the structure of a log uploading device provided in an embodiment of this application;

[0052] Figure 4 This is a schematic diagram of another log uploading device provided in an embodiment of this application;

[0053] Figure 5 This is a schematic diagram of a planning and design scheme for integrating multi-terminal access, provided as an embodiment of this application. Detailed Implementation

[0054] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0055] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0056] Example 1

[0057] Please refer to Figure 1 , Figure 1 This embodiment provides a flowchart illustrating a log upload method. The log upload method includes:

[0058] S101. Enable multi-terminal access with H5 and RN terminals in business scenarios.

[0059] S102. Obtain the set of log types and the set of log templates that match the set of log types.

[0060] S103. Standardize the configuration for multi-terminal access based on the log type set and log template set.

[0061] S104. Receive target log data from multiple access points.

[0062] S105. Normalize the target log data according to the log type set and log template set to obtain the target normalized log.

[0063] S106. Upload the target normalized log.

[0064] Currently, in the financial sector, there are typically multiple platforms, including web and mobile. For example, banks often have multiple platforms, and these platforms can be integrated with other applications when deployed, enabling comprehensive operation of banking applications, banking services, and other financial projects. However, when achieving multi-platform interconnection, there are issues with log uploading technology for React Native applications from the web frontend. The focus is mainly on how the platform builds its log platform and monitoring system, with little attention paid to how business users can integrate the platform's log uploading capabilities. Specifically, many React Native development teams in the financial sector face the following three main issues when integrating logs:

[0065] (1) RN development generally involves H5 and RN, and the log access methods of these two ends are different, which leads to developers adding duplicate logs on both ends, which is equivalent to repeatedly consuming manpower.

[0066] (2) The log upload scenario is mainly concentrated in the interface request scenario, but the interface request scenario involves 6 aspects: problems with interface request parameter processing, problems with interface request output parameter processing, interface request encountering httperror, interface request output parameter returning business exceptions (such as responseCode != 0, not logged in is not an exception scenario filtering, note this httpcode=502, 404 error), and interface request method error.

[0067] (3) The uploaded log content is not standardized, lacks semantic meaning, or is even omitted, making it difficult to understand. This is mainly because the development capabilities vary widely. Many projects have difficulty obtaining log content and also involve a lot of non-business logic processing, making it difficult for developers to decide what to accept and what to discard from the uploaded log content.

[0068] To address the aforementioned issues, this application provides a multi-platform, low-cost, semantic log access solution for React Native (RN), enabling its application in the financial sector to achieve easy multi-platform log access. The methods involve technologies such as RN, Node.js, and JavaScript.

[0069] In this embodiment, the subject executing the method can be a computing device such as a computer or server, and no limitation is made in this embodiment.

[0070] In this embodiment, the subject executing the method can also be a smart device such as a smartphone or tablet, and no limitation is made in this embodiment.

[0071] As can be seen, implementing the log upload method described in this embodiment can provide some assistance to developers in solving related problems during the testing phase. At the same time, it also provides favorable support for locating production problems, determining which emergency plans to use, and customizing customer service responses.

[0072] Example 2

[0073] Please refer to Figure 2 , Figure 2 This embodiment provides a flowchart illustrating a log upload method. The log upload method includes:

[0074] S201. Enable multi-terminal access with H5 and RN terminals in business scenarios.

[0075] S202. Obtain raw log data from multiple access points.

[0076] S203. Perform statistical analysis, sorting, and classification on the raw log data to obtain a set of log types.

[0077] In this embodiment, the log type set includes at least interface input parameter logs, interface output parameter logs, interface exception logs, or interface request method error logs.

[0078] In this embodiment, the method can statistically organize and classify business scenarios, specifically including:

[0079] (1) Interface input parameter log. Traditional interface errors are highly likely to be due to input parameter problems. With input parameter logs, it is easy to quickly identify whether the interface error comes from the front end or the back end during production troubleshooting.

[0080] (2) Interface output parameter logs. When the main page is rendered successfully but the content displayed is different from the expected one, it is often because there is a problem in the parsing of the output parameters, such as missing an attribute, or the corresponding value content being inconsistent with the expectation. For such production problems, backup measures can be quickly activated to avoid risks for production users without changing the code.

[0081] (3) Interface exception logs (distinguishing between regular HTTP request error types such as 502, 404, 400, etc.). Interface exceptions are special error types, and necessary logs can facilitate communication and coordination among developers to handle such issues, thereby achieving the goal of rapid response in production error troubleshooting.

[0082] (4) Error logs for API request methods (GET / POST). These errors are relatively special and generally occur during the development and testing phases. They can help developers quickly locate the root cause of the problem and save development costs.

[0083] S204. Retrieve the log template that matches each log type in the log type set.

[0084] S205. Summarize the log templates to obtain a set of log templates that match the set of log types.

[0085] S206. Standardize the configuration for multi-terminal access based on the log type set and log template set.

[0086] S207. Receive target log data from multiple access points.

[0087] S208. Determine the log type of the target log data based on the log type set.

[0088] S209. Obtain the target log template that matches the log type based on the log type set.

[0089] In this embodiment, the format of the general log content specification is as follows:

[0090] [${module name}-${page name}-${scene name},${supplementary information},page path];

[0091] This is the specification for all log templates. The following sections, such as "Network Anomaly Backup Scenarios" and "API Anomaly Scenarios," are subdivisions of this template.

[0092] In this embodiment, the format of the log template for the network anomaly fallback scenario is as follows:

[0093] [${module name}-${page name}-${specific network error}, page path].

[0094] In this embodiment, regarding the interface exception scenario log template:

[0095] (1) The format for handling exceptions in the interface input parameters is as follows:

[0096] [${module name}-${page name}-${interface name},interface parameter processing exception,interface path,interface parameters, reason, page path].

[0097] (2) The format of the HTTPCode exception in the API output parameter is as follows:

[0098] [${module name}-${page name}-${interface name}, interface output parameter HTTPCode exception, interface path, interface input parameters, interface output parameters (including HTTPCode), page path].

[0099] (3) The format of the interface output parameter code! = 000000 is as follows:

[0100] [${module name}-${page name}-${interface name}, interface output parameter code! = 000000, interface path, interface input parameters, interface output parameters (including httpCode), page path].

[0101] S210. Extract the module name, page name, and page URL from the target log data.

[0102] S211. Generate target normalized logs based on module name, page name, page URL, and target log template.

[0103] S212. Upload the target normalized log.

[0104] Please refer to Figure 5 , Figure 5 The planning and design scheme for integrating multi-terminal access is shown.

[0105] As can be seen, this method can be used in the financial field, specifically in all multi-terminal access scenarios related to logs within the financial sector. These scenarios include, but are not limited to, banking scenarios and business application scenarios.

[0106] In this embodiment, the subject executing the method can be a computing device such as a computer or server, and no limitation is made in this embodiment.

[0107] In this embodiment, the subject executing the method can also be a smart device such as a smartphone or tablet, and no limitation is made in this embodiment.

[0108] As can be seen, implementing the log upload method described in this embodiment can provide some assistance to developers in solving related problems during the testing phase. At the same time, it also provides favorable support for locating production problems, determining which emergency plans to use, and customizing customer service responses.

[0109] Example 3

[0110] Please refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of a log upload device provided in this embodiment. Figure 3 As shown, the log upload device includes:

[0111] Access unit 310 is used for multi-terminal access with H5 terminal and RN terminal in business scenarios;

[0112] The acquisition unit 320 is used to acquire a set of log types and a set of log templates that match the set of log types;

[0113] Configuration unit 330 is used for standardized configuration of multi-terminal access based on the log type set and log template set;

[0114] The receiving unit 340 is used to receive target log data from multiple access points;

[0115] Normalization unit 350 is used to normalize the target log data according to the log type set and the log template set to obtain the target normalized log;

[0116] The upload unit 360 is used to upload target normalized logs.

[0117] In this embodiment, the explanation of the log upload device can be found in the description in Embodiment 1 or Embodiment 2, and will not be repeated here.

[0118] As can be seen, implementing the log upload device described in this embodiment can provide certain assistance to developers in solving related problems during the testing phase. Simultaneously, it also provides favorable support for locating production problems, determining which emergency response plans to employ, and customizing customer service scripts.

[0119] Example 4

[0120] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of a log upload device provided in this embodiment. Figure 4 As shown, the log upload device includes:

[0121] Access unit 310 is used for multi-terminal access with H5 terminal and RN terminal in business scenarios;

[0122] The acquisition unit 320 is used to acquire a set of log types and a set of log templates that match the set of log types;

[0123] Configuration unit 330 is used for standardized configuration of multi-terminal access based on the log type set and log template set;

[0124] The receiving unit 340 is used to receive target log data from multiple access points;

[0125] Normalization unit 350 is used to normalize the target log data according to the log type set and the log template set to obtain the target normalized log;

[0126] The upload unit 360 is used to upload target normalized logs.

[0127] As an optional implementation, the acquisition unit 320 includes:

[0128] The first acquisition subunit 321 is used to acquire raw log data from multiple access points;

[0129] The sorting and classification subunit 322 is used to statistically sort and classify the raw log data to obtain a set of log types.

[0130] The second acquisition subunit 323 is used to acquire a log template that matches each log type in the log type set;

[0131] The summary sub-unit 324 is used to summarize log templates and obtain a set of log templates that match the set of log types.

[0132] In this embodiment, the log type set includes at least interface input parameter logs, interface output parameter logs, interface exception logs, or interface request method error logs.

[0133] As an optional implementation, the normalization unit 350 includes:

[0134] Determine subunit 351, which is used to determine the log type of the target log data based on the log type set;

[0135] The third acquisition subunit 352 is used to acquire a target log template that matches the log type based on the log type set;

[0136] Processing subunit 353 is used to normalize the target log data according to the target log template to obtain the target normalized log.

[0137] As an optional implementation, the processing subunit 353 includes:

[0138] The extraction module is used to extract the module name, page name, and page URL from the target log data.

[0139] The generation module is used to generate target normalized logs based on the module name, page name, page URL, and target log template.

[0140] In this embodiment, the explanation of the log upload device can be found in the description in Embodiment 1 or Embodiment 2, and will not be repeated here.

[0141] As can be seen, implementing the log upload device described in this embodiment can provide certain assistance to developers in solving related problems during the testing phase. Simultaneously, it also provides favorable support for locating production problems, determining which emergency response plans to employ, and customizing customer service scripts.

[0142] This application provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor runs the computer program to enable the electronic device to perform the log upload method in embodiment 1 or embodiment 2 of this application.

[0143] This application provides a computer-readable storage medium storing computer program instructions. When the computer program instructions are read and executed by a processor, the log upload method in embodiment 1 or embodiment 2 of this application is performed.

[0144] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0145] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0146] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0147] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0148] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0149] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A log upload method, characterized in that, include: Enables multi-platform access with H5 and RN clients in business scenarios; Obtain the set of log types and the set of log templates that match the set of log types; Standardized configuration for multi-terminal access is performed based on the log type set and the log template set; the standardized configuration includes: configuring global variables containing module name, page URL, and page name for H5 terminal, and configuring global variables containing module name, page URL, and page name for RN terminal; Receive target log data from multiple access points; The target log data is normalized according to the set of log types and the set of log templates to obtain the target normalized log; Upload the target normalized log; The target normalized log is generated based on the module name, page name, page URL, and target log template. The module name, the page name, and the page URL are extracted from the target log data; The target log template is matched with the log type of the target log data, and the log type is determined based on a set of log types.

2. The log upload method according to claim 1, characterized in that, The process of obtaining the log type set and the log template set matching the log type set includes: Obtain raw log data from multiple access points; The raw log data is statistically processed and categorized to obtain a set of log types; Obtain the log template that matches each log type in the set of log types; The log templates are aggregated to obtain a set of log templates that match the set of log types.

3. The log upload method according to claim 2, characterized in that, The set of log types includes at least one of the following: interface input parameter log, interface output parameter log, interface exception log, and interface request method error log.

4. The log upload method according to claim 1, characterized in that, The step of normalizing the target log data according to the log type set and the log template set to obtain the target normalized log includes: The log type of the target log data is determined based on the set of log types. Obtain the target log template that matches the log type based on the set of log types; The target log data is normalized according to the target log template to obtain the target normalized log.

5. The log upload method according to claim 4, characterized in that, The step of normalizing the target log data according to the target log template to obtain the target normalized log includes: Extract the module name, page name, and page URL from the target log data; Generate a target normalized log based on the module name, the page name, the page URL, and the target log template.

6. A log upload device, characterized in that, The log upload device includes: The access unit is used for multi-terminal access with H5 and RN terminals in business scenarios; The acquisition unit is used to acquire a set of log types and a set of log templates that match the set of log types; The configuration unit is used to perform standardized configuration for multi-terminal access based on the log type set and the log template set; the standardized configuration includes: configuring global variables containing module name, page URL, and page name for H5 terminal, and configuring global variables containing module name, page URL, and page name for RN terminal; The receiving unit is used to receive target log data from multiple access points; A normalization unit is used to normalize the target log data according to the log type set and the log template set to obtain the target normalized log; An upload unit is used to upload the target normalized log; The target normalized log is generated based on the module name, page name, page URL, and target log template. The module name, the page name, and the page URL are extracted from the target log data; The target log template is matched with the log type of the target log data, and the log type is determined based on a set of log types.

7. The log uploading device according to claim 6, characterized in that, The acquisition unit includes: The first acquisition subunit is used to acquire raw log data from multiple access points; The sorting and classification subunit is used to statistically sort and classify the original log data to obtain a set of log types. The second acquisition subunit is used to acquire a log template that matches each log type in the log type set; The summary subunit is used to summarize the log templates to obtain a set of log templates that match the set of log types.

8. The log uploading device according to claim 6, characterized in that, The normalization unit includes: A sub-unit is defined to determine the log type of the target log data based on the log type set. The third acquisition subunit is used to acquire a target log template that matches the log type according to the log type set; The processing subunit is used to perform normalization processing on the target log data according to the target log template to obtain the target normalized log.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory being used to store a computer program, and the processor running the computer program to cause the electronic device to perform the log uploading method according to any one of claims 1 to 5.

10. A readable storage medium, characterized in that, The readable storage medium stores computer program instructions, which, when read and executed by a processor, perform the log upload method according to any one of claims 1 to 5.

Images