[
https://issues.apache.org/jira/browse/STORM-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933978#comment-14933978
]
ASF GitHub Bot commented on STORM-412:
--------------------------------------
GitHub user kishorvpatil opened a pull request:
https://github.com/apache/storm/pull/766
[STORM-412] Allow users to modify logging levels of running topologies
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kishorvpatil/incubator-storm STORM-412
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/storm/pull/766.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #766
----
commit d13cfe2dc9beda8fc4fda6fa6536d87b9ce514a1
Author: Kishor Patil <[email protected]>
Date: 2015-09-24T14:22:37Z
Adding thrift changes for Dynamic Logging
commit 250ab1132e5cb26ac9cf1af5c47cbaf98390923a
Author: Kishor Patil <[email protected]>
Date: 2015-09-25T20:00:45Z
Adding Dynamic Logger to UI, cli and supervisors
commit 087f08ea314df2055bce61abbb54cc7443da41a9
Author: Alessandro Bellina <[email protected]>
Date: 2015-04-10T17:07:22Z
Documentation brief for dynamic log level settings feature
----
> Allow users to modify logging levels of running topologies.
> -----------------------------------------------------------
>
> Key: STORM-412
> URL: https://issues.apache.org/jira/browse/STORM-412
> Project: Apache Storm
> Issue Type: Improvement
> Reporter: Robert Joseph Evans
>
> It really would be great to be able to turn on debug logging for different
> parts of an already running topology, and then turn them off again later. Or
> even better if they could turn it on for just a few workers, so we don't
> flood the logs for a very large topology.
> logback already has the ability to refresh its config periodically so really
> what we needs is some code to generate logback configs on the fly based off
> of the currently desired user settings, and API to modify those dynamically,
> and a way to distribute those configs/settings to the supervisors. I am not
> too concerned about persisting these settings long term. If nimbus goes down
> and they reset back to default, I think that would be OK.
> For the distribution of the configs I think it would be best to setup a
> RESTful web service that is a part of nimbus. logback already supports using
> http to download configs. The service could use the cached logging settings
> for a given topology, or individual worker and the URL of the request to
> generate a logging config on the fly for a specific worker. As for the APIs
> I think a few new thrift calls to nimbus would be good, a command line tool,
> and possibly something on the UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
