Service call chain generation method and device and server

Abstract

The invention discloses a service call chain generation method and device, a server and a computer readable storage medium. According to the method, the service log of each machine is collected, the upstream and downstream dependency relationship of the server is identified according to the service log, the server link diagram is generated, and the server link diagram is generated based on the online real-time log, so that the service operation state is truly reflected, the accuracy can be remarkably improved, and the automatic identification dependency replaces manual analysis in the traditional method, so that the efficiency is improved. According to the method, the implementation cost can be remarkably reduced, the server link is converted into the service link through mapping from the server to the service module, and the service link diagram is generated, the mapping relation can be adjusted through the dynamic service log and the service basic information, so that the accuracy of the link diagram is ensured, manual carding is not needed, and the implementation efficiency is improved. And a more efficient and accurate solution is provided for intelligent operation and maintenance.

Description

Technical Field

[0001] The present application relates to the field of intelligent operation and maintenance technology, and specifically to a method, device, server, and computer-readable storage medium for generating a business call chain. Background Art

[0002] In the current business operation and maintenance field, sorting out business call relationships is crucial for system maintenance and optimization. Existing technologies mainly rely on business product design documents, and log in to business servers to capture upstream and downstream server information, and then analyze this data to sort out business call relationships. However, this method has obvious shortcomings. First, the sorting process requires logging in to multiple servers for packet capture and data analysis, which is not only a huge workload, but also may result in data missing. Secondly, the amount of business call relationship data obtained by sorting is huge, and the cost of manual analysis is extremely high. In addition, the old and new versions of business product design documents are constantly alternating, resulting in inconsistencies between the product design information in the document and the actual operating status of the online service, affecting the accuracy of the sorting results. These problems make the existing technology inefficient in sorting out business call relationships and difficult to meet actual operation and maintenance needs.

[0003] Therefore, how to efficiently generate accurate business call relationships is a problem that technical personnel in this field urgently need to solve. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the existing technology, it is expected to provide a method, device, server and computer-readable storage medium for generating a business call chain, which can automatically analyze, classify and grade alarms, efficiently generate accurate business call relationships, and improve system operation and maintenance efficiency.

[0005] In a first aspect, an embodiment of the present application provides a method for generating a service call chain, comprising:

[0006] Collecting the service logs of each machine; wherein the service logs contain service call information;

[0007] Identify upstream and downstream dependencies of the server based on the business log, and generate a server-based call relationship link graph as a server link graph;

[0008] Obtain basic business information and establish a mapping relationship between servers and business modules based on the basic business information;

[0009] According to the mapping relationship, the server link graph is mapped to generate a call relationship link graph based on the business module as a business link graph.

[0010] In one embodiment, identifying upstream and downstream dependencies of a server based on the service log includes:

[0011] Identify the client's downstream call data, the server's upstream call data, and all server information from the business log as upstream and downstream call data;

[0012] The upstream and downstream dependencies in the upstream and downstream call data are identified through a graph algorithm.

[0013] In one embodiment, before identifying the client's downstream call data, the server's upstream call data, and all server information from the business log, the process further includes:

[0014] Extracting fault data from the service log;

[0015] Then identify the client's downstream call data, the server's upstream call data and all server information from the business log, specifically: based on the fault data, identify the client's downstream call data, the server's upstream call data and all server information from the business log.

[0016] In one embodiment, before identifying the client's downstream call data, the server's upstream call data, and all server information from the service log based on the fault data, the method further includes:

[0017] Obtain statistical fault trend change data;

[0018] Based on the fault data, the data of the client calling downstream, the upstream call data of the server and all server information are identified from the business log, including: based on the fault data and the fault trend change data, the data of the client calling downstream, the upstream call data of the server and all server information are identified from the business log.

[0019] In one embodiment, after converting the server link graph into a call relationship link graph based on the business module according to the mapping relationship, the method further includes:

[0020] The AI ​​model is called to identify and delete redundant calls of the business from the business chain diagram.

