Don’t observe. Debug.
The term “observability” is a strange one. We understand its value as a way to describe a sophisticated approach to monitoring complex distributed systems and microservices. But the term is inherently passive (and let’s be honest. It’s a bit of a loaded marketing term). Simply “observing” doesn’t help you solve problems – especially if you are inundated with loads of non-actionable data. We built Sentry to help developers take action and solve bugs, errors, and other issues, and that’s the philosophy we carried into our approach to building observability tooling: a new spans-first tracing and metrics experience. Both are now in open beta and we want your feedback.
A new spans-first tracing experience
Debugging distributed systems (including microservices) is hard because you need to diagnose issues across a complex and interconnected environment. If users are experiencing delays when placing orders on your e-commerce app, for example, you have to check multiple services (potentially the user service, the order service, the payment service, and the inventory service) to figure out the root cause, which makes the debugging process complex and time-consuming. Debugging fullstack apps can present similar challenges when an issue can originate in either the frontend or backend of an application.
Tracing is powerful because it tracks the complete, end-to-end path of a request from the originating user interaction across systems and services to pinpoint the specific operation causing the problem. Tracing should be part of every developer’s debugging toolkit.
To make tracing more accessible and effective, we built a new, span-based tracing model. Previously, in an effort to simplify the experience, we built tracing on a transaction-based model (a transaction is composed of multiple spans, which are the atomic units of work taking place on a service. For example, a web server responding to an HTTP request or a single invocation of a function would be a span. You can read more on tracing here). Our transaction-based model, however, made it challenging to query critical information like database queries and network requests, which are represented using spans. In our new model, where spans are the primary tracing unit, you can query critical data and easily drill down into root causes.
Investigate known problems using the Trace Explorer
We have always automatically linked traces to issues, and now you can also proactively identify issues by searching for a specific trace using specific span attributes. For example, if a user complained about a slow loading page or a partner API has reported an outage, now you can query by user email, API endpoint, or route to find the trace with the right context to fix the issue faster.
Imagine that a user has reported that your checkout experience is slow. You can find specific traces by searching for spans using high cardinality data, including custom and out-of-the-box tags like user ID and span description.
Debug faster with full context
From the Trace Explorer you can click on a queried trace or a specific span to go directly to the redesigned Trace View, where you have everything you need to debug an issue at your fingertips.
The waterfall view provides full visibility of application requests from frontend to backend and across services. When you drill into a specific span, you get pertinent context and granular data for efficient debugging, including custom tags, profiles, and replays.
Metrics are also available in the Trace View, giving you an additional source of contextual information to help debug.
Get started
Once you have a Sentry account, getting started with Tracing is easy. Just follow the instructions in our docs to start sending spans.
Get help and give feedback
Keep in mind that we’re actively working on these new features while in beta. There is a good chance we make a few changes to how they work - for the better, of course. If you have thoughts and feedback, please find us on GitHub or tell us what you think in Discord.
