Business topological graph determination method and device and nonvolatile storage medium

Abstract

The invention discloses a business topological graph determination method and device and a nonvolatile storage medium. The method comprises the steps of obtaining a call chain identifier of a target call request, the target call request being used for calling services of network devices in different business systems, and the services being located in the network devices of different levels; in the process that the target calling request is transmitted from the starting service node to the ending service node, contextual information of the target calling request in each service node is determined according to the calling chain identifier, and the contextual information comprises metadata information of the calling chain identifier; the call chain identifier is a unique identifier when the target call request calls the service node; establishing a service topological graph according to the context information; and displaying the business topological graph. The technical problem that a traditional monitoring method can only monitor a single hierarchy and is difficult to insight the dependency relationship and the mutual influence between the hierarchies is solved.

Description

Technical Field

[0001] The present application relates to the field of IT system monitoring, and more specifically, to a method and device for determining a business topology map and a non-volatile storage medium. Background Art

[0002] In the current era of rapid development of information technology and in-depth advancement of digital transformation, the complexity and scale of enterprise IT systems are growing at an unprecedented rate. This complexity is particularly prominent in IT core business scenarios, because these scenarios not only span multiple systems and multiple levels, but also involve complex business processes and highly integrated system architectures. Traditional monitoring methods and tools are often limited to data collection and analysis at a single system or business level, and lack a global perspective to examine the operating status of the entire IT core business scenario. When a system fails or a performance bottleneck occurs, the information provided by traditional monitoring methods usually only involves local or fragmentary information, making it difficult to quickly locate the root cause of the problem, let alone evaluate the operating status from the perspective of the entire business process.

[0003] In addition, due to the lack of an effective end-to-end observability view, it is difficult for enterprises to conduct real-time and comprehensive supervision of all aspects of business operations, which has caused significant limitations in troubleshooting, problem location, business optimization and decision support. As enterprises become more dependent on IT systems, traditional monitoring methods can no longer meet the needs of in-depth analysis and efficient operation and maintenance of IT core business scenarios. Especially in the process of troubleshooting, traditional monitoring methods often require operation and maintenance personnel to manually associate data from different systems and levels. This process is not only time-consuming, but also prone to missing important information, resulting in inaccurate problem location and prolonged fault recovery time. At the business optimization level, the lack of end-to-end business process monitoring makes it difficult for enterprises to fully evaluate business operation efficiency and make adjustments to strategies in the first place, affecting the ability of enterprises to respond quickly to market changes.

[0004] In summary, traditional monitoring methods can only monitor a single level, and it is difficult to gain insight into the dependencies and mutual influences across levels.

[0005] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0006] The embodiments of the present application provide a method, device and non-volatile storage medium for determining a business topology map, so as to at least solve the technical problem that traditional monitoring methods can only monitor a single level and have difficulty in gaining insight into the dependencies and mutual influences across levels.

[0007] According to one aspect of an embodiment of the present application, a method for determining a business topology map is provided, including: obtaining a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels; in the process of the target call request being transmitted from a start service node to an end service node, determining context information of the target call request at each service node based on the call chain identifier, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling a service node; establishing a business topology map based on the context information, wherein the business topology map is used to represent the relationship between different services in different network devices in the business system; and displaying the business topology map.

[0008] In some embodiments of the present application, the context information of the call request at each service node is determined based on the call chain identifier, including: obtaining first information of the target call request entering the first service node, wherein the first information includes the first service ID of the first service node, the first call timestamp of the first service node and the first service name of the first service node, the first service node is any service node passed by the target call request, the first service ID is generated based on the service ID of the parent node of the first service node and the call order of the target call request, and the first service ID is used to mark the time taken by the first service node to process the target call request; based on the call chain identifier of the target call request and the first information, the context information of the first service node is determined.

[0009] In some embodiments of the present application, after determining the context information of the first service node based on the call chain identifier and the first information of the target call request, the method also includes: passing the context information of the first service node to the second service node, wherein the second service node is the next service node of the first service node in the target call request; generating a second service ID of the second service node based on the first service ID in the context information of the first service node and the calling order of the target call request, wherein the second service ID is used to mark the time taken by the second service node to process the target call request; obtaining a second call timestamp and a second service name of the second service node; generating the context information of the second service node based on the second service ID, the second call timestamp and the second service name; and passing the context information of the second service node to the downstream service node of the target call request.

[0010] In some embodiments of the present application, the method also includes: when the first service node processes the target call request, obtaining the processing time and processing result of the first service node; associating the processing time and processing result of the first service node with the first service ID and the call chain identifier to generate first processing information; and storing the first processing information in a log.

[0011] In some embodiments of the present application, the calling order of the target call request is determined by: collecting monitoring data of network devices in different business systems; preprocessing the monitoring data to obtain processed standard monitoring data; horizontally and vertically integrating the standard monitoring data according to business logic to obtain multiple business chains, wherein the business chain includes the calling order of all call requests to the service; and determining the calling order of the target call request from the multiple business chains.

[0012] In some embodiments of the present application, after establishing a business topology map based on context information, the method also includes: determining an index value of a target node in the business topology map, wherein the target node is any node in the business topology map; when the index value is greater than a preset index threshold, marking the target node as an abnormal node; and displaying the abnormal node in a preset color.

[0013] In some embodiments of the present application, the preset indicator threshold is adjusted in the following manner: determining the indicator type corresponding to the indicator value; querying the first data from the database based on the indicator type, and determining the mean and standard deviation of the first data, and determining the filtering threshold based on the standard deviation; deleting the data in the first data that is greater than the filtering threshold to obtain the second data; performing regression analysis on the second data to determine the changing pattern of the indicator type; predicting the predicted value of the indicator type at the target time based on the changing pattern; and adjusting the upper and lower limits of the preset indicator threshold based on the predicted value and the standard deviation.

[0014] According to another aspect of an embodiment of the present application, a device for determining a business topology map is also provided, including: an acquisition module, used to obtain a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels; a determination module, used to determine the context information of the target call request at each service node based on the call chain identifier during the process of the target call request being transmitted from a start service node to an end service node, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling a service node; an establishment module, used to establish a business topology map based on the context information, wherein the business topology map is used to represent the relationship between different services in different network devices in a business system; and a display module, used to display the business topology map.

[0015] According to another aspect of an embodiment of the present application, an electronic device is also provided, including: a memory for storing program instructions; a processor, connected to the memory, for executing program instructions that implement the following functions: obtaining a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels; in the process of the target call request being transmitted from a starting service node to an ending service node, determining context information of the target call request at each service node based on the call chain identifier, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling a service node; establishing a business topology map based on the context information, wherein the business topology map is used to represent the relationship between different services in different network devices in the business system; and displaying the business topology map.

[0016] According to another aspect of an embodiment of the present application, a non-volatile storage medium is further provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-mentioned method for determining a service topology map by running the computer program.

[0017] According to another aspect of an embodiment of the present application, a computer program product is also provided, including computer instructions, which implement the above-mentioned method for determining a business topology map when the computer instructions are executed by a processor.

[0018] In an embodiment of the present application, a call chain identifier of a target call request is obtained, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels; in the process of the target call request being transmitted from the starting service node to the ending service node, the context information of the target call request at each service node is determined based on the call chain identifier, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling the service node; a business topology map is established based on the context information, wherein the business topology map is used to represent the relationship between different services in different network devices in the business system; a business topology map is displayed in a manner of obtaining the call chain identifier of the target call request, and then determining the context information of the target call request at each service node based on the call chain identifier, thereby establishing a business topology map, thereby achieving the purpose of displaying the relationship between different services in different network devices through the business topology map, thereby solving the technical problem that traditional monitoring methods can only monitor a single level and it is difficult to gain insight into the dependencies and mutual influences across levels. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0020] Figure 1 It is a hardware structure block diagram of a computer terminal according to a method for determining a service topology map provided in an embodiment of the present application;

[0021] Figure 2 It is a flowchart of a method for determining a service topology map provided according to an embodiment of the present application;

[0022] Figure 3 It is a system flow diagram of a method for determining a service topology map provided according to an embodiment of the present application;

[0023] Figure 4 It is a panoramic monitoring view provided according to an embodiment of the present application;

[0024] Figure 5 is another panoramic monitoring view provided according to an embodiment of the present application;

[0025] Figure 6 It is a structural schematic diagram of a device for determining a business topology map provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0028] The information collected in the embodiments of the present application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or reject automated decision-making results; if the user chooses to reject, the expert decision-making process will be entered.

[0029] The method for determining a service topology map provided in the embodiments of the present application may be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 FIG. 1 shows a hardware structure block diagram of a computer terminal for implementing a method for determining a service topology map. Figure 1 As shown, the computer terminal 10 may include one or more (102a, 102b, ..., 102n are used to illustrate) processors (the processor may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions connected via a wired and / or wireless network. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art can understand that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0030] It should be noted that the one or more processors and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10. As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0031] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the method for determining the business topology map in the embodiment of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, the method for determining the business topology map described above is realized. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0032] The transmission module 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission module 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0033] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 .

[0034] It should be noted that, in some optional embodiments, the above Figure 1 The computer terminal shown may include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of hardware elements and software elements. It should be noted that Figure 1 This is merely one example of a particular embodiment and is intended to illustrate the types of components that may be present in the computer terminal described above.

[0035] In the above-mentioned operating environment, an embodiment of the present application provides an embodiment of a method for determining a business topology diagram. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0036] Figure 2 is a flow chart of a method for determining a service topology map according to an embodiment of the present application, such as Figure 2As shown, the method comprises the following steps:

[0037] Step S202, obtaining a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels.

[0038] In the technical solution provided in step S202, there are multiple implementation methods for obtaining the call chain identifier of the target call request. The following is a specific embodiment:

[0039] The call chain tracing technology is used to capture the request call process across systems and services. When a user request enters a distributed system, at the entry point (such as an application interface gateway or a load balancer, where the application interface gateway is the Application Programming Interface Gateway, referred to as the API gateway), each request call (i.e., the target call request) will generate a unique TraceID (i.e., the call chain identifier), which is used to identify the entire life cycle of the request (i.e., the target call request). The monitoring agent records information such as TraceID, service name, call time, response time, etc. when the service is called to achieve full-link monitoring of the call chain. The TraceID generated when the request enters the distributed system is the key to connecting all subsequent call chain data. TraceID ensures that all monitoring data related to the request can be identified and associated. Even if the data sources are diverse, they can be unified through TraceID. The monitoring data contains logs and monitoring information in multiple formats. By adding TraceID, these data can be identified as call chain data belonging to the same request.

[0040] Step S204, in the process of the target call request being transmitted from the starting service node to the ending service node, the context information of the target call request at each service node is determined based on the call chain identifier, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling the service node.

[0041] In the technical solution provided in step S204, there are multiple ways to determine the context information of the call request at each service node based on the call chain identifier, for example: obtaining first information of the target call request entering the first service node, wherein the first information includes the first service ID of the first service node, the first call timestamp of the first service node, and the first service name of the first service node, the first service node is any service node passed by the target call request, the first service ID is generated based on the service ID of the parent node of the first service node and the call order of the target call request, and the first service ID is used to mark the time taken by the first service node to process the target call request; determining the context information of the first service node based on the call chain identifier and the first information of the target call request.

[0042] It should be noted that after determining the context information of the first service node based on the call chain identifier and the first information of the target call request, the context information of the first service node can also be passed to the second service node, wherein the second service node is the next service node of the first service node in the target call request; based on the first service ID in the context information of the first service node and the call sequence of the target call request, the second service ID of the second service node is generated, wherein the second service ID is used to mark the time spent by the second service node to process the target call request; the second call timestamp and the second service name of the second service node are obtained; the context information of the second service node is generated based on the second service ID, the second call timestamp and the second service name; the context information of the second service node is passed to the downstream service node of the target call request. This process ensures the continuity and integrity of the call chain, allowing operation and maintenance personnel to track from the starting point to the end point of the call chain, which is extremely beneficial for complex service call chain analysis and troubleshooting.

[0043] The calling order of the target call request is determined by: collecting monitoring data of network devices in different business systems; preprocessing the monitoring data to obtain processed standard monitoring data; integrating the standard monitoring data horizontally and vertically according to business logic to obtain multiple business chains, where the business chain includes the calling order of all call requests to services; and determining the calling order of the target call request from multiple business chains. This method can automatically extract the calling order from massive monitoring data, which is crucial for building an accurate business topology map and understanding the system operation status.

[0044] Processing information can be used for data analysis and mining, such as detecting abnormal behavior, predicting system load, optimizing resource allocation, etc., which are important means to improve system performance and stability. Therefore, when the first service node processes the target call request, the processing time and processing result of the first service node are obtained; the processing time and processing result of the first service node are associated with the first service ID and the call chain identifier to generate the first processing information; the first processing information is stored in the log.

[0045] The following is a specific embodiment:

[0046] During the request transmission process, the system will add TraceID and other information (for example, SpanID, call timestamp, service name, etc.) to the metadata of the request to obtain the first information. When the target call request arrives at the first service node, the first service ID (ie, SpanID) is generated through the call sequence and the service ID (SpanID) of the parent node.

[0047] This generation process ensures that the processing information of each service node has a unique identifier in the call chain. The above-mentioned call timestamp can be, for example, the first call timestamp of the first service node. The above-mentioned service name can be, for example, the first service name of the first service node. The above-mentioned metadata is Header (request header) or Context (a batch of information, a collection of information that accompanies the request in the distributed system, which contains key data such as TraceID and SpanID, and is used to transmit the status and identification of the call chain between services to ensure the traceability and transparency of the service call). In this way, when the request is passed to the downstream service (for example, the second service node), the downstream service can obtain the information of the call chain from the first information.

