[Hawkular-dev] availability and metric endpoints

[Thomas Segismont]

Hi,

Last week I had a long phone conversation with John about the impact of 
the coming changes to metrics on the Influx API support. I'd like to 
share the conclusion I've come to.

So in the future we'll have counters and gauges series. The goal is to 
qualify the data inserted upfront so that things like 
statistics/aggregates are automatically computed.

If we're going this way it's going to be difficult (and less relevant) 
to maintain the Influx API support, because we'll lose the 1 to 1 
mapping between an Influx series and an Hawkular Metrics series. When a 
user will post/read data, should it be stored/read to/from a counter or 
a gauge?

As Micke is working on a Go lang sink for cAdvisor/Heapster, the Influx 
support API is less important regarding our immediate needs. But we'll 
lose the ability to integrate with all the tools which support Influx 
already (Grafana and JMeter among others).

It doesn't mean we can't write our own integration code for these tools. 
But that's not for free.

Regards,
Thomas


Le 23/03/2015 15:18, John Sanda a écrit :
>
>> On Mar 23, 2015, at 9:52 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
>>
>>> What I meant is that we shouldn't care about how the data is stored, if
>>> it's a counter, a gauge, a string. It's a "value point" in time.
>>
>> While I think it is good to separate the storage from the semantics,
>> I do not think we should not care how it is stored.
>>
>> For counters, which are integral values, we should probably not
>> store them as double.
>>
>> Similar, a log line should not be stored as double either :-)
>>
>>>
>>> What matters is how we query this data. For example, if you're working
>>> with a counter you'll probably be interested in applying a derivative
>>> function.
>>
>> Yes
>
> The semantics of metric type are precisely about querying. The type information tells us which aggregation functions to apply to the data points. And these functions should be utilized in both ad-hoc queries as well as the generation of pre-computed aggregates/rollups; however, I am not suggesting that this should preclude the use of other functions.