Patent Description:
Datacenters often leverage a microservice architecture to provide for network infrastructure services. A microservice architecture can arrange an application as a collection of loosely-coupled microservices. Microservices can refer to processes that communicate over a network to fulfill a goal using technology-agnostic protocols. In some cases, the microservices may be deployed using a container orchestration platform providing containerized workloads and/or services. The container orchestration platforms may utilize a service mesh to manage the high volume of network-based inter-process communication among the microservices. The service mesh is a dedicated software infrastructure layer for the microservices that includes elements to enable the communication among the microservices to be fast, reliable, and secure. The service mesh provides capabilities including service discovery, load balancing, encryption, observability, traceability, and authentication and authorization. The microservices deployment model provided by the service mesh is becoming increasingly elastic, providing flexibility to scale up and scale down microservices.

In a service mesh environment, a typical worker node in a compute cluster can handle hundreds of container workloads at the same time. These worker nodes may also have statically-attached specialized hardware accelerators optimized for compute intensive tasks. For instance, a class of hardware accelerators can be optimized to efficiently run cryptography and compression algorithms, or to run machine-learning acceleration algorithms. Such hardware accelerators may be provided as a form of disaggregated computing, where the workloads are distributed on disaggregated compute resources, such as CPUs, GPUs, and hardware accelerators (including field programmable gate arrays (FPGAs)), that are connected via a network instead of being on the same platform and connected via physical links such as peripheral component interconnect express (PCIe). Disaggregated computing enables improved resource utilization and lowers ownership costs by enabling more efficient use of available resources. Disaggregated computing also enables pooling a large number of hardware accelerators for large computation making the computation more efficient and better performing.

As the elasticity of deployment of microservices increases and as microservices architecture transitions to utilizing disaggregated computing resources, the amount of data collected as part of trace and performance telemetry collection can become burdensome. Furthermore, the amount of data and information generated by trace and performance telemetry collection can become problematic for networking of the microservices, considering that high volumes of data are transmitted in short periods of time. The document <CIT> discloses a distributed tracing system that detects an error or a slow query generated in an application and presents a state in the application. The distributed tracing system also traces and records transactions in the application. The distributed tracing system performs monitoring and performance analysis of the system. An additional container called Sidecar (Proxy) is deployed for performing tracing.

So that the manner in which the above recited features of the present embodiments can be understood in detail, a more particular description of the embodiments, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate typical embodiments and are therefore not to be considered limiting of its scope. The figures are not to scale. In general, the same reference numbers are used throughout the drawing(s) and accompanying written description to refer to the same or like parts.

Implementations of the disclosure describe matchmaking-based enhanced debugging for microservices architectures.

Cloud service providers (CSPs) are deploying solutions in datacenters where processing of a workload is distributed on various compute resources, such as central processing units (CPUs), graphics processing units (GPUs), and/or hardware accelerators (including, but not limited to, GPUs, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), cryptographic accelerators, compression accelerators, and so on). Traditionally, these compute resources were running on the same platform and connected via physical communication links, such as peripheral component interconnect express (PCIe).

However, disaggregated computing is on the rise in data centers. With disaggregated computing, CSPs are deploying solutions where processing of a workload is distributed on disaggregated compute resources, such as CPUs, GPUs, and hardware accelerators (including FPGAs, ASICs, etc.), that are connected via a network instead of being on the same platform and connected via physical links such as PCIe. Disaggregated computing enables improved resource utilization and lowers ownership costs by enabling more efficient use of available resources. Disaggregated computing also enables pooling a large number of hardware accelerators for large computation making the computation more efficient and better performing.

Hardware accelerators (also referred to herein as a hardware accelerator resources, hardware accelerator devices, accelerator resource, accelerator device, and/or extended resource) as discussed herein may refer to any of special-purpose central processing units (CPUs), graphics processing units (GPUs), general purpose GPUs (GPGPUs), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), inference accelerators, cryptographic accelerators, compression accelerators, other special-purpose hardware accelerators, and so on.

Moreover, the datacenters used by CSPs to deploy a service mesh often leverage a microservice architecture to provide for network infrastructure services of the service mesh. A microservice architecture can arrange an application as a collection of loosely-coupled microservices. The microservices may be the processes that communicate over a network to fulfill a goal using technology-agnostic protocols. In some cases, the microservices can be deployed using a container orchestration platform providing containerized workloads and/or services. In some examples, the service may be a large service comprising hundreds of microservices working in conjunction with each other or may be a modest individual service. A workload may refer to a resource running on the cloud consuming resources, such as computing power. In some embodiments, an application, service, or microservice may be referred to as a workload, which denotes the workload can be moved around between different cloud platforms or from on-premises to the cloud or vice-versa without any dependencies or hassle.

The container orchestration platforms may utilize a service mesh to manage the high volume of network-based inter-process communication among the microservices. The service mesh is a dedicated software infrastructure layer for the microservices that includes elements to enable the communication among the microservices to be fast, reliable, and secure. The service mesh provides capabilities including service discovery, load balancing, encryption, observability, traceability, and authentication and authorization.

As previously noted, the microservices deployment model provided by the service mesh is becoming increasingly elastic, providing flexibility to scale up and scale down microservices. As the elasticity of deployment of microservices increases and as microservices architecture transitions to utilizing disaggregated computing resources, the amount of data collected as part of trace and performance telemetry collection can become burdensome in terms of interpretation (e.g., especially in real time).

Trace and performance telemetry collection is a heavy process that cannot run all the time in production environments. Conventionally, when an issue occurs with a service in the service mesh, a service expert is called in to manually enable tracing or additional logging during specific time windows, so that enough data is collected for analysis and to hopefully identify the issue. This is even more complex on highly distributed systems using microservices architectures. In addition, microservices utilize additional platform components that are running under different privileges, which is complex to match.

Furthermore, the amount of data and information generated by trace and performance telemetry collection can become problematic for networking of the microservices, considering that high volumes of data are transmitted in short periods of time. The amount of information generated is a risk for networking, considering that high volumes of data are transmitted in short periods of time.

Implementations of the disclosure address the above-noted technical drawbacks by providing for matchmaking-based enhanced debugging for microservices architectures. In implementations herein, techniques are provided for matchmaking-based enhanced debugging for microservices architectures. In implementations herein, a sidecar is utilized for each microservice, where the sidecar allows for distributed tracing as a streaming service, with tag information generated by the sidecar. In some implementations, the distributed tracing as a streaming service, with generated tag information, may be performed by other service/microservice components than the sidecar.

An anomaly detection component of the sidecar can analyze telemetry data collected from a service platform hosting the microservice (and sidecar) and includes hooks to capture errors in the service (application) associated with an anomaly. Once an anomaly is detected, an enhanced debug and trace component of the sidecar can enable a debug bug for the microservice. During the debug mode, trace and performance telemetry collection proceeds simultaneously for different components in a stack where the components do not all run at the same privilege; for example, PMU counters or device counters contain indications of activities or errors that span more than just the microservice(s) that are of interest. In some cases, these counters, OS activity traces, etc., should be processed separately, and the portions specific to a given microservice can be broken out or projected. Such is the case, for example, with Wireshark traces, KU traces, etc..

The enhanced debug and trace component can perform a matchmaking process on the collected debug data, where the matchmaking process can introduce timestamped markers and tags in the telemetry stream so that information streams that should be separated out can be indexed against these markers into a global collection and analysis agent. In implementations here, different levels of traces can be enabled based on service policies and/or application-specific service level agreements (SLA)/service level objectives (SLO). The global agent can then respond to these markers and return information it indexes for these markers. As a result, scheduler traces for all threads (other than the threads identified by the sidecar proxy) are anonymized, obfuscated, or normalized out, depending on the privilege of the entity that furnishes the marker along with a query.

The on-demand distributed tracing of implementations herein can reduce the data traffic in the service platform deploying the microservices of the service. This can also contribute to performing a comprehensive analysis of a failure on complex systems.

Implementations of the discosure provide technical advantages over the conventional approaches discussed above. One technical advantage is that implementations reduce a time window used to capture relevant information about issues happening in production systems, automatically and temporarily reconfiguring the system for debug/tracing mode. Furthermore, the use of sidecars to enable the enhanced debugging described herein allows for managing telemetry information at different privileges, making the dataset for analysis more complete.

<FIG> illustrates a datacenter system <NUM> that provides for matchmaking-based enhanced debugging for microservices architectures, in accordance with implementations herein. Datacenter system <NUM> illustrates an example data center (for example, hosted by a cloud service provider (CSP)) providing a variety of XPUs (heterogeneous processing units) for processing tasks at the datacenter, where an XPU can include one or more of: a central processing unit (CPU) <NUM>, a graphics processing unit (GPU) <NUM> (including a general purpose GPU (GPGPU), ASICs, or other processing units (e.g., accelerators <NUM>, <NUM>, <NUM>, inference accelerators <NUM>, cryptographic accelerators <NUM>, programmable or fixed function FPGAs <NUM>, application-specific integrated circuit (ASICs) <NUM>, compression accelerators, and so on). The datacenter may also provide storage units for data storage tasks, as well. The storage units may include solid state drive (SSD) <NUM>, for example. The XPUs and/or storage units may be hosted with similar-type units (e.g., CPUS <NUM> hosted on an application server (app server) <NUM>, SSDs <NUM> hosted on a storage rack <NUM>, GPUs <NUM> hosted on a GPU rack <NUM>, inference accelerators <NUM> hosted on an inference accelerator server <NUM>, cryptographic accelerators <NUM> hosted on a cryptographic accelerator rack <NUM>, and general-purpose accelerators <NUM>, <NUM>, <NUM> hosted on accelerator rack <NUM>.

The datacenter of system <NUM> provides its hosted processing components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> with a variety of offloads using, for example, IPUs <NUM> that are directly attached to the respective host processing component. Although IPUs <NUM> are discussed for example purposes, other programmable network devices, such as DPUs or SmartNICs, may be used interchangeable for IPUs <NUM> herein. The offloads provided may be networking, storage, security, etc. This allows the processing components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> to run without a hypervisor, and provides CSPs the capability of renting out the entire host in a datacenter to their security-minded customers, or avoid cross-talk and other problems associated with multitenant hosts.

An IPU <NUM> can provide a role in data centers by providing the datacenter operator, such as a Cloud Service Provider (CSP), a control point for security, acceleration, telemetry and service orchestration. IPU <NUM> architecture may build upon existing Smart Network Interface Card (SmartNIC) features and is a part of controlling security and data acceleration within and across distributed platforms. It is a secure domain controlled by CSPs for managing a platform, providing services to tenants, and securing access into the data center network. The IPU <NUM> increases the performance and predictability for distributed runtimes and enables scaling to multi-terabit throughputs by offloading host services, reliable transport, and optimizing data copies.

IPUs <NUM> have grown in complexity over the years, starting with foundational NICs, whose sole purpose was to get packets into the host and out of it. With the addition of networking software offload, the NICs evolved to become SmartNICs, that are capable of offloading functions, such as VSwitch, VIRTIO-Net, AVF, etc. Remote disaggregated storage architectures provide a further evolution, where compute and storage are not colocated anymore, but large compute clusters are connected to large storage clusters over the network. Increase in network speeds, and evolution of protocols made this a possibility. One of the advantages that remote disaggregated storage offers over direct attached storage is that compute and memory can be developed and updated at different cadences. The amount of memory that is attached to a compute node is not limited by physical addition or removal of hard-drives anymore, but can be hot-plugged as a PF to a PCIe Switch. Technologies such as Smart End Point enable IPUs to have firmwarecontrolled switches, along the PCIe Switch itself to not be limited by hardware implementations.

As discussed above, embodiments herein provide for matchmaking-based enhanced debugging for microservices architectures. In one implementation, datacenter system <NUM> includes one or more resources that can implement an enhanced debug/trace component <NUM> to provide the matchmaking-based enhanced debugging for microservices architectures. For illustrative example purposes, enhanced debug/trace component <NUM> is shown in the CPU <NUM> and GPU <NUM>, respectively, of datacenter system <NUM>. However, enhanced debug/trace component <NUM> may operate in one or more of the various other disaggregated resources of datacenter system <NUM> in accordance with implementations herein. As such, the resources of datacenter system <NUM> may be in different platforms connected via a network (not shown) in the datacenter system <NUM>. In some implementations, software and/or middleware can cause the resources of datacenter system <NUM> to logically appear to be in the same platform. Furthermore, transport protocols implemented in software and/or hardware (e.g., network interface cards (NICs)) can make the remote resources logically appear as if they are local resources as well.

Further details of the enhanced debug/trace component <NUM> implementing the matchmaking-based enhanced debugging for microservices architectures as described below with respect to <FIG>.

<FIG> illustrates a block diagram of components of a computing platform 202A in a datacenter system <NUM>, according to implementations herein. In the embodiment depicted, platforms 202A, 202B, and 202C (collectively referred to herein as platforms <NUM>), along with a data center management platform <NUM> are interconnected via network <NUM>. In other embodiments, a computer system may include any suitable number of (i.e., one or more) platforms. In some embodiments (e.g., when a computer system includes a single platform), all or a portion of the datacenter management platform <NUM> may be included on a platform <NUM>.

A platform <NUM> may include platform resources <NUM> with one or more processing resources <NUM> (e.g., XPUs including CPUs, GPUs, FPGAs, ASICs, other hardware accelerators), memories <NUM> (which may include any number of different modules), chipsets <NUM>, communication interface device(s) <NUM>, and any other suitable hardware and/or software to execute a hypervisor <NUM> or other operating system capable of executing workloads associated with applications running on platform <NUM>.

In some embodiments, a platform <NUM> may function as a host platform for one or more guest systems <NUM> that invoke these applications. Platform 202A may represent any suitable computing environment, such as a high-performance computing environment, a data center, a communications service provider infrastructure (e.g., one or more portions of an Evolved Packet Core), an in-memory computing environment, a computing system of a vehicle (e.g., an automobile or airplane), an Internet of Things (IoT) environment, an industrial control system, other computing environment, or combination thereof.

Each platform <NUM> may include platform resources <NUM>. Platform resources <NUM> can include, among other logic enabling the functionality of platform <NUM>, one or more processing resources <NUM> (such as CPUs, GPUs, FPGAs, other hardware accelerators, etc.), memory <NUM>, one or more chipsets <NUM>, and communication interface devices <NUM>. Although three platforms are illustrated, computer platform 202A may be interconnected with any suitable number of platforms. In various embodiments, a platform <NUM> may reside on a circuit board that is installed in a chassis, rack, or other suitable structure that comprises multiple platforms coupled together through network <NUM> (which may comprise, e.g., a rack or backplane switch).

In the case of processing resources <NUM> comprising CPUs, the CPUs may each comprise any suitable number of processor cores and supporting logic (e.g., uncores). The cores may be coupled to each other, to memory <NUM>, to at least one chipset <NUM>, and / or to a communication interface device <NUM>, through one or more controllers residing on the processing resource <NUM> (e.g., CPU) and/or chipset <NUM>. In some embodiments, a processing resource <NUM> is embodied within a socket that is permanently or removably coupled to platform 202A. A platform <NUM> may include any suitable number of processing resources <NUM>.

Memory <NUM> may comprise any form of volatile or nonvolatile memory including, without limitation, magnetic media (e.g., one or more tape drives), optical media, random access memory (RAM), read-only memory (ROM), flash memory, removable media, or any other suitable local or remote memory component or components. Memory <NUM> may be used for short, medium, and/or long term storage by platform 202A. Memory <NUM> may store any suitable data or information utilized by platform resources <NUM>, including software embedded in a computer readable medium, and/or encoded logic incorporated in hardware or otherwise stored (e.g., firmware). Memory <NUM> may store data that is used by cores of processing resources <NUM>. In some embodiments, memory <NUM> may also comprise storage for instructions that may be executed by the processing resources <NUM> (e.g., cores of CPUs) or other processing elements (e.g., logic resident on chipsets <NUM>) to provide functionality associated with the management component <NUM> or other components of platform resources <NUM>.

A platform <NUM> may also include one or more chipsets <NUM> comprising any suitable logic to support the operation of the processing resources <NUM>. In various embodiments, chipset <NUM> may reside on the same die or package as a processing resource <NUM> or on one or more different dies or packages. Each chipset may support any suitable number of processing resources <NUM>. A chipset <NUM> may also include one or more controllers to couple other components of platform resources <NUM> (e.g., communication interface device <NUM> or memory <NUM>) to one or more processing resources <NUM>.

In the embodiment depicted, each chipset <NUM> also includes a management component <NUM>. Management component <NUM> may include any suitable logic to support the operation of chipset <NUM>. In a particular embodiment, a management component <NUM> can collect real-time telemetry data from the chipset <NUM>, the processing resources <NUM>, and/or memory <NUM> managed by the chipset <NUM>, other components of platform resources <NUM>, and/or various connections between components of platform resources <NUM>.

Chipsets <NUM> also each include a communication interface device <NUM>. Communication interface device <NUM> may be used for the communication of signaling and/or data between chipset <NUM> and one or more I/O devices, one or more networks <NUM>, and/or one or more devices coupled to network <NUM> (e.g., system management platform <NUM>). For example, communication interface device <NUM> may be used to send and receive network traffic such as data packets. In a particular embodiment, a communication interface device <NUM> comprises one or more physical network interface controllers (NICs), also known as network interface cards or network adapters. A NIC may include electronic circuitry to communicate using any suitable physical layer and data link layer standard such as Ethernet (e.g., as defined by an IEEE <NUM> standard), FibreChannel, InfiniBand, Wi-Fi, or other suitable standard. A NIC may include one or more physical ports that may couple to a cable (e.g., an Ethernet cable). A NIC may enable communication between any suitable element of chipset <NUM> (e.g., management component <NUM>) and another device coupled to network <NUM>. In various embodiments, a NIC may be integrated with the chipset <NUM> (i.e., may be on the same integrated circuit or circuit board as the rest of the chipset logic) or may be on a different integrated circuit or circuit board that is electromechanically coupled to the chipset.

Platform resources <NUM> may include an additional communication interface <NUM>. Similar to communication interface devices <NUM>, communication interfaces <NUM> may be used for the communication of signaling and/or data between platform resources <NUM> and one or more networks <NUM> and one or more devices coupled to the network <NUM>. For example, communication interface <NUM> may be used to send and receive network traffic such as data packets. In a particular embodiment, communication interfaces <NUM> comprise one or more physical NICs. These NICs may enable communication between any suitable element of platform resources <NUM> (e.g., processing resources <NUM> or memory <NUM>) and another device coupled to network <NUM> (e.g., elements of other platforms or remote computing devices coupled to network <NUM> through one or more networks).

Platform resources <NUM> may receive and perform any suitable types of workloads. A workload may include any request to utilize one or more resources of platform resources <NUM>, such as one or more cores or associated logic. For example , a workload may comprise a request to instantiate a software component, such as an I/O device driver <NUM> or guest system <NUM>; a request to process a network packet received from a microservices container 232A, 232B (collectively referred to herein as microservice containers <NUM>) or device external to platform 202A (such as a network node coupled to network <NUM>); a request to execute a process or thread associated with a guest system <NUM>, an application running on platform 202A, a hypervisor <NUM> or other operating system running on platform 202A; or other suitable processing request.

A microservice container <NUM> may emulate a computer system with its own dedicated hardware. A container <NUM> may refer to a standard unit of software that packages up code and all its dependencies, so the application runs quickly and reliably from one computing environment to another. A container image is a lightweight, standalone, executable package of software that includes components used to run an application: code, runtime, system tools, system libraries and settings. Containers <NUM> take advantage of a form of operating system (OS) virtualization in which features of the OS are leveraged to both isolate processes and control the amount of CPU, memory, and disk that those processes have access to.

When implementing containers <NUM>, hypervisor <NUM> may also be referred to as a container runtime. Although implementations herein discuss virtualization of microservice functionality via containers, in some implementations, virtual machines may be hosted by hypervisor <NUM> and utilized to host microservices and/or other components of a service provided by an application.

A hypervisor <NUM> (also known as a virtual machine monitor (VMM)) may comprise logic to create and run guest systems <NUM>. The hypervisor <NUM> may present guest operating systems run by virtual machines with a virtual operating platform (i.e., it appears to the virtual machines that they are running on separate physical nodes when they are actually consolidated onto a single hardware platform) and manage the execution of the guest operating systems by platform resources <NUM>. Services of hypervisor <NUM> may be provided by virtualizing in software or through hardware-assisted resources that utilize minimal software intervention, or both. Multiple instances of a variety of guest operating systems may be managed by the hypervisor <NUM>. Each platform <NUM> may have a separate instantiation of a hypervisor <NUM>.

In implementations herein, the hypervisor <NUM> may also be implemented as a container runtime environment capable of building and containerizing applications.

Hypervisor <NUM> may be a native or bare-metal hypervisor that runs directly on platform resources <NUM> to control the platform logic and manage the guest operating systems. Alternatively, hypervisor <NUM> may be a hosted hypervisor that runs on a host operating system and abstracts the guest operating systems from the host operating system. Hypervisor <NUM> may include a virtual switch <NUM> that may provide virtual switching and/or routing functions to virtual machines of guest systems <NUM>.

Virtual switch <NUM> may comprise a software element that is executed using components of platform resources <NUM>. In various embodiments, hypervisor <NUM> may be in communication with any suitable entity (e.g., a SDN controller) which may cause hypervisor <NUM> to reconfigure the parameters of virtual switch <NUM> in response to changing conditions in platform <NUM> (e.g., the addition or deletion of microservice containers <NUM> or identification of optimizations that may be made to enhance performance of the platform).

The elements of platform resources <NUM> may be coupled together in any suitable manner. For example, a bus may couple any of the components together. A bus may include any known interconnect, such as a multi-drop bus, a mesh interconnect, a ring interconnect, a point-to-point interconnect, a serial interconnect, a parallel bus, a coherent (e.g., cache coherent) bus, a layered protocol architecture, a differential bus, or a Gunning transceiver logic (GTL) bus, to name a few examples.

Elements of the computer platform 202A may be coupled together in any suitable manner such as through one or more networks <NUM>. A network <NUM> may be any suitable network or combination of one or more networks operating using one or more suitable networking protocols. A network may represent a series of nodes, points, and interconnected communication paths for receiving and transmitting packets of information that propagate through a communication system. For example, a network may include one or more firewalls, routers, switches, security appliances, antivirus servers, or other useful network devices.

In implementations herein, microservice containers <NUM> may provide an enhance debug/trace component (not shown), such as enhanced debug/trace component <NUM> described with respect to <FIG>. Further details of how the microservice containers <NUM> implement the enhanced debug/trace component for providing matchmaking-based enhanced debugging for microservices architectures are described below with respect to <FIG>.

<FIG> is a block diagram of a service platform <NUM> implementing matchmaking-based enhanced debugging for microservices architectures, in accordance with implementations herein. In one implementation, service platform <NUM> is the same as platform <NUM> of datacenter system <NUM> described with respect to <FIG>. In some implementations, service platform <NUM> may be hosted in a datacenter that may or may not utilize disaggregated computing. Embodiments herein are not limited to implementation in disaggregated computing environments, and may be deployed across a large spectrum of different datacenter environments. The disaggregated computing datacenter system <NUM> of <FIG> is provided as an example implementation for service platform <NUM> and is not intended to limit embodiments herein.

In one implementation, service platform <NUM> may host a service implemented with one or more microservice containers 320A, 320B (collectively referred to herein as microservice container <NUM>). Microservice containers <NUM> may be the same as microservice containers <NUM> described with respect to <FIG>. The service may be orchestrated and manager using service management component <NUM>. Service management component <NUM> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware.

Service platform <NUM> may function as a host platform for a service, implementing deployed microservices of the service as one or more microservice containers <NUM> that invoke functionalities of the service. Service platform <NUM> may represent any suitable computing environment, such as a high-performance computing environment, a data center, a communications service provider infrastructure (e.g., one or more portions of an Evolved Packet Core), an in-memory computing environment, a computing system of a vehicle (e.g., an automobile or airplane), an Internet of Things (IoT) environment, an industrial control system, other computing environment, or combination thereof. In implementations herein, containers <NUM> may be implemented using hardware circuitry, such as one or more of a CPU, a GPU, a hardware accelerator, and so on. In one embodiment, containers <NUM> may be implemented using platform <NUM> described with respect to <FIG>.

Microservices containers <NUM> may include logic to implement the functionality of the microservice 325A, 325B (collectively referred to herein as microservices <NUM>) and a sidecar 330A, 330B (collectively referred to herein as sidecars <NUM>. A sidecar <NUM> can be a container that runs on the same pod as the microservice <NUM>. As depicted herein, sidecar <NUM> is illustrated as part of the microservice container <NUM>, but sidecar <NUM> may be implemented as a separate container then microservice <NUM> functionality in some implementations.

In implementations herein, sidecar <NUM> may include one or more components to support matchmaking-based enhanced debugging for microservices architectures. These components can include data ingestion 332A, 332B (collectively referred to herein as data ingestion <NUM>), collected data 334A, 334B (data stores collectively referred to as collected data <NUM>), microservice anomaly detection 336A, 336B (collectively referred to as microservice anomaly detection <NUM>), and microservice enhanced debug/trace 338A, 338B (collectively referred to herein as microservice enhanced debug/trace <NUM>).

A local facilitator <NUM> is connected to the sidecars <NUM> and can operate in a privileged space of the microservice containers <NUM>. In one implementation, local facilitator <NUM> is a privileged daemon with access to low-level information. For example, local facilitator <NUM> has access to low-level software telemetry and hardware data, such as registries.

Service platform <NUM> also includes a service management component <NUM>. Service management component <NUM> may be implemented using hardware circuitry, such as one or more of a CPU, a GPU, a hardware accelerator, and so on. In one embodiment, service management component <NUM> may be implemented using platform <NUM> described with respect to <FIG>. More generally, the example service management component <NUM> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, the service management component <NUM> could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)).

In one implementation, service management component <NUM> operates to control management and/or orchestration of resources, such as microservices, for a service of a service mesh hosted by a datacenter, such as datacenter system <NUM> of <FIG>. Service management component <NUM> may located at the same nodes or on a different node of microservice containers <NUM> in the service platform <NUM>.

Service management component <NUM> may include one or more components to support matchmaking-based enhanced debugging for microservices architectures. These components can include service data ingestion <NUM>, service collected data <NUM> (data store), service anomaly detection <NUM>, and service debug/trace manager <NUM>.

In implementations herein, the microservice containers <NUM> and service management component <NUM> provide for matchmaking-based enhanced debugging for microservices architectures. In one implementation, the sidecar <NUM> for each microservice container <NUM> includes a data ingestion component <NUM> that receives telemetry data of the service platform <NUM> that is pertinent to the microservice <NUM>. This telemetry data can include lower-level layers in the architecture (e.g., privileged space) and application (microservice <NUM>) telemetry data and logs (e.g., user space). The collected data <NUM> maintains this microservice-related data as historic data. The microservice anomaly detection component <NUM> continuously analyzes the data stored in the collected data <NUM> to identify any deviations from normal or typical behavior. The microservice enhanced debug/trace component <NUM> manage the microservice container <NUM> to enable different modes of the microservice container <NUM>, including a production (performance) mode and a debug mode, based on a detected anomaly by the microservice anomaly detection component <NUM>.

The service management component <NUM> includes a similar set of components <NUM>-<NUM>, but at a higher level (e.g., per service/application), which can monitor the behavior of a group of microservices <NUM> interacting together to achieve a certain goal.

In implementations herein, the sidecar <NUM> per microservice <NUM> allows for distributed tracing as a streaming service, with tag information generated for the trace data by the sidecar <NUM>. The distributed tracing is triggered on-demand by the microservice anomaly detection component <NUM>. The on-demand distributed tracing per microservice container <NUM> helps to reduce the data traffic in the service platform <NUM>.

The microservice anomaly detection component <NUM> analyzes telemetry data of the platform that is pertinent to the microservice <NUM>. As noted above, this telemetry data can include lower-level layers in the service platform <NUM> (e.g., privileged space) and can include application (microservice <NUM>) telemetry data and logs (e.g., user space). The microservice anomaly detection component <NUM> can provide hooks to capture errors in the applications (e.g., application service level objective (SLO) dictates processing at 30fps, but instead the application is processing at 28fps). In implementations herein, the microservice anomaly detection component <NUM> can consider infrastructure and application SLOs.

To obtain the collected data <NUM>, the microservice anomaly detection component <NUM> can query the information available in the user space and, in addition, can invoke the local facilitator <NUM>. The local facilitator <NUM> is connected to the sidecars <NUM> and has access to low level software telemetry and hardware data such as registries. As such, the local facilitator <NUM> can query the state of the service platform <NUM>. Based on the collected data <NUM>, the microservice anomaly detection component <NUM> can determine whether there are any deviations from normal or typical behavior. If a deviation is detection, the microservice anomaly detection component <NUM> can indicate the anomaly, including its type, to the microservice enhanced debug/trace component <NUM>.

When an anomaly is detected, the microservice enhanced debug/trace component <NUM> can cause a debug mode to be enabled for the microservice container <NUM>. The debug mode may be dynamically (e.g., during runtime) scalable in terms of the number and/or amount of information being traced in the microservice container <NUM>. For example, the debug mode may set an amount of data collected for the microservice container <NUM> based on one or more of the type of anomaly or a service level agreement (SLA) corresponding to the microservice <NUM>. In some implementations, the debug mode can be a debug mirror mode where duplicate resources (e.g., one or more mirror microservice container <NUM> are deployed to run an identical set of operations as the primary microservice container <NUM> with debug mode enabled in the mirror microservice containers <NUM>). This debug mirror mode may be implemented for non-intrusive tracing purposes and/or for performance-critical microservices, for example.

The type of the anomaly can be used to determine what queries to run and for how long in the enabled debug mode. For example, the following possible implementations of queries to run in an enabled debug mode include (<NUM>) predefined set of queries to perform. , check registry X, analyze memory consumption, etc.; (<NUM>) using supervised learning (SVM) to identify the possible actions, or reinforcement learning based on rewards; and/or (<NUM>) using unsupervised learning utilizing clusters where there is no explicit information, and the objective is to find useful and desired metrics on a trialand-error basis.

Once debug mode is enabled, a target set of data points intended to be collected is set (depending on the type of anomaly, as discussed above). Trace and performance telemetry collection proceeds simultaneously for different components in a stack where the components do not all run at the same privilege; for example, PMU counters or device counters contain indications of activities or errors that span more than just the microservice(s) that are of interest. In some cases, these counters, OS activity traces, etc., should be processed separately and the portions specific to a given microservice should be broken out and/or projected. For example, this may be the case with Wireshark traces, KU traces, etc. In some implementations, based on provisioned policies, the data ingestion component <NUM> can obtain encrypted blobs from various components, which can be archived with appropriate metadata.

When the data ingestion component <NUM> starts receiving data coming from user and privilege spaces as part of the enabled debug mode, the microservice enhanced debug/trace component <NUM> can perform a matchmaking process to analyze and tag the collected data. The microservice enhanced debug/trace component <NUM> can perform the matchmaking process on the data from privileged space and on the data from user space. During the matchmaking process, each piece of data is timestamped, tagged for context (i.e., source (user or privileged), sub-component, microservice_id, thread_id, etc.), and optionally signed. The matchmaking process can also consider configurations (e.g., microservice pinned to core <NUM>), profiling, and overall context (e.g., timestamps, resource utilization).

Once the debug/trace information is gathered and matched from the matchmaking process, the microservice enhanced debug/trace component <NUM> makes it available to a next component in the service platform <NUM>, such as a global collection and analysis agent. In one implementation, this global collection and analysis agent works on identifying the possible causes (i.e., clone production systems to reproduce the issue based on the logs and tracing information gathered). In implementations herein, the global collection and analysis agent can be the service debug/trace manager <NUM> of service management component <NUM>.

The processed data (including timestamped markers and tags in the telemetry stream) enables information streams that should be separated out to be indexed against these markers/tags into the global collection and analysis agent, such as the service debug/trace manager <NUM> of service management component <NUM>. The global agent (e.g., service debug/trace manager <NUM>) can respond to these markers and return information it indexes for these markers, so that traces for all threads other than the threads identified by the sidecar <NUM> are anonymized, obfuscated, or normalized out (depending on the privilege of the entity that furnishes the marker along with a query).

In one implementation, once the debug mode information is fully captured, the microservice enhanced debug/trace component <NUM> can return the microservice container <NUM> to a performance mode where debug/trace data is no longer being collected. In some implementations, the performance mode may be enabled after expiration of a time window defined for the debug mode. In some implementations, the performance mode may include generating a reduced set of debugging information (as compared to the debug mode).

As previously noted, the service management component <NUM> includes a similar set of components <NUM>-<NUM>, but at a higher level (e.g., per service/application), which can monitor the behavior of a group of microservices <NUM> interacting together to achieve a certain goal. In some implementations, the service management component <NUM> may perform a similar process for enhanced debug and trace as performed by the components of the sidecar <NUM> discussed above.

In one implementation, the service debug/trace manager <NUM> can generate a configuration overview of the service. The configuration overview can detail hardware and software components of deployed microservices of the service and interactions between the deployed microservices. The service data ingestion component <NUM> can collect telemetry data of the service and store this collected data in the service collected data <NUM>. The service anomaly detection component <NUM> can continuously (or periodically) analyze the service collected data <NUM> to determine whether any anomalies are detected in the service.

Based on a detected anomaly, the service debug/trace manager <NUM> can identify a set of microservices for which to enable a debug mode. The set of microservice identified can be based on the previously generated configuration overview. In implementations herein, the service debug/trace manager <NUM> can communicate with the set of microservices to cause the debug mode to be enabled in the set of microservices. Such enabling of the debug mode override, or compliment, the debug mode enabled by the microservice enhance debug/trace component <NUM> as previously discussed. In one implementation, the debug mode can be enabled at different levels in the set of microservices based on a type of the anomaly and an SLA of the service.

Once the debug mode is enabled at the set of microservice, the service debug/trace manager <NUM> may receive processed debug and trace data from the set of microservice. In implementations herein, the processed debug and trace data generated during the debug mode and processed with the matchmaking process at the set of microservices, as discussed above. In one implementation, the matchmaking process can attach timestamp and context tags to the processed debug and trace data. The service debug/trace manager <NUM> can perform a global analysis of the anomaly for the service based on the processed debug and trace data received from the set of microservices and based on the configuration overview. For example, the service debug/trace manager <NUM> can obtain the data by filtering by microservice_id and obtained the full context for debugging the anomaly of the service.

Embodiments may be provided, for example, as a computer program product which may include one or more machine - readable media having stored thereon machine executable instructions that, when executed by one or more machines such as a computer, network of computers, or other electronic devices, may result in the one or more machines carrying out operations in accordance with embodiments described herein. A machine - readable medium may include, but is not limited to, floppy diskettes, optical disks, CD - ROMs (Compact Disc - Read Only Memories), and magneto - optical disks, ROMs, RAMS, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetic or optical cards, flash memory, or other type of media / machine - readable medium suitable for storing machine - executable instructions.

Moreover, embodiments may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of one or more data signals embodied in and / or modulated by a carrier wave or other propagation medium via a communication link (e.g., a modem and / or network connection).

Throughout the document, term "user" may be interchangeably referred to as "viewer", "observer", "speaker", "person", "individual", "end - user", and / or the like. It is to be noted that throughout this document, terms like "graphics domain" may be referenced interchangeably with "graphics processing unit", "graphics processor", or simply "GPU" and similarly, "CPU domain" or "host domain" may be referenced interchangeably with "computer processing unit", "application processor", or simply "CPU".

It is to be noted that terms like "node", "computing node", "server", "server device", "cloud computer", "cloud server", "cloud server computer", "machine", "host machine", "device", "computing device", "computer", "computing system", and the like, may be used interchangeably throughout this document. It is to be further noted that terms like "application", "software application", "program", "software program", "package", "software package", and the like, may be used interchangeably throughout this document. Also, terms like "job", "input", "request", "message ", and the like, may be used interchangeably throughout this document.

<FIG> is a flow diagram illustrating an embodiment of a method <NUM> for a microservice-level implementation of matchmaking-based enhanced debugging for microservices architectures. Method <NUM> may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, etc.), software (such as instructions run on a processing device), or a combination thereof. More particularly, the method <NUM> may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium (also referred to herein as a non-transitory computer-readable storage medium) such as RAM, ROM, PROM, firmware, flash memory, etc., in configurable logic such as, for example, PLAs, FPGAs, CPLDs, in fixed-functionality logic hardware using circuit technology such as, for example, ASIC, CMOS or TTL technology, or any combination thereof.

The process of method <NUM> is illustrated in linear sequences for brevity and clarity in presentation; however, it is contemplated that any number of them can be performed in parallel, asynchronously, or in different orders. Further, for brevity, clarity, and ease of understanding, many of the components and processes described with respect to <FIG> may not be repeated or discussed hereafter. In one implementation, a datacenter system implementing a sidecar in a microservice container, such as processing device executing a sidecar <NUM> of microservice container <NUM> of service platform <NUM> of <FIG>, may perform method <NUM>.

The example process of method <NUM> of <FIG> begins at block <NUM> where a processing device executing the sidecar may detect, by an anomaly detector of the sidecar of the microservice container, an anomaly in telemetry data generated by the microservice. In one implementation, the microservice part of a service of an application hosted by a datacenter system. At block <NUM>, the processing device may enable, by an enhanced debug and trace component of the sidecar, a debug mode in the microservice, where the debug mode based on a type of the anomaly.

Subsequently, at block <NUM>, the processing device may collect, by the enhanced debug and trace component, a target set of data points generated by the microservice. In one implementation, the debug mode is dynamically adaptable to scale up or scale down the amount of data points collected based on the type of anomaly and service level agreements corresponding to the microservice. At block <NUM>, the processing device may process, by the enhanced debug and trace component, the collected target set of data with a matchmaking process to generate timestamps, tag for context, and sign each data point of the collected set of data. Lastly, at block <NUM>, the processing device may make, by the enhanced debug and trace component, the processed data available to a global agent for the service for analysis of the anomaly in view of full context of the service.

<FIG> is a flow diagram illustrating an embodiment of a method <NUM> for a service-level implementation of matchmaking-based enhanced debugging for microservices architectures. Method <NUM> may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, etc.), software (such as instructions run on a processing device), or a combination thereof. More particularly, the method <NUM> may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium (also referred to herein as a non-transitory computer-readable storage medium) such as RAM, ROM, PROM, firmware, flash memory, etc., in configurable logic such as, for example, PLAs, FPGAs, CPLDs, in fixed-functionality logic hardware using circuit technology such as, for example, ASIC, CMOS or TTL technology, or any combination thereof.

The process of method <NUM> is illustrated in linear sequences for brevity and clarity in presentation; however, it is contemplated that any number of them can be performed in parallel, asynchronously, or in different orders. Further, for brevity, clarity, and ease of understanding, many of the components and processes described with respect to <FIG> may not be repeated or discussed hereafter. In one implementation, a datacenter system implementing a service management component of a service platform, such as a processing device executing a service management component <NUM> of service platform <NUM> of <FIG>, may perform method <NUM>.

The example process of method <NUM> of <FIG> begins at block <NUM> where the processing device may generate, by a global enhanced debug and trace component of a service, a configuration overview of the service. In one implementation, the configuration overview can detail hardware and software components of deployed microservices of the service and interactions between the deployed microservices. At block <NUM>, the processing device may detect an anomaly in the service.

