OpenTelemetry Involves IntelliJ IDEA, GoLand, PyCharm, and WebStorm

OpenTelemetry Involves IntelliJ IDEA, GoLand, PyCharm, and WebStorm.

The OpenTelemetry plugin has damaged out of the confines of JetBrains Rider. No sandbox exploit was concerned – this escape was deliberate by our builders. With the 2026.2 launch, the OpenTelemetry plugin is now obtainable in IntelliJ IDEA, GoLand, PyCharm and WebStorm. Rider customers needn’t fear – it nonetheless works there too.

The plugin brings logs, metrics, traces, and the service map from native functions into the IDE. You’ll be able to examine them with out establishing a separate native observability backend.

What’s the OpenTelemetry plugin?

Whereas growing along with your IDE, you should utilize the plugin to:

• Discover what occurred instantly earlier than an error.
• See which providers and dependencies a request reached.
• Pinpoint the place a request spent its time.
• Examine whether or not the appliance emitted the anticipated logs, metrics, and traces.
• Ask your coding agent to do all the above by way of MCP.

The plugin’s performance enhances what the IDE provides out of the field. Use a debugger to step by means of code, a profiler to investigate efficiency, and a manufacturing monitoring platform to look at deployed methods. Use the OpenTelemetry plugin to examine runtime conduct when you construct or check the appliance.

Think about this

Say you might be testing a function that calls a number of providers and a database earlier than publishing a message to a queue. The request fails, and the console reveals the exception, however not the trail that led to it.

Within the OpenTelemetry instrument window, you may search the logs for the error. Open the related hint to see how the request moved by means of the system and the place it failed. The Service Map reveals the providers and infrastructure concerned.

Discover runtime information within the IDE

Search and examine logs

Console output is manageable till a number of providers begin writing without delay. The Logs view places OpenTelemetry log data in a searchable desk. You’ll be able to filter by severity or content material, then open a file to examine its attributes.

Examine metrics

Choose a metric from the metric tree to plot its values when you use the appliance. This view isn’t a substitute on your manufacturing dashboards, nevertheless it permits you to examine what the appliance will export earlier than you ship the info to a manufacturing observability platform. If a brand new library provides noisy or pointless metrics, you may catch them regionally and modify the instrumentation earlier than your DevOps and SRE colleagues should deal with them.

Observe a request by means of its hint

Open a hint to see its spans throughout providers. Every span consists of timing and attributes, so you may comply with the request from begin to end and 0 in on the operation that failed or slowed issues down. Growth can also be time to have a look at the hint itself. Does it include the spans and particulars you’d want throughout an actual incident? It’s a lot simpler to repair these gaps now than to find them in manufacturing.

See noticed relationships within the Service Map

Structure diagrams go stale. The Service Map builds its relationships from collected traces, so it displays the site visitors the plugin has seen between providers, endpoints, databases, and message queues.

Anticipated one HTTP name or database question, however the diagram reveals a number of? Discovering that in improvement offers you time to repair it earlier than launch.

Join an instrumented utility

The plugin doesn’t add OpenTelemetry libraries or brokers to your utility. It configures the place an already instrumented utility sends its information.

Begin an instrumented Java, Python, Go, or .NET utility from a supported IDE run configuration, and the plugin passes OpenTelemetry Protocol (OTLP) surroundings variables that time to its built-in receiver. It passes the identical variables to new built-in terminal classes.

It’s also possible to level the appliance’s OTLP exporter on the endpoint proven by the plugin. When you already use an area OpenTelemetry Collector, add the plugin as an OTLP vacation spot and maintain the remainder of your pipeline.

Runtime context for coding brokers

The plugin has experimental MCP help by means of the JetBrains MCP server. A suitable coding agent can question the telemetry collected within the IDE with these instruments:

• get_log_records
• get_spans
• get_services
• get_service_map

These instruments give the agent proof from a selected run, in order that it could actually examine the logs and spans or question the noticed service relationships.

Getting began

1. Set up the OpenTelemetry plugin from JetBrains Market on your favourite IDE.
2. Instrument your utility with OpenTelemetry libraries or brokers.
3. Begin it from a supported IDE run configuration or a brand new built-in terminal session. The plugin will move the OTLP surroundings variables. Alternatively, level the appliance’s exporter or your native collector on the endpoint proven by the plugin.
4. Open the OpenTelemetry instrument window and train the a part of the appliance you wish to examine.

The plugin reveals the indicators it receives. In case your utility exports solely traces, the Logs and Metrics views keep empty.

Full setup directions can be found within the OpenTelemetry plugin documentation.

Set up it and inform us what you discover

Attempt it on an actual mission, then inform us within the feedback or by means of the situation tracker what labored and what nonetheless despatched you to a different instrument.