logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ennidhi <psatishb...@hotmail.com>
Subject RE: log.txt
Date Wed, 17 Mar 2010 09:56:50 GMT


Bradley Ward-3 wrote:
> The main thing that I see in your log file is that you are logging what
> are very low level events within your application (entering a screen,
> leaving a screen) at the INFO level. I seriously doubt you will want to
> see low level events like that ALL the time for EVERY user once your
> application is in production use. Most of your log statements look to be
> to be more appropriate for DEBUG messages, not INFO messages.
> I work with both Java and .Net, and I use log4j in the Java applications
> and log4net in the .Net applications. Four or five years ago I wrote some
> general usage instructions for using logging. I originally wrote it for
> Java developers, then later quickly adapted it for log4net users, so you
> will see a mix of those references in the text. Also, my own usage of
> log4net has evolved some since I wrote this document.
> But I will include the text from this document below in hopes you can find
> something useful in it...
> Brad
> Logging Recommendations
> A production quality software system must perform all required business
> related functionality in a dependable and responsive manner. But it must
> also be constructed in such a way that when problems do occur (and they
> will), the problems can be quickly diagnosed on the production system
> while minimizing the disruption of service via any “bouncing” of the
> application server.
> The open source log4j logging package is by far the most widely used
> logging system for production systems written on the Java platform.  Log4j
> is an excellent choice because it is very flexible, highly efficient, and
> widely understood by most Java developers. But there are number of
> requirements that Log4j does not directly address “out of the box”, and
> there are other benefits that can be obtained from Log4j if it is properly
> designed and used in the production application. 
> Missing “Out of the Box” Features
> Automatic Re-Configuration at Runtime
> During development time, any class or method of any complexity should
> include debug level messages wrapped within “if (log.isDebugEnabled())”
> blocks of code. During production use of the application plain vanilla
> log4j provides no method for selectively turning debug logging on or off.
> The only option, therefore, is to bounce the application server to turn
> debug logging on by modifying the log4j.properties file, then bouncing the
> application server once again to turn the logging back off.
> Debug Settings Logging
> Closely related to the previous paragraph is the ability to see the
> current log4j settings.  If good, informative debug messages are coded
> into the application, then leaving DEBUG enabled for long periods of time
> can easily result in huge log files. In the extreme, this in itself can
> destabilize a production system by consuming all available disc space. The
> plain vanilla log4 code has no simple mechanism for displaying the current
> settings.
> Flexible One Line Instantiation
> When properly applied to a code base, Logger instance will be created in
> almost every class in the system. Because it is so frequently used, it is
> important that it be employed in as simple and as efficient a manner as
> possible, preferable with a one line instantiation statement that ensures
> the proper initialization of the Log4j system at the application level.
> Log4j Extension Recommendations
> The following section contains a set of extensions (code) that if
> implemented will maximize the benefit of Log4j use in the application, and
> will address some of the above mentioned issues.
> Implement a Log4j Utility Class
> A Log4j utility class should be developed with the following features. 
> For the purpose of this discussion, this utility class will be referred to
> as Log4jUtil.
> •	A set of static methods very similar to the Logger getLogger methods
> provided by the basic Logger class, but with a few enhancements. The
> following getLogger methods should be provided:
> o	Logger getLogger(Class myClass)
> This method is designed for creating class level Logger instances by
> simply calling Log4jUtil.getLogger(MyClass.class).  This method will call
> the Log4jUtil.init() method,then simply call
> Logger.getInstance(myClass.getName()).
> o	Logger getLogger(Object thisPtr)
> This method is designed for creating instance level Logger instances by
> simply calling Log4jUtil.getLogger(this).  This method will call the
> Log4jUtil.init() method,then simply call
> Logger.getInstance(thisPtr.getClass().getName()).
> The standard Logger.getInstance() method should never be used in the
> application code base. Instead, all Logger instances should be created via
> the use of one of these two Log4jUtil static methods. Why? Because this
> ensures that the Log4jUtil.init() method is always run correctly before
> any use of Log4j.
> •	The static Log4jUtil.init() method that is called by both of the above
> described getLogger methods is critical to this approach, because it is in
> this method that we ensure that the Log4j environment is properly
> initialized. The code in this init() class must perform the following
> actions.
> o	Resolve the full path of the log4j.properties file via inspection of the
> standard log4j.configuration environment variable. If the file cannot be
> located, a fatal exception should be thrown so that the application cannot
> run without proper logging initialization.
> o	Load the properties file using the standard log4j procedures.
> o	Document the initial settings by calling the Log4jUtil document method
> described below.
> o	Instantiate and activate the configuration file watchdog class described
> below. This activation enables the automatic reconfiguration of the log4j
> settings at runtime without the need to bounce the application.
> •	The Log4jUtil class should contain a “print” or “toString” or “document”
> method that will produce a nicely formatted String that documents the
> current logger settings. These settings are obtained via the standard
> LogManager.getCurrentLoggers() method.
> Implement a Configuration File Watchdog Class
> In order to extend the log4j system use so that it will automatically
> detect changes to the log4j.properties file at runtime and reload the
> properties, a configuration file watchdog class should be implemented and
> initialized in the Log4jUtil.init() method as described above.
> The standard Log4j package contains a nice utility class named
> FileWatchdog that provides most of this functionality out of the box.
> Simply use the FileWatchdog class as the base class for a custom watchdog
> class, then implement the required doOnChange() method.
> The doOnChange() method simply reloads the log4j.properties file, then
> calls the above described “print” method to document the new settings that
> were just loaded from the modified properties file. Producing
> documentation of the new settings each time the file is changed is
> important, because this allows the production log file to be monitored
> when troubleshooting a production problem.
> The recommended delay value for the watchdog class is 1 minute. This is
> infrequent enough that it will not cause any performance degradation, but
> frequent enough to allow near real time modifications of the log settings
> when diagnosing a production problem.
> Log4j Application Recommendations
> The previous section describes additional software that will enhance the
> basic out of the box Log4j system. The following section contains
> suggestions on how the Log4j application should be used for maximum
> effect.
> Do NOT Use Logger.getLogger!
> In order to ensure the Log4j system is initialized in the proper manner,
> it is critical that the basic Logger.getLogger() method not be used, as
> this bypasses the proper initialization of the Log4j usage within the
> application.
> Implement For Long Term Use
> Logging is certainly very useful during initial code development, but if
> logging use is not specifically designed for long term use, its overall
> value to the system will be severely marginalized.  At some point in the
> development process, the developer of each module should carefully
> evaluate the use of logging statements in each class. This should also be
> part of any formal code review sessions performed on each class.
> The following are suggested questions to ask during this code evaluation
> process:
> •	Six months after this code is in production, if a problem arises, will I
> be able to turn on DEBUG and get detailed information on the operation of
> this class or method?
> •	Will the information output by any DEBUG statements in this code be
> meaningful to anyone other than the original developer?
> •	Is the output from the message formatted well enough to convey
> information without having to perform a detailed study of the actual
> source code in able to understand its meaning (Example: Do
> “log.debug(“MyClass status = “ + getStatus())” instead of simply
> “log.debug(getStatus())”).
> •	Does the information output by any DEBUG statements contain a sufficient
> level of detail to allow accurate and complete diagnosis of module/method
> operation? Remember that once the software is in production, adding
> another line of code to log additional information is generally not an
> option assuming careful QA and release procedures are followed.
> •	Are all but the most trivial log.debug statements protected by a “if
> (log.isDebugEnabled())” block?  The Logger class is carefully designed and
> very efficient at minimizing any processing if DEBUG is not enabled for
> that particular logger. But if the String argument passed to the log.debug
> statement itself is complex, this in itself can impose significant costs
> in runtime performance, and should be avoided. 
> Remove Any Short Term Debug Messages
> At the end of the development phase of the project and before deployment
> to the production system, any log.debug statements that were introduced
> into the code base purely for use by the developer should be removed. A
> statement such as log.debug(“Got here”) rarely has any use once the code
> is in production.
> “Verticalize” The Log4j Use
> A well designed software application normally has many implementation
> layers. For example in a servlet or Struts application, there are top
> level servlet or action classes that are essentially the “main program”
> for that particular application function, and there are normally multiple
> layers of reusable code below this top level layer that also have
> considerable complexity that may need to be monitored and diagnosed using
> log output.
> A very standard way of creating a Logger instance for a given class is to
> have a class level Logger instance defined as follows:
> Private static final Logger log = Log4jUtil.getLogger(MyClass.class);
> But consider the implications of this style of usage if this class is a
> utility class that is used in a web application that contains 200 screens
> and therefore 200 JSP pages, servlets, or Action classes.  If you turn on 
> DEBUG fort this class to troubleshoot a single screen that is problematic,
> your log file is suddenly flooded with thousands and thousands of DEBUG
> level messages that are output by every one of the 200 screens in this web
> application. This not only can severely impact performance in a heavily
> used web application, it also makes the job of locating the particular
> debug message for the particular screen of interest very difficult and
> time consuming.
> A far better approach is to verticalize the use of Log4j by following
> these suggestions when using log4j in reusable classes within the
> application:
> 1.	Use the getLogger(MyClass.class) method of instantiating a Logger
> instance for “top level” classes such as Struts Action classes, servlet
> classes, or .jsp files. This allows DEBUG to be enabled for very specific
> functionality within the application.
> 2.	For utility classes that are stateful, i.e. an instance is created and
> then a series of method calls are performed on the instance, pass in a
> Logger instance as a part of the constructor for this utility class. Doing
> this in the 200 screen web application mentioned above makes it possible
> to turn on DEBUG output from this utility class, but only when that class
> is used for a single portion of the application, not for all use within
> the application as described above.
> 3.	For static methods of utility classes, pass in a Logger instance as a
> parameter to the static method. Once again, this technique allows DEBUG
> output to be obtained from a very highly used utility method but only in
> conjunction with a single top level module of interest.
> Class Hierarchy Use
> In a good object oriented design there are frequently base classes that
> are then extended one or more levels by derived classes. Significant
> functionality is often encapsulated into these base classes for reuse by
> the derived classes. 
> If the Logger instance used in a base class is created using the standard
> getLogger(MyClass.class)method of instantiation, turning on DEBUG for this
> logger suffers the same problem as addressed in the previous section; too
> much information is logged because logging is turned on for all instances
> of all derived classes. In addition, the logger name typically displayed
> in the log file will be the name of the base class, not the name of the
> derived class, which makes the determination of which message comes from
> the derived class of interest hard to determine when studying the log
> file.
> In this usage scenario, the recommended approach is to use an instance
> level Logger instance in the base class instead of a class level (i.e.
> static) instance. This instance level should be created in the base class
> constructor simply by doing a Log4jUtil.getLogger(this) call. Note that
> since the actual class type of the this pointer is that of the derived
> class not the base class, the logger will actually be associated with the
> derived class and not the base class, thus producing more informative log
> messages and allowing more detailed control when enabling/disabling DEBUG
> in the application.
> -----Original Message-----
> From: ennidhi [mailto:psatishbabu@hotmail.com] 
> Sent: Friday, January 22, 2010 8:23 AM
> To: log4net-user@logging.apache.org
> Subject: log.txt
> Hi,
>    I have implemented the log4net in my project. I have created the log
> file
> using the rollingfileappender. My log file contains mostly info and few
> errors. I wonder is it the right way to implement? since I have not used
> warn fatal error etc. I only used info, error and debug. I am attaching
> the
> log for the reference. http://old.nabble.com/file/p27273055/log.txt
> log.txt 
>   And I have given settings like this in the web.xml. Is it ok to make
> this
> size files? I know it depends on the BA but out of curiosity I am asking
> this question.
> •  Maximum size occupied by the logs would be 50MB *10  = 500MB.
> -- 
> View this message in context:
> http://old.nabble.com/log.txt-tp27273055p27273055.html
> Sent from the Log4net - Users mailing list archive at Nabble.com.

View this message in context: http://old.nabble.com/log.txt-tp27273055p27929728.html
Sent from the Log4net - Users mailing list archive at Nabble.com.

View raw message