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 > >> @spyced > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
