DEV Community

Kim Ipsen
Kim Ipsen

Posted on • Edited on

Getting started using metrics

#devcontainer #telemetry #devops

Getting Started Using the Aspire Dashboard for Metrics, Traces, and Logs

I was recently asked to create and publish a simple repository showcasing how to use the standalone Aspire dashboard for collecting metrics, traces, and structured logs—all using OpenTelemetry standards.

TL;DR

🔗 Find the full repo here: github.com/kimipsen/aspire-metrics

Why Aspire?

This project was born out of frustration while wrestling with the Elastic stack to create a local observability environment. One of the biggest pain points? 🔐 Managing logins across multiple services just to get basic logs flowing.

Cue Aspire.

Aspire makes it incredibly easy to:

  • Spin up dev containers for your services
  • Wire them together
  • Collect observability data (logs, traces, metrics)
  • View it all in a single, clean dashboard

All using OpenTelemetry standards 🔭🎉

Use Case: Standalone Dashboard Only

Usually, Aspire is used as a fully configured project with multiple services defined in code. But in my case, I only needed the dashboard. I didn’t want Aspire to control or define my services—I wanted my existing devcontainer setup to remain untouched.

Luckily, Aspire supports running the dashboard as a standalone container, which still supports everything I need: metrics, traces, and structured logs via OTLP.

Configuring the Dashboard (Docker Compose)

Setup is refreshingly simple—no login-sharing between services, no complex collectors.

Here’s the full docker-compose.yaml snippet:

aspire:
  image: mcr.microsoft.com/dotnet/aspire-dashboard:latest
  restart: unless-stopped
  ports:
    - 18888:18888
    - 18889:18889
  environment:
    ASPIRE_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS: 'true'
Enter fullscreen mode Exit fullscreen mode

🤔 Wait—didn’t you say no logins?
Why set ALLOW_ANONYMOUS if I want authentication?

Good catch! This just controls access to the dashboard UI, not communication between services. If you prefer password protection, remove the ALLOW_ANONYMOUS line. The login token will be shown in the Aspire container logs.

🔌 About the Ports

The Aspire dashboard container exposes two ports:

  • 18888 — Serves the dashboard UI, where you can explore traces, metrics, and logs.
  • 18889 — The OTLP (OpenTelemetry Protocol) ingestion endpoint used by your services to send telemetry data (spans, metrics, and logs).

If you're running multiple services, just point their OTLP exporters to http://localhost:18889 (or the appropriate container network name), and Aspire will start receiving data automatically.

Instrumenting a .NET 8 Web API

To demonstrate end-to-end observability, I built a small .NET 8 Web API with:

  • EF Core
  • Npgsql (PostgreSQL)

OpenTelemetry is added in just ~25 lines of code:

builder.Logging.AddOpenTelemetry(options =>
{
    options.SetResourceBuilder(
        ResourceBuilder
            .CreateDefault()
            .AddService(serviceName))
        .AddOtlpExporter();
});

builder.Services
    .AddOpenTelemetry()
    .ConfigureResource(resource => resource.AddService(serviceName))
    .WithTracing(tracing => tracing
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddEntityFrameworkCoreInstrumentation()
        .AddNpgsql()
        .AddOtlpExporter()
    )
    .WithMetrics(metrics => metrics
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddNpgsqlInstrumentation()
        .AddOtlpExporter()
    );
Enter fullscreen mode Exit fullscreen mode

You migth be wondering how I'm specifying where my collector is located, how OpenTelemetry knows how to use the aspire dashboard for collecting metrics and traces.

I've configured this part in the docker-compose.yml file. By specifying the 2 environment variables OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_PROTOCOL, OpenTelemetry will pick up on this configuration when debugging the .net application.

If I wanted to customize the configuration to send my metrics somewhere else, eg. a central server such as Jaeger, I could then customize my .net application using either code (in the Program.cs file) or appsettings.json. This would then override the environment variables from the container.

✅ This config:

  • Sends traces and metrics via the OTLP exporter
  • Adds common instrumentation: ASP.NET Core, HTTP clients, EF Core, Npgsql
  • Can be easily extracted into a reusable extension method

Next Steps

If you want to go deeper—create custom metrics or spans, enrich telemetry with custom properties—I highly recommend checking out:

Summary

If you're tired of setting up complex stacks just to monitor a few services, the Aspire dashboard offers a great alternative:

  • ✅ Lightweight
  • ✅ Standards-based
  • ✅ Works out-of-the-box with OpenTelemetry
  • ✅ Easy to run standalone

🚀 I’d love to hear what you build with Aspire or how you're using OpenTelemetry in your .NET projects—feel free to share your thoughts in the comments!

Top comments (0)