Thanks Mark.

I am personally in favour of some record of any request sent to a server
being logged by default to help trace activity when something goes wrong
(which is something successful add logging indirectly achieves), but
unfortunately that currently includes internal distrib=false requests which
adds to the spam.

In any case, I will probably first start with ERROR and WAR...



On Mon, Aug 25, 2014 at 9:48 PM, Mark Miller <[email protected]> wrote:

>
>
> > On Aug 25, 2014, at 4:44 PM, Ramkumar R. Aiyengar <
> [email protected]> wrote:
> >
> > I am in the process of looking at some of the ERROR level log output
> coming from Solr to set up alarms, but currently the severity of what ERROR
> means is kind of mixed across the code base. I am happy to fix this where I
> find, but some guidance on what the various levels mean would be helpful.
> This is what I would have expected:
> >
> >       • ERROR: Shouldn't happen, indicates a bug or misconfiguration.
> Leads to loss of functionality or some operation failing. Any occurrence
> indicates something needs to be fixed.
> >       • WARN: Recoverable problem, might genuinely happen in rare cases.
> If it happens too often, might indicate an issue or misconfiguration. Bad
> input data could fall into this category, or should it be INFO?
> >       • INFO: Informational messages which would help in investigation,
> indicates expected behaviour.
> > Let me know if this is not accurate..
> >
>
> Looks right overall. Which is not to say you won’t find an abuse here or
> there…
>
> bq. Bad input data could fall into this category,
>
> +1
>
> I’ve been using more DEBUG as well. I think INFO should not spam (like our
> default successful add logging does) - it should just be useful always
> logged stuff to help with debugging and monitoring and operations.
>
> DEBUG can be a bit more spammy and just whatever is useful if developing
> in that area.
>
> - Mark
>
> http://about.me/markrmiller
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>


-- 
Not sent from my iPhone or my Blackberry or anyone else's

Reply via email to