aspire-service-defaults_skill

Overview

This skill creates a shared ServiceDefaults project for Aspire applications to centralize observability, health checks, resilience, and service discovery. It provides a single AddServiceDefaults() extension that every service calls to apply consistent OpenTelemetry, health endpoints, HTTP resilience, and service discovery configuration. Use it to enforce a common configuration baseline across web and worker services.

How this skill works

The skill registers OpenTelemetry for logging, metrics, and tracing, excluding health endpoints from traces. It adds a default health check registration and maps /health and /alive endpoints (development by default). It configures IHttpClient defaults with a standard resilience handler (retries, circuit breaker, timeouts) and integrates service discovery so HTTP clients resolve service names automatically. OTLP exporters are enabled when OTEL_EXPORTER_OTLP_ENDPOINT is present.

When to use it

• Building Aspire-based distributed microservices that must share observability and resilience settings
• You want consistent liveness and readiness checks across all services
• You need centralized HTTP client resilience and service discovery behavior
• Onboarding new services quickly with a single AddServiceDefaults() call
• When you want telemetry to flow to a central OTLP endpoint (Aspire Dashboard, Jaeger, etc.)

Best practices

• Keep one ServiceDefaults shared project referenced by every service to ensure consistency
• Filter health endpoints from tracing to reduce noise in spans
• Tag health checks (e.g., "live" vs "ready") to separate liveness and readiness probes
• Protect or restrict health endpoints in production (internal ports, auth, or rate limits)
• Add domain-specific ActivitySources to capture custom traces
• Configure OTLP exporter via environment (OTEL_EXPORTER_OTLP_ENDPOINT) rather than hard-coding

Example use cases

• An API service calling downstream services uses AddServiceDefaults() to get tracing, metrics, health endpoints, and resilient HttpClient behavior out of the box
• A background worker registers the same health checks and telemetry as web services by calling AddServiceDefaults() in a non-web host
• Kubernetes deployments use the tagged health checks for separate liveness and readiness probes
• Teams add custom health checks (database, cache) to the shared defaults so all services expose consistent probe behavior
• Enable OTLP export automatically when the platform (AppHost) injects an OTEL endpoint for centralized telemetry