MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)

Jiri Kremser jkremser at redhat.com
Mon Sep 24 12:50:23 UTC 2012


It would be nice to have, but it is not just only about formatting the output. What I was trying to show with the example with the aggregates represented as dates around 1970, was that the dynamically generated metric has the units are taken from the origin metric, hence 1 second is represented in terms of epoch_milliseconds as a 1970 00:00:01 am. Another challenge is that now, only the "X per min" (derivative) type of metrics are dynamically added (afaik, I was looking at MetricsMetadataParser). 

JK

----- Original Message -----
From: "Elias Ross" <genman at noderunner.net>
To: rhq-devel at lists.fedorahosted.org
Sent: Friday, September 21, 2012 7:27:08 PM
Subject: Re: MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)

On Fri, Sep 21, 2012 at 3:06 AM, Jiri Kremser <jkremser at 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.
_______________________________________________
rhq-devel mailing list
rhq-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list