Skip to main content
This article gives a concise, practical guide to the OpenTelemetry Collector debug exporter: what it is, how to configure it, and when to use it. The debug exporter writes telemetry (traces, metrics, logs) to the collector’s logs (stdout/stderr) with configurable verbosity and optional sampling. It is ideal for validating data, testing new configurations, and troubleshooting pipeline behavior during development.
The debug exporter is intended for debugging and testing only — it is not recommended for production use.
The image is a flowchart introducing a "Debug Exporter" involving stages like Testing, Validation, and Troubleshooting within Pipelines.

​
What the debug exporter does

  • Emits telemetry payloads to the collector log stream so you can inspect them in real time.
  • Supports verbosity levels to control how much information is printed.
  • Offers sampling controls to limit output volume in high-throughput environments.
Sampling is useful to keep log output manageable when telemetry rates are high.
Note: Setting sampling_initial and sampling_thereafter reduces how many items are printed (for example, the first N items are printed, then 1 in M thereafter). To actually see output for a given signal (traces, metrics, logs), include the debug exporter in that signal’s pipeline. If not referenced in a pipeline, the collector will not print that signal’s data. Example minimal configuration that enables the debug exporter for all three signals:

​
Verbosity levels

Verbosity controls how much the debug exporter prints. The three supported levels are basic, normal, and detailed. Use the appropriate level depending on how much inspection you need.
VerbosityWhat it printsWhen to use it
basicOne-line summaries with resource metadata, component ID, signal type, and counts.Quick confirmation of data flow and volume.
normalResource and instrumentation scope metadata plus counts.Inspect provenance and scopes without full payloads.
detailedFull payloads: complete spans, metrics, or log records including attributes and events.Deep debugging; inspect attribute values, events, and IDs.
The image shows three verbosity options: "Basic," "Normal," and "Detailed." The "Basic" option is highlighted and indicates it "prints one-line summaries of counts."
Example log entries produced with basic verbosity:
The normal level augments the above with resource and scope metadata. The detailed level prints full payloads including attributes and events.
The image shows three verbosity options: Basic, Normal, and Detailed, with Detailed being highlighted and described as printing full payloads including attributes and events.
A trimmed example of a detailed span record:
Detailed output is particularly useful to:
  • validate payload structure,
  • confirm context propagation (e.g., consistent trace IDs across spans),
  • inspect attribute and field transformations applied by processors, and
  • diagnose pipeline routing or dropping issues.
Be cautious: detailed debug output can include sensitive information and generate very large log volumes. Do not enable detailed verbosity in production. If needed, redirect collector stdout/stderr to a controlled file and restrict access.

​
Additional notes and best practices

  • The collector’s global logging level (e.g., DEBUG, INFO, WARN, ERROR) controls the collector’s own logs and is separate from the debug exporter verbosity.
  • Debug exporter verbosity options: basic | normal | detailed.
  • Persisting debug output: redirect stdout/stderr when launching the collector (for example, shell redirection or container log drivers).
  • Use sampling parameters (sampling_initial, sampling_thereafter) to reduce noise when testing high-throughput pipelines.
This concludes the overview of the debug exporter.

Watch Video