RE: [wsdm] Question about example of Sec. 4.6 Metrics

["Tony Gullotta" <tony.gullotta@soa.com>]

I agree that the way metrics are defined in MUWS is flexible, but can be
confusing. And in MOWS, frankly I think we've left too many options that
will just make building managers that much more complicated.

I was hoping we could address some of the combinations of these
attributes and metadata configurations in the primer. For example, you
are supposed to be able to subscribe to a metric property for any
changes like other WS-ResourceProperties. However, does this make sense
for counters who's GatheringTime is onDemand? Even onChange could end up
sending out a barrage of notifications if it's a SinceReset counter. Or
why would one implementation of a MOWS management agent use SinceReset
counters and another use Interval counters for the same metric?

Tony

-----Original Message-----
From: Murray, Bryan P. [mailto:bryan.murray@hp.com] 
Sent: Thursday, September 08, 2005 6:45 PM
To: Mitsunori Satomi; fred.carter@amberpoint.com;
wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Question about example of Sec. 4.6 Metrics

I have always been confused over which attributes may/should/must be
used with which values of metadata for metrics. It is pretty
complicated.

I don't think the spec explains it well, but here is how I understand a
metric with TimeScope=Interval:

- Duration attribute must be used. It specifies the during which data
was collected. The length of the interval might be longer than the
duration. The metadata CalculationInterval migh offer information about
the length of the interval.

- ResetAt may be included with the metric value. There is no clear
indication of what ResetAt means for an Interval metric, however, I
believe it is the time at which the metric was reset. For example, this
metric was reset at midnight, but the interval ends at the end of every
hour. I am not sure what it means to reset an interval metric, except if
the ResetAt value is less than the Duration, which I guess means that
the metric was reset in this interval.

- LastUpdated should indicate the end of the interval for which the
metric represents. LastUpdated - Duration should be the time of the
beginning of the interval. CurrentTime - LastUpdated should tell you how
far into the next interval the data collection is going.


Now if we look at the values used.

- The metric was reset ~1 minute 4 seconds before the metric was read.
- it was last updated only 0.04 seconds after the reset
- the data collection time for this value was more than 24 seconds

I agree with you that the times do not make sense. The values indicate
that the metric was reset in the middle of data collection. I do not
think we should give such an example.

In my mind, metrics should extremely rarely or never be reset. This is
due to the complications it offers in a multiple manager situation. So,
I would set the ResetAt value to be 3 days ago, or a month ago, or some
long period relative to the other values. I think it is fine to have the
last update time be just a few seconds ago.

What I would do for ServiceTime is make it a SnceReset metric and not
include the duration. I think ServiceTime is an accumulated time for the
total time spent in that service across all requests. So for the example
I would set its value to something that is a few hours. My expectation
is to request ServiceTime with NumberOfRequests and calculate the time
per request myself. This is the behavior that works with multiple
managers.

If my understanding is incorrect regarding the above, please correct me.

Bryan
 

-----Original Message-----
From: Mitsunori Satomi [mailto:Mitsunori.Satomi@hds.com]
Sent: Wednesday, September 07, 2005 7:56 PM
To: fred.carter@amberpoint.com; wsdm@lists.oasis-open.org
Subject: [wsdm] Question about example of Sec. 4.6 Metrics

Hi Fred and folks,

I have one question about the example of "4.6 Metrics" in
wsd-wsdm-primer-15.doc.

Line #4770 to #4796, e.g. mows-xs:ServiceTime is a "Interval" type
metric (not SinceReset) because it has a Duration attribute.
And its attributes are written as follows in this example,

 ResetAt      = "2005-06-14T14:24:58.2181944-04:00"
 LastUpdated="2005-06-14T14:24:58.2582128-04:00"
 Duration      ="PT24.621S"

I think that LastUpdated - ResetAt will be nearly equal to the Duration
value.
But these values of example break this relationship.

(And mows-xs:CurrentTime is "2005-06-14T14:25:21.6589722-04:00".)

In this example CurrentTime - ResetAt is nearly equal to the Duration,
so value of LastUpdated will be adjusted near time of CurrentTime or
Duration should be corrected.


And I'd like to clarify the meaning of "ResetAt" value in case of
"Interval".