vmstats is a java application that collects metrics from vCenter, and sends them to Graphite.
This is a maintaned fork of vmstats written by Tim Conrad. You can find the original on bitbucket.
This will log into your vCenter server, and get all performanceMetrics/stats for all of your virtual machines and ESX nodes. It will then do some manipulation with them, package them up, and send them to Graphite via UDP for graphing.
Keep in mind that Graphite has fairly significant IO requirements, especially during the initial phase of creating the graph files themselves.
The amount of information being sent to graphite is related to the way your ESX nodes and Virtual Machines are configured. As an example, having 10 data stores on ESX will have 1/2 as many stats as having 20 data stores. That statement sounds stupid, but if you have 10 ESX nodes, that's a lot more data.
The CPU requirements for the Java code are fairly small, however.
You'll need a working Graphite installation. Follow the instructions available here: http://graphite.wikidot.com/installation
By default, Graphite should be listening on TCP 2003 - but check the configuration and verify this.
Copy vmstats.default.properties to vmstats.properties and configure to suit your environment. You only need a read-only account in vCenter to gather stats.
Enabling ESX stats will add a significant amount of records being sent to graphite (for 240 VM's with 10 hosts, it almost doubled the amount of stats)
Pick either log4j.rollinglog.properties or log4j.console.properties for how you want logging messages handled. Clearly you could create your own file, as well. Rename the log4j file or adjust the run string below.
Rollinglog will require /var/log/vmstats to be writable by the uid that will be running this process.
Note the file: in the -Dlog4j.configuration section. It's subtle but annoying.
java -Dlog4j.configuration=file:log4j.properties -jar vmstats-
Run with -h to show flags.
You can specify -c /path/to/config to point to a specific config. You should keep separate log4j configurations, however - they should not be logging to the same file.
After you have a configuration that works properly, this software is meant to be run under supervisord. Please check the supervisord directory for instructions on configuration.
This code is a bit cowardly, if exceptions are generated, the entire thing is going bail. After getting some useful exceptions to handle properly, this might change.
The default configuration file is tested and tuned for 4,000 VM's, 220 ESX Hosts.
There's not a lot of configuration file checking, so if all the variables aren't there, it will simply say they're not all there and exit. The -N option to start up without threads can be helpful in this case.
This project is a maven project, so it should auto-grab these dependencies for you.