# munin contrib: where the community's Munin plugins actually live > The Munin contrib repository is not the monitoring system itself but the community shelf next to it, holding contributed plugins, templates, tools and sample configurations. It is a Perl and shell collection with no releases, a deliberately loose commit culture, and a licensing default inherited from Munin itself. **munin-monitoring/contrib** — Contributed stuff for munin (plugins, tools, etc...) - Repository: https://github.com/munin-monitoring/contrib - Website: http://munin-monitoring.org - Stars: 1,045 · Forks: 665 - Language: Perl - License: not declared - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/munin-monitoring-contrib ## Four directories, each with a different social contract The repository is the one for all user contributed stuff related to munin, and it is organised into four directories that each have their own rules. contrib/plugins/ holds third-party plugins, and the README says this is usually where you want to begin your journey, describing it as a plethora of plugins for the most diverse topics, and asking you to take a look and improve existing ones or propose new ones. There is a separate hints document at plugins#contributed-munin-plugins for the contribution conventions, and a browsable gallery at gallery.munin-monitoring.org for an overview of the plugins rather than a raw file listing. contrib/templates/ holds third-party templates, with an invitation to update or create new ones and a bonus-points note for mobile-friendly ones. There is a wrinkle here. The template named official is a loose-synced copy of the one distributed with munin, and it exists to serve as a base for small editions that can be merged into munin itself. The rule that follows is specific: don't copy the whole template, edit the files in this directory directly. contrib/tools/ is for any kind of tool, with the instruction to use this directory instead of a random place on the internet, because it makes things much easier to search for others. contrib/samples/ is for examples of various configs, described as the learn by example way of doing things. ## Elementary commits, and why that matters for a plugin collection The notes to contributors section spends most of its space on commit hygiene, which is unusual for a collection of contributed plugins and says something about how the project is managed. We like to have elementary commits as it is much easier to manage for reviewing and debugging. So please don't be afraid to make as many commits as needed. Merging many commits is as easy as merging one, if not easier. The rationale is that each commit shall have a one-liner commit comment as its first line, ideally with a prefix that shows the part the commit is about, because it makes it very easy to see grouped changes and it enables avoiding to look at the --stat. To know the prefix you should use, the advice is to look at already existing commits. Later lines are optional and should only explain the why it is done in this particular way. The other side of that policy is that pull requests can regroup many commits at once. The requirement is only that you explain in the pull comment the why we should merge it, if it is not obvious. This is a deliberate trade. A repository where each change is one small reviewable commit is far easier to bisect and to revert than one where a pull request arrives as a single large commit, and for a collection where a single broken plugin should be revertable without disturbing the rest, that granularity is the point. The cost is a submission culture that asks contributors to split their work deliberately rather than pushing one tidy commit, which is a real barrier for people new to open source. ## The licence default changed once, and the old terms still exist The licensing section is the part of this repository with a real history, and it is worth reading closely because it describes a change made in 2012 and its consequences. All the code here is licensed with the same terms as munin itself, GPLv2, unless specified otherwise inside a file. In all cases the code shall have an OSI-compatible licence, and asking for a pull implies you agree with that fact. Then the historical note. This change was made on Jun 1st 2012. If you wrote some code earlier and you do not agree with the new licensing default, you can submit a licensing change pull or a removal pull. So the repository has a default and an escape hatch. The default is GPLv2 inherited from Munin, and the escape hatch is a per-file override, which is why the phrase unless specified otherwise inside a file is doing real work rather than being boilerplate. A plugin that carries its own OSI-compatible licence is fine, and a plugin written before the default was set can be relicensed or removed by its author. The overall licence is listed as unknown, which is consistent with the per-file arrangement rather than a contradiction. For a company reviewing a plugin before shipping it, the practical step is to open the file and read the header, because the repository-wide default is not the whole answer. The project itself is written in Perl, with a Makefile, a .rubocop.yml, a .flake8, a .travis.yml and a t/ directory, which is the Perl test layout, so the tooling spans both ecosystems. ## The Makefile runs one check, and it is a spell checker The build tooling in this repository is worth a close look, because it is unusually thin and it tells you something about the priorities. The Makefile has a single target, lint, and it is not a Perl syntax check. It runs codespell over the plugin files. ```bash find plugins/ -type f -not -name "*.png" -not -name "*.conf" -not -name "*.jar" -not -name "*.pyc" -print0 \ | xargs -0 codespell \ --exclude-file .codespell.exclude ``` The exclusions are worth noting. The find step skips PNG images, configuration files, jar archives and pyc files, which is sensible since those are not text worth spell checking, and it uses print0 with xargs -0 so that filenames containing spaces do not break the pipeline. There is a comment above the command explaining a deliberate omission: add --ignore-words .codespell.ignore-words as soon as travis supports a newer testing environment, containing codespell 0.11 or later. The repository therefore carries .codespell.exclude, .codespell.ignore-words, a .flake8, a .rubocop.yml and a .travis.yml, and the ignore-words list sits unused until the CI environment can support the codespell version that reads it. The bigger point is that this is a linting-only build. There is no compile step, no test target in the Makefile, and no release process. The build status badge in the README points at a Travis CI configuration on the master branch. For a collection of contributed plugins, that is a reasonable level of automation, but it also means there is no automated guarantee that any given plugin in the tree still runs against a current Munin. ## What the repository does not document There is a noticeable amount the README leaves unsaid, and for anyone evaluating whether to depend on this collection the gaps matter. The README does not say how to install a plugin once you have found one. It does not describe the plugin API, the configuration format, or where a Munin server looks for plugins. It does not list the plugins, and it does not give any quality signal beyond the gallery link and the existence of a spell check in CI. It does not describe a support policy, a maintenance arrangement or a review standard beyond the elementary commit convention and the licensing default. The samples directory is the closest thing to documentation. There is a samples/munin.conf/ directory, which is an example configuration set rather than an example plugin, and the directory is described as serving the learn by example way of doing things. None of that is a criticism of the design. This is a community shelf, and a shelf that tried to be a package would fail. The important thing for a reader is to know what kind of artefact each thing in the tree is, so that expectations are right. A plugin here is community code with a per-file licence, contributed under a commit convention, checked by a spell checker, with no promise of compatibility with any particular Munin release. The last push was on 2026-09-24, and the repository has no GitHub releases, which is consistent with a collection that is revised in place rather than cut into versions. ## Conclusion munin contrib is worth checking first when you need a Munin plugin for a service nobody has written one for, because the plugins directory is where most of that work already lives, and the gallery gives you a browsable index rather than a directory listing. It is the wrong tool if you need something maintained, since the repository has no releases, no version tags and a per-file licence that varies. Before you deploy any plugin from here, read the header of the specific file to see whether it carries a different licence than the GPLv2 default, and treat the code as community-contributed rather than as part of the Munin distribution. ## FAQ ### What does the munin contrib repository contain? Four directories: contrib/plugins/ for third-party plugins, contrib/templates/ for third-party templates including an official one that is a loose-synced copy of the template shipped with munin, contrib/tools/ for any kind of tool, and contrib/samples/ for examples of various configs. ### How is code in the munin contrib repository licensed? All code is licensed with the same terms as munin itself, GPLv2, unless specified otherwise inside a file, and in all cases it shall have an OSI-compatible licence. The overall licence is listed as unknown because the per-file arrangement allows exceptions. ### What commit style does the munin contrib project expect? Elementary commits, with a one-liner commit comment as the first line and ideally a prefix showing which part the commit is about, so grouped changes are visible without consulting the diff stat. Later lines are optional and should explain the why. Pull requests may regroup many commits at once. ### What checks does the munin contrib Makefile run? A single lint target that runs codespell over the plugin files, excluding PNG images, conf files, jar archives and pyc files, with an exclude file for known false positives. ### Where can I browse the available munin plugins? The README points to a gallery at gallery.munin-monitoring.org for a browsable overview of the contributed plugins, and to a hints document at plugins#contributed-munin-plugins for the contribution conventions. ## Sources - [Issues](https://github.com/munin-monitoring/contrib/issues) - [munin-monitoring/contrib on GitHub](https://github.com/munin-monitoring/contrib) - [Project website](http://munin-monitoring.org) - [README](https://github.com/munin-monitoring/contrib/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/munin-monitoring-contrib