[0048] Based on the call chain identifier and the first information of the request (i.e., the target call request mentioned above), the context information of the first service node is determined. The context information includes but is not limited to request parameters, response results, processing time and call status, call order of the target call request, etc. This information is crucial to understanding how the service node processes the request. When processing the request, the first service node will integrate this context information with the first information and TraceID to ensure the integrity and consistency of the data during cross-service calls. The context information needs to be stored in real time and is usually recorded in a log system or monitoring database to ensure that future analysis can trace back to the detailed processing of each transaction. Through the network protocol (for example, HTTP header), the first service node passes the data packet containing TraceID, SpanID and context information to the downstream service to ensure the continuity and relevance of the data in the distributed system. After receiving the data packet, the called party (downstream service (for example, the second service node)) can extract the TraceID and SpanID, as well as the processing time of the first service node, the calling order of the target calling request and other context information, and generate its own processing information (for example, the second service ID of the second service node), thereby obtaining the second calling timestamp of the second service node and the second service name of the second service node; based on the second service ID, the second calling timestamp and the second service name, the context information of the second service node is generated, and the information is continued to be passed along the calling chain to the downstream service node of the target calling request.

[0049] The calling order of the target call request is determined by collecting monitoring data of network devices in different business systems, for example, collecting data of various business systems, applications, middleware and network devices through monitoring agents and data collection technology, and capturing monitoring data such as performance indicators, logs and call chain tracing in real time or quasi-real time. Alternatively, APM (Application Performance Management) tools can be deployed on application servers, network traffic analyzers (NetFlow analyzers) can be deployed on network devices, and specific monitoring components can be deployed on middleware. Monitoring agents can be lightweight software components used to capture and collect runtime performance data and log information. The deployment of agents can be automated or semi-automated to ensure that all important monitoring points are covered, and the agents are configured to correctly identify and capture performance indicators, logs and call chain data. Monitoring agents must have real-time or quasi-real-time data capture capabilities, which means that during the processing of business requests, the agents can capture necessary monitoring data non-invasively, including but not limited to CPU usage, memory usage, network latency, error logs, call chain tracing information, etc. These data can reflect the operating status and performance bottlenecks of the business system when processing specific requests. Ensure the comprehensiveness and accuracy of data by deploying monitoring agents at key nodes in core IT business scenarios.

[0050] Preprocess the monitoring data to obtain processed standard monitoring data. For example, the collected raw data may come from different data sources with different formats and contents. To ensure the uniformity and comparability of the data, the raw data needs to be standardized, such as data format conversion, field mapping, etc. At the same time, perform data cleaning to remove invalid data, outliers and duplicate data to obtain standard monitoring data to ensure the accuracy of subsequent analysis. At the same time, use the distributed storage system to efficiently manage and store massive amounts of standard monitoring data. The data captured by the monitoring agent needs to be stored in real time or quasi-real time in the distributed storage system (a storage system used to store data in a distributed system). In order to ensure the real-time and accuracy of the data, a data buffer can also be set to write the data to the distributed storage system in batches at regular intervals or when the data reaches a certain amount. At the same time, the distributed storage system needs to provide powerful data query capabilities to support data query and analysis by dimensions such as time, business, and performance indicators.

[0051] The standard monitoring data is integrated horizontally and vertically according to the business logic to obtain multiple business chains, wherein the business chain includes the calling order of all call requests to the service; the calling order of the target call request is determined from the multiple business chains. Among them, the multiple business chains can include horizontally integrated business chains. Specifically, in the horizontal integration, a unique identifier is assigned to each data source (service) (API gateway, service, middleware, etc.), and this identifier is associated with the business logic. For example, each link in the network migration and machine restoration process will have its specific business logic identifier. Each time a service is called, TraceID will be passed along with the request to record the complete path of the request. SpanID is used to identify each service call in the call chain. Even within the same business system, different service calls will have unique SpanIDs. SpanIDs with the same TraceID are merged to build a call chain across business systems. Horizontal concatenation mainly refers to the concatenation of call chains across different business systems. It can ensure that the request calls between different business systems carry the same TraceID. In this way, even if the request spans multiple business systems, the call chain of the entire business process can be connected in series through TraceID to achieve horizontal integration.

[0052] Multiple business chains can also include vertically integrated business chains. Specifically, in vertical integration: vertical concatenation is a call chain from the entry service to the exit service in a business system. Each service will process the request according to its own responsibilities and pass the processing results to the next service. Through the call chain dyeing technology, it can be ensured that the calls between these services are carried out in a predetermined order, and the execution of the entire business process can be tracked and monitored through TraceID. First, the IT system is divided into layers to identify the entry and exit services, intermediate services, and exit services, as well as their internal components and hierarchical relationships. Within each business system, ensure that the requests processed by each service layer are associated with TraceID and SpanID, and record the processing time, results, and context information of the layer. Using the collected data, the service component topology structure within each business system is constructed. This usually involves dependency analysis between services and interaction pattern recognition between layers. By analyzing the parent-child relationship of SpanID, the call sequence and dependency between services are identified to form a vertical business chain.

[0053] Based on the horizontally and vertically integrated data, multiple business chains are constructed, each of which represents a complete business process. The call timestamp and call sequence information are used to determine the order of service calls in the business chain. At the same time, duplicate or invalid data is recorded to ensure that the business chain clearly reflects the business process accurately.

[0054] Through the above steps, standard monitoring data is effectively integrated into multiple clear business chains, which not only provides comprehensive monitoring of business processes, but also greatly improves operation and maintenance efficiency, shortens troubleshooting time, and provides strong data support for IT system optimization and performance improvement. This integration method can help the operation and maintenance team fully grasp the operating status of IT core business scenarios from macro to micro.

[0055] Each of the above services (service nodes) will record its own processing information (such as processing time, processing results, etc.) when processing a request, and associate this information with TraceID and SpanID and store it in a log or monitoring system (that is, the first processing information is stored in the log). In this way, the detailed information of the entire call chain can be queried through TraceID. When the system detects an abnormality or failure, the operation and maintenance personnel can quickly locate the specific service node and time point where the failure occurred through TraceID and the SpanID of the first service node.

[0056] Step S206: Establish a service topology map based on the context information, wherein the service topology map is used to represent the relationship between different services in different network devices in the service system.

[0057] In the technical solution provided in step S206, after the business topology map is established according to the context information, the index value of the target node in the business topology map can also be determined, wherein the target node is any node in the business topology map; when the index value is greater than the preset index threshold, the target node is marked as an abnormal node; and the abnormal node is displayed in a preset color. In this way, the operation and maintenance personnel can intuitively see which nodes in the business topology map are abnormal, which is convenient for rapid response and processing, and improves the stability and availability of the system.

[0058] The preset indicator threshold can be adjusted in the following ways: determine the indicator type corresponding to the indicator value; query the first data from the database according to the indicator type, and determine the mean and standard deviation of the first data, and determine the filtering threshold according to the standard deviation; delete the data in the first data that is greater than the filtering threshold to obtain the second data; perform regression analysis on the second data to determine the change pattern of the indicator type; predict the predicted value of the indicator type at the target time according to the change pattern; adjust the upper and lower limits of the preset indicator threshold according to the predicted value and standard deviation. Dynamic adjustment of the indicator threshold can more accurately reflect the actual operation status of the business system, avoid false alarms or omissions caused by fixed thresholds, and improve the accuracy and reliability of the monitoring system.

[0059] The following is a specific embodiment:

[0060] When an alarm or performance anomaly occurs in a distributed system (the corresponding indicator value is greater than the preset indicator threshold, which is identified as an alarm or performance anomaly), the corresponding business node (i.e. the abnormal node) or system will be highlighted or changed color (i.e. the preset color, such as red) in the view to prompt the user to pay attention. Users can quickly locate the business link or system where the problem occurs based on the alarm information (i.e. directly find the node that changes color).

[0061] The preset indicator threshold is adjusted in the following ways: Determine and configure the indicator type, such as quantity indicator, rate indicator, data granularity, data table structure, etc. Configure the data source, configure the database type of the source database (such as MySQL, etc.) and provide the corresponding connection information and query statements. Establish a connection with the database, obtain historical data, check the data format, and cluster the data according to the indicator ID of the provided indicator type. Perform data preprocessing on the clustered data: 1. Deviation value filtering: Calculate the mean and standard deviation of historical data. Determine the threshold based on the standard deviation and filter the data points whose deviation value exceeds the threshold. Among them, the preset confidence interval can be set to 95%, for example. 2. Missing value filling: Detect and process missing values ​​in historical data. Use the D-value filling method to fill missing values ​​to ensure data integrity and accuracy. Among them, the D-value filling method is a filling method based on data distribution characteristics. It first analyzes the distribution pattern of the data, and then selects the most appropriate value to fill the missing value according to the distribution law of the data. For periodic data, D-value predicts missing values ​​based on the values ​​of other time points in the period; for trend data, it infers missing values ​​based on trend lines.

[0062] Perform regression analysis on the preprocessed data to split it into periodic parameters and trend parameters, and determine the changing patterns of periodic parameters and trend parameters: Perform spectral analysis or time series decomposition on the preprocessed data to identify the periodic and trend components in the data. Periodic parameters are usually related to time periods such as days, weeks, and months, while trend parameters reflect the long-term changing trend of data over time, and use fb prophet to establish the corresponding model. Among them, fb prophet is an open source time series prediction model, which is particularly suitable for time series data with obvious seasonality and trend. Input the preprocessed data into the fb prophet model, and the model will automatically identify and fit the trend and seasonal patterns in the data to generate a prediction model.

