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(a)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.