RE: Logging Best Practice?
We currently use: FATAL - logged. Failure to correctly handle an exception and recover is a breach of our standards, the application should not fail unless something it is dependent on (e.g. database) fails first. If there is some critical system error (e.g. server runs out of disc space) then we allow the hosting application server to handle it. ERROR - The same as you, although I think we over-log here. We log every time an exception is caught before being re-thrown. This means that lower classes can log an exception a few times (e.g. insufficient privileges) before a higher class decides that it's not really an issue and simply reports to the user they don't have permission. WARN - Only used in a few areas. INFO - Not used. DEBUG - Heavily used, but not in any controlled way. Seems to include lots of logging just to tell the developer what method of what class they are in. TRACE - Not used. One issue we do have is that not all the logic is contained in the classes, most is expressed in XML defined rules; so what is not a problem for one rule is critical for another. I think this may be part of the reason our logging looks inconsistent if you just consider the code. Even so, out logging does work. We can track problems and solve them but it seems to me to be pretty slap-dash and it strikes me that there must be a better/more efficient way to use log4j. We are looking at performance and one of the areas which is due for examination is logging. Less is faster, but more is useful. Where is that balance? As for logging the class/method we are in; that's because we do not have log4j record that as it is considered too expensive (we're using an older version 1.2_08). Our customers just want to Switch on logging or Switch off logging, they do not want to be told they have to go and edit .ini (or .xml) files etc. All this is why I was wondering what people use as best practice. I like your suggestion about the different levels being held for times. I take it you just have a variety of appenders which get enabled/disable as required? J. -Original Message- From: Eric Kolotyluk [mailto:[EMAIL PROTECTED] Sent: 29 February 2008 16:35 To: Log4J Users List Subject: RE: Logging Best Practice? I'd also be interested in seeing some published best practices. For now here's my rule-of-thumb FATAL - Stuff that is catastrophic enough to warrant escalation back to the developers for thorough investigation and root-cause analysis. ERROR - Stuff that should be investigated. Don't log something as an error unless you are willing to investigate it yourself. WARN- Stuff someone reading the log really needs to pay attention to. Something you may want to consider investigating. INFO- Stuff you want to see from logs of your product at a customer site to help in troubleshooting an issue. You'll want to be able to save anywhere from a day's to a week's worth of logs. DEBUG - Not enabled by default for released product. Enabled for general development and prerelease testing. Stuff you want to see to help you during the development process. You'll want to save at least a day's worth of logs. TRACE - Not ever enabled by default. Used during code development to help understand how things are working. Can produce volumes of output. Should only be enabled for specific packages, not the whole product. You'll want to save at least an hour's worth of logs. One of the big problems with reading logs is burn out - seeing too much stuff logged at too high a priority. If your log contains 10% ERRORs people grow numb and don't take things seriously. Cheers, Eric -Original Message- From: Jason Irwin [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 1:38 AM To: log4j-user@logging.apache.org Subject: Logging Best Practice? I've been doing a fair bit of trawling around logging for some best practice on logging. Does anyone know of a good resource? Or a book which goes into detail on this? The levels FATAL and ERROR are pretty self-explanatory. Are there rules of thumb for INFO, WARN, DEBUG and TRACE? Common metrics for the amount of debugging per class? What should be logged (e.g. parameter values when entering a method to DEBUG; or something) The nature of the logged information (e.g. class, file, method - or not) We already have a lot of logging in our application, but we only make use of ERROR and DEBUG levels and I am concerned we are not being as pragmatic as we should be with what we are logging. My feeling is that we under-log some information which would help the Support team, and over-log a lot of irrelevant stuff. I'd like to be able to back this feeling up. Cheers for any advice, J. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail:
Re: Different levels to different appenders
Mikael Ståldal skrev:
then set the logger levels for both hierarchies to DEBUG, and write
yourself a simple custom Filter implementation that accepts/denies
events based on your logic, and attach a separate configured instance
of that filter to each of the appenders (accepting/denying as the case
may be above).
I have done that, and it seems to work. I'm not sure how it would affect
the performance though.
Here is the filter code I use. I hereby donate this code to the log4j project. I suggest
that it's included in the org.apache.log4j.varia package.
import org.apache.log4j.Level;
import org.apache.log4j.spi.LoggingEvent;
import org.apache.log4j.spi.Filter;
/**
* Filter to ACCEPT log messages based on Level strongand/strong Logger
name prefix.
*
* Parameters:
* ul
* lithreshold - the Level threshold/li
* liprefix - the Logger name prefix, use the empty string to match all
Loggers
* (including the root Logger)./li
* ul
*
* This filter is NEUTRAL if the Logger name prefix doesn't match, and will
ACCEPT or
* DENY based on Level threshold. You can chain several instances of this
filter.
*
* @author Mikael Ståldal
*/
public class LevelAndPrefixFilter extends Filter {
Level threshold;
String prefix;
@Override
public int decide(LoggingEvent event) {
if (!event.getLoggerName().startsWith(prefix)) {
return NEUTRAL;
}
if (event.getLevel().isGreaterOrEqual(threshold)) {
return ACCEPT;
} else {
return DENY;
}
}
public Level getThreshold() {
return threshold;
}
public void setThreshold(Level threshold) {
this.threshold = threshold;
}
public String getPrefix() {
return prefix;
}
public void setPrefix(String prefix) {
this.prefix = prefix;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
configuring log4j for two JVMs
Hi, My application is such that, at start-up,the first component brings up a new JVM containing the other components. I have a log4j file having one Console and one File appenders attached to the root logger. The same file is being configured by both the JVMs at their startup. The problem is that, when i change the rootlogger level dynamically, i sometimes find logger messages from the first component(the one in the first JVM) whose level is lower than the level configured. Where am i going wrong? -- View this message in context: http://www.nabble.com/configuring-log4j-for-two-JVMs-tp15799976p15799976.html Sent from the Log4j - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chainsaw Tab identifier
Hello, I'm trying to figure out what things I need to place in my Tab identifier field to filter out my applications. I'm using log4j v 1.2.13 and chainsaw v2. I have two applications running on the same server and both are using a socketHubAppender on different ports. I don't have any location info so the default PROP.hostName - PROP.application only separates by hostname and since I'm running two apps on the same server I get both logs dumped to the same tab. I've tried adding PROP.remoteSourceInfo (since that is a column in the logs that shows up and has the port number listed) and that property appears to return nothing. It's my understanding that the location info does not work in log4j 1.2.X. So my question is two fold. Is there some reference that I can look at that will tell me what properties are available, and can someone tell me how I would go about doing this? I see in the comments for LoggingEventFieldResolver the following field are available but nothing here seems like it will work for me. Plus there seems to be no explanation of what keyName is in PROP.keyName. * Field NameField value (String representationReturn type * LOGGERcategory name (logger)String * LEVEL level Level * CLASS locationInformation's class name String * FILE locationInformation's file name String * LINE locationInformation's line number String * METHODlocationInformation's method name String * MSG message Object * NDC NDC String * EXCEPTION throwable string representation ThrowableInformation * TIMESTAMP timestamp Long * THREAD threadString * PROP.keyName entry in the Property hashtable String * mapped to the key [keyName] Any help would be appreciated. Jason Tholstrup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chainsaw Tab identifier
Two things: 1. To get every socketappender connection to display in its own tab in Chainsaw, use PROP.log4j.remoteSourceInfo as the tab identifier (note the log4j. in front of the property name - log4j. isn't some special property name, that's just the name of the property). 2. The 'application' property on socketappender is how you route events to different tabs when the two apps are running on the same server and using socketappender. Here's an example of that config: appender name=SOCKET class=org.apache.log4j.net.SocketAppender param name=remoteHost value=localhost/ param name=LocationInfo value=true/ param name=port value=4560/ param name=application value=someappname/ /appender Use a different value in the 'application' param for each of the socketappender configs and you should be fine. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 9:24 AM To: log4j-user@logging.apache.org Subject: Chainsaw Tab identifier Hello, I'm trying to figure out what things I need to place in my Tab identifier field to filter out my applications. I'm using log4j v 1.2.13 and chainsaw v2. I have two applications running on the same server and both are using a socketHubAppender on different ports. I don't have any location info so the default PROP.hostName - PROP.application only separates by hostname and since I'm running two apps on the same server I get both logs dumped to the same tab. I've tried adding PROP.remoteSourceInfo (since that is a column in the logs that shows up and has the port number listed) and that property appears to return nothing. It's my understanding that the location info does not work in log4j 1.2.X. So my question is two fold. Is there some reference that I can look at that will tell me what properties are available, and can someone tell me how I would go about doing this? I see in the comments for LoggingEventFieldResolver the following field are available but nothing here seems like it will work for me. Plus there seems to be no explanation of what keyName is in PROP.keyName. * Field NameField value (String representationReturn type * LOGGERcategory name (logger)String * LEVEL level Level * CLASS locationInformation's class name String * FILE locationInformation's file name String * LINE locationInformation's line number String * METHODlocationInformation's method name String * MSG message Object * NDC NDC String * EXCEPTION throwable string representation ThrowableInformation * TIMESTAMP timestamp Long * THREAD threadString * PROP.keyName entry in the Property hashtable String * mapped to the key [keyName] Any help would be appreciated. Jason Tholstrup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw Tab identifier
Thanks Scott that was very helpful (and fast). Am I missing the reference to what Prop keyNames are available? It would be nice to know what is available (who knows maybe I'll find something i didn't know i couldn't live without). Even if it's just a matter of looking at the right javadocs that's enough. I'd just like to be able to tinker on my own. Thanks for all your hard work. Chainsaw is pretty cool. Jason Tholstrup Software Engineer [EMAIL PROTECTED] On Mar 3, 2008, at 11:42 AM, Scott Deboy wrote: Two things: 1. To get every socketappender connection to display in its own tab in Chainsaw, use PROP.log4j.remoteSourceInfo as the tab identifier (note the log4j. in front of the property name - log4j. isn't some special property name, that's just the name of the property). 2. The 'application' property on socketappender is how you route events to different tabs when the two apps are running on the same server and using socketappender. Here's an example of that config: appender name=SOCKET class=org.apache.log4j.net.SocketAppender param name=remoteHost value=localhost/ param name=LocationInfo value=true/ param name=port value=4560/ param name=application value=someappname/ /appender Use a different value in the 'application' param for each of the socketappender configs and you should be fine. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 9:24 AM To: log4j-user@logging.apache.org Subject: Chainsaw Tab identifier Hello, I'm trying to figure out what things I need to place in my Tab identifier field to filter out my applications. I'm using log4j v 1.2.13 and chainsaw v2. I have two applications running on the same server and both are using a socketHubAppender on different ports. I don't have any location info so the default PROP.hostName - PROP.application only separates by hostname and since I'm running two apps on the same server I get both logs dumped to the same tab. I've tried adding PROP.remoteSourceInfo (since that is a column in the logs that shows up and has the port number listed) and that property appears to return nothing. It's my understanding that the location info does not work in log4j 1.2.X. So my question is two fold. Is there some reference that I can look at that will tell me what properties are available, and can someone tell me how I would go about doing this? I see in the comments for LoggingEventFieldResolver the following field are available but nothing here seems like it will work for me. Plus there seems to be no explanation of what keyName is in PROP.keyName. * Field NameField value (String representationReturn type * LOGGERcategory name (logger)String * LEVEL level Level * CLASS locationInformation's class name String * FILE locationInformation's file name String * LINE locationInformation's line number String * METHODlocationInformation's method name String * MSG message Object * NDC NDC String * EXCEPTION throwable string representation ThrowableInformation * TIMESTAMP timestamp Long * THREAD threadString * PROP.keyName entry in the Property hashtable String * mapped to the key [keyName] Any help would be appreciated. Jason Tholstrup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw Tab identifier
Sorry Scott I had not tried your instructions before I replied last time. I can get PROP.log4j.remoteSourceInfo to show up in my tab identifier but PROP.application does not seem to work (which to be honest is much closer to what I want). I've seen that there is an issue with the serialized object translation from the 1.2.X branch to the 1.3 based chainsaw v2 download, and I don't receive Class, Method, File, or Line information in my logs. Is this possibly the reason PROP.application does not show up, or is there something else I have missed? Here is the log4j.properties snippet for my app. I've bounced my server container just to make sure it reloaded and PROP.application continues to return nothing in chainsaw log4j.properties sinppet (on server) log4j.appender.HUB=org.apache.log4j.net.SocketHubAppender log4j.appender.HUB.port=9005 log4j.appender.HUB.LocationInfo=true log4j.appender.HUB.Threshold=DEBUG log4j.appender.HUB.application=SES Test Tab identifier string PROP.application - PROP.log4j.remoteSourceInfo chainsaw.xml ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/; debug=true plugin name=SocketHubReceiver class=org.apache.log4j.net.SocketHubReceiver param name=host value=devocs.theebsgroup.com/ param name=port value=9004/ param name=reconnectionDelay value=3/ param name=name value=devocs SES/ /plugin root level value=debug/ /root /log4j:configuration Jason Tholstrup On Mar 3, 2008, at 11:42 AM, Scott Deboy wrote: Two things: 1. To get every socketappender connection to display in its own tab in Chainsaw, use PROP.log4j.remoteSourceInfo as the tab identifier (note the log4j. in front of the property name - log4j. isn't some special property name, that's just the name of the property). 2. The 'application' property on socketappender is how you route events to different tabs when the two apps are running on the same server and using socketappender. Here's an example of that config: appender name=SOCKET class=org.apache.log4j.net.SocketAppender param name=remoteHost value=localhost/ param name=LocationInfo value=true/ param name=port value=4560/ param name=application value=someappname/ /appender Use a different value in the 'application' param for each of the socketappender configs and you should be fine. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 9:24 AM To: log4j-user@logging.apache.org Subject: Chainsaw Tab identifier Hello, I'm trying to figure out what things I need to place in my Tab identifier field to filter out my applications. I'm using log4j v 1.2.13 and chainsaw v2. I have two applications running on the same server and both are using a socketHubAppender on different ports. I don't have any location info so the default PROP.hostName - PROP.application only separates by hostname and since I'm running two apps on the same server I get both logs dumped to the same tab. I've tried adding PROP.remoteSourceInfo (since that is a column in the logs that shows up and has the port number listed) and that property appears to return nothing. It's my understanding that the location info does not work in log4j 1.2.X. So my question is two fold. Is there some reference that I can look at that will tell me what properties are available, and can someone tell me how I would go about doing this? I see in the comments for LoggingEventFieldResolver the following field are available but nothing here seems like it will work for me. Plus there seems to be no explanation of what keyName is in PROP.keyName. * Field NameField value (String representationReturn type * LOGGERcategory name (logger)String * LEVEL level Level * CLASS locationInformation's class name String * FILE locationInformation's file name String * LINE locationInformation's line number String * METHODlocationInformation's method name String * MSG message Object * NDC NDC String * EXCEPTION throwable string representation ThrowableInformation * TIMESTAMP timestamp Long * THREAD threadString * PROP.keyName entry in the Property hashtable
RE: Chainsaw Tab identifier
Properties in Chainsaw are any name/value pair -property- associated with a received event - they are displayed in their own column in the event table. MDC entries show up as properties in Chainsaw. Any arbitrary name/value pair can be added as properties to events, and MDC is one way to get those properties set (another is the 'application' param on socketappender). In the log4j receivers companion, there is a rewrite appender through which you can add properties to all events processed by an appender: http://logging.apache.org/log4j/companions/receivers/apidocs/org/apache/ log4j/rewrite/package-summary.html In Chainsaw, the documentation mentioning 'PROP.keyname' is shorthand for the name of any property associated with an event. 'application', 'log4jid', 'hostname' and 'log4j.remoteSourceInfo' are the only log4j-provided property names if I recall. application, hostname and log4j.remoteSourceInfo are provided by the network-related appenders. Log4jid is created on the Chainsaw side to support event ordering. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 12:16 PM To: Log4J Users List Subject: Re: Chainsaw Tab identifier Thanks Scott that was very helpful (and fast). Am I missing the reference to what Prop keyNames are available? It would be nice to know what is available (who knows maybe I'll find something i didn't know i couldn't live without). Even if it's just a matter of looking at the right javadocs that's enough. I'd just like to be able to tinker on my own. Thanks for all your hard work. Chainsaw is pretty cool. Jason Tholstrup Software Engineer [EMAIL PROTECTED] On Mar 3, 2008, at 11:42 AM, Scott Deboy wrote: Two things: 1. To get every socketappender connection to display in its own tab in Chainsaw, use PROP.log4j.remoteSourceInfo as the tab identifier (note the log4j. in front of the property name - log4j. isn't some special property name, that's just the name of the property). 2. The 'application' property on socketappender is how you route events to different tabs when the two apps are running on the same server and using socketappender. Here's an example of that config: appender name=SOCKET class=org.apache.log4j.net.SocketAppender param name=remoteHost value=localhost/ param name=LocationInfo value=true/ param name=port value=4560/ param name=application value=someappname/ /appender Use a different value in the 'application' param for each of the socketappender configs and you should be fine. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 9:24 AM To: log4j-user@logging.apache.org Subject: Chainsaw Tab identifier Hello, I'm trying to figure out what things I need to place in my Tab identifier field to filter out my applications. I'm using log4j v 1.2.13 and chainsaw v2. I have two applications running on the same server and both are using a socketHubAppender on different ports. I don't have any location info so the default PROP.hostName - PROP.application only separates by hostname and since I'm running two apps on the same server I get both logs dumped to the same tab. I've tried adding PROP.remoteSourceInfo (since that is a column in the logs that shows up and has the port number listed) and that property appears to return nothing. It's my understanding that the location info does not work in log4j 1.2.X. So my question is two fold. Is there some reference that I can look at that will tell me what properties are available, and can someone tell me how I would go about doing this? I see in the comments for LoggingEventFieldResolver the following field are available but nothing here seems like it will work for me. Plus there seems to be no explanation of what keyName is in PROP.keyName. * Field NameField value (String representationReturn type * LOGGERcategory name (logger)String * LEVEL level Level * CLASS locationInformation's class name String * FILE locationInformation's file name String * LINE locationInformation's line number String * METHODlocationInformation's method name String * MSG message
RE: Chainsaw Tab identifier
SocketHubAppender doesn't have the 'application' property support built into the appender like 1.2.15 socketappender does, so to use the application property with sockethubappender, you'd have to: - use log4j 1.2.15 on the appender side - also include the receivers companion in the classpath - specify a rewriteappender which adds the 'application' property and forwards events to the sockethubappender I haven't tested that, but it should work.. Btw, log4j 1.3 sockethubappender supported a 'buffersize' param which would forward the last X events to the connecting sockethubreceiver, but it doesn't look like that was back-ported to log4j 1.2.15. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 12:57 PM To: Log4J Users List Subject: Re: Chainsaw Tab identifier Sorry Scott I had not tried your instructions before I replied last time. I can get PROP.log4j.remoteSourceInfo to show up in my tab identifier but PROP.application does not seem to work (which to be honest is much closer to what I want). I've seen that there is an issue with the serialized object translation from the 1.2.X branch to the 1.3 based chainsaw v2 download, and I don't receive Class, Method, File, or Line information in my logs. Is this possibly the reason PROP.application does not show up, or is there something else I have missed? Here is the log4j.properties snippet for my app. I've bounced my server container just to make sure it reloaded and PROP.application continues to return nothing in chainsaw log4j.properties sinppet (on server) log4j.appender.HUB=org.apache.log4j.net.SocketHubAppender log4j.appender.HUB.port=9005 log4j.appender.HUB.LocationInfo=true log4j.appender.HUB.Threshold=DEBUG log4j.appender.HUB.application=SES Test Tab identifier string PROP.application - PROP.log4j.remoteSourceInfo chainsaw.xml ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/; debug=true plugin name=SocketHubReceiver class=org.apache.log4j.net.SocketHubReceiver param name=host value=devocs.theebsgroup.com/ param name=port value=9004/ param name=reconnectionDelay value=3/ param name=name value=devocs SES/ /plugin root level value=debug/ /root /log4j:configuration Jason Tholstrup On Mar 3, 2008, at 11:42 AM, Scott Deboy wrote: Two things: 1. To get every socketappender connection to display in its own tab in Chainsaw, use PROP.log4j.remoteSourceInfo as the tab identifier (note the log4j. in front of the property name - log4j. isn't some special property name, that's just the name of the property). 2. The 'application' property on socketappender is how you route events to different tabs when the two apps are running on the same server and using socketappender. Here's an example of that config: appender name=SOCKET class=org.apache.log4j.net.SocketAppender param name=remoteHost value=localhost/ param name=LocationInfo value=true/ param name=port value=4560/ param name=application value=someappname/ /appender Use a different value in the 'application' param for each of the socketappender configs and you should be fine. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 9:24 AM To: log4j-user@logging.apache.org Subject: Chainsaw Tab identifier Hello, I'm trying to figure out what things I need to place in my Tab identifier field to filter out my applications. I'm using log4j v 1.2.13 and chainsaw v2. I have two applications running on the same server and both are using a socketHubAppender on different ports. I don't have any location info so the default PROP.hostName - PROP.application only separates by hostname and since I'm running two apps on the same server I get both logs dumped to the same tab. I've tried adding PROP.remoteSourceInfo (since that is a column in the logs that shows up and has the port number listed) and that property appears to return nothing. It's my understanding that the location info does not work in log4j 1.2.X. So my question is two fold. Is there some reference that I can look at that will tell me what properties are available, and can someone tell me how I would go about doing this? I see in the comments for LoggingEventFieldResolver the following field are available but nothing here seems like it
Re: Chainsaw Tab identifier
I'm sure you get this a lot but after reading quite a few posts I am still kind of confused: The lineage between the 1.3 and 1.2 branches is very hazy. From what i can tell 1.3 is essentially dead and that 1.2 is the recommended version to use. As for chainsaw, should I be using the v2 that is available directly on apache's web site? This appears to be based on version 1.3 code if I read correctly. Should I instead be using version 1.2.15 and using the chainsaw client available from there as well as using log4j 1.2.15 on my appender side? I've seen posts mentioning getting the latest 1.2.15 version from svn to get the right version of chainsaw. Is that now current with the latest release or do I still need to tread into the waters of a nightly build? On the back porting effort, what is the status there? Is that completed and that is the purpose of 1.2.15? Is that just a partial back-port with more to come? Is that a partial back-port and that's the end of the road? And finally we have a third party app we were trying to get logging working under that is using 1.2.9. Could we safely drop in 1.2.15 and be able to configure our appenders as you describe (we have access to the log4j.properties file on the server)? Thanks for being patient and walking me through all of this. You've easily save me a couple of days of bumbling around trying to get this to work. Jason Tholstrup Software Engineer [EMAIL PROTECTED] On Mar 3, 2008, at 3:52 PM, Scott Deboy wrote: SocketHubAppender doesn't have the 'application' property support built into the appender like 1.2.15 socketappender does, so to use the application property with sockethubappender, you'd have to: - use log4j 1.2.15 on the appender side - also include the receivers companion in the classpath - specify a rewriteappender which adds the 'application' property and forwards events to the sockethubappender I haven't tested that, but it should work.. Btw, log4j 1.3 sockethubappender supported a 'buffersize' param which would forward the last X events to the connecting sockethubreceiver, but it doesn't look like that was back-ported to log4j 1.2.15. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 12:57 PM To: Log4J Users List Subject: Re: Chainsaw Tab identifier Sorry Scott I had not tried your instructions before I replied last time. I can get PROP.log4j.remoteSourceInfo to show up in my tab identifier but PROP.application does not seem to work (which to be honest is much closer to what I want). I've seen that there is an issue with the serialized object translation from the 1.2.X branch to the 1.3 based chainsaw v2 download, and I don't receive Class, Method, File, or Line information in my logs. Is this possibly the reason PROP.application does not show up, or is there something else I have missed? Here is the log4j.properties snippet for my app. I've bounced my server container just to make sure it reloaded and PROP.application continues to return nothing in chainsaw log4j.properties sinppet (on server) log4j.appender.HUB=org.apache.log4j.net.SocketHubAppender log4j.appender.HUB.port=9005 log4j.appender.HUB.LocationInfo=true log4j.appender.HUB.Threshold=DEBUG log4j.appender.HUB.application=SES Test Tab identifier string PROP.application - PROP.log4j.remoteSourceInfo chainsaw.xml ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/; debug=true plugin name=SocketHubReceiver class=org.apache.log4j.net.SocketHubReceiver param name=host value=devocs.theebsgroup.com/ param name=port value=9004/ param name=reconnectionDelay value=3/ param name=name value=devocs SES/ /plugin root level value=debug/ /root /log4j:configuration Jason Tholstrup On Mar 3, 2008, at 11:42 AM, Scott Deboy wrote: Two things: 1. To get every socketappender connection to display in its own tab in Chainsaw, use PROP.log4j.remoteSourceInfo as the tab identifier (note the log4j. in front of the property name - log4j. isn't some special property name, that's just the name of the property). 2. The 'application' property on socketappender is how you route events to different tabs when the two apps are running on the same server and using socketappender. Here's an example of that config: appender name=SOCKET class=org.apache.log4j.net.SocketAppender param name=remoteHost value=localhost/ param name=LocationInfo value=true/ param name=port value=4560/ param name=application value=someappname/ /appender Use a different value in the 'application' param for each of the
RE: Chainsaw Tab identifier
log4j 1.3 is abandoned - the useful bits were (mostly) backported to log4j 1.2.15 with a few 'companion' downloads providing the non-core functionality added to 1.3. There are a few caveats: - Chainsaw V2 trunk (built against log4j 1.2.15) has not yet been released. Once it is released, location info will work again. - The version of Chainsaw available via web start is based on log4j 1.3, so location info won't work - The component, receivers and zeroconf 'companions' have not yet been officially released - the 'extras' companion has been officially released (meaning any not-yet-released companions need to be built from source..) Since Chainsaw V2 built against log4j 1.2.15 (along with the receivers and other companions) have yet to be officially released, it's a pain to build Chainsaw on the trunk (maven dependencies on snapshots...ug). As for compatibility between log4j 1.2.15 (and Chainsaw V2) and prior versions, Chainsaw V2 should work fine with log4j 1.2.9 (including support for location info). Everything we wanted to keep -should- already be backported to log4j 1.2.15 + companions..the sockethubappender buffer issue is one that was missed.. Once everything is released, it'll be a lot easier to build from sources. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 2:30 PM To: Log4J Users List Subject: Re: Chainsaw Tab identifier I'm sure you get this a lot but after reading quite a few posts I am still kind of confused: The lineage between the 1.3 and 1.2 branches is very hazy. From what i can tell 1.3 is essentially dead and that 1.2 is the recommended version to use. As for chainsaw, should I be using the v2 that is available directly on apache's web site? This appears to be based on version 1.3 code if I read correctly. Should I instead be using version 1.2.15 and using the chainsaw client available from there as well as using log4j 1.2.15 on my appender side? I've seen posts mentioning getting the latest 1.2.15 version from svn to get the right version of chainsaw. Is that now current with the latest release or do I still need to tread into the waters of a nightly build? On the back porting effort, what is the status there? Is that completed and that is the purpose of 1.2.15? Is that just a partial back-port with more to come? Is that a partial back-port and that's the end of the road? And finally we have a third party app we were trying to get logging working under that is using 1.2.9. Could we safely drop in 1.2.15 and be able to configure our appenders as you describe (we have access to the log4j.properties file on the server)? Thanks for being patient and walking me through all of this. You've easily save me a couple of days of bumbling around trying to get this to work. Jason Tholstrup Software Engineer [EMAIL PROTECTED] On Mar 3, 2008, at 3:52 PM, Scott Deboy wrote: SocketHubAppender doesn't have the 'application' property support built into the appender like 1.2.15 socketappender does, so to use the application property with sockethubappender, you'd have to: - use log4j 1.2.15 on the appender side - also include the receivers companion in the classpath - specify a rewriteappender which adds the 'application' property and forwards events to the sockethubappender I haven't tested that, but it should work.. Btw, log4j 1.3 sockethubappender supported a 'buffersize' param which would forward the last X events to the connecting sockethubreceiver, but it doesn't look like that was back-ported to log4j 1.2.15. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Jason Tholstrup [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2008 12:57 PM To: Log4J Users List Subject: Re: Chainsaw Tab identifier Sorry Scott I had not tried your instructions before I replied last time. I can get PROP.log4j.remoteSourceInfo to show up in my tab identifier but PROP.application does not seem to work (which to be honest is much closer to what I want). I've seen that there is an issue with the serialized object translation from the 1.2.X branch to the 1.3 based chainsaw v2 download, and I don't receive Class, Method, File, or Line information in my logs. Is this possibly the reason PROP.application does not show up, or is there something else I have missed? Here is the log4j.properties snippet for my app. I've bounced my server container just to make sure it reloaded and PROP.application continues to return nothing in
