observability-debugginglisted

# Observability Debugging Narrow a symptom to a service and a cause by using each signal for what it is actually good at. ## Purpose **Use this when:** - A service is slow or erroring and you have telemetry but no conclusion. - You need to decide which of several services in a request path is at fault. - Dashboards disagree with what users report. - You have traces available and are not getting value from them. **Do not use this when:** - The telemetry itself is broken — use `prometheus-troubleshooting`. - You are in an active outage and need to stabilise first — use `incident-triage`. Deep investigation comes after mitigation. - You are defining what to measure — use `slo-design`. **What this skill assumes:** metrics exist for the services in the path, logs are queryable, and traces may or may not exist. It works without traces, but says where they would have saved time. ## Operating Procedure Each signal answers a different question. Using the wrong one wastes the most valuable minutes. | Signal | Answers | Does not answer | | --- | --- | --- | | Metrics | Is something wrong, how much, since when | Why, or for which request | | Traces | Where in the request path the time or error is | What the code was thinking | | Logs | What happened in one specific execution | How often, or whether it is unusual | The order that works: **metrics to detect and scope → traces to localise → logs to explain.** Starting with logs on a distributed system means reading a million li