[Hawkular-dev] availability and metric endpoints

[John Sanda]

> On Mar 31, 2015, at 12:52 PM, Thomas Segismont <tsegismo at 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 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.
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev