RFC: Koha needs a logger!
Hey all, I've been thinking about this for quite a while now. I feel that Koha would benefit greatly from having a traditional logger, rather than relying on warn's being written to the apache logs. This would give us many benefits. First, we would be able to log everything to one or more standard files, regardless of whether that file was running under apache or not. Second, we could implement standard logging levels ( trace, debug, info, warn, error, fatal ). It would also help us debug ajax-related issues where child processes no longer write to the apache module. The Catalyst Perl framework has been a primary inspiration for this. We could have C4::Context->log->debug('this is a test message'); Our logger would detect the current error level and output or ignore the message accordingly. My research has lead me to Log4perl, which seems to be an outstanding logging module. It can even capture existing warns and dies. It would work perfectly except for one scenario I was hoping for. I have been thinking it might be useful for developers and even just experienced Koha users of the we could dump all the log output to the webpage. So mainpage.pl?debug=1 would not only enable debug messages, but then append all those debug messages to the bottom of the returned html. Log4perl is meant to be used as a singleton, so even if we can get the logged message back out, it would have messages from other koha scripts that were running concertedly. If I am incorrect, please let me know! So the options are: 1) Forget about the dump-to-screen feature, and just use Log4perl 2) Write our own logger from scratch with all these features, largely duplicating the effor of Log4perl and other loggers 3) Write our own logger that can handle the dump-to-screen feature, but use Log4perl within Koha::Logger for all other logging. Another idea, implement dbi tracing to allow dumping of all queries to the screen and log. Also, Perhaps the dump-to-screen could create a popup window instead of appending to the bottom of the screen. I'm looking for any and all opinions or ideas on this subject. Thanks! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )
Hi Kyle, I already launched this discussion and proposed a patch (Bug 8190). It is waiting for a signoff for 2 months... Please have a look before starting a development :) Regards, Jonathan 2012/9/14 Kyle Hall <kyle.m.hall@gmail.com>
Hey all,
I've been thinking about this for quite a while now. I feel that Koha would benefit greatly from having a traditional logger, rather than relying on warn's being written to the apache logs. This would give us many benefits. First, we would be able to log everything to one or more standard files, regardless of whether that file was running under apache or not. Second, we could implement standard logging levels ( trace, debug, info, warn, error, fatal ). It would also help us debug ajax-related issues where child processes no longer write to the apache module.
The Catalyst Perl framework has been a primary inspiration for this. We could have C4::Context->log->debug('this is a test message'); Our logger would detect the current error level and output or ignore the message accordingly.
My research has lead me to Log4perl, which seems to be an outstanding logging module. It can even capture existing warns and dies. It would work perfectly except for one scenario I was hoping for.
I have been thinking it might be useful for developers and even just experienced Koha users of the we could dump all the log output to the webpage. So mainpage.pl?debug=1 would not only enable debug messages, but then append all those debug messages to the bottom of the returned html. Log4perl is meant to be used as a singleton, so even if we can get the logged message back out, it would have messages from other koha scripts that were running concertedly. If I am incorrect, please let me know!
So the options are: 1) Forget about the dump-to-screen feature, and just use Log4perl 2) Write our own logger from scratch with all these features, largely duplicating the effor of Log4perl and other loggers 3) Write our own logger that can handle the dump-to-screen feature, but use Log4perl within Koha::Logger for all other logging.
Another idea, implement dbi tracing to allow dumping of all queries to the screen and log. Also, Perhaps the dump-to-screen could create a popup window instead of appending to the bottom of the screen.
I'm looking for any and all opinions or ideas on this subject.
Thanks! Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Topic was A C4::Logger module would be useful ? (Jun 05, 2012; 4:07pm) 2012/9/14 Jonathan Druart <jonathan.druart@biblibre.com>
Hi Kyle,
I already launched this discussion and proposed a patch (Bug 8190). It is waiting for a signoff for 2 months...
Please have a look before starting a development :)
Regards, Jonathan
2012/9/14 Kyle Hall <kyle.m.hall@gmail.com>
Hey all,
I've been thinking about this for quite a while now. I feel that Koha would benefit greatly from having a traditional logger, rather than relying on warn's being written to the apache logs. This would give us many benefits. First, we would be able to log everything to one or more standard files, regardless of whether that file was running under apache or not. Second, we could implement standard logging levels ( trace, debug, info, warn, error, fatal ). It would also help us debug ajax-related issues where child processes no longer write to the apache module.
The Catalyst Perl framework has been a primary inspiration for this. We could have C4::Context->log->debug('this is a test message'); Our logger would detect the current error level and output or ignore the message accordingly.
My research has lead me to Log4perl, which seems to be an outstanding logging module. It can even capture existing warns and dies. It would work perfectly except for one scenario I was hoping for.
I have been thinking it might be useful for developers and even just experienced Koha users of the we could dump all the log output to the webpage. So mainpage.pl?debug=1 would not only enable debug messages, but then append all those debug messages to the bottom of the returned html. Log4perl is meant to be used as a singleton, so even if we can get the logged message back out, it would have messages from other koha scripts that were running concertedly. If I am incorrect, please let me know!
So the options are: 1) Forget about the dump-to-screen feature, and just use Log4perl 2) Write our own logger from scratch with all these features, largely duplicating the effor of Log4perl and other loggers 3) Write our own logger that can handle the dump-to-screen feature, but use Log4perl within Koha::Logger for all other logging.
Another idea, implement dbi tracing to allow dumping of all queries to the screen and log. Also, Perhaps the dump-to-screen could create a popup window instead of appending to the bottom of the screen.
I'm looking for any and all opinions or ideas on this subject.
Thanks! Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
That is interesting. Is there a good argument for using something like this over Log4perl? The big question I have is: Would being able to output debug messages to the web browser be useful enough to make it work implement? Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Fri, Sep 14, 2012 at 10:16 AM, Jonathan Druart <jonathan.druart@biblibre.com> wrote:
Hi Kyle,
I already launched this discussion and proposed a patch (Bug 8190). It is waiting for a signoff for 2 months...
Please have a look before starting a development :)
Regards, Jonathan
2012/9/14 Kyle Hall <kyle.m.hall@gmail.com>
Hey all,
I've been thinking about this for quite a while now. I feel that Koha would benefit greatly from having a traditional logger, rather than relying on warn's being written to the apache logs. This would give us many benefits. First, we would be able to log everything to one or more standard files, regardless of whether that file was running under apache or not. Second, we could implement standard logging levels ( trace, debug, info, warn, error, fatal ). It would also help us debug ajax-related issues where child processes no longer write to the apache module.
The Catalyst Perl framework has been a primary inspiration for this. We could have C4::Context->log->debug('this is a test message'); Our logger would detect the current error level and output or ignore the message accordingly.
My research has lead me to Log4perl, which seems to be an outstanding logging module. It can even capture existing warns and dies. It would work perfectly except for one scenario I was hoping for.
I have been thinking it might be useful for developers and even just experienced Koha users of the we could dump all the log output to the webpage. So mainpage.pl?debug=1 would not only enable debug messages, but then append all those debug messages to the bottom of the returned html. Log4perl is meant to be used as a singleton, so even if we can get the logged message back out, it would have messages from other koha scripts that were running concertedly. If I am incorrect, please let me know!
So the options are: 1) Forget about the dump-to-screen feature, and just use Log4perl 2) Write our own logger from scratch with all these features, largely duplicating the effor of Log4perl and other loggers 3) Write our own logger that can handle the dump-to-screen feature, but use Log4perl within Koha::Logger for all other logging.
Another idea, implement dbi tracing to allow dumping of all queries to the screen and log. Also, Perhaps the dump-to-screen could create a popup window instead of appending to the bottom of the screen.
I'm looking for any and all opinions or ideas on this subject.
Thanks! Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hi Kyle,
That is interesting. Is there a good argument for using something like this over Log4perl?
I choose Log::Lite because of it seems easier and lighter than Log4perl. It does all what I want to implement. The big question I have is: Would being able to output debug messages
to the web browser be useful enough to make it work implement?
Currently, the Koha logs are very verbose. If we replace all occurrences of 'warn' to use this module and display them to the web browser, the users will be unhappy. I think it is preferable to manage and encapsule potential errors and display an adapted message for each them. Yes I know it is a big work :-/ But simply it could be possible to display only error message. For developpers I think it is not very useful to display debug messages (just my opinion). Could you test and sign-off my patch if you agree with the Koha::Utils::Logger module and/or propose changes ?
The big question I have is: Would being able to output debug messages to the web browser be useful enough to make it work implement?
Currently, the Koha logs are very verbose. If we replace all occurrences of 'warn' to use this module and display them to the web browser, the users will be unhappy. I think it is preferable to manage and encapsule potential errors and display an adapted message for each them. Yes I know it is a big work :-/ But simply it could be possible to display only error message. For developpers I think it is not very useful to display debug messages (just my opinion).
Could you test and sign-off my patch if you agree with the Koha::Utils::Logger module and/or propose changes ?
I think the option of outputting too much to the screen is better than not outputting enough. I think the one really useful area for screen output of debugging messages would be when selecting circulation rules. This is an area where I have had many libraries submitting bugs that were in reality just circulation rules not set up correctly. I think it would be good to have the GET debug flag choose a level of output. Stuff like circulation rules would be level 1 ( info ). I think you patch looks good, but switching it to log4perl would be better. Many here are suggesting they want to output to the syslog, which log4perl supports. In can output to stderr, syslong, and a log file simultaneously. Kyle
Op 17-09-12 13:48, Kyle Hall schreef:
I think it would be good to have the GET debug flag choose a level of output. Stuff like circulation rules would be level 1 ( info ).
This is not a good thing in production as it runs the risk of causing security issues by leaking information. If you were going to do it, I reckon enabling something that caused an overlay of some sort on the page that got the messages written to it would be neat, similar to what plack can do. Also, using an existing library is good. It always looks easy and useful to make your own logger, and everyone has at some point, but in general it's a bad idea as the existing ones can probably do the job better. Even if it means writing a plugin or something. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
On 2012-09-17, at 11:48 PM, Kyle Hall wrote:
The big question I have is: Would being able to output debug messages to the web browser be useful enough to make it work implement?
Currently, the Koha logs are very verbose. If we replace all occurrences of 'warn' to use this module and display them to the web browser, the users will be unhappy. I think it is preferable to manage and encapsule potential errors and display an adapted message for each them. Yes I know it is a big work :-/ But simply it could be possible to display only error message. For developpers I think it is not very useful to display debug messages (just my opinion).
Could you test and sign-off my patch if you agree with the Koha::Utils::Logger module and/or propose changes ?
I think the option of outputting too much to the screen is better than not outputting enough. I think the one really useful area for screen output of debugging messages would be when selecting circulation rules. This is an area where I have had many libraries submitting bugs that were in reality just circulation rules not set up correctly. I think it would be good to have the GET debug flag choose a level of output. Stuff like circulation rules would be level 1 ( info ).
I think you patch looks good,
then sign-off...
but switching it to log4perl would be better.
...and send a follow-up patch
On 2012-09-15, at 2:16 AM, Jonathan Druart wrote:
Hi Kyle,
I already launched this discussion and proposed a patch (Bug 8190). It is waiting for a signoff for 2 months...
Please have a look before starting a development :)
hi Jonathan, i signed-off on this, (just some little perl-critic warnings)
Am 14.09.12 16:09, schrieb Kyle Hall:
Hey all,
I've been thinking about this for quite a while now. I feel that Koha would benefit greatly from having a traditional logger, rather than relying on warn's being written to the apache logs. This would give us many benefits. First, we would be able to log everything to one or more standard files, regardless of whether that file was running under apache or not. Second, we could implement standard logging levels ( trace, debug, info, warn, error, fatal ). It would also help us debug ajax-related issues where child processes no longer write to the apache module.
The Catalyst Perl framework has been a primary inspiration for this. We could have C4::Context->log->debug('this is a test message'); Our logger would detect the current error level and output or ignore the message accordingly.
My research has lead me to Log4perl, which seems to be an outstanding logging module. It can even capture existing warns and dies. It would work perfectly except for one scenario I was hoping for.
I have been thinking it might be useful for developers and even just experienced Koha users of the we could dump all the log output to the webpage. So mainpage.pl?debug=1 would not only enable debug messages, but then append all those debug messages to the bottom of the returned html. Log4perl is meant to be used as a singleton, so even if we can get the logged message back out, it would have messages from other koha scripts that were running concertedly. If I am incorrect, please let me know!
So the options are: 1) Forget about the dump-to-screen feature, and just use Log4perl 2) Write our own logger from scratch with all these features, largely duplicating the effor of Log4perl and other loggers 3) Write our own logger that can handle the dump-to-screen feature, but use Log4perl within Koha::Logger for all other logging.
Another idea, implement dbi tracing to allow dumping of all queries to the screen and log. Also, Perhaps the dump-to-screen could create a popup window instead of appending to the bottom of the screen.
I generally agree to the idea, I would, however, favour a solution that uses the Unix sylog mechanism under the hood. - Marc
I'm looking for any and all opinions or ideas on this subject.
Thanks! Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Op 14-09-12 18:20, Marc Balmer schreef:
I generally agree to the idea, I would, however, favour a solution that uses the Unix sylog mechanism under the hood.
This would also be my preference, it would allow for things like centralisation of logs, easy logrotates, and all the other goodness that comes with using syslog. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
participants (5)
-
Jonathan Druart -
Kyle Hall -
Marc Balmer -
Mason James -
Robin Sheat