[0021] In one embodiment, after converting the server link graph into a call relationship link graph based on the business module according to the mapping relationship, the method further includes:

[0022] Call the AI ​​model to identify and mark the core service links in the call relationship link diagram to generate a business core call link diagram.

[0023] In one embodiment, collecting the service logs of each machine includes:

[0024] Collect business logs through lightweight collection agents deployed on each data source node;

[0025] The business log includes: request ID, client IP, server IP, client service subject and server service subject.

[0026] In a second aspect, an embodiment of the present application provides a device for generating a service call chain, including:

[0027] A log collection module is used to collect the service logs of each machine; wherein the service logs include service call information;

[0028] A service link generation module is used to identify the upstream and downstream dependencies of the server based on the business log and generate a server-based call relationship link diagram as a server link diagram;

[0029] A business mapping module is used to obtain basic business information and establish a mapping relationship between servers and business modules based on the basic business information;

[0030] The service link generation module is used to map the server link graph according to the mapping relationship to generate a call relationship link graph based on the service module as a service link graph.

[0031] In a third aspect, an embodiment of the present application provides a server comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, the steps of a method for generating a business call chain are implemented.

[0032] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements the steps of a method for generating a business call chain.

[0033] The method for generating a business call chain provided in this application collects the business logs of each machine, and then identifies the upstream and downstream dependencies of the server based on the business logs to generate a server link diagram. The server link diagram is generated based on the online real-time log to truly reflect the service operation status. It can avoid the impact of the inconsistency between the product design documents and the online status in the traditional method on the correctness of the link diagram, and can significantly improve the accuracy. In addition, the automatic identification of dependencies replaces the manual analysis in the traditional method, which can significantly reduce the implementation cost. Then, through the mapping from the server to the business module, the server link is converted into a business link to generate a business link diagram. The business link diagram can intuitively display the call relationship between business modules, help identify core links, optimize redundant calls and quickly locate business faults. Compared with the traditional method that relies on static documents that cannot adapt to business iterations, this method can adjust the mapping relationship through dynamic business logs and basic business information to ensure the accuracy of the link diagram, and does not require manual combing, providing a more efficient and accurate solution for intelligent operation and maintenance.

[0034] Additional aspects and advantages of the present invention will be set forth in part in the description which follows and, in part, will be obvious from the description which follows, or may be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Other features, objects and advantages of the present application will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0036] Figure 1 A schematic diagram of a process for generating a service call chain provided in an embodiment of the present application is shown;

[0037] Figure 2 A schematic diagram of a log collection process provided by an embodiment of the present application is shown;

[0038] Figure 3 A schematic diagram of a business log analysis process provided by an embodiment of the present application is shown;

[0039] Figure 4 An exemplary structural block diagram of a device for generating a service call chain provided in an embodiment of the present application is shown;

[0040] Figure 5 A schematic diagram of the structure of a computer system suitable for implementing a server according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0041] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the invention are shown in the accompanying drawings.

[0042] It should be noted that, in the absence of conflict, the embodiments in this application and the features in the embodiments can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments. Although the embodiments of the present application provide the method operation instruction steps shown in the following embodiments or drawings, more or fewer operation instruction steps may be included in the method based on routine or no creative labor. In steps where there is no necessary causal relationship logically, the execution order of these steps is not limited to the execution order provided in the embodiments of the present application. During the actual processing process or when the device is executed, the method may be executed in the order of the methods shown in the embodiments or drawings or in parallel.

[0043] Example 1:

[0044] This embodiment proposes a method for generating a service call chain. Please refer to Figure 1 , Figure 1 FIG. 1 shows a flow chart of a method for generating a service call chain provided in this embodiment. Figure 1 As shown, the method includes:

[0045] S101. Collect business logs of each machine;

[0046] Each machine refers to the hardware or virtual host that carries the business system, including but not limited to: physical servers, virtual computing nodes, and network equipment.

