A common mistake is scattering the same metadata across every span instead of attaching it once where it belongs. Another is treating RecordError and SetStatus as the same thing. RecordError captures an exception event, while SetStatus marks the span outcome. Using both correctly gives cleaner telemetry and makes error investigation much easier.
Span attributes should be sparse, deliberate, and attached at the right level
Teams often over-annotate traces by copying the same metadata onto every span, then struggle to tell which span actually describes the operation. A better pattern is to attach stable attributes once at the most meaningful span, then let child spans carry only what changes locally. That keeps traces readable, cheaper to store, and easier to query when you are diagnosing failures.
When the same label appears everywhere, filtering becomes noisy and cardinality can climb for no diagnostic gain. The practical test is whether the attribute helps answer a tracing question about that span specifically, or whether it is just ambient context that should live higher in the trace or be derived in analysis.
Useful span attributes usually fall into a few buckets: operation identity, peer or dependency information, request classification, and narrowly scoped business context. If a value is not stable enough to group on, or not specific enough to explain the span’s work, it is usually better omitted than duplicated across the tree.
RecordError and SetStatus solve different problems
Another common mistake is treating RecordError and SetStatus as interchangeable. RecordError captures an exception event so the telemetry shows what was thrown, where it happened, and often the stack or message. SetStatus marks the span outcome, so the trace can say whether the operation completed successfully, failed, or ended with a known error condition.
Those roles matter because not every exception should automatically collapse into the same span status, and not every failed outcome is represented by a thrown error. A span can record an error event and still be marked in a way that reflects the true business outcome, especially when the application catches, transforms, or retries the failure.
The cleanest traces separate event capture from outcome labeling. That gives operators a precise failure timeline without losing the semantic distinction between an exception that occurred and the final state of the work represented by the span.
Cleaner traces come from consistent semantics, not more data
The real problem is usually semantic drift: different teams choose different places to put the same information, or use status and error fields as if they were generic logging helpers. That makes traces harder to aggregate, and it weakens downstream alerting, because automation ends up inferring meaning from inconsistent telemetry instead of from a clear span model.
What to verify: check whether each attribute is attached once at the span that owns the meaning, whether error events are recorded only when there is an actual exception or equivalent failure event, and whether status reflects the final operation result rather than the presence of an error alone.
Common mistake: using tracing to mirror verbose application logs. Traces work best when they describe execution shape and outcome, while logs carry the detailed narrative.
Practitioner takeaway: the strongest traces are not the most decorated ones, they are the ones where attribute placement and error semantics are consistent enough that an operator can reconstruct the failure path without guessing.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Sprawl | Trace metadata often includes identity-bearing context that should not be duplicated everywhere. |
| NHI-06 — Observability and Detection | Trace quality depends on consistent telemetry semantics for diagnosis and investigation. | |
| Recommendation — Keep span attributes minimal and avoid attaching repeated sensitive context to every span. Standardize span naming, attributes, and error semantics so traces stay queryable and actionable. | ||
| CIS Controls v8 | 8.2 — Audit Log Collection | Tracing is an audit-like telemetry source that benefits from consistent event capture and outcome labeling. |
| Recommendation — Define consistent event and status fields so observability data supports investigation and alerting. | ||
| NIST CSF 2.0 | DE.AE-3 — Anomalies and Events are Analyzed | Cleaner trace semantics improve event analysis during troubleshooting and incident response. |
| Recommendation — Use consistent span semantics so trace data can be analyzed for anomalies without ambiguity. | ||
