Open crobert-1 opened 2 weeks ago
Pinging code owners:
receiver/cloudfoundry: @crobert-1
See Adding Labels via Comments if you do not have permissions to add labels yourself.
@CemDK and @jriguera: Let me know if you have any feedback here.
Yes, according with OTEL guidelines, those attributes belong to resource level. The reason why they are at datapoint/log_record
level is because we are copying the tags from the envelope structure. We would need to have a list of attributes which should be moved to resource level, taking into consideration there are other custom tags defined by users/operators which I would keep as datapoint
/log_record
attributes . There are some attributres (eg org.cloudfoundry.product
which do not appear in open source Cloud Foundry)
But (just to take into consideration), one could argue that because the component is targeting CF as a system, only attributes like org.cloudfoundry.deployment
, org.cloudfoundry.product
and org.cloudfoundry.system_domain
would be resource level attributes.
Anyway, I would prefer having them as resource level. And, yes it will be a breaking change.
Hi, I would like to look into this issue if possible
Some thoughts about the breaking change: would it be a solution to temporary (let's say for 5 releases) keep the attributes duplicated on metric level and as well on resource level? Therefore there can be a slow phasing out time for users to adapt. WDYT?
Drafted a first possible (incomplete) draft solution, would like to hear your opinion on if duplicating the attributes is a good way in this. Thanks!
https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/34905
Some thoughts about the breaking change: would it be a solution to temporary (let's say for 5 releases) keep the attributes duplicated on metric level and as well on resource level? Therefore there can be a slow phasing out time for users to adapt. WDYT?
I think a feature gate would probably be better for this scenario. Have the feature gate disabled by default, but if someone enables it, all of the relevant attributes will be resource attributes instead of (not duplicated) attributes of a datapoint.
I like the idea of documenting this though, and giving it a number of releases before upgrading the feature gate's stability.
Some thoughts about the breaking change: would it be a solution to temporary (let's say for 5 releases) keep the attributes duplicated on metric level and as well on resource level? Therefore there can be a slow phasing out time for users to adapt. WDYT?
I think a feature gate would probably be better for this scenario. Have the feature gate disabled by default, but if someone enables it, all of the relevant attributes will be resource attributes instead of (not duplicated) attributes of a datapoint.
I like the idea of documenting this though, and giving it a number of releases before upgrading the feature gate's stability.
Thanks for the response, adapted the implementation and should be ready for review now!
I still need to review the code, but I agree with the feature gate.
Component(s)
receiver/cloudfoundry
Describe the issue you're reporting
An example metric from the Cloud Foundry receiver:
Each of these attributes are really describing the resource from where the metric and its data points are coming from, not the data point itself. These should all be moved to be resource attributes.
This would be a breaking change, and its changing the format of metrics considerably.