Skip to content

Conversation

@shakuzen
Copy link
Member

@shakuzen shakuzen commented Feb 26, 2025

Adds new configuration methods to override the registry-wide configuration at a per Meter (name) level. This gives more fine-grain control of the configuration.

The registry-wide HistogramFlavor configuration can be overridden at the meter level with the new histogramFlavorPerMeter configuration method, which returns a Map<String, HistogramFlavor> where the key is the exact Meter name to match.

Likewise, the registry-wide max bucket count can be overridden at the meter level with the new maxBucketsPerMeter configuration method, which returns a Map<String, Integer> where the key is the exact Meter name to match.

  • TODO: Update documentation

Closes #5459

Adds new configuration methods to override the registry-wide configuration at a per Meter (name) level. This gives more fine-grain control of the configuration.
@shakuzen
Copy link
Member Author

Pinging some folks who expressed interest in or provided input on this feature before to get any feedback they may have on this proposal: @lenin-jaganathan @pirgeo @sfc-gh-rscott @sfc-gh-dguy. Of course anyone else is welcome to give feedback too.

In #5459 I expressed a desire to expose the configuration at the DistributionStatisticConfig level. In this proposal (at the time of writing this comment), I've abandoned that and went for what feels more straightforward: making the configuration specific to OtlpConfig and the OtlpMeterRegistry. If anyone has thoughts on that, please share.

@shakuzen
Copy link
Member Author

shakuzen commented Mar 6, 2025

We have the last 1.15 milestone release on Monday, so I'd like to merge something for this in time for that. If anyone has feedback on the proposal, please share.

void histogramFlavorPerMeter() {
Map<String, String> properties = new HashMap<>();
properties.put("otlp.histogramFlavorPerMeter",
"a.b.c=explicit_bucket_histogram ,expo =base2_exponential_bucket_histogram");
Copy link
Member

Choose a reason for hiding this comment

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

Is spacing intentional?

Suggested change
"a.b.c=explicit_bucket_histogram ,expo =base2_exponential_bucket_histogram");
"a.b.c=explicit_bucket_histogram, expo=base2_exponential_bucket_histogram");

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this was intentionally testing that it can handle weird spacing. That could be made more explicit in a separate test perhaps.

@Test
void maxBucketsPerMeter() {
Map<String, String> properties = new HashMap<>();
properties.put("otlp.maxBucketsPerMeter", "a.b.c = 10");
Copy link
Member

Choose a reason for hiding this comment

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

Is spacing intentional?

Suggested change
properties.put("otlp.maxBucketsPerMeter", "a.b.c = 10");
properties.put("otlp.maxBucketsPerMeter", "a.b.c=10");


import static org.assertj.core.api.Assertions.assertThat;

class PropertyValidatorTest {
Copy link
Member

Choose a reason for hiding this comment

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

I would put tests here with tricky spacing (like above):

a=b ,c =d, e = f

Copy link
Member Author

Choose a reason for hiding this comment

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

Done in 8db4d6e

@shakuzen shakuzen merged commit 2bc1a70 into micrometer-metrics:main Mar 11, 2025
9 checks passed
@shakuzen shakuzen deleted the expo-max-per-meter branch March 11, 2025 01:10
shakuzen added a commit that referenced this pull request Mar 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support configuring exponential histograms at the meter level

2 participants