Ariel can we move discussion to the ticket now that we have one open? That way we can keep all thoughts in one place. Thanks. https://issues.apache.org/jira/browse/CASSANDRA-14326
> On Mar 20, 2018, at 12: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 >