lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-11934) Visit Solr logging, it's too noisy.
Date Tue, 08 May 2018 20:28:00 GMT

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

Mark Miller commented on SOLR-11934:
------------------------------------

I think if we turn this off by default and document how to easily turn it back on, we don't
have a problem. We never have promised back compat with our logging. What's more scary in
SOLR-12055 is that you may think things are working as you expect for what can be a very sensitive
function when they are not. If you actually count on certain logging from an issue like this
though, when you upgrade you have to understand what logging exists for that version and how
your tools work with what you expect - but at least you can count on the logging you as you
would expect to if you see it in testing.

> Visit Solr logging, it's too noisy.
> -----------------------------------
>
>                 Key: SOLR-11934
>                 URL: https://issues.apache.org/jira/browse/SOLR-11934
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Major
>
> I think we have way too much INFO level logging. Or, perhaps more correctly, Solr logging
needs to be examined and messages logged at an appropriate level.
> We log every update at an INFO level for instance. But I think we log LIR at INFO as
well. As a sysadmin I don't care to have my logs polluted with a message for every update,
but if I'm trying to keep my system healthy I want to see LIR messages and try to understand
why.
> Plus, in large installations logging at INFO level is creating a _LOT_ of files.
> What I want to discuss on this JIRA is
> 1> What kinds of messages do we want log at WARN, INFO, DEBUG, and TRACE levels?
> 2> Who's the audience at each level? For a running system that's functioning, sysops
folks would really like WARN messages that mean something need attention for instance. If
I'm troubleshooting should I turn on INFO? DEBUG? TRACE?
> So let's say we get some kind of agreement as to the above. Then I propose three things
> 1> Someone (and probably me but all help gratefully accepted) needs to go through
our logging and assign appropriate levels. This will take quite a while, I intend to work
on it in small chunks.
> 2> Actually answer whether unnecessary objects are created when something like log.info("whatever
{}", someObjectOrMethodCall); is invoked. Is this independent on the logging implementation
used? The SLF4J and log4j seem a bit contradictory.
> 3> Maybe regularize log, logger, LOG as variable names, but that's a nit.
> As a tactical approach, I suggest we tag each LoggerFactory.getLogger in files we work
on with //SOLR-(whatever number is assigned when I create this). We can remove them all later,
but since I expect to approach this piecemeal it'd be nice to keep track of which files have
been done already.
> Finally, I really really really don't want to do this all at once. There are 5-6 thousand
log messages. Even at 1,000 a week that's 6 weeks, even starting now it would probably span
the 7.3 release.
> This will probably be an umbrella issue so we can keep all the commits straight and people
can volunteer to "fix the files in core" as a separate piece of work (hint).
> There are several existing JIRAs about logging in general, let's link them in here as
well.
> Let the discussion begin!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message