Logging 2: Difference between revisions

Revision as of 13:34, 15 May 2013

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.

Logging is fundamental to research, reporting and analytics.

Not much of new Moodle development is based on measured data. We need to
- Prove there is a problem
- Prove that a given change is an improvement.
Data comes from logging
Better data would allow researchers to study what happens in online teaching.
Better data would give admins more feedback on how to run their site (both technically and process)
Better data would give teachers better feedback to improve their teaching process.
Better data would give students better feedback to improve the learning process.
We can't predict all the analysis that might happen in future.

Here are some random ideas, please add more!

Timely notifications of critical events (defined by users), eg more than five people posted in the same forum within an hour.
"Red circle" notification badge counter icons everywhere in Moodle highlighting things that need attention for each user.
Colour heatmaps overlaid on course page showing recent usage patterns on a course
Visualisation of live activity across a whole site (for admins)
Live engagement analytics that take every little action into account
Identification of students at risk based on complete history

A lot of the time-critical uses of the log table can be moved to new tables specifically for this purpose. It will speed things up a lot.

Other things can can continue to query the main logs:

And some future things that will need the full log:

Errors and warnings
- People report errors, but cannot duplicate it.
- Logging history with stack trace would be very useful
- Also dump session variables and all other data that can be useful for debugging
Admin activities
Micro activities in a page (more than one per load)
AJAX calls (eg on course page)
Should be careful about logging confidential information (e.g. do not log any POST data)
Shouldn’t delete logs when course is deleted
All events should all be logged
- Add more events (they are cheap and very useful)
- Need more standardisation of event data for all triggered events
- Add a catch-all handler that pushes events to the logging system
--> Action logging improvements META - MDL-28443

We can't actually predict all the use cases so we must think generically and plan for worst cases.

Things that don't need to use logs should not use logs. (Recent activity, etc)
Make logging calls as cheap as possible
Use Events API for the originating calls to create lots of hooks for other things
Use MUC-like plug-ins to determine where to put logs permanently (NoSQL, SAS, file...). Default will be to the current log table.
Log everything we possibly can think of.
Define log level settings (on each logging call) so different sites can choose what they want logged and so control size, speed etc
add_to_log retained for backward compatibility, make it a wrapper for new logger function.
provide hooks to expose logs everywhere. For example, each page should have a link that shows logs and stats for that page.

@@ Line 86: / Line 86: @@
 * Things that don't need to use logs should not use logs.  (Recent activity, etc)
 * Make logging calls as cheap as possible
+* Use Events API for the originating calls to create lots of hooks for other things
 * Use MUC-like plug-ins to determine where to put logs permanently (NoSQL, SAS, file...).  Default will be to the current log table.
 * Log everything we possibly can think of.