[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] Question about example of Sec. 4.6 Metrics
Satomi-san,
Attached is further elaboration of the example. I show two sets of
examples, the first set (which was part of my original attachment) is
for TimeScope=SinceReset (or PointInTime in the case of
LastResponseTime). The second set is for the same data for
TimeScope=Interval (for those NOWS metric properties that can be either
SinceReset or Interval). I assume that Duration = LastUpdate - ResetAt,
as you show in your example of MaxResponseTime.
I did find one error in my original example. LastResponseTime (a
PointInTime metric) MUST NOT have a ResetAt.
I did notice that the MOWS metric properties are not perfectly in
conformance with the MUWS, which requires a GatheringTime instance for
each metric property. This metadata is not specified for the MOWS
metric properties in the MOWS spec. I assume that the MOWS metrics are
"OnChange". (IMHO, I think Bryan's comment, which you quote, may be
confusing TimeScope=interval with GatheringTime=P(eriodic and/or
CalculationInterval.)
Note that at one point the text states that Duration can change every
time the metric is updated. I assume that one case in which this would
be true is in the case of MaxResponseTime. Each time a new
MaxResponseTime is hit, the duration changes to the duration from the
last MaxReponseTime. (???--This strikes me as a little strange. The
statement seems to conflict with the earlier statement that "a duration
usually remains the same for every reading of a metric.") Thus, in this
case ResetAt has no significance, since the first response time after a
"reset" will be the max. (This idea is reflected in the second example
of MaxResponseTime.)
Also, the definition of ChangeType=Gauge in the MUWS text is
unacceptable--it says noting.
I hope
Kirk Wilson
Architect, Development
Office of the CTO
802 765-4337
-----Original Message-----
From: Mitsunori Satomi [mailto:Mitsunori.Satomi@hds.com]
Sent: Friday, September 09, 2005 9:47 PM
To: Wilson, Kirk D; Murray, Bryan P.
Cc: wsdm@lists.oasis-open.org; fred.carter@amberpoint.com
Subject: RE: [wsdm] Question about example of Sec. 4.6 Metrics
Bryan, Kirk and Jane. Thank you for help.
Kirk, I make sense of your example.
But the point I'd like to clarify is just what Bryan mentioned as
follows,
> - 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.
IMHO, if "reset" event is occurred before the start time of Interval,
I guess that the "reset" event has no effect to the measurement of this
interval.
So in this case, if "ResetAt" attribute is returned, "ResetAt" value
should
indicate the
beginning time of interval. (Because I think that the start of interval
means nearly the "reset" event.)
And I guess that we should include at least one example of "Interval"
metric
in the Primer's example
like followings,
<mows-xs:MaxResponseTime
ResetAt="2005-06-14T14:14:20.1881806-04:00"
LastUpdated="2005-06-14T14:24:20.1881806-04:00"
Duration="PT10M" >PT0.02S</MaxResponseTime>
One of the reasons we confused in this topic, we removed the "reset"
operation from WSDM 1.0 spec, I think.
Anyway, we should discuss about this topic and have to clarify the value
of
"ResetAt" and also meaning of "reset" of metrics in the next version of
WSDM
specification.
Regards,
----
Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com)
Director, Advanced Software Architect
Hitachi Data Systems Corporation
> -----Original Message-----
> From: Wilson, Kirk D [mailto:Kirk.Wilson@ca.com]
> Sent: Friday, September 09, 2005 12:42 PM
> To: Murray, Bryan P.; Mitsunori Satomi;
> fred.carter@amberpoint.com; wsdm@lists.oasis-open.org
> Subject: RE: [wsdm] Question about example of Sec. 4.6 Metrics
>
> I have reworked the data in the 4.6 Metrics example (see attached).
> Does this data make more sense? If so, Heather/Bryan, please
> substitute the example (in vers 17 the example replaces lines
> 4736 - 4762.
>
> I still need to study the issues of what attributes support
> what metadata for metrics. (IOW, there may be changes to the text.)
>
> Kirk Wilson
> Architect, Development
> Office of the CTO
> 802 765-4337
>
> -----Original Message-----
> From: Murray, Bryan P. [mailto:bryan.murray@hp.com]
> Sent: Thursday, September 08, 2005 9: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".
>
> From line #4801 to 4803,
> > On the other hand, the management service may report the data as
> occurring
> over an interval of time.
> > In that case, the ResetAt attribute is optional, and the LastUpdated
> attribute should not be used.
>
> I understand that value of ResetAt attribute means the
> beginning time of this interval. Is that correct?
>
> Regards,
> ----
> Mitsunori SATOMI (mailto:Mitsunori.Satomi@hds.com)
> Director, Advanced Software Architect
> Hitachi Data Systems Corporation
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS
> TC that generates this mail. You may a link to this group
> and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS
> TC that generates this mail. You may a link to this group
> and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]