[0047] Among them, physical servers include Java service servers, GO service servers, and database servers in the computer room; virtual computing nodes include containers (Docker), virtual machines (VMs), and cloud servers (EC2, Alibaba Cloud ECS); and network devices include load balancers and gateways (if they generate business-related logs).

[0048] Business logs record all types of interaction events within a business system, including the technical details and business semantics of business calls. Business logs include, but are not limited to: request ID (a unique identifier for the call chain); client and server IP addresses (addresses of the caller and callee); call time, interface name, response status code (e.g., timeout, success); client service entity (e.g., appname, identifying the specific business application); server service entity (e.g., business service, database, Redis, identifying the business function being called); and business-related parameters (e.g., order ID, user ID, transaction amount, and other business data).

[0049] The method for collecting business logs of individual machines is not limited in this embodiment. The pre-collected business logs can be directly imported, or the original log data can be obtained by calling the log collection device and then the data is screened and pre-processed as needed. It will not be described in detail here.

[0050] S102, identifying the upstream and downstream dependencies of the server based on the business log, and generating a server-based call relationship link diagram as a server link diagram;

[0051] Business logs contain call information such as the client IP, server IP, and request ID (e.g., client IP 192.168.1.10 calling server IP 192.168.1.20). These are the raw data used to identify dependencies. The upstream and downstream servers, as well as the dependencies, are determined from the business logs. The upstream server refers to the party initiating the call (e.g., the client server); the downstream server refers to the party being called (e.g., the server server). Dependencies can be determined based on the call direction in the logs.

[0052] A server link graph is a visualization of server IP addresses as nodes and call relationships as directed edges. For example, 192.168.1.10 → 192.168.1.20 indicates that the upstream server 1.10 calls the downstream server 1.20.

[0053] This method automatically generates a link diagram from the log, which can avoid manually logging into multiple servers to capture packets for analysis and reduce the workload. At the same time, information extraction based on the full log data can avoid the problems of missing data or document inconsistency with reality in the existing technology.

[0054] S103: Obtain basic business information and establish a mapping relationship between the server and the business module based on the basic business information;

[0055] The server link diagram uses the server IP as the node, such as 1.10→1.20. To achieve the transformation from server call to business module call, the node is replaced with the business module through the mapping relationship, such as Web service module→order management module, to generate a business call link diagram.

[0056] The mapping relationship between servers and business modules is established based on business foundation information. Business foundation information refers to static data describing the business system architecture, functional modules, and technical deployment. Its core content includes business architecture documentation (business module divisions and standard business processes between modules), technology-business mapping tables (the correspondence between server IP / service names and business modules, and the mapping between application names (appnames) and business functions), and service deployment lists (the types of business services running on each server and the business lines to which they belong).

[0057] The mapping relationship between servers and business modules can be established through a three-level mapping of server IP → service name → business module. For example, through the technical deployment list in the business basic information, the physical server IP is associated with the specific running service, and then according to the business architecture document, the technical services are classified into the corresponding business function modules, and finally the mapping from server to business module is realized.

[0058] This step obtains basic business information and establishes a mapping relationship. Through the technology-business association rules, the technical calls of the physical server are converted into logical interactions of the business modules, so that the system is upgraded from the technical perspective of server IP interaction to the business perspective of business module collaboration.

[0059] S104: Map the server link graph according to the mapping relationship to generate a call relationship link graph based on the business module as a business link graph.

[0060] Obtain all server IP nodes (such as 1.10, 1.20, 1.30) and call relationship edges (such as 1.10→1.20) from the server link graph, traverse each server IP node, and find its corresponding business module through the mapping relationship; for example, server IP 1.10 is mapped to the Web service module (user interaction); server IP 1.20 is mapped to the order management module; the original link Figure 1 .10→1.20 is converted into Web service module→order management module, and a call relationship link diagram based on the business module is generated as the business link diagram.

