Is it OK to force the user to manually copy some configuration?

The user running this plugin needs read and write access to the
fail2ban communications socket. You will need to add this:
    [fail2ban]
    user root

https://github.com/munin-monitoring/munin/blob/devel/plugins/node.d/fail2ban.in#L20-L24

Could it be in /etc/munin/plugin-conf.d/fail2ban by default?

After renaming tor-bandwidth-usage to tor_bandwidth_usage everything works as expected. There seems to be a bug in munin-graph in the folowing lines

my ($dom, $host, $serv, $scale) =
  $path =~ m#^/(.*)/([^/]+)/(\w+)-([\w=,]+)\.png#; ## avoid bug in vim

or the plugin has an invalid name. I'm not sure.

• Usage of os.env instead of separate config file
• Removal of default sensors
• Addition of fans/rpm alternative
• Configuration example
• fan tresholds (warning and critical) are inverse-checked: not greater than, but less than

I think munin cannot handle "lower then X" warnings. It can.

Maybe I will be the one doing it.

Current (non-conform) config example

/etc/munin/ipmi
Note: not in plugin-conf.d

rpm = CPU FAN, SYSTEM FAN
volts = System 12V, System 5V, System 3.3V, CPU0 Vcore, System 1.25V, System 1.8V, System 1.2V
degrees_c = CPU0 Dmn 0 Temp

I noticed googlebot crawling URLs that seemed to be getting longer and longer, and they always seemed to involve diskstats. I have disabled munin-cgi-html now because of this, but here is an example URL that was valid:

http://kenyonralph.com/munin-cgi/munin-cgi-html/kenyonralph.com/darwin.kenyonralph.com/kenyonralph.com/diskstats_latency/devildog.kenyonralph.com/diskstats_throughput/buddyinfo/diskstats_latency/turing.kenyonralph.com/diskstats_iops/apache_accesses.html

The relevant Apache configuration lines:

Redirect /munin/ /munin-cgi/munin-cgi-html/
Alias /munin-cgi/munin-cgi-html/static /var/cache/munin/www/static
ScriptAlias /munin-cgi/munin-cgi-html /usr/lib/munin/cgi/munin-cgi-html
<Location /munin-cgi/munin-cgi-html>
        <IfModule mod_fcgid.c>
            SetHandler fcgid-script
        </IfModule>
        <IfModule !mod_fcgid.c>
            SetHandler cgi-script
        </IfModule>
</Location>
<Location /munin-cgi/munin-cgi-html/static>
        Options -ExecCGI
      SetHandler None
</Location>

I like to have multiple munin-nodes scattered over several nets and want to configure each node with another update frequency.

There are nodes, that are not quite important or have a connection which are cost-sensitive.
These nodes could have a lower frequency (like once an hour or day) than high priority servers.

update_rate is not sufficient here because it affects all nodes and graphs.

-- Asked from IRC

I realized that some <a href=""> were inconsistent when using munin-httpd:

(1) Plugin page (/group/node/plugin.html)

• href on each graph image is //dynazoom.html?... while it should be /dynazoom.html?...
• href on each header menu item begins with // while it should begin with /
• href on logo link is empty while it should be /

(2) Dynazoom

Same as (1), except for the graph link since there is none

(3) Node page (/group/node/)

Same as (1), except for the graph links which works fine

I have a change to munin_stats to fix it (for me), dynamically deal with lacking munin-graph (cgi) and also use a perl module, File::ReadBackwards, which may not be installed everywhere (e.g. CentOS package perl-File-ReadBackwards).

What, if anything, should I be aware of regarding this situation? The changes got munin_stats working for me again and is reproducible (using munin-run does not 'spoil' later execution) which is another huge bonus, imo.

Munin update could fail!!! You may watch it and set warning and critical levels.
Is there anyone here able to rewrite it in perl?

#!/bin/bash
# -*- sh -*-
: <<=cut

=head1 NAME

munin_events - Plugin to monitor munin updates

=head1 APPLICABLE SYSTEMS

All systems with "bash", "logtail" and "munin"

=head1 CONFIGURATION

