rlogview, chainsaw, and log4r

[listrecv]

log4j has a great hierarchial viewer called chainsaw. When you're
working on a large app, it makes things *much* easier - you can drill
down as you need to in the logs (easier than running grep over and
over).

log4r doesn't have one. I found a link
http://sourceforge.net/projects/rlogview/ to rlogview, but it's several
years old, seems to rely on deprecated gtk libs, and wouldn't run (at
least on my windows machine).

It's only about 200 lines of code. Are there any GTK mavens here who
could fix it, or write a new one? It would be a great asset to the
Ruby community.

http://logging.apache.org/log4j/docs/chainsaw.html

 

[scott]

In case you didn't know, Chainsaw provides a few receivers that allow
it to process events from other frameworks. You can find examples of
these receiver configurations from Chainsaw's Welcome tab (view example
receiver configuration).

Process regular text log files: LogFilePatternReceiver
Accept xml-formatted events sent via tcp socket: XMLSocketReceiver
Accept xml-formatted events sent via UDP: UDPReceiver (or
MulticastReceiver)
Process events stored in a database: CustomSQLDBReceiver

Log4net, log4php, log4perl and log4cxx frameworks can all send events
to Chainsaw over UDP or TCP (and if folks using those frameworks are
just generating log files, they can use LogFilePatternReceiver).

Hope this helps,

Scott

 

[listrecv]

That's a very useful idea. What do you recommend to be the simplest
way to hook up log4r to Chainsaw, then?

 

[listrecv]

Log4net, log4php, log4perl and log4cxx frameworks can all send events
to Chainsaw over UDP or TCP

Hmm.... sounds like this would be a good feature for log4r to add as
well, no?

 

[scott]

The simplest way to send events from log4r to Chainsaw is to configure
log4r to use a FileOutputter with a PatternFormatter.

On the Chainsaw side, you'd then set up a LogFilePatternReceiver to
read the log file.

Log4r side:

You could use a pattern format like:
[%l] %d - %m

which creates events that look like this:
[DEBUG] 2001-01-12 13:15:50 - message here

Chainsaw side:

Define a logFilePatternReceiver (see an example receiver config from
the Welcome tab).

The receiver's logFormat matching the above format would be:
[LEVEL] TIMESTAMP - MESSAGE

The receiver's timestampFormat would be:
yyyy-MM-dd HH:mm:ss

You'll also need to specify a fileURL for the receiver - something like
file:///c:/logfile.txt

