It seems to me the power user who wants to eek out that last bit of performance can do so. It also seems like the user who doesn't even know about that is the exact kind of user that's going to need the debug log in the future.
On Sun, Mar 18, 2018 at 1:45 PM, Michael Kjellman <kjell...@apple.com> wrote: > i’m not trying to get into a fight here jeremiah. and this will be my last > reply on this as i’ve made my opinion pretty clear. but ask yourself: would > you run c* in idea debugger and then do performance testing? no. because > it’s a DEBUGger. > > > On Mar 18, 2018, at 11:43 AM, J. D. Jordan <jeremiah.jor...@gmail.com> > wrote: > > > > If there are some log messages you think should be improved to make them > more useful please do so. Saying things are “crap” is not productive. > > > > I have seen having the extra information from the debug.log be very > helpful in debugging production issues after the fact on operational > clusters many times. > > > > Also if you think there are things logged at DEBUG, since it was cleaned > it up, that are not useful, then please improve them or change their > logging level. > > > > You are also free to change the logging level on clusters you run if you > don’t want the extra information. > > > > And again we are only talking about versions where DEBUG has been > cleaned up. When running 2.1 or earlier, yes there is a ton of stuff at > DEBUG and you would not want that on by default, even asynchronously. > > > > It is up to reviewers and committers to understand the impact of and > rules around the use of different log levels. Said reviewers and committers > should teach new contributors those rules during reviews if they are > violated. > > > > -Jeremiah > > > >> On Mar 18, 2018, at 2:31 PM, Michael Kjellman <kjell...@apple.com> > wrote: > >> > >> what really baffles me with this entire thing is as a project we > don’t even log things like partition keys along with the tombstone > overwhelming or batch to large log messages.. this would immediately be > helpful to thousands and thousands of people... yet somehow we think it’s > okay to log tons of crap at debug to users drives that will shorten their > ssds and objectively reduce the performance of the actual database due to > logging overhead for some possible day in the future when we might need > them to debug a problem really we should have figured out and reproduced > ourselves in the first place. > >> > >>> On Mar 18, 2018, at 11:24 AM, Michael Kjellman <kjell...@apple.com> > wrote: > >>> > >>> it’s too easy to make a regression there. and does anyone even have > a splunk (or equivalent) infrastructure to actually keep debug logs around > for a long enough retention period to even have them be helpful? > >>> > >>> again: this is something engineers for the project want. it’s not in > the best interest for our users. > >>> > >>> > >>>> 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 > >>> > >> ТÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÐÐ¥Fò > Vç7V'67&–&R RÖÖ –â FWb×Vç7V'67&–&T 6 76 æG& æ 6†Ræ÷&pФf÷" FF—F–öæ  > 6öÖÖ æG2 RÖÖ –â FWbÖ†VÇ 6 76 æG& æ 6†Ræ÷&pÐ Ð > > > > --------------------------------------------------------------------- > > 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 > >
