Calling chain data acquisition method and device and computer equipment
By dynamically adjusting the acquisition strategy and selecting target data from the call chain data stream by proportion or condition, the problem of balancing storage cost and utilization of call chain data in high-concurrency scenarios is solved, and efficient data acquisition and storage are achieved.
Patent Information
- Application Number
- CN202511791231.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-01
- Publication Date
- 2026-03-03
AI Technical Summary
How to balance the maintenance cost of call chain data with the availability of call chain data, especially the storage and resource consumption of massive call chain data in high-concurrency scenarios.
By dynamically adjusting the acquisition strategy according to the task density of the target system, and using proportional acquisition and condition-based filtering methods, the target call chain data is determined from the call chain data stream and stored, reducing the maintenance cost of full storage while maintaining data availability.
It enables dynamic collection of call chain data in high-concurrency scenarios, reducing maintenance costs while ensuring data availability and collection quality, and adapting to changes in task density.
Smart Images
Figure CN121597522A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus and computer equipment for acquiring call chain data. Background Technology
[0002] APM (Application Performance Management) is a monitoring system used to monitor and manage application performance. It collects call chain data as the application executes various task requests by embedding probes within the monitored application. Because the call chain data describes the call relationships between related services, developers can use the call chain data of abnormal requests to trace the application's runtime state when exceptions occur.
[0003] When in a high-concurrency scenario of task requests, the application generates a massive amount of call chain data. Storing this massive amount of call chain data requires a lot of hardware and network resources, and the maintenance cost is huge. However, only the call chain data corresponding to abnormal requests can be utilized.
[0004] Therefore, how to balance the maintenance cost of call chain data with the availability of call chain data is a technical problem that urgently needs to be solved. Summary of the Invention
[0005] Therefore, it is necessary to provide a method, apparatus, and computer equipment for collecting call chain data that can balance the maintenance cost and availability of call chain data, addressing the aforementioned technical problems.
[0006] Firstly, this application provides a method for collecting call chain data, including:
[0007] The acquisition strategy is determined based on the task density of the target system; wherein, the task density is the number of task requests received per unit period.
[0008] According to the acquisition strategy, target call chain data is determined from the call chain data stream within the target system;
[0009] The target call chain data is stored.
[0010] In one embodiment, the acquisition strategy includes an acquisition mode and acquisition parameters corresponding to the acquisition mode; determining the acquisition strategy based on the task density of the target system includes:
[0011] In response to a user's selection, a collection mode is determined from a first collection mode and a second collection mode; wherein the first collection mode represents proportional collection, and the second collection mode represents condition-based selection;
[0012] The acquisition parameters are determined based on the task density.
[0013] In one embodiment, determining the acquisition parameters based on the task density includes:
[0014] Determine the parameter type that matches the acquisition mode; wherein the parameter type matched by the first acquisition mode is a proportional parameter, and the parameter type matched by the second acquisition mode is a conditional parameter;
[0015] The acquisition parameters are determined based on the task density and the correspondence between the density and the parameter type.
[0016] In one embodiment, determining the acquisition parameters based on the task density and the correspondence between the density and the parameter type includes:
[0017] Based on the correspondence between density and the condition parameters, the acquisition ratio corresponding to the task density is determined as the acquisition parameter;
[0018] Alternatively, determine the target interval where the task density is located, and determine the screening conditions corresponding to the target interval as the collection parameters based on the correspondence between each interval and the condition parameters.
[0019] In one embodiment, determining the target call chain data from the call chain data stream within the target system according to the acquisition strategy includes:
[0020] The collection order is determined based on the aforementioned collection ratio;
[0021] According to the acquisition order, target call chain data is determined from the call chain data stream; wherein, each call chain data in the call chain data stream is arranged in order based on timestamps.
[0022] In one embodiment, determining the target call chain data from the call chain data stream within the target system according to the acquisition strategy includes:
[0023] Write the call chain data stream of the target system into a cache queue;
[0024] The call chain data in the cache queue is filtered to obtain target call chain data that meets any of the filtering conditions.
[0025] In one embodiment, the filtering criteria include at least one of the following:
[0026] The execution result represents the call chain data corresponding to the task request that encountered an execution exception.
[0027] The call chain data carries a preset identifier;
[0028] The call chain data includes at least one high-frequency fault service.
[0029] In one embodiment, storing the target call chain data includes:
[0030] For each target call chain data, determine the identity identifier of the root service in the target call chain data;
[0031] The target call chain data is stored in the target database based on the identity identifier.
[0032] Secondly, this application also provides a call chain data acquisition device, the device comprising a strategy determination module, a target data determination module, and a storage module, wherein:
[0033] The strategy determination module is used to determine the acquisition strategy based on the task density of the target system; wherein, the task density is the number of task requests received per unit period.
[0034] The target data determination module is used to determine target call chain data from the call chain data stream within the target system according to the acquisition strategy.
[0035] The storage module is used to store the target call chain data.
[0036] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the call chain data acquisition method as described in any one of the first aspects above.
[0037] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the call chain data acquisition method as described in any one of the first aspects above.
[0038] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the call chain data acquisition method as described in any one of the first aspects above.
[0039] The aforementioned call chain data acquisition method, apparatus, and computer equipment employ an acquisition strategy that determines and stores target call chain data from the call chain data flow of the target system, rather than storing the entire call chain data in the call volume data stream. This reduces the maintenance cost of requiring full storage of call chain data. Furthermore, the greater the number of task requests received by the target system within a unit period, the higher its task density, and vice versa. The acquisition strategy for the target system to be monitored is determined based on its task density. In other words, the amount of call chain data collected can be dynamically acquired based on task density, thus achieving dynamic acquisition of call chain data and achieving a relative balance between the maintenance cost and the availability of call chain data.
[0040] The first acquisition mode can adaptively adjust the acquisition ratio according to the task density of the target system, thus keeping the amount of call chain data at a controllable level and preventing excessive costs in maintaining call chain data. However, at high task densities, the lower acquisition ratio may cause some usable call chain data to be missed. Therefore, the first acquisition mode is suitable for scenarios with high task densities.
[0041] When using the second acquisition mode and its corresponding filtering conditions as the acquisition strategy, the filtering conditions can be adaptively adjusted according to the task density of the target system. That is, more filtering conditions indicate more call chain data collected. Although the amount of call chain data collected in the second acquisition mode also dynamically changes with task density, unlike the first acquisition mode, the second acquisition mode is based on conditional filtering. While fewer acquisition conditions are needed when the task density of the target system is high, the priority of these acquisition conditions is also higher. In this way, it is possible to not only reduce the amount of call chain data collected but also ensure that the collected call chain data is usable, thus achieving a balance between the cost of maintaining call chain data and its utilization rate. Attached Figure Description
[0042] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0043] Figure 1 This is an application environment diagram of calling the chain data acquisition method in one embodiment;
[0044] Figure 2This is a flowchart illustrating the invocation of the chain data acquisition method in one embodiment;
[0045] Figure 3 This is a flowchart illustrating the process of determining the acquisition parameters in one embodiment;
[0046] Figure 4 This is a schematic diagram of the data storage process in one embodiment;
[0047] Figure 5 This is a structural block diagram of the call chain data acquisition device in one embodiment;
[0048] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0049] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0050] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.
[0051] The call chain data acquisition method provided in this application embodiment can be applied to, for example... Figure 1 The application environment shown is illustrated. In this environment, the APM (Application Performance Management) system communicates with the target system via a network. The APM system's data collection probes are deployed at preset nodes on the target system. The APM system distributes its data collection strategy to these probes, which then collect the detected call chain data within the target system according to the strategy. The target system can be an application (APP) or a business system; this embodiment does not impose specific limitations on either.
[0052] The target system and the APM system can run on the same computer device or on different computer devices. The computer device can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.
[0053] In one exemplary embodiment, such as Figure 2 As shown, a method for collecting call chain data is provided, which can be applied to... Figure 1 Taking the APM system in the example, the explanation includes the following steps 10-30, where:
[0054] Step 10: Determine the acquisition strategy based on the task density of the target system; where task density is the number of task requests received per unit period.
[0055] In the embodiments of this application, the target system responds to the received task request to execute the task, and in the process of executing the task, calls the service related to the task, thereby generating call chain data; this call chain data can be monitored and collected by the acquisition probes deployed in the target system.
[0056] A complete call chain consists of a complete call path, which is composed of multiple nodes. Each node represents a called service, and its attribute information describes relevant call information. The first node in the call chain represents the first called service, also known as the root service. Each node's attribute information includes at least the following: TraceID, Span ID, Parent Span ID, Operation Name, Start Timestamp, Finish Timestamp, Logs, and Span Kind.
[0057] The Trace ID is unique throughout the entire call chain and is used to identify the entire call chain. Within the same call chain data, the Trace ID is the same in the node attributes of each node. The Span ID represents the service being called and is a unique identifier for each node. The Parent Span ID points to the ID of the parent node, which is a key field constituting the call chain; if a node's Parent Span ID is empty, then it indicates that this node is the root node, meaning that the service represented by this node is the root service.
[0058] Operation Name: The name of the operation, such as an API path or database query method. Start Timestamp: The start time of the operation; Finish Timestamp: The end time of the operation. Tags / Labels: Custom key-value pairs used to record additional dimensional information. Logs: Event records that occurred during the operation; each log is also a timestamp and a set of key-value pairs. Span Kind: Indicates the type of span, helping to understand the context of the call; for example, CLIENT (the party issuing the call), ERVER (the party receiving the call), RODUCER (the producer of the message queue), ONSUMER (the consumer of the message queue).
[0059] In this embodiment, the data stream received by the target system can be monitored using a data acquisition probe or a monitoring component pre-deployed within the target system. The number of task requests received by the target system within a unit period is determined based on this data stream, thereby calculating the task density. The unit period is a pre-set time threshold, which can be 10 seconds, 30 seconds, or 1 minute; this embodiment does not specifically limit it. Furthermore, the strategy for collecting the call chain data of the target system changes dynamically according to the task density of the target system, rather than remaining fixed. That is, the collection method in this embodiment is not based on the logic of full data collection in related technologies.
[0060] Step 20: Based on the acquisition strategy, determine the target call chain data from the call chain data stream within the target system.
[0061] In this embodiment of the application, after determining the acquisition strategy, the acquisition strategy is sent to the acquisition probe. The acquisition probe monitors the call chain data generated by the target system and determines the target call chain data to be acquired based on the acquisition strategy. The acquisition strategy can be to determine the target call chain data proportionally from the call chain data stream; or it can be to filter according to preset filtering conditions, using the call chain data that meets the filtering conditions as the target call chain data.
[0062] Step 30: Store the target call chain data.
[0063] In the embodiments of this application, after the target call chain data is determined, the method of storing each target call chain data in the target database can be to directly store each target call chain data in the target database, or to cache it first, and then store each call chain data in the target database in the space and time of the target system.
[0064] In the aforementioned call chain data acquisition method, the acquisition strategy specifies the target call chain data to be determined and stored from the call chain data flow of the target system, rather than storing the entire call chain data in the call volume data stream. This reduces the maintenance cost of storing the entire call chain data. Furthermore, the larger the number of task requests received by the target system within a unit period, the higher its task density, and vice versa. The acquisition strategy for the target system to be monitored is determined based on its task density. In other words, the amount of call chain data collected can be dynamically acquired based on the task density, thus achieving dynamic acquisition of call chain data. This achieves a relative balance between the maintenance cost and the availability of call chain data.
[0065] In one embodiment, reference Figure 3 Step 10 may specifically include steps 11 and 12, wherein:
[0066] Step 11: In response to the user's selection, determine the acquisition mode from the first acquisition mode and the second acquisition mode;
[0067] Step 12: Determine the acquisition parameters based on the task density.
[0068] Specifically, the acquisition strategy includes acquisition modes and acquisition parameters corresponding to the acquisition modes; in this embodiment of the application, the acquisition modes include two types: a first acquisition mode and a second acquisition mode; and each acquisition mode corresponds to a type of acquisition parameter; for example, the parameter type matched by the first acquisition mode is a proportional parameter, and the parameter type matched by the second acquisition mode is a conditional parameter.
[0069] Furthermore, the first acquisition mode represents proportional acquisition, where the proportional parameter represents the value of the acquisition ratio; the second acquisition mode represents condition-based acquisition, where the condition parameter includes multiple selection conditions; for the monitored call chain data stream, according to the selection conditions, the call chain data that meets the selection conditions is selected from the call chain data stream as the target call chain data that can be acquired.
[0070] Whether the current data collection mode to be executed is the first or the second is determined by the user's selection action. After determining the collection mode, the parameter types that match the collection mode are determined, and then the collection parameters are determined based on the task density and the correspondence between density and parameter types.
[0071] In step 12, the task density determines the acquisition parameters, which may specifically include: determining the parameter type that matches the acquisition mode; and determining the acquisition parameters based on the task density and the correspondence between density and parameter type.
[0072] Specifically, when the acquisition mode is the first acquisition mode, the acquisition ratio corresponding to the task density is determined as the acquisition parameter based on the correspondence between density and condition parameters. When the acquisition mode is the second acquisition mode, the target interval of the task density is determined, and the filtering conditions corresponding to the target interval are determined as the acquisition parameters based on the correspondence between each interval and condition parameters.
[0073] The correspondence between task density and parameter type can be preset. For example, for a proportional parameter, the acquisition ratio can be divided into gradients such as 10%, 20%, ... 100%, and then a corresponding task density range can be set for each acquisition ratio. The larger the task density, the smaller the corresponding acquisition ratio. For example, when the task density range is [101, 200], the corresponding acquisition ratio is 30%, and when the task density range is [201, 300], the corresponding acquisition ratio is 20%.
[0074] When the first acquisition mode and the corresponding acquisition ratio are used as the acquisition strategy, the determination of the target call chain data in step 20 includes: determining the acquisition order according to the acquisition ratio; and determining the target call chain data from the call chain data stream according to the acquisition order.
[0075] Specifically, the call chain data in the call chain data stream is arranged in order based on timestamps. For example, when the collection ratio is 10%, for the monitored call chain data stream, the first call chain data is designated as the target call chain data, and then, every 9 call chain data points thereafter, another call chain data point is designated as the target call chain data. For example, the 1st, 11th, and 21st call chain data points are the target call chain data points, thus achieving proportional data collection.
[0076] The first acquisition mode can adaptively adjust the acquisition ratio according to the task density of the target system, thus keeping the amount of call chain data at a controllable level and preventing excessive costs in maintaining call chain data. However, at high task densities, the lower acquisition ratio may cause some usable call chain data to be missed. Therefore, in the first acquisition mode, the acquisition ratio can be determined not only based on task density but also based on the ratio input by the user, and when a user input ratio exists, it should be used first.
[0077] As for the condition parameters, the task density can be pre-divided into multiple continuous gradient intervals, and then the corresponding filtering conditions can be set for each gradient interval. The larger the extreme value of the gradient interval of task density, the fewer the corresponding filtering conditions. However, the larger the extreme value of the gradient interval of task density, the higher the priority of the corresponding filtering conditions. The priority of the filtering conditions is preset by the user.
[0078] When using the second acquisition mode and the corresponding filtering conditions as the acquisition strategy, the steps in step 20 to determine the target call chain data include: writing the call chain data stream of the target system into the cache queue; filtering each call chain data in the cache queue to obtain the target call chain data that meets any filtering condition.
[0079] Specifically, condition-based comparison requires comparing each call chain data with the filtering conditions. Therefore, the monitored call chain data stream needs to be cached in a cache queue first, and then the call chain data is read from the cache queue one by one and compared with the filtering conditions. Call chain data that meets any filtering condition is determined as the target call chain data.
[0080] Furthermore, the filtering criteria include at least one of the following: the call chain data corresponding to the task request whose execution result indicates an execution error; the call chain data carries a preset identifier; the call chain data includes at least one high-frequency fault service.
[0081] Of course, the three filtering conditions listed above are just examples. Other filtering conditions can be included in addition to those, and users can also pre-set them according to their data collection needs; no further restrictions are imposed here.
[0082] When using the second acquisition mode and its corresponding filtering conditions as the acquisition strategy, the filtering conditions can be adaptively adjusted according to the task density of the target system. That is, more filtering conditions indicate more call chain data collected. Although the amount of call chain data collected in the second acquisition mode also dynamically changes with task density, unlike the first acquisition mode, the second acquisition mode is based on conditional filtering. While fewer acquisition conditions are needed when the task density of the target system is high, the priority of these acquisition conditions is also higher. In this way, it is possible to not only reduce the amount of call chain data collected but also ensure that the collected call chain data is usable, thus achieving a balance between the cost of maintaining call chain data and its utilization rate.
[0083] In one embodiment, reference Figure 4 In step 30, the target call chain data is stored, including steps 31 and 32, wherein:
[0084] Step 31: For each target call chain data, determine the identity identifier of the root service in the target call chain data;
[0085] Step 32: Store the target call chain data in the target database based on the identity identifier.
[0086] Specifically, since each node in the call chain data contains a Trace ID—a parameter unique throughout the entire call chain—it can be directly used as an identity identifier. Alternatively, other identifiers representing identity can be embedded when generating the call chain data. Or, when determining the target call chain data, a preset identity identifier can be embedded for each node in the target call chain data. This application embodiment does not impose specific limitations on the specific fields and embedding methods of the target identity identifier.
[0087] As explained above, the root service (root node) can be determined by checking if the Parent Span ID field is empty. After determining the root service, the identity identifier representing the target call chain data is read from the root service's attribute information. Then, based on this identity identifier, the attribute information of each node (service) containing that identity identifier is read and stored in the target database. Reading data using identity identifiers reduces the chance of missing data in the call chain data while avoiding reading redundant data, thus ensuring the integrity of all target call chain data stored in the target database.
[0088] The call chain data acquisition method provided in this application embodiment effectively reduces the overhead of computing, storage, and network resources through a partial sampling strategy. It can also retain detailed call chain data of interest according to application scenarios, meeting different monitoring needs. Furthermore, the acquisition strategy takes effect immediately when automatically distributed to the acquisition probe. This mechanism also enables dynamic adjustment of the sampling strategy; when the business load is high, either the first or second acquisition mode is used, and after the business peak subsides, it reverts to full sampling or the second acquisition mode. This not only effectively handles call chain data acquisition under high-concurrency business scenarios and effectively reduces the overhead of computing, storage, and network resources, but also ensures the real-time performance and effectiveness of APM system data parsing. Moreover, for full acquisition of performance indicator data, the business application performance monitoring results are not distorted due to data sampling. Faulty call chain data can be fully acquired, accurately replaying the fault scenario.
[0089] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.
[0090] Based on the same inventive concept, this application also provides a call chain data acquisition device for implementing the call chain data acquisition method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more call chain data acquisition device embodiments provided below can be found in the limitations of the call chain data acquisition method described above, and will not be repeated here.
[0091] In one exemplary embodiment, such as Figure 5 As shown, a call chain data acquisition device 500 is provided. This device includes a strategy determination module 501, a target data determination module 502, and a storage module 503, wherein:
[0092] The strategy determination module 501 is used to determine the acquisition strategy based on the task density of the target system; wherein, the task density is the number of task requests received per unit period.
[0093] The target data determination module 502 is used to determine the target call chain data from the call chain data stream within the target system according to the acquisition strategy.
[0094] Storage module 503 is used to store the target call chain data.
[0095] The aforementioned call chain data acquisition device determines and stores the target call chain data from the call chain data flow of the target system through the acquisition strategy, rather than storing the entire call chain data in the call volume data stream. This reduces the maintenance cost of storing the entire call chain data. Furthermore, the greater the number of task requests received by the target system within a unit period, the higher its task density, and vice versa. The acquisition strategy for the target system to be monitored is determined based on its task density. In other words, the amount of call chain data collected can be dynamically acquired according to the task density, thus achieving dynamic acquisition of call chain data. This achieves a relative balance between the maintenance cost and the availability of call chain data.
[0096] In one embodiment, the acquisition strategy includes an acquisition mode and acquisition parameters corresponding to the acquisition mode; the strategy determination module 501 is specifically used for:
[0097] In response to the user's selection operation, a collection mode is determined from a first collection mode and a second collection mode; wherein, the first collection mode represents proportional collection, and the second collection mode represents condition-based selection collection;
[0098] Determine the acquisition parameters based on the task density.
[0099] In one embodiment, the strategy determination module 501 is specifically used for:
[0100] Determine the parameter type that matches the acquisition mode; wherein, the parameter type matched by the first acquisition mode is a proportional parameter, and the parameter type matched by the second acquisition mode is a conditional parameter;
[0101] The acquisition parameters are determined based on the task density and the correspondence between density and parameter type.
[0102] In one embodiment, the strategy determination module 501 is specifically used for:
[0103] Based on the correspondence between density and condition parameters, the acquisition ratio corresponding to the task density is determined as the acquisition parameter.
[0104] Alternatively, determine the target interval for the task density, and based on the correspondence between each interval and the condition parameters, determine the screening conditions corresponding to the target interval as the collection parameters.
[0105] In one embodiment, the target data determination module 502 is specifically used for:
[0106] The collection order should be determined based on the collection ratio;
[0107] Based on the collection order, the target call chain data is determined from the call chain data stream; wherein, each call chain data in the call chain data stream is arranged in order based on timestamps.
[0108] In one embodiment, the target data determination module 502 is specifically used for:
[0109] Write the call chain data stream of the target system into the cache queue;
[0110] The call chain data in the cache queue is filtered to obtain the target call chain data that meets any of the filtering conditions.
[0111] In one embodiment, the filtering criteria include at least one of the following:
[0112] The execution result represents the call chain data corresponding to the task request that encountered an execution error;
[0113] The call chain data carries a preset identifier;
[0114] The call chain data includes at least one high-frequency fault service.
[0115] In one embodiment, the storage module 503 is specifically used for:
[0116] For each target call chain data, determine the identity identifier of the root service in the target call chain data;
[0117] The target call chain data is stored in the target database based on the identity identifier.
[0118] Each module in the aforementioned call chain data acquisition device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0119] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a call chain data acquisition method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.
[0120] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0121] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods in the above-described call chain data acquisition method embodiments.
[0122] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods in the above-described call chain data acquisition method embodiments.
[0123] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of any of the methods in the above-described call chain data acquisition method embodiments.
[0124] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.
[0125] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0126] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0127] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A method for collecting call chain data, characterized in that, The method includes: The acquisition strategy is determined based on the task density of the target system; wherein, the task density is the number of task requests received per unit period. According to the acquisition strategy, target call chain data is determined from the call chain data stream within the target system; The target call chain data is stored.
2. The method according to claim 1, characterized in that, The acquisition strategy includes acquisition modes and acquisition parameters corresponding to the acquisition modes; The step of determining the acquisition strategy based on the task density of the target system includes: In response to a user's selection, a collection mode is determined from a first collection mode and a second collection mode; wherein the first collection mode represents proportional collection, and the second collection mode represents condition-based selection; The acquisition parameters are determined based on the task density.
3. The method according to claim 2, characterized in that, Determining the acquisition parameters based on the task density includes: Determine the parameter type that matches the acquisition mode; wherein the parameter type matched by the first acquisition mode is a proportional parameter, and the parameter type matched by the second acquisition mode is a conditional parameter; The acquisition parameters are determined based on the task density and the correspondence between the density and the parameter type.
4. The method according to claim 3, characterized in that, The step of determining the acquisition parameters based on the task density and the correspondence between the density and the parameter type includes: Based on the correspondence between density and the condition parameters, the acquisition ratio corresponding to the task density is determined as the acquisition parameter; Alternatively, determine the target interval where the task density is located, and determine the screening conditions corresponding to the target interval as the collection parameters based on the correspondence between each interval and the condition parameters.
5. The method according to claim 4, characterized in that, The step of determining the target call chain data from the call chain data stream within the target system according to the acquisition strategy includes: The collection order is determined based on the aforementioned collection ratio; According to the acquisition order, target call chain data is determined from the call chain data stream; wherein, each call chain data in the call chain data stream is arranged in order based on timestamps.
6. The method according to claim 4, characterized in that, The step of determining the target call chain data from the call chain data stream within the target system according to the acquisition strategy includes: Write the call chain data stream of the target system into a cache queue; The call chain data in the cache queue is filtered to obtain target call chain data that meets any of the filtering conditions.
7. The method according to claim 6, characterized in that, The filtering criteria include at least one of the following: The execution result represents the call chain data corresponding to the task request that encountered an execution exception. The call chain data carries a preset identifier; The call chain data includes at least one high-frequency fault service.
8. The method according to any one of claims 5-6, characterized in that, The step of storing the target call chain data includes: For each target call chain data, determine the identity identifier of the root service in the target call chain data; The target call chain data is stored in the target database based on the identity identifier.
9. A call chain data acquisition device, characterized in that, The device includes a strategy determination module, a target data determination module, and a storage module, wherein: The strategy determination module is used to determine the acquisition strategy based on the task density of the target system; wherein, the task density is the number of task requests received per unit period. The target data determination module is used to determine target call chain data from the call chain data stream within the target system according to the acquisition strategy. The storage module is used to store the target call chain data.
10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.