Observability Design
Use current primary guidance as a review baseline, then report only what the available evidence supports. Primary authority: official reference.
Workflow
- Identify critical user journeys, service objectives, dependencies, failure modes, and decision owners.
- Define logs, metrics, and traces that answer distinct operational questions and share useful correlation context.
- Specify event names, dimensions, units, cardinality bounds, sampling, retention, privacy, and redaction.
- Design dashboards around user impact, traffic, errors, latency, saturation, and dependency health as applicable.
- Define alerts with symptoms, thresholds or burn behavior, ownership, runbook links, and expected action.
- Cover deploy markers, configuration changes, queues, retries, background work, and partial failure.
- Test whether an operator can distinguish detection, localization, diagnosis, and recovery from the proposed signals.
Boundaries
- Do not log secrets, tokens, personal data, or unbounded high-cardinality identifiers.
- Do not claim telemetry exists or alerts work without repository, provider, and observed firing evidence.
- A dashboard is not an alerting or incident-response system.
Output
Return Journeys and objectives, Signal design, Correlation, Dashboards, Alerts, Privacy and cost controls, and Validation plan.
1---2name: observability-design3description: Review or design observability for services and applications using logs, metrics, traces, alerts, and user-impact signals. Use when operators need to detect, explain, and respond to failures without confusing telemetry volume with operational understanding.4license: MIT5---67# Observability Design89Use current primary guidance as a review baseline, then report only what the available evidence supports. Primary authority: [official reference](https://opentelemetry.io/docs/concepts/signals/).1011## Workflow12131. Identify critical user journeys, service objectives, dependencies, failure modes, and decision owners.142. Define logs, metrics, and traces that answer distinct operational questions and share useful correlation context.153. Specify event names, dimensions, units, cardinality bounds, sampling, retention, privacy, and redaction.164. Design dashboards around user impact, traffic, errors, latency, saturation, and dependency health as applicable.175. Define alerts with symptoms, thresholds or burn behavior, ownership, runbook links, and expected action.186. Cover deploy markers, configuration changes, queues, retries, background work, and partial failure.197. Test whether an operator can distinguish detection, localization, diagnosis, and recovery from the proposed signals.2021## Boundaries2223- Do not log secrets, tokens, personal data, or unbounded high-cardinality identifiers.24- Do not claim telemetry exists or alerts work without repository, provider, and observed firing evidence.25- A dashboard is not an alerting or incident-response system.2627## Output2829Return Journeys and objectives, Signal design, Correlation, Dashboards, Alerts, Privacy and cost controls, and Validation plan.30
JovaniPink