[0063] Use the corresponding model to predict the predicted value and trend of the indicator type in the future time to obtain the prediction result (output prediction value and uncertainty interval). According to the prediction result, use the standard deviation to correct the upper and lower limits of the generated threshold. According to the uncertainty interval predicted by the model, combined with the mean and standard deviation of the historical data, the prediction result is corrected to generate more accurate threshold upper and lower limits. For example, the predicted value can be added or subtracted by a multiple of the standard deviation to set the threshold to ensure that the threshold can cover most normal system operation states and timely warn potential anomalies. Intelligent analysis of standard monitoring data is performed to automatically identify potential business failures or performance bottlenecks. At the same time, the business topology map is used to achieve horizontal delimitation (determine the affected business system) and vertical positioning (specific to the fault point or component) of the fault, providing an accurate troubleshooting path for operation and maintenance personnel. The above-mentioned prediction results can be written to the library specified by the configuration file in a table form.

[0064] Step S208: display the service topology diagram.

[0065] The following is a specific embodiment: using visualization technology (such as D3.js, ECharts, etc.) to build a dynamic, interactive end-to-end observability view to display the business topology diagram, for example, using D3.js's Force-Directed Graph to display the dependency relationship between services; using ECharts's Sankey Diagram to display the data flow; using line charts and bar charts to display key performance indicators. This view can intuitively display the overall architecture, data flow, service dependency, and key performance indicators of the business system, and support users to view in depth from global to local level by level.

[0066] Horizontal positioning: global perspective viewing First, view the operating status of the entire IT core business scenario through the global display interface of the end-to-end observability view. The business system in the view is displayed in a graphical way, which is convenient for users to quickly identify the key points in the business process. Alarm and anomaly identification When an alarm or performance anomaly occurs in a distributed system, the corresponding business node or system will be marked in the view by highlighting, changing color, etc., prompting users to pay attention. Users can quickly locate the business link or system where the problem occurs based on the alarm information. You can also analyze specific business links: click on a specific business system or link, and the view will jump to the detailed page of the link, showing more detailed performance indicators, data flow and other information, to help users deeply analyze the root cause of the problem.

[0067] Vertical positioning: System internal hierarchical display: In the end-to-end observability view, the service components and hierarchical relationships within each business system are also clearly displayed. Users can understand the internal architecture and service dependencies of the business system through the view. When a performance bottleneck or failure occurs, users can start from the entry service that generates the alarm and analyze downward along the logical topology. By analyzing the call relationship and data flow between services, users can locate the specific fault point or component.

[0068] For example, Figure 3 As shown, a system flow diagram of a method for determining a service topology diagram is provided, which is the system flow corresponding to the mobile network restoration service, and is a view of the mobile network restoration service process during a certain problem period. It can be found that the entire process passes the work order table from the billing policy link of the policy service node to the billing data link of the data service node, and then passes it to the OSS (opening service node) link through EOP (a service gateway). The "state abnormality quantity" indicator is 45, which exceeds the threshold (that is, the above-mentioned preset indicator threshold) 5, indicating that there is a problem with the restoration work order processing in the OSS link. In order to ensure that the user's restoration process is not interrupted, the emergency restoration process is enabled, so that the billing data link skips the OSS link where the problem occurs. After the emergency restoration process is started, the restoration work order is directly sent to the activation link and then sent to each predetermined network element in the network element link through instructions. The restoration work order circulates normally, ensuring the user's usage perception. The customer relationship management (CRM) is used to manage the interaction between the enterprise and its customers, aiming to optimize customer relationships and improve customer satisfaction.

[0069] When starting the emergency recovery process, analyze the root cause of the fault from a system vertical perspective for the OSS link where the problem occurs: Figure 4 , providing a panoramic monitoring view, Figure 5 Another panoramic monitoring view is provided, such as Figure 4 As shown in the figure, the panoramic monitoring view shows the service layer (displaying multiple OSS entities), the PASS layer (Platform as a Service) shows multiple nodes (service nodes) and PostegreSQL (database management system), and the IAAS layer (Infrastructure as a Service) shows multiple component hosts, physical machines, and host machines. Starting from the entry service (OSS entity 1) that generates the alarm, the analysis is carried out downward along the logical topology. Figure 5 For Figure 4When node 2 in the vertical expansion is carried out, the following analysis conclusions can be drawn: due to the failure of the underlying physical machine (memory is not in place), the virtual machine it carries has problems, which in turn causes the middleware deployed on the virtual machine (for example, a Ctgmq middleware, a middleware used to achieve large-scale, high-concurrency, low-latency message transmission and processing), node 1 (for example, Namesrv node, Namesrv node is responsible for maintaining the routing information of the entire message queue system) and node 2 (for example, Broker node) to have exceptions; when the application service interacts with the middleware (pushing the shutdown and resumption work order message), a large number of failures occur, which affects the backlog of the OSS shutdown and resumption link. Therefore, the root cause of the failure is the failure of the underlying physical machine (memory is not in place).

