Stig Sandbeck Mathisen—Munin 3 packaging
The Munin project is moving slowly closer to a Munin 3 release. In parallel, the Debian packaging is changing, too.
The new web interface is looking much better than the traditional web-1.0 interface normally associated with munin.
New package layout
perl libraries
All the Munin perl libraries are placed in “libmunin-*-perl”, and split into separate packages, where the split is decided mostly on dependencies.
If you don’t want to monitor samba, or SNMP, or MySQL, there should be no need to have those libraries installed. That does mean more binary packages, on the other hand.
Munin master
Munin now runs as a standalone HTTPD, it no longer graphs from cron, nor does it run as CGI or FastCGI scripts.
The user “munin” grants read-write access, while the group “munin” grants read only access. The new web interface runs as the “munin-httpd” user, which is member of the “munin” group.
There is a “munin” service. For now, it runs rrdcached for the munin user and RRD directory.
munin node
The perl “munin-node” and the compiled “munin-node-c” should be interchangeable, and be able to run the same plugins.
Munin node, and Munin async node, should be wholly separate from the munin master. It should be possible to use the perl “munin-node” package, and the
munin plugins
The munin plugins are placed separate packages named “munin-plugins-*”. The split is based on monitoring subject, or dependencies. They depend on appropriate “libmunin-plugin-*-perl” packages
The “munin-plugins-c” package, which is is from the “munin-node-c” source, contains a number of compiled plugins which should use less resources than their shell, perl or python equivalents.
Plugins from other sources than “munin” must work similar to the ones from “munin”. More work on this is needed.
Testing
Late December 2015, I set up Jenkins, with jenkins-debian-glue to build packages, test with autopkgtest and and update my development apt repository on each commit. That helped developing and testing the new Munin packages.
The packages are not quite ready to upload to experimental, but they are continuously deployed to weed out bugs. They can be found in my packaging apt repo. (The usual non-guarantees apply, handle with care, keep away from small children, etc…)
Comments
Munin developers, packagers and users hang out on “#munin” on the OFTC network. Please drop by if you have questions or comments.
Stig Sandbeck Mathisen—Free software activities in September 2015
What did I do in September 2015?
Munin
Working on making the munin master fit inside Mojolicious.
The existing code is not written to make this trivial, but all the pieces are there. Most of the pieces need breaking up into smaller pieces to fit.
Debian
Packaging
New version of puppet-module-puppetlabs-apache which closes:
- #788124 By default, produces a configuration incompatible with Apache 2.4
- #788125 Missing directory referenced in SSL configuration
- #788127 SSLv3 is not disabled
I like it when a new upstream version closes all bugs left in the bts for a package.
A new package, the TLS proxy hitch currently waiting in the queue.
(Update 2016-01-02: It’s not in NEW anymore)
Puppet
Lots of work on a new ceph puppet module.
Stig Sandbeck Mathisen—Munin helps showing performance changes
Using btrfs on a networked backup server looked like a good idea, what with the data integrity checksumming and all. Problem was, we experienced massive performance issues.
Reformatting it to ext4 gave a decent increase in write performance, and will hopefully give fewer server crashes per week (from “many” to “none” is the goal) Just before this wipe-and-reinstall, “umount” had been hanging for a few hours, and the admin got a tad annoyed.
This is on Ubuntu 12.04.4 LTS (GNU/Linux 3.12.8-031208-generic x86_64). The “disk” in question is a single 28T device on a nearby disk shelf.
Now, why this performance difference? We have Munin installed, and showing graphs from before and after the change gives us a few clues.
Network througput
Network throughput increased to the limit. Looks like it is time to move to active/active bonding, instead of active/passive.
Storage graphs
The number of operations went down, while the request size increased massively. This allowed much more data to be written to the device.
Steve Schnepp—Tutorial - Setup a dev environment for Munin
I discovered some time ago the marvelous dev_scripts/ directory
in the munin source code. So, as its usage is very easy, I'll just
write a tutorial about how to use it
Prerequisites
To use it, one has to install all the packages needed for munin, and to grab a copy of the source code. Easiest is to use either a tarball, or to clone the git repository.
Note that the guidelines on contributing back are specified directly in the git repo.
Now, I just assume you want to contribute back, otherwise you would not care much about the said dev environment. That means using the git way of doing it.
Download the source code
First step is to clone the git repository. We will use
$HOME/src/munin as the development directory.
mkdir -p $HOME/src cd $HOME/src git clone https://github.com/munin-monitoring/munin munin cd munin
Compile munin
Now, we have to compile the source code. I know that it sounds strange as the code is mostly Perl, but there are some templates that need to be filled with the environment specifics, such as the Perl interpreter path, a POSIX compatible shell, ...
dev_scripts/install 1
Now all munin (and munin-node) should be compiled and installed in
$HOME/src/munin/sandbox.
Note that the 1 at the end is explained below.
Using the dev tools
There are some different tools in dev_scripts/ :
install
This is the one you used already. You have to use it every time you want to recompile & deploy the package.
The 1 argument, does a full re-install (wipe & install), so
you don't usually want to do that.
restart_munin-node
This is a tool to start the development node. Note that it listens on the port 4948, so you can use it alongside a normal munin-node.
run
The run command inside is used to launch all the executable
parts of munin, such as munin-update, munin-html or
munin-limits. It can also be used to launch munin-run
and munin-node-configure.
The usage is very simple, just prefix the command to launch with
dev_scripts/run, every environment variable and command line
argument will be forwarded to the said command.
# launch munin-cron dev_scripts/munin-cron # launch manually some cron parts dev_scripts/munin-update dev_scripts/munin-limits dev_scripts/munin-html dev_scripts/munin-graph # debug a plugin dev_scripts/munin-run --debug cpu config
cgi
This is the same as run, only for CGI. It sets up the whole
environment vars that emulates a CGI call. Usage is very easy :
dev_scripts/cgi munin-cgi-graph /localnet/localhost/cpu-day.png > out.dat
The out.dat will contain the whole HTTP output, with the HTTP
headers and the PNG content. Everything that is sent to STDERR won't be
catched, so you can liberally use it while debugging.
query_munin_node
The query_munin_node is used to send commands to the node in a
very simple way. Node commands are just args of the tool.
dev_scripts/query_munin_node list dev_scripts/query_munin_node config cpu dev_scripts/query_munin_node fetch cpu
Real CGI usage with your web browser
That's the holy grail. You will have a development version that behaves the same as a real munin install.
First, let's assume you have a working user cgi configuration (ie
~user/cgi/whatever is working). If not you should refer yourself
to the local documentation of your preferred webserver. Note that nginx will
_not_ work, as it does
not support CGI.
I wrote a very simple cgi wrapper script. The home dir is hard coded in the script.
#! /bin/sh ROOT=/home/me/src/munin eval "$(perl -V:version)" PERL5LIB=$ROOT/sandbox/usr/local/share/perl/$version #export DBI_TRACE=2=/tmp/dbitrace.log exec perl -T -I $PERL5LIB $ROOT/sandbox/opt/munin/www/cgi/$CGI_NAME
