If debug log is not a real debug then you should rename it to something else, maybe production.log. Also, I have the impression that all logs in system.log are also contained in debug.log so it's not really useful.
I feel that be moving all verbose debug logs to trace we're losing the good info in debug logs. I've been trying to troubleshoot issues from our QA and debug.log didn't really help me. From my point of view there should be a single log file, defaults to info. Debug level should contain all useful info even if it means lower performance, trace should contain all possible relevant info. If some loggers (or groups) are known to cause huge performance hits they should be disabled by default. -- Jacques-Henri Berthemet -----Original Message----- From: kurt greaves [mailto:k...@instaclustr.com] Sent: Monday, March 19, 2018 3:18 AM To: dev@cassandra.apache.org Subject: Re: Debug logging enabled by default since 2.2 On the same page as Michael here. We disable debug logs in production due to the performance impact. Personally I think if debug logging is necessary for users to use the software we're doing something wrong. Also in my experience, if something doesn't reproduce it will not get fixed. Debug logging helps, but I've never seen a case where an actual bug simply *doesn't* reproduce eventually, and I'm sure if this issue appears debug logging could be enabled after the fact for the relevant classes and eventually it will reoccur and we could solve the problem. I've never seen a user say no to helping debug a problem with patched jars/changes to their system (like logging). I'd much prefer we pushed that harder rather than just saying "Everyone gets debug logging!". I'm also really not sold that debug logging saves the day. To me it mostly just speeds up the identification process, it generally doesn't expose magical information that wasn't available before, you just had to think about it a bit more. In a way the real issue might be that we don’t have nightly performance > runs that would make an accidentally introduced debug statement obvious. This is an issue, but I don't think it's the *real* issue. As already noted, debug logging is for debugging, which normal users shouldn't have to think about when they are just operating the software. We shouldn't risk performance regressions just for developer convenience. On 19 March 2018 at 00:55, Ariel Weisberg <adwei...@fastmail.fm> wrote: > Hi, > > In a way the real issue might be that we don’t have nightly > performance runs that would make an accidentally introduced debug statement > obvious. > > A log statement that runs once or more per read or write should be > easy to spot. I haven’t measured the impact though. And as a bonus by > having this we can spot a variety of performance issues introduced by > all kinds of changes. > > Ariel > > > On Mar 18, 2018, at 3:46 PM, Jeff Jirsa <jji...@gmail.com> wrote: > > > > In Cassandra-10241 I said I was torn on this whole ticket, since > > most > people would end up turning it off if it had a negative impact. You said: > > > > “I'd like to emphasize that we're not talking about turning debug or > trace on for client-generated request paths. There's way too much data > generated and it's unlikely to be useful. > > What we're proposing is enabling debug logging ONLY for cluster > > state > changes like gossip and schema, and infrequent activities like repair. > “ > > > > Clearly there’s a disconnect here - we’ve turned debug logging on > > for > everything and shuffled some stuff to trace, which is a one time > action but is hard to protect against regression. In fact, just > looking at the read callback shows two instances of debug log in the > client request path (exercise for the reader to “git blame”). > > > > Either we can go clean up all the surprises that leaked through, or > > we > can turn off debug and start backing out some of the changes in 10241. > Putting stuff like compaction in the same bucket as digest mismatch > and gossip state doesn’t make life materially better for most people. > > > > > > -- > > Jeff Jirsa > > > > > >> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > >> > >> That really depends on whether you're judicious in deciding what to > >> log > at > >> debug, doesn't it? > >> > >> On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman > >> <kjell...@apple.com> > >> wrote: > >> > >>> +1. this is how it works. > >>> > >>> your computer doesn’t run at debug logging by default. your phone > doesn’t > >>> either. neither does your smart tv. your database can’t be running > >>> at > debug > >>> just because it makes our lives as engineers easier. > >>> > >>>> On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < > >>> a...@thelastpickle.com> wrote: > >>>> > >>>> It's a tiny bit unusual to turn on debug logging for all users by > default > >>>> though, and there should be occasions to turn it on when facing > >>>> issues > >>> that > >>>> you want to debug (if they can be easily reproduced). > >>> > >> > >> > >> > >> -- > >> Jonathan Ellis > >> co-founder, > >> http://www.datastax.com > >> astax.com > >> @spyced > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
