I’m out at a customer site this week, and while the customer is awesome, a couple of things have made me very frustrated.
The first concerns Windows Management Instrumentation (WMI). OpenNMS now supports native WMI (thanks mainly to Matt Raykowski) and this is the first time I got to play with it. Works like a charm and how you would expect with OpenNMS – simply. I edited wmi-config.xml, put in a valid username and password, edited capsd-configuration.xml to discover WMI, and turned it on in collectd-configuration.xml. Restart, and now I’m collecting a ton of WMI stats out of the box.
So far, so good.
One of their concerns is monitoring Exchange 2007. So I think, great, I’ll just configure some WMI classes and objects dealing with Exchange, make some graphs, and we’re done.
Not so fast.
First, there doesn’t seem to be a good place to get a list of all the available WMI classes easily. I did find some rather thick Technet docs, but for the most part it is a lot of digging. It would be nice if there was a MIB-like document that described them.
Second, it turns out that Exchange 2007 doesn’t support WMI. You have to use Powershell “cmdlets” and script it from there.
What?
Okay, so Microsoft decides that SNMP isn’t good enough to use for exchanging data between a manager and an agent, so they invent their own management protocol called WMI, and a few years later decide it isn’t worth supporting.
(sigh)
My second source of frustration deals with VMWare. The client currently uses ESX, so I’m like – hey, just go in, enable the Net-SNMP agent, enable the “dlmod” for the ESX MIB and we’re set.
That is all well and good, but they are migrating everything to ESXi which, wait for it, doesn’t support SNMP. Well, at least GETs.
From the VMWare documentation (PDF), you first get:
… hardware monitoring through SNMP continues to be supported by ESXi, and any third-party management application that supports SNMP can be used to monitor it. For example, Dell OpenManage IT Assistant (version 8.1 or later) has ESXi MIBs pre-compiled and integrated, allowing basic inventory of the server and making it possible to monitor hardware alerts such as a failed power supply. SNMP also lets you monitor aspects of the state of the VMkernel, such as resource usage, as well as the state of virtual machines.
Okay, good, but the next paragraph reads
ESXi ships with an SNMP management agent different from the one that runs in the service console of ESX 3. Currently, the ESXi SNMP agent supports only SNMP traps, not gets.
Again, what?
I mean, okay, traps are great, but how am I supposed to monitor “resource usage” if I can’t do a GET?
In both cases there does exist a non-standard, proprietary API that can be used to mine this data, and if the demand is high enough we’ll definitely put it into OpenNMS. Thank goodness the architecture is abstracted so that it is easy to add such plugins without having to re-write everything.
But, c’mon people, we have standards for a reason. Can’t we all just get along?
Tarus there is actually rationalization for the ESXi issue. In VMWare speak ESXi is supposed to be the “secure” implementation as it has no console really at all and it can’t be snmpwalked. Why they didn’t choose to do SNMP v3 or something like that the world may never know, but that’s their reasoning.
No console? I’d say that that’s pretty secure, install something that you can never access! Great idea on the v3, btw.
Tarus,
You can’t really get a “list” of class, properties, commands, etc from the web for WMI but WMI itself is browse-able. When I was developing the plugin I was using CheckWmi to show me a list of classes available in Win32_ComputerSystem, and so on. Because of this you can connect to a given system and find what classes/etc are available on it. Microsoft provides a tool to do this:
http://www.microsoft.com/downloads/en/details.aspx?familyid=6430f853-1120-48db-8cc5-f2abdc3ed314&displaylang=en
That’s a very long way of saying “download Microsoft WMI Object Browser to view available classes.”
FYI I just heard from a source that with vSphere 5 ESX is essentially just going to become ESXi, doing away with the Service Console all together. I personally think this has something to do with VMware buying Suse.
@David, the console in ESX land is nothing more than another VM running a custom version of RHEL that allows for command line access to the hypervisor and to load 3rd party apps (i.e. Dell OM SA) at the lowest level. VMware has never put much of an emphasis that I can see on the CLI choosing to focus on the GUI VIClient instead. I test prepping for the VCP right now and I don’t think I’ve ever seen a reference to any of the useful CLI commands in their certification program.