Application of topology change and infrastructure alert analysis

Abstract

This application relates to application topology change and infrastructure alert analysis. Generally, a technique is described for a computing system to generate a first graph representing a first application topology of a distributed application at a first time, the first application topology including a first plurality of nodes of computing infrastructure across multiple layers. The computing system generates a second graph representing a second application topology of the distributed application at a second time. The computing system determines that paths have changed based on a comparison of the first and second graphs. Based on the determination that paths have changed, the computing system outputs an alert indicating that a problem in the computing infrastructure is caused by the path change.

Description

[0001] Related Applications

[0002] This application claims the benefit of U.S. Patent Application No. 18 / 958,996, filed November 25, 2024, the entirety of which is incorporated by reference herein. TECHNICAL FIELD

[0003] The present disclosure relates to computing systems, and more specifically, to managing distributed applications running on a network. BACKGROUND

[0004] Computer networks have become ubiquitous, and the number of network applications, networked devices, and types of networked devices is rapidly expanding. Such devices now include computers, smartphones, Internet of Things (IoT) devices, automobiles, medical devices, factory devices, and the like. End-user networked devices typically cannot directly access a public network such as the Internet. Instead, end-user networked devices establish a network connection with an access network, and the access network communicates with a core network that connects to one or more packet data networks (PDNs) that provide services. There are currently several different types of access networks. Examples include radio access networks (RANs) that are access networks for Third Generation Partnership Project (3GPP) networks, trusted and untrusted non-3GPP networks such as Wi-Fi or WiMAX networks, and fixed / wired networks such as Digital Subscriber Line (DSL), Passive Optical Network (PON), and cable networks. The core network can be a core network of a mobile service provider network, such as a 3G, 4G / LTE, or 5G network.

[0005] In a traditional cloud data center environment, there is a large number of interconnected servers that provide computing and / or storage capacity to run different applications. For example, a data center can include a facility that hosts applications and services for subscribers (i.e., customers of the data center). The data center may, for example, host all of the infrastructure equipment, such as networking and storage systems, redundant power supplies, and environmental controls. In a typical data center, storage system clusters and application servers are interconnected via a high-speed switch fabric provided by one or more layers of physical network switches and routers. More complex data centers provide subscriber support equipment located in different physical hosting facilities that span the globe.

[0006] Virtualized data centers are becoming a core foundation of modern information technology (IT) infrastructure. In particular, modern data centers have widely utilized virtualized environments in which virtual hosts (also referred to herein as virtual execution elements or workloads, such as virtual machines or containers) are deployed and executed on an underlying computing platform of physical computing devices. Workloads can also include bare metal processes.

[0007] Virtualization within data centers can provide several advantages. One advantage is that virtualization can provide significant improvements in efficiency. With the advent of multi-core microprocessor architectures with a large number of cores per physical central processing unit (CPU), underlying physical computing devices (i.e., servers) are becoming more and more powerful, making virtualization easier and more efficient. A second advantage is that virtualization provides significant control over computing infrastructure. With physical computing resources becoming replaceable resources, such as in cloud-based computing environments, provisioning and management of computing infrastructure becomes easier. Thus, in addition to the efficiency and increased return on investment (ROI) that virtualization provides, enterprise information technology (IT) staff often prefer virtualized computing clusters in data centers for their management advantages.

[0008] Containerization is a virtualization scheme based on operating system-level virtualization. Containers are lightweight and portable workloads of applications that are isolated from each other and from the host. Because containers are not tightly coupled to the host hardware computing environment, applications can be bound to a container image and executed as a single lightweight package on any host or virtual host that supports the underlying container architecture. Thus, containers solve the problem of how to make software work in different computing environments. Containers guarantee consistent operation from one computing environment to another (virtual or physical).

[0009] With the inherent lightweight nature of containers, a single host can often support more container instances than traditional virtual machines (VMs). These systems are characterized as being dynamic and ephemeral, as hosted services can quickly scale up or adapt to new demands. Containers are typically short-lived, can be created and moved more efficiently than VMs, and they can also be managed as groups of logically related elements (sometimes referred to as “pods” for some orchestration platforms, e.g., Kubernetes). These container characteristics impact the requirements for container networking solutions: the network should be agile and scalable. VMs, containers, and bare metal servers can need to coexist in the same computing environment with communication enabled between different deployments of applications. Container networking should also work natively with multiple types of orchestration platforms used to deploy containerized applications.

[0010] Managing the deployment and infrastructure for application execution can involve two main roles: (1) orchestration - for automating the deployment, scaling, and operation of applications across a cluster of hosts and providing the computing infrastructure, which can include container-centric computing infrastructure; and (2) network management - for creating virtual networks in the network infrastructure to enable packet communication between applications running on virtual computing instances (such as containers or VMs) and between applications running on traditional (e.g., physical) environments. Software-defined networking facilitates network management. SUMMARY

[0011] Generally, techniques are described for managing a distributed application based on changes to a graph of an application topology of the distributed application. A computing infrastructure that supports the distributed application includes multiple tiers, each tier having different elements corresponding to the tier. Example tiers and elements can include an application services tier having application services or external clients, a virtual compute instance (“instance”) tier having, e.g., Pods and / or virtual machines, a compute tier having compute nodes / real servers, a network tier having switches, etc. Nodes representing elements of different tiers can be arranged into an application topology graph, with edges connecting pairs of elements to represent relationships between the elements. For example, a node representing a virtual compute instance can be connected via an edge with a node representing a compute node where the virtual compute instance executes on the compute node, or the edge can represent the switching of a packet flow between the two nodes. The nodes and edges of the application topology graph can be augmented with additional information representing the state of the elements, e.g., based on telemetry information generated by the elements. The augmented application topology graph is referred to as a “knowledge graph” of the application topology of the distributed application.

[0012] The application services of the distributed application communicate with each other and have dependencies on each other across tiers of the computing infrastructure via paths through various elements of the different tiers (hereinafter, the terms “element” and “node” can be used interchangeably). In some cases, changes to the application topology that result in new paths can cause problems for nodes. For example, removing a first node from the application topology can cause additional network paths to be routed to a second node, which can overwhelm the second node.

[0013] In examples of the disclosed technology, an analysis system processes telemetry data obtained from nodes of the distributed application, and in some cases other data such as configuration data and / or network data. The analysis system can process the data to identify paths through the nodes (e.g., paths between services of the distributed application). Nodes along the paths can exhibit performance degradation, such as increased latency, reduced transmission speed, reduced data throughput, packet loss, and other effects on the performance and functionality of the paths. In some instances, such effects can be caused by changes to the application topology that cause modifications to the paths. If the analysis system determines that a change to a path in the application topology graph is associated with an alert, the analysis system can generate a user interface that includes an indication that the alert is a result of the change to the path. In some examples, the analysis system can reconfigure the network or direct a scheduler, such as a Kubernetes scheduler, to modify the deployment of services of the distributed application based on the determination that the change to the path is associated with the alert.

[0014] The technology disclosed herein can provide one or more technical advantages that enable one or more practical applications. In an example, the analytics system enables an administrator to determine that an alert is the result of a path change in the topology of a distributed application. Furthermore, the analytics system enables the administrator to restore the topology of the distributed application to its previous configuration, thereby reversing the path change that caused the alert. By enabling the administrator to determine that the alert is the result of a path change, the analytics system can facilitate more efficient diagnosis and remediation of problems within the topology of the distributed application. In some examples, remediation is performed automatically by an orchestrator (e.g., a scheduler), a network controller, and / or an element management system, for example, based on the analytics system's determination that the alert is the result of a path change.

[0015] In another example, this disclosure describes a computing system including: a memory; and processing circuitry communicating with the memory and configured to generate a first graph representing a first application topology of a distributed application at a first time, wherein the first application topology includes a first plurality of nodes of computing infrastructure distributed across multiple layers; generate a second graph representing a second application topology of the distributed application at a second time, wherein the second application topology includes a second plurality of nodes of computing infrastructure distributed across multiple layers; determine, based on a comparison of the first graph and the second graph, that a path has changed; and, based on the determination that the path has changed, output an alert indicating that a problem in the computing infrastructure is caused by the change in the path.

[0016] In one example, this disclosure describes a method comprising: generating a first graph representing a first application topology of a distributed application at a first time, wherein the first application topology includes a first plurality of nodes of a computing infrastructure distributed across multiple layers; generating a second graph representing a second application topology of the distributed application at a second time, wherein the second application topology includes a second plurality of nodes of a computing infrastructure distributed across multiple layers; determining, based on a comparison of the first and second graphs, that a path has changed; and, based on the determination that the path has changed, outputting an alert indicating that a problem in the computing infrastructure is caused by the change in the path.

[0017] In another example, this disclosure describes a non-transient computer-readable storage medium with instructions that, when executed, cause one or more processors to generate a first graph representing a first application topology of a distributed application at a first time, wherein the first application topology includes a first plurality of nodes of computing infrastructure distributed across multiple layers; generate a second graph representing a second application topology of the distributed application at a second time, wherein the second application topology includes a second plurality of nodes of computing infrastructure distributed across multiple layers; determine, based on a comparison of the first and second graphs, that a path has changed; and, based on the determination that the path has changed, output an alert indicating that a problem in the computing infrastructure is caused by the change in the path.

[0018] Details of one or more embodiments of this disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the specification, the drawings, and the claims. Attached Figure Description

[0019] Figure 1 This is a block diagram illustrating an example computing infrastructure and analytics system based on the techniques described in this disclosure.

[0020] Figure 2 This is a block diagram illustrating an example analysis system based on the techniques described in this disclosure.

[0021] Figure 3 This is a block diagram illustrating an example of a distributed application based on one or more technologies according to this disclosure.

[0022] Figures 4A to 4F This is an example user interface based on one or more technologies disclosed herein.

[0023] Figure 5 This is a flowchart illustrating an example operation of a computing system according to one or more techniques of this disclosure.

[0024] Throughout the specification and drawings, the same reference characters denote the same elements. Detailed Implementation

[0025] Site Reliability Engineers (SREs) face challenges in tracking and understanding the evolution of application topologies over time. This problem stems from the complexity of modern applications, which typically have intricate and dynamic architectures. As applications evolve, keeping track of changes, identifying new alerts, resolving existing alerts, and understanding modifications in application topology and path changes become increasingly challenging tasks. SREs face ongoing challenges in tracking changes within complex application architectures and assessing their impact on system performance in a timely manner. The lack of real-time insight into the criticality of path changes further complicates the problem, leaving SREs with insufficient guidance in prioritizing response efforts.

[0026] Figure 1This is a block diagram illustrating an example computing infrastructure 100 and an analytics system 140 according to the technology described in this disclosure. Typically, data center 101 provides an operating environment for applications and services to customer site 104 (shown as "Customer 104"), which has one or more customer networks coupled to the data center via a service provider network 106. Data center 101 may, for example, host infrastructure installations such as network and storage systems, redundant power supplies, and environmental controls. Service provider network 106 is coupled to a public network 115, which may represent one or more networks managed by other providers and thus may form part of a large-scale public network infrastructure (e.g., the Internet). For example, public network 115 may represent a local area network (LAN), a wide area network (WAN), the Internet, a virtual LAN (VLAN), an enterprise LAN, a Layer 3 virtual private network (VPN), an Internet Protocol (IP) intranet operated by the service provider running service provider network 106, an enterprise IP network, or a combination of some of these.

[0027] While customer site 104 and public network 115 are primarily shown and described as edge networks of service provider network 106, in some examples, one or more of customer site 104 and public network 115 may be tenant networks within data center 10 or another data center. For example, data center 101 may host multiple tenants (customers), each associated with one or more virtual private networks (VPNs), each VPN potentially implementing a customer site 104.

[0028] Service provider network 106 provides packet-based connectivity to attached customer sites 104, data centers 101, and public networks 115. Service provider network 106 can represent a network owned and operated by a service provider to interconnect multiple networks. Service provider network 106 can implement Multiprotocol Label Switching (MPLS) forwarding and, in such instances, can be referred to as an MPLS network or MPLS backbone. In some instances, service provider network 106 represents multiple interconnected autonomous systems (such as the Internet) providing services from one or more service providers.

[0029] In some examples, data center 101 may represent one of many geographically distributed data centers in which the technologies and systems described herein can be implemented. For example... Figure 1As illustrated in the example, data center 101 may be a facility that provides network services, cloud services, storage services, and / or application services to customers. Data center 101 may represent an on-premises data center, private cloud, public cloud, hybrid cloud, or other type of deployment. The service provider's customers may be collective entities, such as businesses and governments or individuals. For example, the data center may host web services for several businesses and end users. Other exemplary services may include data storage, virtual private networks, traffic engineering, file services, data mining, scientific or supercomputing, etc. Although shown as a separate edge network of service provider network 106, elements of data center 101 (e.g., one or more physical network functions (PNFs) or virtualized network functions (VNFs)) may be included within the core of service provider network 106.

[0030] Switch architecture 121 may include top-of-rack (TOR) (or other "leaf") switches 16A-16N (hereinafter referred to as "TOR switches 16") that are interconnected to the distribution layer of chassis (or "spine" or "core") switches 18A-18N (hereinafter referred to as "chassis switches 18"). Although not shown, data center 101 may also include, for example, one or more non-edge switches, routers, hubs, gateways, security devices (such as firewalls, intrusion detection and / or intrusion prevention devices), servers, computer terminals, laptops, printers, databases, wireless mobile devices (such as cellular phones or personal digital assistants), wireless access points, bridges, cable modems, application accelerators, or other network devices. Data center 101 may also include one or more physical network functions (PNFs), such as physical firewalls, load balancers, routers, route reflectors, broadband network gateways (BNGs), evolved packet cores or other cellular network elements, and other PNFs.

[0031] The term "packet flow," "traffic flow," or simply "flow" refers to a group of packets originating from a specific source device or endpoint and destined for a specific destination device or endpoint. For example, a single packet flow can be identified by a 5-tuple: <source network address, destination network address, source port, destination port, protocol>. This 5-tuple typically identifies the packet flow corresponding to the received packets. An n-tuple refers to any n items extracted from the 5-tuple. For example, a 2-tuple used for a packet can refer to the combination <source network address, destination network address> or <source network address, source port>.

[0032] Any server in Data Center 101 can be configured with workloads using virtualization server resources to provide isolation between one or more processes (applications) running on the server. "Hypervisor-based," "hardware-level," or "platform" virtualization refers to the creation of virtual machines, each containing a guest operating system for executing one or more processes. Typically, virtual machines provide a virtualization / guest operating system for executing applications in an isolated virtual environment. Because virtual machines are virtualized from the host server's physical hardware, the executing application is isolated from both the host hardware and other virtual machines. Each virtual machine can be configured with one or more virtual network interfaces for communication on a corresponding virtual network.

[0033] Container-based or "OS-based" virtualization refers to the virtualization of an operating system running multiple isolated systems on a single machine (virtual or physical). These isolated systems represent containers, such as those provided by the open-source DOCKER container application or CoreOS Rkt ("Rocket"). Like virtual machines, each container is virtualized and can remain isolated from the host and other containers. However, unlike virtual machines, each container can omit its own operating system and only provide an application suite and application-specific libraries. Typically, containers are executed by the host as isolated user-space instances and can share the operating system and common libraries with other containers running on the host. Therefore, containers may require less processing power, storage, and network resources than virtual machines. A group of one or more containers can be configured to share one or more virtual network interfaces to communicate on the corresponding virtual network.

[0034] In some examples, containers are managed by their host kernel to allow for the determination of resource limits and priorities (CPU, memory, block I / O, network, etc.) without starting any virtual machines. In some cases, namespace isolation is used, which allows for a fully isolated view of the operating environment of an application (e.g., a given container), including the process tree, network, user identifier, and mounted filesystems. In some examples, containers can be deployed based on Linux Containers (LXC), an operating system-level virtualization approach for running multiple isolated Linux systems (containers) on a controlling host using a single Linux kernel. LXC is an operating system-level virtualization approach for running multiple isolated Linux systems (containers) on a single controlling host (LXC host). LXC does not use virtual machines (although LXC can be hosted by virtual machines). Instead, LXC uses its own virtual environment with its own CPU, memory, block I / O, network, and / or other resource spaces. LXC resource control mechanisms are provided by namespaces and cgroups in the Linux kernel on the LXC host. Other examples of containerization methods include OpenVZ, FreeBSD jail, AIX workload partitioning, and Solaris containers. Therefore, as used in this article, the term "container" can encompass not only LXC type containers, but also any one or more of virtualization engines, virtual private servers, silos, or add-ons.

[0035] exist Figure 1 In the example, data center 101 includes storage devices and / or compute servers interconnected by one or more layers of physical network switches and routers, wherein compute nodes 110A-110N (hereinafter, "compute node 110") are described as interconnected via TOR switch 16 and chassis switch 18. Compute node 110 may be a bare metal machine and / or virtual machine within data center 101 and may also be referred to herein as a "host" or "host device". Compute node 110 may represent a computing device configured to operate according to the techniques described herein, such as an x86 processor-based server.

[0036] Compute node 110 can be hosted on one or more virtual network endpoints of a physical network operating on the physical network provided by TOR switch 16 and chassis switch 18. Although described primarily in relation to a data center-based switching network, other physical networks (such as service provider network 106) can cover one or more virtual networks.

[0037] Each compute node 110 may host one or more virtual compute instances 126A-126N (collectively referred to as "virtual compute instances 126", or more simply as "instances 126" or "workloads"). The term "workload" includes virtual machines, containers, Kubernetes pods, and / or other virtualized compute instances that provide at least a partially independent execution environment for an application, and may be referred to as "instances" throughout the text. Figure 1 As shown, compute node 110A hosts instance 126 of service 122A. However, compute node 110 can execute as many instances or workloads as are actually limited by the hardware resources of a given compute node 110.

[0038] Computing infrastructure 100 can implement an automated platform for automating the deployment, scaling, and operation of workloads across compute nodes 110, providing virtualized infrastructure for executing application workloads and services. In some examples, the platform may be a container orchestration platform that provides container-centric infrastructure for automating the deployment, scaling, and operation of containers, thereby providing container-centric infrastructure. In the context of virtualized computing infrastructure, "orchestration" generally refers to the provisioning, scheduling, and management of workloads and / or applications and services executed on host servers available to the orchestration platform. Specifically, container orchestration allows for container orchestration and refers, for example, the deployment, management, scaling, and configuration of containers on host servers via a container orchestration platform. Example instances of orchestration platforms include Kubernetes, Docker clusters, Mesos / Marathon, OpenShift, OpenStack, VMware, and Amazon ECS.

[0039] The components of the automated platform of computing infrastructure 100 include at least computing nodes 110, orchestrators 130, telemetry collectors 142, analytics systems 140, and user interface devices 129. The terms "component" or "node" may be used throughout to refer to the various software and hardware components of computing infrastructure 100. Figure 1 In the example, node 160 includes services 122A-122N, workloads (e.g., instance 126), compute node 110, TOR switch 16, chassis switch 18, and / or other elements of compute infrastructure 100. (The term "node" is also used to refer to a node in an applied topology graph, where such a node corresponds to a node in compute infrastructure 100.)

[0040] Each of the nodes in node 160 belongs to one of the layers of a distributed application running on computing infrastructure 100. Layers may include, for example, a service layer (including services 122A-122N), an instance layer (including instances 126A-126N), a compute layer (including compute nodes 110A-110N), and a network layer (including switches 16, 18).

[0041] Orchestrator 130 implements a scheduler for computing infrastructure 100. Orchestrator 130 can be a distributed or centralized application running on one or more computing devices of the computing system. Orchestrator 130 can implement a master node for one or more clusters, each cluster having one or more mini-nodes implemented by one or more servers of computing infrastructure 100.

[0042] Typically, orchestrator 130 controls the deployment, scaling, and operation of workloads across server clusters and provides compute infrastructure, which may include container-centric compute infrastructure. Orchestrator 130 can implement a separate cluster master for one or more Kubernetes clusters. As an example, Kubernetes is a container management platform that provides portability across public and private clouds, where each cloud can provide virtualization infrastructure to the container management platform. Orchestrator 130 can represent any of the orchestration platforms listed above, such as Kubernetes.

[0043] Instance 126 is used to deploy each of services 122A-122N (collectively, "Service 122"). Service 122 may each represent or include one or more application services (e.g., microservices, application subcomponents, etc.) executed by an instance deployed by a container orchestration system. One or more of Services 122 may collectively implement a distributed application comprising a collection of one or more Services 122. For example, a distributed application may include Services 122A-122N. Each Service 122 may provide or implement one or more services, and where instance 126 represents a container (Pod) or other container deployment, one or more services are containerized services or "microservices". Compute node 110 may host services for multiple different distributed applications. In some examples, the services of a distributed application are distributed across compute nodes managed by any combination of service providers, enterprises, or other entities. Such compute nodes may reside in multiple different data centers, on-premises deployments, or private, public, or hybrid clouds.

[0044] Orchestrator 130 includes a scheduler that schedules services 122 to compute nodes 110. Typically, orchestrator 130 manages the placement of each service 122 to compute node 110 based on scheduling policies, the amount of resources requested for the service, and the available resources of compute node 110. Orchestrator 130 may consider compute node resources, such as CPU-related resources (e.g., cores, CPU / core utilization), memory-related resources (available main memory, e.g., 2GB), temporary storage, and user-defined extended resources, when allocating services 122 to compute node 110. In Kubernetes, the scheduler is called the kube scheduler.

[0045] Service 122 may have different performance requirements that need to be met in a highly dynamic application execution environment. In this environment, application performance is a dynamic product of the performance of different resources (e.g., worker node resources); network resources (e.g., bandwidth, latency, packet loss rate, jitter, firewall policies), network policies, and the communication graph of different services in a distributed application; and external services (such as authentication and external cloud services).

[0046] Services 122 can communicate with each other as part of providing functionality for a distributed application. Each service in 122 can provide functionality for one or more components of the distributed application. In the example, service 122A provides functionality for a portion of the distributed application, while service 122N provides additional functionality for different parts of the distributed application. Service 122A communicates with service 122N to provide functionality and enables service 122N to provide additional functionality.

[0047] Services 122 can communicate with each other using calls such as Remote Procedure Calls (RPCs). Services 122 can communicate with each other along an RPC chain to provide functionality for a distributed application. For example, service 122A can communicate with service 122N and send RPCs to service 122N as part of providing functionality for a distributed application.

[0048] The application topology of the distributed application includes node 160, which includes service 122 and components of computing infrastructure 100 that support service 122 and facilitate the execution of service 100. Node 160 can be any component and device of data center 101, such as service 122, instance 126, compute node 110, TOR switch 16, and chassis switch 18A. As part of providing the functionality of the distributed application, nodes in node 160 can communicate with other nodes in the same layer (e.g., service 122A calls service 122N) and with nodes in other layers (e.g., nodes in layers above and / or below the layer of a given node in the layered structure of the distributed application, compute node 110A communicating with TOR switch 16A, etc.). For example, as part of providing the functionality of the distributed application, service 122A can send traffic to service 122N. Such traffic traverses the various layers and nodes of the application topology, for example, from service 122A, through instance 126A, through compute node 110A, through network layer nodes, through compute node 110N, through instance 126N, and finally to service 122N. These interactions are deeply nested, asynchronous, and invoke many other downstream operations.

[0049] Node 160 may change network paths due to changes in the topology of the distributed application as a result of changes in user intent, hardware changes (e.g., removal of network devices from the topology), reconfiguration of one or more nodes, and / or other changes. For example, the network path between service 122A and service 122N may change due to the reconfiguration of TOR switch 16A. Network controller 124 and / or orchestrator 130 may reconfigure network paths when the configuration of the distributed application is modified. For example, in response to changes in user intent, orchestrator 130 may reschedule service 122A to a different compute node in compute node 110, thereby changing one or more network paths between service 122A and other nodes of the distributed application.

[0050] As used herein, this term refers to a path in the application topology graph between two nodes. These two nodes can be, for example, an application service node and a network node, thereby tracking dependencies from the application service node to the network node. When the application topology changes, the path between any two nodes in the application topology graph may change accordingly. Changes to the application topology can lead to performance issues at any layer of the application topology.

[0051] Computing infrastructure 100 includes an analytics system 140, which can be executed as an application on one or more devices of data center 101 or as a standalone computing system. Analytics system 140 analyzes the performance of node 160 and the distributed applications implemented by node 160. Analytics system 140 can read network information, such as network telemetry obtained by the telemetry collector of analytics system 140 and network flow information obtained from chassis switch 18 and TOR switch 16. For example, analytics system 140 can obtain network information from one or more nodes 160 and store that information in database 142. In some examples, analytics system 140 can read information indicative of the configuration of node 160, such as configuration data for switches 16, 18, compute node 110, or instance 126. This configuration information can be obtained by analytics system 140 from network controller 124, orchestrator 130, or from the nodes. Configuration information can indicate network adjacencies within switch architecture 121, routes configured on switches 16 and 18, execution instance 126, and indications of service 122 on compute node 110. Analysis system 140 processes network information and, in some cases, configuration information to determine the application topology of the distributed application implemented by node 160.

[0052] The analysis system 140 includes a database 142, which may be a database maintained by the analysis system 140 and stored in a storage medium. The analysis system 140 may store data about network flows representing RPC call flows between service pairs 122 in some cases. Furthermore, the analysis system 140 may store one or more mappings of service dependencies and network configurations in the database 142. The database 142 may store flow or other flow records provided by switches 16, 18, and the records indicate which flow was processed by each of the switches, for example, within a certain period of time. Each flow record may include a switch identifier, source IP information, destination IP information, number of packets, number of bytes, actions taken, or other flow description data. The database 142 may store other network information or configuration information of the nodes of the computing infrastructure 100.

[0053] In some examples, analysis system 140 may utilize application tracing tools to determine call paths within service 122. For instance, analysis system 140 may utilize application tracing toolkits (such as OpenTelemetry) and application tracing tools (such as Jaegar) to obtain tracing data of calls within service 122. Application tracing toolkits may use tools such as APIs integrated into service 122 and software development kits (SDKs) that toolize or build service 122 using the application tracing toolkit. Application tracers may obtain data from toolized services of service 122. Analysis system 140 may use application tracing tools (such as Jaegar) to analyze the tracing data generated by the tracing toolkit and determine call paths between services 122. Analysis system 140 may use the tracing data and call paths to determine paths within service 122. Analysis system 140 may store the tracing data and call paths in database 122.

[0054] The distributed application can consist of a large number of communication services 122 that communicate along paths between nodes 160, enabling the functionality of the distributed application. The analysis system 140 can use application tracing tools to determine network paths and store information about those paths in database 142.

[0055] Analysis system 140 can use information from database 122 and / or information obtained from node 160 to determine the node experiencing a problem. Analysis system 140 can use information including the Service Level Agreement (SLA) and Service Level Expectations associated with node 160, performance data about node 160 (e.g., available bandwidth, available compute, throughput, etc.), and / or other information. Analysis system 140 can correlate the performance information about node 160 with the SLA / SLE and / or other performance requirements to the current performance of node 160 to determine the node experiencing a problem. Based on determining that a given node is experiencing a problem, analysis system 140 can associate an alert with that node. The alert thus indicates a problem in the computing infrastructure. In some examples, analysis system 140 may receive indications of an alert from node 160 (e.g., the node performs self-diagnostics, the node determines that it has not met a performance threshold, etc.).

[0056] Analysis system 140 uses modules (such as mapping module 144) to generate application topology graphs included in application topology graphs 155, which represent the application topology of one or more distributed applications. Application topology graph 155 includes nodes 160 from various layers, where edges represent relationships between pairs of nodes. Edge relationships can be understood as dependencies. Edge relationships can be, for example, the exchange of packet flows between two nodes (e.g., from TOR switch 16A to chassis switch 18B, or from TOR switch 16A to compute node 110A, or vice versa), services performed by instances, instances hosted by compute nodes, and so on. Figure 3 The example application topology diagram is depicted in the diagram.

[0057] Mapping module 144 may be a software component of analytics system 140 that generates a graph based on snapshots of the topology of the distributed application and indicates the status of nodes 160 (e.g., health, alerts, new alerts, etc.). For example, mapping module 144 may generate a graph based on snapshots of the topology captured at periodic intervals (e.g., seconds, minutes, hours, etc.) to capture the state of the topology. In some examples, mapping module 144 may use third-party plugins to gain additional insights and enhance application guarantees to reduce mean time to repair (MTTR).

[0058] Analysis system 140 uses mapping module 144 and / or another component to generate snapshots for generating application topology graph 155. Mapping module 144 can use telemetry data and / or other data obtained from node 160 to generate snapshots reflecting the distributed application topology within a corresponding time window on a periodic basis. In the example, mapping module 144 obtains telemetry data and / or other data for a first time period and generates a first snapshot for that time period. Mapping module 144 then obtains telemetry data and / or other data for a second, immediately following time period and generates a second snapshot for that second time period. Mapping module 144 can store the snapshots in a key-value pair structure for efficient data access based on unique identifiers. An example is provided below:

[0059]

[0060]

[0061] Mapping module 144 enables users (such as administrators) to view snapshots of the distributed application topology via a user interface. Analysis system 140 generates a user interface such as UI 152, which includes a visual representation of the application topology map 155 and alerts via interface 154. Analysis system 140 provides information for displaying the user interface to user device 150, which can then display the user interface to a web browser, application screen, or other applications based on that information.

[0062] Analysis system 140 can generate UI 152 based on a snapshot of the distributed application's topology. UI 152 includes visual representations of nodes 160, paths between nodes 160, and alerts associated with nodes 160. In this example, analysis system 140 generates an application topology map 155 based on a snapshot of the distributed application's topology. Analysis system 140 generates UI 152 based on application topology map 155 to include visual indications of alerts associated with service 122A. Analysis system 140 can generate UI 152 for one or more types of topology layouts and implements powerful and user-friendly tools for understanding, analyzing, and troubleshooting application topologies. Analysis system 140 can provide UI 152 to user device 150 via application programming interface (API) of interface 154 for output to the user.

[0063] Computing infrastructure 100 includes user device 150, which may be a computing device associated with a user and / or administrator of computing infrastructure 100. User device 150 may include one or more types of computing devices, such as desktop computers, laptop computers, tablet computers, thin clients, smartphones, mixed reality glasses / goggles, and / or other types of computing devices. User device 150 may include one or more display components capable of outputting UI 152 to a user. In the example, user device 150 receives data about UI 152 from 140, including indications of alarms associated with service 122A. User device 150 outputs UI 152, including visual indications of alarms associated with service 122A, to an administrator via the display components.

[0064] Administrators (such as Site Reliability Engineers (SREs)) may find it challenging to determine why alerts associated with nodes in Node 160 have occurred because modern application architectures are highly complex, involving multiple layers such as application services, instances, compute, and network devices. SREs may struggle to identify and track changes in application topology over time. This lack of visibility into changes within the infrastructure makes it difficult to assess their impact on system performance. For example, Node 160 may experience alerts for a variety of reasons, including network congestion, hardware failure, and / or other causes. Administrators may not be able to easily or effectively determine whether an alert is the result of a change in the topology of a distributed application rather than another issue (e.g., hardware failure, node misconfiguration, etc.). Traditional change analysis tools often fail to provide real-time insight into the criticality of path changes. This inability to provide such insight hinders SREs' ability to effectively prioritize responses and proactively resolve potential network outages.

[0065] According to the technology disclosed herein, the analysis system 140 identifies path changes and determines that an alert is caused by a path change. The analysis system 140 can identify path changes by comparing different application topology graphs 155 representing snapshots of the application topology of a distributed application at different times. In an example, the analysis system 140 compares a first application topology graph representing the current application topology of the distributed application with a second application topology graph representing the previous application topology of the distributed application to determine that an alert in the first application topology graph does not exist in the second application topology graph. Based on this comparison, the analysis system 140 determines that the alert is a result of a path change because the alert exists in the current application topology but not in a different application topology in the immediately preceding application topology.

[0066] Analysis system 140 uses a difference module 148 of analysis engine 146 to compare application topology graphs. The difference module 148 can be a software component of analysis system 140, such as a plugin, process, executable file, and / or other types of software components for comparing application topology graphs. The difference module 148 can compare application topology graphs generated by mapping module 144 to identify differences between application topology graphs. For example, the difference module 148 can identify changes including changes in node removal / addition, changes in node configuration, changes in paths between nodes, and changes in alarm status of nodes.

[0067] The difference module 148 identifies path changes as changes in the paths between application topology graphs. The difference module 148 can identify path changes based on a comparison of the application topology graphs. For example, the difference module 148 can identify path changes including changes in the path between service 122A and another node in the topology (such as service 122N).

[0068] Analysis engine 146 determines that an alert is caused by a path change based on the path change identification by difference module 148. Analysis engine 146 can compare information about the alert with changes in the distributed application topology determined by difference module 148 to determine if the alert is caused by a path change. In the example, analysis engine 146 compares new alerts (e.g., alerts present in the current snapshot rather than the immediately preceding snapshot) with changes in the application topology graph to determine if one of the new alerts is associated with a path change. Analysis engine 146 can determine that an alert is caused by a path change based on alerts associated with nodes that have experienced one or more changes in the path to other nodes.

[0069] The analysis system 140 generates UI 152 as a visual indication that the alert associated with the node is caused by a path change. The analysis system 140 may generate UI 152 as a visual indication that the alert is caused by a path change via one or more types of visual cues such as color coding, animation, and / or text indications. In the example, the analysis system 140 generates UI 152 as a text indication that the alert associated with service 122A is caused by a path change.

[0070] The analysis system 140 can generate a UI 152 that includes a timeline of snapshots generated by the analysis system 140, where the timeline allows the user to select one or more snapshots for display. In the example, the analysis system 140 receives user input consistent with the selection of a first snapshot and a second snapshot. The analysis system 140 generates a UI 152 to display an application topology diagram of the first snapshot and a second snapshot, as well as visual indications of the changes between the first and second snapshots. The analysis system 140 can use a difference module 148 to determine the differences between the snapshots and facilitate the analysis of changes in the distributed application topology over time. The analysis system 140 can generate a UI 152 that includes a dedicated change analysis widget that presents a structured overview of changes within the application topology. The widget can provide detailed insights into changes and their implications in four sections: new alerts, resolved alerts, added nodes, removed nodes, and path changes.

[0071] The analysis system 140 can generate UI 152 to visually highlight changes between snapshots of the distributed application topology. The analysis system 140 can visually highlight different types of changes within the application topology to enhance user understanding. The analysis system 140 can generate UI 152 to visually highlight new alerts, resolved alerts, added nodes, and removed nodes, using different colors and labels to differentiate them, enabling SREs to quickly identify areas of concern. For example, the analysis system 140 can generate UI 152 with widgets that provide insights into changes in the paths between "application services" and "network devices" nodes, which are critical for network connectivity. The analysis system 140 can highlight added and removed paths within the displayed application topology map using one or more colors (such as blue and orange, respectively). Furthermore, the analysis system 140 can use edge labels and icons to highlight the exact edges that have been added / removed, thereby facilitating precise analysis of network changes.

[0072] Analysis system 140 can determine the criticality of changes to the path between nodes 160. Analysis system 140 can assess the criticality of path changes in real time by utilizing alerts and critical log data (e.g., logs obtained by analysis system 140 from nodes 160). By analyzing fluctuations in alert and critical log counts along the changed path, analysis system 140 provides contextual guidance to the user, indicating the potential impact of the changes on system performance.

[0073] Analysis system 140 enables administrators to address alerts caused by path changes by taking one or more actions. Analysis system 140 enables administrators to take actions including modifying the configuration of one or more of nodes 160, modifying paths between nodes 160, and / or otherwise restoring the application topology of the distributed application. In the example, analysis system 140 generates UI 152 as including visual elements corresponding to the selection of a snapshot of the distributed application's topology. Analysis system 140 receives an instruction from user device 150 regarding a previous snapshot of the topology selected by the administrator via UI 152 and restores the topology from the current topology to the selected topology. Based on the received instruction, analysis system 140 can instruct network controller 124 and / or orchestrator 130 to modify the distributed application's configuration to restore the application topology. Modifying the distributed application's configuration may involve reconfiguring one or more nodes, rescheduling services to different compute nodes, or other actions. In some cases, administrators may modify the configuration of node 160 to reconfigure the distributed application to manually resolve alerts. This can include administrator interaction with orchestrator 130, network controller 124, and / or node 160. Reconfiguring a distributed application can have the effect of reconfiguring the application topology.

[0074] Therefore, in some examples, the analysis system 140 causes one or more components of the computing infrastructure 100 to correct alarms caused by path changes. The analysis system 140 can automatically cause one or more components to correct alarms by restoring or otherwise modifying the topology of the distributed application. In an example, the analysis system 140 determines that an alarm associated with service 122A is caused by a path change. The analysis system 140 provides the network controller 124 with an instruction to restore the topology configuration. The network controller 124 and the orchestrator 130 restore the topology of the distributed application to its previous configuration to undo the path change.

[0075] The technology disclosed herein can provide one or more technical advantages. For example, the technology disclosed herein enables an analysis system to identify alerts caused by changes in paths between nodes, which differ from other causes. The technology disclosed herein also enables an analysis system to recover changes in the topology of a distributed application to address the underlying causes of alerts. By utilizing information indicating topology changes in a distributed application, this technology enables faster diagnosis and remediation of distributed application performance. In another example, by providing a user-friendly visual interface, color-coded visualization, and detailed node information, analysis system 140 streamlines the process of identifying changes, making it significantly easier for SREs to analyze and understand changes in the application topology. Analysis system 140 addresses ongoing challenges in the field of system reliability and contributes to the proactive management of application infrastructure.

[0076] Figure 2 This is a block diagram illustrating an example analysis system 202 according to the technology described in this disclosure. The analysis system 202 can be similar to... Figure 1 The analysis system 140 shown provides similar functionality. The analysis system 202 can be implemented as any suitable computing system, such as one or more server computers, workstations, mainframes, appliances, cloud computing systems, and / or other computing systems capable of performing the operations and / or functions described in one or more aspects of this disclosure. In some examples, the computing system 202 represents a cloud computing system, server cluster, and / or server group (or a portion thereof) providing services to other devices or systems. In other examples, the computing system 202 may represent or be implemented through one or more virtualized computing instances (e.g., virtual machines, containers) of a cloud computing system, server cluster, data center, and / or server group.

[0077] exist Figure 2 In the example, analysis system 202 may include one or more processors 204, communication unit 206, one or more output devices 208, one or more input devices 210, interconnect 212, and one or more storage devices of storage system 205. One or more of the devices, modules, storage areas, or other components of computing system 202 may be interconnected to enable inter-component communication (physically, communicatively, and / or operationally). In some examples, this connectivity may be provided through a communication channel that may represent one or more of a system bus, network connection, inter-process communication data structure, or any other method for communicating data.

[0078] One or more processors 204 may implement and / or execute functions and / or instructions associated with the analysis system 202 or with one or more modules shown and / or described herein. One or more processors 204 may be processing circuitry that performs operations according to one or more aspects of this disclosure, may be part of processing circuitry that performs operations according to one or more aspects of this disclosure, and / or may include processing circuitry that performs operations according to one or more aspects of this disclosure. Examples of processors 204 include microprocessors, application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configured to function as a processor, processing unit, or processing device. The analysis system 202 may use one or more processors 204 to perform operations according to one or more aspects of this disclosure based on software, hardware, firmware, or a combination of hardware, software, and firmware residing in and / or executing at the analysis system 202.

[0079] One or more communication units 206 of the analysis system 202 can communicate with devices outside the analysis system 202 by sending and / or receiving data, and in some respects can operate as both an input device and an output device. In some examples, the communication unit 206 can communicate with other devices via a network. In other examples, the communication unit 206 can send and / or receive radio signals on a radio network such as a cellular radio network. In other examples, the communication unit 206 of the analysis system 202 can send and / or receive satellite signals on a satellite network. Examples of communication units 206 include network interface cards (e.g., such as Ethernet cards), optical transceivers, radio frequency transceivers, GPS receivers, or any other type of device capable of sending and / or receiving information. Such communication can follow, implement, or comply with appropriate protocols, including Transmission Control Protocol / Internet Protocol (TCP / IP), Ethernet, or other technologies or protocols.

[0080] One or more of the input devices 210 may represent any input device of the analysis system 202, which will not be described separately here. The input devices 210 may generate, receive, and / or process input. For example, one or more input devices 210 may generate or receive input from a network, a user input device, or any other type of device used to detect input from a person or machine.

[0081] One or more output devices 208 may represent any output device of the analysis system 202, which will not be described separately here. Output devices 208 may generate, present, and / or process output. For example, one or more output devices 208 may generate, present, and / or process output of any form. Output devices 208 may include one or more USB interfaces, video and / or audio output interfaces, or any other type of device capable of generating tactile, audio, visual, video, electrical, or other outputs. Some devices may be used as both input and output devices. For example, a communication device may transmit data to and receive data from other systems or devices via a network.

[0082] Interconnect 212 may include any type of connection between components of analysis system 200. Interconnect 212 may include hardware and / or software buses, interconnects, and / or other types of connections between components of analysis system 202. For example, interconnect 212 may enable processor 204 to execute instructions stored by memory system 216.

[0083] One or more storage devices of storage system 216 within analysis system 202 may store information for processing during operation of analysis system 202. Storage system 216 may store program instructions and / or data associated with one or more modules described according to one or more aspects of this disclosure. One or more processors 204 and one or more storage devices may provide an operating environment or platform for such modules, which may be implemented as software, but in some examples may include any combination of hardware, firmware, and software. One or more processors 204 may execute instructions, and one or more storage devices of storage system 216 may store instructions and / or data of one or more modules. The combination of processor 204 and storage system 216 may retrieve, store, and / or execute instructions and / or data of one or more applications, modules, or software. Processor 204 and / or storage devices of storage system 216 may also be operatively coupled to one or more other software and / or hardware components, including but not limited to one or more components of analysis system 202 and / or one or more devices or systems shown as connected to analysis system 202.

[0084] Processor 204 executes collector 218, which can be from nodes of a distributed application (such as...). Figure 1The software component of the analysis system 202 (shown as node 160) obtains data. Collector 218 can obtain data reported by node 160, including node performance data, node dependencies, and other information. Collector 218 may include one or more application tracing tools (e.g., Jaegar), which it uses to determine paths between nodes 160. For example, collector 218 can use an application tracing tool to determine paths between two services of a distributed application. Collector 218 can store the data obtained from node 160 in database 242.

[0085] Storage system 216 includes database 242, which may be a database maintained by analysis system 202. Database 242 may be similar to database 142 shown and provide similar functionality. Database 242 may include information about the performance of node 160 and the paths between nodes 160 obtained by collector 218. Figure 2 In the example, database 242 includes logs 236, performance metrics 238, and path data 240. Logs 236 may include logs obtained from node 160, such as logs of errors experienced by node 160. Performance metrics 238 may include metrics about the performance of node 160. Path data 160 may include data about the paths between nodes 160 obtained through application tracing tools obtained by collector 218.

[0086] Processor 204 can execute mapping module 244, which can be a software component of analysis system 202 that generates a graph for a distributed application based on data obtained from node 160. Mapping module 244 can be similar to... Figure 1 The mapping module 144 shown provides similar functionality. Mapping module 244 can obtain data from database 242, such as path data 240 generated by collector 218, to generate a graph of the distributed application. Mapping module 244 can generate the graph of the distributed application based on a periodic basis (e.g., minutes, hours, days, etc.) and / or in response to determining the topology of the distributed application (e.g., based on changes indicated by path data 240).

[0087] Mapping module 244 can generate a graph that serves as a snapshot of the distributed application and reflects changes to the distributed application. Mapping module 244 can generate this snapshot graph to facilitate the identification of topology changes and when problems first arise. In the example, mapping module 244 generates a graph that serves as a 15-minute snapshot of the distributed application's topology. Mapping module 244 can store the generated graph in database 242 as an application topology graph 155.

[0088] The storage system includes an analysis engine 246, which can be a software module of the analysis system 202 that analyzes data obtained by the collector 218 and the database 242. The analysis engine 246 can be similar to... Figure 1 The analysis engine 146 shown provides similar functionality. The analysis engine 246 can analyze data stored in the database 242 for one or more purposes, including identifying anomalies within the distributed application, determining differences between graphs in the distributed application, and / or other purposes.

[0089] Analysis engine 246 includes a difference module 248, which can be a software component of analysis engine 246, such as a plugin, module, process, executable file, and / or other types of software components that identify differences between application topology graph 155. Difference module 248 can be similar to... Figure 1 The difference module 148 shown provides similar functionality. The difference module 248 can compare the application topology graph 155 to identify differences between the topologies of the distributed application, including the removal of at least one node, the addition of at least one node, changes in the paths between nodes, and / or other types of changes. In the example, the difference module 248 obtains a first graph representing the current topology of the distributed application from the application topology graph 155, and a second graph representing the topology of the distributed application from the immediately preceding time period. The difference module 248 compares the first and second graphs and identifies changes in the paths between two nodes in the topology.

[0090] In some examples, the difference module 248 dynamically assesses the criticality of path changes. Utilizing data from alerts and critical logs associated with the path, the difference module 248 provides the user with contextual guidance indicating whether the change is potentially disruptive or safe, streamlining the decision-making process. By analyzing fluctuations in alert and critical log counts along the changed path, the difference module 248 can proactively alert the user to potential network outages. In the example, the difference module 248 determines that the latest topology indicates an increase in alerts and critical logs. The analysis system 202 issues a warning message, prompting the SRE to take necessary corrective action.

[0091] In some examples, the difference module 248 may use one or more techniques to identify differences between topology graphs. The difference module 248 may use a pseudocode-based technique that defines the logic for identifying differences between two topology graphs, classifying changes into new alerts, resolved alerts, added nodes, and removed nodes. An example of pseudocode is provided below:

[0092] - Looping through the nodes of the left (previous) diagram

[0093] - Check if the node exists in the right (latest) graph.

[0094] -If it does not exist:

[0095] - Add the node ID to the removedNode list

[0096] -If the node has any alerts:

[0097] - Add the node ID to the resolvedAlarm list

[0098] -If the node exists:

[0099] -If the node has any alarms

[0100] - Check if the alarm exists in the right (latest) chart.

[0101] -If it does not exist:

[0102] - Add the node ID to the resolvedAlarm list

[0103] -If it does exist:

[0104] -neglect

[0105] - Looping through the nodes in the right (latest) graph

[0106] - Check if the node exists in the left (previous) graph.

[0107] -If it does not exist:

[0108] - Add the node ID to the addedNode list

[0109] -If the node has any alerts:

[0110] - Add the node ID to the newAlarms list

[0111] -If the node exists:

[0112] -If the node has any alarms

[0113] - Check if the alarm exists in the left (previous) graph.

[0114] -If it does not exist:

[0115] - Add the node ID to the newAlarms list

[0116] -If it does exist:

[0117] -neglect

[0118] In some examples, the difference module 248 can identify path changes between two or more application topologies. The difference module 248 can use pseudocode-based techniques (such as the following) to identify differences:

[0119] - Define a function getAllPathsFromAppToNetwork that takes nodes, edges, and the application node as input.

[0120] - Initialize an empty array to store all paths from the application node to the network node;

[0121] - Define a depth-first search function (dfs) that takes nodes and paths as input.

[0122] - Add the current node to the visitedNodes collection.

[0123] - If the current node is a network node, add the current path to the path array.

[0124] Otherwise, iterate over the edges.

[0125] - Does the edge start from the current node?

[0126] - If so, find the next node connected by the edge.

[0127] - Recursively call dfs with the next node and the updated path.

[0128] - Call DFS with application nodes and an empty path array

[0129] - Returns a path array

[0130] - Obtain the paths of all applied nodes that are part of the left topology (e.g., previous snapshots):

[0131] - Define an empty object leftGraphPath to store the path for each application node in the left graph;

[0132] - Perform the following for each node in leftGraphNode:

[0133] - If the node represents an application (GraphLayer is an 'application service'):

[0134] - Call getAllPathsFromAppToNetwork with leftGraphNodes, leftGraphEdges, and the current node.

[0135] - Store the resulting path in a LeftGraphPath indexed by the node's ID;

[0136] - Obtain the paths to all applied nodes that are part of the right topology or graph (e.g., the current snapshot or a snapshot that is more recent in time than the left snapshot):

[0137] - Define an empty object rightGraphPath to store the path for each application node in the right graph;

[0138] -For each node in rightGraphNode:

[0139] - If the node represents an application (GraphLayer is 'application service'),

[0140] - Call getAllPathsFromAppToNetwork with rightGraphNodes, rightGraphEdges, and the current node.

[0141] - Store the resulting path in the rightGraphPath indexed by the node's ID.

[0142] - Define an empty object pathDiff to store the difference between leftGraphPath and rightGraphPath.

[0143] - For each application node ID in leftGraphPaths / rightGraphPaths

[0144] - Retrieve the path of the current application node from both the left GraphPath and the right GraphPath;

[0145] - Define an empty array `diff` to store the differences between paths.

[0146] - For each path in the path of the currently applied node in leftGraphPath

[0147] - If the path is not found in the path of the currently applied node in rightGraphPath

[0148] - Add the 'Remove' type to the diff path

[0149] - For each path in the path of the currently applied node in rightGraphPath

[0150] - If the path is not found in the path of the currently applied node in leftGraphPath:

[0151] - Add 'Add' type to the diff path

[0152] -If diff is not empty:

[0153] - Store the differences in pathDiff indexed by the application node ID.

[0154] - Output pathDiff

[0155] In another example, analysis system 202 can call one or more APIs from a set of APIs defined as initiating graph change analysis and querying the results of graph change analysis. Examples of the APIs are provided below:

[0156]

[0157] Analysis engine 246 includes an anomaly detection engine 234, which can be a software component of analysis engine 246, such as a plugin, module, process, executable file, and / or other types of software components. Anomaly detection engine 234 can process data obtained by collector 218 to identify one or more anomalies or problems within the distributed application, including: traffic congestion, node-generated alerts, lost packets, failure to meet SLA / SLE, and / or other issues. For example, anomaly detection engine 234 can process data from database 242 and determine that a specific node is congested by network traffic and cannot meet its assigned SLA.

[0158] Analysis engine 246 can determine, based on graph comparison, that one or more alerts detected by anomaly detection engine 234 are caused by path changes. Analysis engine 246 can determine that an alert is caused by a path change by associating the alert with the path change. In the example, analysis engine 246 associates a path change that causes additional traffic to a given node with an alert generated by that node.

[0159] Storage system 216 includes UI module 250, which may be a software component of analysis system 202 that generates user interfaces. UI 254 can generate a user interface including one or more visual elements based on application topology graph 155 generated by mapping module 244. For example, UI module 250 can generate a user interface that visually represents the application topology graph 155, which includes the topology of a distributed application. UI module 250 can generate a user interface that includes visual elements representing paths between nodes. For example, UI module 250 can generate a user interface that includes visual elements representing node 160 and visual elements representing network paths between nodes 160.

[0160] UI module 250 can generate a user interface that includes visual indications representing alerts associated with node 160. UI module 250 can use SVG and Canvas technologies, as well as graphics layout libraries, to generate the user interface for configurable and dynamic layout. UI module 250 can generate a user interface with the following visual indications: alerts visually associated with the corresponding node (e.g., visually connected or included in a visual element representing node 160), whether the alert is new (e.g., first identified in a recent snapshot of the distributed application), and whether the alert is the result of a path change. In the example, UI module 250 generates the user interface based on a recently generated graph of the distributed application's topology, where the user interface includes a visual representation of node 160 and a visual representation of an alert associated with one of the nodes.

[0161] In some examples, UI module 250 generates a user interface that highlights path changes between the "Application Service" node and the "Network Device" node. By visually representing added and removed paths in blue and orange respectively, UI module 250 enables SREs to gain immediate insight into changes in network connectivity. Furthermore, UI module 250 can display path changes to allow SREs to make informed decisions regarding network configuration and troubleshooting. UI module 250 enables SREs to assess the impact on system performance and take necessary actions to maintain optimal network function based on the changed paths identified by analysis system 202. Additionally, UI module 250 can provide a single portal for application awareness assurance, which facilitates communication with management systems such as... Figure 1 The data center 101 shown provides visibility into the enterprise-related infrastructure and third-party infrastructure. For example, the UI module 250 can facilitate the timely identification of network problems (e.g., average identification time or MTTI) through anomaly detection and root cause analysis.

[0162] Storage system 216 includes interface 254, which can be an interface facilitating access to the functionality of analysis system 202. Interface 254 can be similar to interface 154 and provide similar functionality. For example, interface 254 can expose APIs that enable another device to call functions of analysis system 202. Interface 254 can expose APIs that enable another device to call graphics difference functions, such as those provided by difference module 248. Example operations of the APIs are provided below:

[0163]

[0164] In some examples, interface 254 can define an API to retrieve path changes between the application and network nodes. Example operations are provided below:

[0165]

[0166]

[0167] In some examples, the analytics engine 246 can generate instructions for remedying the topology of a distributed application. The analytics engine 246 can generate instructions to enable one or more devices (such as...) Figure 1 The network controller 124 and / or orchestrator 130 shown modify the topology of the distributed application in one or more ways, including restoring the topology to a previous configuration (e.g., the configuration of the topology represented by application topology diagram 155), adding one or more nodes, removing one or more nodes, reconfiguring one or more nodes, modifying one or more communication paths, and / or other methods. The analysis engine 246 enables the analysis system to provide instructions to one or more receivers.

[0168] Analysis System 202 provides a comprehensive solution for analyzing application topology changes over time. By integrating visual representation, dynamic criticality assessment, and proactive alerting mechanisms, Analysis System 202 enables SREs to gain a deeper understanding of network changes and their implications, ultimately improving system reliability and performance. For example, Analysis System 202 can perform topology change analysis and revolutionize how SREs and administrators manage application topology changes, providing proactive insights and decision support to enhance system reliability and performance optimization.

[0169] Analysis System 202 enables a range of features to improve how administrators and Site Reliability Engineers (SREs) gain insights into application architecture. Packaged with intuitive features, Analysis System 202 not only provides a holistic view of the application but also offers interactive tools for efficient fault finding and in-depth analysis. Analysis System 202 may include several key components for enabling fault finding and analysis, including:

[0170] 1. Supports multiple layouts and user selection persistence:

[0171] - Topology supports hierarchical and graphical layouts to meet user preferences.

[0172] The system remembers the last user selection, ensuring a consistent experience across sessions.

[0173] 2. Hierarchical layout with rotation option:

[0174] - The hierarchical layout includes a rotation option with four views (top, bottom, left-right, and right-left), enhancing the flexibility of visualizing application structures.

[0175] 3. Unique node representation:

[0176] - The analysis system 202 can describe each layer node with unique images and colors, enhancing visual clarity and making it easy to distinguish between different components.

[0177] 4. Dynamic layer configuration:

[0178] - The topology is designed to support any number of layers, allowing for scalability with minimal configuration changes.

[0179] 5. Detailed node and edge information:

[0180] SREs can click on individual nodes to obtain detailed information, such as IP address, metrics, anomalies, and interfaces.

[0181] Clicking on an edge provides information about the connections, metrics, and interfaces between nodes.

[0182] 6. Alarm visualization and root cause analysis (RCA):

[0183] - The analysis system 202 can highlight nodes with identifiable alarms using unique images and identifiers.

[0184] -SREs can click on alerted nodes to view more information, including the metrics that triggered the alert, and initiate root cause analysis using the "Run RCA" button.

[0185] 7. Tool Log Indicator:

[0186] - The analysis system 202 can visually indicate nodes with critical logs, and the SRE can click on these nodes to access detailed critical logs identified by the system.

[0187] 8. Layer grouping / ungrouping:

[0188] - Grouping and ungrouping of topology support layers provide organizational flexibility.

[0189] 9. Alarm highlighted:

[0190] - The analysis system 202 can selectively highlight alarms, allowing the SRE to focus on the identified problems.

[0191] 10. Zooming and navigation features:

[0192] - The topology supports zooming in, zooming out, and resetting to the default state for better visualization.

[0193] Clicking on any node link (from an external widget) brings the SRE's focus to a specific node within the topology and facilitates navigation in large and complex architectures.

[0194] Figure 3This is a block diagram illustrating an example application topology diagram 300 (“Figure 300”) of a distributed application according to one or more technologies of this disclosure. Figure 3 exist Figure 1 Described for illustrative purposes in the context of [the above].

[0195] Analysis system 140 can generate graph 300 using data and / or other data obtained from node 160. Analysis system 140 can use one or more components (such as mapping module 144) to generate graph 300. In this example, analysis system 140 obtains data from node 160 including the state of node 160, paths between nodes 160, and other information. Mapping module 144 uses the information obtained by analysis system 140 from node 160 to generate graph 300.

[0196] Mapping module 144 can generate Figure 300 as one or more layers including nodes of a distributed application. Figure 3 In the example, mapping module 144 generates graph 300 as including application service layer 312, instance layer 314, computation layer 316, leaf layer 318, and spine layer 320. Mapping module 144 can generate graph 300 as including one or more layers, where each layer represents a specific layer of nodes within the hierarchy of the distributed application. For example, application service layer 312 may include multiple nodes within the application service layer of the distributed application.

[0197] Application service layer 312 includes service nodes 302A-302D (collectively referred to as "service node 302"). Service node 302 can be a service of the distributed application that implements the functionality of the distributed application, such as service 122. Service nodes 302 can communicate with each other, for example, using remote procedure calls, as part of enabling the functionality of the distributed application. Figure 3 In the example, service node 302A communicates with service nodes 302B-302D, service node 302C communicates with service node 302A, and service node 302D communicates with service node 302C. Furthermore, service node 302 can communicate with nodes (such as instances) contained in instance layer 314. Figure 3 In the example, service node 302A communicates with instance node 304B, service node 302B communicates with instance node 304A, service nodes 302C-302D communicate with instance node 304C, and service node 304D communicates with instance node 304D. Service nodes 302 can communicate with each other and with nodes in instance layer 314 along network paths through the topology of the distributed application. In some cases, client nodes may be included in application service layer 312. Client nodes represent external clients. Figure 1 Service 122 can be represented by service node 302 of application service layer 312.

[0198] Instance layer 314 includes instance nodes 304A-304D (collectively referred to as "instance nodes 304"), which may represent virtual compute instances, such as Kubenets containers (Kubenetes Pods), virtual machines, one or more containers, or other virtual compute instances. Instance nodes 304 may communicate within themselves and with nodes in layers above and below instance layer 314 (e.g., application service layer 312 and / or compute layer 316) as part of the network path among the nodes in Figure 300. Figure 1 In the example, instance node 304 communicates with service node 304 and compute node 306 of compute layer 316. Figure 1 Instance 126 can be represented by instance node 304 of instance layer 314.

[0199] Computation layer 316 includes computing nodes 306 that can represent one or more types of computing nodes. For example, computing node 306 can be a hardware node, a virtualization execution environment, or other type of computing node that executes instructions for application node 302 and instance node 304. As part of providing an execution environment for application node 302 and instance node 304, computing node 316 can communicate with other computing nodes 314 via leaf layer 318 and spine layer 320, which are part of the network path of the distributed application. Figure 1 The computation node 110 can be represented by the computation node 306 of the computation layer 316.

[0200] Leaf layer 318 includes leaf nodes 308A-308B (collectively referred to as "leaf nodes 308") that can represent one or more types of network devices. For example, leaf node 308 can represent a leaf switch within the topology of the distributed application represented by Figure 300. Leaf node 308 can communicate with other nodes in different layers of the distributed application's topology. Furthermore, leaf node 308 can facilitate the routing of network traffic within the network supporting the distributed application. For example, leaf node 308 can route network traffic from instance node 304 to different receivers within the network. Figure 3 In the example, leaf node 308A is connected to ridge node 310, and leaf node 308B is connected to ridge node 310.

[0201] The spine layer 320 includes spine nodes 310, which can represent one or more types of network devices. For example, spine node 310 can represent a chassis switch that routes network traffic within the network as part of the network path between nodes. Spine node 310 can correspond to... Figure 1 One of the chassis-type switches 18.

[0202] Analysis system 140 can use graphs (such as Figure 300) to determine how the application-to-network topology changes over time. Analysis system 140 can generate a knowledge graph for a given monitoring window that captures the relationships between the application and its underlying infrastructure components during that time window. The knowledge graph is also in the form of an application topology graph, but it is enhanced with additional knowledge.

[0203] The analysis system 140 can utilize a graph generator component within its analysis engine, designed to provide a single glass pane of view of the application and underlying infrastructure (including orchestration layer, hardware, and network) in the form of a single unified knowledge graph. The analysis system 140 can implement a metric / telemetry collection pipeline that collects metrics from various sources into a central metric engine and collects relevant logs into the search function. The analysis system 140 can leverage this telemetry data, along with network topology data, to construct a complete system topology. The analysis system 140 can use additional metric data from the metric engine and logs from the log service to enhance the topology with additional telemetry data. The analysis system 140 can identify relevant telemetry data for each node and edge in the topology graph during the analysis period based on node / edge type and augment the knowledge graph. The analysis system 140 can process each metric data point for each node / edge in the knowledge graph through a real-time machine learning-based anomaly detection service to detect anomalies. The analysis system 140 can highlight nodes / edges with detected anomalies in the knowledge graph.

[0204] The analysis system 140 can generate a knowledge graph that serves as a snapshot of the underlying implementation and application status within a given analysis period, including the complete topology and related telemetry. The analysis system can utilize the knowledge graph generated by the graph generator as one or more graph analysis algorithms, and use cases as sources of topology and telemetry data.

[0205] Analysis system 140 can generate a knowledge graph that includes the following layers:

[0206] ●Application service layer:

[0207] The application service layer can be based on one or more metrics and represent application services in one or more input namespaces deployed in the application cluster, as well as the request flow between application services.

[0208] ○ Key telemetry data used for this layer may include:

[0209] ■ Request Latency: Measure average latency, 50th percentile latency, 90th percentile latency, and 95th percentile latency across application deployments. Track anomalies in latency.

[0210] ■ Throughput (requests per second): Tracks the average request rate over a minute interval.

[0211] ■ Request Count: Monitor the total request count (average per minute) and track anomalies, especially for 2xx, 4xx, and 5xx responses.

[0212] Anomalies: Detect anomalies in latency, throughput, request count, and APM metrics (response time, error rate).

[0213] ●Instance layer:

[0214] ○ Based on one or more metrics, it represents one or more application instances for each application service.

[0215] This layer can capture telemetry of resource utilization and performance metrics focused on a single application instance (including CPU, memory, disk, and network usage), as well as detect anomalies in these metrics.

[0216] ○Key telemetry may include:

[0217] ■CPU Utilization: Monitor overall CPU utilization and 95th percentile CPU utilization and detect anomalies.

[0218] ■Memory Usage: Tracks memory usage in percentages and MB, including the 95th percentile usage over 1, 6, and 24 hours.

[0219] ■Disk and Network: Monitor pod disk usage and network data (received / sent).

[0220] ■ Traffic and Request Metrics: Track incoming traffic, request rate, and latency, highlighting anomalies.

[0221] Anomalies: For a single application instance, detect abnormal patterns in CPU, memory, file system, and request latency.

[0222] ●Computation layer:

[0223] Based on computing host metrics, the computing layer can represent computing hosts in a data center.

[0224] ○Key telemetry may include:

[0225] ■CPU utilization: The 95th percentile of CPU utilization in the current period and the last 1, 6 and 24 hours.

[0226] ■Memory usage: Current and 95th percentile memory usage for the last 1, 6 and 24 hours.

[0227] ■Disk usage: Current and the 95th percentile of disk usage in the last 1, 6 and 24 hours.

[0228] ■ Network performance: Packet loss count and probes with packet loss.

[0229] ■ Anomalies: Detects anomalies in CPU, memory, disk, and network metrics. ● Network device layer:

[0230] Based on topology, this layer may include leaves and / or ridges included in the data center structure.

[0231] ○Key telemetry may include:

[0232] ■ Interface counter: Measures the rate at which data and error packets are sent and received on a network interface.

[0233] ■ Percentage metrics: Provides statistics for Tx / Rx rates and error packets at a specified time frame.

[0234] ■Events: Capture specific network-related events from the topology engine to enhance monitoring.

[0235] ■ Anomaly: Deviations in performance metrics for Tx / Rx rates and error packets.

[0236] The analysis system 140 may include indicator parsers responsible for interpreting input indicator time-series data points as nodes / edges on a knowledge graph. Each indicator parser may encapsulate logic to process indicators of a given category from a specific indicator source. The analysis system 140 may include configuration-driven indicator parsers, and new indicator parsers may be implemented to add support for new indicator sources or new indicator categories.

[0237] Analysis system 140 can generate a knowledge graph that captures alerts related to performance metrics for each node in the knowledge graph. When two such graphs are created for adjacent time windows, analysis system 140 can perform graph change analysis to answer one or more of the following example questions:

