You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@storm.apache.org by Derek Dagit <de...@yahoo-inc.com> on 2015/02/13 23:30:10 UTC
Seeking opinions on moving storm from logback to log4j 2.x
In the past, the storm project used log4j version 1.x as its loggingframework.
Around the time of 0.9.0, before moving to Apache, the project moved to using
logback for two reasons:
1) logback supported rolling log files, which was critical for managing disk
space usage.
2) logback supported dynamically updating its logging configuration files.
Recently, we have met a new requirement that we send logs to a syslog daemon
for further processing. The syslog daemon has a particular format described in
RFC5424, and using it basically means that things like stack traces have
newlines properly contained within a single logging event, instead of written
raw into the log making extra parsing necessary.
log4j version 2.x (or log4j2) has the following:
1) rolling log files with size, duration, and date-based triggers that can be
composed together
2) dynamic log updates that do not cause log messages to be dropped while the
new config is loaded
3) a Syslog appender that is compliant with RFC5424.
This would change the slf4j binding from logback to log4j, but it would not
change the slf4j API. Topology code that uses the slf4j logging library would
not need to change and would continue working as normal.
I would like to hear users' opinions on whether it might be good to switch
from logback to log4j2 based on the above, or else hear about alternative
solutions to the RFC5424 requirement that works well.
--
Derek
Re: Seeking opinions on moving storm from logback to log4j 2.x
Posted by Derek Dagit <de...@yahoo-inc.com>.
> I would question the choice to use any logging implementation at all
This is a fair point, and we could go that route. It would be a bigger change
and would change the way storm would be deployed. Right now, the scope of the
change I was focusing on was just to add a proper way to handle syslog while
changing as little of the functionality as possible.
If we want make the logging implementation up to the user, we would probably
want to handle that it its own JIRA issue.
--
Derek
________________________________
From: Tim Molter <ti...@gmail.com>
To: user@storm.apache.org
Sent: Saturday, February 21, 2015 5:18 AM
Subject: Re: Seeking opinions on moving storm from logback to log4j 2.x
I always thought the point of using slf4j was to give final control to
the end user of a library to pick and configure the specific logging
implementation. I would question the choice to use any logging
implementation at all, but then again, I'm not an expert in Storm at
all, just an outside observer. However, if you need a specific
functionality for syslogging that logback doesn't support, it seems to
me to be an issue with the way Storm handles logging.
I've seen this problem in Dropwizard too. They hard code an
implementation of logback and don't let the end user configure logging
themselves. I think their thinking is that they don't want to
"inconvenience" the end user to have to figure out logging for
themselves. The tradeoff, however, is that the end user is forced to
accept and work within that hard coded logging framework.
That's just my two cents from an observer's point of view. I have no
idea why Storm's logging is how it is or whether it's "good" or "bad".
~Tim
On 2015_02_20 8:45 PM, Derek Dagit wrote:
> Hi all,
>
> Following up, do any users on the list have thoughts about the switch?
>
> Good/Bad/Indifferent?
>
>
>
Re: Seeking opinions on moving storm from logback to log4j 2.x
Posted by Tim Molter <ti...@gmail.com>.
I always thought the point of using slf4j was to give final control to
the end user of a library to pick and configure the specific logging
implementation. I would question the choice to use any logging
implementation at all, but then again, I'm not an expert in Storm at
all, just an outside observer. However, if you need a specific
functionality for syslogging that logback doesn't support, it seems to
me to be an issue with the way Storm handles logging.
I've seen this problem in Dropwizard too. They hard code an
implementation of logback and don't let the end user configure logging
themselves. I think their thinking is that they don't want to
"inconvenience" the end user to have to figure out logging for
themselves. The tradeoff, however, is that the end user is forced to
accept and work within that hard coded logging framework.
That's just my two cents from an observer's point of view. I have no
idea why Storm's logging is how it is or whether it's "good" or "bad".
~Tim
On 2015_02_20 8:45 PM, Derek Dagit wrote:
> Hi all,
>
> Following up, do any users on the list have thoughts about the switch?
>
> Good/Bad/Indifferent?
>
>
>
Re: Seeking opinions on moving storm from logback to log4j 2.x
Posted by Derek Dagit <de...@yahoo-inc.com>.
Hi all,
Following up, do any users on the list have thoughts about the switch?
Good/Bad/Indifferent?
--
Derek
----- Original Message -----
From: Derek Dagit <de...@yahoo-inc.com>
To: User <us...@storm.apache.org>
Cc:
Sent: Friday, February 13, 2015 4:30 PM
Subject: Seeking opinions on moving storm from logback to log4j 2.x
In the past, the storm project used log4j version 1.x as its loggingframework.
Around the time of 0.9.0, before moving to Apache, the project moved to using
logback for two reasons:
1) logback supported rolling log files, which was critical for managing disk
space usage.
2) logback supported dynamically updating its logging configuration files.
Recently, we have met a new requirement that we send logs to a syslog daemon
for further processing. The syslog daemon has a particular format described in
RFC5424, and using it basically means that things like stack traces have
newlines properly contained within a single logging event, instead of written
raw into the log making extra parsing necessary.
log4j version 2.x (or log4j2) has the following:
1) rolling log files with size, duration, and date-based triggers that can be
composed together
2) dynamic log updates that do not cause log messages to be dropped while the
new config is loaded
3) a Syslog appender that is compliant with RFC5424.
This would change the slf4j binding from logback to log4j, but it would not
change the slf4j API. Topology code that uses the slf4j logging library would
not need to change and would continue working as normal.
I would like to hear users' opinions on whether it might be good to switch
from logback to log4j2 based on the above, or else hear about alternative
solutions to the RFC5424 requirement that works well.
--
Derek