Service reply method and device based on log processing, medium, equipment and product

Abstract

The invention discloses a service reply method and device based on log processing, a medium, equipment and a product. According to the scheme, after the abnormal log data is filtered out from the obtained log data, the user identifier contained in the abnormal log data can be extracted from the abnormal log data, and the business abnormal record capable of being inquired subsequently is finally generated, so that when the abnormal inquiry request initiated by the user for the target business is received, the business abnormal record can be inquired subsequently. Therefore, according to the user identifier of the user, the reason data of the reason causing the exception when the target service is executed can be inquired based on the stored service exception record, and then the user is replied, so that even if customer service personnel do not have the authority of calling the log data, the customer service personnel can call the log data. And the reason field can be quickly queried from each pre-stored business exception record based on the user identifier of the user and replied to the user, so that the business experience of the user is effectively improved, and the efficiency of processing the user exception inquiry request by customer service personnel can be improved.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of computer technology, and more particularly, to a business recovery method, apparatus, medium, device, and product based on log processing. Background Art

[0002] With the continuous development of computer technology, network platforms can provide users with a variety of services to bring convenience to users' daily lives through these services.

[0003] When users are executing business, abnormal situations may occur, resulting in business execution failure. When this happens, users may ask the network platform for the reason for the business abnormality. At this time, it is necessary to retrieve the log data generated during the business execution process, so as to analyze the cause of the business abnormality through the log data and respond to the user.

[0004] However, customer service personnel often do not have the authority to retrieve log data, and analyzing log data is also difficult for customer service personnel. This makes it difficult for customer service personnel to quickly respond to users' inquiries about the reasons for business anomalies, causing inconvenience to users. Summary of the Invention

[0005] In view of this, one or more embodiments of this specification provide the following technical solutions:

[0006] According to a first aspect of one or more embodiments of this specification, a service recovery method based on log processing is proposed, the method comprising:

[0007] Obtain the log data generated when the target business is executed;

[0008] Filtering the log data to determine abnormal log data contained in the log data, where the abnormal log data is used to indicate that an abnormality occurs when executing the target business;

[0009] Extracting the user identifier contained in the exception log data, generating and storing a business exception record based on the user identifier and reason data corresponding to the exception log data, wherein the reason data is used to indicate the reason why the exception occurred when executing the target business;

[0010] In response to an exception query request initiated by a user for the target business, the cause data of the exception caused when executing the target business is queried based on the user ID of the user and the saved business exception records, so as to reply to the user based on the cause data.

[0011] Optionally, filtering the log data to determine abnormal log data contained in the log data specifically includes:

[0012] For each log data, if it is determined according to a pre-configured matching rule that the log data contains a specified field, the log data is determined to be abnormal log data.

[0013] Optionally, filtering the log data to determine abnormal log data contained in the log data specifically includes:

[0014] Determine the log analysis configuration corresponding to the target business;

[0015] The log data are filtered according to the matching rules included in the log analysis configuration to determine abnormal log data included in the log data.

[0016] Optionally, generating and storing a service exception record according to the user identifier and the cause data corresponding to the exception log data specifically includes:

[0017] Determine the log analysis configuration corresponding to the target business;

[0018] The specification text corresponding to the log analysis configuration is used as the cause data corresponding to the abnormal log data, so as to generate and store a business abnormality record according to the user identifier and the cause data.

[0019] Optionally, the first system executes the target service, and the second system responds to the user;

[0020] Obtain the log data generated when the target business is executed, including:

[0021] Obtaining, from the first system, various log data generated when the target business is executed, through a preset first interface;

[0022] In response to an exception query request initiated by a user regarding the target business, searching for cause data of a cause of an exception occurring when executing the target business based on the user ID of the user and based on the stored business exception records, and replying to the user based on the cause data, specifically including:

[0023] receiving, via a preset second interface, a query request sent by the second system, wherein the query request is generated by the second system according to the abnormal query request sent by the user;

[0024] According to the user identifier of the user carried in the query request, query the service exception record matching the user identifier of the user as the target record;

[0025] According to the reason data included in the target record, a query result is returned to the second system, so that the second system replies to the user based on the query result.

[0026] According to a second aspect of one or more embodiments of this specification, a service recovery device based on log processing is provided, the device comprising:

[0027] The acquisition module is used to obtain the log data generated when the target business is executed;

[0028] A filtering module, configured to filter the log data to determine abnormal log data contained in the log data, wherein the abnormal log data is used to indicate an abnormality that occurs when executing the target business;

[0029] an extraction module for extracting a user identifier contained in the abnormal log data, and generating and storing a business abnormality record based on the user identifier and cause data corresponding to the abnormal log data, wherein the cause data is used to indicate a cause of an abnormality occurring when executing the target business;

[0030] The query module is used to respond to the exception query request initiated by the user for the target business, query the cause data of the cause of the exception when executing the target business based on the saved business exception record according to the user ID of the user, and reply to the user based on the cause data.

[0031] Optionally, the filtering module is specifically configured to, for each log data, determine that if the log data contains a specified character string according to a pre-configured matching rule, then determine that the log data is abnormal log data.

[0032] Optionally, the filtering module is specifically configured to determine a log analysis configuration corresponding to the target business; and filter the log data according to a matching rule included in the log analysis configuration to determine abnormal log data included in the log data.

[0033] Optionally, the extraction module is specifically used to determine the matching rule used to filter out the abnormal log data as the target rule; use the standard text corresponding to the target rule as the cause data corresponding to the abnormal log data, so as to generate and store a business exception record based on the user identifier and the cause data.

[0034] Optionally, the first system executes the target service, and the second system responds to the user;

[0035] The acquisition module is specifically configured to acquire, from the first system through a preset first interface, various log data generated when the target business is executed;

[0036] The query module is specifically configured to receive, through a preset second interface, a query request sent by the second system, where the query request is generated by the second system based on an exception inquiry request sent by the user; retrieve, based on a user identifier of the user carried in the query request, a business exception record matching the user identifier as a target record; and return a query result to the second system based on cause data contained in the target record, so that the second system can reply to the user based on the query result.

[0037] According to the third aspect of one or more embodiments of this specification, an electronic device is proposed, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the steps of the above-mentioned log processing-based business recovery method by running the executable instructions.

[0038] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is proposed, on which computer instructions are stored. When the instructions are executed by a processor, the steps of the above-mentioned business recovery method based on log processing are implemented.

[0039] According to a fifth aspect of one or more embodiments of this specification, a computer program product is proposed, including a computer program / instruction, which, when executed by a processor, implements the steps of the above-mentioned business recovery method based on log processing.

[0040] It can be seen from the above embodiment that after filtering out the abnormal log data from the acquired log data, the user identifier contained therein can be extracted from the abnormal log data, and finally a business abnormality record that can be queried subsequently is generated. In this way, when an abnormal inquiry request initiated by a user for the target business is received, the cause data of the cause of the abnormality when executing the target business can be queried based on the user's user identifier and the saved business abnormality record, and then a reply can be given to the user.

[0041] Since the log data can be processed in advance to store the user ID extracted from the exception log data and the reason data corresponding to the exception log data in a form that can be queried later, even if the customer service staff does not have the authority to retrieve the log data, they can quickly query the reason field from the pre-stored business exception records based on the user's user ID and reply to the user, which not only effectively improves the user's business experience, but also improves the efficiency of customer service staff in handling user exception inquiry requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 A schematic diagram of the steps involved in the business recovery method based on log processing provided in this manual;

[0043] Figure 2 A flowchart of a business response method based on log processing provided in this manual;

[0044] Figure 3 A schematic diagram of the system provided in this specification monitoring the execution of each process of the target business and reporting abnormalities;

[0045] Figure 4 This is a schematic diagram of a service interface used by customer service personnel provided in this manual;

[0046] Figure 5 A schematic diagram of the structure of a device provided in this manual;

[0047] Figure 6 This is a block diagram of a business recovery device based on log processing provided in this specification. DETAILED DESCRIPTION

[0048] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0049] In actual applications, when a user encounters an abnormality when executing a business and causes a failure, an abnormal inquiry request can be initiated to the network platform. Since the customer service personnel of the network platform usually do not have the authority to retrieve log data, and it is difficult to analyze and process the log data, it is necessary to contact technical personnel based on the user's abnormal inquiry request, so that the technical personnel can use the user's user ID (such as the user's ID on the business platform) to search for the log data generated when the user executes the business in the large amount of log data stored in the background, and then determine the cause of the abnormality in the user's business execution by analyzing the log data, and inform the user through the customer service personnel.

[0050] As can be seen from the above process, the entire process is quite complex and tedious. Customer service personnel often need the help of technical personnel to respond to users, which inevitably makes users wait for a long time before receiving a response, which greatly affects the user's service experience. From the perspective of customer service personnel, it also greatly reduces the efficiency of customer service personnel in handling user inquiries.

[0051] Furthermore, since the execution of network platform services generates a large amount of log data, in order to ensure sufficient storage space for normal service execution, these log data need to be regularly cleared. In other words, under normal circumstances, the log data generated during service execution has a certain retention period, and when the retention period exceeds, it will be cleared.

[0052] Therefore, if the log data involved has been cleared when the user initiates an abnormal inquiry request, the customer service staff will not be able to learn from the technical staff the reason for the abnormality in the user's business execution, nor will they be able to give the user a reasonable response, which will further affect the user's business experience.

[0053] Alternatively, an intrusive tracking method can be used to collect exception causes. This means embedding code for collecting exception causes within the business code. This way, when an exception occurs while executing a business, the pre-embedded code can collect the cause data and store it in a pre-set database.

[0054] However, embedding exception cause collection code within business code inevitably leads to bloated business code, significantly increasing maintenance costs. Furthermore, in real-world applications, business code is often deployed in developer-facing business systems, while customer service staff typically operate in separate systems. This prevents customer service staff from accessing or querying stored cause data in the business system, hindering their ability to quickly respond to users.

[0055] In response to the above problems, this specification provides a business response method based on log processing, in which the user identifier contained in the abnormal log data can be extracted, and an abnormal business record containing the cause data that caused the user to execute the target business abnormally can be generated and stored in a database that can be queried by customer service personnel. In this way, when the user initiates an abnormal inquiry request for the target business, the customer service personnel can query the cause data of the cause of the abnormality when the user executes the target business from the database based on the user's user identifier, and then provide a business response to the user. This can not only significantly improve the user's business experience, but also greatly improve the efficiency of customer service personnel in handling user requests. Moreover, there is no need to bury additional code in the business code, which can effectively reduce the maintenance cost of the business code by technical personnel.

[0056] This manual provides a business recovery method based on log processing, which can be roughly divided into several steps, such as Figure 1 shown.

[0057] Figure 1 This is a schematic diagram of the steps involved in the business recovery method based on log processing provided in this manual.

[0058] First, we need to collect the log data generated by each user when executing the target business. We then use the deployed log analysis configuration to cleanse the collected log data for abnormal log data. The log analysis configuration specifies which fields in the log data are considered abnormal log data. The fields specified in the log analysis configuration can be specific fields that appear in the log data when business execution anomalies occur, determined based on actual needs and experience.

[0059] Therefore, the fields contained in the log data can be matched through the log analysis configuration. Once the log data hits the fields specified in the log analysis configuration, it is determined that it is abnormal log data.

[0060] After cleaning out the abnormal log data from each log data, in order to facilitate subsequent inquiries by customer service personnel, it is necessary to extract the user ID contained in the abnormal log data to generate and save the corresponding business abnormality record. The business abnormality record can be regarded as an abnormal behavior event generated based on the cause data that reflects the abnormality of the user's execution of the target business and the user ID. Therefore, saving this abnormal behavior event is actually writing the structured event data into the database according to the predefined storage strategy for storage, so as to facilitate subsequent query, analysis, management, etc.

[0061] After completing the preservation of the business anomaly records, the customer service staff can use the preset troubleshooting tool to respond to the abnormal inquiry request initiated by the user. Among them, the troubleshooting tool in this manual can be regarded as a tool for customer service staff. When the customer service staff uses the troubleshooting tool, an operation interface can be displayed on the screen of the terminal device used by the customer service staff. The customer service staff can enter the user's user ID in the operation interface and perform a query operation. The troubleshooting tool will also generate a query request based on the query operation performed by the customer service staff, and by executing the query request, query the cause data of the cause of the abnormality of the target business executed by the user from the database. The customer service staff can use the queried cause data to make a business reply to the user to inform the user of the cause of the abnormality of their business.

[0062] Furthermore, the specific forms of the target business executed by the user can be various. For example, the target business can refer to a video incentive business, that is, with the user's authorization, the user can obtain certain rewards by browsing short videos. The specific reward rules can be that when the user browses the short video for a certain length of time, or the number of short videos browsed reaches a preset number, the user can be issued a certain reward (such as a consumption voucher, a cash red envelope, platform points, etc.). When the user executes the video incentive business and finds that he has not successfully received the corresponding reward, he can initiate an abnormal inquiry request to obtain the reason for the failure to receive the reward through the customer service staff (such as insufficient time to browse the short video, the user has not filled in the contact information, the user is a risky user, etc.).

[0063] For another example, the target business could be a wealth management business, where a user purchases a desired wealth management investment product based on actual needs. During this process, if the user fails to successfully complete the purchase of the wealth management investment product while performing the wealth management business, they can initiate an exception inquiry request to obtain information from customer service personnel regarding the reasons for the failure (e.g., the user is at risk of account theft, the user did not conduct a risk assessment before purchasing the wealth management investment product, the user's account balance is insufficient, etc.).

[0064] The specific forms of other target businesses will not be given examples one by one here.

[0065] In addition, the methods provided in this manual may involve various system forms, which can be roughly divided into two situations:

[0066] Single-system form: The so-called single-system form means that the system that executes the target business and the system used by customer service personnel to provide business responses to users can be the same system. In this case, the entire process involved in the method provided in this specification is actually completed within one system and does not involve data calls between other systems.

[0067] Multi-system form: The so-called multi-system form means that the system that executes the target business and the system used by customer service personnel to provide business responses to users may not be the same system. In this case, if the above-mentioned business exception records are stored in the system that executes the target business, it is necessary to set up a data query interface in both systems so that the system used by the customer service personnel can query the reason data required by the user from the system that executes the target business based on the customer service personnel's query request through the data query interface and respond to the user.

[0068] If the business exception records mentioned above are stored in the system used by customer service personnel, it is necessary to set up a data call interface in these two systems so that the system used by customer service personnel can obtain various log data generated by the system that executes the business through the data call interface, and generate and save business exception records by cleaning the log data and extracting fields.

[0069] Of course, within a multi-system model, a separate system can also be built. This system can obtain log data from the system executing the target business through a preset interface, cleanse and extract fields from this log data, generate business exception records, and store them in a local database. When a user initiates an exception query request, the system can obtain the query request sent by the system used by the customer service staff through a preset interface, and then use this query request to query the cause data required by the customer service staff, and then return the query results to the system used by the customer service staff through this interface.

[0070] For ease of explanation, the business recovery method based on log processing provided in this specification will be described in the form of a single system first, and then the multi-system form will be introduced.

[0071] The technical solutions provided by the embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0072] Single system form

[0073] Figure 2 This is a flowchart of a business recovery method based on log processing provided in this manual.

[0074] S200: Acquire various log data generated when executing the target business.

[0075] In a single-system approach, the entire method can be executed by a single system, which serves both as the target business and as the system used by customer service personnel. Within this system, different resources and system environments can be allocated for executing the target business and for customer service personnel to perform customer service tasks. However, it should be noted that although these systems operate within the same system, customer service personnel often do not have access to log data due to business requirements.

[0076] On this basis, in order to ensure the user's business experience and improve the efficiency of customer service personnel in responding to user inquiries, the system can obtain and collect the various log data generated by each user performing the target business, and in the subsequent process, cleanse and extract fields from these log data to generate business exception records that can be queried by customer service personnel.

[0077] Among them, if the target business involves the execution of multiple processes, the system can monitor the execution of each process of the target business in real time, and generate log data in time when an abnormality is detected, so as to report the abnormality, such as Figure 3 shown.

[0078] Figure 3 This is a schematic diagram of the system provided in this manual monitoring the execution of each process of the target business and reporting abnormalities.

[0079] exist Figure 3 In the process, the execution of the target business involves process 1, process 2, process 3, etc., wherein the processes involved in the target business are different for different target business forms.

[0080] For example, assuming that the target business is online shopping, then for a new user of a business platform, before executing the online shopping business, the new user needs to first register an account on the business platform, then bind the registered account with the payment account, and then execute the order operation by browsing the product interface.

[0081] Therefore, the account registration, the binding of the account and the payment account, and the order placed by the user involved in this example can all be regarded as different processes in the online shopping business.

[0082] When the system executes the above target business, it needs to monitor the execution of each process. For any process, if the execution of the process is abnormal, the execution of the target business can be terminated and the abnormal log data for the process can be generated and reported. Figure 3 In the example, any process execution exception will terminate the continued execution of the target business. Then, the generated log data will record which process the target business was executing when the exception occurred.

[0083] S202: Filter the log data to determine abnormal log data included in the log data.

[0084] After acquiring each log data set, it is necessary to filter out exception log data that indicates anomalies encountered by users while executing the target service. This exception log data records the causes of the exceptions during the execution of the target service, including those caused by the user's service operations and those caused by problems within the service system itself. Therefore, the system can perform a matching operation on each acquired log data set according to a pre-configured matching rule, determining whether the log data is an exception log data by determining whether the log data contains the specified string included in the matching rule.

[0085] The matching rules mentioned here may be recorded in the log analysis configuration mentioned above, and the matching rules record which fields appearing in the log data are considered abnormal log data.

[0086] The following is a detailed description of the log data matching rules using a specific example.

[0087] The following is an example of abnormal log data:

[0088] 2024-08-29 17:31:03,154[2187ff3d17249238629862182e7c9b,0.1.2]WARN

[0089] impl.PromoCoreServiceImpl-[bargainConsultError]

[0090] input:{"playId":"PLAY100677798","userId":"2088042871303291"}

[0091] Result: "[20000015] Member information query failed, userId = mobile phone number is empty, count failed, {}"

[0092] The above abnormal log data can be processed through the following matching rules.

[0093]

[0094]

[0095]

[0096] The Match part of the above matching rules includes Contains matching rules and Split matching rules.

[0097] Contains matching rules:

[0098] This matching rule is to check whether the string in the log data contains the specified string ("Contact information is empty, the count is not passed").

[0099] The type in this matching rule is set to "contains", indicating that this is a match based on whether the content is included or not.

[0100] If reverse is set to false in this matching rule, it means that if the specified string is found, the match is considered successful; if it is set to true, it means the logic is inverted, that is, the match is successful if the specified string is not found.

[0101] The values in this matching rule is an array containing a list of specified strings to be found.

[0102] Split matching rules:

[0103] This matching rule is used to extract content from a string contained in log data based on a specific delimiter and compare whether the extracted content is equal to the specified value ("bargain Consult Error").

[0104] The type in this matching rule is set to "split" to indicate that this is a matching method based on split operations.

[0105] The leftStr and rightStr in this matching rule specify the left and right separators, which are "[" and "]" respectively.

[0106] The leftCount in the matching rule specifies how many times the left delimiter should appear before the content is intercepted. In the above example, it is 3 times.

[0107] The values in this matching rule contains the expected value to be compared, namely "bargain Consult Error".

[0108] For the above example, if the log data matches the specified string specified in the Contains matching rule and the Split matching rule at the same time, it can be determined that the log data is abnormal log data, so that in the subsequent process, field extraction can be further performed on the abnormal log data.

[0109] As can be seen from the above example, by setting various required matching rules in the log analysis configuration according to actual needs, when matching a log data, the character string contained in the log data can be matched with the specified character string specified in the matching rule. Once the specified character string specified in the matching rule is hit in the log data, it can be determined that the log data is abnormal log data.

[0110] It should be noted that as business needs change and business updates, the strings that need to be matched in abnormal log data may change, or new matching strings may need to be added. Therefore, in actual applications, you can adjust the above log analysis configuration to adjust the strings that need to be matched in the matching rules or add new matching strings to meet actual needs.

[0111] Among them, the above log analysis configuration can be implemented using Domain Specific Language (DSL) configuration. Since the DSL configuration describes the required rules and trigger logic in a structured manner, it can form a dynamically generated and extensible configuration model to achieve dynamic adjustment and expansion of matching rules.

[0112] S204: extracting the user identifier contained in the abnormal log data, generating and storing a business abnormality record according to the user identifier and the cause data corresponding to the abnormal log data.

[0113] Since customer service personnel do not have the authority to retrieve log data in actual applications and it is difficult to analyze and process log data, it is necessary to store the cause data in the log data that can reflect the cause of the abnormality in a certain form in a database that can be accessed and queried by customer service personnel, so as to facilitate customer service personnel to provide business answers.

[0114] To this end, after filtering out the abnormal log data from each log data, the system needs to further generate a business exception record based on the extracted user ID and the cause data corresponding to the abnormal log data. The cause data here is used to indicate the cause of the exception when executing the target business. The reason for extracting the user ID is to record the user ID and the cause data together, so that in the subsequent process, the customer service personnel can use the user ID of the user to query the cause data that caused the abnormality in the business execution.

[0115] In addition to recording the rules for filtering abnormal log data, the above log analysis configuration may also record the rules for extracting required data. Then, the system can extract the user identifier from the abnormal log data according to the extraction rules.

[0116] The principles of the extraction rules are basically the same as those of the above matching rules. Both can be understood as the identification and interception of specific fields. The following will continue to use the above example to illustrate how the system extracts user identifiers from abnormal log data.

[0117] The Field section in the above example defines how to extract a specific field (such as userId) from the log data.

[0118] Among them, for the extraction of userId, the content is intercepted based on searching for the specific prefix "userId\":\"" until the first double quotation mark is encountered.

[0119] fieldname defines the name of the extracted field.

[0120] leftStr and rightStr are similar to the delimiters in the previous matching rules and are used to define the boundaries of the data to be extracted.

[0121] leftCount determines how many times the left delimiter should appear before extraction is performed.

[0122] By using the above extraction rules, the user ID (i.e., userId) contained in the abnormal log data can be extracted. It should be noted that, as can be seen from the above example, in addition to extracting the user ID, the log analysis configuration also includes extraction rules for other fields.

[0123] Among them, the playId in the above example can be understood as the business identifier of the target business. In the process of extracting playId, an extraction rule similar to userId is adopted, that is, the content is intercepted by searching for the specific prefix "playId\":\"" until the first double quotation mark is encountered.

[0124] The traceId in the above example is the core identifier of distributed link tracing, which is mainly used to track and associate the complete life cycle of a business request in a distributed system. Therefore, traceId can serve multiple purposes in actual applications.

[0125] For example, when the business performed by the user involves the flow between multiple microservices, traceId can run through the entire business chain to ensure that each microservice can record the processing process of the unified request; for another example, by recording traceId in the log data, all log data of the same request can be quickly located, even if the log data is scattered across multiple servers.

[0126] The extraction of traceId is slightly more complicated than that of userId and playId. The corresponding extraction rule mainly looks for the content between the second occurrence of "[" and the next "]".

[0127] After extracting the user ID, the system can further generate a business exception record that is convenient for subsequent query and save it in a preset database. In this process, the above log analysis configuration is provided with a standard text template, and the system can obtain the business exception record through the standard text template.

[0128] Continuing with the previous example, the textTemplate in this example provides a standard text for generating business exception records based on the extracted data. This standard text shows that "User contact information is empty, unable to participate in the red envelope collection task" is the standard text used to replace the cause field in the exception log data. In this standard text, the actual value of playId is replaced by the placeholder {playId}. Therefore, the system can replace the placeholder corresponding to the business identifier in the standard text with the playId extracted by the above extraction rule, thereby obtaining the cause data corresponding to the exception log data.

[0129] As can be seen from the above examples, the specification text in the log analysis configuration is actually highly correlated with the target business executed by the user. Therefore, different log analysis configurations can be set for different businesses, and different log analysis configurations contain specification texts applicable to different businesses. Therefore, when cleaning and extracting fields from the log data generated by the target business, it is necessary to first determine the log analysis configuration corresponding to the target business based on the business identifier of the target business, and then filter the log data through the matching rules contained in the determined log analysis configuration to determine the abnormal log data contained in each log data, and use the specification file corresponding to the log analysis configuration as the cause data corresponding to the abnormal log data, and then generate and store business exception records based on the user identifier extracted from the abnormal log data and the determined cause data.

[0130] Among them, the standard text can be recorded in the log analysis configuration as in the above example. Of course, the log analysis configuration may not record the standard file. The log analysis configuration can be saved corresponding to the standard file, and then in actual application, the corresponding standard file can be determined according to the identification information corresponding to the log analysis configuration.

[0131] Furthermore, as can be seen from the above example, the exception log data actually also contains a field that reflects the cause of the exception in executing the target business. Therefore, the system can also extract this field from the exception log data according to the preset extraction rules, and then generate a business exception record based on the extracted field and the user ID. The method for extracting this field can be similar to the method for extracting the user ID and other identifiers, and will not be detailed here.

[0132] In addition to the user ID and reason data, the service exception record generated by the system can also record the above service ID and traceId to facilitate further analysis of the cause of the target service exception.

[0133] In this specification, a business exception record can be generated according to a preset format. The business exception record can be understood as an abnormal behavior event. Therefore, the system can write the structured event data (i.e., the generated business exception record) into the database for storage. The generated business exception record is as follows:

[0134]

[0135]

[0136] The params object in the business exception record contains a playId attribute. In this example, playId identifies the specific red envelope business that the user participated in. Therefore, placing it in the params object maintains a clear data structure and facilitates subsequent business expansion.

[0137] Since traceId is a unique identifier for a request and serves as a tracking identifier throughout the entire request lifecycle, it usually exists alone. UserId is an identifier used to uniquely identify a user and, because it is directly associated with the user entity, it also needs to exist alone.

[0138] S206: In response to the exception query request initiated by the user for the target business, according to the user ID of the user, based on the saved business exception record, query the cause data of the cause of the exception when executing the target business, and reply to the user based on the cause data.

[0139] When an exception occurs when a user performs a target business, an exception inquiry request can be initiated through the terminal device used by the user. When the system receives the exception inquiry request, it can be assigned to a customer service staff, who will then provide a business response to the user.

[0140] During this process, the system will display an operation interface to the customer service staff, in which the customer service staff can fill in the user ID of the user, and then query the cause data of the abnormality of executing the target business, such as Figure 4 shown.

[0141] Figure 4 This is a schematic diagram of an operation interface used by customer service personnel provided in this manual.

[0142] exist Figure 4 The operation interface shown contains an input box for filling in the user ID (i.e. Figure 4 In the user ID position), fill in the user start and end time input box. Customer service staff can enter the user ID and the start and end time of the user's target business in these input boxes and touch Figure 4to get the required query results.

[0143] exist Figure 4 In the query, a total of 3 records were found that caused the user to execute the target business abnormally, among which: Figure 4 The target business in the example may be a sharing reward business, that is, a user can obtain a certain reward by sharing a business link with other users. As the number of other users who perform business based on the received business link increases, the reward obtained by the user who shared the business link will also increase.

[0144] so, Figure 4 "Failure in the recommendation phase" means that the number of users sharing the business link is insufficient. In other words, the number of other users who receive the business link and execute the business does not meet the requirements. "Failure in the query phase" means that when other users execute the business based on the business link, the user ID of the other user will be used to query whether the other user belongs to the preset blacklist. If so, it is determined that the other user is a risk, and the service is refused to be provided to the other user.

[0145] Customer service staff can touch Figure 4 Through this link, customer service staff can view the detailed reasons for the abnormality in the user's business execution and respond to the user accordingly.

[0146] It should be pointed out that Figure 4 The displayed operation interface can also be displayed to the technical staff of the target business, who can click Figure 4 Click "Copy traceId" in the taskbar to copy the traceId. Then, touch "Jump to Cloud Map" to display the various processes involved in the user's business execution (thus, the cloud map is used to display the various processes involved in a business). Using the copied traceId, technicians can track the log data generated by each process and analyze the entire business chain.

[0147] After querying the cause data of the abnormality in business execution, the customer service staff can make a business reply to the user through the system, thereby informing the user of the reason for the abnormality in business execution.

[0148] From the above content, it can be seen that since the log data can be processed in advance and stored in a form that can be subsequently queried based on the data extracted from the exception log data, even if the customer service staff does not have the authority to retrieve the log data, they can quickly query the cause data from the pre-stored business exception records based on the user's user ID and reply to the user. This can effectively improve the user's business experience and also improve the efficiency of customer service staff in handling user exception inquiry requests.

[0149] Furthermore, the method provided in this specification does not require embedding additional code in the business code, thereby effectively reducing the redundancy of the business code and further effectively reducing the cost of technical personnel maintaining the business code.

[0150] Multi-system form

[0151] In this specification, the system used by the customer service personnel and the system for executing the target business may be different systems. Here, the system for executing the target business may be referred to as the first system, and the system used by the customer service personnel may be referred to as the second system.

[0152] On this basis, a separate system can be built, which has preset interfaces with the first system and the second system respectively. Through the set interfaces, the system can filter the log data and extract fields, store the generated business exception records, receive query requests sent by customer service personnel, and reply to the customer service personnel with query results, so that the customer service personnel can make business responses to users based on the query results obtained.

[0153] Specifically, the system can obtain various log data generated during the execution of the target business from the first system through a preset first interface. In this process, the system can monitor the log data generated during the execution of the target business through a preset listener, and once the log data is monitored, it can be obtained through the first interface.

[0154] Of course, the system can also periodically obtain the various log data generated by the execution of the target business from the first system, where the regular acquisition of log data can be the system actively initiating a log data acquisition request to the first system, or the first system can periodically and actively synchronize the various log data generated by the execution of the target business to the system.

[0155] After acquiring each log data, the system can filter each log data according to the method of steps S202 to S206 to determine abnormal log data and extract required fields from the abnormal log data to generate business abnormality records. The generated business abnormality records can be stored in the local database of the system.

[0156] When an exception occurs when a user performs a target business, an exception query request may be sent to the second system used by the customer service staff. Based on the exception query request, the customer service staff sends a query request containing a user identifier to the system through the second system.

[0157] After receiving the query request through the preset second interface, the system can use the user identifier carried in the query request to query the local database for a business exception record that matches the user identifier, using it as the target record. Based on the cause data contained in the target record, the system then returns the query result to the second system. Customer service personnel can then respond to the user based on the query result returned by the system.

[0158] It can be seen that the above example actually uses a separately built system to provide business responses to users. In fact, it is also possible to directly use the first system or the second system to complete the filtering and field extraction of log data, and have the second system provide responses to users. This situation has been introduced in the above content and will not be elaborated here.

[0159] It should also be noted that as the business develops and actual needs change, it may be desirable to further record required additional data on the basis of the original log data content, so as to identify anomalies in the business performed by the user through the additional data.

[0160] To this end, additional APIs can be created to capture specific data generated during business execution, and then the specific data can be written into the log data in a certain format. This ensures the security of user business while providing more basis for customer service personnel to respond to user business requests.

[0161] Figure 5 This is a schematic diagram of the structure of a device provided in this manual. Please refer to Figure 5 At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, a memory 508, and a non-volatile memory 510. Of course, it may also include hardware required for other functions. One or more embodiments of this specification can be implemented based on software, such as the processor 502 reading the corresponding computer program from the non-volatile memory 510 into the memory 508 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0162] Please refer to Figure 6 The business recovery device based on log processing provided in this specification can be applied to Figure 5 The device shown in the figure can be used to implement the technical solution of this specification. The device can include:

[0163] The acquisition module 600 is used to obtain various log data generated when the target business is executed;

[0164] A filtering module 602 is configured to filter the log data to determine abnormal log data contained in the log data, where the abnormal log data indicates an abnormality that occurs when executing the target business.

[0165] An extraction module 604 is configured to extract the user identifier contained in the exception log data, and generate and store a business exception record based on the user identifier and reason data corresponding to the exception log data, wherein the reason data is used to indicate the reason why the exception occurred when executing the target business;

[0166] The query module 606 is used to respond to the exception query request initiated by the user for the target business, and query the cause data of the cause of the exception when executing the target business based on the saved business exception record according to the user ID of the user, so as to reply to the user based on the cause data.

[0167] Optionally, the filtering module 602 is specifically configured to, for each log data, determine that if the log data contains a specified character string according to a pre-configured matching rule, then determine that the log data is abnormal log data.

[0168] Optionally, the filtering module 602 is specifically configured to determine a log analysis configuration corresponding to the target business; and filter the log data according to a matching rule included in the log analysis configuration to determine abnormal log data included in the log data.

[0169] Optionally, the extraction module 604 is specifically used to determine the log analysis configuration corresponding to the target business; use the standard text corresponding to the log analysis configuration as the cause data corresponding to the abnormal log data, so as to generate and store a business abnormality record based on the user identifier and the cause data.

