On Tuesday, May 19, 2015 13:53:23 Heiko W.Rupp wrote:
On 4 May 2015, at 14:03, Lukas Krejci wrote:
> In my mind almost anything "is changing like a metric", because
> everything changes over time.
Well. Then lets stop your project and make metrics store inventory
data :;->
> Also IMHO "key-value pairs" are just JSON. I think that the
> structured data
> support for configs and operation params served us well in RHQ.
I don't say that the structured data in RHQ is by itself bad (the
implementation
has IMO room for improvement). I also don't say that the traits in RHQ
are a bad thing.
But: with traits and configuration we have some very similar concepts
that have in RHQ some very different implementation.
> So IMHO we need a time-series store for structured data. I am not sure
> inventory
> is that - it is good for storing relationships among entities but I
> am not
> sure if it is well suited for storing (versioned) structured data.
I do not think that each single property needs to be a separate object.
I can imagine that we keep one (JSON) object per version (with some
additional
metadata) and the respective "client" of the store know how to deal with
it.
My understanding was that Inventory can have such a list of things
hanging on a resource.
Yes, it can, so in another words inventory can very well be used for storing
traits or config or whatever.
I think the main difference between inventory or metrics being used for
storing these is that of the focus of each component.
In my mind, inventory is primarily focused on displaying relationships and
properties of different entities *at some point in time*.
Metrics on the other hand is mainly focused on displaying the evolution of
values of a metric *over time*.
While you can certainly use inventory to build your view of changes over time,
it will probably not be optimized for that use-case. Likewise, if you would
like to use metrics to show you values of a number of metrics at some precise
point in time, it might not be optimized for that (and yes, this is a wild
guess of someone who doesn't know metrics at all ;) ).
But in the end, if we decide inventory is the best candidate for doing this, I
hope it can be bent to do what we need in some reasonable way.
The question remains though if inventory is the right place or
metrics.
Also for Traits, I think we should not (like for Availability) store the
whole
string every 20sec, but only store an update when a change occurred (1),
which may or may be applicable for configuration too. In fact RHQ had
logic inside the agents to only send updates when it detected changes.
Also Traits are most likely r/o, while configuration data may be
modified from
the UI.
1) And perhaps the last time the old version was still detected.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev