maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxxx>]

Hi.

So, "Phone Home" or "MySQL feedback daemon" or "better name wanted"
feature.
It is something that can be installed together with MariaDB, it will
gather different statistic about how MariaDB is used and will send this
information anonymously to mariadb.org.

Not unlike the Uptimes Project or Debian Popularity Contest.

The complete specs will be here:
http://askmonty.org/worklog/Server-Sprint/?tid=12

There are basically four questions I'm thinking on.

1. Should that be a MariaDB plugin or a separate executable ?

I tend to prefer a separate executable. There is no need to keep it in
memory constantly - cron job can do. Being separate its bugs won't
affect the server. Being separate one instance can monitor many MariaDB
servers. It can be upgraded separately - and it's not tied to the server
release schedule.

The drawback - it won't be able to grab MariaDB internals easily, which
means it may not report some data that are worth reporting. But to solve
this we can add an I_S table that provides this information. This way
there's no "hidden" data to report, everything is available from the
SQL. Which is good :)

2. How to send the data.

We'll use HTTP. Seems to be the most universally working transport.
That's what other projects are using too - Uptimes Project uses UDP or
HTTP, Debian Popularity Contest - SMTP or HTTP.

We *may* want to add SMTP later, if needed.

3. Auditing.

How can we prove to paranoid users that we only send what we are saying
we send, and none of potentially private information.

Possible solution:

  http sending should support a proxy (to work behind firewalls), so one
  can install a logging proxy and record all the data sent. On the other
  hand, we'd like to use SSL too.

  We can support, besides direct http, a "wget mode" where the data are
  sent by invoking wget (which supports proxies, SSL and --post-file)
  and one could easily replace wget with a simple script that logs
  all the data.

4. What to report.

That's the most interesting part :)

note that not everything from below is collected in MariaDB now, but I
describe the ideal case, what would be useful to know to steer MariaDB
development in the right direction.

The principle I used was not "let's grab as much as we can" but "on a
need-to-know basis". For example, we may need to decide whether to
optimize huge IN (...) lists or GIS first. Knowing what is used more
often would help to make a correct decision.

 hardware: CPU, RAM
 OS (linux distribution, kernel)
 mariadb version, memory usage
 parts of config (e.g. buffer sizes)
 list of installed plugins
 number of databases, max/avg number of tables in a database,
 max/avg db/table size
 uptime
 something that indicates the load, e.g. average qps
 how much a particular feature is used:
   Com_ counters from SHOW STATUS
   plugin usage counters
   per feature, like GIS, replication, etc.
   per query parts, like ORDER BY, subquery in the FROM, IN subquery ...
   how useful is query cache (hit ratio?)

What else ?

Regards,
Sergei