[ 
https://issues.apache.org/jira/browse/SOLR-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16782776#comment-16782776
 ] 

Erick Erickson commented on SOLR-13286:
---------------------------------------

Gus:

There's a lot of that going around. See SOLR-12301. Which I hope to get to 
sometime.

I'm not sure whether changing the code or the logging config or both is the 
right answer. One approach is to change log4j2.xml to only log particular 
classes at WARN (or whatever) level rather than INFO and not touch the code. 
The other is to change the code.

I'm a little uneasy at this approach though. It looks like we're throwing out 
something intending to be logged in one place and catching it in another which 
would be hard to keep coordinated. [[email protected]] do you see a better way 
to address the logging verbosity at its source?

> Move Metrics handler and any other noisy admin logging to debug
> ---------------------------------------------------------------
>
>                 Key: SOLR-13286
>                 URL: https://issues.apache.org/jira/browse/SOLR-13286
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: logging
>    Affects Versions: master (9.0)
>            Reporter: Gus Heck
>            Priority: Minor
>         Attachments: SOLR-13286.patch
>
>
> Lately when looking at log files I always find myself straining and squinting 
> to see things among a vast sea of metrics related logging. The problem 
> appears to be that the metrics system regularly issues /admin/ commands that 
> get logged at info by HttpSolrCall, so turning this down also means you can't 
> see any other admin commands, which is often what you're looking for in the 
> first place (ok what I'm often looking for at least :) ). I also recall 
> seeing a complaint about this on one of the lists at some point. 
> Attaching patch to log at an alternate level these based on the value of the 
> handler field in HttpSolrCall. Patch is untested and meant as fodder for 
> commentary and for suggestions of other handlers that might want to go on the 
> "noisy" list.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to