Introduction
As applications evolve into distributed systems composed of microservices, background jobs, APIs, and frontend apps understanding what’s happening under the hood becomes increasingly critical. This is where observability steps in.
In traditional monolithic applications, debugging often involves adding logs, checking error messages, or attaching a debugger. However, this approach falls short in a distributed environment, where services communicate across processes or networks.
Observability is not just about logs. It’s about having the right data (logs, metrics, traces) and the right tools to connect the dots across your system.
With .NET Aspire, observability is a first-class citizen. Out of the box, Aspire enables.
- Centralized monitoring of all your registered services and apps
- Real-time streaming of logs from all your processes
- Request tracing to follow the path of a request across services
- Visual insights into endpoints, ports, health, and metrics
All of this is surfaced through the Aspire Dashboard, a UI that automatically launches when you run your AppHost project. No extra setup. No complex configurations.
This chapter will guide you through exploring the Aspire Dashboard and making the most of its observability features, starting with understanding the layout and moving on to practical debugging workflows.
If you are new to this Aspire quick guide, please check out the previous articles for a better understanding.
The Aspire Dashboard: Your Observability Cockpit
The Aspire Dashboard is a powerful, real-time UI that launches automatically when you run your .NET Aspire AppHost project. It provides a unified view of all the services registered in your distributed application — making it your go-to observability cockpit.
How to Launch the Dashboard?
If you’ve configured your solution using the .NET Aspire project templates and you're running the AppHost project, the dashboard will open automatically in your default browser.
Dashboard Layout Overview
The dashboard is cleanly divided into tabs, each designed to give insights into different aspects of your application:
1. Resources Tab
- Shows all services registered via AddProject<>, AddContainer<>, etc.
- Lists resource names like api, myweatherapp, etc.
- Displays their current status (Running, Stopped)
- Provides quick actions like:
- Viewing Swagger UI (for APIs)
- Previewing web apps
- Navigating to configured endpoints
![Viewing Swagger]()
2. Console Tab
- Streams stdout logs from all running services in real-time
- Useful during debugging to view console output, exceptions, or custom log messages
- Supports basic text search and filtering.
![Console Tab]()
3. Structured Tab
- Displays logs in a structured, queryable format
- Helps you drill down into specific log events across services
- Supports rich filters like severity, time range, and resource source
![Structured Tab]()
4. Traces Tab
- Shows distributed tracing data (requires OpenTelemetry setup)
- Visualizes the journey of a request across multiple services
- Useful for identifying slowdowns, bottlenecks, and dependencies
![Traces Tab]()
5. Metrics Tab
- Tracks key performance metrics like.
- CPU usage
- Memory consumption
- Request counts and durations
- Offers charts and graphs for real-time visibility
![Metrics Tab]()
The Aspire Dashboard is more than just a service viewer it's your developer control center, letting you,
- See what’s running and healthy
- Follow logs in real-time
- Analyze structured logs and traces
- Monitor performance metrics
Understanding the Aspire Dashboard Architecture
The .NET Aspire Dashboard is not just a UI layer it’s a lightweight diagnostic tool built into your distributed application’s lifecycle.
![Dashboard]()
Architecture Breakdown
- Hosted as a .NET Worker Service inside your AppHost project.
- It uses gRPC for communication between the dashboard backend and instrumentation clients (your services).
- Relies on the .NET Aspire diagnostics infrastructure to gather:
- Logs
- Metrics
- Distributed traces
- Health data
Here’s a simplified flow of how it works.
![Flow]()
Dashboard Security Model
The Aspire Dashboard is designed for developer use only in local environments. Here's what you should know.
Access Control
- No authentication or authorization by default
- Exposed on localhost only
- Do NOT expose it in production
Port Binding
- Default port: 18888
- Accessible only on localhost
Security Recommendations
If you need remote access (not recommended in production)
- Use SSH tunneling (e.g., SSH -L 18888:localhost:18888 user@host)
- Consider reverse proxy + auth (e.g., NGINX)
- Use container isolation if running inside the Docker
Behind the Scenes: Telemetry in .NET Aspire
.NET Aspire integrates powerful telemetry capabilities out of the box. Whether you're building APIs, background workers, or full-blown microservices, Aspire automatically enables diagnostics across your services.
What Telemetry Includes?
When you run your application using the AppHost project, Aspire injects telemetry collectors that gather.
- Logs: Real-time log streams from your services
- Metrics: CPU, memory, request counts, latency, error rates, and more
- Traces: Distributed traces for cross-service calls (HTTP, gRPC, etc.)
- Health Probes: Basic up/down service checks
These diagnostics are funneled to the Aspire Dashboard without any extra configuration.
How Telemetry is Collected?
Internally, .NET Aspire uses OpenTelemetry, an open standard for distributed tracing and metrics collection. Here’s a simplified telemetry flow.
![OpenTelemetry]()
All of this happens via automatic wiring no need to explicitly configure OpenTelemetry unless you want to customize things.
Extending Telemetry
While Aspire gives you a solid default setup, you can extend or override its behavior.
- Add custom loggers like Serilog or Seq
- Export telemetry to external APM tools (like Azure Monitor, Grafana, or Jaeger)
- Define custom metrics for business logic
Sample: Exporting to Console
builder.Services.AddOpenTelemetry()
.WithMetrics(metrics => metrics.AddConsoleExporter())
.WithTracing(tracing => tracing.AddConsoleExporter());
This uses the OpenTelemetry.Extensions.Hosting package and the standard OpenTelemetry .NET API, both of which are stable and production-ready.
Required NuGet Packages
To use this in your Aspire services, make sure to install it.
dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Exporter.Console
Where to Use It?
You can place this snippet in any service project (e.g., your API or Worker service) inside Program.cs.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOpenTelemetry()
.WithMetrics(metrics => metrics.AddConsoleExporter())
.WithTracing(tracing => tracing.AddConsoleExporter());
This setup.
- Exports logs and metrics to the console
- Is useful for debugging and local dev insights
- Complements the Aspire Dashboard’s built-in observability
Use Case: Debugging Performance
Imagine a slow API response. With Aspire telemetry, you can:
- Check the trace tab to see if downstream services caused delays.
- Look at the metrics tab to spot CPU/memory spikes.
- View logs in real-time across all services from the Dashboard console.
Dashboard Themes in .NET Aspire
To enhance the user experience, the Aspire Dashboard includes built-in support for theming. This allows developers to choose how the dashboard appears visually — based on personal preference or development environment conditions.
Available Theme Modes
The Aspire Dashboard currently supports the following three visual themes.
- System Theme (Default)
- This theme adapts automatically to your operating system’s light/dark setting.
- Ideal for users who prefer consistent UI across all their tools and apps.
- Example: If your OS is in dark mode, the dashboard switches to dark too.
- Light Theme
- A clean, high-contrast theme ideal for brightly lit environments.
- Useful when presenting on projectors or during daylight development sessions.
- Offers maximum readability with dark text on light backgrounds.
- Dark Theme
- A developer-favourite theme that reduces eye strain in low-light conditions.
- Complements IDEs and tools that also use dark themes (like VS Code or Rider).
- Reduces screen glare and power usage on OLED displays.
Why do Themes Matter in Observability?
Although seemingly cosmetic, theming can impact productivity and comfort. For long debugging or observability sessions, selecting the right theme can:
- Minimize visual fatigue
- Improve focus on logs, traces, and metrics
- Match your development setup for visual consistency
Theme Selection Experience
You can toggle the theme from the dashboard UI itself.
- Look for the theme selector dropdown (typically in the top-right corner).
- Your selected theme is remembered locally between sessions.
There's no code configuration required theming is fully user-controlled through the dashboard interface.