[Oslc-pm] Questions on spec draft/vocabulary

[John Arwe]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20120926/46f6cac4/attachment-0003.html>