Contributed Munin Plugins
This plethora of plugins covering various topics was contributed by many different users of munin.
See the gallery for a browsable overview of these plugins.
Purpose of this repository
This repository of contributed plugin strives to achieve the following goals:
- allow users to find interesting plugins
- allow contributors to publish their plugins
- simplify cooperative maintenance of plugins
Contributed plugins are maintained primarily by their authors.
You may file bug reports for plugin issue here in this repository (munin-contrib), but please do not forget to notify the author of the plugin (see the plugin's documentation), too.
Please note, that this repository is not supposed to be a dumping site for random plugins of low quality. The related infrastructure (e.g the gallery or automated tests) require a certain level of quality. Please see below for details.
Submit a new plugin
- check if a similar plugin exists and if it can be extended/changed instead of adding a new plugin
- please avoid code copies - they are a maintenance burden
- add documentation including configuration, author, license and magic markers
- pick a suitable category
- use style check tools for the language of the plugin (e.g. perl:
perlcritic, shell:shellcheck, python:flake8, ruby:rubocop) - pick a suitable name and location
- bonus:
- use the multigraph approach for non-trivial plugins
- add example graphs for the gallery
- support dirtyconfig if it is suitable
- open a pull request with your new plugin or send it attached to an email to the mailing list
See the plugin development documentation for more details.
Modify an existing plugin
- try to keep the plugin backwards compatible (e.g. keep data fieldnames unchanged)
- improvements of code quality and features can justify incompatible changes of existing plugins
- bonus:
- improve the existing plugins according to the wishlist for new plugins
- upgrades from simple plugins to a multigraph plugin are welcome
Plugin name and location
The following descriptions are intentions - they do not necessarily describe the current state for all plugins. Please open a pull request if you want to align the current structure along the goals outlined below:
- the top level directory should describe a related software or vendor
- use concepts or platforms only if it is really necessary (e.g. cpu, bsd, memory)
- subdirectories are usually not required