Re: [AOLSERVER] Filtering logs
The thought never occurred to us that logging on a production server would be so extensive that it would require such filtering by severity. Usually production servers should only spew out the most interesting messages: Warning, Error and Fatal. If you're routinely logging on a production server with Notice you might want to reconsider the idea of development vs. production and how you report your server's activity. Just a thought. Kris
Re: [AOLSERVER] Filtering logs
Another option is to preface important log messages with a particular string. For example, I use ERROR - some message and EXCEPTION - some message for logging - old habit. thomas -Original Message- From: Kriston Rehberg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 11:08 AM To: [EMAIL PROTECTED] Subject: Re: [AOLSERVER] Filtering logs The thought never occurred to us that logging on a production server would be so extensive that it would require such filtering by severity. Usually production servers should only spew out the most interesting messages: Warning, Error and Fatal. If you're routinely logging on a production server with Notice you might want to reconsider the idea of development vs. production and how you report your server's activity. Just a thought. Kris
Re: [AOLSERVER] Filtering logs
My own experience is that logging is essential, even in production. We log everything - SQL commands, debug logs we've inserted... everything. The problem is that when a customer writes in and says I can't login to your web site, without logs you are left with telling them clear your cache and try again. I can't even count the number of times a screwed-up browser has sent us total nonsense and confused our scripts. In a perfect world, everything would be bullet-proof before making it available to customers, but I think the very fast cycle times for web development in smaller companies make that impossible. Our server logs (not access logs - server logs) are 90MB a day, and we have even gone so far as to log the start and end of every hit before, without a noticeable effect on performance. Jim The thought never occurred to us that logging on a production server would be so extensive that it would require such filtering by severity. Usually production servers should only spew out the most interesting messages: Warning, Error and Fatal. If you're routinely logging on a production server with Notice you might want to reconsider the idea of development vs. production and how you report your server's activity. Just a thought. Kris
[AOLSERVER] Filtering logs
All, Is there any way, currently, to filter ns_log output? The current aolserver docs include information about the modlog proc, which was used to generate module-based logs. It included filtering based on severity. This apparently has been deprecated, as modlog.tcl only contains the cryptic remark ##modlog is gone. The current logging facilities don't seem to have any capability to filter the logs, even by severity. This is especially annoying, because as it stands aolserver logs all database activity (with no option to suppress.) This can make debugging startup procedures, which often occur among a flood of preliminary database activity, especially cumbersome. Is there any standard solution, other than slogging through miles of irrelevant logs, or modifying the server? Thanks, Sean
Re: [AOLSERVER] Filtering logs
Sean, This is especially annoying, because as it stands aolserver logs all database activity (with no option to suppress.) I know this doesn't answer the larger question but you can turn off database logging by setting verbose to off for a given db pool. I did this to avoid the flood of db logging we have currently. Jeff -Original Message- From: Sean Owen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 17, 2001 4:15 PM To: [EMAIL PROTECTED] Subject: [AOLSERVER] Filtering logs All, Is there any way, currently, to filter ns_log output? The current aolserver docs include information about the modlog proc, which was used to generate module-based logs. It included filtering based on severity. This apparently has been deprecated, as modlog.tcl only contains the cryptic remark ##modlog is gone. The current logging facilities don't seem to have any capability to filter the logs, even by severity. This is especially annoying, because as it stands aolserver logs all database activity (with no option to suppress.) This can make debugging startup procedures, which often occur among a flood of preliminary database activity, especially cumbersome. Is there any standard solution, other than slogging through miles of irrelevant logs, or modifying the server? Thanks, Sean
