munin-monitoring / munin Goto Github PK
View Code? Open in Web Editor NEWMain repository for munin master / node / plugins
Home Page: http://munin-monitoring.org
License: Other
Main repository for munin master / node / plugins
Home Page: http://munin-monitoring.org
License: Other
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.
--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)
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
Make munin-async and munin-asyncd configurable,
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:
This will track the code changes discussed in #319
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.
unmonitor
itself somehow? I plan to do it on Windows shutdown.monitor
itself? It would be on Windows boot.Update the documentation for how to start hacking on Munin
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
This is the output of Update log.
I have:
What calculation's result is Max:0.97
?
How to set it up to 1 be 1 and 2 be 2?
Read defaults from Munin::Common::Defaults
Follow up later with #369
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?
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.
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
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.
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
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
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
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!
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?
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.
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
The "dev_script/deps" script which installs the perl modules as debian packages is out of date. It needs to be updated.
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
[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:
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?
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.
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:
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>
That involves 2 parts :
dev_script/
scripts to be able to run seamlessly on OSXI 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
Plugins need a bit of cleanup.
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:
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!
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
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
Need at least:
--debug-rrd
--debug-protocol
https://github.com/munin-monitoring/munin/blob/devel/plugins/node.d/zimbra_.in need update to read e.g. cpu.csv.gz
Write new install documentation, both for the INSTALL file in the project root, and the install section in the Munin Guide.
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.
Move from "other stuff" to a proper place.
Link from "plugin reference", "plugin authoring", "node plugin protocol" and "master node protocol" pages
os.env
instead of separate config fileI think munin cannot handle "lower then X" warnings. It can.
Maybe I will be the one doing it.
/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
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.
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.
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.
Right now it is very simple, only one group and same number of plugins & services.
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!
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
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?
# 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 -
.
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.
I realized that some <a href="">
were inconsistent when using munin-httpd:
//dynazoom.html?...
while it should be /dynazoom.html?...
//
while it should begin with /
/
Same as (1), except for the graph link since there is none
Same as (1), except for the graph links which works fine
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.