More Collector distros or focus on OCB?

[julianocosta89]

Hello all 👋🏽

I'd like to bring up to discussion a movement that is happening in the community that concerns me.
As user of OTel for a bit more than 4 years I've seen a great evolution in the whole structure of the project, and the future looks promising!

OTel, among other stuff, came to bring a standard and solve vendor lock-in in the observability area.

Having said that I'm seeing a bunch of Collector distros being created (from vendors and from the community itself) and on the other hand not much being said about the OCB.

I get that shipping the collector-contrib is not recommended at all, but we should stress, better document, and make the OCB easier to use, instead of starting creating a bunch of distros.

Why do I think like that?

Lets image I'm running my distributed application in a multi-cloud deployment (AWS, Azure, GCP).
If I opt to use the otelcol-k8s distro I'll miss all cloud related data.

• AWS has 7 different receivers
• Azure has 3
• GCP has 2

Or yet another example. If I have Kafka running in my k8s cluster and I'd like to use the kafkareceiver/kafkametricsreciever I wouldn't be able to use the otelcol-k8s distro.

To solve that I would have to build my own distro using OCB, which personally, I think it should be what the community should recommend.

Am I missing something here?
I just don't get it how having multiple distros would help.

Looks like going back to what we had before, with every vendor using its own solution to monitor the application.

Shouldn't we, as community, continue to push towards a standard?

[mx-psi]

cc @TylerHelmuth

[TylerHelmuth]

@julianocosta89 the official best practice is to create your own distribution of the collector. There are lots of ways to do that, with OCB being the easiest and recommended way. If there are improvements you think OCB needs please open issues.

At the same time, the community benefits from community distributions. For example, the OpenTelemetry Helm Charts for the Collector and Operator both currently use the Contrib image, which is against our own best practices. They do this because, at the time, it was the only image that included k8s components. The Operator's default image is Core, which ultimately doesn't include enough components by default for Kubernetes.

Also, not everyone wants to make their own distribution. Building a distribution means maintaining something, whether thats code, configuration, pipelines, etc, and hosting the images/artifacts. For users that don't want to do this, we can create distributions that will hopefully get closer to their needs than Contrib.

You can view the rational behind the new k8s distribution here and the other distributions here.

I do not feel the community needs to choose 1 strategy over another. Improving OCB can be a goal, while at the same time we can create meaningful community distributions that helps users who do not want to build their own distribution.

As for vendor distributions, that is part of the Collector being Free Open Source Software and modular. We have no plans to restrict collector libraries from anyone and anyone is free to build distributions or code with our code. And while any vendor (or user) may choose what to put in their distribution, many choose to add Collector Core and Contrib components, so the distributions end up sharing the same solutions for monitoring.

[julianocosta89]

Hey @TylerHelmuth thanks for the reply.

I agree with you in regards vendor distributions, and I think we shouldn't restrict anyone at all.

Thinking this further, it would be great to a have a bigger involvement from all Cloud Providers in creating a broader Semantic Conventions for them (https://opentelemetry.io/docs/specs/semconv/cloud-providers/).
Then we could have a generic cloud receiver or processor, but that's just me dreaming about a better future 😅 .

Going back to the topic, I've missed the initial discussion, sorry about that, just getting more time to invest in the community in the new job.

I get that users do not want to build and maintain their own distro, but then we could structure the Operator in a way that it builds the collector based on the components the user has configured.
I think this is actually doable and would give users more freedom to chose off-the-shelf components.
The Operator, should also be able to manage the lifecycle of the collector as well as upgrade components.

The responsibility in maintaining would continue on the maintainers and code owners' desk.

WDYT?

Regarding documentation, I've created an issue for that: open-telemetry/opentelemetry.io#4315

[jpkrohling]

One thing we discussed in the past is that we need better tooling before really pushing users to build their distributions.

• A Web UI a la start.spring.io so that users can select which components they want
• A GitHub Action that can build distributions based on manifests. I think we might have this in the community already

That said, we should make it easy for users of common use-cases and provide distributions for them. That's where the k8s distribution comes in handy. We also need one or two distributions to be officially "supported", so that users can get the bits we produce and have confidence that they will work.

[TylerHelmuth]

I get that users do not want to build and maintain their own distro, but then we could structure the Operator in a way that it builds the collector based on the components the user has configured.
I think this is actually doable and would give users more freedom to chose off-the-shelf components.
The Operator, should also be able to manage the lifecycle of the collector as well as upgrade components.

We've discussed this possibility in the operator before and it is non-trivial (if not impossible). The Operator would need to read a config, then build and host an image, and then reference it. It also does not solve the problem for users who do not want to use an operator (people can achieve their goals on k8s with only the collector helm chart) or for users who are not using kubernetes.

[julianocosta89]

• A Web UI a la start.spring.io so that users can select which components they want

@jpkrohling that's really great