observabilitylisted

# Observability — Logs, Traces, Metrics, SLOs A practical playbook for instrumenting production code so an incident at 03:00 takes minutes, not hours. Aligned with OpenTelemetry 1.x (the 2026 industry standard) and the SRE workbook's golden-signal approach. ## When to Use This Skill - Adding logging / tracing / metrics to a new service. - Designing dashboards before launch — observability built in, not bolted on. - Choosing between OpenTelemetry, Datadog APM, Honeycomb, Grafana Stack, Sentry. - Defining SLO / SLI / error-budget policy for a feature. - Writing or reviewing alert rules — a good alert wakes a human at 03:00 for the right reason. - Investigating "we have logs but can't find the bug" or "alerts fire constantly so nobody reads them." Skip when: writing a one-off script or a dev-only tool with no production lifetime. ## The Three Pillars + One Industry consensus (2020s onward) is *three pillars + traces-as-glue*: | Pillar | Question it answers | Tools | |---|---|---| | **Metrics** | "How is the system doing right now?" — counters, gauges, histograms | Prometheus, Datadog Metrics, CloudWatch Metrics | | **Logs** | "What exactly happened for *this* request?" — structured events | Loki, ELK, Datadog Logs, CloudWatch Logs | | **Traces** | "How did the work flow across services?" — spans + parent-child links | Jaeger, Tempo, Datadog APM, Honeycomb | | **Profiles** *(emerging fourth)* | "Why is the CPU/memory burning?" — continuous profiling | Pyroscope, Parca, Dat