Hi, Another point I want to mention. Another reason we separate the files is that they can then use separate log rolling policies. A verbose debug log no longer rolls the INFO level system.log.
Ariel On Tue, Mar 20, 2018, at 12:19 PM, Ariel Weisberg 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
