Monitoring collects and examines signals from a running application so problems can be found before they have a larger effect on users. For an online shop, uptime, response times, and error rates help reveal reliability problems; CPU and memory measurements help identify bottlenecks, plan capacity, and control infrastructure costs. Access logs, audit trails, and security events can also expose suspicious activity. section 6.0
Aspire uses OpenTelemetry to collect logs, metrics, and traces. Its vendor-agnostic tooling can process and export telemetry from distributed applications. In a standard Aspire Starter Project, the Service Defaults project already includes the monitoring dependencies; for an online shop, that project can be named OnlineShop.ServiceDefaults. section 6.2
The Service Defaults packages divide the work:
- OpenTelemetry.Exporter.OpenTelemetryProtocol supplies the OTLP exporter for communication with collectors and observability backends. section 6.2
- OpenTelemetry.Extensions.Hosting starts and stops tracing; the ASP.NET Core and HTTP instrumentation packages integrate middleware and collect HTTP telemetry. section 6.2
- OpenTelemetry.Instrumentation.Runtime collects .NET runtime metrics, including garbage collection, memory use, and thread-pool measurements. section 6.2
After launching the application, use the Aspire dashboard to inspect services in one place. Console shows an individual service’s console logs; Structured shows structured logs across services; Traces and Metrics expose their respective telemetry. These views help investigate what happened, but they do not by themselves establish whether a service is working correctly right now. Health checks address that separate need. section 6.4 section 6.0
