none
Need to return multiple performance items in a probe script - alternatives? RRS feed

  • Question

  • For SCOM 2007 SP1 (soon to be upgrading to R2):

    I want to be able to track some statistics of a process, say Private Bytes, Handle Count, etc. I have a vbscript and have configured a new Probe-based script performance rule. I believe I can only return one value per rule, like Private Bytes. So I'd have to create multiple rules, each with its own script, to collect what I could consider one "set" of data that is related to a particular process.

    In addition to the clutter of multiple rules, it also means that it's having to do the same query repeatedly - once for each rule.

    This is my first venture into SCOM scripting - hopefully I'm missing something; but otherwise wouldn't I need a way in Performance Mapper to set multiple Counters/Instances/Values?

    Thanks for any help!

    Tuesday, July 28, 2009 8:56 PM

Answers

  • In your script, create multiple property bags.  The mapper module essentially does a "for-each" on each property bag returned.

    Psuedo-code:
    oBag = Create property bag
    oBag.AddValue "Object", "Process"
    oBag.AddValue "Counter", "Private Bytes"
    oBag.AddValue "Instance", strProcessName
    oBag.AddValue "Value", obgProcess.PrivateBytes
    oAPI.AddItem (oBag)

    oBag = Create property bag again
    oBag.AddValue "Object", "Process"
    oBag.AddValue "Counter", "Handle Count"
    oBag.AddValue "Instance", strProcessName
    oBag.AddValue "Value", obgProcess.HandleCount
    oAPI.AddItem (oBag)

    oAPI.ReturnItems



    Then your mapper fields look like:
    ObjectName: $Data/Property[@Name='Object']$
    CounterName: $Data/Property[@Name='Counter']$
    InstanceName: $Data/Property[@Name='Instance']$
    Value: $Data/Property[@Name='Value']$

    • Marked as answer by DougBee Wednesday, August 5, 2009 8:28 PM
    Wednesday, August 5, 2009 4:34 PM
    Moderator
  • There are many ways you could accomplish your goal.  I'd recommend building 1 data source module type (DSMT) that does the following:
    a: executes your VBscript which creates multiple performance values (using oAPI.CreateTypedPropertyBag(2) see http://msdn.microsoft.com/en-ca/library/dd850158.aspx) and then returns all dataitems as a set using oAPI.ReturnItems.  you could use a module like Microsoft.Windows.ScriptPropertyBagProbe which returns a property bag
    b: Then using the mapper module called System.Performance.DataGenericMapper you map the dataitems from your collection above into System.Performance.Data dataitems

    Then you can use this DSMT as the data source in a single rule to collect the perf data for your OpsDB or 1 rule per object/counter unique pair for sending the data to the DW.  You could also leverage the same DSMT in a module type such that you can threshold different counters from seperate unit monitors.  As long as the input to your DSMT is the same across all the different usages of it then OpsMgr will automatically "cookdown" (see here for detail on cookdown: http://www.authormps.com/dnn/Concepts/WorkflowBasics/CookDown/tabid/117/Default.aspx) the script so that it only executes once and data flows into the right rules/monitors.

    this example in MSDN may be useful: http://msdn.microsoft.com/en-ca/library/bb437493.aspx

    this is a very powerful MP pattern for producing data once and doing many things with it (like triggering state changes) and collecting data.  Many MPs make use of this pattern.

    good luck and let us know if you have any questions along the way!
    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    • Marked as answer by DougBee Wednesday, August 5, 2009 8:28 PM
    Saturday, August 1, 2009 2:27 AM
  • Ah, thanks Mike! I think I've got it working now. In case anyone is interested, I've got:

    A management pack with a single composite data source.

    That data source has 2 modules:

    Microsoft.Windows.TimedScript.PropertyBagProvider. It is defined as:
    IntervalSeconds: 10 (for testing, and I want to make it an overrideable parameter)
    Synctime: blank
    ScriptName: MyScript.vbs
    Arguments: $Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$
    ScriptBody: (the contents of a working vbscript, similar to the pseudo-code above)
    TimeoutSeconds: 60

    This module has the System.Performance.DataGenericMapper as its NextModule.

    System.Performance.DataGenericMapper is defined with the mapping fields illustrated above.

    Then in the Health Model area, I defined a single Custom rule. It contains:

    A single Data source Module (the one I defined)
    A single Action (Microsoft.SystemCenter.CollectPerformanceData)
    The rule is disabled by default.

    Once I imported the MP and overrode the rule for the computer I wanted to target, data started appearing in the performance view! Whew!

    Thanks to both Vlad and Mike, this is a good start, though I'm getting an odd Perl-like sense in that there are LOTS of ways to do things in SCOM Authoring, and it's quite daunting in the beginning.

    Doug



    • Marked as answer by DougBee Wednesday, August 5, 2009 8:28 PM
    Wednesday, August 5, 2009 8:27 PM

All replies

  • There are many ways you could accomplish your goal.  I'd recommend building 1 data source module type (DSMT) that does the following:
    a: executes your VBscript which creates multiple performance values (using oAPI.CreateTypedPropertyBag(2) see http://msdn.microsoft.com/en-ca/library/dd850158.aspx) and then returns all dataitems as a set using oAPI.ReturnItems.  you could use a module like Microsoft.Windows.ScriptPropertyBagProbe which returns a property bag
    b: Then using the mapper module called System.Performance.DataGenericMapper you map the dataitems from your collection above into System.Performance.Data dataitems

    Then you can use this DSMT as the data source in a single rule to collect the perf data for your OpsDB or 1 rule per object/counter unique pair for sending the data to the DW.  You could also leverage the same DSMT in a module type such that you can threshold different counters from seperate unit monitors.  As long as the input to your DSMT is the same across all the different usages of it then OpsMgr will automatically "cookdown" (see here for detail on cookdown: http://www.authormps.com/dnn/Concepts/WorkflowBasics/CookDown/tabid/117/Default.aspx) the script so that it only executes once and data flows into the right rules/monitors.

    this example in MSDN may be useful: http://msdn.microsoft.com/en-ca/library/bb437493.aspx

    this is a very powerful MP pattern for producing data once and doing many things with it (like triggering state changes) and collecting data.  Many MPs make use of this pattern.

    good luck and let us know if you have any questions along the way!
    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    • Marked as answer by DougBee Wednesday, August 5, 2009 8:28 PM
    Saturday, August 1, 2009 2:27 AM
  • Thanks very much for that post - I'll dig in and let you know how it goes!

    Doug
    Monday, August 3, 2009 1:22 PM
  • Ok, I got lost rather quickly. I already have a script that utilizes CreateTypedPropertyBag(2) with ReturnItems. That works fine on its own, and I tested it with simple rules that map one value that the script returns.

    I'm trying (for the first time) to use the Authoring Console (in R2) to create the DSMT.

    1. I created a composite module type.
    2. I added a Microsoft.Windows.ScriptPropertyBagProbe that contains my vbscript as the body.
    3. I added a System.Performance.DataGenericMapper as you indicated.

    I'm attempting to save what I have so far, but it returns with an error that says ".. is declared as a composite module type and needs to be composed of at least one DataSourceModule as a MemberModule"

    Am I going about this correctly, an if so - which Data Source module type do I need to add?

    Thanks!

    Doug

    Monday, August 3, 2009 6:33 PM
  • you are on the right track.  how do you want your script to be executed?  should it be a scheduler?  if so use a DS like this: System.Scheduler

    thanks,
    vlad


    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Monday, August 3, 2009 6:37 PM
  • Ah, got it. Acutally, I would like it on a regular interval (once every hour, for example) , and have that as something that can changed via an override. So would that be a Microsoft.Windows.TimedScript.PerformanceProvider?

    Doug

    Monday, August 3, 2009 6:41 PM
  • yes the Microsoft.Windows.TimedScript.PerformanceProvider could be used directly if it meets your requirements.  It is composed of the following modules: Microsoft.Windows.TimedScript.PropertyBagProvider (which is made up of: System.SimpleScheduler and Microsoft.Windows.ScriptPropertyBagProbe) and the System.Performance.DataGenericMapper.  the output is System.Performance.Data.
    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
    Monday, August 3, 2009 7:14 PM
  • Hi Vlad,

    I'm still confused! I decided to take the rule I had previously written and open up the MP in the Authoring Console. I can now see that is has a single data source, which is a Microsoft.Windows.TimedScript.PerformanceProvider.  It contains my vbscript which utilizes the ReturnItems that I'll need. In its current state the script is collecting both the Private Bytes and Processor Time for a given process, say HealthService.exe.

    Of course since the simple rule creation only allows for one InstanceName & Value pair, I'm only seeing Private Bytes, unless I write another rule (with the same script) which maps Processor Time.

    In the example above you said: "Then using the mapper module called System.Performance.DataGenericMapper you map the dataitems from your collection above into System.Performance.Data dataitems"

    This is the part that I'm confused on. In my new composite data source, I added the Microsoft.Windows.TimedScript.PerformanceProvider as was in my old rule. I'm not entirely sure what to put in the InstanceName and Value pair here. And System.Performance.DataGenericMapper has its own (single set) of Object/Counter/InstanceName/Value.

    If in my vbscript I have something like this:

    oBag.addValue "processName", objProcess.Name
    sngProcessTime = (CSng(objProcess.KernelModeTime) + CSng(objProcess.UserModeTime)) / 10000000
    oBag.addValue "processorTime", sngProcessTime
    oBag.addValue "privateBytes", objProcess.PrivateBytes
    oAPI.AddItem(oBag)
    oAPI.ReturnItems

    ..where am I actually mapping both processorTime and privateBytes ?

    Thanks for you patience!

    Doug

    Tuesday, August 4, 2009 3:19 PM
  • In your script, create multiple property bags.  The mapper module essentially does a "for-each" on each property bag returned.

    Psuedo-code:
    oBag = Create property bag
    oBag.AddValue "Object", "Process"
    oBag.AddValue "Counter", "Private Bytes"
    oBag.AddValue "Instance", strProcessName
    oBag.AddValue "Value", obgProcess.PrivateBytes
    oAPI.AddItem (oBag)

    oBag = Create property bag again
    oBag.AddValue "Object", "Process"
    oBag.AddValue "Counter", "Handle Count"
    oBag.AddValue "Instance", strProcessName
    oBag.AddValue "Value", obgProcess.HandleCount
    oAPI.AddItem (oBag)

    oAPI.ReturnItems



    Then your mapper fields look like:
    ObjectName: $Data/Property[@Name='Object']$
    CounterName: $Data/Property[@Name='Counter']$
    InstanceName: $Data/Property[@Name='Instance']$
    Value: $Data/Property[@Name='Value']$

    • Marked as answer by DougBee Wednesday, August 5, 2009 8:28 PM
    Wednesday, August 5, 2009 4:34 PM
    Moderator
  • Ah, thanks Mike! I think I've got it working now. In case anyone is interested, I've got:

    A management pack with a single composite data source.

    That data source has 2 modules:

    Microsoft.Windows.TimedScript.PropertyBagProvider. It is defined as:
    IntervalSeconds: 10 (for testing, and I want to make it an overrideable parameter)
    Synctime: blank
    ScriptName: MyScript.vbs
    Arguments: $Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$
    ScriptBody: (the contents of a working vbscript, similar to the pseudo-code above)
    TimeoutSeconds: 60

    This module has the System.Performance.DataGenericMapper as its NextModule.

    System.Performance.DataGenericMapper is defined with the mapping fields illustrated above.

    Then in the Health Model area, I defined a single Custom rule. It contains:

    A single Data source Module (the one I defined)
    A single Action (Microsoft.SystemCenter.CollectPerformanceData)
    The rule is disabled by default.

    Once I imported the MP and overrode the rule for the computer I wanted to target, data started appearing in the performance view! Whew!

    Thanks to both Vlad and Mike, this is a good start, though I'm getting an odd Perl-like sense in that there are LOTS of ways to do things in SCOM Authoring, and it's quite daunting in the beginning.

    Doug



    • Marked as answer by DougBee Wednesday, August 5, 2009 8:28 PM
    Wednesday, August 5, 2009 8:27 PM
  • Can this be done with an OLEDB Probe that shoots out OLEDB Data? How can I pass in OLEDB Data to a "PerfMapper" that converts the oledb data into Performance Data?


    dcazares
    Thursday, May 5, 2011 10:06 PM