We reach 85,000 developers weekly

O’Reilly said it best this year when they summarized learning trends in 2021:

Observability saw the greatest growth in the past year (128%), while monitoring is only up 9%. While observability is a richer, more powerful capability than monitoring — observability is the ability to find the information you need to analyze or debug software, while monitoring requires predicting in advance what data will be useful — we suspect that this shift is largely cosmetic. “Observability” risks becoming the new name for monitoring. And that’s unfortunate. If you think observability is merely a more fashionable term for monitoring, you’re missing its value.

We can’t lose sight of that value. We can’t afford to. This isn’t just a tale of vendors arguing to define marketing terms for their own benefit. The pain and suffering that people endure every day because they can’t understand their own damn systems is too real. The long hours, the toil, the greasy hacks moldering away into technical debt, the late nights, the missed sleep, the burnout. The pain is real, and the solutions are specific. We need specific, meaningful technical terms to help users navigate the future and find their way to those solutions.

How do you explain a bottleneck in your web stack? Start with learning the ins-and-outs of distributed tracing and how it can help you monitor your increasingly complex full stack apps.

Understanding how a user interaction in the browser cascades into a 500 server error deep in your server stack is challenging. Distributed tracing helps answer these types of questions.

In the early days of the web, writing web applications was simple. Developers generated HTML on the server using a language like PHP, communicated with a single relational database like MySQL, and most interactivity was driven by static HTML form components. While debugging tools were primitive, understanding the execution flow of your code was straightforward.

In today’s modern web stack it’s anything but. Full stack developers are expected to write JavaScript executing in the browser, interop with multiple database technologies, and deploy server side code on different server architectures (e.g. serverless). Without the right tools, understanding how a user interaction in the browser cascades into a 500 server error deep in your server stack is nigh-impossible. Enter: distributed tracing.

This is part 1 in a series from Sentry on distributed tracing.