Munin configuration and testing on RHEL

This article continues the installation and setup of munin on a single slice. It explains how to determine or change the URL used to access munin's reports and then check to make sure those reports are viewable and being updated.


Almost ready!

If you've been following along with the first article in this series, Installing munin, you should now have a munin master configured on your slice and have a node running and gathering data every five minutes. All that's left now is to see if you can access the reports munin generates. To do that you'll need to make sure munin is storing its generated html files in a location you can access through your web server.

The htmldir setting

If you go back to the configuration file at /etc/munin/munin.conf, toward the beginning you will find an entry that looks like:

# The next three variables specifies where the location of the RRD
# databases, the HTML output, logs and the lock/pid files.  They all
# must be writable by the user running munin-cron.  They are all
# defaulted to the values you see here.
#
# dbdir /var/lib/munin
# htmldir /var/www/html/munin
# logdir /var/log/munin
# rundir  /var/run/munin

The line you want to look at is the "htmldir" value. This is the directory where munin stores its web pages, and the default value is a subdirectory of the web server's default document root (more on that later). If you would prefer that munin store its pages in another location (as a subdirectory of an existing site, for instance) you can uncomment that line (remove the leading "#" character) and change its value to a new directory. Just make sure that you set the new directory to be writeable by the munin user or munin won't be able to generate graphs and reports there.

If you aren't sure if the munin HTML directory can be written to by the munin user, the easiest fix is to set the ownership of the directory (which is done for you in a default install). To set the ownership of the directory to the munin user, run the following command:

chown -R munin /var/www/html/munin

If you aren't using the default munin directory, make sure to substitute the new directory for "/var/www/html/munin" in the example above.

Determining the munin URL

The URL used to access munin's reports is a combination of the address you use to access your web server and where the munin HTML directory is relative to the web server's document root. Let's take a look at how you can check these details in a default apache install so you can find and change these settings when you need to.

A closer look at the default site

When apache is installed it puts it default configuration file here:

/etc/httpd/conf/httpd.conf

The default configuration sets up a basic site that can be used to serve some static files, like those munin generates. If you want to serve more than one site from apache you can refer back to our articles on apache for information that would allow you to do that with a single apache installation using a "virtual host". For now we're interested in how the default site is set up, so we'll look in that default configuration file for more details. Open it and go looking for some key lines.

The first section we'll look at sets the address and port apache will use to listen for connections:

# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, in addition to the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to 
# prevent Apache from glomming onto all bound IP addresses (0.0.0.0)
#
#Listen 12.34.56.78:80
Listen 80

By default the "Listen 80" directive tells apache to listen to all available interfaces (the IP addresses on your slice), on port 80 (the default port for unencrypted web traffic). In other words, with the default configuration you can get to the site with any address that points to your slice, be it a domain name or an IP address.

The next section we want to look at is:

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/var/www/html"

This DocumentRoot directive tells apache where the web files are stored. That default setting means that if you visit your slice in a web browser apache will look in /var/www/html to find any pages to show you. If you have "www.example.com" pointing to your slice you can see the default index file in the web server's document root by going to this URL:

http://www.example.com

If munin's web directory is not located in the site's document root, either because you've changed apache's configuration or because you don't want the munin files to be in the document root, you have a couple options. One option is to change the munin.conf file to use a directory in a different document root (using the instructions above under the heading, "The htmldir in munin.conf"). There is another option that doesn't involve changing where munin stores its reports, however, and that is...

The Alias directive

The Alias directive in apache lets you set up an alias from a reference to a subdirectory of the document root to a location somewhere else in your slice's filesystem. For example, if your document root were "/var/www/html" but you wanted your munin HTML files to be in "/home/munin/public_html", you would set up an alias from "/munin" to "/home/munin/public_html".

The Alias directive depends on the module "mod_alias" being enabled. This mod is included and enabled in the default apache installation.

To add an alias like the example above you would want to add the alias to your site configuration in /etc/httpd/conf/httpd.conf, and would need to include a Directory entry for the directory the alias points to. The new section can be inserted at the end of the file. Your configuration might look like:

Alias /munin /home/munin/public_html
<Directory /home/munin/public_html>
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Once the Alias and Directory configuration is added to your site, you'll need to restart apache for the change to take effect.

Wasn't there something about a URL?

Now that you know where munin (or an Alias to it) is in relation to your web server's document root, finding the address of the munin reports is a matter of putting together the URL of your site and the location of munin's web pages within that site.

When you go to your base URL, like, "http://www.example.com", you're telling the web server you want to see the content in your site's document root, let's say "/var/www/html". When you go to your site with that address there's actually an implied slash at the end of the URL. Let's add that slash to make it easier to see the relationship between the URL and the document root:

http://www.example.com/

You can think of that last slash in your base URL as meaning "look in my document root". Since we're assuming /var/www for this example, that means "/" means "/var/www/html/". Now look at where the munin web directory is located in our example, "/var/www/html/munin". If you substitute a slash for the /var/www/html/ part, you get simply "/munin". Now we can put the base URL together with the relative munin location that you just worked out, and get:

http://www.example.com/munin

And there you have the address you visit in a browser to look at munin's reports. Most importantly, you have an idea of how we came up with it. You can change settings on your web server or in munin later and know how those changes could affect the address you use to see munin's web pages.

See the results

Munin collects data and generates new graphs every five minutes. If it hasn't been five minutes since you configured munin you may need to wait a little bit before there are web pages generated in the munin HTML directory. Also expect your initial graphs to be pretty sparse since there won't be much data for munin to use when drawing lines.

Point your web browser to the URL you determined above and let's see what comes up. Hopefully you'll see the host name you put into the munin.conf file, similar to:

Munin overview page

If you get a "not found" error you may need to review this article to see if you missed a settings change or need to make the munin web directory writeable by the munin user. You might also check the web server logs in /var/log/apache2 and the munin logs in /var/log/munin for clues.

Clicking the first name in the list on the munin overview page (in the screenshot, the first "jered") will show a list of graph categories:

Munin node page

Once you've confirmed that the pages are being created and can be reached, wait a half hour or so to let munin accumulate enough data to draw the beginnings of a few graphs. If you click the second hostname entry on the overview page you'll get a page with all generated graphs on it. The following shots are from a munin instance that's been running a few days, to make the graphs easier to spot:

Munin graphs page

Pretty boring stuff at the top on the example server, since it's been mostly idle. You can see more active graphs if you scroll down to the system section:

Munin system graphs

From here it's just a matter of checking in on munin's reports every now and then to watch the trends and to follow up on any emails munin sends you. Keep an eye out for things like swap in/out (ideally there should be almost none), regularly high non-idle cpu use, and spikes in bandwidth use ("eth0 traffic").

For more information on the data munin reports check the documentation and FAQ at the munin project's web site.

Summary

In this article we looked at configuring the munin HTML directory and the web server's document root, and how to put that information together to get the web address for viewing the munin reports. We also viewed the munin reports to make sure they were accessible and updating.

Future articles in this series will cover installing nodes on additional slices (so you can monitor multiple slices from one munin master) and customizing munin by adding more plug-ins or improving security on the data it's generating.

If you're content with the default plug-ins and a single node, you need go no further. You're all set!

  • -- Jered

Article Comments:

shashi commented Wed Mar 21 07:55:31 UTC 2012:

Fantastic articles. I could get the it running in minutes. Thanks a lot

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)