Subsequently, at block <NUM>, the processing device may identify, based on the detected anomaly, a set of microservices to enable a debug mode, the set of microservices identified based on the configuration overview. At block <NUM>, the processing device may communicate with the set of microservices to cause the debug mode to be enabled in the set of microservices. In one implementation, the debug mode can be enabled at different levels in the set of microservices based on a type of the anomaly and an SLA of the service.

Then, at block <NUM>, the processing device may receive processed debug and trace data from the set of microservice, the processed debug and trace data generated during the debug mode and processed with a matchmaking process at the set of microservices. In one implementation, the matchmaking process can attach timestamp and context tags to the processed debug and trace data. Lastly, at block <NUM>, the processing device may perform a global analysis of the anomaly for the service based on the processed debug and trace data received from the set of microservices and based on the configuration overview.

<FIG> is a schematic diagram of an illustrative electronic computing device <NUM> to enable matchmaking-based enhanced debugging for microservices architectures, according to some embodiments. In some embodiments, the computing device <NUM> includes one or more processors <NUM> including one or more processor cores <NUM> including an enhanced debug/trace component (EDTC) <NUM>, such as an enhanced debug/trace component <NUM>, <NUM>, <NUM> described with respect to <FIG> and <FIG>. In some embodiments, the one or more processor cores <NUM> establish a TEE to host the EDTC <NUM>. In some embodiments, the computing device <NUM> includes a hardware accelerator <NUM>, the hardware accelerator <NUM> including an enhanced debug/trace component <NUM>, such as enhanced debug/trace component <NUM>, <NUM>, <NUM> described with respect to <FIG> and <FIG>. In some embodiments, the hardware accelerator <NUM> establishes a TEE to host the enhanced debug/trace component <NUM>. In some embodiments, the computing device is to provide matchmaking-based enhanced debugging for microservices architectures, as provided in <FIG>.

The computing device <NUM> may additionally include one or more of the following: cache <NUM>, a graphical processing unit (GPU) <NUM> (which may be the hardware accelerator in some implementations), a wireless input/output (I/O) interface <NUM>, a wired I/O interface <NUM>, system memory <NUM> (e.g., memory circuitry), power management circuitry <NUM>, non-transitory storage device <NUM>, and a network interface <NUM> for connection to a network <NUM>. The following discussion provides a brief, general description of the components forming the illustrative computing device <NUM>. Example, non-limiting computing devices <NUM> may include a desktop computing device, blade server device, workstation, or similar device or system.

In embodiments, the processor cores <NUM> are capable of executing machine-readable instruction sets <NUM>, reading data and/or instruction sets <NUM> from one or more storage devices <NUM> and writing data to the one or more storage devices <NUM>. Those skilled in the relevant art can appreciate that the illustrated embodiments as well as other embodiments may be practiced with other processor-based device configurations, including portable electronic or handheld electronic devices, for instance smartphones, portable computers, wearable computers, consumer electronics, personal computers ("PCs"), network PCs, minicomputers, server blades, mainframe computers, and the like.

The processor cores <NUM> may include any number of hardwired or configurable circuits, some or all of which may include programmable and/or configurable combinations of electronic components, semiconductor devices, and/or logic elements that are disposed partially or wholly in a PC, server, or other computing system capable of executing processor-readable instructions.

The computing device <NUM> includes a bus or similar communications link <NUM> that communicably couples and facilitates the exchange of information and/or data between various system components including the processor cores <NUM>, the cache <NUM>, the graphics processor circuitry <NUM>, one or more wireless I/O interfaces <NUM>, one or more wired I/O interfaces <NUM>, one or more storage devices <NUM>, and/or one or more network interfaces <NUM>. The computing device <NUM> may be referred to in the singular herein, but this is not intended to limit the embodiments to a single computing device <NUM>, since in certain embodiments, there may be more than one computing device <NUM> that incorporates, includes, or contains any number of communicably coupled, collocated, or remote networked circuits or devices.

The processor cores <NUM> may include any number, type, or combination of currently available or future developed devices capable of executing machine-readable instruction sets.

The processor cores <NUM> may include (or be coupled to) but are not limited to any current or future developed single- or multi-core processor or microprocessor, such as: on or more systems on a chip (SOCs); central processing units (CPUs); digital signal processors (DSPs); graphics processing units (GPUs); application-specific integrated circuits (ASICs), programmable logic units, field programmable gate arrays (FPGAs), and the like. Unless described otherwise, the construction and operation of the various blocks shown in <FIG> are of conventional design. Consequently, such blocks are not described in further detail herein, as they can be understood by those skilled in the relevant art. The bus <NUM> that interconnects at least some of the components of the computing device <NUM> may employ any currently available or future developed serial or parallel bus structures or architectures.

The system memory <NUM> may include read-only memory ("ROM") <NUM> and random access memory ("RAM") <NUM>. A portion of the ROM <NUM> may be used to store or otherwise retain a basic input/output system ("BIOS") <NUM>. The BIOS <NUM> provides basic functionality to the computing device <NUM>, for example by causing the processor cores <NUM> to load and/or execute one or more machine-readable instruction sets <NUM>. In embodiments, at least some of the one or more machine-readable instruction sets <NUM> cause at least a portion of the processor cores <NUM> to provide, create, produce, transition, and/or function as a dedicated, specific, and particular machine, for example a word processing machine, a digital image acquisition machine, a media playing machine, a gaming system, a communications device, a smartphone, or similar.

The computing device <NUM> may include at least one wireless input/output (I/O) interface <NUM>. The at least one wireless I/O interface <NUM> may be communicably coupled to one or more physical output devices <NUM> (tactile devices, video displays, audio output devices, hardcopy output devices, etc.). The at least one wireless I/O interface <NUM> may communicably couple to one or more physical input devices <NUM> (pointing devices, touchscreens, keyboards, tactile devices, etc.). The at least one wireless I/O interface <NUM> may include any currently available or future developed wireless I/O interface. Example wireless I/O interfaces include, but are not limited to: BLUETOOTH®, near field communication (NFC), and similar.

The computing device <NUM> may include one or more wired input/output (I/O) interfaces <NUM>. The at least one wired I/O interface <NUM> may be communicably coupled to one or more physical output devices <NUM> (tactile devices, video displays, audio output devices, hardcopy output devices, etc.). The at least one wired I/O interface <NUM> may be communicably coupled to one or more physical input devices <NUM> (pointing devices, touchscreens, keyboards, tactile devices, etc.). The wired I/O interface <NUM> may include any currently available or future developed I/O interface. Example wired I/O interfaces include, but are not limited to: universal serial bus (USB), IEEE <NUM> ("FireWire"), and similar.

The computing device <NUM> may include one or more communicably coupled, non-transitory, data storage devices <NUM>. The data storage devices <NUM> may include one or more hard disk drives (HDDs) and/or one or more solid-state storage devices (SSDs). The one or more data storage devices <NUM> may include any current or future developed storage appliances, network storage devices, and/or systems. Non-limiting examples of such data storage devices <NUM> may include, but are not limited to, any current or future developed non-transitory storage appliances or devices, such as one or more magnetic storage devices, one or more optical storage devices, one or more electro-resistive storage devices, one or more molecular storage devices, one or more quantum storage devices, or various combinations thereof. In some implementations, the one or more data storage devices <NUM> may include one or more removable storage devices, such as one or more flash drives, flash memories, flash storage units, or similar appliances or devices capable of communicable coupling to and decoupling from the computing device <NUM>.

The one or more data storage devices <NUM> may include interfaces or controllers (not shown) communicatively coupling the respective storage device or system to the bus <NUM>. The one or more data storage devices <NUM> may store, retain, or otherwise contain machine-readable instruction sets, data structures, program modules, data stores, databases, logical structures, and/or other data useful to the processor cores <NUM> and/or graphics processor circuitry <NUM> and/or one or more applications executed on or by the processor cores <NUM> and/or graphics processor circuitry <NUM>. In some instances, one or more data storage devices <NUM> may be communicably coupled to the processor cores <NUM>, for example via the bus <NUM> or via one or more wired communications interfaces <NUM> (e.g., Universal Serial Bus or USB); one or more wireless communications interfaces <NUM> (e.g., Bluetooth®, Near Field Communication or NFC); and/or one or more network interfaces <NUM> (IEEE <NUM> or Ethernet, IEEE <NUM>, or Wi-Fi®, etc.).

Processor-readable instruction sets <NUM> and other programs, applications, logic sets, and/or modules may be stored in whole or in part in the system memory <NUM>. Such instruction sets <NUM> may be transferred, in whole or in part, from the one or more data storage devices <NUM>. The instruction sets <NUM> may be loaded, stored, or otherwise retained in system memory <NUM>, in whole or in part, during execution by the processor cores <NUM> and/or graphics processor circuitry <NUM>.

The computing device <NUM> may include power management circuitry <NUM> that controls one or more operational aspects of the energy storage device <NUM>. In embodiments, the energy storage device <NUM> may include one or more primary (i.e., nonrechargeable) or secondary (i.e., rechargeable) batteries or similar energy storage devices. In embodiments, the energy storage device <NUM> may include one or more supercapacitors or ultracapacitors. In embodiments, the power management circuitry <NUM> may alter, adjust, or control the flow of energy from an external power source <NUM> to the energy storage device <NUM> and/or to the computing device <NUM>. The power source <NUM> may include, but is not limited to, a solar power system, a commercial electric grid, a portable generator, an external energy storage device, or any combination thereof.

For convenience, the processor cores <NUM>, the graphics processor circuitry <NUM>, the wireless I/O interface <NUM>, the wired I/O interface <NUM>, the storage device <NUM>, and the network interface <NUM> are illustrated as communicatively coupled to each other via the bus <NUM>, thereby providing connectivity between the above-described components. In alternative embodiments, the above-described components may be communicatively coupled in a different manner than illustrated in <FIG>. For example, one or more of the above-described components may be directly coupled to other components, or may be coupled to each other, via one or more intermediary components (not shown). In another example, one or more of the above-described components may be integrated into the processor cores <NUM> and/or the graphics processor circuitry <NUM>. In some embodiments, all or a portion of the bus <NUM> may be omitted and the components are coupled directly to each other using suitable wired or wireless connections.

Claim 1:
A method comprising:
detecting, by an anomaly detector in a sidecar of a microservice, an anomaly in telemetry data generated by the microservice, the microservice is hosted in a container executed by a processor and is part of a service of an application;
enabling, by an enhanced debug and trace component of the sidecar, a debug mode in the microservice;
collecting, by the enhanced debug and trace component, a target set of data points generated by the microservice;
processing, by the enhanced debug and trace component, the target set of data points with a matchmaking process to generate a timestamp and a tag for a context for each data point of the target set of data points; and
making, by the enhanced debug and trace component, the target set of data points processed with the matchmaking process available to a global agent of the service for analysis of the anomaly;
characterized in that
the debug mode is based on a type of the anomaly.