[0170] Optionally, the first system executes the target service, and the second system responds to the user;

[0171] The acquisition module 600 is specifically configured to acquire, from the first system through a preset first interface, various log data generated when the target business is executed;

[0172] The query module 606 is specifically configured to receive a query request sent by the second system through a preset second interface, where the query request is generated by the second system based on the exception inquiry request sent by the user; retrieve, based on the user identifier of the user carried in the query request, a business exception record matching the user identifier of the user as a target record; and return a query result to the second system based on the cause data contained in the target record, so that the second system can reply to the user based on the query result.

[0173] Based on the same concept as the above method, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor implements the steps of the method described in any of the above embodiments by running the executable instructions.

[0174] Based on the same concept as the above method, this specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0175] Based on the same concept as the above method, this specification also provides a computer program product, including a computer program / instruction, which implements the steps of the method described in any of the above embodiments when executed by a processor.

[0176] This specification may be described in the general context of computer-executable instructions, such as program modules, executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including storage devices.

[0177] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0178] The above are merely examples of the present invention and are not intended to limit the present invention. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be included within the scope of the claims of the present invention.

Claims

1. A business recovery method based on log processing, the method comprising: Obtain the log data generated when the target business is executed; Filtering the log data to determine abnormal log data contained in the log data, where the abnormal log data is used to indicate that an abnormality occurs when executing the target business; Extracting the user identifier contained in the exception log data, generating and storing a business exception record based on the user identifier and reason data corresponding to the exception log data, wherein the reason data is used to indicate the reason why the exception occurred when executing the target business; In response to an exception query request initiated by a user for the target business, the cause data of the exception caused when executing the target business is queried based on the user ID of the user and the saved business exception records, so as to reply to the user based on the cause data.

