How to read the scale of the munin monitoring system, tomcat accesses by day graph
The tomcat accesses by day graph in munin has a y axis that shows "accesses / second", and currently shows "66 m". It can't be 66 million accesses per second, a single server couldn't return that quickly. Also, tomcat is configured to sit behind apache with ajp and apache is only receiving about 25 queries per second.
What does the "m" mean here?
This can best be answered by quoting Wikipedia
Milli (symbol m) is a prefix in the metric system denoting a factor of one thousandth
Munin (by default) reads a counter every 5 minutes, and calculates the average between the two last reads. 66m means 66*300 = 19.8 accesses within a five minute period (but the 66 is probably 66.6666, so you'll end up with 20 accesses that interval).
I found a couple other posts asking similar questions. Responders came to similar conclusions: what does the 'm' unit in munin mean?
I'm using version 1.4.5 of munin (vs. 1.4.4), and I saw a max of 400 m accesses/second, which makes little sense. It definitely isn't 400 million accesses per second. 400 x 10**-3 makes sense for what I'm running (a very lightly used web service in our engineering group).
When the value to be graphed is less than 1 unit-per-time-interval, showing it this way is very misleading. If the max value in the graph is less than one, then change the units to accesses per minute, or even accesses per hour if necessary. Or make the max y be "1 access per second" and let the data rumble around in the lower region of the graph.
If no reasonably compact, clearer method of displaying the data can be figured out, I'd suggest a note or tooltip or something that helps the user understand the variable and its units. When one drills down (click through to the 4 graphs day/week/month/year), the variable is explained as: "The number of accesses (pages and other items served) globaly on the Apache server". Add a discussion of units (and spell globally correctly).
Note - I have not checked this on a newer version of munin. Perhaps it has been improved. However, I was not able to find mention of the topic on the http://munin-monitoring.org/ site. Apologies for not going and filing a feature request on munin.