[Hawkular-dev] [Metrics] Pluggable aggregation functions: next steps

[John Sanda]

Keep the following in mind. Since the core metrics API is now built on RxJava, function params and return types should probably be rx.Observable. Some of the work described below may already be covered by the work Jay did for HWKMETRICS-144 which involved adding min/max/avg functions. To be honest, I think functions like min/max/avg are poor candidates for some of the changes being discussed because they are so simple. Here is our avg function,

    Func1<Observable<DataPoint<Double>>, Observable<Double>> Average = data ->
            MathObservable.averageDouble(data.map(DataPoint::getValue));

For other, more involved functions, I think we should look first at the core operators in Rx.Observable and then maybe consider custom operators[1].

[1] https://github.com/ReactiveX/RxJava/wiki/Implementing-Your-Own-Operators <https://github.com/ReactiveX/RxJava/wiki/Implementing-Your-Own-Operators>

> On Jul 21, 2015, at 5:43 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> 
> Hi,
> 
> I have looked at Aakarsh's repo:
> https://github.com/Akki5/hawkular_plugin/
> 
> It's a good start with an interface describing a doubles to double 
> function, a classloader for implementation loading and a set of initial 
> implementations.
> 
> In order to integrate this work into Metrics, I think we should follow 
> the following steps:
> 
> =====
> #1 Change the contract
> 
> Doubles to double works great for avg/min/max/... functions on gauge 
> metrics. But we need to consider other metric types.
> 
> Also, the interface should not only accept data point values, but whole 
> data points. Because some functions need the timestamp to compute the 
> result. % of up availability is a good example.
> 
> And functions may return different types: Double, Long, AvailabilityType.
> 
> #2 Update configuration options to let the user set a plugins directory
> 
> Metrics doc needs will have to be updated.
> 
> #3 Create a function repository for each metric type
> 
> We can build on JDK's service loader + Aakarsh's classloader implementation.
> 
> #4 Add builtin aggregate functions
> 
> Extract existing Metrics code (min, max, avg, % of up avail, downtime 
> duration) into builtin functions.
> 
> #5 Document the process of implementing a pluggable function
> 
> We need to think about function naming as well. Should we use a prefix 
> to identify a builtin function?
> =====
> 
> I will start another thread to discuss REST and Core API data query changes.
> 
> Thoughts?
> 
> Thanks,
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20150721/2171a2cd/attachment-0001.html