On Fri, Aug 15, 2014 at 8:50 AM, Aaron T. Myers a...@cloudera.com wrote:
Not necessarily opposed to switching logging frameworks, but I believe we
can actually support async logging with today's logging system if we wanted
to, e.g. as was done for the HDFS audit logger in this JIRA:
The block state change logs are indeed too noisy at INFO and I've not found
them useful when troubleshooting. Just filed HDFS-6860 to fix that.
This is orthogal to SLF4J migration however moving to SLF4J would help ease
the transition to Log4j 2.
Thanks for the pointer to HDFS-5421 Aaron,
On 15 August 2014 17:20, Karthik Kambatla ka...@cloudera.com wrote:
However, IMO we already log too much at INFO level (particularly YARN).
Logging more at DEBUG level and lowering the overhead of enabling DEBUG
logging is preferable.
+1
This is the log4j properties file I've adopted for
moving to SLF4J as an API is independent —it's just a better API for
logging than commons-logging, was already a dependency and doesn't force
anyone to switch to a new log back end.
On 15 August 2014 03:34, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com wrote:
Hi,
Steve has started discussion
Using asynchronous loggers for improved performance sounds reasonable.
However, IMO we already log too much at INFO level (particularly YARN).
Logging more at DEBUG level and lowering the overhead of enabling DEBUG
logging is preferable.
One concern is the defaults. Based on what I read on the
Hi,
Steve has started discussion titled use SLF4J APIs in new modules?
as a related topic.
http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201404.mbox/%3cca+4kjvv_9cmmtdqzcgzy-chslyb1wkgdunxs7wrheslwbuh...@mail.gmail.com%3E
It sounds good to me to use asynchronous logging when we log
I don't recall whether this was discussed before.
I often find our INFO logging to be too sparse for useful diagnosis. A high
performance logging framework will encourage us to log more. Specifically,
Asynchronous Loggers look interesting.