[0061] The business chain diagram uses business modules as nodes, focusing on how business functions collaborate, and providing operations and maintenance with an analytical perspective that is closer to business needs.

[0062] Based on the above introduction, the method for generating a business call chain provided in this embodiment collects the business logs of each machine, and then identifies the upstream and downstream dependencies of the server based on the business logs to generate a server link diagram. The server link diagram is generated based on the online real-time log, which truly reflects the service operation status. It can avoid the impact of the inconsistency between the product design documents and the online status in the traditional method on the correctness of the link diagram, and can significantly improve the accuracy. In addition, the automatic identification of dependencies replaces the manual analysis in the traditional method, which can significantly reduce the implementation cost. Then, through the mapping from the server to the business module, the server link is converted into a business link to generate a business link diagram. The business link diagram can intuitively display the call relationship between business modules, help identify core links, optimize redundant calls and quickly locate business faults. Compared with the traditional method that relies on static documents that cannot adapt to business iterations, this method can adjust the mapping relationship through dynamic business logs and basic business information to ensure the accuracy of the link diagram, and does not require manual combing, providing a more efficient and accurate solution for intelligent operation and maintenance.

[0063] Example 2:

[0064] The above embodiment does not limit the specific identification method of upstream and downstream dependencies. In order to improve operability and ensure the accuracy of analysis, this embodiment proposes an identification method:

[0065] Step S102 of identifying the upstream and downstream dependencies of the server based on the service log can be specifically performed as follows:

[0066] Step S21: Identify the client's downstream call data, the server's upstream call data, and all server information from the business log as upstream and downstream call data;

[0067] like Figure 3 The figure shows a schematic diagram of the service log analysis process. In this embodiment, service logs are clearly divided into three types of input: client call downstream data, server call upstream data, and server information. Client call downstream data refers to the extraction of downstream service call records initiated by the client (caller) from the log, including information such as the client IP address, downstream server IP address, call time, and request ID. For example, a log record showing client IP address 192.168.1.10 calling server IP address 192.168.1.20 is considered client call downstream data.

[0068] Server upstream call data refers to the call records of upstream clients on the server (called party), including the server IP, upstream client IP, call frequency, error rate, etc. For example, the frequency statistics of server IP 192.168.1.20 being called by upstream IP 192.168.1.10 are considered server upstream call data.

[0069] All server information refers to the integration of basic server attributes (such as IP, service type, and business module) and call context (such as call results and response time) to form a complete server call data set.

[0070] Integrate the three types of data to form an upstream and downstream call data set. Among them, the two-way data collection of the client's downstream call data and the server's upstream call data can avoid omissions in call relationships and improve integrity. Moreover, the two types of data can verify the authenticity and integrity of the calls with each other to avoid misjudgment of dependency relationships.

[0071] Step S22: Identify upstream and downstream dependencies in the upstream and downstream call data through a graph algorithm.

[0072] Graph algorithms (such as DFS / BFS) analyze data, abstracting call relationships into directed graph models and automatically identifying direct and indirect dependencies. When identifying dependencies through graph algorithms, they treat servers as nodes and call relationships as directed edges. This allows for precise modeling of complex many-to-many dependencies, ensuring the accuracy of dependency analysis. Furthermore, the link graphs generated by these algorithms intuitively display the hierarchical relationships of the dependency chain, facilitating visual interaction.

[0073] It should be noted that this embodiment does not limit the specific type of graph algorithm used, and can be selected based on the business scenario and data analysis accuracy requirements, which will not be elaborated here.

[0074] The upstream and downstream dependency identification method provided in this embodiment classifies and identifies three types of data from business logs, which can ensure the integrity and accuracy of the call relationship and provide comprehensive data support for subsequent analysis; at the same time, the method uses graph algorithms to efficiently identify dependency relationships, realize the visualization and quantitative analysis of complex topological structures, and improve the automation and accuracy of dependency identification.

[0075] Example 3:

