Trending growth where there is no registered data source
Have you ever needed to trend the growth of ‘something’, but no registered data source existed that could provide the values you needed to collect? With the combination of Windows and all the applications it can host, we have countless performance counters at our disposal. Even still, there are many applications and scenarios where a registered data source doesn’t exist.
For example, if we wanted to trend growth of certain types of Active Directory objects or Exchange mailboxes, we need to create a data source to return a value to a collection workflow to be stored in the data warehouse for historical reporting. Or perhaps we need to do some math before returning the value, because the value we want to store is the result of a calculation of more than one counter. Whatever your scenario is, if you can programmatically return a numeric value using VBScript, JScript or Powershell, you can trend growth using Operations Manager.
In this article, I will demonstrate how this can be done with a fairly basic VBScript and two modules; Microsoft.Windows.TimedScript.PerformanceProvider and Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData. The goal in this demonstration will be to track growth of a folder.
Create the data source
Since there is no performance counter that will provide the sampled values that we need (file count), we’ll need to create a data source. We’ll create a script to test a folder and return the number of files currently in the folder. Keep in mind that for whatever application we are trending, as long as we can programmatically count the number of objects, we can trend growth.
Below is our example script. Read this for more information about developing scripts that will return performance data type for consumption by SCOM.
Tip: First develop your script and ensure that you can return a numeric value. Then add the required MOMScriptAPI.CreateTypedPropertyBag method after you having a working script. Code in red font in the script below was added after I had developed a working script that returned the value I needed.
' #Include File:Script.Based.Performance.Collection.Rule.CountFiles.vbs
' -------------------------------------------------------
'
' This script is provided "AS IS" with no warranties,
' and confers no rights. Use of included script sample
' is subject to the terms specified in the Terms of
' Use located at:
'
' https://www.microsoft.com/info/cpyright.mspx
'
' Jonathan Almquist, Microsoft
' 11-23-2010
' Script.Based.Performance.Collection.Rule.CountFiles.vbs
'
' Intended to be used as a sample in conjunction with Operations
' Manager 2007.
'
' Sample MP: Script.Based.Performance.Collection.Rule
'
' -------------------------------------------------------
' Typed property bag constants
PROPERTY_TYPE_PERFORMANCE = 2
' Declarations
Dim sObjectName, sCounterName, iValue, oFolderPath, oFolder, oFile, oFSO, oArgs
Dim oAPI, oPerformancePropertyBag
' Instantiate objects
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oArgs = Wscript.Arguments
Set oFSO = CreateObject("Scripting.FileSystemObject")
' Get path to folder
oFolderPath = CStr(oArgs.Item(0))
' First check if folder exists. If not, exit script.
If (oFSO.FolderExists(oFolderPath)) = FALSE THEN
WScript.Quit
End If
'Count Files
iValue = 0
Set oFolder = oFSO.GetFolder(oFolderPath)
For Each oFile In oFolder.Files
iValue = iValue + 1
Next
Set oPerformancePropertyBag = oAPI.CreateTypedPropertyBag(PROPERTY_TYPE_PERFORMANCE)
sObjectName = "Sample Management Pack"
sCounterName = "File Count"
oPerformancePropertyBag.AddValue "ObjectName", sObjectName
oPerformancePropertyBag.AddValue "CounterName", sCounterName
oPerformancePropertyBag.AddValue "Value", iValue
oAPI.AddItem oPerformancePropertyBag
Call oAPI.ReturnItems
' #Include File:Script.Based.Performance.Collection.Rule.CountFiles.vbs
As you can see, the script is very basic and would function without the code in red font. This is just an example of how simple it is to create a data source that can be consumed by SCOM and mapped to a performance object for collection.
Author the collection rule
Now that we have a data source, we need to author a rule that will collect this data. This will be a composite workflow that will run the script on a schedule, map the sampled value to a performance data type and then store the value in the data warehouse as a performance counter value.
In the Authoring Console, create a new script-based performance collection rule.
Note: I chose Windows Computer as a target strictly for demonstration purposes. When developing for production use, I rarely (if ever) select Windows Computer as a target for rules or monitors. Only select those types of classes in which you need to collect this data. You might need to author a new class and discovery for your requirement.
On the next screen, enter an interval that makes sense for your application. Depending on how frequent the value changes and how detailed you need your report to be, you may need to collect more or less frequent.
Next, enter the script details.
The script in this example requires a directory path, so it knows the folder to sample for file count. If your script requires parameters to be passed in, you’ll need to enter these. Parameters are cardinally ordered and are space delimited.
On the performance mapper screen, we’ll use variable notation to map the value returned by our script to a performance data type. Note that these are name-value pairs, and these variables were defined in the script. The MOMScriptAPI methods used in the script create these name-value pairs and return them to this next module.
One thing to consider. And that is whether you want to write this performance data to both databases. Since this is collected for the purpose of trending (reporting), this isn’t really considered operational data. If you are keen about implementing good optimization practices whenever possible, you can configure this rule to only write the collected performance data to the data warehouse. This will save operational database space, and reduce the amount of computing and network resources required to store this data.
Do this by opening the rule properties and selecting the modules tab. Highlight the WriteToDB module and click Remove.
This collection rule is now ready to test. After a few days of collecting, run a generic performance report to see the growth trend.
Now take a look at what Dan Savage shared on the momteam blog. See scenario 4 for a custom trend analysis and forecasting report. You can see the future!