In-Portal Issue Tracker

Welcome to the In-Portal Open Source CMS Issue Tracker! This is a central management / tracking tool for all types of tasks / issues / bugs for the In-Portal Project. Before reporting any issues, please make sure to read the Guide into Issue Tracker and How to Properly Test and Report Bugs!

View Revisions: Issue #1003 All Revisions ] Back to Issue ]
Summary 0001003: Logging engine
Revision 2012-10-02 10:13:10 by alex
Description In-Portal has very powerful logging system when debug mode is on, but if developer won't look at errors reported there in time (e.g. before he closes the page with debugger), then most probably he won't get same error next time.

Also In-Portal has nice "Silent Log" feature, when all errors got written to file, but it is turned off by default and that log (since it's a text file) can't be easily analysed.

So this is good error reporting code, but it's results are not being recorded for future analysis and what's is recorded is not enough to properly pinpoint problematic place in code after error already happened and there is no more place to retrieve data from.


To solve above mentioned issues I'm proposing to create kLogger class (and associated SystemLog table), that would:
* handle sql error processing
* handle php error/notice/warning processing
* handle exception processing
* handle user-defined messages

What should be recorded along with each event being logged:
* $_SERVER['HTTP_HOST'] - address of page's webserver (useful in multi-user development environment)
* $_SERVER['REMOTE_ADDR'] - ip address of page visitor
* current user id (guest or not)
* SessionData/UserSession table - session data
* SessionID - session id (when available)
* $_GET, $_POST, $_COOKIE - user input on page, where event happened
* $_SERVER['REQUEST_URI'] - url that was used to access the page
* $this->Application->isAdmi - is user an admin or not
* complete trace to the php method, that raised that event
[TODO] * occurrences count: today/yesterday/last week/last month
[TODO] * last occurrence on - date/time when event was raised


Automatic system log cleanup:
* none
* automatic (weekly)
* automatic (monthly)

In Admin Console there will be a new section under "Summary & Logs" called "System Log" with list of all logged events, that happened.
Revision 2012-08-20 08:38:35 by alex
Description In-Portal has very powerful logging system when debug mode is on, but if developer won't look at errors reported there in time (e.g. before he closes the page with debugger), then most probably he won't get same error next time.

Also In-Portal has nice "Silent Log" feature, were all errors got written to file, but it's turned off by default and that log (since it's a text file) can't be easily analysed.

So there good error reporting code, but it's not recorded for future analysis and what's is recorded is not enough to properly pinpoint problematic place in code after error already happened and there is no more place to retrieve data from.


To solve above mentioned issues I'm proposing to create kLogger class (and associated SystemLog table), that would:
* handle sql error processing
* handle php error/notice/warning processing
* handle exception processing
* handle user defined events

What should be recorded along with each event being logged:
* $_SERVER['HTTP_HOST'] - address of page's webserver (useful in multi-user development environment)
* $_SERVER['REMOTE_ADDR'] - ip address of page visitor
* current user id (guest or not)
* SessionData/UserSession table - session data
* SessionID - session id (when available)
* $_GET, $_POST, $_COOKIE - user input on page, where event happened
* $_SERVER['REQUEST_URI'] - url that was used to access the page
* $this->Application->isAdmi - is user an admin or not
* complete trace to the php method, that raised that event
[TODO] * occurrences count: today/yesterday/last week/last month
[TODO] * last occurrence on - date/time when event was raised


Automatic system log cleanup:
* none
* automatic (weekly)
* automatic (monthly)

In Admin Console there will be a new section under "Summary & Logs" called "System Log" with list of all logged events, that happened.
Revision 2011-02-14 13:28:16 by Dmitry
Description In-Portal has very powerful logging system when debug mode is on, but if developer won't look at errors reported there in time (e.g. before he closes the page with debugger), then most probably he won't get same error next time.

Also In-Portal has nice "Silent Log" feature, were all errors got written to file, but it's turned off by default and that log (since it's a text file) can't be easily analysed.

So there good error reporting code, but it's not recorded for future analysis and what's is recorded is not enough to properly pinpoint problematic place in code after error already happened and there is no more place to retrieve data from.


To solve above mentioned issues I'm proposing to create EventLog class (and associated EventLog table), that would:
* handle sql error processing
* handle php error processing
* handle exception processing
* handle user defined events

What should be recorded along with each event being logged:
* $_SERVER['HTTP_HOST'] - address of page's webserver (useful in multi-user development environment)
* $_SERVER['REMOTE_ADDR'] - ip address of page visitor
* current user id (guest or not)
* SessionData/UserSession table - session data
* SessionID - session id (when available)
* $_GET, $_POST, $_COOKIE - user input on page, where event happened
* $_SERVER['REQUEST_URI'] - url that was used to access the page
* $this->Application->isAdminUser - is user an admin or not
* complete trace to the php method, that raised that event
* occurrences count: today/yesterday/last week/last month
* last occurrence on - date/time when event was raised
* submitted (yes/no) + submitted on (date/time) - fields to indicate when given event was submitted to www.in-portal.org website for analysis.


New step will be added during installation (maybe on final stages, after configuration page), where user will be faced with a question about "In-Portal Customer Experience" program and the following options:

Event log submission method:
* manual
* automatic (daily)
* automatic (weekly)
* automatic (monthly)

Automatic event log cleanup:
* none
* automatic (weekly)
* automatic (monthly)

This should be a separate step, since user MUST notice what we are asking here.


In Admin Console there will be a new section under "Summary & Logs" called "Event Log" with list of all events, that happened. There also will be "Submit To Developers" toolbar button that allows to submit all previously not submitted data to www.in-portal.org website.
Revision 2011-02-14 13:20:43 by Dmitry
Description In-Portal has very powerful logging system when debug mode is on, but if developer won't look at errors reported there in time (e.g. before he closes the page with debugger), then most probably he won't get same error next time.

Also In-Portal has nice "Silent Log" feature, were all errors got written to file, but it's turned off by default and that log (since it's a text file) can't be easily analysed.

So there good error reporting code, but it's not recorded for future analysis and what's is recorded is not enough to properly pinpoint problematic place in code after error already happened and there is no more place to retrieve data from.


To solve above mentioned issues I'm proposing to create EventLog class (and associated EventLog table), that would:
* handle sql error processing
* handle php error processing
* handle exception processing
* handle user defined events

What should be recorded along with each event being logged:
* $_SERVER['HTTP_HOST'] - address of page's webserver (useful in multi-user development environment)
* $_SERVER['REMOTE_ADDR'] - ip address of page visitor
* current user id (guest or not)
* SessionData/UserSession table - session data
* SessionID - session id (when available)
* $_GET, $_POST, $_COOKIE - user input on page, where event happened
* $_SERVER['REQUEST_URI'] - url that was used to access the page
* $this->Application->isAdminUser - is user an admin or not
* complete trace to the php method, that raised that event
* occurrences count: today/yesterday/last week/last month
* last occurrence on - date/time when event was raised
* submitted (yes/no) + submitted on (date/time) - fields to indicate when given event was submitted to www.intechnic.com website for analysis.


New step will be added during installation (maybe on final stages, after configuration page), where user will be faced with a question about "In-Portal Customer Experience" program and the following options:

Event log submission method:
* manual
* automatic (daily)
* automatic (weekly)
* automatic (monthly)

Automatic event log cleanup:
* none
* automatic (weekly)
* automatic (monthly)

This should be a separate step, since user MUST notice what we are asking here.


In Admin Console there will be a new section under "Summary & Logs" called "Event Log" with list of all events, that happened. There also will be "Submit To Developers" toolbar button that allows to submit all previously not submitted data to www.intechnic.com website.



Web Development by Intechnic
In-Portal Open Source CMS
In-Portal Open Source CMS
Copyright © 2000 - 2009 MantisBT Group

Powered by Mantis Bugtracker