Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of ndimiduk@gmail.com designates
 209.85.214.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+RK=_DzmTYrNjvZW6J7y4J6+s-GnbKBYSohH+WnmZuDn7YGCQ@mail.gmail.com>
References: 
 <CAGHyZ6JkMukFGrLSw5wOdrg3ct180do8wN41e_w23158dezMuQ@mail.gmail.com>
	<CAMZUsP65w2A4JE6NaUuVc-S61-rh3F36J3TyGo5gTKkOGV=JHA@mail.gmail.com>
	<CAGHyZ6+V4gvMbQaEKqqurVqGuLCEx-=musNqa1x+HHPg-Xqhhw@mail.gmail.com>
	<CA+RK=_DzmTYrNjvZW6J7y4J6+s-GnbKBYSohH+WnmZuDn7YGCQ@mail.gmail.com>
Date: Sat, 25 Oct 2014 11:49:02 -0700
Message-ID: 
 <CANZa=GsxGw+MyddkdF-hDx1G1yL27P00kacnuqGBAANu0wa+Ag@mail.gmail.com>
Subject: Re: Reworking the use of log levels
From: Nick Dimiduk <ndimiduk@gmail.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2019a52c737050643c029

--001a11c2019a52c737050643c029
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We have the ability to alter log levels at runtime. This would allow an
operator to temporarily increase log level for afflicted components, even
in production. Doing this on a server-by-server basis should have minimal
impact on overall cluster performance. Maybe this needs to be better
documented? Maybe we need a script that makes this easier, or could be
managed via a new shell command?

On Saturday, October 25, 2014, Andrew Purtell <apurtell@apache.org> wrote:

> =E2=80=8B
> On Sat, Oct 25, 2014 at 6:34 AM, Sean Busbey <busbey@cloudera.com
> <javascript:;>> wrote:
>
> > Even if debug is disabled in production, it could be enabled on a
> > non-production system for reproducing the problem, no?
> >
>
> =E2=80=8BIn my experience, often enough, no.=E2=80=8B
>
> I do hear the complaint that Hadoop ecosystem projects are quite operator
> unfriendly because error messages most often come in the form of a
> stacktrace. It's a totally valid point. I think we could certainly improv=
e
> the exception message printed ahead of the stacktrace in a large number o=
f
> cases.
>
>
>
> On Sat, Oct 25, 2014 at 6:34 AM, Sean Busbey <busbey@cloudera.com
> <javascript:;>> wrote:
>
> > Even if debug is disabled in production, it could be enabled on a
> > non-production system for reproducing the problem, no?
> >
> > --
> > Sean
> > On Oct 25, 2014 7:11 AM, "Qiang Tian" <tianq01@gmail.com <javascript:;>=
>
> wrote:
> >
> > > perhaps case by case is better. stacktrace is one of most important
> > problem
> > > determination methods.  debug is mostly disabled in production, we ma=
y
> > lose
> > > important clues.
> > >
> > >
> > > On Sat, Oct 25, 2014 at 1:14 PM, Sean Busbey <busbey@cloudera.com
> <javascript:;>>
> > wrote:
> > >
> > > > Hi!
> > > >
> > > > Right now we have many failure paths where we send stack traces to
> log
> > > > files at ERROR / WARN. In an effort to make things easier to operat=
e,
> > I'd
> > > > like to propose we move towards:
> > > >
> > > > * INFO/WARN/ERROR : description of failure and if possible an actio=
n
> an
> > > > operator could take to fix/diagnose
> > > > * DEBUG : information needed to handle failures that require
> developer
> > > > action, i.e. stack traces
> > > >
> > > > I figure this can go as one or more subtasks off of HBASE-12341, bu=
t
> > > wanted
> > > > to float things here before I get started.
> > > >
> > > > --
> > > > Sean
> > > >
> > >
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

--001a11c2019a52c737050643c029--