9:25 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev