opentelemetry-collector/receiver
github-actions[bot] acb9d86458
dependabot updates Tue Dec 13 16:51:35 UTC 2022 (#6783)
Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp from 0.36.4 to 0.37.0
Bump go.opentelemetry.io/contrib/propagators/b3 from 1.11.1 to 1.12.0
Bump go.uber.org/multierr from 1.8.0 to 1.9.0
Bump go.uber.org/multierr from 1.8.0 to 1.9.0 in /cmd/builder
Bump go.uber.org/multierr from 1.8.0 to 1.9.0 in /component
Bump go.uber.org/multierr from 1.8.0 to 1.9.0 in /confmap
Bump go.uber.org/multierr from 1.8.0 to 1.9.0 in /pdata
Bump goreleaser/goreleaser-action from 3 to 4

Co-authored-by: bogdandrutu <bogdandrutu@users.noreply.github.com>
2022-12-13 09:25:36 -08:00
..
otlpreceiver dependabot updates Tue Dec 13 16:51:35 UTC 2022 (#6783) 2022-12-13 09:25:36 -08:00
receivertest Remove deprecated componenttest.NewNop*CreateSettings (#6761) 2022-12-12 17:04:07 -08:00
scrapererror Enable errorlint and fix all warnings (#5364) 2022-05-16 10:36:41 -07:00
scraperhelper Remove deprecated comonent.Config.[ID|SetIDName]; Deprecate config.*Settings (#6718) 2022-12-12 14:35:45 -08:00
README.md Remove hostmetricsreceiver from docs (#3904) 2021-08-27 08:23:30 -07:00
doc.go Remove deprecated func/types from component (#6606) 2022-11-22 16:25:10 -08:00
receiver.go Remove deprecated funcs/types from component package (#6769) 2022-12-12 18:12:32 -08:00
receiver_test.go Remove deprecated funcs/types from component package (#6769) 2022-12-12 18:12:32 -08:00

README.md

General Information

A receiver is how data gets into the OpenTelemetry Collector. Generally, a receiver accepts data in a specified format, translates it into the internal format and passes it to processors and exporters defined in the applicable pipelines.

Available trace receivers (sorted alphabetically):

Available metric receivers (sorted alphabetically):

Available log receivers (sorted alphabetically):

The contrib repository has more receivers that can be added to custom builds of the collector.

Configuring Receivers

Receivers are configured via YAML under the top-level receivers tag. There must be at least one enabled receiver for a configuration to be considered valid.

The following is a sample configuration for the examplereceiver.

receivers:
  # Receiver 1.
  # <receiver type>:
  examplereceiver:
    # <setting one>: <value one>
    endpoint: 1.2.3.4:8080
    # ...
  # Receiver 2.
  # <receiver type>/<name>:
  examplereceiver/settings:
    # <setting two>: <value two>
    endpoint: 0.0.0.0:9211

A receiver instance is referenced by its full name in other parts of the config, such as in pipelines. A full name consists of the receiver type, '/' and the name appended to the receiver type in the configuration. All receiver full names must be unique.

For the example above:

  • Receiver 1 has full name examplereceiver.
  • Receiver 2 has full name examplereceiver/settings.

Receivers 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, examplereceiver/settings]
      processors: []
      exporters: [exampleexporter]
    # Trace pipeline 2.
    traces/another:
      receivers: [examplereceiver, examplereceiver/settings]
      processors: []
      exporters: [exampleexporter]

At least one receiver must be enabled per pipeline to be a valid configuration.