Skip to content
pvdh edited this page Jun 14, 2015 · 3 revisions

Rationale: Why would anybody need a munin_exporter?

I've been using Munin for more than 10 years now to collect usage data of my servers. The munin-node component and it's plugins over at munin/contrib are amazing and fun to write. Fun to write is probably the reason there are so many good ones aroung. ;-)

However, the backend shows age and limitations like rrd-based storage (bad if you collect lots of metrics), fixed 5 minute sampling interval and server-side visualization by generating gifs (either pregenerated or on demand).

If you have been using munin in the past, it should be easy to provide exactly the same metrics to prometheus, by running the exporter and to evaluate wheter or not changing the backend will provide benefits like less load on the server collecting the metrics. Just continue using your old setup and have prometheus running along. Perhaps one day you'll simply power off your old munin-server.

If you haven't used munin in the past but need some specific metrics, just head to munin/contrib and consider using one of those plugins in combination with munin-node and munin_exporter. It may well be worth the effort.

data types

Munin defines counter, gauge and derive as possible data types a plugin may report. Prometheus however uses counter and gauge only.

Munin Prometheus
Gauge Gauge
Counter Counter
Derive stored as Counter, apply "rate" when graphing. ("deriv" is misleading)

Limitations

  • so far, there is no support for multigraph (not even on the roadmap)

Further development

munin has an integrated alert-system (e.g. sending emails, notifying nagios when metrics get out of hand), just like prometheus does. Some limits are encoded in the plugins, so munin_exporter should be able to suggest alerting rules for prometheus. It could suggest some dashboards for promdash etc. as well