Operations | Monitoring | ITSM | DevOps | Cloud

Ah, good question! TL;DR: Trace instead of log. Traces show connection, performance, concurrency, and causality. Logs are the original observability, right? Back in the day, I did all my debugging with `printf.` Sometimes I still write `console.log(“JESS WAS HERE”)` to see that my code ran. That’s instrumentation, technically. What if I emitted a “JESS WAS HERE” span instead? What’s so great about a span in a trace? Yeah, and so do logs in any decent framework.

Your applications most likely consist of multiple components. These components could be written in different languages, with each individually instrumented with Sentry’s SDK. The goal of our tracing solution is to make sure developers get a full picture of the data captured within their tech stack. Tracing allows you to follow a request from the frontend all the way to your backend application and back.

Before we dive into the Collector, let’s cover the components that make up the OpenTelemetry project. If you missed it, our post What is OpenTelemetry gives a high level introduction to OpenTelemetry and the key components of OpenTelemetry project: The OpenTelemetry collector is optional when using a SaaS service like Scout. Even so, knowing what the Collector can do and when to use it is helpful to understand.

Distributed tracing is a household term nowadays – if your house is an IT department! Modern enterprises use cloud-native applications for agility and responsiveness to customer needs. When monitoring cloud-native applications, distributed tracing follows how transactions perform while traversing services or containers in the backend architecture. By definition, we’re describing production applications with requests, methods, database calls and logs that accompany a transaction.