[
https://issues.apache.org/jira/browse/SOLR-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589690#comment-16589690
]
Erick Erickson commented on SOLR-11934:
---------------------------------------
OK, circling back around to this, I'm finally breaking some time loose. I
looked at a few more logs and here's the list (it includes what's above) of
classes that produce, by far, the largest percentage of messages:
org.apache.solr.update.DirectUpdateHandler2;
org.apache.solr.update.processor.LogUpdateProcessor;
org.apache.solr.servlet.HttpSolrCall; (not sure how this one crept in here,
may be peculiar to that client using HTTP connections)
org.apache.solr.core.SolrCore;
org.apache.solr.update.SolrIndexWriter;
org.apache.solr.search.SolrIndexSearcher;
So here's what I'm thinking now that there's a controlled number of logging
config files.
Rather than debate forever about when a message is a WARN or INFO or DEBUG or
whatever, what about enabling/disabling specific class logging levels? Either
* Move the frequent messages to DEBUG with a comment in the config about how
to enable DEBUG level for these classes
* change the configs to set the level of these classes to WARN as a default
I like the latter best for two reasons:
* it doesn't make someone have to dig around for "how to I change the config
for these classes?" The answer is "either comment out the specific class levels
in log4j2.xml or change WARN to INFO".
* it has the least amount of code changes. Well, none really just config
changes.
As part of SOLR-11884 I'll be looking at pretty much all the log messages
anyway and _may_ change some of the levels we log some messages at, but that's
a tale for another day and we can argue about them there ;)
> 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: [email protected]
For additional commands, e-mail: [email protected]
