CN115460288A

CN115460288A - Detection method and device for call link

Info

Publication number: CN115460288A
Application number: CN202210923545.4A
Authority: CN
Inventors: 朱烨操
Original assignee: Dingtalk China Information Technology Co Ltd
Current assignee: Dingtalk China Information Technology Co Ltd
Priority date: 2022-08-02
Filing date: 2022-08-02
Publication date: 2022-12-09

Abstract

One or more embodiments of the present specification provide a detection method and apparatus for a call link, which are applied to a server, where a target service is deployed on the server; the target service comprises at least one calling link which is composed of a plurality of sub-services according to a preset calling sequence; the method comprises the following steps: responding to a service request aiming at a target service sent by a client, and acquiring the call flow of the service request aiming at the target service; the call flow comprises call data generated when the service request calls a plurality of sub-services, and the call data is combined according to a preset call sequence of the sub-services; performing abnormal call analysis on the call flow to determine whether the call flow is abnormal call flow; and if the calling flow is abnormal calling flow, pushing a target calling link corresponding to the abnormal calling flow to a user corresponding to the target service in the form of abnormal flow alarm so as to prompt the user to carry out abnormal positioning on the target calling link.

Description

Detection method and device for call link

Technical Field

The present disclosure relates to the field of distributed system technologies, and in particular, to a method and an apparatus for detecting a call link.

Background

With the development of the internet, more and more application scenes are provided for users to call by deploying user services on a service end. With the diversified development of user requirements, the service functions that can be provided by the user services deployed on the service end are gradually developed in a diversified direction.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and an apparatus for detecting a call link to solve the problems in the related art.

To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of an embodiment of the present specification, a detection method for a call link is provided, which is applied to a server, where a target service is deployed on the server; the target service comprises at least one calling link which is composed of a plurality of sub-services according to a preset calling sequence; the method comprises the following steps:

responding to a service request aiming at the target service sent by a client, and acquiring the call flow of the service request aiming at the target service; the call flow comprises call data generated when the service request calls the plurality of sub-services, and the call data are combined according to a preset call sequence of the sub-services;

performing abnormal call analysis on the call flow to determine whether the call flow is abnormal call flow;

and if the calling flow is abnormal calling flow, pushing a target calling link corresponding to the abnormal calling flow to a user corresponding to the target service in the form of abnormal flow alarm so as to prompt the user to perform abnormal positioning on the target calling link.

According to a second aspect of the embodiments of the present specification, there is provided a detection apparatus for a call link, which is applied to a server, where a target service is deployed on the server; the target service comprises at least one calling link which is composed of a plurality of sub-services according to a preset calling sequence; the device comprises:

the flow acquisition module is used for responding to a service request aiming at the target service sent by a client and acquiring the call flow of the service request aiming at the target service; the call flow comprises call data generated when the service request calls the plurality of sub-services, and the call data are combined according to a preset call sequence of the sub-services;

the flow analysis module is used for carrying out abnormal call analysis on the call flow so as to determine whether the call flow is abnormal call flow;

and the flow positioning module is used for pushing a target calling link corresponding to the abnormal calling flow to a user corresponding to the target service in an abnormal flow alarm mode when the calling flow is abnormal calling flow so as to prompt the user to perform abnormal positioning on the target calling link.

According to a third aspect of embodiments herein, there is provided an electronic device, including a communication interface, a processor, a memory, and a bus, where the communication interface, the processor, and the memory are connected to each other through the bus;

the memory stores computer readable instructions, and the processor executes the method by calling the computer readable instructions.

According to a fourth aspect of embodiments herein, there is provided a computer-readable storage medium storing computer-readable instructions which, when invoked and executed by a processor, implement the above-described method.

The technical scheme provided by the embodiment of the specification can have the following beneficial effects:

according to the technical scheme, abnormal calling aiming at the target service and the calling link with the abnormal calling can be found in time, so that related personnel can not need to manually position the calling link with the abnormal calling, the time cost for finding the abnormal calling link can be reduced, and the efficiency of the related personnel for processing the abnormal calling link with the abnormal problems can be improved. Moreover, the hidden abnormal call links which cannot be found through manual positioning can be found in time, so that the problem that the calling performance of the target service is influenced due to omission of the abnormal call links can be avoided.

Drawings

Fig. 1 is a schematic diagram of an architecture of a detection system for invoking a link according to an exemplary embodiment.

Fig. 2 is a flowchart of a method for detecting a call link according to an exemplary embodiment.

Fig. 3 is a system architecture diagram of a server according to an exemplary embodiment.

Fig. 4 is a schematic structural diagram of an electronic device in which a detection apparatus for invoking a link is provided according to an exemplary embodiment.

Fig. 5 is a block diagram of a detection apparatus for invoking a link according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Fig. 1 is a schematic diagram of an architecture of a detection system for invoking a link according to an exemplary embodiment. As shown in fig. 1, the system may include a network 10, a server 11, a plurality of electronic devices, such as a mobile phone 12, a mobile phone 13, a mobile phone 14, and the like.

