How should platform teams decide what belongs in metrics versus logs or traces?

How to choose between metrics, logs, and traces

The split starts with the question of cardinality and purpose, not tooling preference. Metrics are for stable signals you want to compare over time or across a population. Logs and traces are for detail that is tied to a specific request, object, session, or execution path and may need to be inspected after the fact. That difference matters because observability systems break down when high-cardinality values are treated like metrics.

Good metrics describe the shape of the system: latency percentiles, error rates, queue depth, saturation, and other values that stay bounded enough to be aggregated. Logs describe events and context: who did what, to which object, under which condition, and with what result. Traces sit between the two, showing the path a request took across services, spans, retries, and dependencies. The right choice is the one that preserves signal without turning every new entity into a new time series.

A useful rule is to ask whether the field answers a population question or a case question. If the field is meant to summarize behaviour across many users, requests, pods, or sessions, it belongs in a metric. If the field is needed to reconstruct one specific incident, authenticate a sequence of events, or understand one execution path, it belongs in logs or traces. This is why identifiers, UUIDs, request IDs, user IDs, pod names, and session tokens are usually poor metric labels even when they are valuable in logs.

Where the boundary becomes operationally important

Boundary mistakes usually show up as cost, noise, or blind spots. A metric label that varies per request creates unbounded cardinality, which makes aggregation expensive and often useless. The reverse mistake is just as harmful: compressing distinct request failures into a single metric can hide the one object, tenant, or dependency that is actually failing. In practice, teams should preserve the coarse signal in metrics and retain the forensic path in logs or traces.

For platform teams, traces are often the better home for request-scoped identity and dependency detail because they preserve causality without forcing every attribute into a global aggregation key. Logs are better when the event itself matters, especially for auditability, retries, authorization decisions, and unusual error conditions. Metrics are best when the team needs alerting, capacity planning, SLO tracking, or trend detection. If the field would be meaningless when averaged across the population, it is probably not a metric.

The same test applies to pod restarts, container IDs, object IDs, and customer-specific tags. Those values are useful for investigation, but they are usually the wrong shape for monitoring. A metric that changes whenever the deployment or tenancy changes can no longer answer the questions operators actually ask. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates auditability and monitoring concerns from configuration and access-control discipline, which is exactly the kind of distinction platform teams need.

Practical rules for instrumenting platform services

Start by deciding what you need to observe: health, behaviour, or evidence. Health should usually become a metric. Behaviour that needs per-request context should become a trace. Evidence that might later support incident response, debugging, or control review should become a log entry with enough structure to be searchable and correlated. Once that purpose is clear, the field placement usually follows naturally.

What to verify: confirm that every metric label has bounded cardinality and a stable lifecycle. If a field can grow with tenants, sessions, objects, deployments, or identities, keep it out of the metric dimension unless it is aggressively controlled and genuinely low-cardinality.

Decision rule: if operators need to alert on it, trend it, or compare it across the fleet, make it a metric. If investigators need the exact value for a single case, make it a log field or trace attribute. If you are unsure, prefer the more detailed channel and derive the aggregate later.

Common mistake: teams often put too much identity-like detail into metric tags because dashboards are convenient. That creates fragile queries, inflated storage, and alerts that are hard to maintain. It is better to keep metrics boring and bounded, then enrich logs or traces where the per-event detail belongs.

Practitioner Guidance

What to measure: watch the number of active time series, label churn, and dashboard query cost. Those are early signals that a metric is being used as a logging system.

Trade-off: the more identity or object detail you push into metrics, the less stable and reusable those metrics become. You gain specificity for one investigation, but you lose the long-term comparability that makes metrics valuable.

Practitioner takeaway: design observability by reuse, not by convenience, keep metrics small and durable, and push request-specific identity detail into logs or traces where it can be searched without exploding cardinality.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How do teams decide whether AI governance belongs in security, privacy, or platform engineering?
• How should teams decide whether observability belongs in a platform or a point tool?
• How should teams implement OpenTelemetry in a way that avoids lock-in across metrics, logs, and traces?