[Greg Smith - Fri at 12:53:55AM -0400]
> Munin is a very interesting solution to this class of problem. They've
> managed to streamline the whole data collection process by layering clever
> Perl hacks three deep. It's like the anti-SNMP--just build the simplest
> possible interface that will work and then stop designing. The result is
> so easy to work with that it's no surprise people like Munin.
It's fairly easy to throw in new graphs, and I like that. One of the
drawbacks is that it spends a lot of CPU building the graphs etc - if I
continue adding graphs in my current speed, and we set up even more
servers, soon it will take us more than five minutes generating the
graphs.
Also, local configuration can be tricky. Locally I fix this by loading
a config file with a hard-coded path. Luckily, as long as the postgres
munin plugins are run at localhost as the postgres user, most of them
don't need any configuration. Still, it can be useful to tune the alarm
thresholds.
> It's also completely inappropriate for any environment I work in, because
> there really is no thought of security whatsoever in the whole thing.
> What I'm still thinking about is whether it's possible to fix that issue
> while still keeping the essential simplicity that makes Munin so friendly.
What layers of security do you need? We're using https, basic auth and
ssh-tunnels. We've considered the munin data to be regarded as
confidential, at the other hand it's nothing ultra-secret there; i.e.
securing the backups of the production database probably deserves more
attention.