Operation and maintenance topological graph generation method and device of micro-service architecture, equipment and medium

Abstract

The invention discloses an operation and maintenance topological graph generation method and device for a micro-service architecture, equipment and a medium. The method comprises the following steps: acquiring micro-service architecture data respectively provided by a plurality of data sources, cleaning the micro-service architecture data, and acquiring a plurality of core fields under each data source; according to the core field under the first data source, determining each node having an association relationship in the SAAS layer, the PAAS layer and the IAAS layer, and constructing a topological relation graph according to each node; according to the core field under the second data source and a pre-trained detection model, obtaining alarm information of each node in the topological relation graph; and marking the topological relation graph according to alarm information, and generating an operation and maintenance topological graph of the micro-service architecture. By the adoption of the technical scheme, multi-level data can be connected, the full-view operation and maintenance topological graph is obtained, the calling relation is more visual and clear, faults can be found rapidly, and fault point troubleshooting is assisted.

Description

Technical Field

[0001] The present invention relates to the field of computer software technology, and in particular to a method, device, equipment and medium for generating an operation and maintenance topology map of a microservice architecture. Background Art

[0002] In a microservice environment, there are many operation and maintenance resource objects involved, and the calling relationships between resources are complex, making it difficult to find the fault point after a failure occurs.

[0003] There are some observability products on the market that can observe faults in microservice architectures. However, when it comes to observing faults in large business systems, across systems, or across departments, the data walls between systems or departments may cause the entire fault observation process to be unsmooth, affecting the efficiency of troubleshooting.

[0004] Currently, there is no public product that can achieve data connectivity among the SAAS (Software as a Service) layer, PAAS (Platform as a Service) layer, and IAAS (Infrastructure as a Service) layer, and it is impossible to intuitively determine the fault point in the call chain. Summary of the invention

[0005] The present invention provides a method, device, equipment and medium for generating an operation and maintenance topology map of a microservice architecture, which can connect multi-level data and obtain an operation and maintenance topology map from a full perspective, making the calling relationship more intuitive and clear, and can quickly discover faults and assist in troubleshooting.

[0006] According to one aspect of the present invention, a method for generating an operation and maintenance topology graph of a microservice architecture is provided, comprising:

[0007] Obtain microservice architecture data provided by multiple data sources respectively, and clean the microservice architecture data to obtain multiple core fields under each data source;

[0008] According to the core fields under the first data source, determine the nodes with associated relationships in the SAAS layer, the PAAS layer, and the IAAS layer, and construct a topological relationship diagram according to the nodes;

[0009] According to the core fields under the second data source and the pre-trained detection model, obtain the alarm information of each node in the topological relationship diagram;

[0010] The topology diagram is annotated according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture.

[0011] According to another aspect of the present invention, a device for generating an operation and maintenance topology map of a microservice architecture is provided, comprising:

[0012] A data cleaning module is used to obtain microservice architecture data provided by multiple data sources, clean the microservice architecture data, and obtain multiple core fields under each data source;

[0013] A topology relationship diagram construction module is used to determine nodes with associated relationships in the SAAS layer, the PAAS layer, and the IAAS layer according to the core fields under the first data source, and to construct a topology relationship diagram according to each node;

[0014] An alarm information acquisition module, used to acquire the alarm information of each node in the topological relationship diagram according to the core field under the second data source and the pre-trained detection model;

[0015] The operation and maintenance topology diagram generation module is used to annotate the topology relationship diagram according to the alarm information and generate an operation and maintenance topology diagram of the microservice architecture.

[0016] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0017] at least one processor; and

[0018] a memory communicatively connected to the at least one processor; wherein,

[0019] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the method for generating an operation and maintenance topology map of the microservice architecture described in any embodiment of the present invention.

[0020] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the method for generating an operation and maintenance topology map of a microservice architecture described in any embodiment of the present invention when executed.

[0021] The technical solution of the embodiment of the present invention cleans the microservice architecture data provided by multiple data sources respectively, obtains multiple core fields under each data source, determines the nodes with associated relationships in the SAAS layer, PAAS layer and IAAS layer according to the core fields under the first data source, and constructs a topological relationship diagram according to each node, obtains the alarm information of each node in the topological relationship diagram according to the core fields under the second data source and a pre-trained detection model, and annotates the topological relationship diagram according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture. This method can connect the data of the SAAS layer, PAAS layer and IAAS layer, obtain a full-view operation and maintenance topology diagram, make the calling relationship more intuitive and clear, and can quickly discover faults, thereby improving the accuracy and comprehensiveness of node anomaly detection and assisting in fault point troubleshooting.

[0022] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0024] Figure 1 This is a flowchart of a method for generating an operation and maintenance topology diagram of a microservice architecture provided in accordance with Embodiment 1 of the present invention;

[0025] Figure 2 is a schematic diagram of a topological relationship diagram provided according to an embodiment of the present invention;

[0026] Figure 3 This is a flowchart of another method for generating an operation and maintenance topology diagram of a microservice architecture provided in Embodiment 2 of the present invention;

[0027] Figure 4 is a schematic diagram of a call relationship snapshot provided according to an embodiment of the present invention;

[0028] Figure 5 It is a schematic diagram of the structure of a device for generating an operation and maintenance topology map of a microservice architecture provided in accordance with a third embodiment of the present invention;

[0029] Figure 6 It is a structural schematic diagram of an electronic device that implements the method for generating an operation and maintenance topology map of a microservice architecture according to an embodiment of the present invention. DETAILED DESCRIPTION

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

[0031] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention 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 interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0032] Embodiment 1

[0033] Figure 1 This is a flowchart of a method for generating an operation and maintenance topology map of a microservice architecture provided in the first embodiment of the present invention. This embodiment can be applied to generate an operation and maintenance topology map between multiple levels in a microservice architecture, and determine the situation of a faulty node in the microservice architecture based on the operation and maintenance topology map. The method can be executed by an operation and maintenance topology map generating device for a microservice architecture, which can be implemented in the form of hardware and / or software, and can generally be configured in a computer or processor with data processing capabilities. Figure 1 As shown, the method includes:

[0034] S110. Obtain microservice architecture data provided by multiple data sources respectively, clean the microservice architecture data, and obtain multiple core fields under each data source.

[0035] Optionally, microservice architecture data may include call chain data collected through embedded points in each application, and platform data accessed by multiple open source platforms. Open source platforms may include K8S-API, CMDB (Configuration Management Database), Zabbix, and Prometheus. These open source platforms and data interfaces embedded in each application can also be understood as data sources.

[0036] Optionally, after obtaining the microservice architecture data provided by each data source, the microservice architecture data may be aggregated and cleaned to obtain multiple core fields under each data source.

[0037] In an optional example, after the call chain data is cleaned, the core fields obtained may include: "traceID", "spanID", "parentspanID", "serviceName", "interfaceName", "instanceName", "host", "cost", "status", "remote_url", "start_time" and their values. Based on the core fields of the call chain data, the call relationship in a single call chain can be clarified.

[0038] Among them, "traceID" is the globally unique ID of a single call, "spanID" is the unique ID of a node in a call chain, "parentspanID" is the parent node ID, "serviceName" is the service name, "interfaceName" is the interface name, "instanceName" is the application instance name (container name), "host" is the host name, "cost" is the time taken in milliseconds, "status" is the call status, "remote_url" is the middleware call, and "start_time" is the start time of the call.

[0039] In an optional example, after the microservice architecture data provided by K8S-API is cleaned, the core fields obtained may include: "pod_name", "pod_ip", "container_name", "node_ip" and "namespace".

[0040] Among them, these core fields are used to indicate the ownership relationship between containers and Pods at the PAAS layer, the ownership relationship between Pods and namespaces, and the deployment relationship between Pods and hosts (Nodes). "pod_name" is the Pod name, "pod_ip" is the Pod IP, "container_name" is the container name, "node_ip" is the host IP, and "namespace" is the namespace.

[0041] In an optional example, after the microservice architecture data provided by the CMDB is cleaned, the core fields obtained may include: "resourceName", "resourceID", "resourceType" and "attribute".

[0042] Among them, these core fields are used to represent the basic resource data of the IAAS layer, "resourceName" is the resource name, "resourceID" is the resource ID, "resourceType" is the resource type, and "attribute" is the attribute value.

[0043] In an optional example, after the microservice architecture data provided by Zabbix and Prometheus is cleaned, the core fields obtained may include: "alert_time", "alert_level", "alert_discription" and "alert_obj".

[0044] Among them, "alert_time" is the alarm time, "alert_level" is the alarm level, "alert_discription" is the alarm content, and "alert_obj" is the alarm object. The core fields of the microservice architecture data cleaning provided by Zabbix are used to indicate the alarm status of the resource objects of the IAAS layer, and the core fields of the microservice architecture data cleaning provided by Prometheus are used to indicate the alarm status of the resource objects of the PAAS layer.

