Allow access of any Aggregate metrics using field IDs from tests configuration.
Changes
Field reference IDs
All previous field IDs (MEAN, FAILURE_COUNT, ...) have been renamed. See below.
Aggregate metrics access via Field
The issue with statically declared field IDs
The logics around Field have been entirely remade from scratch. In the previous version we had to bookkeep every possible metric field, which required to define manually for each:
an arbitrary id for referencing
an associated getter to connect the id with a path from Aggregate
metadata (typing) to associate the id with the type of the referenced metric
Commit 1a46f90ebe1c8908078f0d0336fab9a01ee87ade gives an idea of the difficulty we'd have to maintain that system for all metrics, and it only added very basic stats (min, max, mean) for 3 request events (out of 8). Worse: how can we handle access to StatusCodesDistribution metrics with that system? A field id for each possible code?
New dynamic access system
That's why we had to switch for a more suitable, generic solution. It uses a Field id as a path representation from an Aggregate to its value: this ID is now semantically tied to Aggregate structure: it serves both as a reference name and as a getter. The type of the value doesn't need to be defined in advance anymore, it is dynamically retrieved as well.
It is also able to call a method and retrieve its result, so we can move implementation of XXX_COUNT functions (previously inlined as a getter in field definitions) in dedicated Aggregate methods, which makes more sense.
Implementation details
The change only impacted metrics internals (except test files with hardcoded fields which needed an update): the package is used the same way as before.
Just as before, metric field resolution is done via Aggregate.MetricOf, only its implementation changed.
It uses a new generic package reflectutil, that provides helpers around reflect to resolve a path from a structure
Most of logics & definitions around Field are gone: it's now a single type with 2 methods Type() string and Validate() error that basically are aliases to Aggregate methods.
Description
Allow access of any
Aggregatemetrics using field IDs from tests configuration.Changes
Field reference IDs
All previous field IDs (
MEAN,FAILURE_COUNT, ...) have been renamed. See below.Aggregatemetrics access viaFieldThe issue with statically declared field IDs
The logics around
Fieldhave been entirely remade from scratch. In the previous version we had to bookkeep every possible metric field, which required to define manually for each:AggregateCommit 1a46f90ebe1c8908078f0d0336fab9a01ee87ade gives an idea of the difficulty we'd have to maintain that system for all metrics, and it only added very basic stats (min, max, mean) for 3 request events (out of 8). Worse: how can we handle access to
StatusCodesDistributionmetrics with that system? A field id for each possible code?New dynamic access system
That's why we had to switch for a more suitable, generic solution. It uses a
Fieldid as a path representation from anAggregateto its value: this ID is now semantically tied toAggregatestructure: it serves both as a reference name and as a getter. The type of the value doesn't need to be defined in advance anymore, it is dynamically retrieved as well.It is also able to call a method and retrieve its result, so we can move implementation of
XXX_COUNTfunctions (previously inlined as a getter in field definitions) in dedicatedAggregatemethods, which makes more sense.Implementation details
metricsinternals (except test files with hardcoded fields which needed an update): the package is used the same way as before.Aggregate.MetricOf, only its implementation changed.reflectutil, that provides helpers aroundreflectto resolve a path from a structureFieldare gone: it's now a single type with 2 methodsType() stringandValidate() errorthat basically are aliases toAggregatemethods.Usage
This unit test demonstrates how the new system is used: https://github.com/benchttp/engine/blob/560f0ee42268a424b2c7799834b186e0894ff062/runner/internal/metrics/metrics_test.go#L79-L150
Notes