A dependency bump reached the go.sum files but not the go.mod files: 27 modules still required go.uber.org/zap v1.27.1 while their go.sum carried only v1.28.0. Go then refused to build them at all — 43 modules answered `go list ./...` with "updates to go.mod needed" or "missing go.sum entry". They went unnoticed because every one of them sorts after cmd/otelcorecol, and gotest walks the modules in sorted order and stops at the first error, so the walk never reached them. Adding the missing sums to the four modules before that point moves the wall without removing it. Ran the tree's own tidy in every module, pinning each module's existing go directive so the local toolchain cannot raise it. cmd/otelcorecol is generated and carries a DO-NOT-EDIT header, so its result was checked against `make genotelcorecol`: byte-identical, go.mod and go.sum both. The rest is the convergence that bump implied — zap 1.27.1 -> 1.28.0, otel 1.40 -> 1.45, grpc 1.79.1 -> 1.80.0 and the x/ packages that follow them. Two requirements were missing outright (hashicorp/golang-lru/v2, go.yaml.in/yaml/v2) and configgrpc gained the root collector module it already replaces locally. mostynb/go-grpc-compression leaves the graph; no .go file imports it. go list ./... is clean in all 118 modules and no go directive moved.
Debug Exporter
| Status | |
|---|---|
| Stability | alpha: traces, metrics, logs, profiles |
| Distributions | core, contrib, k8s |
| Warnings | Unstable Output Format |
| Issues | |
| Code Owners | @andrzej-stencel |
Outputs telemetry data to the console for debugging purposes.
See also the Troubleshooting document for examples on using this exporter.
Getting Started
The following settings are optional:
verbosity(default =basic): the verbosity of the debug exporter:basic,normalordetailed. See Verbosity levels below for more information.sampling_initial(default =2): number of messages initially logged each second.sampling_thereafter(default =1): sampling rate after the initial messages are logged (every Mth message is logged). The default value of1means that sampling is disabled. To enable sampling, changesampling_thereafterto a value higher than1. Refer to Zap docs for more details on how sampling parameters impact number of messages.use_internal_logger(default =true): uses the collector's internal logger for output. See below for description.output_paths(default =["stdout"]): a list of file paths to write output to. This option can only be used whenuse_internal_loggerisfalse. Special strings "stdout" and "stderr" are interpreted as standard output and standard error respectively. All other values are treated as file paths. Settingoutput_pathswhenuse_internal_loggeristrueresults in a configuration error.sending_queue(disabled by default): see Sending Queue for the full set of available options.
Example configuration:
exporters:
debug:
verbosity: detailed
sampling_initial: 5
sampling_thereafter: 200
Example configuration with custom output path:
exporters:
debug:
use_internal_logger: false
output_paths:
- stderr
Verbosity levels
The following subsections describe the output from the exporter depending on the configured verbosity level - basic, normal and detailed.
The default verbosity level is basic.
To understand how the below example output was generated, see Generating example output.
Basic verbosity
With verbosity: basic, the exporter outputs a single-line summary of received data with a total count of telemetry records for every batch of received logs, metrics or traces.
Here's an example output:
2025-04-17T10:40:44.559+0200 info Traces {"otelcol.component.id": "debug/basic", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces", "resource spans": 1, "spans": 2}
Normal verbosity
With verbosity: normal, the exporter outputs about one line for each telemetry record.
The "one line per telemetry record" is not a strict rule.
For example, logs with multiline body will be output as multiple lines.
Here's an example output:
2025-05-09T19:57:16.332+0200 info Traces {"resource": {}, "otelcol.component.id": "debug/normal", "otelcol.component.kind": "exporter", "otelcol.signal": "traces", "resource spans": 1, "spans": 2}
2025-05-09T19:57:16.332+0200 info ResourceTraces #0 [https://opentelemetry.io/schemas/1.25.0] service.name=telemetrygen
ScopeTraces #0 telemetrygen
okey-dokey-0 ab1030bd4ee554af936542b01d7b4807 1d8c93663d043aa8 net.sock.peer.addr=1.2.3.4 peer.service=telemetrygen-client
lets-go ab1030bd4ee554af936542b01d7b4807 0d238e8a2f97733f net.sock.peer.addr=1.2.3.4 peer.service=telemetrygen-server
{"resource": {}, "otelcol.component.id": "debug/normal", "otelcol.component.kind": "exporter", "otelcol.signal": "traces"}
Detailed verbosity
With verbosity: detailed, the exporter outputs all details of every telemetry record, typically writing multiple lines for every telemetry record.
Here's an example output:
2025-04-17T10:40:44.560+0200 info Traces {"otelcol.component.id": "debug/detailed", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces", "resource spans": 1, "spans": 2}
2025-04-17T10:40:44.560+0200 info ResourceSpans #0
Resource SchemaURL: https://opentelemetry.io/schemas/1.25.0
Resource attributes:
-> service.name: Str(telemetrygen)
ScopeSpans #0
ScopeSpans SchemaURL:
InstrumentationScope telemetrygen
Span #0
Trace ID : fafdac970271dd2ce89de2442c0518c7
Parent ID : d98de4cb8e2a0ad6
ID : 3875f436d989d0e5
Name : okey-dokey-0
Kind : Server
Start time : 2025-04-17 08:40:44.555461596 +0000 UTC
End time : 2025-04-17 08:40:44.555584596 +0000 UTC
Status code : Unset
Status message :
Attributes:
-> net.sock.peer.addr: Str(1.2.3.4)
-> peer.service: Str(telemetrygen-client)
Span #1
Trace ID : fafdac970271dd2ce89de2442c0518c7
Parent ID :
ID : d98de4cb8e2a0ad6
Name : lets-go
Kind : Client
Start time : 2025-04-17 08:40:44.555461596 +0000 UTC
End time : 2025-04-17 08:40:44.555584596 +0000 UTC
Status code : Unset
Status message :
Attributes:
-> net.sock.peer.addr: Str(1.2.3.4)
-> peer.service: Str(telemetrygen-server)
{"otelcol.component.id": "debug/detailed", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces"}
Using the collector's internal logger
When use_internal_logger is set to true (the default), the exporter uses the collector's internal logger for output.
This comes with the following consequences:
- The output from the exporter may be annotated by additional output from the collector's logger.
- The output from the exporter is affected by the collector's logging configuration specified in
service::telemetry::logs.
When use_internal_logger is set to false, the exporter does not use the collector's internal logger.
Changing the values in service::telemetry::logs has no effect on the exporter's output.
The exporter's output is sent to the paths specified in output_paths (default: ["stdout"]).
You can configure output_paths to send output to stderr, a file, or multiple destinations.
Warnings
- Unstable Output Format: The output formats for all verbosity levels is not guaranteed and may be changed at any time without a breaking change.