Logs, metrics and traces

Imagine an invented record system with a site summary, an inspection notebook and a linked checklist for each visit. The summary reveals how many visits reported a problem. A checklist shows which activities belonged to one visit. The notebook records what someone observed during an activity. Looking at more summary totals cannot recover a sentence that was never included there.

Record	Signal role
Summary grouped by site and outcome	Metric series
Individual observation note	Log event
Linked activities in one inspection	Trace and spans
Visit reference on a note	Correlation identifier

This is a recordkeeping analogy, not a claim about beekeeping practice. A trace represents instrumented work, not necessarily every activity. A log is not inherently an explanation; it helps only when useful information was recorded. Trace relationships also do not establish that a particular operation caused a failure. S3 S4

Metrics are convenient for trends and alert conditions because many observations can collapse into a compact aggregate. That advantage depends on dimensions. Every distinct label combination creates another time series in the Prometheus model, with storage, memory and processing costs. A unique request identifier can defeat the intended aggregation. The fixture demonstrates series growth; it does not measure a vendor bill or establish a universal price ordering. S2 S5

Logs and traces can retain individual identifiers without making those identifiers metric dimensions. They still have collection and storage costs; more detail is not free. Choose fields for a concrete diagnostic question and apply the system's data-handling policy. The useful workflow is to move from an aggregate symptom to a relevant operation and then to its event details, checking correlation rather than assuming adjacent records belong together. This is a workflow, not a rule that every investigation must start from an alert. S3 S4