[Hawkular-dev] Metrics, tags and search capabilities

[Gary Brown]

Hi

I think use of tags to provide greater flexibility would be good, to support future requirements, such as metrics related to services, apps, queries, customers, etc.

So maybe a generic 'type' tag/field would define the type of metric, e.g. response time, size, availability, etc - but other information defined using appropriate tags.

Although is there any standard naming convention for referring to resources in inventory - i.e. so where metrics relate to a resource in inventory, then perhaps a tag/field could be used to link them?

Regards
Gary

----- Original Message -----
> Hi,
> 
> Earlier today I created HWKMETRICS-54, but I later thought about it a bit
> more and to me it looks like we're not sure what the tags should really do
> and how the system should be used. Lets assume the following scenario:
> 
> 3 machines, each one running an agent that provides data for memory.free,
> memory.cached, cpu.idle, cpu.user, cpu.system, disk.free, disk.used
> 
> Now what user might want to do in these cases is:
> 
> a) I want to get all the statistics affecting the host 1
> b) I want to get all the memory.free statistics from each host
> 
> Think about the data modeling in our current hawkular-metrics for a moment.
> The user starts:
> 
> I. Model everything with machine1.memory.free, machine2.memory.free etc
> a) How to query machine1.* ? Can't be done. c) How to get *.memory.free?
> Can't be done.
> 
> How would the query succeed with our current format? By creating tags for
> every occasion on metric creation:
> 
> create machine1.memory.free (tags: machine='machine1', category='memory')
> create machine2.memory.free (tags: machine='machine2', category='memory')
> 
> What the user finds out is that "why on earth do I have the metricId at all"
> ? It's a good question. In our current structure we should remove metricId
> and just invent something random for better Cassandra partitioning.
> 
> What it probably should look like (and this is how I assumed it was to be
> done until I checked the unit tests and find out that there's nothing
> pointing to this OpenTSDB familiar method):
> 
> II. memory.free, cpu.idle are the metricIds and I'll define it has a
> parameter 'machine'. When pushing a metric I set a tag with a value, such as
> machine='machine2'.
> 
> Now when I fetch the metric "memory.free", I can get all the memory.free
> valuess with 'machine'-tag indicating which machine it was gathered from. If
> I need to search for all machine-statistics, then I could use the
> tag-searching. If I wanted only machine1 memory.free, I would add a filter:
> tag machine='machine1'.
> 
> Or how are we supposed to model real-world-use-cases? The current model is
> quite cumbersome and not even necessarily doable in many cases (am I
> supposed to query for a metric definition before pushing any metric -
> because a new container could give me new set of parameters or a new machine
> new set of machine parameters and I need to remember to register them
> instead of pre-defined types which I might know).
> 
>    - Micke
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>