[
https://issues.apache.org/jira/browse/SOLR-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371040#comment-16371040
]
Shawn Heisey commented on SOLR-11934:
-------------------------------------
Thought stream:
I think the default logfile rollover size of 4MB is WAY too small. On a busy
server, it can cycle through all ten logfiles in a hurry and what you're
looking for may not even be available. I increase this to 4GB on my installs,
but this is perhaps far too large for a default. I think it does need to be
increased. I wonder if 100MB is too large. 64MB? Should we switch to
time-based rollover instead? Because the time-based logs have variable
filenames, scripting becomes more difficult. And on a busy server, one day of
logging could be REALLY huge.
I'm wary of splitting the logging into separate files. It sounds like a good
idea to control verbosity, until you discover that you need to see the order of
seven different log entries that all happened in the same millisecond, and
because they're in multiple files, you have no idea what order they occurred.
The solution to that would probably lead to duplication of logging entries in
multiple files, so we're back to a situation where too much data is being
logged.
Logging into a core/collection is an interesting idea, especially if there is a
UI for querying it, and the problem of recursive logging storms can be
prevented. (probably by logging everything for that core/collection ONLY to a
logfile)
Without doing some research, I'm neutral on the subject of intricate log4j2
config details and how to use MDC more effectively.
Minor point: I disagree with the assertion [~gus_heck] made that ERROR can be
looked at in the morning. I would use that phrase to describe WARN.
I don't see any ability in slf4j to actually log at FATAL, and I've never seen
any logs from Solr at that level. The highest severity it seems to give the
developer is ERROR. I think there are probably some problems that should be
logged at this level. The log4j API has FATAL, but we're not using log4j in
the code, only slf4j.
Perhaps as an Apache project, we should be eating our own dogfood, not using
slf4j. What do people think about the idea of a new issue that migrates slf4j
to log4j2 and configures it programmatically from solr.xml? The config could
have a few very simple options (some for size-based rotation like we have now,
some for time-based rotation, etc). I wonder if there's possibly a way that we
could tell it to configure from a log4j.xml file instead of those easy options,
so expert users can still have complete control over the logging with all the
capability that log4j normally has.
> 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]
