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
