BACKGROUND

Computer systems may run applications or services that are provided via a server or cloud. A client computer system may send a request to a server that retrieves application installation files in an underlying database. The applications or services can be developed and deployed as a single unit or as multiple units, such as a collection of microservices. Applications that are developed as single unit may be a monolithic application that includes a user interface and data access codes combined into a single program from a single platform. Monolithic applications are self-contained and independent from other computing applications. With the advent of cloud computing, however, these large centralized monolithic systems are being decoupled and distributed to address scalability needs and to allow companies to deliver value faster.

Microservices or microservice architecture is a software development method of developing software applications as a suite of independently deployable smaller cooperating services. The cooperating services run processes and communicate to serve a business goal to form an enterprise application. More specifically, in a microservice architecture, an application is developed as a collection of small services; each service implements business capabilities, runs in its own process and communicates via APIs (e.g., HTTP APIs) or messaging. Each microservice can be deployed, upgraded, scaled, and restarted independent of other services in the application, typically as part of an automated system, enabling frequent updates to live applications without impacting end customers.

With the rise of cloud native applications, which include microservices, there has been not only a shift in the manner in which software is built and deployed, but also in the manner in which it is monitored and observed. Microservices based applications have to deal with dramatically increased complexity and many more layers of abstraction compared to previous generations of monolithic applications. Compared to monolithic applications, microservice architectures introduce complexity in network communication, feature short lifecycles, and require resiliency in dynamic environments.

As companies begin to increasingly rely on microservice architectures, they run into operational complexity and struggle to efficiently monitor their environments. One of the challenges associated with microservice architectures, for example, is getting visibility in distributed workflows without a central orchestrator. Traditional monitoring and troubleshooting tools, designed as symptom-based solutions with single purpose capabilities, result in information overload and are unable to keep up with the dynamic nature of cloud native applications. Thus, systems that can efficiently and accurately monitor microservice architectures and microservices based applications are the subject of considerable innovation.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

The challenges associated with monitoring, troubleshooting and tracking errors in microservice architectures has led to the rise of distributed tracing, which deals with tracing user requests through applications that are distributed. One of the challenges in implementing microservice observability with distributed tracing systems is pinpointing where errors originated or determining the root cause of an error. In a microservice architecture, an error associated with a particular request may originate in one of the services and might manifest as errors across all the services that participate in that request. Conventional tracing and monitoring systems are unable to systematically track the causal chain of events that result in an error or degraded response in a distributed system.

Embodiments of the present invention allow clients of a monitoring platform to track the causal chain of operations that resulted in an error or possibly a degraded response being returned to a client in response to a request. In order to track the causal chain of operations, the monitoring platform may utilize distributed error stacks. A distributed error stack (also referred to as a “trace error signature”) is a type of signature that summarizes a causal chain of operations encountered during trace execution that resulted in an error, and, further, also summarizes information pertaining to the root cause of the error. Capturing summary information for a causal chain of operations that followed from a root cause originating the error using a distributed error stack provides an application developer insight into types of errors occurring in the environment and helps assess impact.

In one or more embodiments, in order to generate distributed error stacks, the monitoring platform needs to keep track of and summarize the errors generated by the various services in a microservices-based application for discrete ranges of time. For each trace, the monitoring platform first identifies one or more root cause error spans belonging to a single trace. A trace corresponds to a user request and is comprised of one or more spans that are generated as the request propagates from one service to the next in response to calls made by the services in a distributed application. One or more of those spans may return an error to a caller service and is considered an “error span,” and, further, one or more of the error spans may be a “root cause error span,” which is an error span that is associated with the error originator.

In one or more embodiments, having determined a root cause error span, the monitoring platform determines a call path associated with it. The call path comprises a chain of spans (associated with calls made by services in the application) starting at the root cause error span, where each subsequent span in the chain is a parent span of a prior span in the chain.

In one or more embodiments, having determined the call path, the monitoring platform may create a distributed error stack by mapping each span in the chain to a span error frame that comprises summary information for an associated span. The distributed error stack comprises a stack of span error frames where the top-most frame is associated with the root cause error span (which corresponds to the error originator).

In an embodiment, a visual representation of the distributed error stack is rendered and presented to a client through a graphical user interface (GUI), which allows a client to efficiently determine the micro-service that the error originated in and the call path that the error propagated through before ultimately reaching the user (either as an error or a degraded response to a user-request).

According to one or more embodiments of the present disclosure, a method is provided for performing error analysis in a computer system comprising microservices. The method comprises identifying a root cause error span from a plurality of error spans of a trace, wherein an error span is a span that returns an error to a microservice that generates the span, and wherein a root cause error span is an error span associated with a microservice that originated the error. The method also comprises determining a call path associated with the root cause error span, wherein the call path comprises a chain of spans starting at the root cause error span, and wherein each subsequent span in the chain is a parent span of a prior span in the chain. Further, the method comprises mapping each span in the chain to a span error frame to create an error stack from the chain of spans. The method also comprises rendering an image of the error stack for display within a graphical user interface, wherein the image is operable to indicate the microservice that originated the error.

