However, Munin has more plug-ins available that may be useful to your environment. The plugins that turned on by default on fresh Munin installation are mostly general and available on all systems. However, if you have specific requirements, or your systems can provide more types of useful information, it’s recommended to collect these data too. Munin provides a command that allows you to view and modify which plugins are enabled, together with the suggestion.
The munin-node-configure command reports which plugins are enabled on the current node, and suggest changes to this list by checking whether the plugins will probably work or not on the system based on the plugins’ autoconf command. It also provides shell scripts with commands to automatically install and activate the plugins that you wanted to enable. Here’s how you use the munin-node-configure to perform several common tasks.
Show Which Plugins Are Installed and Active
To check which plug-ins are installed on a Munin node, login to the Munin node, and run the following command:
$ sudo /usr/sbin/munin-node-configure
The output lists all available plugins, with active plugins indicated as “yes” under “Used” column, while “no” indicates that the plugins are readily available and installed, but disabled.
Plugin | Used | Extra information ------ | ---- | ----------------- acpi | no | amavis | no | apache_accesses | no | apache_processes | no | apache_volume | no | apc_envunit_ | no | apc_nis | no | apt | no | apt_all | no | asterisk_channels | no | asterisk_channelstypes | no | asterisk_codecs | no | asterisk_meetme | no | asterisk_meetmeusers | no | asterisk_sipchannels | no | asterisk_sippeers | no | asterisk_voicemail | no | bind9 | no | bind9_rndc | no | bonding_err_ | no | buddyinfo | no | cmc_tc_sensor_ | no | courier_ | no | courier_mta_mailqueue | no | courier_mta_mailstats | no | courier_mta_mailvolume | no | cps_ | no | cpu | yes | cpuspeed | no | cupsys_pages | no | df | yes | df_abs | no | df_inode | yes | ..... truncated .....
Determine and Suggest Plugins that May Work and Should be Enabled
Run the following command on a Munin node to get a table of plugins that will probably work, which were tested according to the plugins’ autoconf command:
$ sudo /usr/sbin/munin-node-configure --suggest
Plugin | Used | Suggestions ------ | ---- | ----------- acpi | no | no [cannot read  amavis | no | no apache_accesses | no | no [Port 80: Can't connect to 127.0.0.1:80 (Connection refused)] apache_processes | no | no [Port 80: Can't connect to 127.0.0.1:80 (Connection refused)] apache_volume | no | no [Port 80: Can't connect to 127.0.0.1:80 (Connection refused)] apc_envunit_ | no | no [no units to monitor] bonding_err_ | no | no [No /proc/net/bonding] courier_mta_mailqueue | no | no [spooldir not found] courier_mta_mailstats | no | no [could not find executable] courier_mta_mailvolume | no | no [could not find executable] cps_ | no | no cpu | yes | yes cpuspeed | no | no [missing /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state] cupsys_pages | no | no [could not find logdir] df | yes | yes df_inode | yes | yes diskstats | no | no entropy | yes | yes exim_mailqueue | no | no [no exiqgrep] exim_mailstats | no | no ['/usr/sbin/exim -bP log_file_path' returned an error] fail2ban | no | no [/usr/bin/fail2ban-client not found] forks | yes | yes fw_conntrack | yes | yes fw_forwarded_local | yes | yes fw_packets | yes | yes hddtemp_smartctl | no | no [no drives known] http_loadtime | no | no if_ | yes | yes (venet0) if_err_ | yes | yes (venet0) interrupts | yes | yes ip_ | no | no [could not run iptables as user nobody] ipmi_ | no | no [missing ipmitool command] irqstats | no | no load | yes | yes ..... truncated .....
The output is a table of plugins with additional “Suggestions” column, and also some additional output at the end that lists the plugins caused errors especially the junk which was not understood by Munin but does not affect Munin’s operation.
A “yes” suggestion indicates that the plugin is supported by the system and can be activated without further changes. For “no” suggestion, Munin may also display the reason why a particular plugins cannot or shouldn’t be activated, as Munin faced error when attempting to collect the data from the system component provided by the plugin. Correct the problem if you want Munin to monitor the system component and before enabling the plug-in.
Enable and Activate Munin Plug-Ins
To enable a plugin, what needed to be done is essentially making a symlink (symbolic link) from the physical plugin file located in /usr/share/munin/plugins to the active plugins directory located in /etc/munin/plugins which Munin looks for and loads activated plugins. However, munin-node-configure can also outputs a list of shell commands required to activate and enable all supported plugins that are not yet active. To get the shell commands, run the following command:
$ sudo /usr/sbin/munin-node-configure --shell
ln -s '/usr/share/munin/plugins/apache_accesses' '/etc/munin/plugins/apache_accesses' ln -s '/usr/share/munin/plugins/apache_processes' '/etc/munin/plugins/apache_processes' ln -s '/usr/share/munin/plugins/apache_volume' '/etc/munin/plugins/apache_volume' ln -s '/usr/share/munin/plugins/munin_stats' '/etc/munin/plugins/munin_stats' ..... truncated .....
“munin-node-configure –shell” lists out all shell commands to enable plugins that can be enabled as provided by “munin-node-configure –suggest” command. You can copy and paste the command to execute it, or pipe them to the shell for automatic execution:
$ sudo /usr/sbin/munin-node-configure --shell | sudo sh
Once plugins are enabled, you can re-run the munin-node-configure command to verify that they’re listed as “yes” in “Used” column. Wait for a few minutes for Munin master to run and query the node, and then you shall see the graphs for newly enabled plugins in Munin reports.