[0238] 1. How does the application layer evolve between two adjacent time windows?

[0239] 2. How does the underlying computing layer evolve between two adjacent time windows?

[0240] 3. How does network health evolve between adjacent time windows?

[0241] 4. How many new nodes / edges are added / deleted between two monitoring time windows?

[0242] 5. Across all layers in the diagram, how do alarms evolve / change between two monitoring time windows?

[0243] Analysis system 140 can compare two knowledge graphs, such as showing how the graphs change between two time windows. For example, analysis system 140 can compare a first knowledge graph and a second knowledge graph of the application topology at a first time to determine if an alert indicating a problem in the computing infrastructure is caused by a change in the path is being triggered. Analysis system 140 can generate knowledge graphs, such as showing an analysis of each layer regarding changes between two graphs generated on two different monitoring windows. For example, analysis system 140 can determine that the following changes have occurred between the two graphs:

[0244] Layer 1 (Application):

[0245] ●Added nodes: 13

[0246] ● Deleted nodes: None

[0247] ●Added edges: 13-6

[0248] ● Deleted edge: None

[0249] ●Added alerts: 13

[0250] ●Resolved alerts: None

[0251] Layer 2 (Virtual Computing Instance Layer):

[0252] ●Added nodes: 14

[0253] ●Added edges: 13-14

[0254] ● Deleted edge: None

[0255] ●Added Alerts: None

[0256] ●Resolved alerts: None

[0257] Layer 3 (Computation Layer):

[0258] ●Added nodes: None

[0259] ● Deleted nodes: None

[0260] ●Added edges: None

[0261] ● Deleted edge: None

[0262] ●Added Alerts: None

[0263] ●Resolved alerts: 3

[0264] Layer 4 (Network Probe Layer):

[0265] ●Added nodes: None

[0266] ● Deleted nodes: 9

[0267] ●Added edges: None

[0268] ● Edges to be deleted: 8-9

[0269] ●Added alerts: 11

[0270] ●Resolved alerts: None

[0271] Layer 5 (Network Device Layer):

[0272] ●Added nodes: None

[0273] ● Deleted nodes: 10

[0274] ●Added edges: None

[0275] ● Edges to be deleted: 9-10, 9-5

[0276] ●Added alerts: 12

[0277] ●Resolved alerts: None

[0278] Figures 4A to 4F This is an example user interface based on one or more technologies according to this disclosure. For clarity, Figures 4A to 4F exist Figure 1 The background is described. For example, the analysis system 140 can generate... Figures 4A to 4F The user interface is displayed as an instance of UI152 via one or more display components and / or user device 150.

[0279] exist Figure 4A In the example, the analysis system 140 generates UI 400A as including a first snapshot 402A and a second snapshot 404A, which can be representations of snapshots of the distributed application topology. The analysis system 140 can obtain data about the topology from multiple nodes 160 and generate snapshots representing the configuration of the topology within a given time window. The analysis system 140 can generate UI 400A in two parts, each part dedicated to presenting a separate topology graph (e.g., the first snapshot 402A and the second snapshot 404A). The analysis system 140 can use an HTML canvas to simultaneously present two topology graphs—a left (previous) graph and a right (latest) graph. For example, the analysis system 140 can generate the first snapshot 402A as a representation of the topology within a first time window and the second snapshot 404A as a representation of the topology within a second subsequent time period.

[0280] The analysis system 140 can generate UI 400A including node icons 406A, which can be representations of nodes 160. The analysis system 140 can generate the node icons 406A as visual elements of UI 400A, including visual indications of the node type represented by each of the node icons 406A (e.g., service, instance, compute, spine, leaf, etc.). For example, the analysis system 140 can generate a first snapshot 402A including multiple node icons 406A based on a first topology of the distributed application, and a second snapshot 404A including multiple node icons 406A based on a second topology of the distributed application.

[0281] The analysis system 140 can generate UI 400A as a path 408A, which includes a representation of the paths between nodes represented by node icons 406A. Path 408A can represent physical and / or software communication paths between nodes in a distributed application. For example, one path in path 408A can represent a path between a spine node and a leaf node of node icon 406A.

[0282] The analysis system 140 can generate a visual indication of UI 400A, including alerts associated with node icons 406A. Figure 4A In the example, the analysis system 140 generates a visual indication of the first snapshot 402A, including alerts on the instance node and alerts on the compute node. The analysis system 140 can generate the visual indication based on alerts about one or more issues with the node icon 406A, such as failure to meet SLA / SLE, hardware problems, misconfiguration, exceeding threshold traffic values, exceeding resource utilization thresholds, and / or other issues.

[0283] The analysis system 140 can generate visual indications for alarms that include new alarms. The analysis system 140 can determine whether one or more alarms present in the current or relatively recent snapshot of the distributed application topology also exist in previous or relatively older snapshots. Figure 4A In the example, the analysis system 140 determines that these alarms are new alarms based on the absence of three alarms in the first snapshot 402A that are not associated with two spine nodes and one leaf node in the second snapshot 404A. The analysis system 140 generates a UI 400A with the second snapshot 404A, which includes visual indications of the new alarms visually associated with the nodes experiencing the new alarms (e.g., such as...). Figure 4A (The "new alert" shown, along with different colors / shades, etc.)

[0284] exist Figure 4B In the example, analysis system 140 generates UI 400B, which can be similar to... Figure 4AUI400A is shown. For example, the analysis system 140 can generate UI 400B as a subsequent (e.g., temporal) instance of UI 400A.

[0285] The analysis system 140 generates UI 400B as a snapshot including a first snapshot 402B and a second snapshot 404B, which represent snapshots of the distributed application topology. The first snapshot 402B and the second snapshot 404B may include node icons 406B and paths 408B, where node icon 406B serves as a visual representation of node 160 and the alerts associated with node 160, and path 408B serves as a visual representation of paths between nodes 160. Furthermore, the analysis system 140 may generate the second snapshot 404B as a visual indication including new alerts (e.g., alerts not present in the first snapshot 402B).

[0286] exist Figure 4B In the example, the analysis system 140 generates UI 400B as including a path change icon 410B, which can be a visual element of UI 400B corresponding to a request to display a list of new alerts. A user interacting with UI 400B can hover the cursor over the path change icon 410B or otherwise interact with it. In response to user interaction, the analysis system 140 can generate an instance of UI 400B as including a visual window indicating the number of new alerts. Figure 4B In the example, the analysis system 400B generates a UI 400B that includes a visual window indicating the number of path changes (“3 path changes”) from the distributed application topology shown in the first snapshot 402B. In addition to indicating new alerts, the path change icon 410B can indicate one or more resolved alerts.

[0287] exist Figure 4C In the example, the analysis system 140 generates UI 400C, which may resemble an instance of UI 400B or UI 400A and / or UI 400B or UI 400A. For example, the analysis system 140 may generate UI 400C as a subsequent instance of UI 400B that includes similar visual elements (e.g., first snapshot 402C, second snapshot 404C, node icon 406C, path 408C, and path change icon 410C).

[0288] The analysis system 140 can generate UI 400C based on the user's interaction with the path change icon 410C. In the example, the analysis system 140 receives user input consistent with the interaction with the path change icon 410C. The analysis system 140 generates UI 400C based on the user input.

[0289] The analysis system 140 can generate UI 400C as a visual element of UI 400C that includes a path change window 412C, which can be an indication of path changes between nodes 160. The analysis system 140 can generate the path change window 412C as an identifier of the node associated with the path change (e.g., "external client") and an indication of the path change (e.g., "path change"). The analysis system 140 allows the user to select or prompt the user to select one or more of the node identifiers to view further information about the path change (e.g., "click any application service to view path changes").

[0290] The analysis system 140 can display detailed widgets (e.g., a path change window 412C) on the right side of the page, providing information on new alerts, resolved alerts, added nodes, removed nodes, and network path changes. Furthermore, the analysis system 140 can generate or display the path change window 412C to show new alerts using tooltips, where the tooltips display the indicators that caused the alerts. For example, the analysis system 140 can generate a path change window 412C with indicators about anomaly interface counters, which are displayed visually associated with network device identifiers. The analysis system 140 can generate a path change window 412C that includes both graph changes (added / removed nodes) and path changes.

[0291] Analysis system 140 can generate a widget for the path change window 412C that accepts graphical difference data as input for new alerts / resolved alerts / added / removed node sections that can be retrieved from the backend. Furthermore, the widget can accept path change data as input for network path change sections, and this can even be obtained from the backend. The widget can provide a callback function onNodeNameClick(name: string, source: "new alert"|"resolved alert"|"added"|"removed"|"path_change"), which is triggered when a node name in the detailed widget is clicked. As part of the callback function execution, analysis system 140 can generate UI 400C, where the corresponding node / path is highlighted within the topology graph, and the source of the highlight based on the change appears on the left or right graph. The callback function facilitates seamless user interaction, allowing SREs to quickly locate and focus on nodes / paths within a broad topology. Furthermore, the unique combination of HTML canvas rendering, key-value data storage, and the proposed graphical comparison method provides an innovative solution for topology change analysis.

[0292] exist Figure 4DIn this example, the analysis system 140 generates a UI 400D, which can be an instance of a GUI 400C. For instance, the analysis system 140 can generate the UI 400D as including a first snapshot 402D, a second snapshot 404D, a node 406D, a path 408D, a path change icon 410D, and a path change window 412D, as well as other visual elements. The analysis system 140 can generate the UI 400D based on user input or interaction with the visual elements of the UI 400C. In the example, the user interacts with visual elements of the UI 400C corresponding to nodes that have undergone path changes. The analysis system 140 generates the UI 400D based on this interaction.

[0293] The analysis system 140 can generate the UI 400D as including a first snapshot 402D and a second snapshot 404D as snapshots of the distributed application topology. The analysis system 140 can also generate the UI 400D to display only a portion of the first snapshot 402D and / or the second snapshot 404D. For example, the analysis system 140 can generate the UI 400D to be focused on or "zoomed in" on a portion of the distributed application topology visually represented by the first snapshot 402D and the second snapshot 404D.

[0294] Analysis system 140 can generate UI 400D based on the selection of node identifiers within the path change window 410D. Figure 4D In this example, the analysis system 140 receives a selection of "productpage-V1" within the path change window 410D. The analysis system 140 generates a UI 400D with the path change window 410D, which includes an indication that the selected path has triggered one or more alerts ("It appears a path change has introduced new alerts. Please review them immediately and take the necessary actions"). Furthermore, the analysis system 140 generates a UI 400D where the representation of the distributed application topology is focused on the representation of the changed paths.

[0295] The analysis system 140 generates UI 400D as including a path removal indicator 414D that visually indicates the removal of path 408D and a path addition indicator 416D that visually indicates the addition of path 408D. The path removal indicator 414D can visually indicate the removal of one or more paths 408D between snapshots via a text indicator (e.g., “X REMOVED PATH”) and / or the path's color / shading. The path addition indicator 414D can visually indicate the addition of one or more paths 408D between snapshots via a text indicator (e.g., “ADDED PATH”) and / or the path's color / shading. Furthermore, the analysis system 140 can generate UI 400D as including visual indications of other paths that have been affected or otherwise associated with the added / removed paths.

[0296] exist Figure 4E In the example, analysis system 140 generates UI 400E, which can be as follows: Figure 4D An example of UI400D is shown. The analysis system 140 generates UI 400E comprising a first snapshot 402E, a second snapshot 404E, a node 406E, a path 408E, a path change icon 410E, a path change window 412E, a path removal indicator 414E, and a path addition indicator 416E, each of which may resemble the corresponding visual element of UI 400D. For example, the analysis system 140 may generate UI400E where the first snapshot 402E is a snapshot of the distributed application topology in which a path change has triggered an alert, and where the second snapshot 404E is a snapshot of the distributed application topology in which the alert has been resolved.

[0297] The analysis system 140 generates a UI 400E that includes a snapshot timeline 418E. The snapshot timeline 418E can be a visual element of the UI 400E representing a timeline of one or more snapshots taken of the distributed application topology, and includes indications of the distributed application topology shown by the UI 400E (e.g., the topology represented by the first snapshot 402E and the second snapshot 404E). The snapshot timeline 418E allows the user to select one or more distributed application topologies to be displayed in a side-by-side comparison (e.g., how the first snapshot 402E and the second snapshot 404E are displayed side-by-side in the UI 400E). Furthermore, the snapshot timeline 418E allows the user to visualize changes between one or more snapshots. For example, the snapshot timeline 418E allows the user to view changes in the distributed application topology that resolve alerts caused by path changes. For example, the snapshot timeline 418E of the page can display the last 10 snapshots of the application topology. The analysis system 140 can provide the user with two processes to select previous and most recent application snapshots to compare changes in the application topology.

[0298] Analysis system 140 can determine that one or more changes have resolved alarms associated with path changes. For example, analysis system 140 can determine that a recovery path change has resolved alarms associated with the path change. Analysis system 140 can generate UI400E as a visual indication of the changes that resolved the alarms. Figure 4E In the example, the analysis system 140 generates the path change window 412E as a text indication that the path change has been resolved (e.g., “Good news! The path change has resolved the previous alert. No new critical logs were identified.”).

[0299] exist Figure 4F In the example, analysis system 140 generates UI 400F, which can be UI 400E or... Figures 4A to 4E Any other instance of the UI. The analysis system 140 can generate UI 400F as including one or more visual elements, such as a first snapshot 402F, a second snapshot 404F, a node 406F, a path 408F, a path change icon 410F, a path change window 412F, a path removal indicator 414F, and a path addition indicator 416F.

[0300] Analysis system 140 can generate UI 400F as an illustration of path changes between snapshots of a distributed application topology that have not yet caused an alert. In the example, analysis system 140 determines that no new alerts have occurred between the topology represented by first snapshot 402F and the topology represented by second snapshot 404F. Analysis system 140 generates UI 400F as including first snapshot 402F, second snapshot 404F, and a path change window 412F, wherein the path change window 412F includes a text indication of the lack of alerts caused by path changes (e.g., "No impact detected from recent path changes in alerts or logs. Everything remains stable"). Analysis system 140 can output GUI 400F for display.

[0301] Figure 5 This is a flowchart illustrating example operation of a computing system according to one or more technologies of this disclosure. (The remaining text appears to be unrelated and likely refers to further details about the technology.) Figure 1 discuss Figure 5 .

[0302] A computing system (such as analytics system 140) generates a first graph representing a first application topology of a distributed application at a first moment, wherein the first application topology includes a first plurality of nodes (502) of computing infrastructure (such as computing infrastructure 100) distributed across multiple layers. Analytics system 140 may generate the first graph, wherein the first application topology includes a first plurality of nodes of computing infrastructure 100 distributed across multiple layers. For example, analytics system 140 may use a module such as mapping module 144 to obtain information from node 160.

[0303] The analysis system 140 generates a second graph (504) representing a second application topology of a distributed application at a second time. The analysis system 140 can generate the second graph, where the second application topology includes a second plurality of nodes 160 of the computing infrastructure 100 distributed across multiple layers. The analysis system 140 can generate periodic snapshots of the application's topology within the computing infrastructure 100. For example, the analysis system 140 can generate snapshots of the topology based on periodic scheduling.

[0304] Analysis system 140 determines that the path has changed based on a comparison of the first and second graphs (506). Analysis system 140 can compare the first and second graphs to determine one or more paths between nodes 160. For example, analysis system 140 can compare the first and second graphs to determine that the path between TOR switch 16 and chassis switch 18 has changed.

[0305] Based on the determination that the path has changed, the analysis system 140 outputs an alert indicating that a problem in the computing infrastructure 100 is caused by the path change (508). The analysis system 140 can generate UI 152 as one or more visual indications that the path change and the alert are caused by the path change. In an example, the analysis system 140 determines that the path between the TOR switch and the chassis switch has changed, and the alert is caused by this path change. The analysis system 140 generates UI 140 as a visual indication that the alert is caused by the path change. The analysis system 140 outputs the UI for display. In some examples, the analysis system 140 can provide data about UI 152 to user device 150 for user device 150 to output UI 152.

[0306] The techniques described herein can be implemented in hardware, software, firmware, or any combination thereof. Different features described as modules, units, or components may be implemented together in an integrated logic device or separately as discrete but interoperable logic devices or other hardware devices. In some cases, different features of an electronic circuit may be implemented as one or more integrated circuit devices, such as integrated circuit chips or chipsets.

[0307] If implemented in hardware, this disclosure may relate to means such as a processor or integrated circuit device (e.g., an integrated circuit chip or chipset). Alternatively or additionally, if implemented in software or firmware, these techniques may be implemented at least in part by a computer-readable data storage medium comprising instructions that, when executed, cause one or more processors to perform one or more of the methods described above. For example, the computer-readable data storage medium may store such instructions that are executed by one or more processors.

[0308] Computer-readable media can form part of a computer program product, which may include packaging material. Computer-readable media may include computer data storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, etc. In some examples, the article of manufacture may include one or more computer-readable storage media. Computer-readable storage media may be distributed among multiple packages, devices, or other components capable of being configured with computer instructions.

[0309] In some examples, computer-readable storage media may include non-transient media. The term "non-transient" can indicate that the storage medium is not embodied in a carrier wave or propagating signal. In some examples, non-transient storage media may store data that may change over time (e.g., in RAM or cache).

[0310] The code or instructions can be software and / or firmware executed by processing circuitry including one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein can refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described in this disclosure can be provided within a software module or a hardware module.

Claims

1. A computing system, comprising: Memory; as well as The processing circuit communicates with the memory and is configured to: Generate a first graph representing a first application topology of a distributed application at a first moment, wherein the first application topology includes a first plurality of nodes of computing infrastructure distributed across multiple layers; Generate a second graph representing a second application topology of the distributed application at a second time, wherein the second application topology includes a second plurality of nodes of the computing infrastructure distributed across the plurality of layers; Based on the comparison between the first and second maps, it is determined that the path has changed; as well as Based on the determination that the path has changed, an alert is output indicating that the problem in the computing infrastructure is caused by the change in the path.

2. The computing system according to claim 1, wherein, The processing circuit is further configured to: Based on the determination that the path has changed, the configuration of the distributed application in the computing infrastructure is modified.

3. The computing system according to claim 2, wherein, In order to modify the configuration of the distributed application in the computing infrastructure, the processing circuitry is further configured to: Modify the configuration to restore the second application topology of the distributed application to the first application topology of the distributed application.

4. The computing system according to any one of claims 1 to 3, wherein, The processing circuit is further configured to: An output user interface is provided for display, the user interface including a visual representation of the second graph and an indication that an alert indicating a problem in the computing infrastructure is caused by a change in the path.

5. The computing system according to claim 4, wherein, The processing circuitry is also configured to generate the user interface to include visual indications of changes in the path.

6. The computing system according to claim 4, wherein, The processing circuit is further configured to: The user interface is generated to include visual representations of the first and second images.

7. The computing system according to any one of claims 1 to 3, wherein, The output of the alert indicating a problem in the computing infrastructure is caused by a change in the path. The indication is also based on the determination that the alert exists at the second time but not at the first time.

8. The computing system according to any one of claims 1 to 3, wherein, The output of the alert indicating a problem in the computing infrastructure is caused by a change in the path. The indication is also based on the determination that the alert is associated with a path that has been removed from or added to the first application topology.

9. The computing system according to claim 8, wherein, To determine whether the alarm is associated with a path that has been added to the first application topology, the processing circuitry is further configured to: Compare one or more alarms in the first graph with one or more alarms in the second graph.

10. The computing system according to any one of claims 1 to 3, wherein, One or more of the paths represent traffic flows between nodes of the distributed application, and wherein the one or more layers include at least one of the following: Service layer Instance layer, Computation layer leaf layer, and Ridge layer.

11. The computing system according to any one of claims 1 to 3, wherein, To determine that the path has changed, the processing circuit is further configured to: It is determined that at least one node has been removed from or added to the first application topology.

12. The computing system according to any one of claims 1 to 3, in, The first graph includes a first knowledge graph. The second graph includes a second knowledge graph, which is enhanced with alert information to associate one of a plurality of nodes with an alert indicating the problem in the computing infrastructure. The processing circuitry is configured to compare the first knowledge graph and the second knowledge graph to determine the alarm indicating that the problem in the computing infrastructure is caused by a change in the path.

13. A computer network method, comprising: A first graph representing a first application topology of a distributed application is generated by a computing system at a first moment, wherein the first application topology includes a first plurality of nodes of computing infrastructure distributed across multiple layers; The computing system generates a second graph representing a second application topology of the distributed application at a second time, wherein the second application topology includes a second plurality of nodes of the computing infrastructure distributed across the plurality of layers; The computing system determines that the path has changed based on a comparison between the first and second maps; as well as Based on the determination that the path has changed, the computing system outputs an alert indicating that the problem in the computing infrastructure is caused by the change in the path.

14. The method of claim 13, further comprising: Based on the determination that the path has changed, the computing system modifies the configuration of the distributed application in the computing infrastructure.

15. The method according to claim 14, wherein, Modifying the configuration of the distributed application in the computing infrastructure further includes: Modify the configuration to restore the second application topology of the distributed application to the first application topology of the distributed application.

16. The method according to any one of claims 13 to 15, wherein, Identifying that the path has changed also includes: It is determined that at least one node has been removed from or added to the first application topology.

17. The method according to any one of claims 13 to 15, further comprising: The computing system outputs a user interface for display, the user interface including a visual representation of the second graph and an alert indicating that a problem in the computing infrastructure is caused by a change in the path.

18. The method of claim 17, further comprising: The user interface is generated as a visual indication of the changes in the path.

19. The method of claim 17, further comprising: The user interface is generated to include visual representations of the first and second images.

20. A computer-readable storage medium encoded with instructions for causing one or more programmable processors to be configured as a computing system according to any one of claims 1 to 12 or to be configured to perform the method according to any one of claims 13 to 19.

Images