#### Description Adds displaying of resource and scope details in `normal` verbosity. Each resource is represented with one line showing the resource's details: - schema URL - resource attributes which looks like `ResourceTraces #0 [resource-schema-url] resource_attr1=value1 attr2=value2`. Each instrumentation scope is represented by one line showing the scope's details: - scope name - scope version - scope schema URL - scope attributes which looks like `ScopeTraces #0 scope-name@scope-version [scope-schema-url] scope_attr1=value1 attr2=value2`. Before: ```console 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 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"} ``` After: ```console 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"} ``` #### Link to tracking issue Fixes https://github.com/open-telemetry/opentelemetry-collector/issues/10515 #### Testing Updated unit tests. #### Documentation Updated example in documentation. |
||
---|---|---|
.. | ||
debugexporter | ||
exporterhelper | ||
exportertest | ||
internal/experr | ||
nopexporter | ||
otlpexporter | ||
otlphttpexporter | ||
xexporter | ||
Makefile | ||
README.md | ||
example_test.go | ||
exporter.go | ||
exporter_test.go | ||
go.mod | ||
go.sum | ||
package_test.go |
README.md
General Information
An exporter defines how the pipeline data leaves the collector.
This repository hosts the following exporters available in traces, metrics and logs pipelines (sorted alphabetically):
The contrib repository has more exporters available in its builds.
Configuring Exporters
Exporters are configured via YAML under the top-level exporters
tag.
The following is a sample configuration for the exampleexporter
.
exporters:
# Exporter 1.
# <exporter type>:
exampleexporter:
# <setting one>: <value one>
endpoint: 1.2.3.4:8080
# ...
# Exporter 2.
# <exporter type>/<name>:
exampleexporter/settings:
# <setting two>: <value two>
endpoint: 0.0.0.0:9211
An exporter instance is referenced by its full name in other parts of the config, such as in pipelines. A full name consists of the exporter type, '/' and the name appended to the exporter type in the configuration. All exporter full names must be unique.
For the example above:
- Exporter 1 has full name
exampleexporter
. - Exporter 2 has full name
exampleexporter/settings
.
Exporters are enabled upon being added to a pipeline. For example:
service:
pipelines:
# Valid pipelines are: traces, metrics or logs
# Trace pipeline 1.
traces:
receivers: [examplereceiver]
processors: []
exporters: [exampleexporter, exampleexporter/settings]
# Trace pipeline 2.
traces/another:
receivers: [examplereceiver]
processors: []
exporters: [exampleexporter, exampleexporter/settings]
Data Ownership
When multiple exporters are configured to send the same data (e.g. by configuring multiple exporters for the same pipeline):
- exporters not configured to mutate the data will have shared access to the data
- exporters with the Capabilities to mutate the data will receive a copy of the data
Exporters access export data when ConsumeTraces
/ConsumeMetrics
/ConsumeLogs
function is called. Unless exporter's capabilities include mutation, the exporter MUST NOT modify the pdata.Traces
/pdata.Metrics
/pdata.Logs
argument of
these functions. Any approach that does not mutate the original pdata.Traces
/pdata.Metrics
/pdata.Logs
is allowed without the mutation capability.
Proxy Support
Beyond standard YAML configuration as outlined in the individual READMEs above, exporters that leverage the net/http package (all do today) also respect the following proxy environment variables:
- HTTP_PROXY
- HTTPS_PROXY
- NO_PROXY
If set at Collector start time then exporters, regardless of protocol, will or will not proxy traffic as defined by these environment variables.