Disclosure of Invention
In view of this, one or more embodiments of the present disclosure provide the following technical solutions:
According to a first aspect of one or more embodiments of the present disclosure, a service reply method based on log processing is provided, where the method includes:
Acquiring log data generated when the target service is executed;
Filtering the log data to determine abnormal log data contained in the log data, wherein the abnormal log data are used for representing that the target service is abnormal when the target service is executed;
extracting a user identifier contained in the abnormal log data, so as to generate and store a business abnormal record according to the user identifier and reason data corresponding to the abnormal log data, wherein the reason data is used for indicating the reason of abnormality when the target business is executed;
And responding to an abnormal inquiry request initiated by a user aiming at the target service, inquiring reason data of a reason for abnormal occurrence when the target service is executed based on the stored service abnormal record according to the user identification of the user, and replying to the user based on the reason data.
Optionally, filtering each log data to determine abnormal log data contained in each log data, which specifically includes:
and for each log data, if the log data contains the appointed field according to the preset matching rule, determining that the log data is abnormal log data.
Optionally, filtering each log data to determine abnormal log data contained in each log data, which specifically includes:
Determining log analysis configuration corresponding to the target service;
And filtering each log data according to the matching rules contained in the log analysis configuration to determine abnormal log data contained in each log data.
Optionally, generating and storing a business anomaly record according to the user identifier and the reason data corresponding to the anomaly log data, which specifically includes:
Determining log analysis configuration corresponding to the target service;
and taking the normative text corresponding to the log analysis configuration as the reason data corresponding to the abnormal log data, so as to generate and store a business abnormal record according to the user identification and the reason data.
Optionally, the first system executes the target service, and the second system replies the service to the user;
The method for acquiring the log data generated during the execution of the target service specifically comprises the following steps:
acquiring each log data generated when the target service is executed from the first system through a preset first interface;
Responding to an abnormal inquiry request initiated by a user aiming at the target service, inquiring reason data of a reason for abnormal occurrence when the target service is executed based on a stored service abnormal record according to a user identification of the user, so as to reply to the user based on the reason data, wherein the method specifically comprises the following steps:
Receiving a query request sent by the second system through a preset second interface, wherein the query request is generated by the second system according to an abnormal query request sent by the user;
Inquiring a business abnormal record matched with the user identification of the user as a target record according to the user identification of the user carried in the inquiry request;
and returning a query result to the second system according to the reason data contained in the target record, so that the second system replies to the user based on the query result.
According to a second aspect of one or more embodiments of the present specification, there is provided a log processing-based service reply device, the device including:
The acquisition module is used for acquiring log data generated when the target service is executed;
the filtering module is used for filtering the log data to determine abnormal log data contained in the log data, wherein the abnormal log data are used for representing that the target business is abnormal when the target business is executed;
The extraction module is used for extracting the user identification contained in the abnormal log data so as to generate and store a business abnormal record according to the user identification and the reason data corresponding to the abnormal log data, wherein the reason data is used for representing the reason of the abnormality when the target business is executed;
And the query module is used for responding to an abnormal query request initiated by a user aiming at the target service, querying the reason data of the reason for abnormal occurrence when the target service is executed based on the stored service abnormal record according to the user identification of the user, and replying to the user based on the reason data.
Optionally, the filtering module is specifically configured to determine, for each log data, that the log data is abnormal log data if it is determined that the log data includes a specified string according to a preset matching rule.
Optionally, the filtering module is specifically configured to determine a log analysis configuration corresponding to the target service, and filter each log data according to a matching rule included in the log analysis configuration, so as to determine abnormal log data included in each log data.
Optionally, the extraction module is specifically configured to determine a matching rule used for filtering the abnormal log data as a target rule, and use a canonical text corresponding to the target rule as cause data corresponding to the abnormal log data, so as to generate and store a business abnormal record according to the user identifier and the cause data.
Optionally, the first system executes the target service, and the second system replies the service to the user;
The acquisition module is specifically configured to acquire, from the first system through a preset first interface, each log data generated when the target service 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 according to an abnormal query request sent by the user, query, according to a user identifier of the user carried in the query request, a service abnormal record matching with the user identifier of the user as a target record, and return, according to cause data included in the target record, a query result to the second system, so that the second system replies to the user based on the query result.
According to a third aspect of one or more embodiments of the present specification, an electronic device is provided, which includes a processor, and a memory for storing executable instructions of the processor, where the processor implements the steps of the above log processing based service reply method by executing the executable instructions.
According to a fourth aspect of one or more embodiments of the present description, a computer-readable storage medium is provided, on which computer instructions are stored, which instructions, when executed by a processor, implement the steps of the log-processing based service reply method described above.
According to a fifth aspect of one or more embodiments of the present description, a computer program product is presented, comprising a computer program/instruction which, when executed by a processor, implements the steps of the above-described log processing based service reply method.
As can be seen from the above embodiments, after filtering out the abnormal log data from the obtained log data, the user identifier contained in the abnormal log data may be extracted from the abnormal log data, and the service abnormal record that may be queried later may be finally generated, so when an abnormal query request initiated by the user for the target service is received, the reason data of the reason for the abnormality occurring when the target service is executed may be queried based on the saved service abnormal record according to the user identifier of the user, and further a reply is made to the user.
Because the log data can be processed in advance to store the user identification extracted from the abnormal log data and the reason data corresponding to the abnormal log data in a follow-up query mode, even if customer service personnel do not have the authority of calling the log data, the reason fields can be quickly queried from the pre-stored business abnormal records and the user can be replied based on the user identification of the user, so that the business experience of the user is effectively improved, and the efficiency of the customer service personnel for processing the user abnormal query request can be improved.
Detailed Description
User information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, presented data, etc.) referred to in this specification are both information and data authorized by the user or sufficiently authorized by the parties, and the collection, use and processing of relevant data requires compliance with relevant laws and regulations and standards of the relevant country and region, and is provided with corresponding operation portals for the user to choose authorization or denial.
In practical application, when a user performs a service abnormally and fails, an abnormal inquiry request can be initiated to the network platform, and customer service personnel of the network platform usually do not have the authority to retrieve log data and have higher difficulty in analyzing and processing the log data, so that the technician needs to be contacted according to the abnormal inquiry request of the user, so that the technician searches a large amount of log data stored in the background for the log data generated when the user performs the service through the user identification (such as the ID of the user on the service platform) of the user, and further determines the reason for causing the abnormal service to occur through analyzing the log data and informs the user through the customer service personnel.
From the above-mentioned in-process can obviously show that whole process is comparatively complicated and loaded down with trivial details, and customer service personnel often need rely on the help of technician, just can reply to the user, and this must let the user wait for a longer time and just can obtain reply information to very big influence user's business experience. In addition, from the perspective of customer service personnel, the efficiency of customer service personnel in processing the user inquiry request is greatly reduced.
In addition, since a large amount of log data is generated during the service execution of the network platform, in order to ensure that there is enough storage space to execute the normal execution of the service, the log data needs to be cleared periodically. That is, in general, log data generated during the execution of a service has a certain save time limit, and when the save time limit is exceeded, the log data is cleared.
Therefore, if the log data is already cleared when the user initiates the abnormal inquiry request, the customer service personnel cannot know the reason of the abnormal execution of the user by the technician, and cannot give a reasonable reply to the user, so that the service experience of the user is further affected.
In addition, at present, acquisition of the cause of the abnormality may be implemented by an invasive point burying method, that is, a code for acquiring the cause of the abnormality is buried in the service code. Therefore, when the user executes the business to generate an abnormality, the pre-embedded code can collect the reason data of the abnormality of the business, and then the reason data is stored in a preset database.
However, embedding the code for collecting the cause of the abnormality into the service code tends to result in a bulkiness of the service code, thereby significantly increasing the maintenance cost of the service code. In practical application, the service codes are often deployed in a service system facing the developer, and the system used by the customer service personnel is usually independent from the service system, so that the customer service personnel cannot call or inquire the saved reason data from the service system, and therefore, the customer service personnel cannot quickly reply to the user.
Aiming at the problems, the present specification provides a business reply method based on log processing, in the method, by extracting the user identifier contained in the abnormal log data and generating an abnormal business record recorded with the reason data for causing the abnormality of the user execution target business, so as to store the abnormal business record in a database capable of being executed by a customer service staff, when the user initiates an abnormal inquiry request aiming at the target business, the customer service staff can inquire the reason data for causing the abnormality when the user executes the target business from the database according to the user identifier of the user, and further carry out business reply to the user, thereby not only remarkably improving the business experience of the user, but also greatly improving the efficiency of the customer service staff for processing the user request. In addition, extra codes are not needed to be buried in the service codes, so that maintenance cost of technicians to the service codes can be effectively reduced.
The service reply method based on log processing provided in the present specification can be roughly divided into several processes, as shown in fig. 1.
Fig. 1 is a schematic diagram of steps involved in a business reply method based on log processing provided in the present specification.
First, it is necessary to collect log data generated by each user when executing a target service, and it is necessary to clean out abnormal log data from the collected log data by deployed log analysis configuration. When the log analysis configuration specifies what field is included in the log data, the field belongs to abnormal log data, and the specified field in the log analysis configuration can be a specific field which is determined to appear in the log data when the business execution is abnormal according to actual requirements and experience.
Therefore, each field included in the log data can be matched by the log analysis configuration, and if a field specified in the log analysis configuration is hit in the log data, it is determined that it belongs to the abnormal log data.
When the abnormal log data is cleaned from the log data, in order to facilitate the inquiry of the subsequent customer service personnel, the user identification contained in the abnormal log data needs to be extracted to generate and store the corresponding business abnormal record, and the business abnormal record can be regarded as an abnormal behavior event generated based on the reason data representing the occurrence of the abnormality of the user execution target business and the user identification, so that the abnormal behavior event is stored, and the structured event data is actually written into a database for storage according to a predefined storage strategy so as to facilitate the subsequent inquiry, analysis, management and the like.
After the business anomaly record is stored, customer service personnel can send and back an anomaly query request initiated by a user through a preset checking tool. The checking tool in the specification can be regarded as a tool facing a customer service person, when the customer service person uses the checking tool, an operation interface can be displayed in a screen of a terminal device used by the customer service person, the customer service person can input a user identifier of a user in the operation interface and execute a query operation, the checking tool also generates a query request according to the query operation executed by the customer service person, and the query request is executed to query the reason data of the reason for the abnormality of the target service executed by the user from the database. Service personnel can reply the service to the user through the queried reason data so as to inform the user of the reason for abnormal service.
Further, the specific form of the target service executed by the user may be various, for example, the target service may refer to a video incentive service, that is, under the authorization of the user, the user may obtain a certain reward by browsing short videos, and the specific reward rule may be that the user browses short videos for a certain period of time, or when the number of browsed short videos reaches a preset number, a certain reward (such as a consumption ticket, a cash packet, a platform integral, etc.) may be issued to the user. When the user finds that the corresponding rewards are not successfully received when the user executes the video excitation service, an abnormal inquiry request can be initiated to acquire reasons (such as insufficient duration of browsing short videos, unfilled contact ways of the user, the user belongs to a risk user and the like) causing the rewards to be received through customer service personnel.
As another example, the target service may refer to a financial service, i.e., a user purchases a desired financial investment product according to actual demand. In this process, when the user finds that the purchase of the financial investment product is not successfully completed when executing the financial service, an abnormal inquiry request may be initiated to obtain the reason (such as the risk that the account number of the user is stolen currently, the risk that the user does not perform risk assessment before purchasing the financial investment product, the account balance of the user is insufficient, etc.) that the purchase of the financial investment product fails through the customer service personnel.
The specific form of the other targeted traffic is not illustrated here.
In addition, the methods provided in this specification may involve various forms of systems, and may be broadly divided into two cases:
single system form by single system form is meant that the system executing the target service and the system used by the customer service personnel to reply to the service to the user may be the same system, in which case the whole process involved in the method provided in the present specification is actually completed within one system and does not involve data call between other systems.
In this case, if the above-mentioned abnormal records of the service are stored in the system for executing the target service, a data query interface needs to be set in both systems, so that the system used by the customer service person queries the reason data required by the user from the system for executing the target service and replies to the user based on the query request of the customer service person through the data query interface.
If the above-mentioned abnormal records of the business are stored in the system used by the customer service personnel, a data calling interface needs to be set in the two systems, so that the system used by the customer service personnel can obtain various log data generated by the system for executing the business through the data calling interface, and the abnormal records of the business are generated and stored through cleaning and field extraction of the log data.
Of course, in the form of multiple systems, a system may be separately constructed, where the system may acquire log data from a system executing a target service through a preset interface, and clean and extract fields from the log data to generate a service exception record, and store the service exception record in a local database. When a user initiates an abnormal inquiry request, the system can acquire an inquiry request sent by a system used by customer service personnel through a preset interface, and then inquire out reason data required by the customer service personnel through the inquiry request, so that an inquiry result is returned to the system used by the customer service personnel through the interface.
For convenience of explanation, the service reply method based on log processing provided in the present specification will be described in the form of a single system, and then the form of multiple systems will be described.
The following describes in detail the technical solutions provided by the embodiments of the present specification with reference to the accompanying drawings.
Form of single system
Fig. 2 is a flow chart of a business reply method based on log processing provided in the present specification.
S200, acquiring log data generated when the target service is executed.
In a single system form, the execution subject of the whole method may be a system, which is a system for executing the target service, and a system used by customer service personnel. In the system, different resources and system environments can be allocated for the execution of the target service and the execution of the customer service by customer service personnel. However, it should be noted that, although belonging to the same system, customer service personnel often do not have the right to access log data based on the service requirements.
On the basis, in order to ensure the service experience of the user and improve the efficiency of customer service personnel to reply to the user inquiry, the system can acquire and collect log data generated by each user executing the target service, and clean and extract fields of the log data in the subsequent process, so as to generate a service abnormal record for the customer service personnel to inquire.
If the target service involves execution of a plurality of processes, the system may monitor the execution of each process of the target service in real time, and generate log data in time to report the abnormality when the occurrence of the abnormality is monitored, as shown in fig. 3.
Fig. 3 is a schematic diagram of a system provided in the present disclosure for monitoring execution of each process of a target service and reporting an exception.
In fig. 3, the execution of the target service involves a process 1, a process 2, a process 3.
For example, assuming that the target service is an online shopping service, for a new user of a service platform, before executing the online shopping service, the new user needs to register an account on the service platform, bind the registered account with a payment account, and then execute a ordering operation through a commodity browsing interface.
The account registration, account binding with the payment account, and the user-performed ordering referred to in this example may then all be considered different processes in the online shopping service.
When the system executes the target service, the execution of each process needs to be monitored, and for any process, if the execution of the process is monitored to be abnormal, the execution of the target service can be ended, and abnormal log data aiming at the process can be generated and reported. In the example of fig. 3, if any process is abnormal, the continuous execution of the target service is terminated, and the generated log data records which process the target service is executed when the abnormality occurs.
S202, filtering the log data to determine abnormal log data contained in the log data.
After each log data is obtained, the abnormal log data used for representing the abnormality of the user when the user executes the target service needs to be filtered, and the reasons for the abnormality in the execution process of the target service are recorded in the abnormal log data, wherein the reasons comprise the abnormality reasons caused by the service operation of the user and the reasons caused by the occurrence of problems of the service system. Therefore, the system can perform a matching operation on each log data obtained according to a pre-configured matching procedure, and determine whether the log data is abnormal log data by judging whether the log data contains a specified character string contained in a matching rule.
Here, the matching rule mentioned here may be recorded in the above-mentioned log analysis configuration, in which an abnormal log data is recorded when what field appears in the log data.
The matching rule of log data will be described in detail below with a specific example.
The following is an example of an exception log data:
2024-08-29 17:31:03,154[2187ff3d17249238629862182e7c9b,0.1.2]WARN
impl.PromoCoreServiceImpl-[bargainConsultError]
input:{"playId":"PLAY100677798","userId":"2088042871303291"}
result, "[20000015] member information query fails, userId = mobile phone number is empty, count times do not pass, { }"
The abnormal log data may be processed by the following matching rule.
The Match part of the matching rule Contains a contents matching rule and a Split matching rule.
Contains matching rules:
The matching rule is to check whether the character string of the log data contains a specified character string ("contact is empty, count fail").
The type set to "containers" in the matching rule indicates that this is a content-inclusion-or-not-based matching.
The reverse in the matching rule is set to false, meaning that if a specified string is found, the matching is considered successful, and if true, the reverse logic is indicated, i.e. the matching is successful when not found.
The value in the matching rule is an array containing a list of specified strings that need to be found.
Split matching rules:
This matching rule is used to intercept content from a string contained in the log data according to a particular separator and compare whether the intercepted content is equal to a specified value ("bargain Consult Error").
Setting type to "split" in the matching rule means that this is a matching manner based on the split operation.
LeftStr and rightStr in the matching rule specify separators on the left and right sides, respectively, here "[" and "]".
LeftCount in the matching rule specifies that the left separator should appear several times before starting to intercept the content, 3 times in the example above.
The values in the matching rule contain the expected values to be aligned, i.e., "bargain Consult Error".
For the above example, if the specified character string specified in the content matching rule and the Split matching rule is hit in the log data at the same time, it may be determined that the log data belongs to the abnormal log data, so that the field extraction is further performed on the abnormal log data in the subsequent process.
As can be seen from the above examples, by setting various required matching rules in the log analysis configuration according to actual demands, when matching one log data, the character string contained in the log data can be matched with the specified character string specified in the matching rule, and once the specified character string specified in the matching rule is hit in the log data, it can be determined that the log data belongs to abnormal log data.
It should be noted that, along with the change of the service requirement and the service update, the character string to be matched in the abnormal log data may change or the character string to be matched needs to be newly added, so in practical application, the character string to be matched or the character string to be matched needs to be newly added in the matching rule may be adjusted by adjusting the manner of the log analysis configuration, so as to meet the practical requirement.
The log analysis configuration can be implemented using a domain specific language (Domain Specific Language, DSL) configuration, and because the DSL configuration describes the required rules and trigger logic in a structured manner, a dynamically-generatable and extensible configuration model can be formed to implement dynamic adjustment and extension of matching rules.
S204, extracting the user identification contained in the abnormal log data, and generating and storing a business abnormal record according to the user identification and the reason data corresponding to the abnormal log data.
Because the customer service personnel does not have the authority of calling the log data in the practical application and is difficult to analyze and process the log data, the reason data which can embody the abnormal reason in the log data is required to be stored in a database which can be accessed and inquired by the customer service personnel according to a certain form, thereby facilitating the service solution of the customer service personnel.
Therefore, after filtering the abnormal log data from each log data, the system needs to further generate a service abnormal record based on the extracted user identifier and the reason data corresponding to the abnormal log data, where the reason data is used to represent the reason of the abnormality when executing the target service, and the user identifier needs to be extracted to record the user identifier and the reason data together, so that the customer can query the reason data causing the abnormality of service execution through the user identifier of the user in the subsequent process.
In the log analysis configuration, besides the rule of how to filter the abnormal log data, the rule of extracting the required data can also be recorded, so that the system can extract the user identification from the abnormal log data according to the extraction rule.
The principle of the extraction rule is basically the same as that of the matching rule, and can be understood as the identification and interception of a specific field, and the following description will proceed with the extraction of the user identifier from the exception log data by the system using the above example.
The Field section in the above example defines how a particular Field (e.g., userId) is extracted from log data.
Wherein, for extraction of userId, the content is intercepted based on looking up the specific prefix "userId \\" until the first double-quotation mark is encountered.
Fieldname define the extracted field names.
LeftStr and rightStr are similar to the separators in the previous matching rules for defining the boundaries of the desired extracted data.
LeftCount determines how many times the left separator should appear before extraction is performed.
By the above extraction rule, the user identifier (i.e., userId) contained in the anomaly log data can be extracted. It should be noted that, as can be seen from the above examples, in addition to the user identifier, the log analysis configuration also includes extraction rules for other fields.
Wherein playId in the above example can be understood as the service identification of the target service, and in the extraction process of playId, a user id-like extraction rule is adopted, i.e., the content is intercepted by looking up a specific prefix "playId \\until the first double-quote" is encountered.
For traceId in the above example, it belongs to a core identifier of distributed link tracking, and is mainly used for tracking and associating a complete life cycle of a service request in a distributed system, so traceId can provide multiple purposes in practical application.
For example, traceId may be used throughout the entire business link to ensure that each micro-service can record the processing of a unified request when the business performed by the user involves flowing between the plurality of micro-services, and further for example, by recording traceId into log data, all log data for the same request may be located quickly, even if the log data is scattered across multiple servers.
Whereas for traceId extraction, the corresponding extraction rules are mainly to find the content between the second occurrence "[" up to next "]", which is slightly more complex than userId and playId.
After the user identification is extracted, the system can further generate a business anomaly record which is convenient for subsequent inquiry and store the business anomaly record in a preset database. In the process, a standard text template is arranged in the log analysis configuration, and the system can obtain a business anomaly record through the standard text template.
Continuing with the above example, textTemplate in the above example provides a canonical text for generating business anomaly records from the extracted data. As can be seen from the specification text, the "user contact way is empty and cannot participate in the red-packet-gathering task" is the specification text used for replacing the reason field which represents the reason of the abnormality and is contained in the abnormal log data, and the actual value palyId in the specification text is replaced by the placeholder which is { playId }, so that the system can replace the placeholder which corresponds to the service identifier in the specification text by palyId which is extracted by the extraction rule, thereby obtaining the reason data which corresponds to the abnormal log data.
As can be seen from the above examples, the specification text in the log analysis configuration is actually highly correlated with the target service performed by the user, so different log analysis configurations may be set for different services, and the different log analysis configurations include specification text set for different services. Therefore, when cleaning and field extraction are performed on each log data generated by the target service, it is necessary to determine a log analysis configuration corresponding to the target service according to the service identifier of the target service, further filter each log data according to a matching rule included in the determined log analysis configuration, so as to determine abnormal log data included in each log data, and use a specification file corresponding to the log analysis configuration as cause data corresponding to the abnormal log data, and further generate and store a service abnormal record according to the user identifier extracted from the abnormal log data and the determined cause data.
The standard text may be recorded in the log analysis configuration as in the above example, and of course, the log analysis configuration may not be recorded with a standard file, and the log analysis configuration may be stored in correspondence with the standard file, so that in practical application, the corresponding standard file is determined according to the identification information corresponding to the log analysis configuration.
In addition, as can be seen from the above example, in practice, a field for reflecting the cause of the abnormality of the execution target service is also recorded in the abnormality log data, so that the system may extract this field from the abnormality log data according to a preset extraction rule, and further generate a service abnormality record according to the extracted field and the user identifier. The manner of extracting the field may refer to the manner of extracting the user identifier and other identifiers, which will not be described in detail herein.
Besides the user identifier and the reason data, the business identifier and traceId can also be recorded in the business anomaly record generated by the system, so that the reason of the anomaly of the target business can be further analyzed.
In this specification, a business anomaly record may be generated according to a preset format, where the business anomaly record may be understood as an abnormal behavior event, so that the system may write structured event data (i.e., the generated business anomaly record) into a database for storage, where the generated business anomaly record is as follows:
The params in the business anomaly record is an object, which contains playId attributes. In the above example, playId may identify the packet-in-packet service that the user specifically participates in, so that it is placed in the params object, so that the data structure may be kept clear, and subsequent service expansion is facilitated.
And traceId, being a unique identifier of a single request, is a tracking identifier that acts throughout the entire request lifecycle and thus is typically present alone. While userId is an identifier that is used to uniquely identify a user, it also needs to be present alone because it is directly associated with the user entity.
S206, responding to an abnormal inquiry request initiated by a user aiming at the target service, inquiring reason data of reasons for abnormal occurrence when the target service is executed based on the stored service abnormal record according to the user identification of the user, and replying to the user based on the reason data.
When the target service executed by the user is abnormal, an abnormal inquiry request can be initiated through the terminal equipment used by the user, and after the system receives the abnormal inquiry request, the abnormal inquiry request can be distributed to customer service personnel, and the customer service personnel replies the service to the user.
In this process, the system will display an operation interface to the customer service personnel, and the customer service personnel can fill in the user identifier of the user in the operation interface, so as to query the reason data of the reason for abnormal execution of the target service, as shown in fig. 4.
Fig. 4 is a schematic diagram of an operation interface used by a customer service person provided in the present specification.
The operation interface shown in fig. 4 includes an input box for filling in the user identifier (i.e., the position of the user ID in fig. 4), and an input box for filling in the start and stop time of the user. Customer service personnel can input user identification and start and stop time of target service execution of the user in the input boxes, and touch the search control in FIG. 4 to obtain a required query result.
In fig. 4, a total of 3 records causing abnormal execution of the target service by the user are queried, where the target service in the example of fig. 4 may be a shared rewards service, that is, the user may obtain a certain rewards by sharing the service link to other users, and as the number of other users executing the service based on the received service link increases, the rewards obtained by the user sharing the service link also increases.
Therefore, in fig. 4, the "failure in the recommendation phase" refers to that the number of the service links shared by the users is insufficient, in other words, the number of other users receiving the service links and executing the service is not satisfied, and the "failure in the query phase" refers to that when the other users execute the service based on the service links, the other users will query whether the other users belong to the users in the preset blacklist according to the user identification of the other users, if yes, the other users are determined to have risks, and further the service is refused to be provided for the other services.
The customer service personnel can touch the link of the detailed information in fig. 4, and through the link, the customer service personnel can check the detailed reason of the abnormal execution business of the user and reply the user.
It should be noted that the operation interface illustrated in fig. 4 may also be presented to a technician of the target service, where the technician may copy traceId by clicking on "copy traceId" in fig. 4, and by touching "jump cloud image" to present each process involved in performing the service by the user (so, the cloud image is used to represent each process involved in a service). The technician can track the log data generated by each process through the copied traceId, so that the whole business link is analyzed.
After inquiring the reason data of the reason for abnormal execution business, the customer service personnel can reply the business to the user through the system, so that the user is informed of the reason for abnormal execution business.
From the above, it can be seen that, since the log data can be processed in advance to be stored according to the data extracted from the abnormal log data in the form of subsequent query, even if the customer service personnel does not have the authority of calling the log data, the customer service personnel can quickly query the reason data from the pre-stored abnormal records of each service based on the user identification of the user and reply to the user, which can effectively improve the service experience of the user and also improve the efficiency of the customer service personnel in processing the abnormal query request of the user.
In addition, the method provided by the specification does not need to embed additional codes into the service codes, so that the redundancy degree of the service codes is effectively reduced, and the cost of maintaining the service codes by technicians is further effectively reduced.
Multiple system format
In this specification, a system used by a customer service person and a system for executing a target service may be different systems, and herein, the system for executing the target service may be referred to as a first system and the system used by the customer service person may be referred to as a second system.
On the basis, a system can be independently constructed, a preset interface is arranged between the system and the first system and between the system and the second system, the system can realize the filtering and the field extraction of log data through the set interfaces, store the generated business anomaly record, receive the inquiry request sent by customer service personnel and reply the inquiry result to the customer service personnel, so that the customer service personnel replies the business to the user based on the obtained inquiry result.
Specifically, the system can obtain each log data generated when the target service is executed from the first system through a preset first interface. In the process, the system can monitor log data generated in the execution process of the target service through a preset monitor, and acquire the log data through the first interface once the log data is monitored.
Of course, the system may periodically acquire each log data generated by the target service execution from the first system, where the periodically acquiring log data may be that the system actively initiates a log data acquisition request to the first system, or that the first system periodically actively synchronizes each log data generated by the target service execution to the system.
After obtaining each log data, the system may filter each log data according to the manner of step S202 to step S206 to determine the abnormal log data, and extract the required fields from the abnormal log data to generate the business abnormal record. Wherein the generated business anomaly record may be stored in a local database of the system.
When the user executes the target service and is abnormal, an abnormal inquiry request can be sent to a second system used by the customer service personnel, and the customer service personnel sends an inquiry request containing the user identification to the system through the second system based on the abnormal inquiry request.
After the system receives the query request through the preset second interface, the system can query the business exception record matched with the user identifier from the local database through the user identifier carried in the query request as a target record, and then, based on the reason data contained in the target record, a query result is returned to the second system. Customer service personnel can reply the service to the user through the query result returned by the system.
It can be seen that the above example actually replies to the user through a separately constructed system, and in fact, the filtering of the log data and the field extraction may be directly performed by using the first system or the second system, and the reply is performed by the second system, which is already described in the above content and will not be described in detail herein.
It should be noted that, with the development of the service and the change of the actual demand, it may be desirable to further record the required additional data based on the original log data content, so as to perform the anomaly identification on the service executed by the user through the additional data.
Therefore, the special data generated in the service execution process can be captured by creating an additional API, and then the special data is written into the log data according to a certain format, so that more basis is provided for customer service personnel to reply to the service of the user while the service safety of the user is ensured.
Fig. 5 is a schematic structural view of an apparatus provided in the present specification. Referring to fig. 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 storage 510, although other hardware required for other functions may be included. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 502 reading a corresponding computer program from the non-volatile storage 510 into the memory 508 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device 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 may also be hardware or a logic device.
Referring to fig. 6, a service reply device based on log processing provided in the present disclosure may be applied to a device shown in fig. 5, so as to implement the technical solution of the present disclosure. Wherein the apparatus may comprise:
an acquisition module 600, configured to acquire log data generated when the target service is executed;
A filtering module 602, configured to filter each log data to determine abnormal log data included in each log data, where the abnormal log data is used to indicate that an abnormality occurs when the target service is executed;
An extracting module 604, configured to extract a user identifier included in the anomaly log data, so as to generate a service anomaly record according to the user identifier and reason data corresponding to the anomaly log data, and store the service anomaly record, where the reason data is used to represent a cause of an anomaly occurring when the target service is executed;
And a query module 606, configured to query, based on the stored service exception record, cause data of a cause of the exception when the target service is executed according to a user identifier of the user in response to an exception query request initiated by the user for the target service, so as to reply to the user based on the cause data.
Optionally, the filtering module 602 is specifically configured to determine, for each log data, that the log data is abnormal log data if it is determined that the log data includes a specified string according to a pre-configured matching rule.
Optionally, the filtering module 602 is specifically configured to determine a log analysis configuration corresponding to the target service, and filter each log data according to a matching rule included in the log analysis configuration to determine abnormal log data included in each log data.
Optionally, the extracting module 604 is specifically configured to determine a log analysis configuration corresponding to the target service, and use a canonical text corresponding to the log analysis configuration as the reason data corresponding to the abnormal log data, so as to generate and store a service abnormal record according to the user identifier and the reason data.
Optionally, the first system executes the target service, and the second system replies the service to the user;
The obtaining module 600 is specifically configured to obtain, through a preset first interface, each log data generated when the target service is executed from the first system;
The query module 606 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 according to an abnormal query request sent by the user, query, according to a user identifier of the user carried in the query request, a business abnormal record matching with the user identifier of the user, as a target record, and return, according to cause data included in the target record, a query result to the second system, so that the second system replies to the user based on the query result.
Based on the same conception as the above method, the present specification also provides an electronic device comprising a processor, a memory for storing executable instructions of the processor, wherein the processor implements the steps of the method according to any of the embodiments described above by executing the executable instructions.
Based on the same conception as the above method, the present specification also provides a computer readable storage medium having stored thereon computer instructions which when executed by a processor perform the steps of the method according to any of the above embodiments.
Based on the same conception as the above method, the present specification also provides a computer program product comprising a computer program/instruction which, when executed by a processor, implements the steps of the method according to any of the embodiments described above.
The description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.
The foregoing is merely an example of the present specification and is not intended to limit the present specification. Various modifications and alterations to this specification will become apparent to those skilled in the art. Any modifications, equivalent substitutions, improvements, or the like, which are within the spirit and principles of the present description, are intended to be included within the scope of the claims of the present description.