Remove usage of direction attribute

[codeboten]

Follow-up to the change in specification: open-telemetry/opentelemetry-specification#2617

The following actions are needed:

• [receiver/hostmetrics/diskscraper]: remove direction attribute #11816
• [receiver/hostmetrics/networkscraper]: remove direction attribute #11817
• [receiver/hostmetrics/pagingscraper]: remove direction attribute #11818
• [receiver/hostmetrics/processscraper]: remove direction attribute #11819
• [receiver/activedirectoryds]: remove direction attribute #12191
• [receiver/bigip]: remove direction attribute #12190
• [receiver/elasticsearch]: remove direction attribute #12189
• [receiver/iis]: remove direction attribute #12188
• [receiver/kubeletstats]: remove direction attribute #12164
• [receiver/memcached]: remove direction attribute #12165
• [receiver/mongodbatlas]: remove direction attribute #12187
• [receiver/nsxt]: remove direction attribute #12186
• [receiver/vcenter]: remove direction attribute #12185
• [receiver/zookeeper]: remove direction attribute #12184

[dmitryax]

@codeboten I'm not sure several feature gates for hostmetrics receiver provides a good user experience. Maybe we should have one feature gate for all host metrics with a single documentation?

Also I would like to have all of them aligned to the same release schedule. So if we cannot resolve #11816 by tomorrow's release, I would recommend adjusting it a bit (delaying the schedule for one more release).

[dmitryax]

I will submit a PR for ^ by tomorrow

[TylerHelmuth]

@codeboten @dmitryax did the receiver.hostmetricsreceiver.emitMetricsWithDirectionAttribute and receiver.hostmetricsreceiver.emitMetricsWithoutDirectionAttribute gates make it into the 0.55.0 release? If so we should update the 0.55.0 release notes with the appropriate gates. I just spent way too much time messing with the feature gates listed in the release notes instead of checking the hostmetrics README while updating some collector examples we have lol

[dmitryax]

Looks like #12134 was prepared before #12105 got merged. So we still have another kind of changelog race condition :)

I'll submit a PR to update the generated changelog and release notes

[dmitryax]

Submitted #12171

[crobert-1]

[exporter/signalfx] - Another place that needs updated

The signalfxexporter has functionality that "translates" input metrics into output metrics, and the default translation functionality references the direction attributes. These references should be updated for the new metric format.

I've created issue #12641 to track this.

[dmitryax]

@codeboten can we slow down the adoption of the new metrics a bit? We are having troubles on Splunk Observability side to provide the backward compatibility. Can we introduce the new metrics feature-gated in silent mode for a few more releases, then start the transition in a more relaxed schedule? I believe our backend might be not the only one trying to do it gracefully.

It may be good to have all the receivers ready by the start of the deprecation process so the schedule is aligned for all the receivers.

I'll be back in a week and can help with this effort.

[codeboten]

👍🏻 sure no problem

[mwear]

@dmitryax I'm happy to help push this work forward, and adjust the transition plan in whatever way makes the most sense. It sounds like it would be best if we:

• Implement the feature gates in each receiver, but leave them undocumented, and continue to emit metrics with direction attributes
• Once the feature gates exist for each receiver
  • Publish a revised transition plan
  • Document the gates
  • Add deprecation warnings
  • Push these changes out in one release, that will officially begin the transition plan
• At some later point in time (according to the transition plan), default to emitting metrics without direction, but keep the feature gate to allow users to enable emitting metrics with a direction attribute if needed
• When the transition period is over:
  • Remove the gates
  • Remove the documentation, warnings, etc around the transition plan

Let me know if this sounds reasonable or if you have any further suggestions on the plan and how we should carry it out.

[dmitryax]

Hi @mwear, this is exactly what I envisioned. Thanks for putting the plan together. Let's follow it

[mwear]

Great. One followup question. I think the answer is yes, but I wanted to clarify. Should we remove documentation about the feature gates and transition plan from the readmes where they are currently documented as well as any existing deprecation messages?

[dmitryax]

Should we remove documentation about the feature gates and transition plan from the readmes where they are currently documented as well as any existing deprecation messages?

Yes, let's remove it for now

[mwear]

Is this work impacted by: open-telemetry/opentelemetry-specification#2726. If so, should we continue with it, or wait for a resolution?

[dmitryax]

It is indeed. Let's hold off until it's resolved

[codeboten]

Closing this as the resolution was to not implement anything unless the specification declares any changes.