What logs, metrics, and alerts would you expect for a production .NET service?

In production I design telemetry as a bounded data product. Metric labels use low-cardinality dimensions; user ids, raw URLs, exception messages, and request values do not become labels. Logs avoid tokens, secrets, personal payloads, and uncontrolled duplication, with retention and access based on operational need. Sampling preserves errors and important traces while controlling healthy high-volume traffic, and exemplars or trace links connect aggregate metrics to representative requests. I distinguish symptoms from causes: user-facing latency and success alerts page first, while CPU or one dependency warning helps diagnosis unless it independently threatens capacity. Alert thresholds include duration, traffic minimums, and service-objective burn so a quiet service or one transient spike does not create noise. Queue age, dead letters, background-job outcomes, and stale business states cover work that request metrics miss. I test telemetry during failure drills, review unused fields and noisy alerts, and verify that dashboards still answer what changed, who is affected, where time is spent, and whether mitigation worked. Success is faster confident decisions, not the number of logs stored.