[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