PoC: Add experimental support for bound sum instruments#8278
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #8278 +/- ##
=======================================
- Coverage 82.9% 82.8% -0.1%
=======================================
Files 314 314
Lines 24911 25209 +298
=======================================
+ Hits 20661 20889 +228
- Misses 3878 3937 +59
- Partials 372 383 +11
🚀 New features to boost your workflow:
|
|
The documentation on Delta aggregation temporality mentions that the SDK should be able to 'forget about things that are no longer needed' to control memory usage. |
In this PoC, it can be completely eliminated. But in the current specification PR for bound instruments, that is not the case. |
Resolves open-telemetry#4126. See issue for full details, but some of the key bits: - Adds new optional "bind" capability to synchronous instruments - Marked as "in development" - SDK implementation requirements phrase it as "A bound instrument MUST behave identically to calling the equivalent unbound recording operation with the pre-bound Attributes on each measurement". That is, the same behavior with respect to cardinality limits, exemplars, and anything else relevant. Since attributes are pre-bound, this excludes attributes processing from views, which is done at bind time. There have been a few prototypes built: - Java: open-telemetry/opentelemetry-java#8314 - Rust: open-telemetry/opentelemetry-rust#3421 - Go: open-telemetry/opentelemetry-go#8278 I'm particularly interested to here from @dashpole and @cijothomas if this aligns with their prototypes and ideas. Other interest has been expressed in .NET and Erlang, but no prototypes that I'm aware of.
|
I'll work on a new implementation that is spec compliant |
2 participants
Supersedes #7790
This implements a PoC for open-telemetry/opentelemetry-specification#5050, with some divergences (to try and make this more ergonomic):
metric.Float64Counter, which has an Add function that also accepts attributes. The current proposal does not allow the Add function for a bound instrument to also accept attributes.Differences compared to the previous prototype:
metric/xinstead of inmetricto avoid public API changes.This prototype does not implement bound instruments for all instrument types (only for counters).
Benchmarks:
Note: I removed Filtered, Naive, and WithAttributes, and the 5 attribute case to make the benchmarks legible.
Overall, Bind() and Add() have zero memory allocations as long as there is a single measurement function (i.e. you don't have multiple views defined for the same instrument).
The Precomputed case, in which the attributes are known ahead of time, the runtime is very close to the underlying performance of incrementing an atomic counter on my machine (3 ns with no contention, ~25 ns) with 24 cores. In the Dynamic case, where attributes need to be computed for each call, the additional runtime cost is from hashing the incoming attributes, and performing the map lookup.
Serial Benchmarks:
Most of this was written by Gemini.