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:

• What’s the best way to choose graph colors?
• Version 1.1.7 of Better Cacti Templates released
• A better way to build Cacti templates
• Secure, easy Cacti graphing without SNMP
• Version 1.1.2 of improved Cacti templates released

Over half a gigabyte; more than twice what MySQL itself is using. So, that raises an interesting question. How much memory would you say your server’s MySQL Enterprise Monitor agent uses? No bashing allowed, tell the truth. And please post if your agent runs in a small amount of memory, too.

Another thing I’m interested in: what factors contribute to the high memory usage? Under what conditions does it use a lot or a little? What can you expect, generally speaking?

On another note, I think it’s almost unfair not to mention the competition, so I will: I was playing with MONyog 2.6 recently and it started to use a lot of CPU. I think it might be architecture-specific (amd64 Ubuntu) but I can’t be sure. It was using 170% CPU on my dual-core system to monitor 2 instances.

Further Reading:

• Is agent-based or agentless monitoring best?
• How to set up dual monitors in Ubuntu on Dell Inspiron 1501
• MySQL Table Sync vs. SQLyog Job Agent
• mk-query-digest uses less memory
• What would make me buy MySQL Enterprise?