[receiver/mongodb] add receiver.mongodb.removeDatabaseAttr Alpha feature gate

[sakulali]

Description:
Add receiver.mongodb.removeDatabaseAttr Alpha feature gate to remove duplicate database name attribute.

Link to tracking Issue:
#24972

Testing:
make generate
make chlog-validate
go test for mongodbreceiver

Manually tested, built image and manually enabled and disabled this feature gate.

This is the warning we publish:

2023-10-15 17:06:29 2023-10-15T09:06:29.358Z warn [email protected]/scraper.go:62 Feature gate receiver.mongodb.removeDatabaseAttr is not enabled. Please see the README for more information: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/mongodbreceiver/README.md {"kind": "receiver", "name": "mongodb", "data_type": "metrics"}

Documentation:

[djaglowski]

LGTM, but can we do this with a feature gate?

[sakulali]

LGTM, but can we do this with a feature gate?

Thanks for the reviews @djaglowski! I will look into how to implement it using feature gates.

[djaglowski]

Thanks @sakulali

[sakulali]

Hello @djaglowski , i would greatly appreciate it if you could kindly review the code changes of the feature gate.

[djaglowski]

@sakulali, I think we should leave database as a resource attribute and remove it as a datapoint attribute. Apologies, this should have been stated in the issue and/or noticed in the initial review.

A couple reasons here:

1. Databases are noteworthy components which can be described individually. This works in favor of it each being a separate resource.
2. The problem with changing resource attributes is that it requires reorganizing the data as well. For example, without the database noted as a resource attributes, we would emit multiple resources with the same set of resource attributes. (See some of the testdata files.)

[sakulali]

I think we should leave database as a resource attribute and remove it as a datapoint attribute. Apologies, this should have been stated in the issue and/or noticed in the initial review.

Thanks for thoughtful reply @djaglowski. The reasons you mentioned make sense, and I will take some time to make the necessary adjustments to the code.

[sakulali]

I think we should leave database as a resource attribute and remove it as a datapoint attribute

Hello @djaglowski, sorry fo delay reply, i tried to remove datapoint attribute with a feature gate and replace with resource attribute, it seems that regardless of whether the feature gate is enabled or not, the database attribute will be removed. Could you mind help reviews again?

[djaglowski]

Thanks for continuing on with this @sakulali.

it seems that regardless of whether the feature gate is enabled or not, the database attribute will be removed.

Can you explain why and what the purpose of the feature gate would be in this case?

[sakulali]

Can you explain why and what the purpose of the feature gate would be in this case?

Thanks for your patient guidance @djaglowski :). I don't have a thorough understanding of feature gates. From my understanding, the purpose of a feature gate is to inform users that there will be changes to telemetry in future versions, giving downstream users sufficient time to make adjustments. In transitional versions, users can enable the feature gate to adopt new functionality or disable it to retain the original functionality.

[djaglowski]

@sakulali, that's my understanding as well, but what doesn't make sense to me is why we would include a feature gate if it isn't going to actually control anything. That my interpretation of what you said it seems that regardless of whether the feature gate is enabled or not, the database attribute will be removed, but perhaps I misunderstood.

To be clear, I think we need the feature gate, but it should control whether or not the the database attribute is present.

[sakulali]

To be clear, I think we need the feature gate, but it should control whether or not the the database attribute is present.

@djaglowski, thanks very much for helping me correct my mistake and clarifying the proper approach and significance of the feature gate. I will take some more time to think about how to implement this feature gate.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[sakulali]

To be clear, I think we need the feature gate, but it should control whether or not the the database attribute is present.

Sorry for delay. Thanks for your attentive correction, could you help to reviews again @djaglowski? During this time, i have been contemplating how to implement this feature. I came across PR 29152 by chance and found some inspiration from it. I would like to express my gratitude to @mx-psi for that.

[djaglowski]

Thank you very much for persisting through this effort @sakulali.