MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)

Jiri Kremser jkremser at redhat.com
Fri Sep 21 10:06:40 UTC 2012


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 at redhat.com>
To: rhq-devel at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
_______________________________________________
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