[Oslc-pm] Questions on spec draft/vocabulary
Julianne Bielski
bielsk at us.ibm.com
Thu Sep 27 11:41:32 EDT 2012
One concern I have about the refactoring approach is that the so-called
"Best Practice" metrics is now going to be whatever a particular provider
says they are vs. something that we've asserted. In other words, more like
CIM. And, clients must always introspect Resource Shapes to know what
they're going to get.
-- Regards,
Julianne Bielski, STSM
ITM Core Chief Architect
Tivoli, IBM Software Group
tel: (919) 224-1170 (T/L) 687-1170
e-mail: bielsk at us.ibm.com
"All growth is a leap in the dark, a spontaneous unpremeditated act
without benefit of experience." — Henry Miller
From: John Arwe/Poughkeepsie/IBM at IBMUS
To: oslc-pm at open-services.net,
Date: 09/26/2012 02:54 PM
Subject: [Oslc-pm] Questions on spec draft/vocabulary
Sent by: oslc-pm-bounces at open-services.net
While synching up the vocabulary document with the current spec draft, the
following questions occurred to me.
Q1: pm:process and pm:disk do not seem like they are properties of a
generic PerformanceMonitoringRecord. They seem like properties of a
computer system or similar animal. So they may be in the wrong table, and
possibly more appropriate in another namespace like CRTV. I.e. if I
mentally say they're just in the wrong table, then (in the Perf Mon
vocabulary) I have to come up with a description for them that applies to
PerformanceMonitoringRecords generally, not computer systems specifically.
I can imagine ways to re-use those concepts in places other than computer
systems, FWIW (resource pools, images, ...).
Q2: pm:availabilityStatus - I'm unclear what this is the status of. I
thought it would be the status of a monitoring agent, but it's in the
PerformanceMonitoringRecord properties table.
Q3: Metric URI PercentageSpaceUsed - "Percentage" in the name seems
limiting. I thought that aspect (units) was orthogonal to the metric
semantic, as the diagram above the PerformanceMonitoringRecord table
suggests. I would expect something like
ems:observes #obs1,
...
#obs1 a ems:Measure,
ems:metric pm:SpaceUsed,
ems:numericValue 80,
ems:unitOfMeasure dbpedia:Percentage.
Q4: Metric URI VirtualMemoryUtilization (and similar) - "Utilization"
seems to imply percentage (sensible, and borne out by the comments), which
makes me think it's units again.
Q5: Taking Q3 and Q4 together, seems like I have [disk]space, virt mem,
real mem, cpu as "consumable resources"; for each of those I need metrics
for "amount in use". I see the "amount in use" pattern repeated for heap,
buffer pool. Which makes me wonder if these should look something like
(which extends ems:Measure in new ways)
ems:observes #obs1,
...
#obs1 a ems:Measure,
ems:metric pm:AmountUsed, (or free)
ems:numericValue 80,
ems:unitOfMeasure dbpedia:Percentage,
pm:metricQualifier pm:Cpu (or
heap, virt mem, etc)
Q6: NumFailedSqlStmts ... similar pattern(?) Num = units,
Failed=qualifier, SqlStmt=metric
Q7: TableReorgNeeded - sounds like a boolean, but it's in the metrics
list. Was the thinking that we'd fit booleans into ems:NumericValue by
"casting" them to 0/1?
Q8: PercentageTimeThreadPoolMaxed vs PercentageTimeJCAThreadPoolMaxed ...
we need to spell out JCA, and understand the relationship between these
two so I can sufficiently distinguish them in the desc. As currently
written, I'd expect JCA apps to be a subset of all apps. Ditto "database
apps".
Q9: VMCPUPercentReady - how is this related to CPUUtilization? I'm
familiar with many different CPU utilizations from my performance days in
a previous life. I'm wondering if the "VM" part however requires a
distinct metric, or is it implicit from the context in which the property
occurs? E.g. should a client "know" that the CPU is VM CPU not "normal
CPU" (whatever that is ;-) ) based on the rdf:type(s) of the resource that
the PerformanceMonitoringRecord describes?
Q10: OverCommmittedDiskUtilization - is this anything other than SpaceUsed
(disk,%) - 100 ? I'm trying to tease out what's different about this
(e.g. is there an "allocated/reserved" notion that is distinct from
"used"), and also whether it applies naturally to resources other than
disk.
If we do end up following some path like metricQualifier, I would
recommend making it multivalued. Then I could define qualifiers like
real, virtual, memory and combine them as needed rather than having to
enumerate each combination as a separate URI. I'd have to go back to
ems:metric's definition to see if that is in fact any different.... maybe
we just make ems:metric itself multivalued, under the "less is more"
principle.
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
_______________________________________________
Oslc-Pm mailing list
Oslc-Pm at open-services.net
http://open-services.net/mailman/listinfo/oslc-pm_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20120927/e62cd9a1/attachment-0003.html>
More information about the Oslc-Pm
mailing list