Thanks for the pointers, we'll have a look.
Le 21/07/2015 23:27, Jay Shaughnessy a écrit :
Right, you may find what you need is already in place, or you may find
that you can spend time on higher-level functions. In particular, see:
MetricsService:
<T> Observable<T> findGaugeData(String tenantId, MetricId id, Long
start, Long end,Func1<Observable<DataPoint<Double>>,
Observable<T>>...
funcs);
Aggregate:
predefined functions.
Here is an example snippen from
org.hawkular.alerts.external.metrics.Manager to gather multiple
aggregates in one call and determine the range:
case range: {
Iterator<Double> iterator =
metrics.findGaugeData(tenantId, metricId, start, end,
Aggregate.Min, Aggregate.Max)
.toBlocking().toIterable().iterator();
Double min = iterator.next();
Double max = iterator.next();
value = max - min;
break;
}
-Jay
On 7/21/2015 10:43 AM, John Sanda wrote:
> 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(a)redhat.com
>> <mailto:tsegismo@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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev