I'd add (in addition to what you have now) your own procfs tools to extend some of the knowledge the older command line tools.
- For a C app you care about argv[0] that top batch mode displays. But for some shell, python or perl or ruby you care about the actual script name. And for Java you care about the .jar (especially in enterprise envs). Even in your example, it's just some anonymous java process. There could be 12 'java's - I want to know whether it's our app or some Enterprise Crapware agent.
- Likewise load average - for a multicore system a load average of 10 could be quite underutilized - if I remember correctly, the run queue is actually (number of logical cores) long.
There's also some things you audience might not be familiar with, but would find valuable - tools like this can be a good way to show off some of this stuff.
- Do you have ethtool in there? Particularly patch disconnect events.
- You can also ask the switch what ports the host is connected to with a two liner LLDP/CDP thing.
These kinds of things are GOLD to people that know they exist, but as you know, Unix tools aren't very discoverable - your app could help with that.
- Not sure if this is relevant, but if you do monitor network stuff, try and steer users away from ifconfig, it's not maintained and will simply skip certain interfaces (eg, trading arbitrage desks used vlans on top of virtual IPs on top of bonds, these are completely invisible to ifconfig. There are problably other cases I haven't run into yet).
Are you guys on Twitter? I'm also working in similar space (used to work at Red Hat and IBM as a Linux specialist, now I write node apps all day). Not competing, but doing similar stuff.