The server 11 may be a physical server comprising a separate host, or the server 11 may be a virtual server, a cloud server, etc. carried by a cluster of hosts. Handsets 12-14 are just one type of electronic device that a user may use. In fact, it is obvious that the user can also use electronic devices of the type such as: tablet devices, notebook computers, personal Digital Assistants (PDAs), wearable devices (e.g., smart glasses, smart watches, etc.), etc., which are not limited by one or more embodiments of the present disclosure. The network 10 may include various types of wired or wireless networks.

In one embodiment, the server 11 may cooperate with handsets 12-14; the mobile phones 12 to 14 may collect call traffic, upload the collected call traffic to the server 11 through the network 10, and then the server 11 processes the received call traffic based on the detection scheme of the present specification, so as to implement detection of the call link. In another embodiment, the handsets 12-14 may independently implement the detection scheme of the present description; the mobile phones 12 to 14 collect the call links, and process the received call traffic based on the detection scheme of the present specification, so as to detect the call links.

Under the influence of such demands, the user services deployed on the service end gradually evolve into services with higher diversity, which are formed by combining a plurality of sub-services according to a certain calling sequence. For such services, because the sub-services constituting the service have diversity, the sub-services included in the service are freely combined based on the user's requirements, a plurality of different call links can be formed, and different service functions can be provided for the user through the different call links.

Although a plurality of calling links can be formed by freely combining the sub-services included in the service, so that the service functions provided by the service are richer, with the increase of the calling links, once the abnormal calling links exist in the links, it becomes more and more difficult to quickly and accurately locate the abnormal calling links.

In view of this, the present specification proposes an automatic detection scheme for automatically performing an abnormal call analysis on a call traffic of a service to find an abnormal call link in time.

The scheme conception of this specification lies in:

when receiving a service request aiming at the target service sent by a client, the method can respond to the service request and acquire the call flow of the service request aiming at the target service; the call flow comprises call data generated when the service request calls the plurality of sub-services, and the call data are combined according to a preset call sequence of the sub-services;

then, performing abnormal call analysis on the call flow to determine whether the call flow is an abnormal call flow;

further, if the call flow is an abnormal call flow, a target call link corresponding to the abnormal call flow can be determined, an abnormal flow alarm corresponding to the abnormal call flow is generated, and the abnormal flow alarm is pushed to a user corresponding to the target service to prompt the user to perform abnormal positioning on the target call link.

Through the technical scheme, abnormal calling aiming at the target service and the calling link with the abnormal calling can be found in time, so that related personnel can not need to manually position the calling link with the abnormal calling, the time cost for finding the abnormal calling link can be reduced, and the efficiency of processing the abnormal problem of the abnormal calling link by the related personnel is improved. Moreover, the more concealed abnormal call links which cannot be found through manual positioning can be found in time, so that the call performance of the target service can be prevented from being influenced by omission of the abnormal call links.

The following describes the detection scheme of the call link in detail with reference to the accompanying drawings.

Referring to fig. 2, fig. 2 is a flowchart of a detection method for a call link, which is applied to a server. Wherein, a target service can be deployed on the service end; the target service may include at least one call link composed of a plurality of sub-services in a preset call order. As shown in fig. 2, the method comprises the following steps:

step 202, responding to a service request aiming at the target service sent by a client, and acquiring the call flow of the service request aiming at the target service; the call flow comprises call data generated when the service request calls the plurality of sub-services, and the call data are combined according to a preset call sequence of the sub-services;

the target service may be any type of service including a plurality of call links. The target service usually includes a plurality of sub-services, and the call link usually is a link formed by combining a plurality of sub-services according to a preset call sequence.

For example, in one example, the sub-service may be a method that may be invoked by a user; for example, the method that can be called by the user can be the service logic that can be called by the user and is developed by the developer based on a specific programming language. In this case, the target service may be an application program (for example, may be an APP) composed of a plurality of methods that can be called by a user.

In another example, the sub-service may be an application sub-program consisting of a plurality of methods available for invocation. In this case, the target service may be an application program composed of a plurality of application subprograms.

In practical application, a user may send a service request to a server through a client to invoke the target service deployed on the server. After receiving the service request, the server may respond to the service request and invoke the target service in an execution environment of the server.

For example, in an example, after receiving the service request, the server may respond to the service request and sequentially invoke a plurality of sub-services included in the target service according to a preset invoking sequence.

It should be noted that, since the called target service may include multiple call links, after receiving the service request, the server may determine the call links that the service request needs to call first, and then sequentially call each sub-service in the call links according to a preset call sequence. It will be appreciated that different service requests, call links that they need to invoke, will often differ as well.

The specific manner of determining the call link that the service request needs to call is not particularly limited in this specification;

for example, in one example, the invocation link that the service request needs to invoke may be determined based on the type of service request. That is, the different types of service requests, the call links that they need to invoke, will often also differ. In another example, the service request may specifically include a link identifier of a call link that needs to be called, and in this case, the call link that needs to be called by the service request may also be determined based on the link identifier in the service request.

The server side can also obtain the call flow of the service request aiming at the target service in the process of calling the target service in the execution environment.

The call flow may specifically refer to call data generated when the service request calls a plurality of sub-services constituting the target service, and the call data may be combined according to the call order described above. And the call data may generally comprise any form of data relating to service calls to the plurality of sub-services.

For example, in an actual application, the call data may generally include a service identifier of the called sub-service, a call parameter input to the called sub-service, a call result generated after the called sub-service makes a service call based on the call parameter, and the like. Of course, the above-mentioned call data may also include other types of call data besides the three types of data described above, and are not listed in this specification.

When the server side obtains the call flow, a flow recording mode can be specifically adopted. The traffic recording is a process that the server can monitor a service request submitted by a user and a response result generated after the service request invokes a related service in the process that the user invokes the target service, and then store the monitored result.

In this case, in the process of calling the target service in the execution environment, the server may adopt a "traffic recording" mode to obtain call data generated when the service request sequentially calls the plurality of sub-services; and then, combining the acquired call data according to the call sequence to generate the call flow of the service request aiming at the target service.

For example, in an example, a subsystem for performing traffic recording may be separately deployed on the server, and in a process that the server invokes the target service in an execution environment, the subsystem may automatically run in the background, perform traffic recording on the invocation process of the target service, and locally store the recorded traffic. In this case, the server may obtain the call traffic by directly reading the call traffic recorded by the subsystem.

Step 204, performing abnormal call analysis on the call flow to determine whether the call flow is abnormal call flow;

after the server acquires the call traffic of the service request for the target service, abnormal call analysis can be automatically started on the call traffic to determine whether the call traffic is abnormal call traffic.

In an illustrated embodiment, a rule base for performing exception call analysis on call traffic may be loaded on the server, and the rule base may include a plurality of detection rules for performing exception call analysis on call traffic. The server side can perform abnormal calling analysis on the calling flow by running the detection rule in the rule base.

It should be noted that the type of the exception call traffic is not particularly limited in this specification, and in practical applications, a person skilled in the art may define and expand the exception call traffic based on actual needs.

For example, in one application scenario shown, the service request may repeatedly invoke a part of sub-services in the target service when invoked for the sub-services due to some potential failures (such as unreasonable design of the basic framework, incorrect code writing related to the invocation link, and the like). Therefore, in this application scenario, the exception call traffic may include repeat call traffic generated by the repeat call.

The repeated calling refers to that when the plurality of sub-services are sequentially called according to a preset sequence, after a specific sub-service is called, the next sub-service is not called continuously according to the calling sequence, but the sub-service is executed again due to some potential faults, so that repeated and invalid cyclic calling for a certain sub-service is formed. Since such a repeat call cannot be found based on the call results of the plurality of sub-services, the repeat call is a very hidden exception call.

Of course, the types of the abnormal call traffic may include other types of abnormal traffic in practical applications besides the above-described repeat call traffic, and are not listed in this specification.

In the rule base, a detection rule corresponding to each type of abnormal call traffic may be included. The detection logic corresponding to these detection rules may be defined based on the traffic characteristics corresponding to each type of abnormal call traffic.

For example, in the case that the abnormal call traffic is the repeat call traffic, since the repeat call refers to a repeat call to a part of the sub-services in the plurality of sub-services, the repeat call usually means that the sub-services called in two calls and the input call parameters are all the same; therefore, for the abnormal call behavior of the repeated call, call data containing the same service identifier and call parameter of the called sub-service must exist in the call data contained in the call traffic generated by the abnormal call behavior.

In this case, the detection logic corresponding to the detection rule related to the above-mentioned repeat call traffic may be the detection logic as follows:

determining whether the calling flow exists, wherein the calling flow contains calling data with the same service identifier and calling parameter of the called sub-service; if so, determining the call flow as a repeated call flow; if not, determining that the call flow is not the repeated call flow.

When the detection rule is operated by the server side to carry out abnormal call analysis on a certain call flow, whether the call flow exists or not can be determined, and the call data which contain the same service identifier and call parameter of the called sub-service is contained; if so, the call traffic may be determined to be repeat call traffic.

And step 206, if the calling flow is abnormal calling flow, pushing a target calling link corresponding to the abnormal calling flow to a user corresponding to the target service in an abnormal flow alarm mode so as to prompt the user to perform abnormal positioning on the target calling link.

In an embodiment shown in the present disclosure, after the service request performs an abnormal call analysis on the call traffic of the target service, the service request determines that the call traffic is an abnormal call traffic, at this time, an abnormal call tag indicating a type of an abnormal call may be added to the call traffic, and then the call traffic to which the abnormal call tag is added is stored in a preset abnormal database. In this way, the detected abnormal call flow can be uniformly stored and indicated to the abnormal database for centralized processing.

In another illustrated embodiment, when the server processes the detected abnormal call traffic, the server may read the abnormal call traffic to which the abnormal call tag is added from the abnormal database based on a preset cycle timing, and then perform centralized processing on the read abnormal call traffic.

It should be noted that, in practical application, most of the abnormal call traffic in the abnormal database may not substantially affect the system operation of the server; therefore, the server side can also analyze and screen the abnormal call traffic stored in the abnormal database to screen out valuable abnormal call traffic meeting preset risk conditions, and then only process the screened valuable abnormal call traffic.

For example, in one embodiment shown, a rule base for performing analysis and screening on the abnormal call traffic may be installed on the server, and the rule base may include a plurality of screening segment rules for performing analysis and screening on the abnormal call traffic. The server side can screen out valuable abnormal call flow meeting preset risk conditions from the abnormal database by operating the screening rules in the rule base.

The rule base may include a filtering rule corresponding to each type of abnormal call traffic. The screening logic corresponding to the detection rules may define a risk condition for each type of abnormal call traffic based on the degree of influence of each type of abnormal call traffic on the system operation of the server, and then define the screening rules based on the risk condition.

For example, in an application scenario shown, for example, the repeat call traffic in the exception database is taken as an example, for the repeat call traffic, the influence of the repeat call traffic on the system operation of the server is generally related to the duration of the repeat call and the number of calls. The longer the duration of the repeated call is, the more the number of calls is, the more serious the influence on the system operation of the server is generally caused.

Thus, for repeat call traffic, the risk conditions corresponding to it may be:

the calling duration for repeatedly calling at least part of the sub-services in the plurality of sub-services reaches a preset threshold value; and/or the presence of a gas in the atmosphere,

the ratio of the number of times of repeated calls to at least part of the sub-services to the total number of times of calls to the sub-services reaches a threshold value.

When the server side operates the screening rule corresponding to the risk condition to analyze and screen the repeated calling flow in the abnormal database, the server side can count that the calling duration for repeated calling of at least part of the sub-services in the repeated calling flow reaches a preset threshold value; and/or the ratio of the number of calls repeatedly made for at least part of the sub-services to the total number of calls made for the sub-services reaches a threshold; if so, the recall traffic may be determined to be valuable recall traffic.

In another application scenario shown, in practical applications, it may be desirable to prioritize the service invocation experience for some critical users (such as VIP users). In this case, a user tag indicating that the user is a key user may be added to the abnormal call traffic of the service request sent by the key users through the client for the target service.

In this case, the risk condition may be: carrying the user tag.

When the server side operates the screening rule corresponding to the risk condition to analyze and screen the abnormal call flow in the abnormal database, whether the abnormal call flow in the abnormal database carries the user tag or not can be determined; if so, the exception call traffic may be determined to be valuable repeat call traffic.

In this specification, when the server processes the abnormal call traffic in the abnormal database, the server may push a target call link corresponding to the abnormal call traffic to a user corresponding to the target service in the form of an abnormal traffic alarm, so as to prompt a relevant person to perform abnormal positioning on the target call link.

For example, in this case, the server may obtain a link identifier of a target call link corresponding to the abnormal call traffic, and then generate an abnormal traffic alarm including the link identifier based on the link identifier. It should be noted that the specific manner of determining the target call link corresponding to the abnormal call traffic, that is, the target call link that needs to be called for the service request that generates the abnormal call traffic, may be described in detail with reference to the foregoing description.

In an embodiment shown in the present invention, in the process that the server sequentially calls each sub-service in the target service in response to the service request, the server may generate call logs of the service request for the plurality of sub-services, respectively, and combine the generated call logs according to the call order to generate a call log corresponding to the target call link. By the method, the call logs generated when the sub-services are called can be linked, the call logs of the full link corresponding to the target call link are generated, richer and more complete call logs can be provided for relevant personnel to carry out abnormal positioning of the call link, and the problem that the call logs generated by calling the next sub-service cover the logs generated by calling the previous sub-service after the logs are stored and further the logs are lost can be avoided.

In this case, the server may further perform exception positioning analysis on the target call link based on the call log corresponding to the target call link, and generate an exception positioning guidance corresponding to the target call link based on an analysis result. The abnormal positioning guide is guiding and prompting related personnel in advance through guiding and prompting abnormal problems possibly faced by the target call link by the aid of guiding information generated by the server side based on a preliminary analysis result of the call log corresponding to the target call link. The specific form of the abnormality localization guide is not particularly limited in the present specification; for example, in practical applications, the anomaly localization guide may be in the form of text.

Correspondingly, when the server generates the abnormal alarm, the server may obtain the link identifier of the target call link corresponding to the abnormal call flow and the generated abnormal positioning guide, and generate an abnormal flow alarm including the link identifier and the abnormal positioning guide.

After the server generates the abnormal traffic alarm, the abnormal traffic alarm may be pushed to a user (such as an administrator, a developer, and the like) corresponding to the target service, so as to promote relevant personnel to perform abnormal positioning on the target call link. After receiving the abnormal traffic alarm, the related personnel can determine the calling link with the abnormality based on the link identification carried in the abnormal traffic alarm, and meanwhile, can look up the initial result of the abnormal positioning analysis of the calling link by the service end by looking up the abnormal positioning guide in the abnormal traffic alarm, and then can continue to perform manual intervention on the calling link on the basis to define the specific abnormal problem.

It should be noted that, the specific manner in which the server side pushes the abnormal traffic alarm to the user corresponding to the target service is not particularly limited in this specification;

in an embodiment shown, the client may specifically be an instant messaging client; for example, in one example, the server may be a mobile platform constructed based on a proprietary cloud; the client may be an instant messaging client (e.g., a proprietary dingtalk) corresponding to the proprietary cloud for mobile office.

In this scenario, the instant messaging client may specifically maintain a user group consisting of at least one user corresponding to the target service; the user group may also preset an RPA (rpcosmetic Process Automation) robot for pushing the warning prompt information to the user group. When the server side pushes the abnormal traffic alarm to the user corresponding to the target service, the RPA robot may specifically push the abnormal traffic alarm to the RPA robot, so that the RPA robot further automatically pushes the abnormal traffic alarm to the user group.

Of course, in practical applications, other push methods besides the above-mentioned push method may be adopted; for example, the push is performed in the form of short message, mail, etc., and they are not listed in this specification.

Referring to fig. 3, fig. 3 is a system architecture diagram of a server shown in this specification.

As shown in fig. 3, the system architecture of the server includes the following systems:

the traffic collection system 320 is configured to, in response to a service request for the target service sent by a client, obtain a call traffic of the service request for the target service; the call flow comprises call data generated when the service request calls the plurality of sub-services, and the call data are combined according to a preset call sequence of the sub-services.

The flow detection system 330 is configured to perform an abnormal call analysis on the call flow to determine whether the call flow is an abnormal call flow. The traffic detection system 330 includes a detection rule base 332.

The database 340 is configured to, when it is determined that the call flow is an abnormal call flow, add an abnormal call tag indicating a type of the abnormal call to the call flow, and store the call flow to which the abnormal call tag is added to a preset abnormal database.

And an alarm system 350, configured to push the target call link corresponding to the abnormal call traffic to a user corresponding to the target service in the form of an abnormal traffic alarm, so as to prompt the user to perform abnormal positioning on the target call link. The alert system 350 includes a screening rule base 352.

When the application 310 in the server receives a service request for a target service sent by a client, the application can sequentially call a plurality of sub-services according to the call sequence of the service request to the plurality of sub-services, can acquire call data generated when the service request sequentially calls the plurality of sub-services, and can combine the acquired call data according to the call sequence to generate a call flow of the service request for the target service.

The traffic collection system 320 may obtain call traffic for the service request for the target service. The call flow may be call data generated when the service request calls a plurality of sub-services, and data combined according to a call sequence, in one example, a sub-service may be a method that can be called by a user, and correspondingly, the call flow may be call data generated when the service request calls a plurality of methods, and data combined according to a call sequence; in another example, the sub-service may be a sub-program that can be called by a user, and accordingly, the call flow may be data that is combined in a call order from call data generated when the service request calls a plurality of sub-programs.

After the traffic collection system 320 obtains the call traffic, it may respectively generate call logs of the service request for the plurality of sub-services, combine the generated call logs according to the call sequence to generate a call log corresponding to the call link for the user to use when performing abnormal positioning on the call link, and may also issue the call traffic to a traffic detection system, where the traffic detection system performs abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic.

The traffic detection system 330 may include a detection rule base 332 for determining traffic anomalies, where the detection rule base may include at least one detection rule for determining traffic anomalies, for example, the detection rule may include a rule for determining whether there is a repeat call for traffic, carrying a user tag, a repeat of a sub-call, SQL aggregation, an interface anomaly, and so on. When the flow detection system receives the call flow, the detection rules in the rule base may be run one by one, and when it is determined whether the call flow is an abnormal call flow, the flow detection system may indicate an abnormal call tag of the type of the abnormal call for the abnormal call flow, and may store the call flow to which the abnormal call tag is added to the preset abnormal database 340.

For the call traffic carrying the abnormal call tag stored in the abnormal database 340, the alarm system 350 may periodically read based on a preset period. For example, the call traffic carrying the exception call tag stored in the exception database may be read every 1 day, 3 days, or 7 days as required.

The alarm system 350 may include a filtering rule base 352, where the filtering rule base 352 includes at least one filtering rule corresponding to abnormal call traffic, for example, the filtering rule corresponding to repeated call traffic may include: the method comprises the steps that the calling duration for repeatedly calling at least part of sub-services in a plurality of sub-services reaches a preset threshold value; and/or the ratio of the number of times of repeated calls to at least part of the sub-services in the plurality of sub-services to the total number of times of calls to the plurality of sub-services reaches a threshold value; the filtering rule corresponding to carrying the user tag may include carrying the user tag.

The alarm system 350 may generate an abnormal traffic alarm corresponding to the abnormal call traffic meeting the filtering rule, and may push the abnormal traffic alarm to a user corresponding to the target service, so as to prompt the user to perform abnormal positioning on the target call link. For example, the service end may include a mobile working platform constructed based on a proprietary cloud, the client may be an instant messaging client 360 corresponding to the proprietary cloud and used for performing mobile office, the instant messaging client 360 may maintain a user group composed of at least one user corresponding to a target service, the instant messaging client 360 may be provided with an RPA robot for pushing alarm prompt information into the user group, and the alarm system 350 may push an abnormal traffic alarm to the RPA robot, so that the RPA robot further pushes the abnormal traffic alarm into the user group, so as to prompt the user to perform abnormal positioning on a call link corresponding to the abnormal call traffic.

The detection method of the call link described in the above embodiments is described in detail below with reference to specific application scenarios.

The application scene one: and carrying out a stress test scene aiming at the target service.

In this scenario, the service request may specifically be a stress test request for the target service, and the abnormal call traffic may be the repeat call traffic.

When receiving a pressure test request which is sent by a pressure test user through a client and aims at the target service, a server can acquire call data of the pressure test request to the target service through the flow acquisition system in a flow recording mode.

The flow detection system can acquire the call data acquired by the flow acquisition system, and perform abnormal call analysis on the call data by running the detection rules in the detection rule base to determine whether the call data is the repeated call flow. The details of performing the abnormal call analysis on the call data to determine whether the call data is the repeated call flow are not repeated, please refer to the description of the previous embodiment.

When the flow detection system determines that the call data is the repeated call data through abnormal call analysis, an abnormal call tag indicating that the call data is the repeated call data may be added to the repeated call data, and then the abnormal call data is stored in an abnormal database.

The alarm system can read abnormal calling transactions from the abnormal database at regular time to carry out centralized processing, and the screening rules in the screening rule base are operated to analyze and screen the repeated calling data in the abnormal database so as to screen out valuable repeated calling data in the repeated calling data. The details of screening out valuable repetitive calling data from these repetitive calling data are not repeated, and please refer to the description of the previous embodiment. For example, as described above, the repeat call data having a relatively high influence on the system operation of the server may be screened out.

After valuable repeated calling data are screened out, the alarm system can generate abnormal alarms and push the abnormal alarms to pressure testers related to the target service, and the pressure testers are reminded to carry out abnormal positioning on a target calling link corresponding to the repeated calling data.

Since a duplicate call cannot be found based on the result of the call to the target service (i.e., the result of the pressure test) of the pressure test request, the duplicate call is a very hidden abnormal call. If repeated calling abnormity is not found in time in the pressure test process, the performance of the pressure test is affected.

By adopting the technical scheme, the repeated calling abnormity aiming at the target service and the calling link with the repeated calling abnormity can be found in time, so that related pressure testing personnel can not need to manually position the calling link with the repeated calling abnormity, the time cost for finding the calling link with the repeated calling abnormity can be reduced, and the efficiency of the related personnel for processing the abnormity problem of the calling link with the repeated calling abnormity is improved. In addition, by the mode, the call link which cannot be found by manual positioning and is relatively hidden and abnormal in repeated call can be found in time, so that the pressure test performance aiming at the target service can be prevented from being influenced by omission of the abnormal call link.

Application scenario two: and the VIP user (namely the key user) makes a service call for the target service.

In this scenario, the service request may specifically be a service invocation request of the VIP for the target service, and the abnormal invocation traffic may be abnormal invocation traffic of the service invocation request initiated by the VIP user for the target service.

When receiving a service call request aiming at the target service sent by a VIP user through a client, a server can acquire call data of the service call request to the target service in a traffic recording mode through the traffic acquisition system, and can determine whether the user initiating the service call request is a VIP user in a preset VIP user list after acquiring the call data of the service call request to the target service; if so, a VIP user tag may be further added to the collected call traffic indicating that the user is a VIP user.

The flow detection system can acquire the call data acquired by the flow acquisition system, and perform abnormal call analysis on the call data by running the detection rules in the detection rule base to determine whether the call data is abnormal call flow.

When the flow detection system determines that the call data is the abnormal call data through the abnormal call analysis, an abnormal call tag indicating the abnormal call type may be added to the call data, and then the abnormal call data is stored in the abnormal database.

The alarm system can read abnormal call transactions from the abnormal database at regular time to perform centralized processing, analyze and screen abnormal call data in the abnormal database by operating the screening rules in the screening rule base, and screen valuable abnormal call data in the abnormal call data. For example, as previously described, the exception call data carrying the VIP user tag may be screened out as valuable exception call data. Exception call data carrying VIP user tags may be handled preferentially.

After the abnormal calling data carrying the VIP user tag is screened out, the alarm system can generate an abnormal alarm and push the abnormal alarm to pressure testers related to the target service, so that the pressure testers are reminded to preferentially perform abnormal positioning on a target calling link corresponding to the abnormal calling data carrying the VIP user tag.

By adopting the technical scheme, the abnormal calling data of the VIP aiming at the target service can be used as the calling link corresponding to the valuable abnormal calling data, and the calling link is pushed to related personnel in an abnormal alarming mode to be processed preferentially, so that the calling abnormality in the target service calling process of the VIP user can be processed preferentially, and the service calling experience of the VIP user is improved.

In an exemplary embodiment of the present specification, there is also provided an apparatus capable of implementing the above method.

FIG. 4 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 4, at the hardware level, the apparatus includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410, although it may include hardware required for other tasks. One or more embodiments of the present description may be implemented in software, such as by processor 402 reading a corresponding computer program from non-volatile memory 410 into memory 409 and then executing. Of course, besides the software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combination of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 5, in a software implementation, a detection apparatus for invoking a link is provided, and is applied to a server, where a target service is deployed on the server; the target service comprises at least one calling link which is composed of a plurality of sub-services according to a preset calling sequence; the device comprises:

a traffic collection module 510, configured to respond to a service request for the target service sent by a client, and obtain a call traffic of the service request for the target service; the call flow comprises call data generated when the service request calls the plurality of sub-services, and the call data are combined according to a preset call sequence of the sub-services;

a flow analysis module 520, configured to perform abnormal call analysis on the call flow to determine whether the call flow is an abnormal call flow;

a flow positioning module 530, configured to generate an abnormal flow alarm corresponding to the abnormal call flow when the call flow is an abnormal call flow, and push the abnormal flow alarm to a user corresponding to the target service, so as to prompt the user to perform abnormal positioning on a call link corresponding to the abnormal call flow.

Optionally, before obtaining the call traffic of the service request for the target service, the method further includes:

the calling data generating module 540 is configured to respond to a service request, sent by a client, for the target service, sequentially call the plurality of sub-services according to the calling sequence, and acquire calling data generated when the plurality of sub-services are sequentially called by the service request;

and combining the acquired call data according to the call sequence to generate the call flow of the service request aiming at the target service.

Optionally, the method further includes:

a call log generating module 550, configured to generate call logs of the service request for the multiple sub-services, respectively, and combine the generated call logs according to the call sequence to generate a call log corresponding to the call link, so that the call log is used when the user performs exception positioning on the call link

Optionally, the method further includes:

the storage module 560 is configured to, when it is determined that the call flow is an abnormal call flow, add an abnormal call tag indicating a type of the abnormal call to the call flow, and store the call flow to which the abnormal call tag is added to a preset abnormal database.

Optionally, the method further includes:

the screening rule screening module 570 is configured to periodically read the abnormal call traffic to which the abnormal call tag is added from the abnormal database based on a preset period;

screening abnormal call flows meeting preset screening rules from the read abnormal call flows;

and generating an abnormal flow alarm corresponding to the screened abnormal call flow.

Optionally, the filtering rule filtering module 570 includes:

a repeated flow determining module 572 for determining whether the call flow exists, and the included call data that the service identifier and the call parameter of the called sub-service are the same; and if so, determining the call flow as a repeated call flow.

Optionally, the filtering rule filtering module 570 includes:

a repeated traffic screening module 574, configured to determine whether a call duration for performing repeated calls for at least some of the multiple sub-services reaches a preset threshold; and/or the presence of a gas in the atmosphere,

determining whether a ratio of a number of calls made repeatedly for at least some of the plurality of sub-services to a total number of calls made for the plurality of sub-services reaches a threshold.

Optionally, the call log generating module 550 includes:

an abnormal location guidance generating module 552, configured to perform abnormal location analysis on the call link based on the call log corresponding to the call link, and generate an abnormal location guidance corresponding to the call link based on an analysis result;

generating an abnormal traffic alarm corresponding to the abnormal call traffic, comprising:

and generating an abnormal flow alarm corresponding to the abnormal call flow based on the link identification of the call link corresponding to the abnormal call flow and the abnormal positioning guide.

Optionally, the service request includes a service call request for the target service; or, a stress test request for the target service.

Optionally, if the service request is a service invocation request for the target service; further comprising:

a key user determining module 554, configured to determine whether a user initiating the service invocation request is a key user in a preset key user list; if so, adding a user tag indicating that the user is a key user for the acquired service calling request aiming at the calling flow of the target service.

Optionally, the key user determining module 554 includes:

an abnormal traffic determining module 556, configured to determine whether the call traffic carries the user tag indicating that the user is a key user; if so, determining the call flow as an abnormal call flow.

Optionally, if the service request is a service invocation request for the target service, the preset screening rule includes: and carrying the user tag.

Optionally, the server includes a mobile working platform constructed based on a proprietary cloud; the client is an instant messaging client corresponding to the proprietary cloud and used for mobile office.

Optionally, the method further includes:

an abnormal traffic alarm pushing module 580, configured to push the abnormal traffic alarm to indicate the RPA robot, so that the RPA robot further pushes the abnormal traffic alarm to the user group.

Optionally, the sub-service includes a method that can be called by a user; the target service comprises an application program consisting of a plurality of methods which can be called by a user; or the sub-service comprises an application subprogram which is used for being called by a user and consists of a plurality of methods for being called; the target service includes an application program composed of a plurality of application subprograms.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising a … …" does not exclude the presence of another identical element in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if," as used herein, may be interpreted as "at … …" or "at … …" or "in response to a determination," depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A detection method for a call link is applied to a server, and a target service is deployed on the server; the target service comprises at least one calling link which is composed of a plurality of sub-services according to a preset calling sequence; the method comprises the following steps:

2. The method of claim 1, the obtaining call traffic of the service request for the target service, comprising:

acquiring call data generated when the service request calls the plurality of sub-services in sequence;

3. The method of claim 2, further comprising:

and respectively generating call logs of the service requests aiming at the plurality of sub-services, combining the generated call logs according to the call sequence to generate a call log corresponding to the target call link, so that the call log can be used when the user abnormally positions the target call link.

4. The method of claim 1, further comprising:

and when the calling flow is determined to be abnormal calling flow, adding an abnormal calling tag indicating the type of the abnormal calling to the calling flow, and storing the calling flow added with the abnormal calling tag to a preset abnormal database.

5. The method of claim 4, generating an abnormal traffic alert corresponding to the call traffic, comprising:

screening abnormal call flow which meets preset risk conditions in the abnormal database;

6. The method of claim 5, the exception call traffic comprising repeat call traffic that repeats calls for at least some of the plurality of sub-services; the calling data comprises a service identifier and calling parameters of the called sub-service;

performing abnormal call analysis on the call flow to determine whether the call flow is an abnormal call flow, including:

determining whether the calling flow exists or not, wherein the calling flow contains calling data with the same service identifier and calling parameter of the called sub-service; and if so, determining the call flow as a repeated call flow.

7. The method of claim 6, the risk condition corresponding to the repeat call traffic comprising:

the calling duration for repeatedly calling at least part of the sub-services in the plurality of sub-services reaches a preset threshold value; and/or the presence of a gas in the gas,

the ratio of the number of calls for repeated calls to at least some of the plurality of sub-services to the total number of calls to the plurality of sub-services reaches a threshold.

8. The method of claim 3, further comprising:

performing abnormal positioning analysis on the calling link based on the calling log corresponding to the calling link, and generating abnormal positioning guide corresponding to the calling link based on the analysis result;

and generating an abnormal flow alarm corresponding to the abnormal calling flow based on the link identification of the target calling link corresponding to the abnormal calling flow and the abnormal positioning guide.

9. The method of claim 5, the service request comprising a service invocation request for the target service; or, a stress test request for the target service.

10. The method of claim 9, if the service request is a service invocation request for the target service;

the method further comprises the following steps:

determining whether the user initiating the service calling request is a key user in a preset key user list; if so, adding a user tag indicating that the user is a key user for the acquired service calling request aiming at the calling flow of the target service.

11. The method of claim 10, the preset risk condition comprising: and carrying the user tag.

12. The method of claim 1, wherein the server is a mobile workbench constructed based on a proprietary cloud; the client is an instant messaging client corresponding to the private cloud and used for mobile office.

13. The method of claim 12, the instant messaging client maintains a user group of at least one user corresponding to the target service; the instant messaging client side is provided with an RPA robot used for pushing alarm prompt information to the user group in advance;

pushing the abnormal traffic alarm to a user corresponding to the target service, including:

and pushing the abnormal flow alarm to the RPA robot so that the RPA robot further pushes the abnormal flow alarm to the user group.

14. The method of claim 1, the sub-service comprising a method that is available for invocation by a user; the target service comprises an application program consisting of a plurality of methods which can be called by a user; or the sub-service comprises an application subprogram which is used for being called by a user and consists of a plurality of methods used for being called; the target service includes an application program composed of a plurality of application subprograms.

15. A detection device for calling a link is applied to a server, and a target service is deployed on the server; the target service comprises at least one calling link which is composed of a plurality of sub-services according to a preset calling sequence; the device comprises:

16. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-14 by executing the executable instructions.

17. A computer-readable storage medium having computer-readable instructions stored thereon which, when executed by a processor, implement the method of any one of claims 1-14.