This is an article from DZone’s 2022 Performance and Site Reliability Trend Report.
For more:
Distributed tracing, as the name suggests, is a method of tracking requests as it flows through distributed applications. Along with logs and metrics, distributed tracing makes up the three pillars of observability. While all three signals are important to determine the health of the overall system, distributed tracing has seen significant growth and adoption in recent years.
When we build a microservice architecture and the number of services keeps growing, we face the problem of debugging and tracing requests through our entire system. What happened when a user got a 500 error on his request? What service incorrectly processed his request? All these questions can be solved by the Distributed Tracing System. Let’s take Spring Cloud Sleuth as an example.
To trace a request through a distributed system, the concepts TraceID and SpanID are introduced. TraceID is generated when a request enters our system and remains unchanged throughout its path. SpanID changes as the request passes from one service to another. If necessary, it is possible to generate new spans within one service to distinguish business processes.
With the ecosystem being extremely saturated with a diversity of tools such as monitoring, observability, tracing, logging, and much more, it’s hard to truly understand how troubleshooting differs from these typical tools.
Today, when incidents occur, it is becoming increasingly complex to get a grasp on where to even get started with understanding what you’re up against, and then ultimately fixing the immediate issue, and then remediating the root cause.
Tye is an experimental dotnet tool from Microsoft that aims to make developing, testing, and deploying microservices easier. Tye’s opinionated nature greatly simplifies the lifecycle of development and deployment of .NET Core microservices.
To understand the benefits of Tye, let’s enumerate the steps involved in the development and deployment of the DCalculator application to Kubernetes:
While developing applications using Spring batch, especially in a micro-service project, we sometimes face one or most of the following cases:
The following schema illustrates remote calls that can be performed in a micro-service-based application and the context information that String Batch items can propagate.
If you’re paying attention to anything that’s happening in the development world, you’re likely familiar with the term “observability.” We’re seeing more and more monitoring companies from all different backgrounds jumping on the term to describe their solutions, many claiming their observability tool to be the factor that will take businesses to the next level.
Growing out-of-control system engineering, observability allows dev teams to unify and study the behaviors of various IT systems through the external outputs of the internal systems. In the case of software, that’s log events, distributed tracing, and time-series metrics. By unifying the data streaming through today’s complex IT environments, it certainly gives SREs and DevOps practitioners a leg up from traditional monitoring. But the data alone is no longer enough.
When I first started following Charity on Twitter back in early 2019, I was quickly overwhelmed by the new words and concepts she was discussing. I liked the results she described: faster debugging, less alert fatigue, happier users. Those are all things I wanted for my team! But I was hung up on these big polysyllabic words, which stopped me from taking those first steps toward improving our own observability.
This post is my attempt to help orient folks who want to learn more about observability but maybe feel overwhelmed or intimidated by the vocabulary list, like I did. My goal is to get everyone on the same page about what these words mean so that we can focus on leveraging the tools and ideas to build better software and deliver more value!