2. The method according to claim 1, wherein filtering the log data to determine abnormal log data contained in the log data comprises: For each log data, if it is determined according to a pre-configured matching rule that the log data contains a specified character string, the log data is determined to be abnormal log data.

3. The method according to claim 1, wherein filtering the log data to determine abnormal log data contained in the log data comprises: Determine the log analysis configuration corresponding to the target business; The log data are filtered according to the matching rules included in the log analysis configuration to determine abnormal log data included in the log data.

4. The method according to claim 1, generating and storing a business exception record based on the user identifier and the cause data corresponding to the exception log data, specifically comprising: Determine the log analysis configuration corresponding to the target business; The specification text corresponding to the log analysis configuration is used as the cause data corresponding to the abnormal log data, so as to generate and store a business abnormality record according to the user identifier and the cause data.

5. The method according to any one of claims 1 to 4, wherein the first system executes the target service, and the second system performs a service response to the user; Obtain the log data generated when the target business is executed, including: Obtaining, from the first system, various log data generated when the target business is executed, through a preset first interface; In response to an exception query request initiated by a user regarding the target business, searching for cause data of a cause of an exception occurring when executing the target business based on the user ID of the user and based on the stored business exception records, and replying to the user based on the cause data, specifically including: receiving, via a preset second interface, a query request sent by the second system, wherein the query request is generated by the second system according to the abnormal query request sent by the user; According to the user identifier of the user carried in the query request, query the service exception record matching the user identifier of the user as the target record; According to the reason data included in the target record, a query result is returned to the second system, so that the second system replies to the user based on the query result.

