There are three distributions of otelcol to chose from, two "standard" and one custom:

• otelcol-core: smallest distribution, mostly supports pure otlp for traces, logs and metrics, as well as a few de-facto standard receivers and exporters. Main concern: Limited processors selection.
• otelcol-contrib: includes quite a few receivers, processors and exporters with varying degrees of stability and usefulness. Main concern: Includes unnecessary modules for our use case.
• otelcol-wmf: An hypothetical wmf distribution of otelcol. The official documentation encourages building custom distributions using otelcol-core as a base and adding needed modules with ocb. In that case, we need to build a list of the receivers, processors and exporters we want to include on top of otelcol-core. Main concern: May take a long time to get right for a v0.

A possible approach to reduce time to release is to build the first versions of otelcol-wmf either:

• Based on otelcol-contrib, removing obviously unnecessary modules and reviewing after a time which modules are actually needed: fastest approach, risk of leaving unused modules in the distribution, risk of relying on specific protocols instead of standardizing on otlp standard
• Based on otelcol-core, building up from there adding modules as we go: limits the first iteration to standard otlp, may need a lot of iterations of the distribution to get our desired modules list right

Thanks Clement!

I think basing on otelcol-contrib is probably the easiest/best thing to do
for v0. Sound good to you?

Sounds good. Will get on the repackaging.

@MoritzMuehlenhoff What are your thoughts on importing the raw otelcol-contrib_0.62.1_linux_amd64.deb from https://github.com/open-telemetry/opentelemetry-collector-releases/releases into our third-party component in order to have a v0 up quickly, and work on building our own distribution and package of it based on our usage down the road?

I took a quick look at otelcol-contrib_0.62.1_linux_amd64.deb and looks good to me, I think we can import it into bullseye-wikimedia as-is.

There doesn't appear to be an apt repo as @Clement_Goubert mentioned. Lacking that and going forward the next best thing would probably be to see how feasible it is to establish trust between a set of developer gpg keys and the artifacts we're downloading/importing (not a blocker for now).

For reference the commands to issue on apt1001.wikimedia.org are the following:

reprepro includedeb bullseye-wikimedia otelcol-contrib_0.62.1_linux_amd64.deb
# if the package needs to be available on buster
reprepro copy buster-wikimedia bullseye-wikimedia otelcol-contrib

In T320551#8316349, @Clement_Goubert wrote:

@MoritzMuehlenhoff What are your thoughts on importing the raw otelcol-contrib_0.62.1_linux_amd64.deb from https://github.com/open-telemetry/opentelemetry-collector-releases/releases into our third-party component in order to have a v0 up quickly, and work on building our own distribution and package of it based on our usage down the road?

Ack, let's do that. It's not pretty, but there's no showstoppers/red flags.

I'll be importing it to a new thirdparty component, as the future package will probably have a different name than otelcol-contrib. It'll be cleaner that way.

Change 849089 had a related patch set uploaded (by Clément Goubert; author: Clément Goubert):

[operations/puppet@production] aptrepo: add component thirdparty/otelcol-contrib

https://gerrit.wikimedia.org/r/849089

Change 849089 merged by Clément Goubert:

[operations/puppet@production] aptrepo: add component thirdparty/otelcol-contrib

https://gerrit.wikimedia.org/r/849089

Mentioned in SAL (#wikimedia-operations) [2022-10-25T15:30:17Z] <claime> added package otelcol-contrib_0.62.1_linux_amd64.deb to component thirdparty/otelcol-contrib for bullseye-wikimedia and buster-wikimedia - T320551