By the way, there's also a version of LogFilePatternReceiver can that
read events over ssh (VFSLogFilePatternReceiver in the
org.apache.log4j.chainsaw.varia package). Same arguments, but the
fileURL can be any URL supported by the jakarta commons-VFS project
(http://jakarta.apache.org/commons/vfs/index.html)

As for TCP/UDP integration, it depends on what you need. The other
frameworks generate XML events conforming to log4j's dtd.

The xml-supporting network receivers require the appender (outputter)
side to send events to a multicast address or the IP of the box running
Chainsaw itself.

Log4j also provides a 'sockethubappender' that allows a Chainsaw client
(socketHubReceiver) to connect to a source (socketHubAppender) and the
appender will push events to the receiver (reverse-connect of
SocketAppender/SocketReciever), but there isn't an xml-supporting
version of that appender like there is for the socketapppender that has
the source send events to the Chainsaw client. This would be more
useful in a long-running server environment, and in some cases where
firewall issues arise.

Do you need to receive all events? If so, UDP and multicast are out.
Also, since TCP sockets can block, I usually suggest just using the
LogFilePatternReceiver or VFSLogFilePatternReceiver if you need to
receive all events. Storing events in a database and using
CustomSQLDBReceiver is also an ok option if your environment can handle
the processing load.

If you can lose events, UDP and multicastappenders are good options,
assuming your network config can support it.

Scott

 

[listrecv]

Thank you very much for the detailed info!

The simplest way to send events from log4r to Chainsaw is to configure
log4r to use a FileOutputter with a PatternFormatter.

On the Chainsaw side, you'd then set up a LogFilePatternReceiver to
read the log file.

Log4r side:

You could use a pattern format like:
[%l] %d - %m

which creates events that look like this:
[DEBUG] 2001-01-12 13:15:50 - message here

Chainsaw side:

Define a logFilePatternReceiver (see an example receiver config from
the Welcome tab).

The receiver's logFormat matching the above format would be:
[LEVEL] TIMESTAMP - MESSAGE

The receiver's timestampFormat would be:
yyyy-MM-dd HH:mm:ss

You'll also need to specify a fileURL for the receiver - something like
file:///c:/logfile.txt

By the way, there's also a version of LogFilePatternReceiver can that
read events over ssh (VFSLogFilePatternReceiver in the
org.apache.log4j.chainsaw.varia package). Same arguments, but the
fileURL can be any URL supported by the jakarta commons-VFS project
(http://jakarta.apache.org/commons/vfs/index.html)

As for TCP/UDP integration, it depends on what you need. The other
frameworks generate XML events conforming to log4j's dtd.

The xml-supporting network receivers require the appender (outputter)
side to send events to a multicast address or the IP of the box running
Chainsaw itself.

Log4j also provides a 'sockethubappender' that allows a Chainsaw client
(socketHubReceiver) to connect to a source (socketHubAppender) and the
appender will push events to the receiver (reverse-connect of
SocketAppender/SocketReciever), but there isn't an xml-supporting
version of that appender like there is for the socketapppender that has
the source send events to the Chainsaw client. This would be more
useful in a long-running server environment, and in some cases where
firewall issues arise.

Do you need to receive all events? If so, UDP and multicast are out.
Also, since TCP sockets can block, I usually suggest just using the
LogFilePatternReceiver or VFSLogFilePatternReceiver if you need to
receive all events. Storing events in a database and using
CustomSQLDBReceiver is also an ok option if your environment can handle
the processing load.

If you can lose events, UDP and multicastappenders are good options,
assuming your network config can support it.

Scott

That's a very useful idea. What do you recommend to be the simplest
way to hook up log4r to Chainsaw, then?

 

[listrecv]

Is there anyway to save those receivers in chainsaw, so that when I
exit, I don't need to reconfigure it?

The simplest way to send events from log4r to Chainsaw is to configure
log4r to use a FileOutputter with a PatternFormatter.

On the Chainsaw side, you'd then set up a LogFilePatternReceiver to
read the log file.

Log4r side:

You could use a pattern format like:
[%l] %d - %m

which creates events that look like this:
[DEBUG] 2001-01-12 13:15:50 - message here

Chainsaw side:

Define a logFilePatternReceiver (see an example receiver config from
the Welcome tab).

The receiver's logFormat matching the above format would be:
[LEVEL] TIMESTAMP - MESSAGE

The receiver's timestampFormat would be:
yyyy-MM-dd HH:mm:ss

You'll also need to specify a fileURL for the receiver - something like
file:///c:/logfile.txt

By the way, there's also a version of LogFilePatternReceiver can that
read events over ssh (VFSLogFilePatternReceiver in the
org.apache.log4j.chainsaw.varia package). Same arguments, but the
fileURL can be any URL supported by the jakarta commons-VFS project
(http://jakarta.apache.org/commons/vfs/index.html)

As for TCP/UDP integration, it depends on what you need. The other
frameworks generate XML events conforming to log4j's dtd.

The xml-supporting network receivers require the appender (outputter)
side to send events to a multicast address or the IP of the box running
Chainsaw itself.

Log4j also provides a 'sockethubappender' that allows a Chainsaw client
(socketHubReceiver) to connect to a source (socketHubAppender) and the
appender will push events to the receiver (reverse-connect of
SocketAppender/SocketReciever), but there isn't an xml-supporting
version of that appender like there is for the socketapppender that has
the source send events to the Chainsaw client. This would be more
useful in a long-running server environment, and in some cases where
firewall issues arise.

Do you need to receive all events? If so, UDP and multicast are out.
Also, since TCP sockets can block, I usually suggest just using the
LogFilePatternReceiver or VFSLogFilePatternReceiver if you need to
receive all events. Storing events in a database and using
CustomSQLDBReceiver is also an ok option if your environment can handle
the processing load.

If you can lose events, UDP and multicastappenders are good options,
assuming your network config can support it.

Scott

That's a very useful idea. What do you recommend to be the simplest
way to hook up log4r to Chainsaw, then?

 

[scott]

Yes...see the 'view example receiver configuration' button on the
Welcome tab.

Save that to your local file system (or a web server) and modify it as
needed.

Next, go to the view-show application wide preferences menu
In the automatic configuration URL field at the bottom of the page,
enter the URL to the config file (for example:
file:///c:/chainsaw-config.xml)

Restart Chainsaw

It'll load each 'plugin' entry in the config file as a receiver config.
If there are errors configuring the receiver, you'll see messages in
the chainsaw-log tab.

Good luck!

Is there anyway to save those receivers in chainsaw, so that when I
exit, I don't need to reconfigure it?

The simplest way to send events from log4r to Chainsaw is to configure
log4r to use a FileOutputter with a PatternFormatter.

On the Chainsaw side, you'd then set up a LogFilePatternReceiver to
read the log file.

Log4r side:

You could use a pattern format like:
[%l] %d - %m

which creates events that look like this:
[DEBUG] 2001-01-12 13:15:50 - message here

Chainsaw side:

Define a logFilePatternReceiver (see an example receiver config from
the Welcome tab).

The receiver's logFormat matching the above format would be:
[LEVEL] TIMESTAMP - MESSAGE

The receiver's timestampFormat would be:
yyyy-MM-dd HH:mm:ss

You'll also need to specify a fileURL for the receiver - something like
file:///c:/logfile.txt

By the way, there's also a version of LogFilePatternReceiver can that
read events over ssh (VFSLogFilePatternReceiver in the
org.apache.log4j.chainsaw.varia package). Same arguments, but the
fileURL can be any URL supported by the jakarta commons-VFS project
(http://jakarta.apache.org/commons/vfs/index.html)

As for TCP/UDP integration, it depends on what you need. The other
frameworks generate XML events conforming to log4j's dtd.

The xml-supporting network receivers require the appender (outputter)
side to send events to a multicast address or the IP of the box running
Chainsaw itself.

Log4j also provides a 'sockethubappender' that allows a Chainsaw client
(socketHubReceiver) to connect to a source (socketHubAppender) and the
appender will push events to the receiver (reverse-connect of
SocketAppender/SocketReciever), but there isn't an xml-supporting
version of that appender like there is for the socketapppender that has
the source send events to the Chainsaw client. This would be more
useful in a long-running server environment, and in some cases where
firewall issues arise.

Do you need to receive all events? If so, UDP and multicast are out.
Also, since TCP sockets can block, I usually suggest just using the
LogFilePatternReceiver or VFSLogFilePatternReceiver if you need to
receive all events. Storing events in a database and using
CustomSQLDBReceiver is also an ok option if your environment can handle
the processing load.

If you can lose events, UDP and multicastappenders are good options,
assuming your network config can support it.

Scott

That's a very useful idea. What do you recommend to be the simplest
way to hook up log4r to Chainsaw, then?

scott wrote:
In case you didn't know, Chainsaw provides a few receivers that allow
it to process events from other frameworks. You can find examples of
these receiver configurations from Chainsaw's Welcome tab (view example
receiver configuration).

Process regular text log files: LogFilePatternReceiver
Accept xml-formatted events sent via tcp socket: XMLSocketReceiver
Accept xml-formatted events sent via UDP: UDPReceiver (or
MulticastReceiver)
Process events stored in a database: CustomSQLDBReceiver

Log4net, log4php, log4perl and log4cxx frameworks can all send events
to Chainsaw over UDP or TCP (and if folks using those frameworks are
just generating log files, they can use LogFilePatternReceiver).

Hope this helps,

Scott

(e-mail address removed) wrote:
log4j has a great hierarchial viewer called chainsaw. When you're
working on a large app, it makes things *much* easier - you can drill
down as you need to in the logs (easier than running grep over and
over).

log4r doesn't have one. I found a link
http://sourceforge.net/projects/rlogview/ to rlogview, but it's several
years old, seems to rely on deprecated gtk libs, and wouldn't run (at
least on my windows machine).

It's only about 200 lines of code. Are there any GTK mavens here who
could fix it, or write a new one? It would be a great asset to the
Ruby community.

http://logging.apache.org/log4j/docs/chainsaw.html