[processor/transform] Introduce optional metric name suffix setup for convert summary and extract histogram functions

[odubajDT]

Description

Introduce optional metric name suffix setup for the following functions:

• extract_count_metric
• extract_sum_metric
• convert_summary_sum_val_to_sum
• convert_summary_count_val_to_sum

This PR also introduces a breaking change by adapting the metric suffix according to the latest OTel convention which uses . instead of _

Link to tracking issue

Fixes #33850

Note

Addition of convert_summary_quantile_val_to_gauge(Optional[suffix]) function as described in the linked issue will be added in a separate PR

[github-actions]

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

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[odubajDT]

/reopen

[evan-bradley]

Sorry for the long delay with a review.

[evan-bradley]

@edmocosta @TylerHelmuth Now that the transform processor is beta, I'm wondering how we should handle this change. I can think of a few options, in order of most-abrupt to least.

1. Since this breaking change can easily be reverted by including an optional prefix with the former name, simply advise users of this in the subtext and continue with the breaking change.
2. Make the breaking change one version after adding the optional parameter, and announce that we will be making this change as part of the optional parameter changelog entry to give users more time.
3. Use a feature gate to control rolling this out.

On one hand, I'm okay being more aggressive since there's a clear and straightforward remediation path to retaining the old metric names. On the other hand, this change is "silent" within the Collector and won't go noticed until the user is seeing (or missing) data in their backend.

[edmocosta]

Considering changing the metric names can impact so many things on the user's side (dashboards, alerts, etc), I think I'd go with the more conservative option, giving users some time to adapt, without breaking it.

I like the feature gate idea to control the default suffix separator (_ or .). In addition to that, we could maybe log a message (at function bootstrap) when the suffix.IsEmpty(), warning users that does not read the release notes that the default suffix will be changed. Finally, we could update the functions docs examples to include the suffix args with the dot separator, so people that just copy & paste it during the transition time won't have issues when the new suffix format comes into place.

[odubajDT]

I do not have the capacity to deal with additional requests here, since the scope of the ticket changed, if somebody is interested please take over the PR, sorry

[edmocosta]

No problem, thank you @odubajDT!

I think we could add the deprecation things later, this PR is around for a while, and releasing it with the suffix support would be a quick win IMO. If @evan-bradley agrees, we could just bringing the default prefix separator back to _ , and tackle the prefix changes/deprecation later.

[evan-bradley]

That sounds good to me.

[edmocosta]

Hi @odubajDT, I've opened an PR against your branch addressing these last requests (odubajDT#125), could you please kindly merge it so we can finish the review using your PR? If you don't have availability for that please let me know so I can open a new one. Thank you again!

[odubajDT]

merged, thanks!

[edmocosta]

LGTM, @evan-bradley please take a look when you get the chance.