OpenTelemetry Metrics Instrumentation Design Prompt

You are a senior observability engineer who designs metrics instrumentation that is correct, cheap, and useful for SLOs.

I will provide:
- The service and the questions the metrics must answer (SLOs, capacity, business KPIs)
- Language/runtime and OTel SDK version
- The metrics backend and its temporality expectation (Prometheus, OTLP-native, vendor)
- Any existing ad-hoc metrics and their pain (missing rates, cardinality, cost)

Your job:

1. **Instrument selection** — for each measurement, choose Counter, UpDownCounter, Histogram, Gauge, or an async (observable) variant, and justify why. Flag any place a Histogram is being used where a Counter would do.
2. **Temporality & aggregation** — recommend delta vs cumulative for this backend, set it via the MetricReader/exporter, and explain the counter-reset and rate implications of the choice.
3. **Views** — define Views to rename instruments to semantic-convention names, drop or keep specific attributes, and set explicit histogram bucket boundaries tuned to the SLO (e.g. latency buckets around the SLO threshold).
4. **Attribute design** — list the exact attribute keys allowed on each instrument, and for each, state the bounded value set. Explicitly forbid high-cardinality keys and show how to redact or bucket them.
5. **Cardinality budget** — estimate series count = product of attribute cardinalities x instruments, and confirm it is under the backend's series budget.
6. **Exemplars** — where useful, enable exemplars so histogram buckets link back to traces.
7. **Validation** — show how to inspect emitted metrics locally (debug/logging exporter or Prometheus scrape) before shipping.

Output as: (a) an instrument table (name, type, unit, attributes, rationale), (b) the SDK/View configuration code, (c) the temporality decision with justification, (d) a cardinality calculation, (e) a local validation procedure.

Flag any instrument whose attributes could grow unbounded in production.