New Metric Type: big_counter for storing countable values likely to exceed i32::MAX
Categories
(Data Platform and Tools :: Glean: SDK, task, P3)
Tracking
(Not tracked)
People
(Reporter: chutten, Unassigned)
Details
Proposal for changing an existing or adding a new Glean metric type
Who is the individual/team requesting this change?
:chutten from the Glean Team, on behalf of Florian Quèze and Romain Testard
Is this about changing an existing metric type or creating a new one?
Up to you!
Can you describe the data that needs to be recorded?
An example would be the number of milliseconds of CPU across all processes in Firefox Desktop.
Can you provide a raw sample of the data that needs to be recorded
It's any really large number, really.
What is the business question/use-case that requires the data to be recorded?
Could be anything, but in this case the question is "What is the number of CPU millis spent across Firefox?" for the purposes of estimating the electrical power use of Firefox Desktop.
How would the data be consumed?
Aggregated counts and distributions on GLAM, Looker, etc.
Why existing metric types are not enough?
counter and quantity saturate at too low a value. I'm looking for something more u64 in size. Or u128?
What is the timeline by which the data needs to be collected?
Data's already running into problems being collected now (See bug 1751241)
|
||
Comment 1•4 years ago
|
||
I wonder how much breaks if we change Counter to accept a u64.
Now that unsigned types in Kotlin are stable we should be good on the usability front there.
Only languages where we can't rely on types (Python, JavaScript) would go from recording an error on negative values to recording huge values instead (which could also be mitigated with runtime checks).
|
Reporter | |
Comment 2•4 years ago
|
||
We're asking BigQuery to make Counters into INTEGER which is INT64 which fits Rust's i64, but not u64, so there's a migration hazard here.
What we need is a u63 primitive.
|
||
Updated•1 year ago
|
Description
•