Observability Signals
Observability signals are evidence a system sends about its own behavior. Common signals are traces, metrics, logs, and baggage, which carries small context between services.
Another example
Checkout p95 latency goes above 800ms. A metric points to the EU region, and an exemplar opens trace `7af…`. Spans find `inventory.reserve`. Linked logs show a timeout type without card data. A deploy field ties the bug to release `2026.07.30`, and sampling still keeps errors.
Main parts
- 01Instrumented telemetry
- 02Correlated traces, metrics, and logs
- 03Collection, sampling, storage, and query
Use it when
Design signals around service goals people can feel. Pass trace context, link IDs, limit how many label values exist, and remove sensitive data.
Do not use it when
Collecting everything is not observability. Do not log secrets or unlimited user IDs, and do not build dashboards with no investigation or alert response plan.
Name used in code
OpenTelemetry traces + metrics + logs + resource/attribute conventions + context propagation Before you ship
Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule.
Outcome: Use Observability Signals to gather repeatable evidence about this behavior or quality risk. User context: Checkout p95 latency goes above 800ms. A metric points to the EU region, and an exemplar opens trace `7af…`. Spans find `inventory.reserve`. Linked logs show a timeout type without card data. A deploy field ties the bug to release `2026.07.30`, and sampling still keeps errors. Validation approach: Observability Signals. Why it fits: Design signals around service goals people can feel. Pass trace context, link IDs, limit how many label values exist, and remove sensitive data. Do not use it when: Collecting everything is not observability. Do not log secrets or unlimited user IDs, and do not build dashboards with no investigation or alert response plan. Test requirements: Name the system and test environment. Define prepared test data, other inputs, and the result you can observe. Include failure and edge cases, allowed error, isolation, and cleanup. Test operations: Make failures easy to diagnose. Control random or changing inputs. Name an owner. Keep the test fast and simple enough for its release gate. Acceptance criteria: The test fails for the known bug and passes after the fix. It repeats in the target environment, gives useful evidence, and does not expose or change unrelated data. Evidence and limits (evidence boundary): It is official for that source. Other platforms or teams may use the term in another way. Unknowns to confirm: Release gate, environment, prepared test data, allowed error, time budget, owner, and flaky-test rule.
Check this request
Review the current use of Observability Signals. Definition: Observability signals are evidence a system sends about its own behavior. Common signals are traces, metrics, logs, and baggage, which carries small context between services. Release checks: Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.