README
¶
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.
Documentation
¶
Overview ¶
Package receiver contains implementations of Receiver components.
To implement a custom receiver you will need to implement component.ReceiverFactory interface and component.Receiver interface.
To make the custom receiver part of the Collector build the factory must be added to defaultcomponents.Components() function.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
observ
package observ contains logic pertaining to the internal observation of the fluent forward receiver.
|
package observ contains logic pertaining to the internal observation of the fluent forward receiver. |
|
internal/perfcounters
Package perfcounters is a thin wrapper around https://godoc.org/github.com/leoluk/perflib_exporter/perflib that provides functions to scrape raw performance counter data, without calculating rates or formatting them, from the registry.
|
Package perfcounters is a thin wrapper around https://godoc.org/github.com/leoluk/perflib_exporter/perflib that provides functions to scrape raw performance counter data, without calculating rates or formatting them, from the registry. |
|
nopreceiver
module
|
|
|
ocmetrics
Package ocmetrics is the logic for receiving OpenCensus metrics proto from already instrumented applications and then passing them onto a metricsink instance.
|
Package ocmetrics is the logic for receiving OpenCensus metrics proto from already instrumented applications and then passing them onto a metricsink instance. |
|
octrace
Package octrace is the logic for receiving OpenCensus trace protobuf defined spans from already instrumented applications and then passing them onto a TraceReceiverSink instance.
|
Package octrace is the logic for receiving OpenCensus trace protobuf defined spans from already instrumented applications and then passing them onto a TraceReceiverSink instance. |
|
Package prometheusreceiver has the logic for scraping Prometheus metrics from already instrumented applications and then passing them onto a metricsink instance.
|
Package prometheusreceiver has the logic for scraping Prometheus metrics from already instrumented applications and then passing them onto a metricsink instance. |