For a 2024 architecture review, observability offers a more useful exercise than counting dashboards: follow one customer action from the browser to its final business outcome.
Consider submitting an order that later generates a document. The HTTP request can succeed while the worker fails. An uptime chart for the API will not explain the missing document.
Give each signal a job
Use metrics to identify a change in volume, latency or failures. Use traces to explore where a particular operation spent time. Use structured logs to explain decisions and failures in context. OpenTelemetry provides .NET APIs and SDKs for these signals; exact package capabilities should be checked against the version being deployed.
Instrument the handoff
Carry correlation context through the queue boundary and record enough information to connect the worker outcome with the initiating action. Distinguish a retry from a new business request so an incident does not appear as unexplained extra traffic.
Do not use customer names or document bodies as convenient diagnostic attributes. Prefer bounded labels for metrics and carefully controlled identifiers in detailed telemetry.
Test the design by introducing a failed dependency in a non-production environment. Ask a colleague to locate the affected operation using only the available signals. Their investigation is a better acceptance test than a screenshot of a populated dashboard.
Reference
OpenTelemetry .NET documentation describes the current implementation; this article proposes a period-themed design exercise without claiming historical package status.