go.opentelemetry.io/collector/receiver
Package receiver defines components that allows the collector to receive metrics, traces and logs. Receiver receives data from a source (either from a remote source via network or scrapes from a local host) and pushes the data to the pipelines it is attached to by calling the nextConsumer.Consume*() function. The nextConsumer.Consume*() function may return an error to indicate that the data was not accepted. There are 2 types of possible errors: Permanent and non-Permanent. The receiver must check the type of the error using IsPermanent() helper. If the error is Permanent, then the nextConsumer.Consume*() call should not be retried with the same data. This typically happens when the data cannot be serialized by the exporter that is attached to the pipeline or when the destination refuses the data because it cannot decode it. The receiver must indicate to the source from which it received the data that the received data was bad, if the receiving protocol allows to do that. In case of OTLP/HTTP for example, this means that HTTP 400 response is returned to the sender. If the error is non-Permanent then the nextConsumer.Consume*() call should be retried with the same data. This may be done by the receiver itself, however typically it is done by the original sender, after the receiver returns a response to the sender indicating that the Collector is currently overloaded and the request must be retried. In case of OTLP/HTTP for example, this means that HTTP 429 or 503 response is returned. The receivers that receive data via a network protocol that support acknowledgments MUST follow this order of operations: This ensures there are strong delivery guarantees once the data is acknowledged by the Collector. Similarly, receivers that use checkpointing to remember the position of last processed data (e.g. via storage extension) MUST store the checkpoint only AFTER the Consume*() call returns.
Readme
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.
This repository hosts the following receiver available in traces, metrics and logs pipelines:
The contrib repository has more receivers available in its builds.
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:
examplereceiver.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.
FAQs
Package receiver defines components that allows the collector to receive metrics, traces and logs. Receiver receives data from a source (either from a remote source via network or scrapes from a local host) and pushes the data to the pipelines it is attached to by calling the nextConsumer.Consume*() function. The nextConsumer.Consume*() function may return an error to indicate that the data was not accepted. There are 2 types of possible errors: Permanent and non-Permanent. The receiver must check the type of the error using IsPermanent() helper. If the error is Permanent, then the nextConsumer.Consume*() call should not be retried with the same data. This typically happens when the data cannot be serialized by the exporter that is attached to the pipeline or when the destination refuses the data because it cannot decode it. The receiver must indicate to the source from which it received the data that the received data was bad, if the receiving protocol allows to do that. In case of OTLP/HTTP for example, this means that HTTP 400 response is returned to the sender. If the error is non-Permanent then the nextConsumer.Consume*() call should be retried with the same data. This may be done by the receiver itself, however typically it is done by the original sender, after the receiver returns a response to the sender indicating that the Collector is currently overloaded and the request must be retried. In case of OTLP/HTTP for example, this means that HTTP 429 or 503 response is returned. The receivers that receive data via a network protocol that support acknowledgments MUST follow this order of operations: This ensures there are strong delivery guarantees once the data is acknowledged by the Collector. Similarly, receivers that use checkpointing to remember the position of last processed data (e.g. via storage extension) MUST store the checkpoint only AFTER the Consume*() call returns.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
A hospital in Mobile, Alabama, agreed to a settlement in a landmark ransomware death lawsuit, but is now reportedly reconsidering the agreement and refusing to pay.
Security News
A new report explores how advancements in LLMs are enhancing cyber threats, including polymorphic malware, personalized spearphishing, and the risk of hijacking customer service bots.
Security News
ESLint has approved an RFC that adds support for TypeScript configuration files, which is aimed at improving the developer experience and recognizing changes in the evolving JavaScript ecosystem.