3 ms·
Munin is my favorite monitoring tool. One reason (among many mentioned here already) is that its information density is higher than anything else. When your sit
by pjungwir 6y ago
Munin is my favorite monitoring tool. One reason (among many mentioned here already) is that its information density is higher than anything else. When your site goes down and you need to know why, the page full of tight graphs is incredibly helpful. You can scan everything without any clicks at all and see if the problem is disk, RAM, database locks, etc. This compactness is the main criterion Tufte uses throughout Visual Display of Quantitative Information. I don't think Munin is doing anything clever or original (nothing like the map of Napolean's march), but it is far more useful than most of the custom d3 "dataviz" stuff you see. And it's way faster to navigate than something like datadog. And since it's just serving static HTML, the page loads instantly.
I think the homepage was overdue for a redesign, but I hope they don't redesign the tool itself! :-)
If they are trying to improve their communication, one thing I would have appreciated when I got started years ago is a clearer tutorial-like explanation about where the client & server live, how both execute (daemon vs cron), and who opens a connection to whom. Just the basic big picture architecture. It seemed difficult to find that information. EDIT: This right here: "Munin has a master/node architecture in which the master connects to all the nodes at regular intervals and asks them for data." Great!
ANOTHER EDIT: I see they are emphasizing how easy it is to write plugins. I can attest to that. I've written plugins for Postgres and Phusion Passenger, and both were really simple. Also there are tons of "contrib" plugins that probably already have most of what you want (even beyond the extensive default system-level metrics).
AND ANOTHER: The graphs at http://demo.munin-monitoring.org/munin-monitoring.org/www.munin-monitoring.org/ http://demo.munin-monitoring.org/munin-monitoring.org/www.mu... are more painful to read than my existing deployments. They are 497x261, and my own graphs are 499x277. That doesn't seem like enough difference to matter. The font is smaller though. Having to squint to read the graphs makes the display a lot more effort to read. It's a small thing, but I could feel the difference immediately.
- kijin 6y agoTotally agreed. The "static HTML" part is IMO munin's single most important feature. You can point any webserver at the output directory (or just download the output directory) and immediately browse the contents. There's no need for CGI or any daemon to be running in the backend, which is extremely helpful when you might be trying to diagnose why said daemon isn't running. I also agree that documentation about the basic architecture and execution method needs improvement. At some point in the CentOS 7 lifecycle, a minor update to EPEL's munin package deleted its own crontab file, effectively disabling the master, without providing an obvious alternative such as a systemd timer. I couldn't find any explanation about why it did that.
- manigandham 6y agoHave you tried netdata? https://www.netdata.cloud/ https://www.netdata.cloud/ I've switched to this for all hosted/decentralized monitoring.
- dannyman 6y agoThe graphs appear to scale based on viewport size.