Ariel, the current plan that's discussed on the ticket ( https://issues.apache.org/jira/browse/CASSANDRA-14326) is to maintain the separation and keep the debug.log for "real" DEBUG level logging, which would be disabled by default. A new intermediate marker would be created to have VERBOSE_INFO logging (some current debug loggings must be changed to that new level/marker), which would be enabled by default, and "standard" INFO logging would go to system.log.
I guess in that configuration, some/most TRACE level loggings would then be eligible to graduate to DEBUG...? On Tue, Mar 20, 2018 at 4:19 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > Hi, > > Signal to noise ratio matters for logs. Things that we log at DEBUG aren't > at all bound by constraints of human readability or being particularly > relevant most of the time. I don't want to see most of this stuff unless I > have already not found what I am looking for at INFO and above. > > Can we at least maintain the separation of what is effectively debug > logging (switching to an annotation aside) from INFO and above? I want to > avoid two steps forward one step back. > > Ariel > On Tue, Mar 20, 2018, at 9:23 AM, Paulo Motta wrote: > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- ----------------- Alexander Dejanovski France @alexanderdeja Consultant Apache Cassandra Consulting http://www.thelastpickle.com
