What Does a Good Trace Look Like?

At Honeycomb, we’ve made a name for ourselves in distributed tracing—and as such, we’re often asked what a good trace looks like. It’s not an easy question to answer, because everyone’s application is different and the user experience changes drastically from one application to the next.

Any generic trace can answer how slow a request was or when the first error occurred. We want better than generic tracing though—we want good tracing, because we want to know which customer had a slow experience, which account had fraudulent levels of activity, or which product keys returned errors. The theme here is we want specifics. And while we may not be able to tell you exactly what fields to put in your traces, we can give you general philosophical advice on what a good trace looks like. In this guide, you'll learn:

• The characteristics of a good trace
  • We'll take you through an example, using art
• Why traces should describe application events as richly as possible
  • How you can leverage BubbleUp to see correlations
  • Why you should go beyond automatic instrumentation
  • How yes, there is such a thing as too much detail
• Why we don't subscribe to traces as a "pillar" of observability
• Why traces are all you really need
• and more!