[0045] Optionally, the above core fields are only for illustrative purposes, and the purpose is to obtain core fields with the same meaning as above. For different microservice architectures, the specific representation of the core fields may be different. Therefore, it is not limited to the specific field content of the above core fields. Of course, the obtained core fields can also be adaptively increased or decreased according to user needs.

[0046] S120. According to the core fields under the first data source, determine the nodes with associated relationships in the SAAS layer, the PAAS layer, and the IAAS layer, and construct a topological relationship diagram according to the nodes.

[0047] Optionally, in the SAAS layer, each service can serve as a node; in the PAAS layer, containers, Pods, hosts, and virtual spaces can all serve as nodes; in the IAAS layer, databases, virtual machines, and other infrastructure can serve as nodes. There is no limitation on this, and the specific node configuration depends on the resource configuration at each level.

[0048] Optionally, the first data source may include call chain data, a first open source platform, and a second open source platform, wherein the first open source platform may be K8S-API, and the second open source platform may be CMDB, but is not limited to the above open source platforms. It is only necessary to ensure that the same core fields as K8S-API and CMDB can be obtained.

[0049] Optionally, the core fields obtained from the call chain data can represent the call relationship in the SAAS layer. The target call chain can be determined based on "traceID", "spanID", and "parentspanID", that is, based on the global unique ID of a single call, the unique ID of a node in a call chain, and the parent node ID. The target call chain includes multiple services with call relationships, and the call relationship between each service can be determined.

[0050] Specifically, the services belonging to the target call chain can be located according to the globally unique ID of a single call, and then the call relationship between the services can be determined according to the unique ID of a node in the call chain and the parent node ID, to clarify which service is the child node and which service is the parent node.

[0051] Figure 2 is a schematic diagram of an optional topological relationship diagram. Figure 2 As shown, service A to service D are services in the SAAS layer. Each service can be used as a node in the topology diagram. The call relationship between service A and service D can be determined based on the global unique ID of a single call, the unique ID of a node in a call chain, and the parent node ID. In addition, the service name of each service in the SAAS layer can be determined based on the "serviceName" in the core field of the call chain data. For example, for service A to service D, the container and application instance of each service can be labeled based on the "instanceName".

[0052] It can be understood that, based on the core fields under the first open source platform, the ownership relationship between the Pod and the host machine in the PAAS layer, and the ownership relationship between the Pod and the container can be determined, and based on these ownership relationships, the association relationship between each node in the PAAS layer can be determined.

[0053] Specifically, you can determine whether the Pod is deployed in a specific host and the container is deployed in a specific Pod based on the Pod name, Pod IP, container name, and host IP. For example, Figure 2 In the example shown, the ownership relationship between the container and the Pod, and the ownership relationship between the Pod and the Node are determined respectively, and then the association relationship between the nodes of the PAAS layer is determined.

[0054] Optionally, the association relationship between the SAAS layer and the PAAS layer can be determined based on the container name in the core field of the first open source platform, such as "container_name", and the application instance name (container name) in the core field of the call chain data, such as "instanceName". When the values ​​of "container_name" and "instanceName" are the same, the target service in the SAAS layer has an association relationship with the target node in the PAAS layer. Figure 2 In the example shown, service C is deployed in container C, container C is deployed in PodC, and the container name of container C is the same as the container name of container C of the PAAS layer. Therefore, service C has an association relationship with the PodC node of the PAAS layer.

[0055] In another optional embodiment, based on the Pod IP in the core field of the first open source platform, such as "pod_ip", and the host name in the core field of the call chain data, such as "host", when the host name of the target service is the same as the Pod IP of the target Pod node, the target service can also be associated with the target Pod node.

[0056] Optionally, the association between the SAAS layer and the IAAS layer can be determined based on the attribute value in the core field of the second open source platform, such as "attribute", and the middleware call in the core field of the call chain data, such as "remote_url". When the target service of the SAAS layer has an association relationship with the target node of the IAAS layer, the attribute value and the value of the middleware call are the same value. Figure 2 In the example shown, the application instance D of the service D corresponds to the connection address and port of the IAAS layer node.