The following is the default configuration

  [munin_events]
  user munin
  env.muninupdate /var/log/munin/munin-update.log
  env.logtail2 /usr/sbin/logtail2

You could trigger alert on updatefailure

  [munin_events]
  env.munin_fatal_critical 1
  env.munin_error_critical 1
  env.munin_warning_warning 1
  env.munin_warning_critical 10

=head1 INTERPRETATION

This plugin shows a graph with one line per active fail2ban jail, each
showing the number of blacklisted addresses for that jail.

In addition, a line with the total number of blacklisted addresses is
displayed.

=head1 MAGIC MARKERS

  #%# family=auto
  #%# capabilities=autoconf

=head1 VERSION

  1.0.20141113

=head1 AUTHOR

Viktor Szépe <[email protected]>

=head1 LICENSE

GPLv2

=cut


##############################
# Configurable variables
muninupdate=${muninupdate:-/var/log/munin/munin-update.log}
logtail_bin=${logtail_bin:-/usr/sbin/logtail2}

##############################
# Functions

# Print the munin values
do_values() {
    local FIELD="$1"
    local EVENT_LABEL="$2"
    local EVENT_COUNT

    EVENT_COUNT="$("$logtail_bin" -t "$muninupdate"|grep -c "^[0-9/: ]\{19\} \[${EVENT_LABEL}\]" 2>&1)"
    if ! [ -z "${EVENT_COUNT//[0-9]/}" ]; then
        echo "Cannot determine event count" >&2
        exit 10
    fi

    echo "${FIELD}.value ${EVENT_COUNT}"
}

values() {
    do_values 'munin_info' 'INFO'
    do_values 'munin_warning' 'WARNING'
    do_values 'munin_error' 'ERROR'
    do_values 'munin_fatal' 'FATAL'
    # set offset
    "$logtail_bin" "$muninupdate" &> /dev/null
    chmod 640 "${muninupdate}.offset"
}

# Print the munin config
config() {
    echo 'graph_title Update events groupped by log levels'
    echo 'graph_info This graph shows INFO, WARNING, ERROR and FATAL events'
    echo 'graph_category munin'
    echo 'graph_vlabel Number of events'

    echo 'graph_args --base 1000 -l 0'
    echo 'graph_total total'

    echo 'munin_info.label INFO'
    echo 'munin_warning.label WARNING'
    echo 'munin_error.label ERROR'
    echo 'munin_fatal.label FATAL'
}

# Print autoconfiguration hint
autoconf() {
    if [ -r "${muninupdate}" ] && [ -x "$logtail_bin" ]; then
        echo "yes"
    else
        echo "missing (${muninupdate} or (${logtail_bin})"
    fi
    exit
}

##############################
# Main

case $1 in
    config)
        config
        ;;
    autoconf)
        autoconf
        ;;
    *)
        values
        ;;
esac

Cloned from fail2ban.

When trying to find the cause and attributes of (e.g.) an attack a guideline would be helpful:

#content {
    position: relative;
}
#content:after {
    border-right: 1px solid black;
    bottom: 0;
    content: "";
    left: 364px;
    position: absolute;
    top: 0;
}

And left would be set by Javascript to a point of time as in dynazoom: 2014-11-08T13:25:48+0100

With the latest updates to bind9_rndc plugin (multigraph), it seems to duplicate what bind9 plugin does (and better). I'm not sure what the proper procedure for removing a plugin is, but it seems bind9 is now obsolete.

should "cap foo" be available to the plugins as MUNIN_CAP_FOO?

Something like:

sprintf("MUNIN_CAP_%s", uc($cap)) if $cap =~ m{^[a-z]+$};

This might need some discussion

Move from "other stuff" to a proper place.

Link from "plugin reference", "plugin authoring", "node plugin protocol" and "master node protocol" pages

Could you clarify why the topmost item in legend belongs to graph at the bottom?

Would it be easier to read if the topmost legend item would belong to the graph at the top?

