CSC/ECE 517 Fall 2016 E1703: Logging for Expertiza

Introduction

Currently, Expertiza doesn’t log anything, beyond the events in the console log. But often we need to know when a student logged in, reserved a topic, dropped off a team, etc. This will help the admin/instructor verify claims made by the student saying that he had submitted something or did some other activity that but didnt get reflected in expertiza due to a bug, a network issue or something else that went wrong. In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

In a production environment, logs are the best way to debug the application when something goes wrong. In the absence of logs, it is very difficult for a developer/support technician to debug and analyze what went wrong.

Events to Log

Student Activity

Logins, logouts, signups, submission of files/links (although there is already a log of when links are submitted), issuing invitations, joining teams, dropping off teams, requesting reviews, submitting reviews (or author feedback, or teammate reviews, or meta-reviews), undoing any of these operations.

Instructor/TA/Admin Activity

creating/editing courses and assignments, giving grades, impersonating other users, adding TAs, adding participants to courses or assignments, assigning reviewers.

What we plan to implement

There are two parts to this project:

• Logging the events and other information that will help in debugging
• Creating a GUI to interpret the logs and show events for a particular user in a particular time frame.

We are planning to use the logging framework that comes inbuilt with rails. Rails makes use of the ActiveSupport::Logger class to write log information. Each log statement in the program has a level associated with it which indicates their importance.

The hierarchy of log messages is as below:

• UNKNOWN: An unknown message that should always be logged.
• FATAL: A unhandleable error that results in a program crash
• ERROR: A handleable error condition
• WARN: Warnings
• INFO: Useful info about system operation
• DEBUG: Low level info for developers to help with debugging.

In the config file, we can specify the level of logs to be printed. A log statement in the program will be printed only if its level is equal to or higher than the level set in the config file. Usually in production, we set the level to INFO or WARN and in in a development environment, we set it to debug which will print out all the finer details of the state of the system which helps in debugging. Currently, the expertiza code contains very little logging statement and it does not record student/instructor or TA activity. The current logs are also of little or no help to a developer/ support technician trying to debug the code when something goes wrong. We improve the current log statements by adding more information to it so that it becomes more useful to the person trying to debug the code and will also record all student, TA and instructor activities.

For the second part of the project, we will create a view that is accessible only to the admin from his console. This view will list out the events by interpreting the logs and give an option to filter it based on user and date.

Approch

Logging

We are planning to standardize the log statements by giving them a predefined format. This will also help us in the second part of the project which is to interpret the logs and display student activities in a GUI. This is the format we propose:

• INFO:

[TimeStamp: | controller_name|method|  roleid| userid|event: {login|submission|.....}]
We will use this to log entry into methods and to log events like login, submission, joining teams, leaving teams, creating assignments, inviting other user to team etc.

• DEBUG:

[TimeStamp: controller_name| method_name|roleid| userid|{variable_name, variable_value}]
We will use this to print out values of key variables which the developer/debugger can use for debugging.

In the production environment, we will limit the logs to INFO mode, i.e it will print out only the errors and events.

In development environment, we will set the logger mode to DEBUG. This will print out all the logs including errors, events and debug statements. This will help the developer in debugging the code when something goes wrong.

Interpreting the Logs

This is the second part of the project. We will be creating a GUI to interpret and make sense of all the log data. The GUI will display the events for each user. We will also give an option to filter the event listing based on date and events.