Support multiple resources/controllers

[skonto]

• What is the proper way to add multiple resource support? I am looking at the comment here and that lock is used only to get the exporter's controller during collector's collect calls. Should each prometheus exporter support an array of controllers instead?
• What happens when a resource is dynamically managed due its short lifecycle and we want to remove it from a specific controller, is there a way to do so?

[skonto]

@MrAlias is this part of the roadmap? Should I create a PR?

[MrAlias]

@skonto thanks for the question. At this time we are focusing on delivering a 1.0.0 release candidate that will implement the 1.0.1 release of the OpenTelemetry specification. This work is centered on tracing and context propagation, but it does not include metrics. For that reason this is not something we will be prioritizing at this time. Especially since there is large effort in the OpenTelemetry project to overhaul the metric signal implementation.

[MrAlias]

@skonto FWIW, the specification defines resources as immutable types and states their association with providers as being constant. We'll need to wait for the metric specification to solidify before we can make changes to how the controller handles this association.

[skonto]

@MrAlias thank you. I am interested in this because we have this requirement at knative monitoring where multiple resources have a lifecycle within a specific process. I am doing a spike to see if we can migrate to this new lib. Let me know if I can help in anyway.

[MrAlias]

@skonto thanks for the link, that is really exciting that you all are considering migrating! However, I would recommend holding off for a few months based on current re-evaluations of the OTel metric SIG. We recently reached out the community for feedback and based on this feedback there was internal desire to re-evaluate the API that was linked to (particularly to better support the Prometheus data model). I would hate to have you all migrate to our project to only have to then migrate to a new version if that is the ultimate decision of the Metric SIG.

@jmacd does this seems like a reasonable suggestion to you?

[skonto]

@MrAlias

FWIW, the specification defines resources as immutable types and states their association with providers as being constant.

I am looking for a way to associate N resources with a controller and dynamically de-associate them from it. Is there a pointer for the requirements captured by Metric SIG, I would like to provide feedback about this use case.

[MrAlias]

@skonto I think it would be worth attending the metric SIG meetings or maybe posting in the slack channel.

The merging of multiple resource into a single one is currently supported with the Merge function, but, by design, association with a controller is static.

[MrAlias]

@skonto can this be closed?

The association of a resource to a MeterProvider is going to be a static one-to-one relationship based on the OTel specification definition. If multiple resources are needed a dynamic way to change out MeterProviders is likely something you will need to develop.

[MrAlias]

Closing as this looks stale. Please re-open if this was an error.