MetricPlugin currently handles metric aggregation on behalf of the implementation plugins, which are only responsible for routing aggregated metrics to their destinations. There is a use-case, however, for plugin types which do their own aggregation or processing on the minimally-aggregated metrics coming directly from MetricManager.
To this end, I propose renaming the current MetricPlugin to something like "AggregatingMetricPlugin" and adding a pure virtual MetricPlugin interface which defines the minimal set of functions needed by MetricManager to pass metrics down. All current _metric plugins would then inherit from AggregatingMetricPlugin.
This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/23776 (FNAL account required) Originally created by @eflumerf on 2019-12-18 14:45:47
MetricPlugin currently handles metric aggregation on behalf of the implementation plugins, which are only responsible for routing aggregated metrics to their destinations. There is a use-case, however, for plugin types which do their own aggregation or processing on the minimally-aggregated metrics coming directly from MetricManager.
To this end, I propose renaming the current MetricPlugin to something like "AggregatingMetricPlugin" and adding a pure virtual MetricPlugin interface which defines the minimal set of functions needed by MetricManager to pass metrics down. All current _metric plugins would then inherit from AggregatingMetricPlugin.