From dev-return-310383-archive-asf-public=cust-asf.ponee.io@lucene.apache.org Thu Feb 1 17:23:05 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 77CC0180652 for ; Thu, 1 Feb 2018 17:23:05 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 6837E160C58; Thu, 1 Feb 2018 16:23:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 89CFC160C26 for ; Thu, 1 Feb 2018 17:23:04 +0100 (CET) Received: (qmail 57273 invoked by uid 500); 1 Feb 2018 16:23:02 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 57113 invoked by uid 99); 1 Feb 2018 16:23:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Feb 2018 16:23:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 5128AE77D6 for ; Thu, 1 Feb 2018 16:23:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -110.311 X-Spam-Level: X-Spam-Status: No, score=-110.311 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id Vz3o3I8wQRA8 for ; Thu, 1 Feb 2018 16:23:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 2F6745F4A8 for ; Thu, 1 Feb 2018 16:23:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 88C44E0153 for ; Thu, 1 Feb 2018 16:23:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 4555F21E81 for ; Thu, 1 Feb 2018 16:23:00 +0000 (UTC) Date: Thu, 1 Feb 2018 16:23:00 +0000 (UTC) From: "Erick Erickson (JIRA)" To: dev@lucene.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (SOLR-11934) Visit Solr logging, it's too noisy. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SOLR-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348842#comment-16348842 ] Erick Erickson commented on SOLR-11934: --------------------------------------- bq: if someone tells me when it went wrong, with a default Solr install I have something to dig into to find out what went wrong Yeah, that's the tension, isn't it? When it does hit the fan you want _everything_, and it's awkward to say "Sorry, the info we need isn't in the logs, change your logging and next time it happens immediately zip up all the log files and call me..." Unfortunately with the defaults I find myself saying the above all the time. Solr produces so much information that the logs roll over pretty quickly under any kind of load, especially indexing. So the info I want is often gone anyway. Which leads to another discussion about the default configuration ;) I suspect this going to morph into a wider discussion about "logging in general". It's grown ad-hoc so far, your comments about "is there a query log" is a question I've heard from clients and on the user's list more than a few times for instance. I don't particularly care if the defaults are producing lots and lots and lots of info, At present, though, we don't rationally group log messages, they're mostly INFO. The important stuff is buried in a sea of messages. I can't grep for WARN and be confident I'll see messages that matter for instance. Of course "what matters" often is something arcane ;)... If the consensus is to move a lot of our INFO messages to DEBUG and distribute OOB with DEBUG enabled, that's fine as well.... I have about 4 different versions of my Java program that I use to tease out different "stuff" from the log file, mostly just to ignore noise. Which noise I need to filter out changes with the problem unfortunately ;) As an example of how logging has grown without any supervision... Did you know that the "%C" bit in the layout pattern generates an exception for each and every log line issued? Useful information to be sure when trying to analyze a problem but costly steady-state. Not only do we generate a stack trace, but also allocate memory, contribute to GC, etc. That's an example of how we've viewed logging from a development/troubleshooting PoV without considering the needs of the operations folks. Much of this discussion will be about thinking about this from an operations viewpoint too. > 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: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org