[0070] Through the above steps, seamless monitoring of the entire process, across systems and levels, from business request triggering to completion can be achieved. Through real-time monitoring and deep visualization technology, the integrity and timeliness of data are ensured, providing a perspective without blind spots for business operations. The innovative call chain technology is adopted to generate and transmit unique TraceID to achieve accurate data concatenation from horizontal business systems to vertical system internal levels. It not only improves the accuracy of data tracking, but also significantly enhances the transparency and traceability of call chains between systems and services. A multi-dimensional, high-definition business topology map is constructed. These topology maps not only intuitively display the overall architecture, data flow and service dependencies of the business system, but also reflect key performance indicators in real time, providing strong data support for operation and maintenance decisions. At the same time, intelligent analysis of monitoring data is performed to automatically identify potential business failures and performance bottlenecks. Combined with the business topology map, the rapid location of faults is achieved, providing an efficient and accurate troubleshooting path for the operation and maintenance team. Through the construction of an end-to-end observability view, enterprises can grasp the operating status of each link of the business process in real time, and promptly discover and locate potential problems and risk points. This real-time monitoring and visual display method greatly shortens the troubleshooting time and improves operation and maintenance efficiency. The intelligent fault diagnosis and location function enables operation and maintenance personnel to quickly and accurately find the root cause of the fault and take appropriate measures to repair it. This not only reduces the impact of faults on business operations, but also improves the stability and reliability of the system.

[0071] The present application also provides a schematic diagram of a structure of a device for determining a service topology map. Figure 6 As shown, including:

[0072] The acquisition module 602 is used to acquire a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels.

[0073] Determination module 604 is used to determine the context information of the target call request at each service node based on the call chain identifier during the process of the target call request being transmitted from the starting service node to the ending service node, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling the service node.

[0074] The determination module 604 is also used to obtain first information of the target call request entering the first service node, wherein the first information includes the first service ID of the first service node, the first call timestamp of the first service node and the first service name of the first service node. The first service node is any service node passed by the target call request. The first service ID is generated based on the service ID of the parent node of the first service node and the call order of the target call request. The first service ID is used to mark the time spent by the first service node to process the target call request; based on the call chain identifier of the target call request and the first information, the context information of the first service node is determined.

[0075] Determination module 604 is also used to collect monitoring data of network devices in different business systems; pre-process the monitoring data to obtain processed standard monitoring data; integrate the standard monitoring data horizontally and vertically according to business logic to obtain multiple business chains, wherein the business chain includes the calling order of all call requests to the service; determine the calling order of the target call request from the multiple business chains.

[0076] Determination module 604 is also used to pass the context information of the first service node to the second service node, wherein the second service node is the next service node of the first service node in the target call request; generate a second service ID of the second service node based on the first service ID in the context information of the first service node and the calling order of the target call request, wherein the second service ID is used to mark the time spent by the second service node to process the target call request; obtain the second call timestamp of the second service node and the second service name of the second service node; generate the context information of the second service node based on the second service ID, the second call timestamp and the second service name; and pass the context information of the second service node to the downstream service node of the target call request.

[0077] The establishing module 606 is used to establish a service topology map according to the context information, wherein the service topology map is used to represent the relationship between different services in different network devices in the service system.

[0078] Establishing module 606 is also used to determine the index value of the target node in the business topology map, where the target node is any node in the business topology map; when the index value is greater than a preset index threshold, mark the target node as an abnormal node; and display the abnormal node in a preset color.

[0079] Establishing module 606 is also used to determine the indicator type corresponding to the indicator value; querying the first data from the database according to the indicator type, and determining the mean and standard deviation of the first data, and determining the filtering threshold according to the standard deviation; deleting the data in the first data that is greater than the filtering threshold to obtain the second data; performing regression analysis on the second data to determine the changing pattern of the indicator type; predicting the predicted value of the indicator type at the target time according to the changing pattern; and adjusting the upper and lower limits of the preset indicator threshold according to the predicted value and the standard deviation.

[0080] The display module 608 is used to display the service topology diagram.

[0081] The embodiment of the present application further provides an electronic device, which includes a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the program instructions to implement the following functions:

[0082] Obtain a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels; in the process of the target call request being transmitted from a start service node to an end service node, determine the context information of the target call request at each service node based on the call chain identifier, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling a service node; establish a business topology map based on the context information, wherein the business topology map is used to represent the relationship between different services in different network devices in the business system; and display the business topology map.

[0083] An embodiment of the present application also provides a non-volatile storage medium, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the following method for determining a business topology map by running the computer program: obtaining a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels; in the process of the target call request being transmitted from a start service node to an end service node, determining context information of the target call request at each service node based on the call chain identifier, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling a service node; establishing a business topology map based on the context information, wherein the business topology map is used to represent the relationship between different services in different network devices in the business system; and displaying the business topology map.

[0084] An embodiment of the present application also provides a computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps of the method for determining the business topology map in each embodiment of the present application are implemented.

[0085] An embodiment of the present application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the steps of the method for determining a business topology map in each embodiment of the present application.

[0086] The embodiment of the present application also provides a computer program, which, when executed by a processor, implements the steps of the method for determining the service topology map in each embodiment of the present application.

[0087] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0088] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0089] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0090] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0091] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0092] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0093] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for determining a service topology graph, characterized in that: include: Obtaining a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels; In the process of transmitting the target call request from the starting service node to the ending service node, context information of the target call request at each service node is determined according to the call chain identifier, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling a service node; Establishing a service topology map according to the context information, wherein the service topology map is used to represent the relationship between different services in different network devices in the service system; The business topology diagram is displayed.

2. The method according to claim 1, characterized in that Determining the context information of the call request at each service node according to the call chain identifier includes: Acquire first information that the target call request enters a first service node, wherein the first information includes a first service ID of the first service node, a first call timestamp of the first service node, and a first service name of the first service node, the first service node is any service node passed by the target call request, the first service ID is generated based on the service ID of a parent node of the first service node and a call sequence of the target call request, and the first service ID is used to mark the time taken by the first service node to process the target call request; Determine the context information of the first service node according to the call chain identifier of the target call request and the first information.

3. The method according to claim 2, characterized in that After determining the context information of the first service node according to the call chain identifier of the target call request and the first information, the method further includes: passing the context information of the first service node to a second service node, wherein the second service node is a next service node of the first service node in the target call request; Generate a second service ID of the second service node according to the first service ID and the calling order of the target calling request in the context information of the first service node, wherein the second service ID is used to mark the time taken by the second service node to process the target calling request; Obtain a second calling timestamp of the second service node and a second service name of the second service node; Generate context information of the second service node according to the second service ID, the second call timestamp and the second service name; The context information of the second service node is passed to the downstream service node of the target call request.

4. The method according to claim 2, characterized in that: The method further comprises: When the first service node processes the target call request, obtaining the processing time and processing result of the first service node; Associating the processing time and processing result of the first service node with the first service ID and the call chain identifier to generate first processing information; The first processing information is stored in a log.

5. The method according to claim 2, characterized in that: The calling order of the target calling request is determined in the following way: Collecting monitoring data of network devices in the different business systems; Preprocessing the monitoring data to obtain processed standard monitoring data; Integrate the standard monitoring data horizontally and vertically according to the business logic to obtain multiple business chains, wherein the business chain includes the calling sequence of all calling requests for services; The calling order of the target calling request is determined from the multiple service chains.

6. The method according to claim 1, characterized in that After establishing the service topology map according to the context information, the method further includes: Determine an index value of a target node in the service topology graph, wherein the target node is any node in the service topology graph; When the indicator value is greater than a preset indicator threshold, marking the target node as an abnormal node; The abnormal node is displayed in a preset color.

7. The method according to claim 6, characterized in that The preset indicator threshold is adjusted in the following way: Determine the indicator type corresponding to the indicator value; querying first data from a database according to the indicator type, determining a mean and a standard deviation of the first data, and determining a filtering threshold according to the standard deviation; Deleting data in the first data that is greater than the filtering threshold value to obtain second data; Performing regression analysis on the second data to determine a change pattern of the indicator type; Predicting the predicted value of the indicator type at the target time according to the change rule; The upper and lower limits of the preset indicator threshold are adjusted according to the predicted value and the standard deviation.

8. A device for determining a service topology graph, characterized in that: include: An acquisition module, used to acquire a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels; A determination module, used to determine the context information of the target call request at each service node according to the call chain identifier during the process of the target call request being transmitted from the start service node to the end service node, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling the service node; An establishing module, used to establish a service topology map according to the context information, wherein the service topology map is used to represent the relationship between different services in different network devices in the service system; The display module is used to display the business topology diagram.

9. An electronic device, characterized in that: include: A memory for storing program instructions; A processor, connected to the memory, is used to execute program instructions that implement the following functions: obtaining a call chain identifier of a target call request, wherein the target call request is used to call services of network devices in different business systems, and the services are located in network devices at different levels; in the process of the target call request being transmitted from a starting service node to an ending service node, determining context information of the target call request at each service node based on the call chain identifier, wherein the context information includes metadata information of the call chain identifier, and the call chain identifier is a unique identifier of the target call request when calling a service node; establishing a business topology map based on the context information, wherein the business topology map is used to represent the relationship between different services in different network devices in the business system; and displaying the business topology map.

10. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the method for determining a service topology map as described in any one of claims 1 to 7 by running the computer program.

11. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the method for determining a service topology map described in any one of claims 1 to 7 is implemented.

Images