Policy for log levels? Give each non-DEBUG output an identifier. #7430
Replies: 4 comments
-
hi Johannes,
hm, this might easily spam the log file - I think NOTICE is ok here.
bot sure if this helps - I think it would be better to improve the code and use the correct log levels. here's some additional input on this topic: https://sematext.com/blog/logging-levels/ |
Beta Was this translation helpful? Give feedback.
-
syncroton PR: tine20/syncroton#30 |
Beta Was this translation helpful? Give feedback.
-
Thanks for the patches, which I've implemented manually in my current production installation. What do you think about |
Beta Was this translation helpful? Give feedback.
-
yup, already fixed that: https://github.com/tine20/tine20/blob/main/tine20/Felamimail/Controller/Message.php#L1340 (0c13177). sorry for the slow updates - the automatic merge was broken and I just fixed it 😉 |
Beta Was this translation helpful? Give feedback.
-
I recently started to use DBLogger, not in DEBUG of course. However, I haven't found a useful way to monitor my installation. It made me wondering, what the policy for log levels LIKE NOTICE, WARN, ERR and CRIT are...
Some examples of what I have as much in my logs that logging is rendered useless:
Tinebase_Mail::decodingErrorHandler::611 stream_get_contents(): iconv stream filter ("utf-8"=>"utf-8"): invalid multibyte sequence in /tine/vendor/zendframework/zendframework1/library/Zend/Mime/Part.php::346 (2)
(max. DEBUG, seems developer related)Felamimail_Controller_Message::_updateFolderCounts::1337 folder counters dont match => refresh counters
(expected: NOTICE)Syncroton_Command_Sync::handle::249 invalid synckey 4744 provided
(expected: NOTICE max. better DEBUG)Syncroton_Server::_handlePost::110 command not supported: ResolveRecipients
(expected: NOTICE max. better DEBUG)Syncroton_Server::_handlePost::166 exception message: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction, query was: INSERT INTO tine20_acsync_content (device_id, folder_id, contentid, creation_time, creation_synckey, id) VALUES (?, ?, ?, ?, ?, ?)
(expected: DEBUG)It seems that everything stemming from Syncroton_Server class is CRIT automatically.
On the other hand, failed login attempts are only NOTICE but I would expect them to be WARN at least?!
Idea: It would be helpful to give each Log Message an unique identifier. The logging facilities could have (beside the filter) a list of "always" and "never" to log ids.
Beta Was this translation helpful? Give feedback.
All reactions