[Oslc-pm] Questions on spec draft/vocabulary

[Tuan Dang]

We moved process to crtv.

disk looks like it should be mapped to crtv:StorageVolume ?

Thanks ! T

Tuan Dang
Tivoli OSLC governance, Tivoli Common Data Model
Internet: tdang at us.ibm.com
phone: (919) 224-1242 T/L 687-1242




From:   John Arwe/Poughkeepsie/IBM at IBMUS
To:     oslc-pm at open-services.net, 
Date:   09/26/2012 02:51 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/20120926/c621ff5e/attachment-0003.html>