Quantcast
Channel: TechNet Blogs
Viewing all articles
Browse latest Browse all 34890

Monitor for file size with SCOM – Using script and WMI examples

$
0
0

 

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.

image

 

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.

image

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.

image

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:

image

 

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']

image

Repeat for Healthy expression:

image

Configure the health status you are looking to drive:

image

 

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:

image

 

Here is the finished result of the alert:

image

 

And Health Explorer output is also very useful:

image

 

If you need to tune the monitor for specific systems – the script arguments are automatically exposed in Overrides:

image

 

Additional reading and examples on using script based monitors:

http://technet.microsoft.com/en-us/library/ff629453.aspx

http://blogs.technet.com/b/kevinholman/archive/2014/03/06/create-a-script-based-monitor-for-the-existence-of-a-file-with-recovery-to-copy-file.aspx

http://blogs.technet.com/b/kevinholman/archive/2014/02/11/opsmgr-simple-example-script-based-monitor-with-script-based-recovery.aspx

http://blogs.technet.com/b/kevinholman/archive/2009/07/22/101-using-custom-scripts-to-write-events-to-the-opsmgr-event-log-with-momscriptapi-logscriptevent.aspx

http://blogs.technet.com/b/kevinholman/archive/2011/03/02/how-to-collect-performance-data-from-a-script-example-network-adapter-utilization.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:

image

Give it a name, choose Windows Server Operating System as that is the preferred generic target of choice, and choose Availability.

image

 

We will connect to root\cimv2.  The query we will use is:

select filesize from cim_datafile where name='c:\\windows\\system32\\config\\software'

image

 

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. 

image

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:

image

Configure health according to what you desire:

image

Configure alerting:

image

The subsequent alert:

image

And Health Explorer:

image

 

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:

image

Provide a name and target:

image

Provide the same query, and set a frequency that you need for reporting on changes.

image

 

Fill out the performance mapper just as we did above:

image

 

Now – create a performance view to examine the data:

image

image

 

image

 

And even a cool dashboard to show off all of it:

image

 

For additional reading on using WMI counters in SCOM:

http://blogs.technet.com/b/kevinholman/archive/2008/07/02/collecting-and-monitoring-information-from-wmi-as-performance-data.aspx

http://blogs.msdn.com/b/steverac/archive/2009/08/30/monitoring-file-size-with-custom-wmi-performance-counter.aspx


Viewing all articles
Browse latest Browse all 34890

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>