[web2py] Re: Log tickets
I agree. In the future I can see myself wanting to using something like this. Do want /Daniel
[web2py] Re: Log tickets
I think this would be a great addition. The major pro is that you can redirect the information about new tickets to a place where you already have other logging. For instance, we run web2py in apache2 via wsgi, and we already have several apache mods for other things. The sysadmins already know where to look for errors and we already have alarms in place that are triggered by certain messages in the apache error log. However, I do not like the idea of splitting a ticket into multiple log calls. If you like to have it that way you could always add your own log Formatter that does splitting. I would rather see that the ticket info was logged as a single string. Anders
Re: [web2py] Re: Log tickets
On Feb 1, 2011, at 11:38 AM, Massimo Di Pierro wrote:
>
> I'd like to hear more pros and cons about this from other users.
Good idea.
I'd make one change, though: define a separate ticket logger:
logger_ticket = logging.getLogger("web2py.ticket")
...and use it for this purpose. Perhaps add an explicit entry for it in
logging.example.conf. That way ticket logging can be controlled independently
of "real" web2py errors.
Is there a reason perhaps to log a little more information? The application, at
least? That won't always be obvious from the traceback. Also the request URL is
living somewhere in request.env (request.env.request_uri IIRC); might be useful.
>
> massimo
>
> On Feb 1, 11:19 am, Jim Karsten wrote:
>> On my development server, I log errors to syslog so they are
>> accessible from a single location. Web2py tickets present a problem
>> since they are not logged. I could configure syslog to access errors
>> from the ticket error file, but it contains more information than I
>> need and the text isn't in a suitable format.
>>
>> I added three lines to the RestrictedError class log() method in gluon/
>> restricted.py. The traceback message of a ticket is then logged quite
>> nicely.
>>
>> def log(self, request):
>> ...
>>
>> ticket_storage = TicketStorage(db=request.tickets_db)
>> ticket_storage.store(request, f, d)
>> => for line in str(self.traceback).split("\n"):
>> => if len(line.strip()) > 1:
>> => logger.error(line.strip())
>> return '%s/%s' % (a, f)
>> except:
>> logger.error(self.traceback)
>> return None
>>
>> Is there any interest in adding that to the source code?
>>
>> Also, when I first tested this, I copied the
>> logger.error(self.traceback) line from the except clause to log the
>> ticket message. It only logged the first line. The message logged is:
>> "Traceback (most recent call last):" which isn't much use. Possibly a
>> for loop similar to what I used above would improve that.
>>
>> Regards,
>> Jim Karsten
[web2py] Re: Log tickets
I'd like to hear more pros and cons about this from other users.
massimo
On Feb 1, 11:19 am, Jim Karsten wrote:
> On my development server, I log errors to syslog so they are
> accessible from a single location. Web2py tickets present a problem
> since they are not logged. I could configure syslog to access errors
> from the ticket error file, but it contains more information than I
> need and the text isn't in a suitable format.
>
> I added three lines to the RestrictedError class log() method in gluon/
> restricted.py. The traceback message of a ticket is then logged quite
> nicely.
>
> def log(self, request):
> ...
>
> ticket_storage = TicketStorage(db=request.tickets_db)
> ticket_storage.store(request, f, d)
> => for line in str(self.traceback).split("\n"):
> => if len(line.strip()) > 1:
> => logger.error(line.strip())
> return '%s/%s' % (a, f)
> except:
> logger.error(self.traceback)
> return None
>
> Is there any interest in adding that to the source code?
>
> Also, when I first tested this, I copied the
> logger.error(self.traceback) line from the except clause to log the
> ticket message. It only logged the first line. The message logged is:
> "Traceback (most recent call last):" which isn't much use. Possibly a
> for loop similar to what I used above would improve that.
>
> Regards,
> Jim Karsten
