-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Singleton Receiver Creator #34460
Comments
That sounds interesting. A similar approach is used in Metricbeat for covering the cluster level metrics collection when running as part of a Daemonset. II assume we want to achieve something similar here where the Collector will be running only as a Daemonset and the leader will be responsible for enabling the While this is useful from user experience perspective, from my past experience, it can be problematic when it comes to scale. |
Hey @ChrsMark! Thanks for the feedback. Yes, exactly the leader is responsible for enabling a sub-receiver (such as Yes, I fully agree with the concerns about resource limits/requests. However, as you said, it should be properly documented. Not sure if there is a way to workaround it. Regarding putting some extra load on the k8s API - do you mean querying/updating leases? |
@skhalash yes, but this is something that can also be properly documented along with some perf tests results so as users be aware of any possible impact to their clusters. |
The purpose and use-cases of the new component
A receiver creator that can wrap an arbitrary sub-receiver and ensure that only one instance of this sub-receiver is active at a time in a high-availability OTel Collector setup. This setup is useful in a situation where there are multiple collector replicas running, but only one of them is producing telemetry (metrics, data, logs) at a time. The rest of the replicas are not active (standby mode). This mechanism is implemented using leader election.
Example configuration for the component
Telemetry data types supported
traces, metrics, and logs
Is this a vendor-specific component?
Code Owner(s)
@skhalash @a-thaler
Sponsor (optional)
No response
Additional context
I work at SAP on a project called Kyma: https://kyma-project.io/#/. In Kyma, we recently developed such a receiver and we are already testing it out in a production setup: https://github.com/kyma-project/opentelemetry-collector-components/tree/main/receiver/singletonreceivercreator.
We’ve noticed discussions in the community about introducing leader election in the k8sobjects and k8scluster receivers. That's why we believe that a generic mechanism could be quite beneficial. If there’s interest, we are ready to contribute it to the Open Telemetry project.
The text was updated successfully, but these errors were encountered: