8:45 p.m.
On Mar 31, 2015, at 12:52 PM, Thomas Segismont
<tsegismo(a)redhat.com> wrote:
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.
I have thought a lot about this. The need for storing aggregated metrics has been
established. We may not want to store aggregate metrics for everything as we did in RHQ,
but we do want the ability to store data at lower resolutions. Given that, the question
that naturally follows is how should the data be aggregated. At some point that needs to
be specified. I anticipate that the vast majority of metrics will be created by inventory.
The inventory service will likely know about the metric type at creation time, so on that
basis I think that qualifying it up front makes sense.
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.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev