observability-modeling

Design telemetry by first defining concrete diagnostic questions for key workflows, then mapping each question to required logs, metrics, traces, or events, and finally specifying correlation identifiers to reliably reconstruct failures.

Correlation identifiers must be defined to span async boundaries like queues and external API calls, ensuring that distributed traces and diagnostic events maintain context across system transitions for accurate failure reconstruction.

Align SLO alerting to actionable symptoms by mapping diagnostic questions to specific telemetry signals, ensuring alerts reflect user-impactful failures rather than raw metric thresholds, and validating with an evaluation checklist.

Enforce telemetry constraints by specifying cardinality limits to prevent metric explosion, applying privacy redaction to sensitive attributes, and defining sampling rules to control data volume while preserving diagnosability.

Yes, observability modeling applies to agent workflows, async jobs, APIs, and queues, defining telemetry semantics for logs, metrics, traces, and diagnostic events to support reliable failure reconstruction across these systems.

Diagnostic-question-driven telemetry design may be excessive for simple, stateless scripts where basic logging suffices, as the overhead of defining correlation IDs, span attributes, and SLOs provides limited diagnosability value.