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

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:

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.