A detection method and device for a call link

Abstract

One or more embodiments of this specification provide a method and device for detecting a call chain, which are applied to a server where a target service is deployed; the target service includes at least one call chain composed of multiple sub-services in a preset call order; the method includes: in response to a service request for the target service sent by a client, obtaining the call traffic of the service request for the target service; wherein, the call traffic includes call data generated when the service request calls multiple sub-services, and the call data is combined in the preset call order of the sub-services; performing abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic; if the call traffic is abnormal call traffic, pushing the target call chain corresponding to the abnormal call traffic to the user corresponding to the target service in the form of an abnormal traffic alarm to prompt the user to perform abnormal positioning for the target call chain.

Description

Technical Field

[0001] This specification relates to the technical field of distributed systems, and particularly to a method and device for detecting a call link. Background Art

[0002] With the development of the Internet, there are more and more application scenarios where user services are deployed on the server side for users to call. And with the diversification of user needs, the service functions that can be provided by the user services deployed on the server side are also gradually developing in the direction of diversification. Summary of the Invention

[0003] In view of this, one or more embodiments of this specification provide a method and device for detecting a call link to solve the problems existing in the related art.

[0004] To achieve the above object, one or more embodiments of this specification provide the following technical solutions:

[0005] According to the first aspect of the embodiments of this specification, a method for detecting a call link is provided, which is applied to a server, and a target service is deployed on the server; the target service includes at least one call link composed of a plurality of sub-services in a preset call order; the method includes:

[0006] In response to a service request for the target service sent by a client, obtain the call traffic of the service request for the target service; wherein, the call traffic includes call data generated when the service request calls the plurality of sub-services, and the call data is combined in the preset call order of the sub-services;

[0007] Perform abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic;

[0008] If the call traffic is abnormal call traffic, push the target call link corresponding to the abnormal call traffic to the user corresponding to the target service in the form of an abnormal traffic alarm to prompt the user to perform abnormal location for the target call link.

[0009] According to the second aspect of the embodiments of this specification, a device for detecting a call link is provided, which is applied to a server, and a target service is deployed on the server; the target service includes at least one call link composed of a plurality of sub-services in a preset call order; the device includes:

[0010] A traffic collection module, configured to obtain the call traffic of the service request for the target service in response to a service request for the target service sent by a client; wherein, the call traffic includes call data generated when the service request calls the multiple sub-services, and the call data is combined according to a preset call order of the sub-services;

[0011] A traffic analysis module, configured to perform abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic;

[0012] A traffic positioning module, configured to, when the call traffic is abnormal call traffic, 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 to prompt the user to perform abnormal positioning on the target call link.

[0013] According to a third aspect of the embodiments of the present specification, an electronic device is provided, including a communication interface, a processor, a memory, and a bus, and the communication interface, the processor, and the memory are interconnected through the bus;

[0014] The memory stores computer-readable instructions, and the processor executes the above method by calling the computer-readable instructions.

[0015] According to a fourth aspect of the embodiments of the present specification, a computer-readable storage medium is provided, and the computer-readable storage medium stores computer-readable instructions, and when the computer-readable instructions are called and executed by a processor, the above method is implemented.

[0016] The technical solutions provided by the embodiments of the present specification may include the following beneficial effects:

[0017] Through the above technical solutions, abnormal calls for the target service and the call links where call anomalies occur can be discovered in a timely manner, so that relevant personnel no longer need to manually locate the call links where anomalies occur, thereby reducing the time cost of discovering abnormal call links and improving the efficiency of relevant personnel in handling abnormal problems for abnormal call links. Moreover, relatively hidden abnormal call links that cannot be discovered through manual positioning can also be discovered in a timely manner, thereby avoiding affecting the call performance of the above target service due to omission of such abnormal call links. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 is a schematic structural diagram of a call link detection system provided by an exemplary embodiment.

[0019] Figure 2 is a flowchart of a call link detection method provided by an exemplary embodiment.

[0020] Figure 3 It is a system architecture diagram of a server provided by an exemplary embodiment.

[0021] Figure 4 It is a schematic structural diagram of an electronic device where a detection device for a call link provided by an exemplary embodiment is located.

[0022] Figure 5 It is a block diagram of a detection device for a call link provided by an exemplary embodiment. Detailed implementation manners

[0023] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all the implementation manners consistent with one or more embodiments of this specification. On the contrary, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0024] It should be noted that: In other embodiments, the steps of the corresponding methods are not necessarily executed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step for description in other embodiments.

[0025] Figure 1 It is a schematic architecture diagram of a detection system for a call link provided by an exemplary embodiment. As Figure 1 shown, the system may include a network 10, a server 11, and several electronic devices, such as mobile phones 12, 13, and 14, etc.

[0026] The server 11 may be a physical server including an independent host, or the server 11 may be a virtual server, a cloud server, etc. hosted by a host cluster. The mobile phones 12 - 14 are just one type of electronic device that users can use. In fact, users can obviously also use electronic devices of the following types: tablet devices, laptop computers, personal digital assistants (PDAs), wearable devices (such as smart glasses, smart watches, etc.), etc. One or more embodiments of this specification do not limit this. The network 10 may include various types of wired or wireless networks.

