Consistent logging across modules
Jeremy - July 27, 2009 - 13:44
| Project: | Spam |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Jump to:
Description
By default, the Spam module logs "Important" messages, which should include major actions such as blocking a comment, etc. However, when the module is configured to log important messages, nothing at all is showing up in my spam log.
When I drop the log level to debug, I do see debug logs, hence this apparently only affects some logs.
#1
It looks like log levels are working fine, but the default log mode doesn't really log much. I changed one log message, committed here:
http://drupal.org/cvs?commit=247156
#2
Yeah, I wasn't able to replicate this one. I thought the sparse default logging was intentional, though I did think it was perhaps too far on the light side. Maybe we should be coming up with a list of use cases that we'd want logged by default ([content] logged as spam, moderated spam approved, etc), and from there change the code to match? Better than going piecemeal with it, I think.
#3
Sure, sounds like a plan. I reviewed the log levels when reviewing this issue and decided I liked the current settings -- what further logs do you feel should be showing up?
#4
I started going through all spam_log calls and making a list of what I thought should be upped, realized that some of it maybe needed to be downgraded, and then realized what the real issue was: it's not really the levels of logging, it's that they're not consistently applied. For example, Bayesian and custom will return some final results as SPAM_VERBOSE, while duplicate and custom won't (and surbl won't return a success at all, it seems).
So I was thinking maybe it was better to propose some guidelines for logging in general that all modules should follow, and then we can go through each and modify them to comply with those guidelines.
My first pass:
SPAM_LOG
* content marked as spam by spam.module, with final score
* content marked as spam or not-spam by user
* any "this is never supposed to happen" errors (as they're probably indicative of a bug)
SPAM_VERBOSE
* content marked as not-spam by spam module, with final score
* individual filters indicating spam, with scores
SPAM_DEBUG
* individual filters calculating all content score
* any internal processes that would be handy to expose for debugging
#5
Yes, I like this. There may be some missing actions, but we can add them as we find them when auditing the code.
We should create a DEVELOPER.txt file (or whatever name you prefer) and put these guidelines in there, and any others we agree upon as time goes by.