hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12396) Document suggested use of log levels in dev guide
Date Fri, 31 Oct 2014 17:33:34 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192133#comment-14192133
] 

stack commented on HBASE-12396:
-------------------------------

Nice one Sean. Kept meaning to do this.  Here's another few items to throw on the list.

+ Logs should be info-dense (don't just write 'starting', but rather 'starting ...' and a
listing of the config the service was started with).
+ Don't have two log lines where one would do.
+ Logs should be absent repetition and no need of verbiage that is obvious from context.
++ For example, don't write 'opening region xyz' when the context is the RegionOpenHandler
+ Logs should use same vocabulary (to be published) everywhere and the same format when referring
to entities throughout; it makes the logs greppable.
++ We should not log an edits sequenceid with the label sequenceid in one location, seqid
in another, and id somewhere else again.
++ We should not log sequenceid=XYZ in one log message and sequenceid: XYZ in another.
++ For example, tracing the history of a region, always refer to it the same when when making
mention in the logs: if we use its encoded name everywhere, then a grep on this will turn
up all mentions

Logs should be digestible, actionable.  They should be so regularized, 'standardized' (as
it is termed in one of the articles noted above by Sean) so that monitoring of logs can be
done by tools and building a tool like http://www.ymc.ch/en/hbase-split-visualisation-introducing-hannibal
is easy-to-do and continues to work across versions (you shouldn't need to install hannibal
to get a historic, cluster-wide view on compactions/flushes -- but that is another issue).

I like the idea of standard context to dump on DEBUG (one of the articles talks of log4j MDC).
 We had a hack of this where we'd dump context in JSON when stuff was slow.

> Document suggested use of log levels in dev guide
> -------------------------------------------------
>
>                 Key: HBASE-12396
>                 URL: https://issues.apache.org/jira/browse/HBASE-12396
>             Project: HBase
>          Issue Type: Improvement
>          Components: documentation
>            Reporter: Sean Busbey
>            Priority: Minor
>
> Right now we don't provide any guidance on appropriate use of log levels, which leads
to inconsistent use and in some cases exacerbating problems for tests and troubleshooting
(see HBASE-12395). We should add a section on suggested use of log levels to the guide.
> Some related reading
> * [a good ops-focused blog post on levels|http://watchitlater.com/blog/2009/12/logging-guidelines/]
> * [another, focused on devs|http://www.codeproject.com/Articles/42354/The-Art-of-Logging]
> * [guidelines from a user on stackoverflow (that I like)|http://stackoverflow.com/a/2031209]
also has some good discussion.
> * [extended logging discussion with some level use guidelines|http://www.javacodegeeks.com/2011/01/10-tips-proper-application-logging.html]
> * [guidelines for Atlassian devs|https://developer.atlassian.com/display/CONFDEV/Logging+Guidelines]
> * [guidelines for OpenStack devs|https://wiki.openstack.org/wiki/LoggingStandards]
> * [the Kafka dev guide|http://kafka.apache.org/coding-guide.html] has a good section
on their use titled "Logging"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message