CN111158926B - Service request analysis method, device and equipment - Google Patents
Service request analysis method, device and equipment Download PDFInfo
- Publication number
- CN111158926B CN111158926B CN201911275981.XA CN201911275981A CN111158926B CN 111158926 B CN111158926 B CN 111158926B CN 201911275981 A CN201911275981 A CN 201911275981A CN 111158926 B CN111158926 B CN 111158926B
- Authority
- CN
- China
- Prior art keywords
- request
- trace identifier
- service request
- diffusion ratio
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000004458 analytical method Methods 0.000 title claims abstract description 87
- 238000009792 diffusion process Methods 0.000 claims abstract description 94
- 238000000034 method Methods 0.000 claims abstract description 48
- 238000012545 processing Methods 0.000 claims abstract description 41
- 238000011144 upstream manufacturing Methods 0.000 claims abstract description 35
- 238000004590 computer program Methods 0.000 claims description 7
- 238000011161 development Methods 0.000 claims description 7
- 230000005856 abnormality Effects 0.000 claims description 5
- 230000004044 response Effects 0.000 abstract description 17
- 230000002159 abnormal effect Effects 0.000 abstract description 13
- 206010033799 Paralysis Diseases 0.000 abstract description 11
- 238000004364 calculation method Methods 0.000 description 7
- 230000001186 cumulative effect Effects 0.000 description 7
- 238000012423 maintenance Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000012827 research and development Methods 0.000 description 4
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 210000004709 eyebrow Anatomy 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 238000012216 screening Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses a service request analysis method, a device and equipment, which relate to the technical field of Internet, can accurately evaluate the diffusion ratio of service requests, reduce the possibility of paralysis of a downstream system, and further reduce the response time of the service requests. The method comprises the following steps: acquiring a real-time processing log of a service request; analyzing the real-time processing log, acquiring a Trace identifier which is configured uniquely and corresponds to the upstream system when receiving a service request, and accumulating the request quantity of the same Trace identifier for a functional interface in the downstream system; and determining a problem Trace mark with abnormal diffusion ratio according to the request quantity. The method and the device are suitable for service request analysis.
Description
Technical Field
The present invention relates to the field of internet technologies, and in particular, to a method, an apparatus, and a device for analyzing a service request.
Background
With the rapid development of the internet, users have higher requirements on network services, the scale of platforms for providing services for users has also been larger, and more systems are involved in processing service requests. For example, service request processing of an upstream system sometimes requires invocation of an associated service request of its downstream system.
Currently, a service request of an upstream system is sometimes expanded by a multiple (i.e., a diffusion ratio) and applied to a downstream system. If the number of service requests of the upstream system is huge, the related service requests of the downstream system are called to realize. Therefore, if the diffusion ratio cannot be well estimated and solved, once the service request flow of the upstream system is instantaneously gushed in, the service request of the downstream system is amplified according to the diffusion ratio coefficient, so that the downstream system instantaneously gushes in to exceed the service request born by the system to cause system paralysis, and further the service request response time is prolonged or the service request response cannot be made at all.
Disclosure of Invention
In view of this, the present application provides a method, an apparatus and a device for analyzing a service request, which mainly aims to solve the technical problems that in the prior art, a diffusion ratio cannot be well estimated and solved, so that the number of instantaneous service requests possibly gushed in a downstream system cannot be well estimated in advance, and further, the downstream system is paralyzed, and the service request response duration is increased or the request response cannot be made at all.
According to one aspect of the present application, there is provided a service request analysis method, the method including:
acquiring a real-time processing log of a service request;
analyzing the real-time processing log, acquiring a Trace (Trace) identifier corresponding to unique configuration when an upstream system receives a service request, and accumulating the request quantity of the same Trace identifier for a functional interface in a downstream system;
and determining a problem Trace mark with abnormal diffusion ratio according to the request quantity.
Optionally, the determining, according to the request amount, a problem Trace identifier that the diffusion ratio has an abnormality specifically includes:
and determining the problem Trace identification according to the accumulated request quantity of the same Trace identification for the single functional interface and/or the total accumulated request quantity of the same Trace identification for each functional interface.
Optionally, the determining the problem Trace identifier according to the accumulated request quantity of the same Trace identifier for a single functional interface and/or the total accumulated request quantity of the same Trace identifier for each functional interface specifically includes:
and if the accumulated request quantity of the target Trace identifier for the single functional interface is greater than or equal to a first preset threshold value and/or the total accumulated request quantity of the target Trace identifier for each functional interface is greater than or equal to a second preset threshold value, determining the target Trace identifier as the problem Trace identifier.
Optionally, after determining that the diffusion ratio has abnormal problem Trace identification according to the request amount, the method further includes:
counting a first total request quantity of the target page corresponding to the service request received by the upstream system and a second total request quantity of the related calling function interface of the downstream system;
determining the overall diffusion ratio of the service request corresponding to the target page by utilizing the first total request quantity and the second total request quantity;
and generating a request analysis result corresponding to the target page according to the overall diffusion ratio and the problem diffusion ratio corresponding to the problem Trace identifier contained in the target page.
Optionally, the method further comprises:
and if the overall diffusion ratio is larger than or equal to a preset diffusion ratio threshold value and/or the problem diffusion ratio exists in the target page, outputting corresponding alarm information.
Optionally, the request analysis result further includes a user IP corresponding to the request for sending the question Trace identifier and region feature information corresponding to the user IP.
Optionally, the request analysis result further includes detailed data of the problem Trace identifier, where the detailed data is obtained by performing an association search of the detailed log by using the problem Trace identifier.
Optionally, the method further comprises:
counting the request analysis results corresponding to the target page according to a preset time interval;
and performing transverse comparison analysis by referring to the request analysis results obtained by interval statistics.
Optionally, the accumulating the request amount of the same Trace identifier for the functional interface in the downstream system specifically includes:
the same Trace is used for identifying the request quantity of the functional interface and the increment is updated in the same record.
Optionally, the acquiring the real-time processing log of the service request specifically includes:
a real-time processing log of service requests for the offline development phase and/or the online run phase is obtained.
According to another aspect of the present application, there is provided a service request analysis apparatus, the apparatus comprising:
the acquisition module is used for acquiring a real-time processing log of the service request;
the analysis module is used for analyzing the real-time processing log, acquiring a Trace identifier which corresponds to the unique configuration when the upstream system receives the service request, and accumulating the request quantity of the same Trace identifier for the functional interface in the downstream system;
and the determining module is used for determining the problem Trace mark with abnormal diffusion ratio according to the request quantity.
Optionally, the determining module is specifically configured to determine the problem Trace identifier according to an accumulated request amount of the same Trace identifier for a single functional interface and/or a total accumulated request amount of the same Trace identifier for each functional interface.
Optionally, the determining module is specifically further configured to determine the target Trace identifier as the problem Trace identifier if the cumulative request amount of the target Trace identifier for a single functional interface is greater than or equal to a first preset threshold, and/or the total cumulative request amount of the target Trace identifier for each functional interface is greater than or equal to a second preset threshold.
Optionally, the apparatus further includes: a statistics module and a generation module;
the statistics module is used for counting a first total request quantity of the target page corresponding to the service request received by the upstream system and a second total request quantity of the related calling function interface of the downstream system;
the determining module is further configured to determine an overall diffusion ratio of the service request corresponding to the target page by using the first total request amount and the second total request amount;
the generating module is configured to generate a request analysis result corresponding to the target page according to the overall diffusion ratio and a problem diffusion ratio corresponding to a problem Trace identifier included in the target page.
Optionally, the apparatus further includes:
and the output module is used for outputting corresponding alarm information if the overall diffusion ratio is larger than or equal to a preset diffusion ratio threshold value and/or the problem diffusion ratio exists in the target page.
Optionally, the request analysis result further includes a user IP corresponding to the request for sending the question Trace identifier and region feature information corresponding to the user IP.
Optionally, the request analysis result further includes detailed data of the problem Trace identifier, where the detailed data is obtained by performing an association search of the detailed log by using the problem Trace identifier.
Optionally, the apparatus further includes: an analysis module;
the statistics module is further used for counting the request analysis results corresponding to the target page according to a preset time interval;
and the analysis module is used for carrying out transverse comparison analysis by referring to the request analysis results obtained by interval statistics.
Optionally, the parsing module is specifically configured to update the request amount of the same Trace identifier for the functional interface in the same record in an increment manner.
Optionally, the acquiring module is specifically configured to acquire a real-time processing log of the service request in the offline development stage and/or the online operation stage.
According to still another aspect of the present application, there is provided a storage medium having stored thereon a computer program which, when executed by a processor, implements the above-described service request analysis method.
According to still another aspect of the present application, there is provided an entity apparatus for service request analysis, including a storage medium, a processor and a computer program stored on the storage medium and executable on the processor, the processor implementing the service request analysis method described above when executing the program.
By means of the technical scheme, compared with the prior art, the service request analysis method, device and equipment provided by the application can analyze and calculate according to the real-time processing log of the service request, obtain the Trace identifier which is configured uniquely and corresponds to the upstream system when the upstream system receives the service request, and accumulate the request quantity of the same Trace identifier for the functional interface in the downstream system. And finally, timely finding out a problem Trace mark with abnormal diffusion ratio according to the request quantity, further timely judging related business with overlarge diffusion ratio according to the problem Trace mark, helping to well evaluate the quantity of instantaneous business requests possibly gushed in by a corresponding downstream system, thus, corresponding precautionary measures can be made in advance, the paralysis of the downstream system is avoided, the response time of the business requests is reduced, and the business request efficiency is improved.
The foregoing description is only an overview of the technical solutions of the present application, and may be implemented according to the content of the specification in order to make the technical means of the present application more clearly understood, and in order to make the above-mentioned and other objects, features and advantages of the present application more clearly understood, the following detailed description of the present application will be given.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:
fig. 1 is a schematic flow chart of a service request analysis method according to an embodiment of the present application;
fig. 2 is a schematic flow chart of another service request analysis method according to an embodiment of the present application;
fig. 3 is a schematic diagram of an overall framework of an application scenario example provided in an embodiment of the present application;
fig. 4 shows a schematic structural diagram of a service request analysis device according to an embodiment of the present application.
Detailed Description
The present application will be described in detail hereinafter with reference to the accompanying drawings in conjunction with embodiments. It should be noted that, in the case of no conflict, the embodiments and features in the embodiments may be combined with each other.
In order to solve the technical problem that the diffusion ratio cannot be well estimated and solved in the prior art, so that the number of transient service requests possibly gushed in a downstream system cannot be well estimated in advance, and further the downstream system is paralyzed, the service request response time is increased or the request response cannot be made at all, the embodiment provides a service request analysis method, as shown in fig. 1, which comprises the following steps:
101. and acquiring a real-time processing log of the service request.
The real-time processing log may include a real-time processing procedure of the service request sent by the server side to the client, such as time of receiving the service request, which functional interfaces in which systems are correspondingly called after receiving the service request, and processing response time of the service request. The real-time processing log may be obtained from the server side.
For example, according to the service request received by the upstream system, it is determined that the user needs to obtain a service of a certain type with the top ranking, and then the downstream system needs to perform a series of function interface calls such as corresponding service inquiry, sequencing, screening, and the like according to the service type.
The execution body for the present embodiment may be an apparatus or device for service request analysis. The real-time processing log of the service request can be used for analyzing and calculating whether the service with overlarge diffusion ratio exists. It should be noted that in this embodiment, the real-time processing log is used to perform analysis and calculation, instead of calling the application system, and no intrusion and no influence on performance of the application system are caused.
102. Analyzing the acquired real-time processing log, acquiring a Trace identifier which is configured uniquely when the upstream system receives the service request, and accumulating the request quantity of the same Trace identifier for the functional interface in the downstream system.
The upstream system may be understood as a system that performs service interaction with the client, and the downstream system may be understood as a system that supports the upstream system to implement related service functions. An upstream system may correspond to one or more downstream systems based on actual business needs. Trace identification may be a Trace name or ID, etc.
In this embodiment, when the upstream system receives the service request sent by the client, the corresponding Trace identifier is configured correspondingly, and the Trace identifier is attached correspondingly in the service request processing process, so that the Trace identifier can be used to query which function interfaces in which downstream systems are called correspondingly when the service request is processed. The same Trace identity is then accumulated for the requested amount of each functional interface in each downstream system.
103. And determining the problem Trace identifier with abnormal diffusion ratio according to the accumulated request quantity of the same Trace identifier for the functional interface in the downstream system.
For example, the cumulative request quantity of the same Trace identifier for the functional interface in the downstream system is first utilized to calculate the diffusion ratio corresponding to the Trace identifier, and then the diffusion ratio can be compared with a preset threshold value, so that the problem Trace identifier with a large diffusion ratio can be found. When the upstream system receives a small number of service requests about related services corresponding to the problem Trace identifier, too many requests are not gushed to the corresponding downstream system. Once the upstream system receives a large number of service requests about the relevant service corresponding to the problem Trace identifier, the downstream system amplifies according to the large diffusion ratio corresponding to the problem Trace identifier, and the large amount of flow instantaneously gushed in is likely to cause overload of the downstream system and further cause paralysis of the downstream system. Therefore, in this embodiment, an analysis report can be generated for the Trace identifier of the problem, and a corresponding countermeasure for reminding the relevant staff can be timely output.
By applying the service request analysis method, compared with the prior art, the embodiment can analyze and calculate according to the real-time processing log of the service request, acquire the Trace identifier which is configured uniquely and corresponds to the upstream system when receiving the service request, and accumulate the request quantity of the same Trace identifier for the functional interface in the downstream system. And finally, timely finding out a problem Trace mark with abnormal diffusion ratio according to the request quantity, further timely judging related business with overlarge diffusion ratio according to the problem Trace mark, helping to well evaluate the quantity of instantaneous business requests possibly gushed in by a corresponding downstream system, thus, corresponding precautionary measures can be made in advance, the paralysis of the downstream system is avoided, the response time of the business requests is reduced, and the business request efficiency is improved.
Further, as a refinement and extension of the foregoing embodiment, in order to fully describe a specific implementation procedure of the present embodiment, the present embodiment provides another service request analysis method, as shown in fig. 2, where the method includes:
201. a real-time processing log of service requests for the offline development phase and/or the online run phase is obtained.
In this embodiment, in an offline research and development testing stage, the acquisition system performs analysis and calculation on a real-time processing log (prefire log) of a service request, finds a problem Trace identifier with an abnormal diffusion ratio, and counts the problem Trace identifier existing in a service page, so that the service page with a problem and a corresponding service request can be found conveniently in the service research and development stage.
In the online operation stage, an online log processed by the service request is acquired for analysis and calculation, so that a problem Trace identifier with abnormal diffusion ratio can be found in time when the service is initially online, and further, a worker is reminded of correspondingly repairing the service, and the condition that the online service subsequently causes system paralysis is avoided.
According to the logs of the two stages, for the embodiment, the logs of the two stages can be accessed together for comprehensive analysis and calculation, so that the accuracy of finding the service with a large diffusion ratio is improved. For example, although the running environments are different in the research and development stage and the online stage, an excessive diffusion ratio of a certain service is found, and the possibility that the service has a diffusion ratio problem is high, so that relevant staff can be timely reminded to carry out repair treatment.
202. Analyzing the acquired real-time processing log, acquiring a Trace identifier which corresponds to the unique configuration when the upstream system receives the service request, and accumulating the request quantity of the same Trace identifier for the functional interface in the downstream system.
In this embodiment, a real-time script may be configured in advance, and the real-time processing log may be cleaned and summarized by using the real-time script, and statistics of the diffusion ratio number may be performed and updated in real time for the Trace identifier with a problem.
Optionally, accumulating the request amount of the same Trace identifier for the functional interface in the downstream system specifically includes: the same Trace is used to identify the amount of requests for the functional interface, and incremental updates are made in the same record, rather than one new record at a time causing data duplication. In this alternative, data duplication may be reduced, saving data storage space. And because the request quantity of the same Trace identifier for the functional interface is recorded in one log record, the subsequent staff can directly search the record quantity with the diffusion ratio problem, namely the Trace identifier quantity with the diffusion ratio problem can be obtained, and the corresponding related services can be repaired one by one according to the quantity.
203. And determining the problem Trace identification with abnormal diffusion ratio according to the accumulated request quantity of the same Trace identification for the single functional interface and/or the total accumulated request quantity of the same Trace identification for each functional interface.
For this embodiment, when each piece of real-time log data is generated and reaches the executing body side, aggregation statistics can be performed for a specific factor, and analysis is performed on specific Trace under a specific method (functional interface), so that multiple service requests are accumulated and generated, once the request amount is greater than a certain preset threshold (for example, a single Trace may be set here, the request of a single method exceeds 10, and/or the accumulated request of all methods of a single Trace exceeds 20, where the threshold may be modified according to actual service requirements), specific Trace identification, occurrence, request of which method, total request number and other data are updated to the result table as problematic requests for subsequent analysis.
By the method, the problem Trace mark with larger diffusion of the single function interface request in the single downstream system can be accurately judged, so that instantaneous flow impact threat to the downstream system can be timely early warned. The problem Trace mark with larger total diffusion of the request amount of each functional interface in each downstream system can be accurately judged, so that the instant flow impact threat caused to the whole business of each downstream system can be early warned in time.
To illustrate the implementation of step 203, optionally, step 203 may specifically include: if the accumulated request quantity of the target Trace identifier for the single functional interface is greater than or equal to a first preset threshold value and/or the total accumulated request quantity of the target Trace identifier for each functional interface is greater than or equal to a second preset threshold value, the target Trace identifier is determined to be the problem Trace identifier with abnormal diffusion ratio.
The first preset threshold and the second preset threshold can be set according to actual service requirements. In this alternative way, the problem Trace identification of the diffusion ratio abnormality can be accurately determined technically.
204. The statistics target page corresponds to a first total request quantity of the service request received by an upstream system and corresponds to a second total request quantity of the related calling function interface of a downstream system.
205. And determining the overall diffusion ratio of the service request corresponding to the target page by using the counted first total request quantity and second total request quantity.
For example, for each service included in page 1, the total request amount a of these services corresponding to the upstream system receiving the service request is counted as 2000, and the total request amount B corresponding to each downstream system-related call function interface is counted as 4000. Then dividing the total request quantity B by the total request quantity A to obtain the overall diffusion ratio of the business request corresponding to the page 1 as 2.
206. And generating a request analysis result corresponding to the target page according to the determined overall diffusion ratio and the problem diffusion ratio corresponding to the problem Trace identifier contained in the target page.
After the request analysis result is generated and obtained, corresponding output display and the like can be performed. For example, by the analysis mode, the analysis result of the target page about the diffusion ratio problem can be obtained, so that the diffusion ratio problem existing in the target page can be found in time.
Optionally, the method of this embodiment may include: and if the integral diffusion ratio corresponding to the target page is larger than or equal to the preset diffusion ratio threshold value and/or the target page has a problem diffusion ratio, outputting corresponding alarm information. So that corresponding staff can maintain corresponding business in the page in time, and the subsequent risk of causing instantaneous flow impact to a downstream system is reduced.
Since in practical applications, the number of functional interface requests generated for the downstream system call will be different for the requests of different users for the same service in the same page. Therefore, optionally, the generated request analysis result may further include a user IP corresponding to the request for sending the question Trace identifier, region feature information corresponding to the user IP, and the like. Meanwhile, the service corresponding to the problem Trace is identified in the target page, and the request analysis result can also contain the request conditions of other user IP for the same service in the same page, such as specific diffusion ratio, the region characteristic information corresponding to the other user IP, and the like. Therefore, in the process of analyzing the user access of the same service in the same page, the staff is convenient to analyze that the problem of relatively large diffusion exists after the user in which region accesses the service, and the problem of relatively large diffusion does not exist after the user in which region accesses the service, so that the purpose of corresponding maintenance according to territory can be realized, the large-scale blind maintenance is reduced, the maintenance efficiency is improved, and the maintenance cost is reduced.
Further, in order to facilitate the staff to check the detailed data of the problem Trace identifier, optionally, the request analysis result may further include the detailed data of the problem Trace identifier, where the detailed data is obtained by performing an association search of the detailed log by using the problem Trace identifier. For example, by the search function of a Simple Log Service (SLS) log platform, when a problematic Trace identification is found, an associated search of detail logs may be performed using the platform and then stored in ES (Elastic Search).
Based on the foregoing embodiments, the data may be aggregated according to TDDL (Taobao Distribute Data Layer), so as to generate an analysis report (not only problematic issue data, but also related data without problems), such as a visual report, or the like. And further, staff can count the request quantity of the page, the request quantity of the method, other indexes (such as average packet size, average response time, response time variance, diffusion ratio of Resource and the like) and the like, so that the transverse and longitudinal comparison analysis is convenient.
Wherein for the transverse comparison analysis process, optionally, specific processes thereof may include: counting the request analysis results corresponding to the target page according to a preset time interval; and then performing transverse comparison analysis by referring to the request analysis results obtained by interval statistics. For example, according to the daily request amount of a certain page, the daily request amount of a method, the diffusion ratio and the like, the fluctuation condition of each day is analyzed, and further, content with reference value is found out, so that the maintenance and update of related business in the page are conveniently guided.
In order to facilitate understanding of the specific implementation process of the method of the present embodiment, the following application scenario is given, but not limited thereto:
at present, for a meeting place page of a network platform, the meeting place page plays an important service guiding role, and meanwhile, the concentrated flow of the meeting place page brings huge flow to a downstream system, if the diffusion ratio cannot be evaluated and the problem of large diffusion ratio is found, the instant flow collapses the downstream system and the paralysis of the service function of the service of the whole downstream system is caused, so that the problem of the diffusion ratio can be found in the research and development and verification stages in real time (although the total flow amount is not large at this time) is a matter of urgent eyebrows, and therefore, the method of the embodiment aims to more effectively and intuitively find the problem of large diffusion ratio in advance and avoid similar online faults.
Therefore, the method based on the embodiment is equivalent to designing a system for carrying out real-time statistics, aggregation and monitoring of response time and diffusion ratio by using logs, so that workers can pay attention to huge icebergs under the water surface better, and the exposure to submerged reefs is avoided. For example, as shown in fig. 3, the present system may utilize a system application log on the server side as input data. Firstly, the TT log represents the real-time processing log content of the business request in the application log, by performing real-time calculation on the TT log (for example, analyzing how many requests are accumulated under a specific method by a specific Trace, and updating data such as specific traceID, occurrences, requests of which method, total request times and the like to a result table as problematic requests once the request quantity exceeds a set threshold), and then, going to TDDL aggregate data (for example, the request quantity of pages, the request quantity of methods, and other indexes (for example, average packet size, average response time, response time variance, diffusion ratio of Resource and the like), finally, the data (for example, configured summary and detail report form, which is convenient for intuitively checking the total data and the problematic detail data, and analyzing and positioning) can be summarized. The problem traceID of the diffusion ratio abnormality is found in the real-time calculation and can be stored in the ES, wherein the capability of updating the primary key of the ES is used, and when the method is the same trace+method, the same record can be updated incrementally (only the number of times of increasing is modified) instead of the data repetition caused by a new record each time. And the staff acquires diffusion ratio problem data in the ES and matches and analyzes detail logs on the SLS log platform by using the problem TraceID.
By applying the scheme of the method, compared with the prior art, analysis and calculation can be performed according to the real-time processing log of the service request, the Trace identifier which is configured uniquely and corresponds to the service request is obtained when the upstream system receives the service request, and the request quantity of the same Trace identifier for the functional interface in the downstream system is accumulated. And finally, timely finding out a problem Trace mark with abnormal diffusion ratio according to the request quantity, further timely judging related business with overlarge diffusion ratio according to the problem Trace mark, helping to well evaluate the quantity of instantaneous business requests possibly gushed in by a corresponding downstream system, thus, corresponding precautionary measures can be made in advance, the paralysis of the downstream system is avoided, the response time of the business requests is reduced, and the business request efficiency is improved.
Further, as a specific implementation of the methods of fig. 1 and fig. 2, an embodiment of the present application provides a service request analysis device, as shown in fig. 4, where the device includes: the device comprises an acquisition module 31, a resolution module 32 and a determination module 33.
An obtaining module 31, configured to obtain a real-time processing log of a service request;
the analysis module 32 is configured to analyze the real-time processing log, obtain a Trace identifier corresponding to the unique configuration when the upstream system receives the service request, and accumulate the request amount of the same Trace identifier for the functional interface in the downstream system;
a determining module 33, configured to determine, according to the request amount, a problem Trace identifier that the diffusion ratio has an abnormality.
In a specific application scenario, the determining module 33 may be specifically configured to determine the problem Trace identifier according to a cumulative request amount of the same Trace identifier for a single functional interface and/or a total cumulative request amount of the same Trace identifier for each functional interface.
In a specific application scenario, the determining module 33 may be specifically further configured to determine the target Trace identifier as the problem Trace identifier if the cumulative request amount of the target Trace identifier for a single functional interface is greater than or equal to a first preset threshold, and/or the total cumulative request amount of the target Trace identifier for each functional interface is greater than or equal to a second preset threshold.
In a specific application scenario, the device may further include: a statistics module and a generation module;
the statistics module is used for counting a first total request quantity of the target page corresponding to the service request received by the upstream system and a second total request quantity corresponding to the related call function interface of the downstream system;
the determining module is further configured to determine an overall diffusion ratio of the service request corresponding to the target page by using the first total request amount and the second total request amount;
the generating module is configured to generate a request analysis result corresponding to the target page according to the overall diffusion ratio and a problem diffusion ratio corresponding to a problem Trace identifier included in the target page.
In a specific application scenario, the device further includes: an output module;
and the output module is used for outputting corresponding alarm information if the overall diffusion ratio is larger than or equal to a preset diffusion ratio threshold value and/or the problem diffusion ratio exists in the target page.
In a specific application scenario, optionally, the request analysis result further includes a user IP corresponding to the request for sending the question Trace identifier and region feature information corresponding to the user IP.
In a specific application scenario, optionally, the request analysis result further includes detailed data of a problem Trace identifier, where the detailed data is obtained by performing association search of a detailed log by using the problem Trace identifier.
In a specific application scenario, the device may further include: an analysis module;
the statistics module is further used for counting the request analysis results corresponding to the target page according to a preset time interval;
the analysis module can be used for carrying out transverse comparison analysis on the request analysis results obtained by referring to interval statistics.
In a specific application scenario, the parsing module 32 may be specifically configured to update the request amount of the same Trace identifier for the functional interface in the same record in an incremental manner.
In a specific application scenario, the obtaining module 31 may be specifically configured to obtain a real-time processing log of a service request in an offline development stage and/or an online operation stage.
It should be noted that, other corresponding descriptions of each functional unit related to the service request analysis device provided in this embodiment may refer to corresponding descriptions in fig. 1 and fig. 2, and are not described herein again.
Based on the above-described methods shown in fig. 1 and 2, correspondingly, the present embodiment further provides a storage medium having a computer program stored thereon, which when executed by a processor, implements the above-described service request analysis method shown in fig. 1 and 2.
Based on such understanding, the technical solution of the present embodiment may be embodied in the form of a software product, where the software product may be stored in a nonvolatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.), and includes several instructions to cause a computer device (may be a personal computer, a server, or a network device, etc.) to execute the method described in each implementation scenario of the present embodiment.
Based on the methods shown in fig. 1 and fig. 2 and the virtual device embodiment shown in fig. 4, in order to achieve the above objective, this embodiment further provides an entity device for analyzing a service request, which may specifically be a computer, a server, a smart phone, a tablet computer, a smart watch, or a network device, where the entity device includes a storage medium and a processor; a storage medium storing a computer program; a processor for executing a computer program to implement the service request analysis method as shown in fig. 1 and 2.
Optionally, the physical device may further include a user interface, a network interface, a camera, radio Frequency (RF) circuitry, sensors, audio circuitry, WI-FI modules, and the like. The user interface may include a Display screen (Display), an input unit such as a Keyboard (Keyboard), etc., and the optional user interface may also include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), etc.
It will be appreciated by those skilled in the art that the structure of the entity device for analyzing a service request provided in this embodiment is not limited to the entity device, and may include more or fewer components, or some components may be combined, or different arrangements of components.
The storage medium may also include an operating system, a network communication module. The operating system is a program that manages the physical device hardware and software resources of the service request analysis described above, supporting the execution of information handling programs and other software and/or programs. The network communication module is used for realizing communication among all components in the storage medium and communication with other hardware and software in the information processing entity equipment.
From the above description of the embodiments, it will be apparent to those skilled in the art that the present application may be implemented by means of software plus necessary general hardware platforms, or may be implemented by hardware. By applying the technical scheme of the embodiment, compared with the prior art, the method and the device can analyze and calculate according to the real-time processing log of the service request, acquire the Trace identifier which is configured uniquely and corresponds to the upstream system when receiving the service request, and accumulate the request quantity of the same Trace identifier for the functional interface in the downstream system. And finally, timely finding out a problem Trace mark with abnormal diffusion ratio according to the request quantity, further timely judging related business with overlarge diffusion ratio according to the problem Trace mark, helping to well evaluate the quantity of instantaneous business requests possibly gushed in by a corresponding downstream system, thus, corresponding precautionary measures can be made in advance, the paralysis of the downstream system is avoided, the response time of the business requests is reduced, and the business request efficiency is improved.
Those skilled in the art will appreciate that the drawings are merely schematic illustrations of one preferred implementation scenario, and that the modules or flows in the drawings are not necessarily required to practice the present application. Those skilled in the art will appreciate that modules in an apparatus in an implementation scenario may be distributed in an apparatus in an implementation scenario according to an implementation scenario description, or that corresponding changes may be located in one or more apparatuses different from the implementation scenario. The modules of the implementation scenario may be combined into one module, or may be further split into a plurality of sub-modules.
The foregoing application serial numbers are merely for description, and do not represent advantages or disadvantages of the implementation scenario. The foregoing disclosure is merely a few specific implementations of the present application, but the present application is not limited thereto and any variations that can be considered by a person skilled in the art shall fall within the protection scope of the present application.
Claims (18)
1. A method for analyzing a service request, comprising:
aiming at a service request sent to an upstream system by a client, acquiring a real-time processing log of the service request, wherein the upstream system calls a functional interface of a downstream system according to a diffusion ratio;
analyzing the real-time processing log, acquiring a Trace identifier which corresponds to the unique configuration when the upstream system receives the service request, and accumulating the request quantity of the same Trace identifier for a functional interface in the downstream system;
and if the accumulated request quantity of the target Trace identifier for the single functional interface is greater than or equal to a first preset threshold value and/or the total accumulated request quantity of the target Trace identifier for each functional interface is greater than or equal to a second preset threshold value, determining the target Trace identifier as a problem Trace identifier.
2. The method of claim 1, wherein after determining, based on the request amount, a problem Trace identification that a diffusion ratio has an abnormality, the method further comprises:
counting a first total request quantity of the target page corresponding to the service request received by the upstream system and a second total request quantity of the related calling function interface of the downstream system;
determining the overall diffusion ratio of the service request corresponding to the target page by utilizing the first total request quantity and the second total request quantity;
and generating a request analysis result corresponding to the target page according to the overall diffusion ratio and the problem diffusion ratio corresponding to the problem Trace identifier contained in the target page.
3. The method according to claim 2, wherein the method further comprises:
and if the overall diffusion ratio is larger than or equal to a preset diffusion ratio threshold value and/or the problem diffusion ratio exists in the target page, outputting corresponding alarm information.
4. The method of claim 2, wherein the request analysis result further includes a problem Trace identifier corresponding to a user IP sending the request, and region feature information corresponding to the user IP.
5. The method of claim 2, wherein the request analysis result further comprises detailed data of a problem Trace identifier, and the detailed data is obtained by performing an association search of a detailed log by using the problem Trace identifier.
6. The method according to any one of claims 2 to 5, further comprising:
counting the request analysis results corresponding to the target page according to a preset time interval;
and performing transverse comparison analysis by referring to the request analysis results obtained by interval statistics.
7. The method of claim 1, wherein accumulating the request amount of the same Trace identifier for the functional interface in the downstream system specifically comprises:
the same Trace is used for identifying the request quantity of the functional interface and the increment is updated in the same record.
8. The method according to claim 1, wherein the obtaining a real-time processing log of the service request specifically comprises:
a real-time processing log of service requests for the offline development phase and/or the online run phase is obtained.
9. A service request analysis apparatus, comprising:
the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring a real-time processing log of a service request aiming at the service request sent to an upstream system by a client, wherein the upstream system calls a functional interface of a downstream system according to a diffusion ratio;
the analysis module is used for analyzing the real-time processing log, acquiring a Trace identifier which corresponds to the unique configuration when the upstream system receives the service request, and accumulating the request quantity of the same Trace identifier for the functional interface in the downstream system;
and the determining module is used for determining the target Trace identifier as the problem Trace identifier if the accumulated request quantity of the target Trace identifier for the single functional interface is greater than or equal to a first preset threshold value and/or the total accumulated request quantity of the target Trace identifier for each functional interface is greater than or equal to a second preset threshold value.
10. The apparatus of claim 9, wherein the apparatus further comprises: a statistics module and a generation module;
the statistics module is used for counting a first total request quantity of the target page corresponding to the service request received by the upstream system and a second total request quantity of the related calling function interface of the downstream system;
the determining module is further configured to determine an overall diffusion ratio of the service request corresponding to the target page by using the first total request amount and the second total request amount;
the generating module is configured to generate a request analysis result corresponding to the target page according to the overall diffusion ratio and a problem diffusion ratio corresponding to a problem Trace identifier included in the target page.
11. The apparatus of claim 10, wherein the apparatus further comprises:
and the output module is used for outputting corresponding alarm information if the overall diffusion ratio is larger than or equal to a preset diffusion ratio threshold value and/or the problem diffusion ratio exists in the target page.
12. The apparatus of claim 10, wherein the request analysis result further comprises a problem Trace identifier corresponding to a user IP sending the request, and region characteristic information corresponding to the user IP.
13. The apparatus of claim 10, wherein the request analysis result further comprises detailed data of a problem Trace identifier, and the detailed data is obtained by performing an association search of a detailed log by using the problem Trace identifier.
14. The apparatus according to any one of claims 10 to 13, further comprising: an analysis module;
the statistics module is further used for counting the request analysis results corresponding to the target page according to a preset time interval;
and the analysis module is used for carrying out transverse comparison analysis by referring to the request analysis results obtained by interval statistics.
15. The apparatus of claim 9, wherein the device comprises a plurality of sensors,
the analysis module is specifically configured to update the request amount of the same Trace identifier for the functional interface in the same record in an increment manner.
16. The apparatus of claim 9, wherein the device comprises a plurality of sensors,
the acquisition module is specifically configured to acquire a real-time processing log of a service request in an offline development stage and/or an online operation stage.
17. A storage medium having stored thereon a computer program, wherein the program when executed by a processor implements the service request analysis method of any of claims 1 to 8.
18. A service request analysis device comprising a storage medium, a processor and a computer program stored on the storage medium and executable on the processor, characterized in that the processor implements the service request analysis method according to any one of claims 1 to 8 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911275981.XA CN111158926B (en) | 2019-12-12 | 2019-12-12 | Service request analysis method, device and equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911275981.XA CN111158926B (en) | 2019-12-12 | 2019-12-12 | Service request analysis method, device and equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111158926A CN111158926A (en) | 2020-05-15 |
| CN111158926B true CN111158926B (en) | 2024-01-30 |
Family
ID=70557024
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911275981.XA Active CN111158926B (en) | 2019-12-12 | 2019-12-12 | Service request analysis method, device and equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111158926B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112866055A (en) * | 2021-01-05 | 2021-05-28 | 广州品唯软件有限公司 | Service flow evaluation method and device, computer equipment and storage medium |
| CN113434135B (en) * | 2021-06-28 | 2023-06-16 | 青岛海尔科技有限公司 | Method and device for determining call repeatability of interface, storage medium and electronic device |
| CN115082133B (en) * | 2022-08-19 | 2022-11-18 | 深圳云威网络科技有限公司 | Target page flow analysis management system and method |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104486138A (en) * | 2014-11-25 | 2015-04-01 | 北京奇虎科技有限公司 | Flow monitoring method and device and monitoring server |
| CN108600034A (en) * | 2018-05-28 | 2018-09-28 | 腾讯科技（深圳）有限公司 | Traffic pressure management method, device, equipment, system and storage medium |
| CN108683604A (en) * | 2018-04-03 | 2018-10-19 | 平安科技（深圳）有限公司 | concurrent access control method, terminal device and medium |
| CN109327353A (en) * | 2018-09-29 | 2019-02-12 | 阿里巴巴集团控股有限公司 | Service traffics determine method, apparatus and electronic equipment |
| CN109669982A (en) * | 2018-12-25 | 2019-04-23 | 钛马信息网络技术有限公司 | The called statistical system of platform interface and method |
| CN110109955A (en) * | 2019-03-15 | 2019-08-09 | 平安科技（深圳）有限公司 | Data call amount statistical method, system, computer installation and readable storage medium storing program for executing |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8738759B2 (en) * | 2004-09-23 | 2014-05-27 | Hewlett-Packard Development Company, L.P. | System and method for service response monitoring |
-
2019
- 2019-12-12 CN CN201911275981.XA patent/CN111158926B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104486138A (en) * | 2014-11-25 | 2015-04-01 | 北京奇虎科技有限公司 | Flow monitoring method and device and monitoring server |
| CN108683604A (en) * | 2018-04-03 | 2018-10-19 | 平安科技（深圳）有限公司 | concurrent access control method, terminal device and medium |
| CN108600034A (en) * | 2018-05-28 | 2018-09-28 | 腾讯科技（深圳）有限公司 | Traffic pressure management method, device, equipment, system and storage medium |
| CN109327353A (en) * | 2018-09-29 | 2019-02-12 | 阿里巴巴集团控股有限公司 | Service traffics determine method, apparatus and electronic equipment |
| CN109669982A (en) * | 2018-12-25 | 2019-04-23 | 钛马信息网络技术有限公司 | The called statistical system of platform interface and method |
| CN110109955A (en) * | 2019-03-15 | 2019-08-09 | 平安科技（深圳）有限公司 | Data call amount statistical method, system, computer installation and readable storage medium storing program for executing |
Non-Patent Citations (3)
| Title |
|---|
| João V. P. Gomes.Source traffic analysis.《ACM Transactions on Multimedia Computing, Communications, and Applications》.2010,第6卷(第3期),全文. * |
| 赖蔚蔚 ; .基于基线算法的电力企业信息网异常流量检测的实现.机电信息.2014,(第36期),全文. * |
| 马升康.QoE驱动的DASH动态负载均衡关键技术研究.中国优秀博硕士学位论文全文数据库(硕士)信息科技辑》.2019,(第06期),全文. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111158926A (en) | 2020-05-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111522922B (en) | Log information query method and device, storage medium and computer equipment | |
| US20170155570A1 (en) | Analysis of site speed performance anomalies caused by server-side issues | |
| CN111158926B (en) | Service request analysis method, device and equipment | |
| US8204928B2 (en) | System and method for analyzing internet usage | |
| CN108156141B (en) | Real-time data identification method and device and electronic equipment | |
| CN109995555B (en) | Monitoring method, device, equipment and medium | |
| CN109309596A (en) | A kind of method for testing pressure, device and server | |
| CN110348471B (en) | Abnormal object identification method, device, medium and electronic equipment | |
| US20160203337A1 (en) | Identifying private information from data streams | |
| CN110519263B (en) | Anti-swipe method, device, apparatus, and computer-readable storage medium | |
| CN111611519B (en) | Method and device for detecting personal abnormal behaviors | |
| US20190188593A1 (en) | Method and system for reducing risk values discrepancies between categories | |
| CN109684863B (en) | Data leakage prevention method, device, equipment and storage medium | |
| CN112364267A (en) | Front-end data acquisition method and device | |
| CN108804501B (en) | Method and device for detecting effective information | |
| CN114445088A (en) | Method and device for judging fraudulent conduct, electronic equipment and storage medium | |
| CN106789277B (en) | User behavior determination method and device based on state machine model | |
| US9645877B2 (en) | Monitoring apparatus, monitoring method, and recording medium | |
| CN113609202A (en) | Data processing method and device | |
| CN111506455A (en) | Checking method and device for service release result | |
| CN112541183B (en) | Data processing method and device, edge computing equipment and storage medium | |
| KR101553923B1 (en) | Apparatus and method for analyzing system usage | |
| CN113452533B (en) | Charging self-inspection and self-healing method and device, computer equipment and storage medium | |
| CN106649343B (en) | Network data information processing method and equipment | |
| CN111416744B (en) | Method and device for monitoring and alarming on internet |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |