[
https://issues.apache.org/jira/browse/SOLR-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102025#comment-17102025
]
Erick Erickson commented on SOLR-11934:
---------------------------------------
{quote} I wish it had timing info and ditched the too-detailed low
{quote}
I can make that happen. It's a bit ugly, but looks something like this:
{code}
if (log.isdebugEnabled()) {
// This form dumps a bunch of messages like
// Uninverting(_6(9.0.0):C177290:[diagnostics={lucene.version=9.0.0,
java.vm.version=11.0.5+10,
// java.version=11.0.5, timestamp=1588849987808, os=Mac OS X,
// java.vendor=AdoptOpenJDK, os.version=10.15.4,
java.runtime.version=11.0.5+10,
// os.arch=x86_64,
source=flush}]:[attributes={Lucene50StoredFieldsFormat.mode=BEST_SPEED}]
// :id=ce2v4okod0tsdz9wxrl628t9s)
// which I've never found particularly useful.
// I'll take this comment out before pushing, this comment is here
for discussion.
// nocommit
log.debug("{} Registered new searcher {} autowarm time: {} ms",
logid, newSearcher, newSearcher.getWarmupTime());
} else if (log.isInfoEnabled()) {
log.info("{} Registered new searcher autowarm time: {} ms", logid,
newSearcher.getWarmupTime());
}
{code}
Or just get rid of all the low-level stuff altogether? Personally, I've never
really found the low-level stuff useful and would happily get rid of it
altogether. Once upon a time the Uninverting message was a red flag indicating
that a field should have docvalues, but that disappeared.
bq. See getInstance() and notice that...
Ah, I was looking in a totally different place, I'll add that in.
> 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
