Errors, traces, logs, metrics: when to reach for what

Summary

Modern application telemetry relies on four overlapping signals: errors, traces, logs, and metrics. Each telemetry type addresses distinct engineering questions and powers specific debugging workflows. Errors track grouped, actionable application crashes, whereas traces map timing and execution paths across dependency waterfalls. Metrics aggregate numerical measurements across historical deployments, and logs preserve complete state and decision-making context at specific moments in execution. Emitting telemetry directly into the format needed for a given workflow proves superior to relying on a single wide event, as tools like AI coding agents require structured spans to optimize execution paths while human debuggers rely on unsampled logs and metrics to pinpoint silent failures.

Context

Developers and automated coding agents frequently struggle to decide whether to emit an error, trace, log, or metric when instrumenting application code due to functional overlap across telemetry types.

Approach / What changed

Map each telemetry type to a distinct operational question and retention strategy, emitting structured data into the dedicated signal format required by target workflows such as error tracking, dependency tracing, or metrics aggregation.

Takeaways

• Traces suit sampled representation because percentage data adequately reveals latency bottlenecks, whereas logs and metrics should remain unsampled to isolate rare failures and track accurate aggregate trends.
• AI coding agents like Codex can directly analyze structured trace dependency trees with span timing to parallelize async operations without reconstructing call graphs from raw log lines.
• Emitting a single wide event is insufficient for diverse operational workflows because raw columnar events cannot natively deduplicate into issues, build waterfalls, or trigger real-time threshold alerts.

Related reading

• Sentry · Jul 1, 2026

  Reading the agent traces is how you make the call your eval can't

  Automated evaluations often miss unknown failure modes in AI agents because developers only write tests for anticipated errors. While building an itinerary agent for AI Engineer World's Fair, an open-weight model routed a speaker query to a tool returning only tracks, leading the model to hallucinate famous speakers and falsely claim the tool provided that data. Because a tool was executed, the trace appeared grounded until inspectable tool outputs revealed the discrepancy. To resolve this, the author retained the inexpensive model, corrected query routing, tightened system prompts against ungrounded entities, and added a custom entity-diffing eval in CI. Ultimately, directly reading agent telemetry traces alongside errors and logs is essential for diagnosing root causes and deciding trade-offs between model costs, prompt adjustments, and routing fixes.

  Sergiy Dybskiy

• Sentry · Jul 9, 2026

  When and what should I be logging?