Everyone needs to know how to trace

It’s a bold claim for me to say that every developer can benefit from something 40% of them haven’t heard of, but hear me out. I was among the 40% who didn’t know tracing existed until this summer. Still, I spent the last three months learning why it’s critical to a developer’s workflow and the different ways developers pragmatically use it. In this blog, I hope to show you that you can benefit from tracing regardless of your stack, role, size, or project.

What is Tracing?

Tracing is the process of tracking the flow of execution within an application, especially in distributed systems or microservices. It enables developers to monitor requests as they move through various services and components, providing detailed insights into performance, bottlenecks, and errors. By capturing data at each step, tracing helps pinpoint the root cause of issues and ensures a clear understanding of how different parts of the system interact.

Tracing in Sentry is a tool used to record the operations of your code across your frontend and backend, and between services. A trace consists of atomic units called spans, which provide granular details of what’s happening behind the scenes of every larger action. For example, if a trace shows a page load, the spans would include every database query, API request, and asset loaded. Sentry’s Trace View has the tools and information developers need to quickly identify and debug issues, but we’ll talk about that in more detail soon. Now that you’ve joined the 60% of developers who know that tracing exists let me onboard you to the 30% who actively use it to make their debugging process faster and simpler.

Identifying elusive performance issues with tracing

While tracing can help you debug in several ways, it’s particularly useful for finding the root cause of performance issues that aren’t obvious when locally debugging or sifting through logs. The nature of tracing makes investigating and debugging performance bottlenecks across distributed systems straightforward, highlighting common oversights and poorly performing spans. There are generally two situations in which you’ll look to tracing to help you improve the performance of your web app.

Investigating reported issues

When building products, there’s going to come a time when a page on your site takes too long to load. That realization will usually come from dogfooding your own project or your users letting you know. Fixing known performance errors is important in keeping your app fresh and your users engaged, but If you’re in that 70% not yet using tracing, your current debugging workflow probably has a lot of unnecessary friction. Trying to get a video reproduction out of a user or trying to reproduce the issue locally from a description can be impossible. Sentry helps remove all this friction by giving you the users’ feedback, session replay, and traces in a connected view, so you don’t have to fight for reproduction details.

Proactive debugging with tracing

While a reported issue affecting many users will generally take precedence, proactively fixing your apps is an equally important practice for shipping high-quality code that won’t be due for a refactor in a week. As with the example above, checking in on your app’s performance and making small fixes before they become big problems is an incredibly hard problem when you don’t have the means of analyzing granular data. Luckily, the same Trace View that helped you resolve your reported issue can highlight things your users didn’t catch, like repeat queries.

One of our engineers at Sentry was passively digging around for ways to improve the performance of an API call, and when he checked out the trace, he found six duplicate queries. Under normal circumstances, this error would likely have remained unknown. However, Sentry’s grouping of the repeated spans meant that this fix was simply a matter of glossing over the trace, seeing where you went wrong, and making a small tweak in the code to avoid it. While an individual user might not notice the speed improvement, these small fixes (made trivial with tracing) will help lower your serverless bill and keep you from getting rate-limited.

In my eyes, using tracing to fix performance issues should already encompass all developers. Still, I can recognize that there are situations in which the complexity and scale of your app haven’t reached a point that calls for performance optimization or debugging beyond your browser’s dev tools.

Debugging non-performance issues

Okay, so performance isn’t a big deal to you (who cares about Google rankings anyway), that’s fine. But what if your users are getting errors and their sessions are crashing? Can you sit back and sip your latte while watching the new fireship video? If so, I applaud your serenity, but I tend to believe that issues causing your users to churn are a sufficiently urgent reason to get down to debugging. Like before, though, a user tweeting that your site is down or you see a stream of 500 errors in your logs is generally not enough to figure out why it’s happening. Tracing in Sentry will once again come to your rescue in helping resolve important issues that might not be from obvious sources.

Finding the root cause of an error

The Issues page on Sentry is a great place to start (and often finish) investigating a bug that crashed your app. With source maps uploaded, you’ll get a detailed stack trace showing where your app crashed and some surrounding context. However, in certain architectures, the code that threw the error is only sometimes the origin of the issue.

In distributed systems and microservices, data is passed across multiple projects and languages, usually managed by many siloed-off teams. These architectures make it hard to ensure data consistency at each step. For example, a variable might have been altered 10 requests back and passed through several different code bases without issue until it’s eventually needed and fails validation, causing an error. In this case, tracing in Sentry can help you identify the actual source of the problem by looking back at earlier calls and data passed during the session (data that can be attached to traces with added context).

Learning an unfamiliar codebase

Let’s say we live in some utopia where your website is performant and your code works perfectly. I still have a reason for you to learn how to trace. That being, it’s an amazing way to quickly understand how unfamiliar systems work at a low level without combing through some spaghetti code an ex-coworker wrote on a stone tablet. Instead of taking a week to set up a dev environment of a codebase you’ll never touch, just look through recent traces to understand how data moves through the system and how user experience is impacted. Couple this with profiling in Sentry, and you’ll quickly understand the granular details of an unfamiliar codebase without ever having to open a text editor.

Get started with tracing

If you’re still not convinced you need tracing, DM me the link to your website so I know to avoid it. Otherwise, check out these resources to get started with tracing.

(Note: Depending on your stack, you can also select a different framework or language.)

• [Docs] Set up Tracing with the JavaScript SDK
• [Docs] Set up Trace Propagation (i.e. Distributed Tracing)
• [Blog] See how Dan Mindru cut 22.3 seconds off an API call with the Trace View
• [Blog] Learn how to debug slow pages caused by slow backends

Want to stay up-to-date on the latest from Sentry? Check out our changelog for a running list of all product and feature releases. You can also connect with us on GitHub, Twitter, or Discord. And if you’re new to Sentry, you can try it for free today or request a demo to get started.