[
https://issues.apache.org/jira/browse/SOLR-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17101784#comment-17101784
]
Erick Erickson commented on SOLR-11934:
---------------------------------------
{quote}I can live with losing the inner details of commit but need that one
SolrIndexSearcher for opening it. We agree on this I think.
{quote}
It Depends (tm) on how valuable warmup times would be. The log message in
SolrIndexSearcher comes very early in the process, long before autowarming is
done. The one in SolrCore comes after autowarming and can trivially include the
autowarm time with each message. WDYT?
{quote}{quote}I really value LogUpdateProcessorFactory; I insist we keep it at
INFO by default.
{quote}{quote}
I looked some more to see how much I disagreed and... well I don't disagree any
more. Turns out that both the client app that started this Jira and the logs I
have to evaluate are ill-behaved. The overwhelming number of updates are a
single document, not to mention external commits and the like. So if people
insist on following this pattern, they can bump the log level to WARN for
LogUpdateProcessorFactory in the log4j2 config files. It won't be nearly as
egregious if sane patterns are followed.
{quote} BTW if you set it to WARN threshold, I can see a small bug where it
skips the URP altogether and thus also misses logging the slow queries at WARN.
{quote}
I don't quite follow. Are you talking about what's done in
{code:java}
LogUpdateProcessorFactory.getLogStringAndClearRspToLog()?{code}
where the response.toLog is cleared? That looks...confused, perhaps another
JIRA? The response.toLog is referenced in the LogUpdateProcessorFactory and
cleared in the method I just mentioned (if called). Then, back in SolrCore the
information is (potentially) logged in requestLog and/or slowLog, both of which
are bypassed if either of the calls in LogUpdateProcessorFactory are called
since the response.toLog is cleared. Which means that slow logging and request
logging aren't working at all. Which isn't true AFAIK, so I'd rather not try to
address it in this JIRA.
{quote} Lets also ensure that this log category is easily separated out so that
it's easy to manipulate without messing with other logs in whatever class this
happens to be in.
{quote}
Please raise another Jira if for that, I don't want too much feature creep
here. I'm not quite sure what you mean by "this log category" here anyway, the
requestLog?
> Visit Solr logging, it's too noisy.
> -----------------------------------
>
> Key: SOLR-11934
> URL: https://issues.apache.org/jira/browse/SOLR-11934
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