[0057] Optionally, the association between the PAAS layer and the IAAS layer can be determined based on the attribute value in the core field of the second open source platform, such as "attribute", and the host IP in the core field of the first open source platform, such as "node_ip". Figure 2 In the example shown, in the PAAS layer, PodC is deployed in NodeC, the IP of NodeC is 182.1.1.10, and the value of VMC in the IAAS layer is also 182.1.1.10. Therefore, the virtual machine node of the IAAS layer can be associated with the host node of the PAAS layer.

[0058] Optionally, after determining the internal relationships within the SAAS layer and the PAAS layer, as well as the relationships between the SAAS layer and the PAAS layer, the relationships between the IAAS layer and the PAAS layer, and the relationships between the SAAS layer and the IAAS layer, the data between the SAAS layer, the PAAS layer, and the IAAS layer can be connected to construct a topological relationship diagram including the SAAS layer, the PAAS layer, and the IAAS layer.

[0059] S130. Obtain the alarm information of each node in the topological relationship diagram according to the core fields of the second data source and the pre-trained detection model.

[0060] Optionally, the second data source may include call chain data, a third open source platform, and a fourth open source platform, wherein the third open source platform may be Zabbix, and the fourth open source platform may be Prometheus, but is not limited to the above open source platforms. It is only necessary to ensure that the same core fields as Zabbix and Prometheus can be obtained.

[0061] It can be understood that the core fields of the microservice architecture data cleaning provided by Zabbix are used to indicate the alarm status of the resource objects of the IAAS layer, and the core fields of the microservice architecture data cleaning provided by Prometheus are used to indicate the alarm status of the resource objects of the PAAS layer. According to the core fields of Zabbix and the core fields of Prometheus, the alarm status of each node in the PAAS layer and the IAAS layer can be directly determined, including the alarm time, alarm level, alarm content and alarm object.

[0062] Optionally, for each service in the SAAS layer, the success volume, average time consumption and success rate of the target service within each monitoring time range can be determined through the call chain data, or the core fields after the call chain data is cleaned, and the success volume, average time consumption and success rate can be input into the pre-trained detection model at the same time to obtain the output result of the detection model.

[0063] Optionally, the monitoring time range can be customized. For example, the monitoring time range can be 1 minute, which means that the service is monitored once every minute.

[0064] Optionally, based on the call chain data or the core fields of the call chain data after cleaning, the total number of calls to the target service within each monitoring time range can be counted, and the number of successes, average time consumption, and success rate can be calculated based on the value of the "cost" field in milliseconds, the value of the call status "status" field, and the total number of calls to the target service.

[0065] Optionally, the output results of the detection model may include health, indicator detection status, upper limit of detection conditions, and lower limit of detection conditions. The indicator detection status can be used to indicate whether the current indicator of the target service is normal or abnormal. If the current indicator is abnormal, an alarm needs to be issued for the target service.

[0066] S140. Annotate the topology diagram according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture.

[0067] Optionally, after determining the alarm information of each node, the topology diagram can be annotated. For example, for each service in the SAAS layer, its indicator detection status can be annotated, and the upper and lower limits of the detection conditions can also be annotated at the same time. A health trend graph can also be generated based on the health level and the health trend graph can also be annotated. For the PAAS layer and the IAAS layer, the alarm time, alarm level, alarm content and alarm object can be determined based on the core fields and annotated.

[0068] The technical solution of the embodiment of the present invention cleans the microservice architecture data provided by multiple data sources respectively, obtains multiple core fields under each data source, determines the nodes with associated relationships in the SAAS layer, PAAS layer and IAAS layer according to the core fields under the first data source, and constructs a topological relationship diagram according to each node, obtains the alarm information of each node in the topological relationship diagram according to the core fields under the second data source and a pre-trained detection model, and annotates the topological relationship diagram according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture. This method can connect the data of the SAAS layer, PAAS layer and IAAS layer, obtain a full-view operation and maintenance topology diagram, make the calling relationship more intuitive and clear, and can quickly discover faults, thereby improving the accuracy and comprehensiveness of node anomaly detection and assisting in fault point troubleshooting.

[0069] Embodiment 2

[0070] Figure 3 This is a flowchart of a method for generating an operation and maintenance topology map of a microservice architecture provided in the second embodiment of the present invention. Based on the above embodiment, this embodiment specifically describes a method for generating an operation and maintenance topology map of a microservice architecture. Figure 3 As shown, the method includes:

[0071] S210. Obtain microservice architecture data provided by multiple data sources respectively, clean the microservice architecture data, and obtain multiple core fields under each data source.

