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