I'm running munin-node 2.0.25 on Fedora 21. I've configured contacts in munin master to email me.
Until recently, I got a lot of emails from the df and df_inode plugins, always with OKs lines, no ERRORs. The mount points in these mails never changed, only their order. This was mostly occuring when someone logged in or out (via ssh, the machine is headless).
I figured the plugins call df, which reads /etc/mtab, which is not guaranteed to be in any specific order. And it treats a changed order like mountpoints were changed, and re-issues a notification.
Thus I (think I) could fix this by including | sort into the shell call issued by the plugin. Maybe another solution would be to store the mountpoints in a set - but I don't know enough perl, to see if that's a good approach.

https://github.com/munin-monitoring/munin/blob/devel/plugins/node.d/zimbra_.in need update to read e.g. cpu.csv.gz

I've installed the backported hwmon plugin into /usr/local/share/munin/plugins/
After symlinking hwmon and telneting to the node fetch hwmon works but list does not contain hwmon.

Should I use /usr/share/munin/plugins/ for now?

Is it possible to monitor my Windows PC? It is offline (switched off) at night. I wouldn't like to get notifications when it is goes offline by Windows shutdown.

1. Could the client unmonitor itself somehow? I plan to do it on Windows shutdown.
2. Could the client monitor itself? It would be on Windows boot.

I think smartctl displays attributes in sensible order.

Would it be much better unsorted?
https://github.com/munin-monitoring/munin/blob/devel/plugins/node.d/smart_.in#L208
https://github.com/munin-monitoring/munin/blob/devel/plugins/node.d/smart_.in#L231

Find a way to do a "node and plugins" installation.

When the build system was refactored, the feature list was reduced considerably.
One feature which is needed is the ability to configure, test, build and install just a munin node with plugins.

It would be very nice to be able to install a node & its plugins on a server from source without requiring the dependencies needed for the master.

I propose to have ${var:okfields} also to be able to silence "OK" alerts.
I mount and umount the backup disk and it generates an alert.

Right now it is very simple, only one group and same number of plugins & services.

• randomize the number of plugins
• use a word list to name the elements
• use some clever values output instead of a simple sin()

Basically, it's the same thing I wrote for "df" one year ago (issue #1461): It adds the environment variable "env.dfopts" that allows overriding the default commandline arguments "-P -l".

I'm using it to monitor GlusterFS network storage.

The patch can be found here:
http://download.das-werkstatt.com/pb/contribs/patches/munin-v2.0.6-df_abs-env_dfopts.patch

It was initially written for v2.0.6 (=packaged with Debian Wheezy), but I'm pretty sure it should work with current git-HEAD, too. Changes are trivial.

Kind regards,
^Rooker

An issue has been introduced in the latest version of munin (available for preview at here).
As you can see (by displaying page source or inspecting the element in Chrome/Firefox), the alt attribute has en empty value on each graph :

<img class="i" src="/munin/../munin-cgi-graph/munin-monitoring.org/demo.munin-monitoring.org/if1sec_lo-day.svg" alt="">

Previously (demo still available here), it was filled:

<img class="i" src="/munin-cgi/munin-cgi-graph/munin-monitoring.org/demo.munin-monitoring.org/if1sec_eth0-day.png" alt="Interface 1sec stats for eth0">

Faulty version is Munin version 2.1.10-debian-auto-2015-01-20-c120-g79bd1cb

As far as I understand, munin forks separate worker for each host in config file. Wouldn't it be advantageous for a worker to first get list of plugins available on a node and fork some more workers in order to request config and results? For example if it happens to be the time when server experiences heavy I/O, requesting some I/O related information first would give great delay for next requests, however you can at this time request other information, like network related, which will return faster, without delay. This will definitely speed up the process since delays do not accumulate.

[PERL WARNING] Use of uninitialized value $severities[0] in join or string at /usr/share/perl5/Munin/Master/LimitsOld.pm line 847.

Please start me up where to begin debugging.
Version: 2.0.24-1~bpo70+1
Problems:

• Critical 0
• Warning 0
• Unknown 0

This is the output of Update log.

I have:

• 1 FATAL
• 2 ERROR

What calculation's result is Max:0.97?
How to set it up to 1 be 1 and 2 be 2?

Need at least:

--debug-rrd
--debug-protocol

There is a need for configurable ssh options.

