DEV Community: Max

Stop Spinning Up Jaeger Containers: Debug OTEL Logs, Traces and Metrics Right Inside VS Code

Max — Sun, 20 Sep 2026 07:56:06 +0000

Your laptop is running your application, database, Redis, Kafka, OpenTelemetry Collector, Jaeger, Prometheus and Grafana.

You changed one line of code.

All you wanted was to see the trace.

Why are you running half an observability platform on your laptop?

For local development, OpenTelemetry debugging can be much simpler.

OpenTelemetry for VS Code puts an OTLP receiver directly inside VS Code, so your application can send logs, traces and metrics straight to the editor.

No Jaeger container. No Zipkin. No OpenTelemetry Collector required.

The old local-development workflow

A typical setup can look like this:

Application
    │
    ├── OTLP
    ▼
OpenTelemetry Collector
    │
    ├── Jaeger
    ├── Prometheus
    └── other tooling
             │
             ▼
        Browser dashboards

It works.

But for a developer who simply wants to answer:

"Why did this request fail?"

it's a lot of infrastructure.

You now have containers to start, ports to remember, dashboards to open, and resources consuming your laptop.

The simpler workflow

With OpenTelemetry for VS Code:

Application
     │
     │ OTLP
     ▼
┌──────────────────────────┐
│          VS Code         │
│                          │
│  Logs                    │
│  Traces                  │
│  Metrics                 │
│  Service Map             │
└──────────────────────────┘

The extension runs an embedded OTLP receiver supporting gRPC on 4317 and HTTP on 4318.

It can receive telemetry from applications launched inside VS Code or applications running completely outside it.

And because you're already in VS Code, your telemetry is sitting next to your code.

Install it

Install OpenTelemetry for VS Code from the Marketplace:

OpenTelemetry for VS Code

Or from the terminal:

code --install-extension SukantaSaha.opentelemetry

Open the OpenTelemetry view in VS Code and click Start receiver.

The extension shows the active OTLP endpoints.

Point your application at it

For an OTLP/gRPC exporter, for example:

export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:4317"
export OTEL_EXPORTER_OTLP_PROTOCOL="grpc"

For applications launched from VS Code, the extension can automatically inject the OTLP endpoint into the launch/debug environment.

That's it.

Start your application, generate some traffic, and telemetry starts appearing in VS Code.

Now debug the actual problem

1. Start with traces

Suppose an API request is failing.

Open Traces, filter for errors, select the failed trace and examine the span waterfall.

You can quickly see:

HTTP request
   │
   ├── authentication
   │
   ├── database query       18ms
   │
   ├── payment service      742ms  ← suspicious
   │
   └── response

No need to switch to a separate tracing UI.

The extension supports trace filtering and distributed spans are merged by trace ID.

2. Jump from logs to code

Now open Logs.

Search or filter the telemetry, inspect the relevant record and use Navigate To Code when source-location information is available.

That turns:

"I found an error."

into:

"I found the error and I'm looking at the source line."

The Logs view also supports filtering, sorting, selectable columns and exporting data as OTLP/JSON, JSON or CSV.

3. Check metrics

Then switch to Metrics.

You can inspect gauges, counters/sums and histograms, with graphing and time-series controls available directly in the extension.

So your debugging loop becomes:

Logs
  ↓
Trace
  ↓
Metrics
  ↓
Source code

without leaving VS Code.

4. Understand dependencies

For distributed applications, open the Service Map.

It can infer services, databases, queues and external dependencies from spans.

That gives you a quick picture of:

API
 ├── PostgreSQL
 ├── Redis
 ├── Payment Service
 └── Kafka

again without spinning up another dashboard.

But what about RAM?

This is where the difference becomes interesting.

The extension itself is lightweight — around 5 MB in the measurement used for this example.

A Docker-based local observability setup can be considerably larger.

As an illustrative estimate, a small development stack might look something like:

Setup	Approx. additional memory
VS Code OpenTelemetry extension	~5 MB
Jaeger container	~100–300 MB
OpenTelemetry Collector	~50–150 MB
Prometheus	~100–300+ MB
Grafana	~100–300 MB
Typical multi-container stack	~350–1,000+ MB

Important: These Docker numbers are illustrative ranges, not benchmark measurements. Actual memory usage depends heavily on versions, configuration, telemetry volume, retention and workload.

The important point isn't whether your particular Jaeger container uses 150 MB or 250 MB.

It's this:

Do I really need hundreds of MB of
observability infrastructure...

...to inspect a trace generated
by the application I'm debugging?

For many local debugging scenarios, the answer can be no.

And you can verify it yourself.

Run your normal Docker observability stack and check:

docker stats

Then stop it, run the same workload with the VS Code extension, and compare your system's total memory usage.

Your laptop gets to be the benchmark.

It's not trying to replace your production observability platform

This distinction matters.

Jaeger, Prometheus, Grafana and OpenTelemetry Collector still have important roles in production and team environments.

You may need:

Persistent telemetry storage
Long-term retention
Production-scale ingestion
Team-wide access
Advanced dashboards
Alerting
Centralized observability
Multi-user security and access control

This extension is solving a different problem:

Local developer observability.

When you're writing code and need to inspect the telemetry your application is producing, you may not need an entire observability stack running beside it.

Fewer containers. Fewer tabs. Faster debugging.

The traditional workflow:

Write code
   ↓
Start application
   ↓
Start containers
   ↓
Open Jaeger
   ↓
Find trace
   ↓
Switch back to VS Code
   ↓
Fix code
   ↓
Repeat

The VS Code workflow:

Write code
   ↓
Start application
   ↓
Inspect telemetry
   ↓
Fix code
   ↓
Repeat

Logs. Traces. Metrics. Service relationships. Source code.

All in the same place.

And your laptop doesn't have to run an observability stack just because you wanted to inspect one request.

Give it a try

Install OpenTelemetry for VS Code, point your existing OTLP instrumentation at the local receiver, generate some traffic and start debugging.

If your current local workflow looks like:

App + Docker + Collector + Jaeger + Prometheus + Grafana

try:

App + VS Code

and see how much infrastructure you can remove from your local development loop.

Why Does Debugging One OpenTelemetry Trace Feel So Complicated?

Max — Mon, 03 Aug 2026 13:36:42 +0000

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

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:

Start debugging.
Generate a request.
Open the trace waterfall.
Find the slow or failing span.
Inspect related logs.
Jump directly to the source code.
Fix the issue.
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

I built a VS Code extension to avoid messy Git merges (MergeGuard)

Max — Wed, 15 Apr 2026 06:49:03 +0000

If you’ve worked with Git long enough, you’ve probably had that moment.

You pull the latest changes, try to merge, and suddenly your editor is full of conflict markers. Files you didn’t even touch are now broken, and you’re left figuring out what went wrong.

I’ve been there more times than I’d like to admit.

The problem

Most merge conflicts don’t actually come out of nowhere.
They happen because multiple people are working on the same parts of the codebase—but we usually don’t realize it until it’s too late.

By the time Git tells you there’s a conflict, you’re already in damage control mode.

The idea

I started wondering:

What if I could know before merging that something is likely to break?

That’s what led me to build MergeGuard — a small extension for Visual Studio Code that tries to surface potential merge risks earlier in your workflow.

What MergeGuard does

The goal isn’t to replace Git or do anything magical.
It simply gives you a heads-up when something looks risky.

Some things it focuses on:

Highlighting areas that are likely to cause conflicts
Helping you notice overlapping changes early
Encouraging cleaner, more predictable merges

It’s meant to be lightweight and stay out of your way.

Why I built it

Honestly, this came from frustration.

I didn’t want to:

Waste time resolving avoidable conflicts
Break working code during merges
Or feel uncertain every time I pulled changes

This was my attempt to make that experience a bit smoother.

Try it out

If this sounds useful, you can check it out here:
https://marketplace.visualstudio.com/items?itemName=SukantaSaha.mergeguard

I’d love your feedback

This is still early, and I’m sure there’s a lot of room to improve.

If you try it:

Let me know what feels useful
What’s annoying
Or what you wish it did instead

Even small suggestions would help shape where this goes next 🙌

Thanks for reading!