JetBrains ships its OpenTelemetry plugin to four more IDEs; instrumentation is still your problem

The trick is environment variables. Launch from a supported run configuration and the IDE hands the process a set of OTLP variables pointing at a receiver built into the plugin ^[4]. New integrated terminal sessions get the same variables ^[5]. If you would rather keep your own plumbing, the plugin exposes an endpoint you can aim an exporter at, and an existing local Collector can treat it as one more OTLP destination ^[6].

So the cost that goes away is the backend and the wiring around it. JetBrains's claim is that you inspect logs, metrics, traces and a service map from a locally running application without standing up a local observability stack ^[2]. The cost that does not go away is instrumentation, and the announcement is unusually direct about it: the plugin adds no OpenTelemetry libraries and no agents, it only decides where an already instrumented application sends its data ^[3]. A team that never wired up the SDK gets a tool window with nothing in it.

The Service Map is assembled from collected traces, which is why JetBrains contrasts it with architecture diagrams that go stale ^[8]. That construction also bounds it: a dependency reached only on a code path your run did not touch is a dependency the map will not draw ^[2]. The other limit is language coverage. The automatic handoff is listed for four runtimes ^[4], none of them JavaScript, even though WebStorm is among the IDEs picking up the plugin ^[1]. The post does not say what a Node process gets, and on the text as written the manual exporter endpoint ^[6] is the route.

The MCP surface is the part most likely to change. Four tools, all reads: log records, spans, services, service map ^[9]. That is enough for a coding agent to stop inferring runtime behaviour from the source tree and check what one particular run emitted ^[10], which is the difference between an assertion and a citation. It is also, on the published list, only reading ^[3]. If the trace is missing the span you needed, the agent can point at the hole and you fill it.

The quieter change is to when a question gets asked. JetBrains suggests treating development as the moment to check whether a trace carries the detail you would want during a real incident ^[13]. That check was never blocked by tooling so much as by the cost of finding out. Once the answer sits a click away from the run button, "we will add instrumentation when we need it" stops being a scheduling call and becomes a gap somebody can see in a diff.