One of the default plugins is memory use. In this graph you can see the memory usage for one of our application servers. Last week we changed some configuration so the application won't grow to eat a ton of memory every few hours.
Other similar tools are Cacti and Ganglia. I've played with both but they didn't hook me like Munin did. I never really liked how Cacti and Ganglia is put together, but the sensibilities of Munin are ones that makes a great tool.
The basic Munin configuration is extremely short and simple; in particular on the monitored nodes.
Everything is driven by "plugins" - again very simple and self-contained. The plugins "self-configure", for example giving the list of mount names for the disk usage graphs so there's no configuration. That way most of the plugins don't need configuration, making it's easy to just duplicate the configuration to all your nodes.
It's flexible, just in the right spots. And when you do need a configuration override for a plugin it's easy to do. The configuration system even fits well the puppet configuration tool - another favorite.
We run multiple MySQL instances on several of our database servers and the existing MySQL plugins don't handle that, but since all the plugins are shell or Perl scripts, it will be easy to fix.
The only thing I don't like about Munin is it wants an agent on every system it monitors. I do not like that. I don't understand why most monitoring systems go this route. In the age of SSH, just creating an account for the monitoring system and throwing a key into its .ssh/authorized_keys file is all I ever want to alter on a system I need to monitor. I'm currently using Nagios and I've written a custom plugin for everything. The plugins all basically do something like "ssh remotemachine df -h" and then process the result. If there's a need for running an agent, I can't think of it.
You can of course write a "proxy" plugin that uses ssh in the same way for munin too.
Nicolai