That sounds like a good plan, Alexander! Thanks! Stefan, someone needs to go through all messages being logged at DEBUG and reclassify important ones as INFO. I suggest continuing discussion on specifics on CASSANDRA-14326.
2018-03-20 6:46 GMT-03:00 Stefan Podkowinski <s...@apache.org>: > Are you suggesting to move all messages currently logged via debug() to > info() with the additional marker set, or only particular messages? > > > On 19.03.2018 19:51, Paulo Motta wrote: >> Thanks for the constructive input and feedback! From this discussion >> it seems like overloading the DEBUG level to signify >> async-verbose-INFO on CASSANDRA-10241 is leading to some confusion and >> we should fix this. >> >> However, we cannot simply turn debug.log off as during CASSANDRA-10241 >> some verbose-but-useful-info-logs, such as flush information were >> changed from INFO to DEBUG, and since the patch has been in for nearly >> 3 years it's probably non-revertable. Furthermore, the practice of >> using the DEBUG level for logging non-debug stuff has been in our >> Logging Guidelines >> (https://wiki.apache.org/cassandra/LoggingGuidelines) since then, so >> there is probably useful DEBUG stuff that would need to be turned into >> INFO if we get rid of debug.log. >> >> For this reason I'm more in favor of converting the debug.log into >> async/verbose_system.log as suggested by Jeremiah and use a marker to >> direct these logs (former DEBUG level logs) to that log instead. >> Nevertheless, if the majority prefers to get back to a single >> system.log file and get rid of debug.log/verbose_system.log altogether >> then we would need to go through all log usages and readjust them to >> use the proper logging levels and update our logging guidelines to >> reflect whatever new policy is decided, not only disabling debug.log >> and call it a day. >> >> 2018-03-19 12:02 GMT-03:00 Jeremiah D Jordan <jerem...@datastax.com>: >>> People seem hung up on DEBUG here. The goal of CASSANDRA-10241 was >>> to clean up the system.log so that it a very high “signal” in terms of what >>> was logged >>> to it synchronously, but without reducing the ability of the logs to allow >>> people to >>> solve problems and perform post mortem analysis of issues. We have >>> informational >>> log messages that are very useful to understanding the state of things, >>> like compaction >>> status, repair status, flushing, or the state of gossip in the system that >>> are very useful to >>> operators, but if they are all in the system.log make said log file harder >>> to look over for >>> issues. In 10241 the method chosen for how to keep these log messages >>> around by >>> default, but get them out of the system.log was that these messages were >>> changed from >>> INFO to DEBUG and the new debug.log was created. >>> >>> From the discussion here it seems that many would like to change how this >>> works. Rather >>> than just turning off the debug.log I would propose that we switch to using >>> the SLF4J >>> MARKER[1] ability to move the messages back to INFO but tag them as >>> belonging to >>> the asynchronous_system.log rather than the normal system.log. >>> >>> [1] https://logback.qos.ch/manual/layouts.html#marker >>> <https://logback.qos.ch/manual/layouts.html#marker> >>> https://www.slf4j.org/faq.html#fatal <https://www.slf4j.org/faq.html#fatal> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
