When we last left our hero MRTG, he was doing simple SNMP Gets and spitting out some fairly basic graphs. While this is terribly useful already, MRTG (and sidekick Routers2.cgi) is capable of much more. In this installment of the MRTG article series, I will be demonstrating how to tap into the power of WMI to further enhance your MRTG experience.
For the purposes of this article, I will be assuming that you have a working MRTG system already running. If you need help with that, please see the previous article in this series: Installing MRTG on a Windows Platform.
Using WMI with MRTG:
WMI, for those who are unfamiliar with it, is Windows Management Instrumentation. It is a capability of every Microsoft operating system since NT version 4, and is enabled by default on all current operating systems. Unlike SNMP, which is “secured” in a disastrous manner (simple community passwords which are sent in the clear), WMI harnesses the built-in authentication methods of the operating system and is much more secure. You can also pull metrics from many more objects using WMI than is possible on SNMP. And if that wasn’t enough already, Microsoft makes available an SNMP provider for WMI, which allows you to pull SNMP information through the WMI interface. (For more information on WMI, please have a look at Microsoft’s WMI site)
But WMI isn’t used just to instrument the operating system, no. All Microsoft enterprise-class products expose metrics to the WMI providers, enabling application-level metrics to be graphed. You want to know how many connections your SQL server is currently hosting? WMI can tell you. You want to know how many files have been downloaded from your FTP site in the past 24 hours? WMI can tell you. You want to know how many errors your web site is encountering? You got it, ask WMI.
Enough talk, let’s see it in action, eh?
MRTG is not capable of fetching WMI information directly, so it will be necessary to write a short script for the metric you are interested in graphing. (I will be providing a number of useful scripts during the course of this demonstration, and they can all be found in a zipped collection at the end of this article.)
Let’s start with a simple one: Processor Load.
Consider the following script (I put a .txt extension on it for ease of use): procLoad.vbs
This is quite a simple script. All it does is take the machine name provided on the command line and fetch the current processor load. Note the Impersonate directive; you must make sure the account you are using to start your CRON service on the MRTG system has permission to run WMI queries on the TARGET system. If Cron doesn’t have permission to query WMI on the target system, MRTG will not get any data to graph. Remember, WMI relies on OS security.
Open a command window and give the script a shot to ensure it can pull data from the target system. On a command line, simply run
cscript procload.vbs machine_name
You will want to fix any errors before proceeding.
Now that we have our script working (right?), let’s look at what needs to change in our MRTG config file. Remember, previously we fetched processor usage on a Windows system with the following line in our .cfg file:
Target[CPU]:
.1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.1.48&.1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.1.48:public@machine_name
With WMI, the Target line changes to:
Target[CPU]:
`cscript //nologo \VBScripts\procLoad.vbs machine_name`
Note that we have specified the location where cscript.exe can find the vbs script, and we have also wrapped the whole command in single quotes. Both of these are important.
Save the cfg file and you’re finished. How easy was that?
If you want to get fancy, you can even pull data from 2 different machines in a script. Let’s say you had a webfarm, for instance, with 2 servers sharing the load. In order to see how many ASP sessions were active on both machines, you would have a script similar to the one I lovingly call aspsessions.vbs. And then your target line in the MRTG cfg file would look like:
Target[ASPSessions]: `cscript //nologo \VBScripts\aspsessions.vbs
machine1 machine2`
Done and done!
“Dang, Beau, that was easy!” I hear you saying, “But how do I know what can be queried in WMI, and what all the objects are called?” Fret not, gentle reader, for the heroes at Microsoft’s Script Center have delivered unto us a miracle called the “Scriptomatic“. The Scriptomatic, when executed on the target system, will display all WMI objects that can be queried on the system, including any application-specific providers. Note that it MUST be run on the system you are expecting to monitor to get a complete list of objects for that system. But don’t worry, the Scriptomatic is only a single file, and doesn’t need to be installed or registered or anything. Just run it.
I have just scratched the surface of what is possible when you combine WMI and MRTG together. I hope this article has encouraged you to explore the capabilities of WMI further, and discover all the useful information it now exposes.
Here are some additional scripts you can play with:
Memory Usage
Current HTTP Users
Current Disk Queue Length
Current Disk Usage
Current SQL Connections
All Scripts plus Scriptomatic (zipped)
Beau Monday has been in the computer industry for 17 years and holds a
myriad of certifications from Microsoft, Cisco, Checkpoint, Nokia, SANS, and
others. Beau specializes in monitoring and securing Microsoft-based
networks, and he’s currently the Security Officer at SumTotal Systems in
Seattle, where he makes his home with his wife and 2 cats. More of Beau’s
security articles can be seen at his weblog (http://bmonday.com)
