nop receiver/exporter as a released components #7316
Comments
|
I'm supportive of this idea, especially the exporter. A nop receiver would primarily be valuable in that it saves trouble configuring some other receiver. We have a few very simple receivers that can be used with very limited configuration, but I can still appreciate that a zero-configuration receiver would be less of a distraction. A nop exporter, on the other hand, has much more value because all exporters introduce non-trivial performance impact. For example, when testing performance bottlenecks in a receiver, I've often seen people use the file exporter or logging exporter, which each introduce performance bottlenecks of their own. A nop exporter would remove this concern entirely. In addition, the same zero-configuration benefit noted for the receiver would apply. |
|
noop receiver/exporter can be also used for OpAMP Boostraping: https://docs.google.com/document/d/1KtH5atZQUs9Achbce6LiOaJxLbksNJenvgvyKLsJrkc/edit#heading=h.uqsttr89cud1 |
**Description:** Add the nopexporter. This can be helpful if a user wants to start the Collector with a dummy pipeline to only enable extensions. It could also be used to test Collector pipeline throughput. **Link to tracking Issue:** Resolves #7316 **Testing:** Added lifecycle tests; the receiver doesn't do anything. **Documentation:** Added a readme for the component. cc @djaglowski @tigrannajaryan
**Description:** Add the nopreceiver. This can be helpful if a user wants to start the Collector with a dummy pipeline to only enable extensions. It could also be used to start a dynamically-configured Collector that starts with no config and waits to receive its config from a confmap.Provider that supports reloads. **Link to tracking Issue:** Works toward #7316 **Testing:** Added lifecycle tests; the receiver doesn't do anything. **Documentation:** Added a readme for the component.
**Description:** Add the nopexporter. This can be helpful if a user wants to start the Collector with a dummy pipeline to only enable extensions. It could also be used to test Collector pipeline throughput. **Link to tracking Issue:** Resolves open-telemetry#7316 **Testing:** Added lifecycle tests; the receiver doesn't do anything. **Documentation:** Added a readme for the component. cc @djaglowski @tigrannajaryan
**Description:** Add the nopreceiver. This can be helpful if a user wants to start the Collector with a dummy pipeline to only enable extensions. It could also be used to start a dynamically-configured Collector that starts with no config and waits to receive its config from a confmap.Provider that supports reloads. **Link to tracking Issue:** Works toward open-telemetry#7316 **Testing:** Added lifecycle tests; the receiver doesn't do anything. **Documentation:** Added a readme for the component.
This will be put into core/contrib in open-telemetry/opentelemetry-collector-releases#519. Realistically we could declare this stable as well, it doesn't seem feasible to introduce breaking changes. **Link to tracking Issue:** #7316
This will be put into core/contrib in open-telemetry/opentelemetry-collector-releases#519. Realistically we could declare this stable as well, it doesn't seem feasible to introduce breaking changes. **Link to tracking Issue:** #7316
**Description:** Add the nop receiver and nop exporter to otelcontribcol. **Link to tracking Issue:** open-telemetry/opentelemetry-collector#7316
**Description:** Add the nop receiver and nop exporter to otelcontribcol. **Link to tracking Issue:** open-telemetry/opentelemetry-collector#7316
**Description:** Add the nop receiver and nop exporter to otelcontribcol. **Link to tracking Issue:** open-telemetry/opentelemetry-collector#7316
Is your feature request related to a problem? Please describe.
The collector requires a fully configured pipeline to startup/validate/run.
There are times when we want to test specific components of a pipeline.
Other times, we just need a placeholder, eg receiver for spanmetricsprocessor.
Or we just want to sinkhole all the data we receive.
Describe the solution you'd like
The
nopreceiver/exporters exist as part of receivertest and exportertest,and also in some example documentation.
I'd like these to become proper receivers/exporters that are included in release builds.
Describe alternatives you've considered
Find a different component with low reqs (otlp receiver, filter+logging exporter) to use as placeholders.
Additional context
https://cloud-native.slack.com/archives/C01N6P7KR6W/p1677735109897419
https://cloud-native.slack.com/archives/C01N6P7KR6W/p1673521760960439
https://cloud-native.slack.com/archives/C01N6P7KR6W/p1632938290251300
https://cloud-native.slack.com/archives/C01N6P7KR6W/p1636486514281000
#5324
The text was updated successfully, but these errors were encountered: