DEV Community

Max
Max

Posted on

Why Does Debugging One OpenTelemetry Trace Feel So Complicated?

#opentelemetry #vscode #observability #programming

Why Does Debugging One OpenTelemetry Trace Feel So Complicated?

When working with OpenTelemetry, one thing always bothered me during local development.

I would make a small change, run the application, generate a request, and then realize I needed to start additional infrastructure just to inspect a trace.

A typical local setup often looked like this:

Application
    │
    ▼
OpenTelemetry SDK
    │
    ▼
OpenTelemetry Collector
    │
    ▼
Jaeger / Zipkin / Grafana / Vendor Backend
Enter fullscreen mode Exit fullscreen mode

There is absolutely nothing wrong with this architecture. It's designed for production observability and scales well.

But for local development, I usually wasn't trying to monitor an entire distributed system.

I simply wanted answers to questions like:

  • Did my span get created?
  • Why is this request slow?
  • Which service made this database call?
  • What logs belong to this trace?
  • Why didn't this metric get exported?

Starting multiple services just to answer those questions felt like unnecessary friction.

The idea

That led me to build OpenTelemetry for VS Code.

Instead of sending telemetry to an external backend, the extension embeds an OTLP receiver directly inside VS Code.

Applications can export telemetry directly to the editor, where it can be inspected immediately.

No Jaeger.

No Zipkin.

No OpenTelemetry Collector.

No Docker containers.

Just start the receiver, run your application, and begin debugging.

What the extension can do

The extension currently provides:

  • Embedded OTLP receiver supporting both gRPC and HTTP
  • Log viewer with filtering and search
  • Navigate directly from logs to source code
  • Distributed trace viewer with waterfall visualization
  • Metrics explorer
  • Service dependency map
  • Automatic OTLP endpoint injection for applications launched from VS Code
  • Instrumentation snippets for Java, .NET, Go, Node.js, Python, Rust, and other OTLP-compatible SDKs

It also works well with .NET Aspire, allowing Aspire applications to export telemetry directly into VS Code for local debugging.

Why keep everything inside the editor?

One of the biggest advantages is context.

Instead of constantly switching between your IDE, browser, dashboards, and terminals, everything is available in one place.

A typical workflow becomes:

  1. Start debugging.
  2. Generate a request.
  3. Open the trace waterfall.
  4. Find the slow or failing span.
  5. Inspect related logs.
  6. Jump directly to the source code.
  7. Fix the issue.
  8. Run again.

Keeping the feedback loop inside the editor makes local debugging much faster.

This isn't a replacement for production observability

Production platforms like Jaeger, Grafana, Tempo, Azure Monitor, and others solve a very different problem.

They provide long-term storage, distributed analysis, alerting, dashboards, and team collaboration.

This extension focuses on a different use case:

Making local development and debugging as simple as possible.

What's next?

I'm currently exploring features such as:

  • Persistent storage
  • Live telemetry streaming
  • Metric charts
  • More advanced search and filtering
  • Richer service-map analytics
  • Trace comparison
  • Exporting collected telemetry

I'm also interested in hearing what the community would find most useful.

I'd love your feedback

If you're using OpenTelemetry—or especially if you're working with .NET Aspire—I'd love to know how you currently debug telemetry during development.

Does your workflow involve a Collector and Jaeger?

Do you use the Aspire dashboard?

Would an IDE-native experience fit into your daily workflow?

The project is open source, and feedback, issues, and contributions are always welcome.

GitHub: https://github.com/sukanta1991/opentelemetry

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=SukantaSaha.opentelemetry

Top comments (0)