It would be super useful to know what commands and options folks are using in the real world. We could consider adding an optional feature which

  1. Logs each command that gets invoked, along with its options. Option values and arguments are omitted since we don't need them and are potentially sensitive. Log file by default lives in $HOME/.drush/usage. We could consider logging to an local sqlite DB as well. Possibly log environment info like OS as well.
  2. Weekly, drush uploads the data to its warehouse. Ideally we do that at the end of a regular drush request so the user does not have to actively remember to push.
  3. I'd like to maintain as little server side code as possible. One idea is have drush POST data to MongoLab (hosted MongoDB with REST API). We could point a web GUI at it and ad-hoc query from there. Other options are Amazon SimpleDB and Sampler+Views.

Comments

moshe weitzman’s picture

Status: Active » Needs review
StatusFileSize
new1.98 KB

Attached commandfile logs locally. Rename to usage.drush.inc and put in ~/.drush

I've asked MongoLab if they support multi-insert via the REST interface. Kinda critical for speedy data transfer.

moshe weitzman’s picture

MongoLab does not support multi-insert via REST. Google spreadsheets has a max row limit. Starting to think we'll need to use a Drupal backend.

moshe weitzman’s picture

StatusFileSize
new76 bytes

If you are using the commandfile attached earlier to track your usage, then you will see an error if it loads and you happen to use drush4 (it was written for drush5). To avoid that error, name the attached file usage.drush.load.inc and put it in ~/.drush alongside the commandfile. This prevents the commandfile from loading on 4. Interested parties can see where we do this check at http://api.drush.org/api/function/_drush_add_commandfiles/5.x

moshe weitzman’s picture

StatusFileSize
new3.03 KB

Mongolab added multi-insert to its REST API so here is a new usage.drush5.inc. As the name implies, it only works for drush5 and you have to have today's version, or later. Also, paste the following code into your drushrc.php to turn it on completely:

$options['drush_usage_log'] = TRUE;
$options['drush_usage_send'] = TRUE;
moshe weitzman’s picture

StatusFileSize
new3.08 KB

Slightly better version that breaks out major and minor version of drush.

So, do people think this should ship with drush5? Would be off by default.

moshe weitzman’s picture

So - put this into drush5 or no?

greg.1.anderson’s picture

Looks good to me; I'd be in favor of putting it in.

You could now use drush_directory_cache('usage') . '/usage.txt'; instead of drush_directory_cache() . '/usage/usage.txt';, if you want. It would create the usage dir for you, then.

Seems like the 10k limit is too low; drush status --debug sends usage info every time. Maybe 50k or 100k would be better? Don't want to go too high...

A frill: include a command to show the unsent cached data. Folks might want to run it for a while and inspect before enabling the send feature.

greg.1.anderson’s picture

StatusFileSize
new5.5 KB

It looks like the usage stats were being sent every time because the comparison operator was reversed. The stat files are tiny.

Here is a slightly reworked version with two frill commands: usage-show and usage-send. Perhaps these should be hidden commands to avoid clutter?

moshe weitzman’s picture

Status: Needs review » Fixed

Committed to master.

I upped default log_size to 50Kb, added README/drushrc.php docs, removed confirm for usage-send, and added a 'host' element so we can omit outlier submitters when running reports.

moshe weitzman’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.