OpenTelemetry Plugin for JetBrains Rider: Observability Inside Your IDE

Understanding how your application behaves at runtime has always been a challenge. Traditional debugging and profiling tools can help you understand what’s happening at specific points in time – but getting a complete picture of system behavior, performance patterns, and architectural relationships often means jumping between external tools and dashboards. We’re building the OpenTelemetry plugin […]

Jun 16, 2025 - 21:50

OpenTelemetry Plugin for JetBrains Rider: Observability Inside Your IDE

Understanding how your application behaves at runtime has always been a challenge. Traditional debugging and profiling tools can help you understand what’s happening at specific points in time – but getting a complete picture of system behavior, performance patterns, and architectural relationships often means jumping between external tools and dashboards.

We’re building the OpenTelemetry plugin for JetBrains Rider to bring runtime observability directly into your development environment.

What is the OpenTelemetry plugin for Rider?

This plugin is designed for observability during local and dev/test development. It’s not a debugger or profiler – instead, it lets you correlate runtime behavior (logs, metrics, traces) with your code inside Rider.

It helps you answer questions like:

What happened right before this error?
Which services did this endpoint call?
Why is this request slower today than yesterday?

If you’ve been following our work on observability, you might have already seen OpenTelemetry support in our .NET Aspire plugin. This new plugin builds on that experience, but it stands on its own. It doesn’t require Aspire or any other specific tooling. Just run your application from Rider, and the plugin gives you access to runtime data inside the IDE. It’s designed to support a wide range of .NET development workflows, whether or not Aspire is part of your stack.

With everything in one place, you can jump straight from a log to the responsible line of code – no external dashboards needed.

Imagine this

You’re implementing a new feature in a cloud-based .NET system: a few services, a PostgreSQL database, and a message queue. Typically, validating its behavior would mean setting up external tools for logs, metrics, and traces, wiring them into your environment, and flipping between dashboards to piece everything together.

With the OpenTelemetry plugin for Rider, you just run the app and watch everything come into focus – logs appear instantly, metrics stream in with zero setup, and an architecture diagram shows exactly how your feature flows through services and dependencies.

No dashboards to set up. No context-switching. Just insight, right where you work.

Key features

Comprehensive log management

The plugin includes a table-style log viewer with advanced search and filtering capabilities to help you quickly find the information you need. You can filter by log level, text content, and other parameters to focus on what matters most.

The real power lies in its tight integration with the source code. When you find an issue in the logs, you can click through directly to the relevant line of code. This connection between runtime behavior and source makes it more than a typical monitoring tool.

*The log viewer with filtering capabilities and different log levels .*

*Detailed log view showing timestamps, levels, and messages for different log types*.

*Detailed log information panel showing trace IDs, span IDs, and the “Navigate To Code” functionalit*y.

Runtime metrics at your fingertips

The metrics viewer presents a detailed metric tree showing your application’s runtime performance. Instead of guessing about resource usage or performance bottlenecks, you can see exactly how your application behaves under different conditions.

*The metrics viewer displays ASP.NET Core routing performance data with real-time charts*.

Automatic architecture visualization

Most interestingly, the plugin can automatically generate architecture diagrams from your execution traces. These aren’t static diagrams you have to maintain – they’re built directly from how your system actually behaves at runtime, showing services, endpoints, databases, and message queues as they interact in real scenarios.

*Automatically generated service map showing the relationship between API endpoints, internal services, RabbitMQ, and PostgreSQL based on actual runtime traces*.

Zero-setup auto-instrumentation

You don’t need to manually add OpenTelemetry instrumentation to your application. If you start your application using a .NET Project or a launchSettings.json configuration, the plugin will automatically inject the required OpenTelemetry packages — as long as you’ve enabled the Allow automatic instrumentation option under Settings/Preferences | Tools | OpenTelemetry.

With that setting enabled, you’ll get runtime observability without modifying your codebase or managing dependencies yourself.

Real-world use cases

Manual testing and debugging

Instead of adding console.WriteLine statements or setting breakpoints everywhere, you can inspect logs, metrics, and traces to understand runtime behavior while developing or testing features. Most importantly, when you identify an issue, you can immediately jump to the relevant source code without leaving your development environment.

Team onboarding

New developers joining your team can visualize system architecture and understand runtime context without learning a separate set of tools. Just install Rider and start exploring.

This is just the beginning

We’re just getting started with this tooling. Here’s what we’re currently exploring:

Multi-IDE support: OpenTelemetry is language- and vendor-agnostic, which opens the door to supporting additional IDEs like IntelliJ IDEA and PyCharm in the future.

AI-powered insights: We’re exploring how runtime data can be used to explain issues or suggest improvements. Imagine having AI explain error logs in context, adding runtime data to AI Assistant conversations for better suggestions, or even running automated testing agents that can analyze system behavior.

Cloud integration: While the current focus is on local and dev environments, the OpenTelemetry standard enables natural integration with cloud observability workflows for deeper insights in production environments.

Some final notes

This functionality is the product of a collaborative effort between the Rider Execution team and the Dynamic Program Analysis team at JetBrains Research. This launch is the first step in exploring how telemetry analysis can help us build development tools that better adapt to real-world developer workflows.

Tell us what you think

The OpenTelemetry Plugin for Rider is available now as part of the Early Access Program for Rider 2025.2. Download the latest preview build and give it a try:

Download Rider 2025.2 EAP5

We’re actively developing this plugin and would love your feedback. Share your thoughts in the comments, or add your input to this ticket. If you encounter any issues, please report them via our issue tracker.