To make distributed tracing better, it must be useful and accessible.
How do we make distributed tracing useful?
For engineering organizations to realize the full potential of trace data, engineers have to use it. Any calculation that attempts to measure the value of tracing is going to include some measure of breadth of use or the number of engineers who regularly use trace data.
The obvious answer to this question is to build a solution that has two different modes of operations: One that can meet the needs of both advanced power users and casual users.
Of course this is easier said than done. A truly valuable distributed tracing product must harness the workflows and insights of your expert users to deliver more “out of the box” value for the casual users. The ideal environment will offer a standard UI/UX across the organization, but enough customization options so power users can extract the insights they need.
How do we make trace data accessible?
Trace data can, and should be, integrated into workflows that matter to engineers whether that be making alert notifications more actionable (including where to route them) or providing service dependency data alongside dashboards responsible for that service.
Trace data isn’t valuable if it’s inaccessible. Every engineer in the organization must have easy access to trace data setup in tools they already work with on a regular basis. For a huge portion of software developers, that ends up being good old reliable dashboards.
Dashboards historically are the visualization of metric time series as line charts, gauges, and bar graphs. But engineering teams shouldn’t limit themselves to just displaying metrics; they can absolutely use dashboards to display insights from trace and other observability data types.