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

[Thomas Segismont]

The goal of Aakarsh's work is not to implement min/max/avg, of course. 
It's to let users plug in custom functions.

I've talked about min/max/avg because at some point we'll need to be 
able to call builtin functions as well as user defined function, and it 
would be nice to do it seamlessly.

Thank you for talking about RxJava. It makes me think we'll need to 
consider which classes should be visible to user defined functions and 
which shouldn't.

Le 21/07/2015 16:43, John Sanda a écrit :
> 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
>
>> On Jul 21, 2015, at 5:43 AM, Thomas Segismont <tsegismo at redhat.com
>> <mailto: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
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>