That's a good question. At this point ¯\_(ツ)_/¯
On Tue, Mar 20, 2018 at 4:42 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > Hi, > > That's good to hear. > > What's the difference between DEBUG and TRACE? Obviously we decide > ourselves. I don't have a good answer because right now we are in the > process of eliminating the distinction we used to make which is that DEBUG > is safe to turn on in production and TRACE is not. > > Ariel > > On Tue, Mar 20, 2018, at 12:36 PM, Alexander Dejanovski wrote: > > 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 > > --------------------------------------------------------------------- > 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