6. A business recovery device based on log processing, the device comprising: The acquisition module is used to obtain the log data generated when the target business is executed; A filtering module, configured to filter the log data to determine abnormal log data contained in the log data, wherein the abnormal log data is used to indicate an abnormality that occurs when executing the target business; an extraction module, configured to extract a user identifier contained in the exception log data, and generate and store a business exception record based on the user identifier and cause data corresponding to the exception log data, wherein the cause data is used to indicate a cause of an exception when executing the target business; The query module is used to respond to the exception query request initiated by the user for the target business, query the cause data of the cause of the exception when the target business occurs based on the saved business exception record according to the user ID of the user, and reply to the user based on the cause data. 7 . The device according to claim 6 , wherein the filtering module is specifically configured to, for each log data, determine that if the log data contains a specified character string according to a pre-configured matching rule, then determine that the log data is abnormal log data.

8. The device as described in claim 6, wherein the filtering module is specifically used to determine the log analysis configuration corresponding to the target business; and filter the various log data according to the matching rules contained in the log analysis configuration to determine the abnormal log data contained in the various log data.

9. In the device as described in claim 6, the extraction module is specifically used to determine the matching rule used to filter out the abnormal log data as the target rule; use the standard text corresponding to the target rule as the cause data corresponding to the abnormal log data, so as to generate and store the business exception record based on the user identifier and the cause data.

10. The device according to any one of claims 6 to 9, wherein the first system executes the target service, and the second system performs a service response to the user; The acquisition module is specifically configured to acquire, from the first system through a preset first interface, various log data generated when the target business is executed; The query module is specifically configured to receive, through a preset second interface, a query request sent by the second system, where the query request is generated by the second system based on an exception inquiry request sent by the user; retrieve, based on a user identifier of the user carried in the query request, a business exception record matching the user identifier as a target record; and return a query result to the second system based on cause data contained in the target record, so that the second system can reply to the user based on the query result.

11. An electronic device comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method according to any one of claims 1 to 5 by running the executable instructions.

12. A computer-readable storage medium having computer instructions stored thereon, wherein when the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

13. A computer program product comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 5.

Images