Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ProtocolMetrics #1014

Open
michael-mclawhorn opened this issue Mar 5, 2020 · 0 comments
Open

ProtocolMetrics #1014

michael-mclawhorn opened this issue Mar 5, 2020 · 0 comments

Comments

@michael-mclawhorn
Copy link
Contributor

michael-mclawhorn commented Mar 5, 2020

Protocol Metrics are a new alternative design to nested-function parsed parameter metrics.

Instead of allowing arbitrary metric functions to enclose metrics, protocol metrics will be configured with a fixed set of 'core parameters' that when values are passed to them (as if the metric itself was a function name), they are at request time metric-built/transformed into a variation on the base metric.

The novel concept is a Protocol (formerly called a named signal), which represents a transformation that the system is configured to be able to apply, with an associated contract name (representing the type of the transform) and core parameter(the api named parameter that signals that the protocol should be applied.

In general, protocols and the metric functions that they enclose are expected to be immutable and not close over any interesting state or have any dependencies on metrics instances.

Similarly, it's going to generally be good practice to have a single Protocol implementation used in a system for a given contract name and a single Protocol associated with any given 'core parameter'.

Protocols are connected to Metrics via a 'ProtocolSupport' object, also immutable objects, containing a map of protocols that a metric accepts and a blacklist indicating which protocol contracts should be forbidden to any metric built on top of this metric. Example: A reaggregated metric (built by AggregationAverageMaker) should never be subjected to the 'reaggregation' protocol, nor should any metric built (say by apply arithmetic operations) upon it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant