MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)

Jiri Kremser jkremser at redhat.com
Thu Feb 27 13:11:08 UTC 2014


Hi,
  
> Thirdly, and Jiri brings this up, how do we handle aggregates and per
> minute values for epoc_milliseconds? I would think per-minute would
> become 'milliseconds', because the delta between K + M and K + N is N
> - M, right?

You are right here, it is doable. What I meant is that epoc_milliseconds and epoc_milliseconds.perMinute has to be 
handled differently. The former should be formatted as a exact date, while the latter as a time period. afaik, we handle all the metrics and its "per-minute" variants the same way, so if you want to implement this, we should keep this in mind, that there must be a exception for this unit type.


> Aggregates may not make sense, but again, the use case is primarily
> for alerting, which occurs at the resource level.

Actually, to me, aggregates doesn't make much sense for any metric that is trending up/down.


In general, I am not against it, afaik, there is no such metric that would benefit from this unit type in standard RHQ plugin set (perhaps something for platform and filesystem, but we have the drift subsystem for it), but there might be a need for it out there. Introducing a new unit type can't break backward compatibility with existing plugins. Feel free to ping me on IRC about it. We will be on GitHub soon, so you can send a pull request, if you want to address this.


jk


----- Original Message -----
> From: "Elias Ross" <genman at noderunner.net>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Wednesday, February 26, 2014 6:38:58 PM
> Subject: Re: MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)
> 
> Hi, I know this is an old discussion but this lack of feature keeps
> coming up for me and I wonder if I can help move this forward.
> 
> To refresh your memories:
> 
> First, I would like RHQ to properly handle the display of
> epoc_milliseconds for metrics (not traits.)
> 
> The use case for this is to monitor things like file modification
> times, times a periodic job ran, process start time, etc. It would be
> nice if the data displayed properly. There are a couple areas that
> would need addressing:
> 1) Table display formatting
> 2) Graph display
> 
> Secondly, creating some sort of alerting system where if a date is
> 'after current_time - N', then send an alert.
> 
> Thirdly, and Jiri brings this up, how do we handle aggregates and per
> minute values for epoc_milliseconds? I would think per-minute would
> become 'milliseconds', because the delta between K + M and K + N is N
> - M, right?
> 
> Aggregates may not make sense, but again, the use case is primarily
> for alerting, which occurs at the resource level.
> 
> I can take a stab at this, but I'm not really an expert at the code in
> these areas.
> 
> On Mon, Sep 24, 2012 at 5:50 AM, Jiri Kremser <jkremser at redhat.com> wrote:
> > 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
> > _______________________________________________
> > 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