[0027] In one embodiment, the server 11 can cooperate with mobile phones 12-14; among them, the mobile phones 12-14 can be used to call traffic collection, and the collected call traffic can be uploaded to the server 11 through the network 10, and then the server 11 processes the received call traffic based on the detection scheme of this specification to achieve the detection of the call link. In another embodiment, the mobile phones 12-14 can independently implement the detection scheme of this specification; among them, the mobile phones 12-14 perform call link collection and process the received call traffic based on the detection scheme of this specification to achieve the detection of the call link.

[0028] With the development of the Internet, there are more and more application scenarios where user services are deployed on the server side for users to call. And with the diversified development of user needs, the service functions that the user services deployed on the server side can provide are also gradually developing in the direction of diversification.

[0029] Under the influence of such needs, the user services deployed on the server side have gradually evolved into more diverse services composed of multiple sub-services combined in a certain call order. For such services, since the sub-services that make up the service are diverse, freely combining the sub-services included in such services based on user needs can often form multiple different call links, and different service functions can often be provided to users through different call links.

[0030] Although freely combining the sub-services included in such services can form multiple call links, making the service functions that such services can provide more abundant, however, with the increase in call links, once there are call links with call exceptions among these links, it will become increasingly difficult to quickly and accurately locate the call links with call exceptions.

[0031] In view of this, this specification proposes an automatic detection scheme that can timely discover abnormal call links by automatically performing abnormal call analysis on the call traffic of the service.

[0032] The concept of the solution in this specification lies in:

[0033] When receiving a service request for the target service sent by the client, the service request can be responded to, and the call traffic of the service request for the target service can be obtained; among them, the call traffic includes the call data generated when the service request calls the multiple sub-services, and the call data is combined according to the preset call order of the sub-services;

[0034] Then, abnormal call analysis can be performed on the call traffic to determine whether the call traffic is abnormal call traffic;

[0035] Further, if the call traffic is abnormal call traffic, a target call link corresponding to the abnormal call traffic can be determined, an abnormal traffic alarm corresponding to the abnormal call traffic can be generated, and then the abnormal traffic alarm is pushed to a user corresponding to the target service to prompt the user to perform abnormal positioning for the target call link.

[0036] Through the above technical solutions, abnormal calls to the target service and the call links where call anomalies occur can be discovered in a timely manner, enabling relevant personnel to no longer need to manually locate the call links where anomalies occur, thereby reducing the time cost of discovering abnormal call links and improving the efficiency of relevant personnel in handling abnormal problems with abnormal call links. Moreover, relatively hidden abnormal call links that cannot be discovered through manual positioning can also be discovered in a timely manner, thereby avoiding affecting the call performance of the above target service due to omission of such abnormal call links.

[0037] The detection scheme of the call link in this specification will be described in detail below with reference to the accompanying drawings.

[0038] Please refer to Figure 2 , Figure 2 which is a flowchart of a method for detecting a call link proposed in this specification, and the method is applied to a server. Among them, a target service can be deployed on the server; the target service can include at least one call link composed of multiple sub-services in a preset call order. As Figure 2 shown, the method includes the following execution steps:

[0039] Step 202, in response to a service request for the target service sent by a client, obtain the call traffic of the service request for the target service; wherein, the call traffic includes call data generated when the service request calls the multiple sub-services, and the call data is combined in the preset call order of the sub-services;

[0040] The above target service can be any form of service including multiple call links. Among them, the target service usually includes multiple sub-services, and the above call link is usually a link composed of multiple sub-services in a preset call order.

[0041] For example, in an example, the above sub-services can be methods available for users to call; for example, the methods available for users to call can be service logics developed by developers based on a specific programming language and available for users to call. In this case, the above target service can be an application program composed of multiple methods available for users to call (such as an APP).

[0042] In another example, the above-mentioned sub-service can also be an application subroutine composed of multiple callable methods. In this case, the above-mentioned target service can be an application composed of multiple application subroutines.

[0043] In practical applications, the user can send a service request to the server through the client to call the above-mentioned target service deployed on the server. After receiving the service request, the server can respond to the service request and call the above-mentioned target service in the execution environment of the server.

[0044] For example, in one example, after receiving the service request, the server can respond to the service request and call multiple sub-services included in the target service in the preset call order.

[0045] It should be noted that since the called target service may include multiple call chains, after receiving the service request, the server can first determine the call chain that the service request needs to call, and then call each sub-service in the call chain in the preset call order. It is not difficult to understand that different service requests usually have differences in the call chains they need to call.

[0046] Among them, the specific method for determining the call chain that the service request needs to call is not particularly limited in this specification;

[0047] For example, in one example, the call chain that the service request needs to call can be determined based on the type of the service request. That is, different types of service requests usually have differences in the call chains they need to call. In another example, the service request can specifically include the link identifier of the call chain that needs to be called. In this case, the call chain that the service request needs to call can also be determined based on the link identifier in the above-mentioned service request.

[0048] During the process of the server calling the above-mentioned target service in the execution environment, the server can also obtain the call traffic of the service request for the target service.

[0049] Among them, the above-mentioned call traffic can specifically refer to the call data generated when the above-mentioned service request calls multiple sub-services that make up the above-mentioned target service, and the call data can be combined in the call order described above. And the above-mentioned call data usually can include any form of data related to the service calls for the above-mentioned multiple sub-services.

[0050] For example, in practical applications, in the above-mentioned call data, it usually can include the service identifier of the called sub-service, the call parameters input to the called sub-service, and the call result generated after the called sub-service performs a service call based on the above-mentioned call parameters, and so on. Of course, in addition to the above three types of data, the above-mentioned call data can also include other types of call data, which will not be listed one by one in this specification.

[0051] When the above-mentioned server obtains the above-mentioned call traffic, it can specifically adopt the method of "traffic recording". The so-called traffic recording means that the server can monitor the service requests submitted by the user and the response results generated after the services related to the service requests are called during the process of the user calling the above-mentioned target service, and then save the monitored results.

[0052] In this case, when the server calls the above-mentioned target service in the execution environment, it can adopt the method of "traffic recording" to obtain the call data generated when the service request calls the above-mentioned multiple sub-services in sequence; then, the obtained call data is combined according to the call order to generate the call traffic of the service request for the target service.

[0053] For example, in one example, a sub-system for traffic recording can be deployed separately on the above-mentioned server. When the server calls the above-mentioned target service in the execution environment, this sub-system can run automatically in the background, record the traffic of the call process of the above-mentioned target service, and save the recorded traffic locally. In this case, the server can obtain the call traffic by directly reading the call traffic recorded by this sub-system.

[0054] Step 204, perform abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic;

[0055] After the server obtains the call traffic of the service request for the target service, it can automatically start abnormal call analysis on this call traffic to determine whether this call traffic is abnormal call traffic.

[0056] In an illustrated embodiment, on the server, a rule library for abnormal call analysis of call traffic can be carried. In this rule library, several detection rules for abnormal call analysis of call traffic can be included. The server can perform abnormal call analysis on this call traffic by running the detection rules in the rule library.

[0057] It should be noted that the type of the above-mentioned abnormal call traffic is not specifically limited in this specification. In practical applications, those skilled in the art can define and expand it based on actual needs.

[0058] For example, in one of the illustrated application scenarios, due to some potential failures (such as unreasonable basic framework design, incorrect coding of the call chain-related code, etc.), when the above service request invokes multiple sub-services in the above target service, some of the multiple sub-services may be repeatedly invoked. Therefore, in this application scenario, the above abnormal call traffic may include the repeated call traffic generated by the above repeated calls.

[0059] Among them, the so-called repeated call means that when sequentially invoking the above multiple sub-services according to a preset order, after the invocation of a specific sub-service is completed, instead of continuing to invoke the next sub-service according to the call order, due to some potential failures, the sub-service is executed again for this sub-service, forming a repeated and invalid loop call for a certain sub-service. Since this repeated call cannot be detected based on the call results of the above multiple sub-services, this repeated call is a very hidden abnormal call.

[0060] Of course, the types of the above abnormal call traffic, in addition to including the repeated call traffic described above, may also include other types of abnormal traffic in actual applications, which will not be listed one by one in this specification.

[0061] In the above rule library, detection rules corresponding to each type of abnormal call traffic may be included. And the detection logics corresponding to these detection rules can be defined based on the traffic characteristics corresponding to each type of abnormal call traffic.

[0062] For example, taking the above abnormal call traffic as the repeated call traffic, since a repeated call means that some of the multiple sub-services are repeatedly called, and a repeated call usually means that the sub-services called and the input call parameters in the two calls are exactly the same; therefore, for the abnormal call behavior of repeated calls, among the call data included in the call traffic generated by it, there will inevitably be call data in which the service identifier and call parameters of the called sub-service are the same.

[0063] In this case, the detection logic corresponding to the detection rule related to the above repeated call traffic may be the detection logic shown below:

[0064] Determine whether there is call data in the call traffic in which the service identifier and call parameters of the called sub-service are the same; if so, determine that the call traffic is repeated call traffic; if not, determine that the call traffic is not repeated call traffic.

[0065] When the server runs the detection rule to perform abnormal call analysis on a certain call traffic, it can determine whether there is call data in the call traffic where the service identifiers and call parameters of the called sub-services included are the same; if so, it can determine that the call traffic is duplicate call traffic.

[0066] Step 206, if the call traffic is abnormal call traffic, push the target call link corresponding to the abnormal call traffic to the user corresponding to the target service in the form of an abnormal traffic alarm to prompt the user to perform abnormal positioning for the target call link.

[0067] In one shown embodiment, after the server performs abnormal call analysis on the call traffic of the above service request for the above target service and determines that the call traffic is abnormal call traffic, an abnormal call label indicating the type of abnormal call can be added to the call traffic at this time, and then the call traffic with the added abnormal call label is stored in a preset abnormal database. In this way, the detected abnormal call traffic can be uniformly stored in the indicated abnormal database for centralized processing.

[0068] In another shown embodiment, when the server processes the detected abnormal call traffic, it can regularly read the abnormal call traffic with the added abnormal call label from the abnormal database based on a preset period, and then perform centralized processing on the read abnormal call traffic.

[0069] It should be noted that in actual applications, since most of the abnormal call traffic in the abnormal database may not have a substantial impact on the system operation of the above server; therefore, the server can also analyze and screen the abnormal call traffic stored in the abnormal database to screen out valuable abnormal call traffic that meets the preset risk conditions, and then only process the screened valuable abnormal call traffic.

[0070] For example, in one shown embodiment, a rule library for analyzing and screening abnormal call traffic can also be installed on the server, and several screening segment rules for analyzing and screening abnormal call traffic can be included in the rule library. The server can screen out valuable abnormal call traffic that meets the preset risk conditions from the abnormal database by running the screening rules in the rule library.

[0071] Among them, in the above rule library, screening rules corresponding to each type of abnormal call traffic can also be included. The screening logics corresponding to these detection rules can define risk conditions for this type of abnormal call traffic based on the actual impact degree of each type of abnormal call traffic on the system operation of the server, and then define screening rules based on the risk conditions.

[0072] For example, in one of the illustrated application scenarios, taking the repeated call traffic in the above abnormal database as an example, for the repeated call traffic, the impact it has on the system operation of the server is usually related to the duration and frequency of the repeated calls. The longer the duration of the repeated calls and the more the number of calls, the more serious the impact on the system operation of the server usually is.

[0073] Therefore, for the repeated call traffic, the corresponding risk conditions can be:

[0074] The duration of repeated calls to at least some of the above-mentioned multiple sub-services reaches a preset threshold; and / or,

[0075] The ratio of the number of repeated calls to at least some of the above-mentioned multiple sub-services to the total number of calls to the above-mentioned multiple sub-services reaches a threshold.

[0076] When the server analyzes and screens the repeated call traffic in the abnormal database by running the screening rule corresponding to this risk condition, it can count that in the repeated call traffic, the duration of repeated calls to at least some of the above-mentioned multiple sub-services reaches a preset threshold; and / or, the ratio of the number of repeated calls to at least some of the above-mentioned multiple sub-services to the total number of calls to the above-mentioned multiple sub-services reaches a threshold; if so, it can be determined that this repeated call traffic is valuable repeated call traffic.

[0077] In another illustrated application scenario, in actual applications, it may be necessary to give priority to ensuring the service call experience of some key users (such as VIP users). In this case, a user label indicating that the user is a key user can be added to the abnormal call traffic of the service request sent by these key users through the client for the above-mentioned target service.

[0078] In this case, the above risk condition can be: carrying the above user label.

[0079] When the server analyzes and screens the abnormal call traffic in the abnormal database by running the screening rule corresponding to this risk condition, it can determine whether the abnormal call traffic in the abnormal database carries the above user label; if so, it can be determined that this abnormal call traffic is valuable repeated call traffic.

[0080] In this specification, when the server processes the abnormal call traffic in the abnormal database, it can push the target call link corresponding to this abnormal call traffic to the user corresponding to the target service in the form of an abnormal traffic alarm to prompt relevant personnel to perform abnormal location on this target call link.

[0081] For example, in this case, the server can obtain the link identifier of the target call link corresponding to the abnormal call traffic, and then generate an abnormal traffic alarm containing the link identifier based on the link identifier. It should be noted that the target call link corresponding to the abnormal call traffic is the target call link that the service request generating the abnormal call traffic needs to call. The specific method for determining the target call link can refer to the previous description and will not be elaborated here.

[0082] In an illustrated implementation manner, when the server responds to the above service request and sequentially calls each sub-service in the above target service, the server can respectively generate call logs of the above service request for the above multiple sub-services, and combine the generated call logs in the above call order to generate a call log corresponding to the above target call link. In this way, the call logs generated when calling each sub-service can be linked together to generate a call log for the entire link corresponding to the above target call link. In addition to providing more abundant and complete call logs for relevant personnel to locate call link abnormalities, it can also avoid the call log generated when calling the next sub-service from overwriting the log generated when calling the previous sub-service after storing the log, thereby causing loss of the log.

[0083] In this case, the server can also perform abnormal location analysis on the above target call link based on the call log corresponding to the above target call link, and generate an abnormal location guidance corresponding to the above target call link based on the analysis result. The abnormal location guidance refers to a guiding information generated by the server based on the preliminary analysis result of the call log corresponding to the above target call link. Through this guiding information, the possible abnormal problems faced by the target call link can be guided and prompted to relevant personnel in advance. The specific form of the abnormal location guidance is not particularly limited in this specification; for example, in actual applications, the abnormal location guidance can be in the form of text.

[0084] Correspondingly, when the server generates the above abnormal alarm, it can obtain the link identifier of the target call link corresponding to the abnormal call traffic and the generated above abnormal location guidance, and generate an abnormal traffic alarm containing the link identifier and the abnormal location guidance.

[0085] After the server generates the above abnormal traffic alert, it can push the abnormal traffic alert to the users corresponding to the above target service (such as administrators, developers, etc.) to enhance the abnormal positioning of the relevant personnel for the target call link. After the relevant personnel receive the abnormal traffic alert, they can clarify the call link where the abnormality occurs based on the link identifier carried in the abnormal traffic alert. At the same time, they can also refer to the abnormal positioning guide in the abnormal traffic alert to review the preliminary results of the server's abnormal positioning analysis of the call link, and then continue to perform manual intervention on the call link based on this to define specific abnormal problems.

[0086] It should be noted that the specific method for the server to push the abnormal traffic alert to the users corresponding to the above target service is not particularly limited in this specification;

[0087] In an illustrated embodiment, the above client can specifically be an instant messaging client; for example, in an example, the above server can be a mobile work platform built based on a proprietary cloud; the client can be an instant messaging client for mobile office corresponding to the proprietary cloud (such as, proprietary dingtalk).

[0088] In this scenario, the instant messaging client can specifically maintain a user group composed of at least one user corresponding to the above target service; among them, the user group can also be pre-set with an RPA (Robotic Process Automation) robot for pushing alert prompt information to the user group. When the server pushes the abnormal traffic alert to the users corresponding to the above target service, it can specifically push the abnormal traffic alert to the RPA robot, so that the RPA robot further automatically pushes the abnormal traffic alert to the above user group.

[0089] Of course, in actual applications, in addition to the above push method, other push methods can also be used; for example, push through forms such as text messages and emails, which will not be listed one by one in this specification.

[0090] Please refer to Figure 3 , Figure 3 which is a system architecture diagram of a server shown in this specification.

[0091] As Figure 3 shown, the system architecture of the server includes the following systems:

[0092] A traffic collection system 320 is configured to obtain the call traffic of the service request for the target service in response to the service request for the target service sent by the client. Wherein, the call traffic includes the call data generated when the service request invokes the multiple sub-services, and the call data is combined according to the preset call order of the sub-services.

[0093] A traffic detection system 330 is configured to perform abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic. The traffic detection system 330 includes a detection rule library 332.

[0094] A database 340 is configured to add an abnormal call label indicating the type of the abnormal call to the call traffic when it is determined that the call traffic is abnormal call traffic, and store the call traffic with the added abnormal call label into a preset abnormal database.

[0095] An alarm system 350 is configured to push the target call link corresponding to the abnormal call traffic to the user corresponding to the target service in the form of an abnormal traffic alarm to prompt the user to perform abnormal location on the target call link. The alarm system 350 includes a screening rule library 352.

[0096] When the application program 310 in the server receives the service request for the target service sent by the client, it can sequentially call multiple sub-services according to the call order of the service request for the multiple sub-services, and can obtain the call data generated when the service request sequentially calls the multiple sub-services, and can also combine the obtained call data according to the call order to generate the call traffic of the service request for the target service.

[0097] The traffic collection system 320 can obtain the call traffic of the service request for the target service. The call traffic can be the call data generated when the service request invokes multiple sub-services and combined according to the call order. In one example, the sub-service can be a method that can be called by the user. Correspondingly, the call traffic can be the call data generated when the service request invokes multiple methods and combined according to the call order. In another example, the sub-service can be a subroutine that can be called by the user. Correspondingly, the call traffic can be the call data generated when the service request invokes multiple subroutines and combined according to the call order.

[0098] After the traffic collection system 320 obtains the call traffic, it can generate call logs for the calls to multiple sub-services for each service request respectively, and combine the generated call logs in the call order to generate a call log corresponding to the call link for users to use when locating anomalies in the call link. It can also send the call traffic to the traffic detection system, and the traffic detection system can perform abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic.

[0099] The traffic detection system 330 may include a detection rule library 332 for determining traffic anomalies. The detection rule library may include at least one detection rule for determining traffic anomalies. For example, the detection rules may include rules for determining anomalies such as whether there are duplicate calls in the traffic, carrying user tags, sub-call duplicates, SQL aggregation, interface anomalies, etc. When the traffic detection system receives the call traffic, it can run the detection rules in the rule library one by one. When determining whether the call traffic is abnormal call traffic, the traffic detection system can assign an abnormal call label indicating the type of the abnormal call to the abnormal call traffic, and can store the call traffic with the added abnormal call label in a preset abnormal database 340.

[0100] For the call traffic with abnormal call labels stored in the abnormal database 340, the alarm system 350 can read it regularly based on a preset period. For example, it can read the call traffic with abnormal call labels stored in the abnormal database every 1 day, 3 days, or 7 days according to requirements.

[0101] The alarm system 350 may include a screening rule library 352. The screening rule library 352 includes at least one screening rule corresponding to the abnormal call traffic. For example, the screening rule corresponding to the duplicate call traffic may include: the call duration for making duplicate calls to at least some of the multiple sub-services reaches a preset threshold; and / or, the ratio of the number of calls for making duplicate calls to at least some of the multiple sub-services to the total number of calls to the multiple sub-services reaches a threshold; the screening rule corresponding to carrying user tags may include carrying the user tag.

[0102] The alarm system 350 can generate corresponding abnormal traffic alarms for abnormal call traffic that meets the screening rules, and can push the abnormal traffic alarms to the users corresponding to the target service to prompt the users to locate the abnormality for the target call link. For example, the server side may include a mobile work platform built based on a proprietary cloud, and the client side may be an instant messaging client 360 for mobile office corresponding to the proprietary cloud. The instant messaging client 360 can maintain a user group composed of at least one user corresponding to the target service. The instant messaging client 360 can be set with an RPA robot for pushing alarm prompt messages to the user group. The alarm system 350 can push the abnormal traffic alarm to the RPA robot, so that the RPA robot can further push the abnormal traffic alarm to the user group to prompt the user to locate the abnormality for the call link corresponding to the abnormal call traffic.

[0103] The following describes in detail the method for detecting the call link described in each of the above embodiments in combination with specific application scenarios.

[0104] Application scenario 1: A scenario for performing a stress test on the above target service.

[0105] In this scenario, the above service request may specifically be a stress test request for the above target service, and the above abnormal call traffic may be the above repeated call traffic.

[0106] When the server receives a stress test request for the above target service sent by the stress test user through the client, it can collect the call data of the stress test request for the above target service through the above traffic collection system by means of traffic recording.

[0107] The above traffic detection system can obtain the call data collected by the above traffic collection system, and perform abnormal call analysis on the call data by running the detection rules in the detection rule library to determine whether the call data is repeated call traffic. The specific details of performing abnormal call analysis on the call data to determine whether the call data is repeated call traffic will not be elaborated here. Please refer to the description of the previous embodiments.

[0108] When the above traffic detection system determines through abnormal call analysis that the call data is repeated call data, it can add an abnormal call label indicating that the call data is repeated call data to the repeated call data, and then store the abnormal call data in the abnormal database.

[0109] The above warning system can regularly read abnormal call transactions from the abnormal database for centralized processing. By running the screening rules in the screening rule library, it analyzes and screens the duplicate call data in the abnormal database, and filters out the valuable duplicate call data among these duplicate call data. The specific details of filtering out the valuable duplicate call data among these duplicate call data will not be elaborated here. Please refer to the description of the previous embodiment. For example, as mentioned above, those duplicate call data with a relatively high impact on the system operation of the server can be filtered out.

[0110] After filtering out the valuable duplicate call data, the warning system can generate an abnormal warning and push the abnormal warning to the stress testers related to the target service, reminding these stress testers to perform abnormal location on the target call link corresponding to the duplicate call data.

[0111] Since the call results (i.e., stress test results) for the above target service based on the above stress test requests cannot detect duplicate calls, duplicate calls are a very hidden type of abnormal call. If the duplicate call abnormality is not detected in time during the stress test, it will affect the performance of the stress test.

[0112] By adopting the above technical solution, the duplicate call abnormality for the target service and the call link where the duplicate call abnormality occurs can be discovered in time, so that the relevant stress testers no longer need to manually locate the call link where the duplicate call abnormality occurs, thereby reducing the time cost of discovering the call link with the duplicate call abnormality and improving the efficiency of the relevant personnel in handling abnormal problems of the call link with the duplicate call abnormality. Moreover, in this way, the call link with a relatively hidden duplicate call abnormality that cannot be discovered through manual location can also be discovered in time, thereby avoiding affecting the stress test performance for the above target service due to omission of such abnormal call links.

[0113] Application scenario two: The scenario where VIP users (i.e., the above key users) make service calls to the above target service.

[0114] In this scenario, the above service request can specifically be a service call request from VIPs to the above target service, and the above abnormal call traffic can be the abnormal call traffic of the service call requests initiated by VIP users to the above target service.

[0115] When the server receives a service call request for the above-mentioned target service sent by a VIP user through the client, it can collect the call data of the service call request to the above-mentioned target service through traffic recording by the above-mentioned traffic collection system, and after collecting the call data of the service call request to the above-mentioned target service, it can determine whether the user who initiated the service call request is a VIP user in the preset VIP user list; if so, a VIP user tag indicating that the user is a VIP user can be further added to the collected call traffic.

[0116] The above-mentioned traffic detection system can obtain the call data collected by the above-mentioned traffic collection system, and perform abnormal call analysis on the call data by running the detection rules in the detection rule library to determine whether the call data is abnormal call traffic.

[0117] When the traffic detection system determines that the call data is abnormal call data after abnormal call analysis, an abnormal call tag indicating the abnormal call type can be added to the call data, and then the abnormal call data is stored in the abnormal database.

[0118] The above-mentioned alarm system can read abnormal call transactions from the abnormal database at regular intervals for centralized processing, and analyze and filter the abnormal call data in the abnormal database by running the screening rules in the screening rule library, and filter out valuable abnormal call data from these abnormal call data. For example, as mentioned above, abnormal call data carrying VIP user tags can be filtered out as valuable abnormal call data. Abnormal call data carrying VIP user tags can be processed first.

[0119] After filtering out abnormal call data carrying VIP user tags, the alarm system can generate abnormal alarms and push the abnormal alarms to stress testers related to the target service, reminding these stress testers to prioritize abnormal location of the target call links corresponding to the abnormal call data carrying VIP user tags.

[0120] By adopting the above technical solution, the abnormal call data of VIP for the above-mentioned target service can be used as the call link corresponding to the valuable abnormal call data, and pushed to the relevant personnel in the form of abnormal alarm for priority processing, so that the call exceptions of VIP users in the process of calling the target service can be processed first, thereby improving the service call experience of VIP users.

[0121] In an exemplary embodiment of the present specification, a device capable of implementing the above method is also provided.

[0122] Figure 4 is a schematic structural diagram of a device provided by an exemplary embodiment. Figure 4, at the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410. Of course, it may also include other hardware required for other tasks. One or more embodiments of this specification can be implemented in software. For example, the processor 402 reads the corresponding computer program from the non-volatile memory 410 into the memory 409 and then runs it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, and can also be hardware or a logic device.

[0123] Please refer to Figure 5 , in a software implementation manner, a detection device for a call link is provided, which is applied to a server, and a target service is deployed on the server; the target service includes at least one call link composed of multiple sub-services in a preset call order; the device includes:

[0124] A traffic collection module 510, configured to obtain the call traffic of the service request for the target service in response to a service request for the target service sent by a client; wherein, the call traffic includes call data generated when the service request calls the multiple sub-services, and the call data is combined in the preset call order of the sub-services;

[0125] A traffic analysis module 520, configured to perform abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic;

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

[0127] Optionally, before obtaining the call traffic of the service request for the target service, it further includes:

[0128] A call data generation module 540, configured to call the multiple sub-services in sequence according to the call order in response to a service request for the target service sent by a client, and obtain the call data generated when the service request calls the multiple sub-services in sequence;

[0129] The obtained call data is combined in the call order to generate the call traffic of the service request for the target service.

[0130] Optionally, it further includes:

[0131] The call log generation module 550 is configured to generate call logs for the service requests for the multiple sub-services respectively, and combine the generated call logs in the call order to generate a call log corresponding to the call chain for the user to use when performing exception location on the call chain.

[0132] Optionally, it further includes:

[0133] The storage module 560 is configured to add an exception call label indicating the type of the exception call to the call traffic when determining that the call traffic is abnormal call traffic, and store the call traffic with the added exception call label in a preset exception database.

[0134] Optionally, it further includes:

[0135] The screening rule screening module 570 is configured to periodically read, based on a preset period, the abnormal call traffic with an added exception call label from the exception database;

[0136] screen the abnormal call traffic that meets the preset screening rules from the read abnormal call traffic;

[0137] generate an abnormal traffic alarm corresponding to the screened abnormal call traffic.

[0138] Optionally, the screening rule screening module 570 includes:

[0139] The duplicate traffic determination module 572 is configured to determine whether there is call data in the call traffic where the service identifiers and call parameters of the called sub-services included are the same; if so, determine that the call traffic is duplicate call traffic.

[0140] Optionally, the screening rule screening module 570 includes:

[0141] The duplicate traffic screening module 574 is configured to determine whether the call duration of repeated calls for at least some of the multiple sub-services reaches a preset threshold; and / or,

[0142] determine whether the ratio of the number of repeated calls for at least some of the multiple sub-services to the total number of calls for the multiple sub-services reaches a threshold.

[0143] Optionally, the call log generation module 550 includes:

[0144] The abnormality location guide generating module 552 is used to perform abnormality location analysis on the call link based on the call log corresponding to the call link, and generate an abnormality location guide corresponding to the call link based on the analysis result;

[0145] Generating an abnormal traffic alarm corresponding to the abnormal call traffic, including:

[0146] Based on the link identifier of the call link corresponding to the abnormal call traffic and the abnormal location guide, an abnormal traffic alarm corresponding to the abnormal call traffic is generated.

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

[0148] Optionally, if the service request is a service call request for the target service, the method further includes:

[0149] The key user determination module 554 is used to determine whether the user who initiates the service call request is a key user in a preset key user list; if so, add a user tag indicating that the user is a key user to the acquired call traffic of the service call request for the target service.

[0150] Optionally, the key user determination module 554 includes:

[0151] The abnormal traffic determination module 556 is used to determine whether the call traffic carries the user tag indicating that the user is a key user; if so, determine that the call traffic is abnormal call traffic.

[0152] Optionally, if the service request is a service call request for the target service, the preset screening rule includes: carrying the user tag.

[0153] Optionally, the server includes a mobile work platform built based on a proprietary cloud; the client is an instant messaging client corresponding to the proprietary cloud and used for mobile office.

[0154] Optionally, also include:

[0155] The abnormal traffic alarm pushing module 580 is used to push the abnormal traffic alarm to the RPA robot, so that the RPA robot further pushes the abnormal traffic alarm to the user group.

[0156] Optionally, the sub-service includes methods that can be called by users; the target service includes an application program composed of multiple methods that can be called by users; or, the sub-service includes an application subprogram composed of multiple callable methods that can be called by users; the target service includes an application program composed of multiple application subprograms.

[0157] The systems, devices, modules or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, and the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver device, a game console, a tablet computer, a wearable device, or a combination of any several of these devices.

[0158] In a typical configuration, a computer includes one or more processors (CPUs), an input / output interface, a network interface, and a memory.

[0159] The memory may include non-permanent memory in the computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of, for example, read-only memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.

[0160] Computer-readable media includes permanent and non-permanent, removable and non-removable media and can be implemented by any method or technology for storing information. The information can be computer-readable instructions, data structures, program modules, 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 technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0161] It should also be noted that the term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, commodity or device comprising a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, commodity or device comprising said element.

[0162] The specific embodiments of this specification are described above. Other embodiments are within the scope of the appended 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 the desired result. Additionally, the processes depicted in the drawings do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0163] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a", "the" and "said" used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly dictates 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.

[0164] It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of this specification to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to determining".

[0165] The above description is only the preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included within the scope of protection of one or more embodiments of this specification.

Claims

1. A detection method for a call chain, which is applied to a server, and a target service is deployed on the server; The target service includes at least one call link composed of multiple sub-services in a preset call order; the method includes: In response to a service request for the target service sent by a client, obtain the call traffic of the service request for the target service; wherein, the call traffic includes call data generated when the service request sequentially calls the multiple sub-services in the preset call order, and the call data is combined in the preset call order of the sub-services; the call data includes the service identifier and call parameters of the called sub-service; Perform abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic; wherein the abnormal call traffic includes repeated call traffic that repeatedly calls at least some of the multiple sub-services; performing abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic includes: determining whether there is call data in the call traffic whose included service identifier and call parameters of the called sub-service are the same; if so, determining that the call traffic is repeated call traffic; If the call traffic is abnormal call traffic, push the target call link corresponding to the abnormal call traffic to the user corresponding to the target service in the form of an abnormal traffic alarm to prompt the user to perform abnormal positioning on the target call link.

2. The method according to claim 1, the method further includes: Generate call logs of the service request for the multiple sub-services respectively, and combine the generated call logs in the call order to generate a call log corresponding to the target call link for the user to use when performing abnormal positioning on the target call link.

3. The method according to claim 1, the method further includes: When it is determined that the call traffic is abnormal call traffic, add an abnormal call label indicating the type of the abnormal call to the call traffic, and store the call traffic with the added abnormal call label in a preset abnormal database.

4. The method according to claim 3, generating an abnormal traffic alarm corresponding to the call traffic includes: Screen the abnormal call traffic in the abnormal database that meets the preset risk conditions; Generate an abnormal traffic alarm corresponding to the screened abnormal call traffic.

5. The method according to claim 4, the risk conditions corresponding to the repeated call traffic include: The call duration of repeatedly calling at least some of the multiple sub-services reaches a preset threshold; and / or, The ratio of the number of repeated calls to at least some of the multiple sub-services to the total number of calls to the multiple sub-services reaches a threshold.

6. The method according to claim 2, the method further includes: Based on the call log corresponding to the call link, perform abnormal positioning analysis on the call link, and generate an abnormal positioning guide corresponding to the call link based on the analysis result; Generating an abnormal traffic alarm corresponding to the abnormal call traffic includes: Based on the link identifier of the target call link corresponding to the abnormal call traffic and the abnormal location guide, an abnormal traffic alarm corresponding to the abnormal call traffic is generated.

7. According to the method of claim 4, the service request comprises a service call request for the target service; or a stress test request for the target service.

8. The method according to claim 7, if the service request is a service call request for the target service; The method further comprises: Determine whether the user who initiates the service call request is a key user in a preset key user list; If yes, a user tag indicating that the user is a key user is added to the acquired call flow of the service call request for the target service.

9. The method according to claim 8, wherein the preset risk conditions include: Carrying the user tag.

10. According to the method of claim 1, the server is a mobile work platform built on a private cloud; the client is an instant messaging client corresponding to the private cloud and used for mobile office.

11. The method according to claim 10, wherein the instant messaging client maintains a user group composed of at least one user corresponding to the target service; wherein, The instant messaging client is pre-configured with an RPA robot for pushing alarm prompt information to the user group; Pushing the abnormal traffic alarm to a user corresponding to the target service includes: The abnormal traffic alarm is pushed to the RPA robot, so that the RPA robot further pushes the abnormal traffic alarm to the user group.

12. According to the method of claim 1, the sub-service includes a method that can be called by a user; the target service includes an application composed of multiple methods that can be called by a user; or, the sub-service includes an application sub-program that can be called by a user and consists of multiple methods that can be called; the target service includes an application composed of multiple application sub-programs.

13. A detection device for a call link, which is applied to a server, and a target service is deployed on the server; The target service includes at least one call link composed of multiple sub-services in a preset call order; the device includes: A traffic collection module, configured to obtain, in response to a service request for the target service sent by a client, a call traffic of the service request for the target service; wherein the call traffic includes call data generated when the service request calls the multiple sub-services in sequence according to the preset call sequence, and the call data is combined according to the preset call sequence of the sub-services; the call data includes a service identifier and call parameters of the called sub-service; The traffic analysis module is used to perform abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic; wherein the abnormal call traffic includes repeated call traffic for repeatedly calling at least some of the multiple sub-services; performing abnormal call analysis on the call traffic to determine whether the call traffic is abnormal call traffic, including: determining whether there is call data in the call traffic that contains the same service identifier and call parameters of the called sub-service; if so, determining that the call traffic is repeated call traffic; A traffic positioning module, which is used to push the target call link corresponding to the abnormal call traffic to the user corresponding to the target service in the form of abnormal traffic alarm when the call traffic is abnormal call traffic, so as to prompt the user to perform abnormal positioning for the target call link.

14. An electronic device, comprising: A processor; A memory for storing processor-executable instructions; Wherein, the processor realizes the method according to any one of claims 1-12 by running the executable instructions.

15. A computer-readable storage medium, on which computer-readable instructions are stored, and when the instructions are executed by a processor, the method according to any one of claims 1-12 is realized.

Images