[
https://issues.apache.org/jira/browse/KAFKA-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967297#comment-13967297
]
Guozhang Wang commented on KAFKA-1352:
--------------------------------------
We have this describe() function that have the details flag as the new
implementation of RequestOrResponse.toString, but the problem is that we only
set it to false when we print the state-change-log in debug mode.
So here are my proposal for the logging convention additional to
http://kafka.apache.org/coding-guide.html:
1. Always keep log entries single-lined except:
a. RequestOrResponse.toString(details = true) for produce/fetch requests.
b. Lists of topic/partitions to consume on startup/rebalance in
ZookeeperConsumerConnector.
c. .. (this list could grow, but we need to keep track)
----------------
I am also proposing the following exception handling conventions (copied from
the RB):
1. No stack trace below WARN
2. For WARN,
a) Print stack trace when calling library functions (i.e. non-kafka functions)
or we captured Throwable which could be various exception types.
b) Print e.toSting (e.Class.Name + ":" + e.Message) when we captured Throwable
but we could be sure about possible exception types.
c) Only print e.Message otherwise.
3. For ERROR, always print stack trace.
Also there are some mis-use of swallow, which should only be used when "we do
not throw more exceptions but just log in with stack trace in whole", but not
"when we really do not care if it throw any exceptions".
1. Avoid capture Throwable as less as possible. Only capture Throwable when 1)
calling a library function whose throwable exceptions are not defined clearly,
or 2) if we REALLY want to "swallow" any exceptions thrown. In the second case,
we should log not any exceptions thrown.
2. For our own scala classes, specify possible checked kafka exceptions in the
comments as often as possible (for java classes do that in signatures). When
catching exceptions, case-enumerate all possible types and log
Exception.getMessage.
3. When log with WARN or below, do not include the stack trace; when log with
ERROR, only log the stack trace if we are catching Throwable or any runtime
exceptions.
4. Only re-throw the same/another exception type after logging when the
function needs a return value and the thrown exception cause it to not able to
return any. In this case, throw a specific exception and capture it the caller
without further double-logging.
> Reduce logging on the server
> ----------------------------
>
> Key: KAFKA-1352
> URL: https://issues.apache.org/jira/browse/KAFKA-1352
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.8.0, 0.8.1
> Reporter: Neha Narkhede
> Assignee: Ivan Lyutov
> Labels: newbie, usability
> Fix For: 0.8.2
>
> Attachments: KAFKA-1352.patch, KAFKA-1352.patch,
> KAFKA-1352_2014-04-04_21:20:31.patch
>
>
> We have excessive logging in the server, making the logs unreadable and also
> affecting the performance of the server in practice. We need to clean the
> logs to address these issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