[0072] S220. According to the core fields under the first data source, determine the association relationship between the services belonging to the target call chain in the SAAS layer, the container association relationship between the SAAS layer and the PAAS layer, the middleware call relationship between the SAAS layer and the IAAS layer, the host call relationship between the PAAS layer and the IAAS layer, and the ownership relationship between the containers, Pods, and hosts in the PAAS layer.

[0073] Optionally, the first data source includes call chain data, a first open source platform, and a second open source platform;

[0074] According to the core fields under the first data source, the association relationship between the services belonging to the target call chain in the SAAS layer, the container association relationship between the SAAS layer and the PAAS layer, and the middleware call relationship between the SAAS layer and the IAAS layer are determined, including:

[0075] Determine the target call chain according to the call ID in the call chain data, and determine the services in the SAAS layer that belong to the target call chain and the association relationship between the services according to the node ID and the parent node ID in the target call chain;

[0076] Determine the container association relationship between the SAAS layer and the PAAS layer according to the application instance name in the call chain data and the container name in the first open source platform;

[0077] According to the calling address in the calling chain data and the resource attribute value in the second open source platform, the middleware calling relationship between the SAAS layer and the IAAS layer is determined.

[0078] Continuing with the previous example, the core fields "traceID", "spanID", and "parentspanID" obtained from the call chain data can represent the call ID, node ID, and parent node ID, respectively; the core field "instanceName" obtained from the call chain data can represent the application instance name; the core field "container_name" of the first open source platform can represent the container name; the core field "remote_url" obtained from the call chain data, that is, the middleware call, can represent the call address; the core field "attribute" of the second open source platform can represent the attribute value.

[0079] Optionally, according to the core fields under the first data source, determining the host call relationship between the PAAS layer and the IAAS layer and the ownership relationship between the container, Pod and host in the PAAS layer includes:

[0080] Determine the host call relationship between the PAAS layer and the IAAS layer according to the host IP in the first open source platform and the resource attribute value in the second open source platform;

[0081] According to the Pod name, container name, Pod IP and host IP in the first open source platform, the ownership relationship between the container, Pod and host in the PAAS layer is determined.

[0082] S230: According to the internal relationship of each level and the relationship between each level, determine each node in the target call chain and the association relationship between each node, and construct a topological relationship diagram.

[0083] S240. Obtain the alarm information of each node in the topological relationship diagram according to the core fields under the second data source and the pre-trained detection model.

[0084] Optionally, the second data source includes call chain data;

[0085] According to the core fields under the second data source and the pre-trained detection model, the alarm information of each node in the topological relationship diagram is obtained, including:

[0086] According to the core fields in the call chain data, multiple monitoring indicators of each service belonging to the target call chain in the SAAS layer are determined; the monitoring indicators include the success amount, average time consumption and success rate within the monitoring time range;

[0087] Input each monitoring indicator into the detection model respectively, obtain the output result of the detection model, and determine the alarm information of each service in the SAAS layer according to the output result.

[0088] Optionally, the output result includes health status, indicator detection status, detection condition upper limit and detection condition lower limit;

[0089] Determine the alarm information of each service in the SAAS layer according to the output result, including:

[0090] According to the indicator detection status, it is determined whether the target service needs to be alerted, and the health trend graph of the target service is updated according to the health level.

[0091] Optionally, for the detection of indicators, the general indicators will fluctuate within a certain range. For example, the minimum success rate of service A per minute is 60 and the maximum is 75. When it is higher than 75 or lower than 60, the detection model will determine it as abnormal. However, due to the large service volume of the SAAS layer and each service has its own characteristics, it is impossible to monitor with a unified threshold. For different indicators of different services, the detection model has an upper limit and a lower limit of the detection condition. When the upper limit or the lower limit of the detection condition is exceeded, the indicator detection status is determined to be abnormal, otherwise, it is normal.

[0092] The advantage of this setting is that by adding the upper and lower limits of the detection conditions in the output results, users can clearly view the evaluation criteria for each indicator of each service, which makes it easier for users to determine the evaluation results.

[0093] Optionally, the health degree may refer to the health degree of the current monitoring indicator. The health degrees of different indicators may be different. The greater the deviation between the indicator state of the current monitoring indicator and the historical state, the lower the health degree.

[0094] Optionally, a health trend graph may be maintained according to the health level, and each time the health level is updated, the health trend graph stored historically may be updated according to the current health level.

[0095] S250. Annotate the topology diagram according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture.