Add a default, and a configuration variable for this. Also look at overriding this per configured node.

Use cases:

• Compression, for speed
• Control Master sockets, for speed
• Connecting through a proxy, for access

This will track the code changes discussed in #319

Write new install documentation, both for the INSTALL file in the project root, and the install section in the Munin Guide.

That involves 2 parts :

• enhance the dev_script/ scripts to be able to run seamlessly on OSX
• create a brew formula for the various munin components.

Plugins need a bit of cleanup.

• Which to keep in the "munin" repo
• Which to move to "contrib"
• Which to retire

Need to agree on plugin requirements for "munin" vs "contrib".

Implementation language: Perl/Shell in main repo, and anything else in "contrib"? Do we need to rewrite any plugins in perl for them to remain in "munin"?

Where to place the java plugins? Keep in "munin"? Move to "contrib"? Make a "java-plugins" repo?

Other points to consider per plugin:

• Plugin family
• Test requirements
• What is the plugin for? The operating system? A common application? An uncommon application? Free software or not?

I have a munin-update.log analyzer plugin:
#307

After adding these to munin node config:

[munin_events]
user munin
env.munin_fatal_critical 1
env.munin_error_critical 1
env.munin_warning_warning 1
env.munin_warning_critical 10

"Graph information" shows no warning nor critical values.
Version 2.0.25-1~bpo70+1.

--verbose should make munin emit messages from "info" and up.

The default minimum log level today is "warning".

There's no way to see "notice" and "info" without also getting "debug" (by using the --debug flag)

munin-node should watch for changes in the plugin directory, /etc/munin/plugins and the plugin config directory /etc/munin/plugin-conf.d

On changes, it should reload its configuration.

In the example provided by Steve S. months ago, we can see that sparkline graphs doesn't display anything much than the graph.
When trying to display those sparklines now (?&only_graph=1&size_x=128&size_y=32), I saw that they seems broken (since acting like a real graph):

only_graph parameter seems broken, isn't it?

The "dev_script/deps" script which installs the perl modules as debian packages is out of date. It needs to be updated.

I'm trying to use the SVG version of the munin logo in the web interface (much prettier on high-res displays: retina screens & smartphones)

While apache serves a .svg file as image/svg+xml file, munin-httpd serves it as text/html, making it impossible to render in a web browser.

One should map the file type with the correct MIME type:

AddType image/svg+xml svg
AddType image/svg+xml svgz

Hi,

for a long time I've been running Munin with a NSCA contact setup as per the docs.
However, every time the cron job runs, I get an email with a number of rows like this:

1 data packet(s) sent to host successfully.
...
1 data packet(s) sent to host successfully.

During the years I've manually patched LimitsOld.pm after every upgrade:

--- master/lib/Munin/Master/LimitsOld.pm        2014-04-06 23:24:41.524752501 +0200
+++ master/lib/Munin/Master/LimitsOld.pm        2014-04-06 23:28:05.634751300 +0200
@@ -731,6 +731,7 @@
             } else { # child
                 close $w;
                 open(STDIN, "<&", $r);
+                close(STDOUT);
                 exec($cmd) or WARN "[WARNING] Failed to exec for contact $c in pid $$";
                 exit;
             }

But since it haven't been fixed by anyone else, and I'm getting tired patching, I thought I'd report it here and see if anyone else is having these problems?
If not, any ideas why this occurs to only my setup?

Other info: FreeBSD (9.x-)10.1
munin 2.0.25 and earlier from FreeBSD ports
nsca 2.9.1 and earlier from ports.

I found some mentioning from 2005 about Debian packaging having the same issue, but I'm not sure if it would be debian specific (apparently not).. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291168

Thanks!

Hi,

I'm installing munin-node on RHEL4 and having this error when installing perl-Net-SNMP dependencies:
#rpm -ivh munin-node-1.2.6-4.el4.noarch.rpm
warning: munin-node-1.2.6-4.el4.noarch.rpm: V3 DSA signature: NOKEY, key ID 217521f6
error: Failed dependencies:
perl(Net::SNMP) is needed by munin-node-1.2.6-4.el4.noarch

