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? 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
"Last time something happened per min is not calculated" from # value changes
but from # millis and then formatted.
Does it make sense to have it as a numeric metric?
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.".
JK
----- Original Message -----
From: "John Mazzitelli" <mazz(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Thursday, September 20, 2012 3:12:56 PM
Subject: Re: MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)
Elias could respond (I think he's on this mailing list) for his particular use-case
that triggered his BZ.
Even though the value may be in epoch millis (that is, # of milliseconds since Jan 1,
1970), they should probably be displayed at a formated time - preferrably in the
browser's time zone/locale.
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? I can't remember - but we
only show the traits as raw strings right? (we don't format them using a specific
units converter right? Is that the issue?) I would say, are we sure traits are the only
valid use-cases for these units? I would ask Elias what he needed this for (perhaps add a
NEEDINFO to the BZ to ask for the use case?)
----- Original Message -----
Hi,
in plugin descriptor, there can be a metric definition with unit
type "epoch_milliseconds" or "epoch_seconds"
(rhq-configuration.xsd allows it). What kind of metric should
could be represented by epoch_milliseconds? Shouldn't the exact
time moments (what values epoch_milliseconds represent) be
addressed rather by traits?
I am asking because the values of this type are not formatted
(
https://bugzilla.redhat.com/show_bug.cgi?id=857144).
I think these two unit types should be removed from MeasurementUnits
and xml schema, however there might be some plugins out there using
it, so what about deprecation? Are there any edge cases, when these
unit types do make sense?
JK
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel