Re: SocketAppender based filtering relay/router..

[Paul Glezen <pg...@atdial.net>]

Alain RAVET wrote:
> 
> Hi all,
> 
> We plan to use log4j for the monitoring of remote applications.
> 
> As there will be many clients, we want them to log to a SocketAppender, an
> have the server (socket listener) make the routing/filtering the log
> messages decisions, based on simple rules.
> 
> We'd thought about building a socket listener to handle the messages,
> depending on their contents, source, priority.
> We need to
>    - display in a terminal all the live messages,
>    - log all the received messages in a DB,
>    - route some messages based on some rules
>     (ex. when a WARNING comes in, send an email to ..)
>     (ex. when a ERROR   comes in, send a SMS to ..)
>    - ...

Hi Alain,

I used this very thing at one engagement.  I called them "log
dispatchers."  They come in handy for a variety of reasons.

1. All the distributed apps can be configured to point
   to the dispatcher once and for all.  When you need
   to change a  logging property for a distributed
   app, you can change it at the log dispatcher rather
   than running around to every component (some of which
   maybe very remote). 

2. A log dispatcher can server to integrate the log streams
   of several servers.  This eliminates the need to cross
   reference many log files produced by various app server
   processes

3. It serves as a single point of contact for enterprise
   system management tools like Candle Command Center or
   Tivoli.

Our development environment had four dispatch hosts, one for integration
testing, one for QA (the testing team), one for a training system and
one for production.  Each dispatch host had two dispatchers (listening
on different ports).  One accepted trace messages (often turned off
during production).  The other accepted event messages that were sent to
the central management console.  (The "dispatch machines" had many other
things running on them, they don't have to be dedicated to log4j).

Hope this provides some insights. Sorry for the delayed response.

- Paul
-- 
Beware of bugs in the above code.  I have
only proved it correct, not tried it.
-Don Knuth

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

RE: SocketAppender based filtering relay/router..

[Alain RAVET <ar...@cirb.irisnet.be>]

Paul,

Thanks for your reply.

We have just started developing a simple "log4jSocketRelay", that uses log4j
for output.
As it is a relay, we want it to be as transparent as possible, and it does not
modify the log events, it just dispatches them, using log4j.


Questions:
- When was it useful to be able to modify a property in incoming event,
  before dispatching it?
- Shouldn't this rather be implemented as a "FilterAppender", 
  than hardcoded in the dispatcher?


Alain


-----Message d'origine-----
De : pglezen [mailto:pglezen]De la part de Paul Glezen

Hi Alain,

I used this very thing at one engagement.  I called them "log
dispatchers."  They come in handy for a variety of reasons.

1. All the distributed apps can be configured to point
   to the dispatcher once and for all.  When you need
   to change a  logging property for a distributed
   app, you can change it at the log dispatcher rather
   than running around to every component (some of which
   maybe very remote). 

2. A log dispatcher can server to integrate the log streams
   of several servers.  This eliminates the need to cross
   reference many log files produced by various app server
   processes

3. It serves as a single point of contact for enterprise
   system management tools like Candle Command Center or
   Tivoli.

Our development environment had four dispatch hosts, one for integration
testing, one for QA (the testing team), one for a training system and
one for production.  Each dispatch host had two dispatchers (listening
on different ports).  One accepted trace messages (often turned off
during production).  The other accepted event messages that were sent to
the central management console.  (The "dispatch machines" had many other
things running on them, they don't have to be dedicated to log4j).

Hope this provides some insights. Sorry for the delayed response.

- Paul
-- 
Beware of bugs in the above code.  I have
only proved it correct, not tried it.
-Don Knuth

Alain RAVET wrote:
> 
> Hi all,
> 
> We plan to use log4j for the monitoring of remote applications.
> 
> As there will be many clients, we want them to log to a SocketAppender, an
> have the server (socket listener) make the routing/filtering the log
> messages decisions, based on simple rules.
> 
> We'd thought about building a socket listener to handle the messages,
> depending on their contents, source, priority.
> We need to
>    - display in a terminal all the live messages,
>    - log all the received messages in a DB,
>    - route some messages based on some rules
>     (ex. when a WARNING comes in, send an email to ..)
>     (ex. when a ERROR   comes in, send a SMS to ..)
>    - ...

This mail has been checked by exiscan.
To be safe, please scan the mail attachements with your local virus scanner !

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