publish ebf as otel collector module

[cforce]

Is your feature request related to a problem? Please describe.

I need to setup and run additional processes to enable ebf collection on devices(eg iot). I want to have the features as part and integrated into the otel collector process.

Describe the solution you'd like

Provide the collector and reducer feature set as opentelemetry collector modules which can be optional integrated as receiver and /or processor module.

Describe alternatives you've considered

No response

Additional context

No response

[utezduyar]

wouldn't this fall under "hostmetrics" ?

[cforce]

What about metrics from https://github.com/open-telemetry/opentelemetry-ebpf/blob/main/docs/kernel-collector.md - are those covered in hostmetrics.
What about embedding reducer https://github.com/open-telemetry/opentelemetry-ebpf/blob/main/docs/reducer.md otel collector receiver for inbound ebpf stream pushed from "ebpf collector's" running on the same edge but on "low" resource devices:
The otel collector would be "the" gate on the edge for all controllers around at the same iot edge , kind of a gateway to the backend collecting epbf requests.

[utezduyar]

What I meant was to suggest if this software features should be offered under hostmetrics receiver or not. What hostmetrics offer and what this project offers is really about the hostmetrics and it would be nice to have all the configuration in one receiver. But I understand why it might benefit to keep separate too.

[atoulme]

I think you are referring to the encapsulation of the eBPF collector as a receiver directly available as part of the receivers of the OpenTelemetry collector.

The collector right now doesn't allow cross-compilation of C components (it builds with CGO=0).

https://github.com/open-telemetry/opentelemetry-collector/blob/main/CONTRIBUTING.md#using-cgo

Now, we could build a separate go receiver that encapsulates the eBPF collector and offer it for folks who want to build their own collector distribution.

[cforce]

"prohibited due to the lack of portability and complexity"
Would it generally work? The problem on IOT devices mostly is that go is not the first citizen, whereas c is one.
Switching CGO=1 for a collector with ebf "onboard" ..would make sense a lot, doesn't it?
It would be great if you can provide a manual how to build the ebf (as ebf receiver using c libs) included in a "custom" collector build. I already use the ocb builder to craft my own binary why not add CG0=1 and with your manual the ebpf part and make it work on dedicated hardware.

[atoulme]

From the SIG meeting: what problem are we trying to solve? Are we trying to slim down the solution to one binary, which compiles both the eBPF collector and the OpenTelemetry Collector?

Given that you mention that Go is not a first class citizen on iot devices, why not instead deploy the kernel collector on the device and move off the reducer to a central location? Then it might make sense to create a reducer receiver.

[cforce]

Sorry..maybe i made it not clear, the reducer as an otel collector receiver is exactly what i requested, where as the eBpf collector can run in x instances in the outer rim of that iot/edge device where resources are tight and go is not welcome but still push it to the collector where its gets reduced and forwarded to the cloud
The request was mean't to create a collector receiver for the reducer which can listen on inbound requests from any kernel collector process and being compiled natively.
@atoulme