Xaprb » graphing

How to lie beautifully with FusionCharts

Xaprb — Tue, 29 Sep 2009 03:14:16 +0000

Gotta love those three-dimensional charts. They sure are shiny! Look at this:

FusionCharts graphs

This is a screenshot of FusionCharts graphs. But wait, on closer inspection: 5 and 7 are the same height? 6 is exactly twice as tall as 2?

Pseudo-three-dimensional charts are the bane of my existence. Tufte would definitely not approve. (If you don’t have The Visual Display of Quantitative Information, you should really get it and give it a read.)

Further Reading:

MySQL Cacti templates version 1.1.1 released

Xaprb — Thu, 16 Oct 2008 03:21:14 +0000

I’ve released version 1.1.1 of the MySQL Cacti templates I develop. The new templates work around more Cacti limitations, including the limitation on the length of the data returned from the poller script. There’s also a new graph and many other niceties since the last release.

Note that there are TWO incompatible changes with the previous version of the templates. You don’t have to throw away your RRA files, you just have to delete and re-import over all the existing templates. It’s not my fault, there was no other way to work around the limitations mentioned above. Really. Have fun upgrading!

Version 1.1.1 is actually just a repackaging of 1.1.0.

The changelog follows.

2008-10-15: version 1.1.1

	* The tarball didn't have make-template.pl mysql_definitions.pl (issue 34)

2008-10-14: version 1.1.0

	* Graphs fetched too much data, causing errors (incompatible; issue 28, 23).
	* Output of the poller script is compressed with short value names.
	* Checks can be disabled; no need to fetch INNODB STATUS if unwanted.
	* Queries could cause a MySQL thread stack overflow (issue 19).
	* Older PHP didn't have array_change_key_case function (issue 21).
	* The PROCESS privilege is required for MySQL 5.1.29 with InnoDB (issue 22).
	* Added an aggregated view of SHOW PROCESSLIST; requires PROCESS privilege.
	* The text on the graph could overflow the right-hand edge.
	* Truncated SHOW INNODB STATUS could cause an SQL error (issue 27).
	* The poller script requires proper cmdline options (incompatible change).

Further Reading:

Would Tufte approve of mixing units on a graph?

Xaprb — Fri, 10 Oct 2008 01:58:22 +0000

I’ve created a set of Cacti templates for graphing stats about MySQL. While these were based on several other people’s work, there are many improvements. One of them in particular I want to bring up, and I’ll go so far as to say it ought to be a “best practice” for graphing. That is, don’t mix units on a graph.

In the simplest terms, this means that just because things are related doesn’t mean they belong together. I made an effort to separate things onto different graphs when they have different units. For example, the query cache metrics don’t all belong together. There are memory metrics, there are block metrics, and there are metrics about queries. If you jam them all together, the differences in the units will cause various graphs to obliterate each other. Some values are much larger than others, and that’ll cause some values to be minuscule on the graph.

The graph templates that inspired me to create mine mashed them all together and then scaled things logarithmically to compensate for the resulting problems. This does not address the root of the matter. By contrast, my templates split them apart, so all the things whose unit is “query” are on one graph together. Then I looked at the remaining stats (units: blocks and units: bytes) and decided that in the interest of not having way too many graphs, I’d put them together. I’m still not sure this was a great idea, and I have a nagging Tufte voice in my head. Anyway, I tried to strike a balance in this specific case, but in general I kept things separate.

One of the great things about Cacti is that you can graph whatever you want. You can graph the temperature on your server’s hard drives, or the Dow Jones Industrial Average, or whatever. So you can have a single graphing solution for your whole company’s needs. By contrast, MySQL Enterprise Monitor is focused on a single purpose. So it should do a really good job at it, right? Actually, no, they get it wrong too — they mix units. Here you can see exactly the effect I’m talking about; one value can obliterate the other. (You get points if you guess what’s going on in this graph.)

MySQL Enterprise Monitor Query Cache Graph

I’ve tried to make the Cacti templates for MySQL as useful as possible, and judging by the graphs I see on client sites (these templates are quite popular, independent of me or my employer) they do a pretty good job. There’s still room for improvement, though. I’m adding more carefully selected bits of information into the graphs, and making them more robust to deal with bizarre errors that happen in real life. And of course, always finding new ways to work around the limitations of PHP and Cacti, both of which have their quirks.

Are there wishes you have for these graphs, too? If so, submit an issue report on the Google Code project. Just don’t ask me to graph unrelated things together, OK?

PS: sometimes things with the same units are still much bigger or smaller than each other. That’s why my templates always print out the values in numbers along the bottom of the graph, so you can see the magnitude of the values, not just look at the lines.

Further Reading:

Screenshots of improved MySQL Cacti templates

Xaprb — Sun, 25 May 2008 18:10:00 +0000

I finally have some images to show you what my improved Cacti templates look like.

These aren’t a perfect demo, since for example this server doesn’t have the query cache enabled, but it should show you what I’ve done. Note, for example, that each graph is labeled with the actual values of the images drawn on it. You don’t have to guess what the values are by squinting at the graphs.

You can click on any image to go to a larger version. Enjoy:

Enjoy!

Further Reading:

Improved Cacti monitoring templates for MySQL

Xaprb — Mon, 28 Apr 2008 00:43:18 +0000

Download MySQL Cacti templates

As promised, I’ve created some improved software for monitoring MySQL via Cacti. I began using the de facto MySQL Cacti templates a while ago, but found some things I needed to improve about them. As time passed, I rewrote everything from scratch. The resulting templates are much improved.

You can grab the templates by browsing the source repository on the project’s homepage.

In no particular order, here are some things I improved:

Standard polling interval and graph size by default.
Full captions on every graph; you don’t have to guess at how big the values are. Each graph has current, max, and average values printed at the bottom for every value on it.
Much more data is captured. I’ve graphed almost everything I could think of.
The graphs are grouped better. Most graphs have only related values. There are some exceptions, but not many.
The templates don’t hijack your existing installation. They don’t depend on or alter anything in your default Cacti installation.
The script that gathers the data is totally rewritten from scratch, and much improved. For example, the math works on 32-bit systems. It has caching built-in so each poll cycle results in just one request to the server, instead of one request per graph. (This is a weakness of Cacti I’m trying to work around). It also has debugging aids and other good coding stuff.
By default, it assumes you have the same username and password across every server you’re monitoring, so you don’t have to fill in a username and password for every single graph you create.
One data template == one graph template. This helps work around another Cacti limitation.
Lots more. Honestly I can’t really remember everything I’ve done. I’m sure you’ll help me remember by asking me how to get X feature working the way you want, and I’ll go “oh, yeah, that’s another thing I improved…”

Cacti templates are very laborious to create if they’re complex at all; it takes a long time and is very error-prone. Instead of doing it through Cacti’s web interface and exporting a huge XML file, I eliminated the redundancies and created a small, easy-to-maintain file from which I generate the XML template with a Perl script. This gives the added benefit of letting me (or you) generate templates with different parameters such as polling interval or graph size. The README file has the full details. However, I’ve pre-generated a set of templates that matches Cacti’s defaults, so you can probably just use that.

This has taken a lot of time. In particular, I spent a lot of time working on it at my former employer, The Rimm-Kaufman Group (kudos to them for letting me open-source the work) and I just spent most of my weekend writing the scripts to convert from the compact format to XML templates, so it’s possible to maintain these beasts. Plus I had to develop the compact format, too. This took a lot of time because I had to understand the Cacti data model, which is pretty complex.

Please enter issue reports for bugs, feature requests, etc at the Google project homepage, not in the comments of this blog post. I do not look through comments on my blog when I’m trying to remember what I should be working on for a software project.

If these templates help you and you feel like visiting my Amazon.com wishlist and sending something my way, I’d appreciate it!

PS: You may also be interested in Alexey Kovyrin’s list of templates for monitoring servers.

Further Reading: