observability-architectlisted

# Observability Architecture — Signal Production What an application emits about itself: **logs**, **metrics**, **traces**. Pairs with [grafana-architect](../grafana-architect/SKILL.md) which owns the consumption side (dashboards, alerts). This skill enforces what gets emitted, how it's named, and how the three pillars correlate. Wiring code in [RECIPES.md](RECIPES.md); pinned libraries in [STACK.md](STACK.md). ## 1. Three pillars + correlation Each pillar answers a different question: | Pillar | Question | Cardinality | Cost | |---|---|---|---| | **Logs** | "What happened on *this* request?" | High (per event) | High storage | | **Metrics** | "What is the *rate* / *aggregate*?" | Low (aggregated) | Low storage | | **Traces** | "What was the *path*?" | One per request | Medium | The *design goal* is **correlation**: from any signal you can pivot to the others. A trace shows a slow request → click → see the logs from that request → see the metric spike around the same time. This is what makes observability worth the cost. **Correlation mechanism: trace_id everywhere.** - Every log line carries the current `trace_id` and `span_id`. - Every metric exposes the current `trace_id` as an exemplar (Prometheus exemplars). - Every trace span carries the operation name, attributes, and status. If you skip the correlation, you have three independent data lakes — useful in isolation, painful to cross-reference. Concrete wiring in [RECIPES §1](RECIPES.md#1-correlation-trace_id-in-l