DEV Community: Kim Ipsen

Metrics and Console applications

Kim Ipsen — Fri, 22 Aug 2025 20:02:51 +0000

Collecting Metrics in a .NET Console Application

In a previous post, I showed how to get started with metrics collection in a .NET application using the Aspire dashboard. That example was based on an ASP.NET Core Web API, where metrics and tracing feel almost effortless to enable thanks to the hosting model and built-in instrumentation.

But what if you’re working on a console application — a CLI tool, a batch processor, or a background job? Can you still use the same approach? The answer is yes, but with a slightly different setup. In this post, I’ll walk through how to add metrics to a console app, show two possible approaches (with and without a host), and explain why the setup differs from what you get in a web app.

Setting up the Aspire Dashboard

First, let’s set up the Aspire dashboard to receive metrics. If you followed along in my previous post, this part will look familiar.

You can run the Aspire dashboard locally with Docker:

# docker-compose.yml
services:
  aspire-dashboard:
    image: mcr.microsoft.com/dotnet/aspire-dashboard:latest
    ports:
      - "18888:18888" # Dashboard UI
      - "18889:18889" # OTLP endpoint

Start it with:

docker compose up -d

The dashboard UI will be available at http://localhost:18888, and the OTLP endpoint for metrics will be available on http://localhost:18889.

Console apps: with or without a Host

There are actually two ways you can wire up metrics in a console application:

1. Without a Host

This is the most minimal approach. You create your Meter, Counter, and MeterProvider directly in Program.cs. This works well for small tools and keeps things lightweight.

using System.Diagnostics.Metrics;
using OpenTelemetry;
using OpenTelemetry.Metrics;

var meter = new Meter("PlainConsoleApp");
var counter = meter.CreateCounter<long>("records_processed");

using var meterProvider = Sdk.CreateMeterProviderBuilder()
    .AddMeter("PlainConsoleApp")
    .AddOtlpExporter(options =>
    {
        options.Endpoint = new Uri("http://localhost:18889");
    })
    .Build();

for (int i = 0; i < 5; i++)
{
    counter.Add(1);
    Console.WriteLine($"Processed record {i + 1}");
    await Task.Delay(500);
}

This approach is straightforward, but you don’t get the conveniences of a hosting environment (like DI, config, or logging automatically wired up).

2. With a Host

If your console app grows more complex, you can use the Generic Host. This gives you a structure that’s closer to an ASP.NET Core app, making it easier to share setup patterns.

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using OpenTelemetry.Metrics;

using IHost host = Host.CreateDefaultBuilder(args)
    .ConfigureServices(services =>
    {
        services.AddOpenTelemetry()
            .WithMetrics(builder =>
            {
                builder
                    .AddMeter("HostConsoleApp")
                    .AddOtlpExporter(options =>
                    {
                        options.Endpoint = new Uri("http://localhost:18889");
                    });
            });

        services.AddHostedService<Worker>();
    })
    .Build();

await host.RunAsync();

In this example, the Worker service can inject metrics and emit them as part of its work loop. This is more boilerplate, but it scales better if your app has multiple services, configuration needs, or background tasks.

👉 You can find both full examples in my GitHub repo: kimipsen/cli-app-metrics.

Why is the setup different from Web APIs?

If you’ve worked with ASP.NET Core before, you might have noticed that collecting metrics there feels almost effortless. You enable instrumentation, and suddenly you’ve got request counts, response times, and dependency calls showing up in your dashboard.

But when you switch to a console (CLI) app, things look a little different — and here’s why.

1. Hosting model

Web APIs run on the Generic Host, which comes with dependency injection, logging, metrics, and tracing all wired up for you.

Console apps don’t use a host unless you add one. They just run whatever you put in Main, which means there’s no prebuilt telemetry pipeline. That’s why you have to explicitly create and configure the MeterProvider (and optionally TracerProvider) yourself.

2. Application lifetime

A Web API is a long-running process, constantly handling requests. That makes continuous instrumentation natural.

A CLI tool, on the other hand, is often short-lived: it runs a job, then exits. Because of this, you need to make sure telemetry is flushed before the app shuts down (disposing the provider is key). Metrics in a console app are tied to the lifecycle of a single run.

3. Instrumentation sources

ASP.NET Core ships with automatic instrumentation for things like HttpClient, Entity Framework, and Kestrel (requests, connections).

Console apps don’t have a request pipeline — so you won’t get anything “for free.” Instead, you define your own metrics with counters, gauges, or histograms that match the logic of your CLI tool (for example: files processed, records imported, or errors encountered).

4. Different focus

In a web service, metrics are usually about observability — monitoring traffic, latency, and errors over time.

In a console app, metrics are usually about outcomes — how many items were processed, how long a run took, and whether it succeeded or failed. You’re measuring the job itself, not ongoing service health.

Here’s a quick side-by-side comparison:

Aspect	ASP.NET Core (Web API)	Console App (without Host)	Console App (with Host)
Hosting	Generic Host with built-in DI, logging, metrics	No host by default, manual setup	Generic Host, similar to ASP.NET Core
App Lifetime	Long-lived, continuous	Short-lived, often one-off	Short-lived or long-running
Instrumentation	Automatic (HTTP, EF Core, etc.)	Manual (custom counters, histograms)	Manual, but easier to extend via DI
Metric Focus	Requests, latency, availability	Task progress, job duration, outcomes	Same, but can scale to complex apps

Wrapping up

Adding metrics to a console app is just as possible as in a web app — it just requires a bit more manual setup. The key differences come from the hosting model and application lifetime, which shape how you collect and flush telemetry.

The good news is that once you’ve wired up MeterProvider and added your custom counters, you can use the same Aspire dashboard and OTLP pipeline across both web and console apps.

That means you can monitor batch jobs, CLI utilities, and background workers with the same tools you’re already using for APIs and services.

👉 You can find the code for this example here: github.com/kimipsen/cli-app-metrics

Getting started using metrics

Kim Ipsen — Tue, 01 Jul 2025 19:59:37 +0000

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'

🤔 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()
    );

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:

📚 OpenTelemetry.io
📘 .NET OpenTelemetry docs

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!