Perth Hackfest October 2012/Logging User activity / Reporting / Analytics

• Why this is the most important topic?
  • Hardly any of new development is data based. Hard to prove issue being solved is a problem and later that your fix was an improvement.
  • To get data, we need to do more logging. Right now logging is added whenever someone feels like it. No admin actions are logged, no synchronization with server logs, no capturing data over time, not deleted with much granularity (all or nothing mostly)
  • Would allow researchers to study data
  • Would allow teachers to improve their teaching process. Provide real time feedback.
• Approach: Build something and they will come vs built what we think people need
  • Just log everything
  • store it ‘somewhere’ really quick and let plug-ins determine where to put it permanently (NoSQL, SAS, file...) default base level plug-in to current log table
  • Should be more of a tracing architecture
  • The more defined you have your data, the more data you can get out of it. The less restrictive, the more data you can capture, but more you need to sift through. Need to find a balance between the two.
  • have a log level settings so different sites can define how much they want logged - small sites might have low-level logging, to help manage log size
  • add_to_log retained for backward compatibility, wrapper for new logger class.
• Parts of Moodle that aren’t being logged, that should
  • 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
  • Should be careful about logging confidential information (e.g. POST data)
  • Shouldn’t delete logs when course is deleted
  • Action logging improvements META - MDL-28443
• Notification screen
  • Like facebook timeline
  • log view for current page available on every page
• How to capture logging
  • Streaming logs into logsstash, fluentd, etc via UDP. Then query or filter on generic log server.
  • Use event handler and plugins can determine where to send logs or if it would be logged.
  • Similar to MUC, have different store back-end plugins.
• Needs to be able to send data BACK to Moodle => Requirement.
• Uses of log table at the moment
  • recent activity (block, myMoodle)
  • course activity report, participation report, user outline report
  • stats
  • cron
  • conditional access
  • files via clamav
  • automated backup locking/heartbeats (probably)
  • failed logins
  • auth/mnet/auth.php
  • backup/restore (target logs and own logging)
  • grade history (currently separate log)
• Problems
  • How to bring logs stored in course backup in a restore?
    • who cares?
  • Need to standardize event data that is being passed

Examples of data-based learning technology development:

http://onlinelibrary.wiley.com/doi/10.1111/j.1467-8535.2008.00928.x/abstract

http://www.sciencedirect.com/science/article/pii/S0360131510000461

-> qtype_pmatch

http://www.tandfonline.com/doi/abs/10.1080/02680513.2011.567754

http://oro.open.ac.uk/24619/

Events API would need a catch all event handler for the logging system

Trigger an event for every loggable action

Possible logging backends

1. Database (default)
2. File
3. logsstash, fluentd, etc

Why use the Event API? Any log is a recorded event.

Eloy side-note: No. The event API can be a “vehicle” to send information to logging (agree with that), but logging MUST work (be able to log “things”) independent of the event API.