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&–&T676æG&æ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âFWbÖ†VÇ676æ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
