On Jan 26, 2011, at 4:18 PM, Emanuel Muckenhuber wrote:
> If it's important to just register a single handler
per-resource, then
> we'll need to register some sort of MetricHandler interface:
>
> public interface MetricHandler {
>
> Set<String> getHandledMetricNames();
>
> Cancellable execute(NewOperationContext context, String metricName,
> ResultHandler resultHandler);
>
> }
One thing which i think is interesting about having one metricHandler
per "runtime resource" is that you have to call execute only once to get
all the metrics rather than running execute N times for each name.
IMO the separation makes sense. For use cases that don't require metrics,
that data should not be send over the wire. I would prefer a custom operation opposed to
another operation attribute switch, like "includeMetrics=false".
On the API level this separation highlights that metrics run under different performance
considerations
and different semantics apply in general. It should not be intermingled with config data.
Anything we build atop of that (caching, aggregation, etc) would clearly benefit from a
distinction build into the API
right from the beginning.
But to make sure I understand you correctly:
- Does this means you have a custom operation to retrieve the metrics per resource?
(probably yes)
- Could metrics also be retrieved when reading the configuration?
I.e. separate payload element, but still one request?
- Although there is one handler per resource, will it be possible to retrieve just a
single metric value?
Ike