Mailing-List: contact log4j-user-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Users List" <log4j-user@logging.apache.org>
From: Remko Popma <remko.popma@gmail.com>
Content-Type: text/plain;
	charset=shift_jis
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: status appender?
Message-Id: <645CD9DB-031A-4023-A3CB-7007EB646AC9@gmail.com>
Date: Tue, 15 Dec 2015 06:20:24 +0900
References: <COL126-W36ACCC5DC2BD20D77D06DEDBED0@phx.gbl>
 <0FF36674-5A9B-4370-AFC9-49D149368D08@dslextreme.com>
 <COL126-W26440632AB5F9900909E35DBED0@phx.gbl>
 <86685E21-DB74-4265-85FD-06AFCA1C0E0B@dslextreme.com>
 <COL126-W41F3D87EEC381A908B237EDBED0@phx.gbl>
In-Reply-To: <COL126-W41F3D87EEC381A908B237EDBED0@phx.gbl>
To: Log4J Users List <log4j-user@logging.apache.org>

Nick,

Are you sure you want to use a logging framework for this? When I hear terms=
 like "business event" and "domain socket appender" that makes me think you m=
ay want to look at some message oriented middleware solution, like JMS or th=
e like.=20

Remko=20

Sent from my iPhone

> On 2015/12/15, at 3:27, Nicholas Duane <nickdu@msn.com> wrote:
>=20
> I'll give a brief description on the setup so that hopefully you have a be=
tter picture.
>=20
> We want to capture a specific type of event, let's say a business event, f=
rom all the applications on the box and get them to a central location.  We'=
re also looking ahead to a possible PaaS environment and thinking that writi=
ng to log files might not be an option.  Our solution is that all the applic=
ations on the box will use our domain socket appender to write these busines=
s events into.  In addition, there will be a daemon on this box listening on=
 the domain socket.  It will buffer, compress and send the events to a centr=
al location.  Even if we don't want to take into consideration the PaaS envi=
ronment and thus can consider writing to local files (as I guess that's the m=
ost common logging solution and has its benefits), there might be issues the=
re.  For instance, let's say we have a process which picks up log files and s=
ends them centrally.  What happens when new applications are installed on th=
e box?  We would probably have to update the configuration of this "log file=
 consolidator" to watch new folder locations.  That might be a bit of a main=
tenance nightmare.
>=20
> If the domain socket appender runs into issues, like it can't open the soc=
ket, we need for someone to look into it.  I guess the thinking is that if w=
e get these ERROR/INFO events to a central location we can have some monitor=
ing there to address these issues.
>=20
> We also, currently, are failing over the event sent to the domain socket a=
ppender to the domain socket appender's logger, which I guess is what you're=
 referring to by "Routing events being processed by an Appender through a Lo=
gger is a bad idea.".  While that is happening now, that's not the main ques=
tion I have here.  It's about how to send INFO - ERROR to one location, or p=
ossibly two, and have DEBUG only go to the status logger.
>=20
> There is push back on "failing over" the events from the domain socket app=
ender so that code might get pulled out.
>=20
> Thanks,
> Nick
>=20
>> Subject: Re: status appender?
>> From: ralph.goers@dslextreme.com
>> Date: Mon, 14 Dec 2015 10:56:11 -0700
>> To: log4j-user@logging.apache.org
>>=20
>> I don=81ft think I understand - =81gwe=81fre writing to our own logger wi=
thin our DomainSocketAppender=81h.  The status logger in your appender shoul=
d only be logging errors or other events that occur within that Appender, wh=
ich normally would be nothing. Routing events being processed by an Appender=
 through a Logger is a bad idea.
>>=20
>> Ralph
>>=20
>>=20
>>=20
>>> On Dec 14, 2015, at 10:17 AM, Nicholas Duane <nickdu@msn.com> wrote:
>>>=20
>>> Thanks.  Yes, that's the one option I was thinking of.  Adding a console=
 or file appender to our logger.  However, the actual class in question is o=
ur DomainSocketAppender.  This is somewhat related to a previous question I a=
sked about capturing events from our appenders centrally.  I guess in genera=
l, the advice is to log to the status logger in your log4j2 classes.  We wan=
t to capture INFO - ERROR messages centrally so we're writing to our own log=
ger within our DomainSocketAppender.  It would be nice to have all other eve=
nts, DEBUG and less specific (or maybe just all events), go to the status lo=
gger and let the application team decide what they want to do with status lo=
gger events.
>>>=20
>>> I was just thinking that one other solution would be to log all events w=
ithin our DomainSocketsAppender to both its private logger and the status lo=
gger, thus somewhat removing the "routing" within the code.  Our filter on t=
he http appender already filters out anything less specific than INFO.
>>>=20
>>> Thanks,
>>> Nick
>>>=20
>>>> Subject: Re: status appender?
>>>> From: ralph.goers@dslextreme.com
>>>> Date: Mon, 14 Dec 2015 09:32:51 -0700
>>>> To: log4j-user@logging.apache.org
>>>>=20
>>>> First, what you are wanting to do is, in fact, pretty normal.  However,=
 by default the StatusLogger that Log4j uses for its components doesn=81ft u=
se an Appender. Although the API is the same the internals of the StatusLogg=
er are actually quite different than the =81gnormal=81h Log4j implementation=
.  That said, the StatusLogger normally just writes to the console.  I actua=
lly doubt that that is where you want your debug events to go.  Most people p=
refer them to go to a rolling file.
>>>>=20
>>>> To accomplish what you want you just need to set up filtering in your c=
onfiguration so that the FATAL-INFO events go to one Appender and the DEBUG a=
nd TRACE events go to another Appender.
>>>>=20
>>>> Ralph
>>>>=20
>>>>> On Dec 14, 2015, at 8:34 AM, Nicholas Duane <nickdu@msn.com> wrote:
>>>>>=20
>>>>> I'm curious if there is such a thing as a StatusAppender in log4j2 whi=
ch, as you would guess, is the appender the StatusLogger would use?
>>>>>=20
>>>>> Here's what I'm trying to solve, I think.
>>>>>=20
>>>>> I've been telling other developers I work with that a piece of code sh=
ould only write to a single logger.  The reason for this, in my mind, is tha=
t if a piece of code writes to more than one logger then it essentially has r=
outing logic in it and I would rather have the routing in the configuration.=
  For example:
>>>>>=20
>>>>> try
>>>>>  {
>>>>>  logger1.info(...);
>>>>>  .
>>>>>  .
>>>>>  .
>>>>>  logger2.debug(...);
>>>>>  }
>>>>> catch(Exception e)
>>>>>  {
>>>>>  logger1.error(...);
>>>>>  }
>>>>>=20
>>>>> The above code is sending debug events to a different logger than the r=
est of the events it raises.  I would rather have the code send all events t=
o a single logger and control where those events are routed via the configur=
ation.  Feel free to let me know whether this is in line with logging princi=
ples.
>>>>>=20
>>>>> So here's the problem.  We've got some code which writes events to its=
 logger.  We want to capture these events centrally so we're sending them to=
 a central location via an HTTP appender.  We want to do this only for FATAL=
 - INFO events, so we're not expecting a huge load.  DEBUG events however, w=
e'd like to send to the same location as the status logger.  We can, of cour=
se, just add a console appender for DEBUG events but that would have to be c=
ontrolled separately from the status logger and ideally it would be nice to j=
ust piggy back on the status logger.  We could have this code write to its p=
rivate logger and the status logger for DEBUG events, but then we get into t=
he routing issue I mentioned above.  So I'm wondering, is there such a thing=
 as a StatusAppender?
>>>>>=20
>>>>> Thanks,
>>>>> Nick
>>>>=20
>>>>=20
>>>>=20
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>=20
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>                        =20

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org