[Oslc-pm] some metric examples

John Arwe johnarwe at us.ibm.com
Mon May 21 18:20:38 EDT 2012


Julie our fearless leader was chatting with me about a couple of concrete 
instance examples, so I wanted to get some other people thinking about 
them, the general ideas and discussions they bring up so that we can start 
generalizing into vocabulary and then resource definition(s) and/or 
shape(s).  All of which is very doable via email, so hey just using the 
community here.  This is the kind of discussion that instance examples are 
great to flush out.

As you'll quickly realize, much of the discussion is about two levels: not 
just the -value- (data) of a given metric, but also information about the 
implementation (e.g. source token) and information that is information 
about the property -other than- its value.  I like this, because having 
some background in performance analysis myself, it is something I had 
thought about some.

---------------------------------------
example 1: 
Application Resource = collection of references to monitored attributes

monitored attribute
    name: CPU Utilization
    unit of measurement: percent
    source token: percent_cpu_utilizaion
    inverse frequency: 20
    reference to value
    description: Describes how much CPU is in use verses how much is 
available for use

value
    dependsOn monitored attribute
    type: integer
    value: 80
    timestamp: 20120512

---------------------------------------
example 2: 
monitored attribute
    name: Average Pool Size
    unit of measurement:
    source token: DB Connection Pools
    inverse frequency: 20
    reference to value
    description: Describes how many connections are available in the 
database connection pool on average

value
    dependsOn monitored attribute
    type: integer
    value: 68
    timestamp: 20120512

---------------------------------------

So of course I asked a bunch of questions/comments:

JA: at least some of monitored attribute I had envisioned being in the 
provider's resource shape.  which I suspect should be fine from your pt of 
view; 1 res shape/provider/instance (you might have all instance use the 
same shape, your choice).  value.type would also live in the res shape.

JB: i'm showing the metrics as a collection in the resource
JA: I saw that - I don't think they need to be refs however.
JB: oh, so you envision value being directly in the attribute. so you 
don't think it would have its own properties
JA: that's usually simpler/less surprising. [Here I'm exposing my 
OSLC-process-bias toward doing "the simplest thing that could possibly 
work".]

JA: timestamp is interesting - is that "timestamp last collected" or was 
it intended to allow exposing a time series?  don't remember time series 
being in the scenarios, so that could be an itm extension.  w/ timestamp, 
are you trying to "just" stamp the value (not all values from 1 record 
collected at same pt in time), to expose warehouse data, both, neither? do 
you need timestamp per-value or will all values in 1 record have a single 
timestamp?
JB: timestamp per value. if underying data collectors cache at different 
intervals, what is returned to a consumer in one batch may have actually 
be collected at slightly different times.  alternatively, we could decide 
it's the time we wrote the rdf xml

JA: what is the semantics of source token, inverse freq? 
JB: source token is meant to show how the underlying service provider 
names the metric "natively". inverse frequency is the inverse of how often 
the metric is sampled.  inverse frequency is in unites of 1/seconds. so if 
monitoring is done every 5 minutes, the inverse frequency would be 300. 

JA: do you expect type=integer to vary across mult values of the same 
metric?
JB: no
[Given this answer, my earlier supposition about it belonging in the 
resource instance's shape gains support.]

JB: want to know if group thinks we should just embed 'value', and if we 
should add/remove/modify any properties
JA: some of that is going to come back to scenarios.  i.e. if we think we 
need to expose something, and it needs to be in-oslc vs an extension, it 
needs at least one scenario to motivate it.


I don't recall having seen interactions about anything -other than- " 
-value- (data) of a given metric", until David brought in his scenario 
[1].  According to [2] we have not prioritized this yet [TODO], but since 
Julie's instance examples seem to have a similar requirement, it may be 
that we have not rendered all of the implicit requirements in the others 
explicit [TODO - probably on-going as we find them]. Is that the case here 
Julie?  Where would you see your scenarios eliciting a requirement for the 
"metadata" about a metric?

>From what I can see, "the simplest thing that could possibly work" for 
these two instance examples would look like this (by-hand Turtle 
approximation warning):
<record-instance-URL>
        pm:cpuUtilization       80
        pm:connections          68
        oslc:instanceShape      <shape-URL>
        pm:collectedAt          20120512
.
<shape-URL>
        oslc:describes          <pm:MonitoringRecord>
        dcterms:title   "Julie's implementation's shape"
        oslc:property   [
                dcterms:description     "CPU utilization"
                oslc:name       "cpuUtilization"
                oslc:propertyDefinition         <pm:cpuUtilization>
                oslc:valueType          <
http://www.w3.org/2001/XMLSchema#integer>
                oslc:occurs     <oslc:Zero-or-one>
                ]
        oslc:property   [
                dcterms:description     "Average Pool Size"
                oslc:name       "connections"
                oslc:propertyDefinition         <pm:connections>
                oslc:valueType          <
http://www.w3.org/2001/XMLSchema#integer>
                oslc:occurs     <oslc:Zero-or-one>
                ]
        oslc:property   [
                dcterms:description     "Timestamp when data was 
collected"
                oslc:name       "collectedAt"
                oslc:propertyDefinition         <pm:collectedAt>
                oslc:valueType          <
http://www.w3.org/2001/XMLSchema#dateTime>
                oslc:occurs     <oslc:Zero-or-one>
                ]
.

That fails to cover the following properties; they could be covered either 
as PM extensions to resource shape, or as private extensions ... so the 
question to the WG is do/should we have scenarios where a client needs a 
consistent understanding of those, across multiple providers, and is able 
to provide implementation feedback on whatever we specify *this iteration* 
?  Right now these are not called out by scenarios, so by default we'd 
declare them all to be private extensions and/or candidates for future 
iterations.
    unit of measurement: percent
    source token: percent_cpu_utilization
    inverse frequency: 20

I assumed that one timestamp for the entire record would suffice, since 
Julie said that it might, just to pick one.  Same question around 
scenarios, implementation experience, and this iteration.  If we think it 
likely that we need to have the timestamp (or anything else) for each 
value, then we are heading into reification territory I suspect.  Per 
previous discussions, something we've chosen to avoid unless really 
necessary.

I showed the "Turtle" as a very simple class instance with concrete 
properties, rather than as a collection of metric objects and a collection 
of values, since that's what most RDF looks like.  This carries with it 
some assumptions about variability, e.g. that the type=integer part of CPU 
utilization is UNlikely to vary across multiple instances of a single 
implementation (hence a client could likely fetch the shape once, instead 
of once per monitoring record, saving message payload size at the very 
least).  Is everyone willing to live with that?  Do you need to see the 
equivalent alternative in order to have a real opinion?

Glancing quickly through [1], I'm not sure how the consumer selects the 
monitoring granularity or frequency.  The scenario appears to be assuming 
one frequency for monitoring the app, whereas in this example Julie 
appears to be assuming one frequency per metric.  If I took that at face 
value, that says we have two frequencies and then there must be some 
relationship between them - possibly also factoring in the "activation 
status" from [1] - which is sounding complicated, if that's the intent.  I 
might also think about PM defining a "monitoring SP" extension(s?), but 
now my head hurts.  I have the feeling that [1] is talking about different 
resource(s) than the other scenarios, e.g. about controlling an agent 
(which might/not be the implementation behind a PM SP), but I cannot be 
sure at this point.


[1] http://open-services.net/bin/view/Main/PmAppMonitAdmin
[2] http://open-services.net/bin/view/Main/PmScenariosV2
[3] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;table=up;up=#oslc_ResourceShape_Resource


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20120521/dae52aa0/attachment.html>


More information about the Oslc-Pm mailing list