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

Reply via email to