Skip to content

otlp/translator: Use separate function for metric names with UTF8 characters#15664

Merged
ArthurSens merged 13 commits intomainfrom
otlp-noncompliant-name
Jan 6, 2025
Merged

otlp/translator: Use separate function for metric names with UTF8 characters#15664
ArthurSens merged 13 commits intomainfrom
otlp-noncompliant-name

Conversation

@ArthurSens
Copy link
Copy Markdown
Member

@ArthurSens ArthurSens commented Dec 11, 2024

After many discussions with the team, it seems that our previous approach of using the method BuildCompliantName to translate all kinds of translation strategies stretched its usefulness too much.

This is an alternative for #15440. Here, concerns are split into two separate functions. BuildCompliantName was renamed to BuildCompliantMetricName and focuses only on building metric names that follow Prometheus naming conventions.

The new function BuildMetricName is responsible for building metric names that keep characters as they come. The only thing it does is append prefixes and suffixes, if asked.

For the reviewers, I recommend reviewing commits individually :)


Fixes #15534
Fixes #15362

@ArthurSens
Copy link
Copy Markdown
Member Author

@aknuds1 I did not add a test specifically for the problem described in #15534, but I can add it if you think it adds value :)

@ArthurSens ArthurSens force-pushed the otlp-noncompliant-name branch from 4863399 to 90ce391 Compare December 12, 2024 12:59
@aknuds1
Copy link
Copy Markdown
Contributor

aknuds1 commented Dec 12, 2024

Can you change the name of this PR? Refactoring per definition doesn't fix any bugs. Refactoring just means changing code for maintainability reasons.

@ArthurSens ArthurSens changed the title otlp/translator: Refactor how OTLP metric names are translated otlp/translator: Use separate function for metric names with UTF8 characters Dec 12, 2024
@ArthurSens ArthurSens force-pushed the otlp-noncompliant-name branch from 90ce391 to d1934e8 Compare December 16, 2024 21:37
@ArthurSens
Copy link
Copy Markdown
Member Author

merge conflict resolved :)

@aknuds1
Copy link
Copy Markdown
Contributor

aknuds1 commented Dec 17, 2024

Thanks, going to take a look.

Copy link
Copy Markdown
Contributor

@aknuds1 aknuds1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see comments for bugs I could spot.

Copy link
Copy Markdown
Contributor

@aknuds1 aknuds1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to include one of the bugs I spotted in the previous review.

Copy link
Copy Markdown
Contributor

@aknuds1 aknuds1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've defined a test that catches a bug in this PR. If you try that with this PR, you'll see that the suffix comes out as _km_per_, instead of just _km.

It's probably a good idea to copy said test to this PR, to guard against the regression in question.

@ArthurSens
Copy link
Copy Markdown
Member Author

I've defined a test that catches a bug in this PR. If you try that with this PR, you'll see that the suffix comes out as _km_per_, instead of just _km.

It's probably a good idea to copy said test to this PR, to guard against the regression in question.

Sounds good, I'm merging that PR and rebasing this one

@ArthurSens ArthurSens force-pushed the otlp-noncompliant-name branch from bf1c8ff to 960edd8 Compare December 23, 2024 13:30
@ArthurSens
Copy link
Copy Markdown
Member Author

Hmmm, I'm not really sure about what should be the expected behavior in the failing test 😵

require.Equal(t, "broken_metric_speed_km", normalizeName(createGauge("broken.metric.speed", "km/°"), ""))
// Not equal: 
// expected: "broken_metric_speed_km"
// actual  : "broken_metric_speed_km_per_"

We see a /, so per OTel conventions it's a something per something kind of translation, but the second unit is invalid for the Prometheus Compliant naming convention. What should we do here? Drop the per completely? Or keep the current behavior that translates to per_?

@aknuds1
Copy link
Copy Markdown
Contributor

aknuds1 commented Dec 23, 2024

Hmmm, I'm not really sure about what should be the expected behavior in the failing test 😵
We see a /, so per OTel conventions it's a something per something kind of translation, but the second unit is invalid for the Prometheus Compliant naming convention. What should we do here? Drop the per completely? Or keep the current behavior that translates to per_?

@ArthurSens It's the other way around. The current behaviour is what's in main, i.e. before the changes in this PR, and since the test in question passes there (on the main branch), the current behaviour is to drop the "per" part. The expectation of the test represents the current, desired, behaviour. This PR is not supposed to change the classical translation mode, only the UTF-8 translation mode, so it follows that the implementation should merely pass the test.

BuildCompliantName no longer takes UTF8 support into consideration and fully focus on building a metric name that follows Prometheus conventions.

Signed-off-by: Arthur Silva Sens <[email protected]>
Signed-off-by: Arthur Silva Sens <[email protected]>
Signed-off-by: Arthur Silva Sens <[email protected]>
Signed-off-by: Arthur Silva Sens <[email protected]>
By making it return only the appropriate suffixes without modifying them. Character transformation is now done by the caller if necessary.

Signed-off-by: Arthur Silva Sens <[email protected]>
@ArthurSens ArthurSens force-pushed the otlp-noncompliant-name branch from 8a30da4 to 2026c5b Compare January 3, 2025 14:58
Signed-off-by: Arthur Silva Sens <[email protected]>
@ArthurSens
Copy link
Copy Markdown
Member Author

Finally coming back to this after the holidays 👋

Copy link
Copy Markdown
Contributor

@aknuds1 aknuds1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks much better now, but please see my suggestion for cleaning up a hairy code block that I think has a bug:

ArthurSens and others added 3 commits January 3, 2025 15:16
Co-authored-by: Arve Knudsen <[email protected]>
Signed-off-by: Arthur Silva Sens <[email protected]>
Signed-off-by: Arthur Silva Sens <[email protected]>
Signed-off-by: Arthur Silva Sens <[email protected]>
aknuds1
aknuds1 previously approved these changes Jan 6, 2025
Copy link
Copy Markdown
Contributor

@aknuds1 aknuds1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I think there's a misleading test case comment. Should we remove the test case?

Signed-off-by: Arthur Silva Sens <[email protected]>
Copy link
Copy Markdown
Contributor

@aknuds1 aknuds1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

2 participants