feat: Improve support for exponential histogram

[thomasstauffer666]

Fixes #2111 and implements exponential histogram support in opentelemetry-stdout.

Design discussion issue (if applicable) #

Changes

Please provide a brief description of the changes here.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: thomasstauffer666 / name: Thomas Stauffer (4d1a7c6, 6ef5d10, abd0b0f)

[codecov]

Codecov Report

❌ Patch coverage is 2.73973% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.5%. Comparing base (df412fe) to head (abd0b0f).

Files with missing lines	Patch %	Lines
opentelemetry-stdout/src/metrics/exporter.rs	0.0%	71 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3259     +/-   ##
=======================================
- Coverage   80.8%   80.5%   -0.3%     
=======================================
  Files        129     129             
  Lines      23203   23272     +69     
=======================================
  Hits       18750   18750             
- Misses      4453    4522     +69     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[scottgerring]

@thomasstauffer666 let us know when this is ready for review!

[thomasstauffer666]

@scottgerring would be ready for review

codecov correctly reports that nothing I added to stdout is tested. AFAIK rust has no official way to unit test functions which use stdout. Possibilites I see:

• Leave it as is
• Use a module like gag which only works on unix
• Rewrite opentelemetry-stdout to not directly use println! instead using a writer (or something else) which by default uses stdout, but at least for testing could be redirected, but this would be another PR then

[scottgerring]

hey @thomasstauffer666 great - cheers! I'll check it out tomorrow 💪

Apropos the stdout coverage; we try and be pragmatic with coverage, and my initial thought is that this is a case where we don't need to go wild chasing it, but I will form proper opinions shortly.

[scottgerring]

Hey @thomasstauffer666 thanks for the PR! Couple of minor notes inline

p.s. if you would like to chat about this or other otel-rust stuff, you can join us in #opentelemetry-rust in the CNCF slack 🤝

[scottgerring]

I struggle a bit with the format, but it might just be me:

Bucket 0 (<= -2.000 to > -4.000) : 5"

Maybe something like is clearer?

Bucket 0 ( -4.000 < x < -2.00)

Also i'm not sure of the inclusivity ( x > y <= z ) - when it goes negative - did you have a look at the spec here?

[thomasstauffer666]

I looked up

https://opentelemetry.io/docs/specs/otel/metrics/data-model/#histogram-bucket-inclusivity

But I will document it and put a reference to into the code and add an additional data point to the example where this is better visible.

It probably would be even better idea to access the boundaries via API. The official documentation goes into details how implementation may differ and even the reference implementation may not be fully accurate.

What about using mathematical notation?

		NegativeOffset : 0
			 ->  Bucket 4 (-5.657, -4.000] : 1
			 ->  Bucket 3 (-4.000, -2.828] : 1
			 ->  Bucket 2 (-2.828, -2.000] : 0
			 ->  Bucket 1 (-2.000, -1.414] : 0
			 ->  Bucket 0 (-1.414, -1.000] : 1
		PositiveOffset : -3
			 ->  Bucket 0 (0.354, 0.500] : 1
			 ->  Bucket 1 (0.500, 0.707] : 0
			 ->  Bucket 2 (0.707, 1.000] : 0
			 ->  Bucket 3 (1.000, 1.414] : 0
			 ->  Bucket 4 (1.414, 2.000] : 0
			 ->  Bucket 5 (2.000, 2.828] : 0
			 ->  Bucket 6 (2.828, 4.000] : 0
			 ->  Bucket 7 (4.000, 5.657] : 0
			 ->  Bucket 8 (5.657, 8.000] : 1

more obvious?

[scottgerring]

I think it's more obvious; although if we change it here we should also change the stdout formatter for the regular histogram for consistency. I don't know if there is some reason to not do this - e.g. we expect folks to use this in bash-style grep-y pipelines and this breaks - feels unlikely, and i'd err for clarity. @cijothomas wdyt before we change more?

[thomasstauffer666]

For the regular histogram the example yields

			 0 to 5 : 2
			 5 to 10 : 0
			 10 to 25 : 0
			 25 to 50 : 0

IMHO somewhat ambiguous where e.g. a 5.0 would end up, but consistency between both histogram types is a good idea