On Fri, Sep 21, 2012 at 3:06 AM, Jiri Kremser <jkremser(a)redhat.com> wrote:
Thanks for response.
> Now, is your concern that the only valid use-cases are for traits and since traits
are Strings, it doesn't make sense to support these units?
Well, Elias apparently has a valid use-case (for monitoring the data flows to HBase)
using these units for a numeric metric, but I am still not convinced. One reason are the
aggregate functions, what will mean min / max / avg of a set of timestamps for last n
hours?
Aggregates don't make too much sense. Still, say for a day aggregate,
you would see for that day the first event time, last event time for
that day. The average, if it was before noon, would be an indication
more events in the morning, etc. Still, you could make some sense of
trending...
Other reason if someone blindly marks this metric definition as a
trends up (which it often is) then resulting new metric with type (epoch_milliseconds /
per min) doesn't make any sense. Imagine these rows at monitoring table:
Name Alerts Min Max
Avg Last
"Last time something happened" 1 10/10/2012 1:00 am
10/20/2012 1:00 am 10/15/2012 1:00 am 10/20/2012 1:00 am
"Last time something happened per min" 0 1/1/1970 0:01 am
1/1/1970 0:10 am 1/1/1970 0:05 am 1/1/1970 0:10 am
You wouldn't want to display 'per min' like that, or shouldn't. Drop
the date and keep the minutes.
You could display:
"Time between events" 0 1 min 9 min 5 min
I agree that now it is not user friendly. What about allowing it only
for traits and I'll add a formatting logic if the units is set to
epoch_(milli)seconds? I know the complex alerts wont work for traits since it allows only
"val. change cond.".
Both would be great. Obviously, things like 'when the server started'
would be a trait. But something like 'last time data processed' type
stuff could be a measurement.
To me, formatting this properly seems like a trivial amount of code
and easy to test. I can give it a shot if you'd like.