[ 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