[0076] Based on the above embodiment, before executing step S21 to identify the client's downstream call data, the server's upstream call data and all server information from the business log, in order to improve the efficiency of upstream and downstream call relationship identification, fault data can be first extracted from the business log.

[0077] We filter out data containing fault records (such as logs containing keywords like error and timeout) from business logs to form a fault dataset. This data records information such as the time, type, and scope of the fault. Based on this fault data, we identify client calls, server calls, and server information related to the fault from business logs.

[0078] By filtering log information by fault data, you can focus on analyzing call relationships related to the fault, avoiding interference from the full data set and improving fault tracing efficiency. For example, if a payment service fails, this step can quickly determine whether it is caused by a client call timeout (client downstream data) or an abnormal server call (server upstream data). It can also combine server information to determine whether the failure affects core business modules.

[0079] Furthermore, when identifying client-side call downstream data, server-side upstream call data and server information, statistical fault trend change data can also be obtained. At the same time, by combining fault data with fault trend change data, log information can be targeted and filtered from two dimensions: current fault records and historical fault trends, to achieve auxiliary analysis for identifying upstream and downstream call relationships.

[0080] Fault data refers to specific fault records (such as call timeouts and error codes) extracted in real time from business logs, including details such as the time, type, and scope of the fault. Fault trend data, on the other hand, refers to the statistical analysis results of historical fault data. For example, the fault count curve for a service over the past week and the fluctuation trend of fault severity over time reflect the temporal characteristics of faults.

[0081] Fault data is used to quickly locate the direct cause of the current fault (such as a client call timeout), and fault trend data is used to discover potential problems (such as an increasing frequency of link failures indicating an impending serious failure) to implement preventive operation and maintenance. The two types of data verify each other to avoid misjudgments caused by a single data point.

[0082] Example 4:

[0083] In the above embodiment, the specific implementation method of collecting the business logs of each machine in step S101 is not limited. In one embodiment, the business logs can be collected by a lightweight collection agent deployed at each data source node, such as Figure 2 As shown, distributed and real-time collection is achieved.

[0084] Install a log collection agent on each machine (such as PHP server, Java server, GO server, PYTHON server). The agent supports multi-format log parsing (JSON, text, XML, etc.) and adapts to the log output of different business systems.

[0085] Agent monitors the business log files on the machine in real time (such as

[0086] / var / log / application.log); filter irrelevant logs (such as system logs) according to rules, extract business-related records, and remove redundant fields; convert logs in different formats into a standard structure (such as JSON format containing timestamp, request ID, and service principal).

[0087] The collected business logs include but are not limited to: request ID, client IP, server IP, client service subject, and server service subject.

[0088] Request ID: The unique identification information of the log call link.

[0089] Client IP: records the caller's client server address information.

[0090] Server IP: records the server address information of the called party.

[0091] Client service principal: records detailed information about the client service, such as appname.

[0092] Server service subject: records detailed information of the server, which may include various types of service information, such as business services, databases, and redis.

[0093] After generating log data containing the above key information, the preprocessed log data is transmitted to the data aggregation node through the network; the aggregation node can store the data in a log database (such as Elasticsearch, Kafka) for subsequent analysis.

[0094] The service log collection method provided in this embodiment implements distributed collection by deploying an Agent on each machine, thereby solving the problems of heavy workload and incomplete data in manual collection in the prior art.

[0095] Embodiment 5:

[0096] After obtaining the business chain diagram, although it reflects the calling relationship between modules, it may contain low-frequency, non-core, or repeated calling links. In order to reduce the resources occupied by invalid calls and optimize business processes, we can further use AI models to conduct in-depth analysis of business chains, automatically identify and eliminate redundant calls that do not contribute substantially to the core business. The identification dimensions of redundant calls include call frequency, business impact, and chain substitutability. For example, we can analyze the historical frequency of call chains and mark low-frequency calls (such as less than 1 per month) as potentially redundant. Another example is to evaluate the impact of call chain failures on core businesses. If the failure does not affect the main process (such as the comment module calling the recommendation module), it is determined to be redundant.

[0097] A complete business link diagram includes both core and non-core links. Furthermore, after converting the server link diagram into a business link diagram, AI models can be used to conduct in-depth analysis of the call relationships between business modules, automatically identifying core service links that are critical to business operations. These links are then annotated to generate a link diagram focused on the core business, preventing non-core links from interfering with O&M priorities. Core service links are identified by factors such as business impact, call frequency, and stability. Fault trend correlation is also considered. For example, the impact of link failures on core business metrics (such as order volume and payment success rate) is analyzed. If a link failure causes a business metric to drop by more than a threshold (such as 10%), the link is identified as a core link. For another example, based on historical fault trend data, if a link's fault frequency is strongly correlated with peak business periods (e.g., failures are inevitable during promotional events), the link is identified as a core link. The business core call link diagram intuitively demonstrates the scope of a fault's impact on the business, helping O&M personnel quickly locate critical business paths, prioritize the stability of core links, and accelerate fault location.

[0098] It should be noted that the AI ​​model for redundant call identification and the AI ​​model for core service link identification in this embodiment can be one model, or two models can be trained separately. In addition, this embodiment does not limit the specific model type of the AI ​​model. For example, graph neural networks (GNN), deep learning models (Transformer), supervised learning models (random forest, XGBoost), etc. can be selected, which will not be repeated here.

[0099] Example 6:

[0100] Further references Figure 4 , which shows an exemplary structural block diagram of a business call chain generation device according to an embodiment of the present application, which mainly includes: a log collection module, a service link generation module, a business mapping module and a business link generation module. The business call chain generation device adopts a modular design and realizes efficient and accurate business link generation through four core units.

[0101] The log collection module is used to collect the business logs of each machine; wherein the business logs contain business call information;

[0102] The service link generation module is used to identify the upstream and downstream dependencies of the server based on the business log and generate a server-based call relationship link diagram as the server link diagram;

[0103] The business mapping module is used to obtain basic business information and establish a mapping relationship between servers and business modules based on the basic business information;

[0104] The business link generation module is used to map the server link graph according to the mapping relationship to generate a call relationship link graph based on the business module as the business link graph.

[0105] In the device for generating the business call chain provided by this embodiment, the log collection module can efficiently and stably collect the log data generated by large-scale complex systems, avoiding the high workload and data loss problems of manually logging into the server to capture packets; the service link generation module performs intelligent analysis on the business logs, can automatically identify the upstream and downstream dependencies of the server and generate a link diagram, reducing the cost of manual analysis and improving the efficiency of link combing; the business mapping module obtains basic business information and establishes a mapping relationship between the server and the business module, realizing the semantic conversion from the technical layer to the business layer, so that the link diagram has business readability; the business link generation module generates a business link diagram based on the mapping relationship. Overall, the modules work together to form a complete closed loop from log collection, technical link analysis to business link generation, realizing automated data collection, intelligent analysis and business semantic abstraction, solving the problems of high labor costs, inaccurate data, and missing business semantics in the existing technology, and providing intelligent operation and maintenance with an efficient, accurate and adaptable solution for complex distributed systems.

[0106] Embodiment seven:

[0107] Reference below Figure 5 , Figure 5 A schematic diagram of the structure of a computer system suitable for implementing a server according to an embodiment of the present application is shown.

[0108] like Figure 5 As shown, the computer system includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 502 or the program loaded from the storage part 508 into the random access memory (RAM) 503. Various programs and data required for the operation instructions of the system are also stored in the RAM 503. The CPU 501, ROM 502 and RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0109] The following components are connected to the I / O interface 505: an input section 506 including a keyboard, a mouse, and the like; an output section 507 including components such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 508 including components such as a hard disk; and a communication section 509 including components such as a network interface card such as a LAN card or a modem. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 510 as needed, so that a computer program read therefrom can be installed into the storage section 508 as needed.

[0110] In particular, according to the embodiment of the present application, the above reference flow chart Figure 1 The described process can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program code for executing the method shown in the flowchart. In such an embodiment, the computer program includes program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 509, and / or installed from a removable medium 511. When the computer program is executed by the central processing unit (CPU) 501, the above-mentioned functions defined in the system of the present application are executed.

[0111] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can, for example, be an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or component. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical cable, RF, or any suitable combination thereof.

[0112] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operating instructions of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the aforementioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than the order marked in the accompanying drawings. For example, the boxes represented by two connections can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operating instruction, or can be implemented using a combination of dedicated hardware and computer instructions.

[0113] The units or modules involved in the embodiments described in this application may be implemented in software or hardware. The units or modules described may also be provided in a processor. The names of these units or modules do not, in certain circumstances, constitute limitations on the units or modules themselves.

[0114] As another aspect, the present application further provides a computer-readable storage medium, which may be included in the server described in the above embodiments, or may exist independently and not be incorporated into the server. The computer-readable storage medium stores one or more programs, which, when used by one or more processors, execute the data balancing method described in the present application.

[0115] The above description is merely a preferred embodiment of the present application and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to the technical solutions formed by a specific combination of the above-mentioned technical features, but also encompasses other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the aforementioned disclosed concepts. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for generating a business call chain, characterized in that: include: Collecting the service logs of each machine; wherein the service logs contain service call information; Identify upstream and downstream dependencies of the server based on the business log, and generate a server-based call relationship link graph as a server link graph; Obtain basic business information and establish a mapping relationship between servers and business modules based on the basic business information; According to the mapping relationship, the server link graph is mapped to generate a call relationship link graph based on the business module as a business link graph.

2. The method according to claim 1, wherein Identifying upstream and downstream dependencies of the server based on the business log includes: Identify the client's downstream call data, the server's upstream call data, and all server information from the business log as upstream and downstream call data; The upstream and downstream dependencies in the upstream and downstream call data are identified through a graph algorithm.

3. The method according to claim 2, wherein Before identifying the client's downstream call data, the server's upstream call data, and all server information from the business log, the following steps are also included: Extracting fault data from the service log; Then identify the client's downstream call data, the server's upstream call data and all server information from the business log, specifically: based on the fault data, identify the client's downstream call data, the server's upstream call data and all server information from the business log.

4. The method according to claim 3, wherein Before identifying the client's downstream call data, the server's upstream call data, and all server information from the business log based on the fault data, the following steps are also included: Obtain statistical fault trend change data; Based on the fault data, the data of the client calling downstream, the upstream call data of the server and all server information are identified from the business log, including: based on the fault data and the fault trend change data, the data of the client calling downstream, the upstream call data of the server and all server information are identified from the business log.

5. The method according to claim 1, wherein After converting the server link graph into a call relationship link graph based on the business module according to the mapping relationship, the method further includes: The AI ​​model is called to identify and delete redundant calls of the business from the business chain diagram.

6. The method according to claim 1, wherein After converting the server link graph into a call relationship link graph based on the business module according to the mapping relationship, the method further includes: Call the AI ​​model to identify and mark the core service links in the call relationship link diagram to generate a business core call link diagram.

7. The method according to claim 1, wherein The collection of service logs of each machine includes: Collect business logs through lightweight collection agents deployed on each data source node; The business log includes: request ID, client IP, server IP, client service subject and server service subject.

8. A device for generating a business call chain, characterized in that: include: A log collection module is used to collect the service logs of each machine; wherein the service logs include service call information; A service link generation module is used to identify the upstream and downstream dependencies of the server based on the business log and generate a server-based call relationship link diagram as a server link diagram; A business mapping module is used to obtain basic business information and establish a mapping relationship between servers and business modules based on the basic business information; The service link generation module is used to map the server link graph according to the mapping relationship to generate a call relationship link graph based on the service module as a service link graph.

9. A server comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images