cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10241) Keep a separate production debug log for troubleshooting
Date Wed, 09 Sep 2015 22:44:46 GMT


Paulo Motta commented on CASSANDRA-10241:

bq. Or is there more to it than that?

My initial patch didn't populate {{debug.log}} at all, unless the operator manually set the
{{TROUBLESHOOTING_LEVEL}} property to {{DEBUG}} or {{TRACE}}, on {{logback.xml}}.

bq. If it's not on be default how will we know if it is safe to turn on in production?

Advanced operators and consultants could start using it by manually turning it on, and if
no issues found after a few versions, then we could enabled it by default later.

bq. This isn't going to be trace/debug for everything right? 

Right, only on the aforementioned packages.

I don't have strong feelings about this, so I'm fine with either way. I think that with the
{{AsyncAppender}} we shouldn't have significant impact with debug logging on by default.

> Keep a separate production debug log for troubleshooting
> --------------------------------------------------------
>                 Key: CASSANDRA-10241
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Config
>            Reporter: Jonathan Ellis
>            Assignee: Paulo Motta
>             Fix For: 2.1.x, 2.2.x, 3.0.x
> [~aweisberg] had the suggestion to keep a separate debug log for aid in troubleshooting,
not intended for regular human consumption but where we can log things that might help if
something goes wrong.

This message was sent by Atlassian JIRA

View raw message