Consider instrumenting metrics configurations
Categories
(Data Platform and Tools :: Glean: SDK, task, P4)
Tracking
(Not tracked)
People
(Reporter: chutten, Unassigned)
References
(Blocks 1 open bug)
Details
Metrics configurations can affect the completeness of data being reported, and it's not guaranteed to be clear which pings were subject to which configurations.
I propose we instrument metrics configurations and include the list of configured metrics in at least the "metrics" ping (maybe all pings the configured metrics are sent in + "metrics"?)
Comment 1•2 years ago
|
||
I approve of this, especially since it would give us something to compare to when validating behavior of remotely configured metrics.
Updated•2 years ago
|
Updated•1 years ago
|
Comment 2•1 years ago
|
||
Considering the limitations of LabeledBoolean metric type (this would not scale well with only 16 dynamic labels before we hit __other__
), and considering this would imply some embedded encoding/format for a StringList metric type, I think that this might be a good use-case for the coming ObjectMetricType.
This ultimately is shaped as a list/array of key/value pairs and Object seems well suited for that shape of collection, and would scale better with wider adoption and use of Server Knobs. I propose to wait until the object type is ready for use and then use that for this collection.
Not only is it well shaped for this, this would potentially give us a way to have an integration/instrumentation test for the object metric type outside of the normal unit tests.
Updated•1 year ago
|
Comment 3•7 months ago
|
||
Untaking this until I have time to get back to it.
Description
•