[collectd] How to store MySQL statistics?

Niki Waibel niki.waibel at newlogic.com
Tue Dec 20 10:45:51 CET 2005


On 18-Dec-2005 Florian Forster wrote:
> Hello everyone,
> 
> I have a hard time deciding between two alternatives and just wanted to
> ask if anyone cares and, if so, which way to prefer:
> 
> The new `mysql' plugin connects to a MySQL database and issues
> `SHOW STATUS;'. One of the things I want to handle are the commands that
> have been issued. There are counters for a large number of commands, for
> example: `Com_select' and `Com_update' but also rather uninteresting
> stuff such as `Com_show_charsets' or `Com_create_function'.
> 
> Since these `data sources' aren't closely connected (a different version
> of MySQL could show two more, another could have some less..) the
> ``right way'' would be to have one RRD-file for each counter, e.g.
> `mysql_commands-select.rrd' and `mysql_commands-show_charsets.rrd'. This
> will result in a huge number of RRD-files but every user can decide on
> his own what's interesting for him..

i have EXACTLY the same problem with the quota plugin!!!!!
there can be more or less users, groups and dirs!!!
it is even worse!!!

at the moment i create files like this:
        quota-<type>-<name>-<id>-<dir>.rrd
type: usr/grp/prj
name: niki/octo/users/...
id:   100/101/500/...
dir:  ie _
      or _video
      or _crypto_disc_a
(dir: all / converted to _)

 ... which is VERY bad!

> The other way is to categorize these counters for the user. It's the way
> it's currently implemented, though I'm not entirely happy with that. I
> sum up `Cmd_insert*', `Cmd_select', `Cmd_show*' and `Cmd_update*'. I
> ignore `Com_stmt_*' and everything `Cmd_*'-else is called `other'. This
> way I have five DS which show the most used commands in not so great
> detail..

hmmm -- i dont know that much about the mysql quotas,
but i really think that a dir structure is necessary
for the .rrd files. at least for the quota plugin, i
think there is no workaround...

> So, which solution to choose? Great detail and flexibility, and many
> files. Or one file and only a rough view of what the database is doing?

i'd say all detail and many files, but organized in a dir structure.
one of:
        plugin_submit()
        plugin_write()
        <plugin>_write)()
        rrd_update_file()
should be able to create the dirs if necessary.

niki



More information about the Collectd mailing list