SCOM has many different ways to monitor for a file size. Here are some simple examples using script and WMI monitor types.
In this specific example – this will be a monitor to look for Windows Server Registry Bloat. The monitor will inspect the registry hives for the registry file size, and alarm when the size is over a set threshold.
In the console, under Authoring, create a new Unit Monitor. Choose a Timed Script Two State Monitor and choose an appropriate management pack.
Provide a displayname for the monitor, and choose “Windows Server Operating System” as that is the BEST generic targeting class. I will place the monitor under “Availability” as that is most applicable for what I am trying to impact: If the registry file grows to large, the availability of the server might become impacted.
Set a schedule that makes sense for your monitor. Remember script based monitors consume the most resources, especially depending on the complexity of the script, so don’t try and run it too frequently.
Next, give your script a name that it will be compiled in XML as, and paste in the body of your script. Here is my script below. It accepts two parameters: the full path to the file we wish to monitor, and the size threshold.
Option Explicit Dim oAPI, oBag, objFSO, objFile, varSize, oArgs, filepath, threshold Set oArgs = Wscript.Arguments filepath = oArgs(0) threshold =int(oArgs(1)) Set oAPI = CreateObject("MOM.ScriptAPI") Set objFSO = CreateObject("Scripting.FileSystemObject") Set objFile = objFSO.GetFile(filepath) varSize = objFile.Size If varSize > threshold Then Set oBag = oAPI.CreatePropertyBag() Call oBag.AddValue("Status","Bad") Call oBag.AddValue("Size", varSize) Call oBag.AddValue("Threshold", threshold) Call oAPI.Return(oBag) Call oAPI.LogScriptEvent("regfilesize.vbs", 160, 0, "The registry file size of HKLM\SOFTWARE is greater than the threshold of "& threshold &" bytes. The current size is: "& varSize &" bytes") Else Set oBag = oAPI.CreatePropertyBag() Call oBag.AddValue("Status","Ok") Call oBag.AddValue("Size", varSize) Call oBag.AddValue("Threshold", threshold) Call oAPI.Return(oBag) Call oAPI.LogScriptEvent("regfilesize.vbs", 160, 0, "The registry file size of HKLM\SOFTWARE is less than the threshold of "& threshold &" bytes. The current size is: "& varSize &" bytes") End If
Then select the “parameters” button, and provide the params:
Next – we must provide the “Unhealthy” expression. We are returning a PropertyBag from the script as “Status” which will either be “Bad” or “Ok”. The parameter name here is in the format: Property[@Name='Status']
Repeat for Healthy expression:
Configure the health status you are looking to drive:
And alerting. Note: to make the value of the alert higher, you can include data from the propertybags returned in the script, into the alert context. See the examples below for Size and Threshold, along with the computer name:
Here is the finished result of the alert:
And Health Explorer output is also very useful:
If you need to tune the monitor for specific systems – the script arguments are automatically exposed in Overrides:
Additional reading and examples on using script based monitors:
http://technet.microsoft.com/en-us/library/ff629453.aspx
http://contoso.se/blog/?p=1367
You can make this even more sexy, by creating a composite datasource for the script. Then create a Monitortype to call the datasource, and then create Monitors to pass the necessary data. Then you can also create a script based performance collection rule to use the same datasource.
Ok, that’s pretty cool. But – what about another way?
SCOM also has a built in WMI based monitor, which will accept WMI queries to which you can map as performance type data with thresholds. I previously wrote examples of this:
Lets create another new Unit Monitor, WMI Performance Counters, Static Threshold, Simple Threshold:
Give it a name, choose Windows Server Operating System as that is the preferred generic target of choice, and choose Availability.
We will connect to root\cimv2. The query we will use is:
select filesize from cim_datafile where name='c:\\windows\\system32\\config\\software'
The Performance Mapper screen might be the most confusing. We simply just need to make up the data as to how we’d like to see it inserted in SCOM.
I used “FileSize” for the counter, since that is what I am querying from WMI. Then I need to make sure that Value matches the counter name I used, and in the format of: $Data/Property[@Name='QueryObject']$
Next I set my threshold value:
Configure health according to what you desire:
Configure alerting:
The subsequent alert:
And Health Explorer:
Now, we can also create a rule – to collect this value, and have a report for which servers have the biggest registry:
Create a new rule, collection, performance based, WMI:
Provide a name and target:
Provide the same query, and set a frequency that you need for reporting on changes.
Fill out the performance mapper just as we did above:
Now – create a performance view to examine the data:
And even a cool dashboard to show off all of it:
For additional reading on using WMI counters in SCOM: