Last modified: 2014-02-26 12:53:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T49591, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 47591 - Generate alerts if theoretically impossible or unwanted logging occurs
Generate alerts if theoretically impossible or unwanted logging occurs
Status: NEW
Product: Analytics
Classification: Unclassified
EventLogging (Other open bugs)
unspecified
All All
: Normal enhancement
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-24 05:43 UTC by Steven Walling
Modified: 2014-02-26 12:53 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Steven Walling 2013-04-24 05:43:07 UTC
In E3, we recently ran in to a situation where post-hoc analysis revealed logging that should in theory have been impossible given the user experience and bucketing logic (bug 47590). It would be relatively easy to set up alerts if actions like logging a test condition impression for a user id bucketed as control occurs, letting us know about errors as they happen. Since each experimental design is different, this may require setting up custom alerts per schema/log.
Comment 1 Ori Livneh 2013-04-24 06:16:59 UTC
Here's one:

count(page-impression) >= count(page-save-attempt) >= count(page-save-success)
Comment 2 Ori Livneh 2013-04-24 06:31:46 UTC
Super-simple approach: a repository which consists of a single script and a 'sql' subdirectory. The subdirectory contains SQL queries, one to a file. Each query should return a boolean. When the script is launched, it iterates through these queries and executes each in turn against the database. If any query returns 0, an e-mail alert is sent. A cron job ensures the script is invoked at regular intervals.

If we had this, Steven and Dario would be able to add and remove assertions very easily, using git rm / git add and git review. I'd use puppet to configure a cron job to keep the repository state up-to-date.
Comment 3 Andre Klapper 2014-02-26 12:53:48 UTC
[moving from MediaWiki extensions to Analytics product - see bug 61946]

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links