esxplot is a GUI application that lets you explore the data collected by esxtop in batch mode. The program takes a single command line argument which is the esxtop batch mode output file. You can also simply start esxplot without any arguments, and enter a dataset file via the File attribute of the menu bar. Esxplot loads the data in this file and presents the metrics as a hierarchical tree where the values are selectable in the left panel. In the right panel, a graph is plotted (value over time) of the selected metric, in this way, you can “browse” the contents of these somewhat unwieldy files.
Eric, I want to thank you for alerting the community to the fork. The current code base has been reworked under the hood a bit to allow for actual continued development which was difficult with the original, single file version. The forked code is not packaged for the "end user", there isn't an installable package for windows or even an egg or easy install just yet.
What I would like interested parties to do for now is to follow the repository, and try it out when you hear of a feature that you think you would be interested in. I also need folks to test this out on vSphere 5. I've seen an elusive behavior with the 1.0 version where it seemed that data was being reported in a 'skewed' fashion which, if it's a bug in esxplot, it would be somewhat serious.
The problem is that I've observed it on a single vSphere 5 host, and then when I changed the state of the host, (powered off a VM) the problem disappeared. I've added extra debugging code into this fork to try and log any bad data being read in (the 1.0 version would just silently ignore it) to try and catch this. If anyone has seen this using the 1.0 version, please report it to me so we can get to the bottom of this. I need to isolate if this is a bug in esxplot or a bug in the way esxtop is writing the csv in batch mode. So the number one priority for me right now is to get to the bottom of the possible bug.
The number two priority is to fix the way the metric selection works so that it is easier to navigate and so that start-up time and response time will decrease with large data sets (> 150 MB). This work should also allow users to load larger data sets without the program becoming unresponsive. The number three priority is the WHERE clause that I've been alluding to in the past which will allow some limited visibility into the actual data when you are pruning the result set with a search query. You can read about it in the repository wiki. This is also a good time to put in feature requests. For now, you can go over to the github repository and add an issue.
I am not going to move away from wxPython for the 1.x release but I am entertaining a new GUI model for the 2.x version, what i'm currently looking at is jPlot/JQuery and/or QT5. I'm glad the program has been useful to folks over the years, my apologies for not updating it sooner, but this was not a primary job function (still isn't but a labor of necessity and love.