[0096] Optionally, the method for generating an operation and maintenance topology diagram of a microservice architecture may further include:

[0097] Whenever the specified time node is reached, a call relationship snapshot is generated and saved based on the current operation and maintenance topology diagram;

[0098] After generating the operation and maintenance topology diagram of the microservice architecture, it also includes:

[0099] When it is determined that there is a fault in the target call link according to the current operation and maintenance topology map, the current operation and maintenance topology map is compared with the most recently stored historical call relationship snapshot, and at least one node related to the fault is determined according to the comparison result.

[0100] Optionally, a real-time call relationship may be generated according to the current operation and maintenance topology diagram, and the real-time call relationship may be compared with a historical call relationship snapshot to determine whether there is an obvious call relationship change between the two.

[0101] Figure 4 is a schematic diagram of an optional call relationship snapshot. Figure 4 As shown, the call relationship snapshot can represent the topological relationship between the nodes in the target call chain, and can be used to represent the topological relationship between the services in the SAAS layer. Figure 4 In the example shown, by comparing the historical call relationship snapshot with the real-time call relationship, it is obvious that the call relationship is missing starting from the J node. If there is a fault at this time, you can focus on checking whether there is an abnormality from the F to J node, or directly check whether the J node is abnormal, because it is likely that the abnormality of the J node causes the missing of its downstream calls, such as the application of the J node will be dead.

[0102] The advantage of this setting is that it can clearly and intuitively show users the nodes in the target call chain that may have problems, which plays a certain auxiliary role in troubleshooting.

[0103] The technical solution of the embodiment of the present invention cleans the microservice architecture data provided by multiple data sources respectively, obtains multiple core fields under each data source, determines the nodes with associated relationships in the SAAS layer, PAAS layer and IAAS layer according to the core fields under the first data source, and constructs a topological relationship diagram according to each node, obtains the alarm information of each node in the topological relationship diagram according to the core fields under the second data source and a pre-trained detection model, and annotates the topological relationship diagram according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture. This method can connect the data of the SAAS layer, PAAS layer and IAAS layer, obtain a full-view operation and maintenance topology diagram, make the calling relationship more intuitive and clear, and can quickly discover faults, thereby improving the accuracy and comprehensiveness of node anomaly detection and assisting in fault point troubleshooting.

[0104] Embodiment 3

[0105] Figure 5 This is a schematic diagram of the structure of a device for generating an operation and maintenance topology diagram of a microservice architecture provided in Embodiment 3 of the present invention. Figure 5 As shown, the device includes: a data cleaning module 310, a topology relationship diagram construction module 320, an alarm information acquisition module 330 and an operation and maintenance topology diagram generation module 340.

[0106] The data cleaning module 310 is used to obtain microservice architecture data provided by multiple data sources respectively, and clean the microservice architecture data to obtain multiple core fields under each data source.

[0107] The topology relationship diagram construction module 320 is used to determine the nodes with associated relationships in the SAAS layer, the PAAS layer and the IAAS layer according to the core fields under the first data source, and to construct a topology relationship diagram according to the nodes.

[0108] The alarm information acquisition module 330 is used to obtain the alarm information of each node in the topological relationship diagram according to the core field under the second data source and the pre-trained detection model.

[0109] The operation and maintenance topology diagram generation module 340 is used to annotate the topology relationship diagram according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture.

[0110] The technical solution of the embodiment of the present invention cleans the microservice architecture data provided by multiple data sources respectively, obtains multiple core fields under each data source, determines the nodes with associated relationships in the SAAS layer, PAAS layer and IAAS layer according to the core fields under the first data source, and constructs a topological relationship diagram according to each node, obtains the alarm information of each node in the topological relationship diagram according to the core fields under the second data source and a pre-trained detection model, and annotates the topological relationship diagram according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture. This method can connect the data of the SAAS layer, PAAS layer and IAAS layer, obtain a full-view operation and maintenance topology diagram, make the calling relationship more intuitive and clear, and can quickly discover faults, thereby improving the accuracy and comprehensiveness of node anomaly detection and assisting in fault point troubleshooting.

[0111] Based on the above embodiments, the topology diagram construction module 320 may include:

[0112] An association relationship determination unit is used to determine, based on the core fields under the first data source, the association relationship between the services belonging to the target call chain in the SAAS layer, the container association relationship between the SAAS layer and the PAAS layer, the middleware call relationship between the SAAS layer and the IAAS layer, the host call relationship between the PAAS layer and the IAAS layer, and the attribution relationship between the container, Pod and host in the PAAS layer;

[0113] The topology relationship determination unit is used to determine the nodes in the target call chain and the association relationship between the nodes according to the internal relationship of each level and the relationship between each level, and construct a topology relationship diagram.

[0114] Based on the above embodiments, the first data source includes call chain data, a first open source platform, and a second open source platform;

[0115] The association relationship determination unit can be used for:

[0116] Determine the target call chain according to the call ID in the call chain data, and determine the services in the SAAS layer that belong to the target call chain and the association relationship between the services according to the node ID and the parent node ID in the target call chain;

[0117] Determine the container association relationship between the SAAS layer and the PAAS layer according to the application instance name in the call chain data and the container name in the first open source platform;

[0118] According to the calling address in the calling chain data and the resource attribute value in the second open source platform, the middleware calling relationship between the SAAS layer and the IAAS layer is determined.

[0119] Based on the above embodiments, the association relationship determination unit may also be used to:

[0120] Determine the host call relationship between the PAAS layer and the IAAS layer according to the host IP in the first open source platform and the resource attribute value in the second open source platform;

[0121] According to the Pod name, container name, Pod IP and host IP in the first open source platform, the ownership relationship between the container, Pod and host in the PAAS layer is determined.

[0122] Based on the above embodiments, the second data source includes call chain data;

[0123] The alarm information acquisition module 330 can be specifically used for:

[0124] According to the core fields in the call chain data, multiple monitoring indicators of each service belonging to the target call chain in the SAAS layer are determined; the monitoring indicators include the success amount, average time consumption and success rate within the monitoring time range;

[0125] Input each monitoring indicator into the detection model respectively, obtain the output result of the detection model, and determine the alarm information of each service in the SAAS layer according to the output result.

[0126] Based on the above embodiments, the output results include health status, indicator detection status, detection condition upper limit and detection condition lower limit;

[0127] The alarm information acquisition module 330 may be further specifically used for:

[0128] According to the indicator detection status, it is determined whether the target service needs to be alerted, and the health trend graph of the target service is updated according to the health level.

[0129] Based on the above embodiments, a snapshot storage module may be called to:

[0130] Whenever the specified time node is reached, a call relationship snapshot is generated and saved based on the current operation and maintenance topology diagram;

[0131] A snapshot comparison module may also be included to:

[0132] When it is determined that there is a fault in the target call link according to the current operation and maintenance topology map, the current operation and maintenance topology map is compared with the most recently stored historical call relationship snapshot, and at least one node related to the fault is determined according to the comparison result.

[0133] The operation and maintenance topology map generation device of the microservice architecture provided in the embodiment of the present invention can execute the operation and maintenance topology map generation method of the microservice architecture provided in any embodiment of the present invention, and has the functional modules and beneficial effects corresponding to the execution method.

[0134] Embodiment 4

[0135] Figure 6 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0136] like Figure 6 As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0137] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0138] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The processor 11 executes the various methods and processes described above, such as the method for generating an operation and maintenance topology map of a microservice architecture as described in an embodiment of the present invention. That is:

[0139] Obtain microservice architecture data provided by multiple data sources respectively, and clean the microservice architecture data to obtain multiple core fields under each data source;

[0140] According to the core fields under the first data source, determine the nodes with associated relationships in the SAAS layer, the PAAS layer, and the IAAS layer, and construct a topological relationship diagram according to the nodes;

[0141] Obtaining alarm information of each node in the topological relationship diagram according to the core fields under the second data source and the pre-trained detection model;

[0142] The topology diagram is annotated according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture.

[0143] In some embodiments, the method for generating an operation and maintenance topology map of a microservice architecture may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the method for generating an operation and maintenance topology map of the microservice architecture described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the method for generating an operation and maintenance topology map of a microservice architecture in any other appropriate manner (e.g., by means of firmware).

[0144] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0145] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0146] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, 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 foregoing.

[0147] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0148] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0149] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0150] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0151] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for generating an operation and maintenance topology diagram of a microservice architecture, characterized in that: include: Obtain microservice architecture data provided by multiple data sources respectively, and clean the microservice architecture data to obtain multiple core fields under each data source; According to the core fields under the first data source, determine the nodes with associated relationships in the software as a service SAAS layer, the platform as a service PAAS layer, and the infrastructure as a service IAAS layer, and construct a topological relationship diagram according to the nodes; According to the core fields under the second data source and the pre-trained detection model, obtain the alarm information of each node in the topological relationship diagram; The topology diagram is annotated according to the alarm information to generate an operation and maintenance topology diagram of the microservice architecture.

2. The method according to claim 1, characterized in that According to the core fields under the first data source, nodes with associated relationships in the SAAS layer, the PAAS layer, and the IAAS layer are determined, and a topological relationship diagram is constructed according to each node, including: According to the core fields under the first data source, determine the association relationship between the services belonging to the target call chain in the SAAS layer, the container association relationship between the SAAS layer and the PAAS layer, the middleware call relationship between the SAAS layer and the IAAS layer, the host call relationship between the PAAS layer and the IAAS layer, and the ownership relationship between the container, Pod and host in the PAAS layer; According to the internal relationship of each level and the relationship between each level, the nodes in the target call chain and the association relationship between each node are determined to construct a topological relationship diagram.

3. The method according to claim 2, characterized in that The first data source includes call chain data, a first open source platform, and a second open source platform; According to the core fields under the first data source, the association relationship between the services belonging to the target call chain in the SAAS layer, the container association relationship between the SAAS layer and the PAAS layer, and the middleware call relationship between the SAAS layer and the IAAS layer are determined, including: Determine the target call chain according to the call ID in the call chain data, and determine the services in the SAAS layer that belong to the target call chain and the association relationship between the services according to the node ID and the parent node ID in the target call chain; Determine the container association relationship between the SAAS layer and the PAAS layer according to the application instance name in the call chain data and the container name in the first open source platform; According to the calling address in the calling chain data and the resource attribute value in the second open source platform, the middleware calling relationship between the SAAS layer and the IAAS layer is determined.

4. The method according to claim 3, characterized in that According to the core fields under the first data source, the host call relationship between the PAAS layer and the IAAS layer and the ownership relationship between the container, Pod and host in the PAAS layer are determined, including: Determine the host call relationship between the PAAS layer and the IAAS layer according to the host IP in the first open source platform and the resource attribute value in the second open source platform; According to the Pod name, container name, Pod IP and host IP in the first open source platform, the ownership relationship between the container, Pod and host in the PAAS layer is determined.

5. The method according to claim 1, characterized in that The second data source includes call chain data; According to the core fields under the second data source and the pre-trained detection model, the alarm information of each node in the topological relationship diagram is obtained, including: According to the core fields in the call chain data, multiple monitoring indicators of each service belonging to the target call chain in the SAAS layer are determined; the monitoring indicators include the success amount, average time consumption and success rate within the monitoring time range; Input each monitoring indicator into the detection model respectively, obtain the output result of the detection model, and determine the alarm information of each service in the SAAS layer according to the output result.

6. The method according to claim 5, characterized in that The output results include health status, indicator detection status, detection condition upper limit and detection condition lower limit; Determine the alarm information of each service in the SAAS layer according to the output result, including: According to the indicator detection status, it is determined whether the target service needs to be alerted, and the health trend graph of the target service is updated according to the health level.

7. The method according to claim 1, characterized in that Also includes: Whenever the specified time node is reached, a call relationship snapshot is generated and saved based on the current operation and maintenance topology diagram; After generating the operation and maintenance topology diagram of the microservice architecture, it also includes: When it is determined that there is a fault in the target call link according to the current operation and maintenance topology map, the current operation and maintenance topology map is compared with the most recently stored historical call relationship snapshot, and at least one node related to the fault is determined according to the comparison result.

8. A device for generating an operation and maintenance topology diagram of a microservice architecture, characterized in that: include: A data cleaning module is used to obtain microservice architecture data provided by multiple data sources, clean the microservice architecture data, and obtain multiple core fields under each data source; A topology relationship diagram construction module is used to determine nodes with associated relationships in the software as a service SAAS layer, the platform as a service PAAS layer, and the infrastructure as a service IAAS layer according to the core fields under the first data source, and to construct a topology relationship diagram according to each node; An alarm information acquisition module, used to acquire the alarm information of each node in the topological relationship diagram according to the core field under the second data source and the pre-trained detection model; The operation and maintenance topology diagram generation module is used to annotate the topology relationship diagram according to the alarm information and generate an operation and maintenance topology diagram of the microservice architecture.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the method for generating an operation and maintenance topology map of a microservice architecture as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the method for generating an operation and maintenance topology map of a microservice architecture according to any one of claims 1 to 7 when executed.

Images