rpm -ivh perl-Net-SNMP-5.2.0-1.2.el4.rf.noarch.rpm

warning: perl-Net-SNMP-5.2.0-1.2.el4.rf.noarch.rpm: V3 DSA signature: NOKEY, key ID 6b8d79e6
error: Failed dependencies:
perl(Digest::HMAC) is needed by perl-Net-SNMP-5.2.0-1.2.el4.rf.noarch

rpm -ivh perl-Digest-HMAC-1.01-13.noarch.rpm

warning: perl-Digest-HMAC-1.01-13.noarch.rpm: V3 DSA signature: NOKEY, key ID e01260f1
error: Failed dependencies:
perl-Digest-MD5 is needed by perl-Digest-HMAC-1.01-13.noarch

rpm -ivh perl-Digest-MD5-2.39-1.el4.rf.i386.rpm

warning: perl-Digest-MD5-2.39-1.el4.rf.i386.rpm: V3 DSA signature: NOKEY, key ID 6b8d79e6
Preparing... ########################################### [100%]
file /usr/share/man/man3/Digest::MD5.3pm.gz from install of perl-Digest-MD5-2.39-1.el4.rf conflicts with file from package perl-5.8.5-12.1

I found solution using CPAN but didn't success because of internet issue.
So could you help please!

Thanks in advance!

Assuming the default munin file locations for Debian (using Apache2 2.4 and current version of Munin), the etc/apache2/sites-enabled/default-munin.conf (example name for the munin virtual host file), etc/munin/apache24.conf, and munin/munin.conf all work together. I'm assuming the Apache24.conf file is the replacement for apache.conf in the etc/munin/ directory. This file gets symlinked into etc/apache2/conf-available and is enabled using a2enconf to be then symlinked into apache2/conf-enabled.
At least for Debian (and Ubuntu?), the "correct" way for Apache2 2.4 to be configured is to install application specific config files in /etc/apache2/conf-available, and then enable them as a symlink in /etc/apache2/conf-enabled in a similar fashion as sites-available/sites-enabled for virtual hosts. I assume this can be done via symlinks to the config file /etc/munin, or directly. I suppose having it installed this way would be an "enhancement" git request. It would also be a great thing to have "default" configuration files for each of these available on github to copy.

Hello guys! On my system, I have several plugins in unknown state, but they are not displayed on the Problems page. Probably it will be a good idea to update munin_service_status sub with "unknown" state:
https://github.com/munin-monitoring/munin/blob/devel/master/lib/Munin/Master/Utils.pm#L1394
Thanks!

Imported from https://bugs.debian.org/781790

Source: munin
Version: 2.0.25-1~bpo70+1
Severity: normal

Hi,

So I finally got annoyed enough by this to dig into the source enough
to make a reasonable bug report about it :) I've been writing a
multigraph plugin for a new package, and I'd seen that sometimes it
would make the field label far wider than the text was, crowding the
Cur/Min/Avg/Max values hard to the right, in the worst cases even
wrapping them to a new line, but just generally rendering them horribly.

I've now figured out where it's getting the wrong field width from at
least, and there's probably a couple of easy fixes for that, but there
might be something subtle I'm missing, so we should probably run this
past upstream rather than me just attaching a naive patch for it ...

The (simplified) problem case looks something like this:

multigraph foo
foo_field.label Foo

multigraph foo.bar
bar_long_descriptive_field_name.label Bar

With the result being that when the top level 'foo' graph is generated,
the width of the "Foo" label, rather than being 3, will instead be
strlen("bar_long_descriptive_field_name") ...

The reason for this is that in the GraphOld.pm process_service() function
we have:

$max_field_len = munin_get_max_label_length($service, \@field_order);

and @field_order for the foo graph also contains all the fields for the
foo.bar subgraph (and any others it may also have).

The munin_get_max_label_length() function (in Utils.pm), in turn does
this:

my $len = length (munin_get ($service->{$f}, "label") || $f);

and so when it processes the bar_long_descriptive_field_name field,
the $service hash doesn't contain that member, $len instead becomes
the length of the field name. Hilarity ensues.

As far as I can gather so far, the reason for the '|| $f' clause there
is to support use of munin_get_max_label_length in munin_field_status()
(also in Utils.pm) - so basically we have two (unintended?) side effects
that collide to make this behave badly.

In process_service, the subgraph fields are skipped from further
processing for the top level graph later in the loop, but the damage to
$len is already done.

This could be fixed by either removing those fields before passing the
array to munin_get_max_label_length, or by ignoring fields where
$service->{$f} is undefined in that function when computing the length.
(but I think the latter might break the munin_field_status() use).
Or this might also be an indication of some other bug in the multigraph
handling that they even in that array in the first place ...

That should hopefully be enough for someone familiar with how this was
originally intended to work to see the right place to really fix this.
AFAICS, the current upstream git HEAD doesn't look significantly
different to the code in 2.0.25-1~bpo70+1 -- so hopefully any fix will
also be backportable to that brance too :)

Cheers,
Ron

Make munin-async and munin-asyncd configurable,

• Add a /etc/munin/async.conf
• Add a perl module (Munin::Async::Config?) to read from Munin::Common::Defaults, parse configuration file, and make values available

Update the documentation for how to start hacking on Munin

Read defaults from Munin::Common::Defaults

Follow up later with #369

I am running munin 2.0.19.

I'm getting "returned no data for label" errors in /var/log/munin/munin-update.log. What does this mean?

I have run my plugin with munin-run cpu_byproc and munin-run cpu_byproc config and I don't see anything obviously wrong.

munin-run cpu_byproc
cpu0_user.value 263411550
cpu0_nice.value 32953
cpu0_system.value 22897578
cpu0_idle.value 4361318137
cpu0_iowait.value 110004158
cpu0_irq.value 5903
cpu0_softirq.value 3855195
...
munin-run cpu_byproc config
update_rate 60
graph_title CPU time time by proc
graph_args --upper-limit 100 -l 0
graph_vlabel %
graph_scale no
graph_category system
cpu0_user.label cpu0_user
cpu0_user.type DERIVE
cpu0_user.min 0
cpu0_user.graph no
cpu0_nice.label cpu0_nice
cpu0_nice.type DERIVE
cpu0_nice.min 0
cpu0_nice.graph no
cpu0_system.label cpu0_system
cpu0_system.type DERIVE
cpu0_system.min 0
cpu0_system.graph no
cpu0_idle.label cpu0_idle
cpu0_idle.type DERIVE
cpu0_idle.min 0
cpu0_idle.graph no
cpu0_iowait.label cpu0_iowait
cpu0_iowait.type DERIVE
cpu0_iowait.min 0
cpu0_iowait.graph no
cpu0_irq.label cpu0_irq
cpu0_irq.type DERIVE
cpu0_irq.min 0
cpu0_irq.graph no
cpu0_softirq.label cpu0_softirq
cpu0_softirq.type DERIVE
cpu0_softirq.min 0
cpu0_softirq.graph no
...
cpu0.label cpu0
cpu0.sum cpu0_user cpu0_system

I can telnet to the agent port 4949 and do a fetch cpu_byproc, and I see the variables coming across with no errors.

I don't know what cpu0.sum means. I assume that it is adding together the CPU time spent in user mode and CPU time spent in system mode.

The graphs seem to work, so I am wondering if the warning message is spurious?

I found the warning message in the source code at "UpdateWorker.pm" line 614. Unfortunately, I don't understand the source code well enough to understand what it means - I don't have the context and I am reluctant to reverse engineer something as complicated as munin.

Thank you

Jeff Silverman

# df -P -l -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/qupdate-root       0       0       0    -  /
tmpfs                 257453       8  257445    1% /lib/init/rw
udev                  256074     807  255267    1% /dev
tmpfs                 257453       1  257452    1% /dev/shm
/dev/md126             50200     241   49959    1% /boot
/dev/mapper/qupdate-home       0       0       0    -  /home
/dev/mapper/qupdate-storage       0       0       0    -  /storage
/dev/sdc1            30531584  427151 30104433    2% /var/backups/mailbck

And munin cannot evaluate -.