Logging Best Practices Using Crypto Logger

Logging can be an invaluable tool during all stages of software development right from development to deployment/production. Good use of logging enables you to record and report errors, maintain audit trials, gather app usage statistics and gather performance benchmarks. The following are best practices to be used when using logging in your software:

Know Who Will Consume And Analyze The Logs

Logging output should make sense to the people who will view/Analyze the logs. For example, logging information targeted at developers will typically be quite different from that targeted at end-users which in turn will be different from that targeted at system-administrators. For example, end users are likely to have no use for your logs if you output messages like "Heap error in function ABC" or "Lock cannot be acquired for polling". Generating the correct type of logging info is important so that the log information can actually be used and understood by the consumers of the logs.

Decide Beforehand What Type Of Messages Should Be Used For Each Log Level

Loggers typically provide multiple log levels using which messages can be logged. Each level indicates a different level of severity and/or detail. Typical levels defined are Debug, Info, Warning, Error and Fatal. It is important that all the members of your team agree beforehand on the type of messages to be used with each log level. This is necessary so that a log generated during a routine run of the software does not get flooded with Debug log messages. Similarly, important information which should have the Warning, Error or Fatal levels should not be logged using the Debug or Info levels. Since there are no hard and fast rules for what constitutes the informational detail and/or severity associated with each level, it is upto your team to decide this beforehand.

Crypto Logger provides the following levels and guidelines/conventions for when each level should be used:

Log Only As Much As Needed

Logging code is not free - it increases the size of your code and your compiled binaries. Further, the logging code itself consumes processor time to run. Logging code also requires maintenance just like any other code. Keep these factors in mind when deciding how much and what type of data to log. You should not log the code execution progress after each line of code, nor should you produce useless logs contain very little info like "Failure!". Use your judgment when deciding the quantity and quality of data to log that will provide useful information when it actually comes time to view and Analyze the logs to resolve issues or gather statistics.

Use External Configuration Files

Logging should be configured via an external configuration file so that the log outputs, level, verbosity, etc can be easily configured without having to recompile your software.

Crypto Logger supports simple XML configuration files. It can also watch external configuration files for changes - if the file changes, Crypto Logger will automatically reconfigure itself using the changed file.

Ship Production Apps With Logging Configured To Produce Less Log Information

Typically, you should ship production apps that are configured (via external configuration files) to only output Info, Warning, Error Or Fatal log messages. Only if the software encounters a problem should it be configured (again, via a configuration file) to output Debug level log messages which can help in trouble-shooting the problem.

Use Buffered Mode To Avoid Repeated Costly Writes To Disk, Network, etc

If you output log messages to targets like disks, or tcp, which are costly in terms of write times, considered using the buffered mode of your logging software. When a certain quantity of log data is Buffered, all Buffered log data is written at once which typically saves a considerable amount of time.

Crypto Logger has full support for buffered mode and various triggers which induce flushing.

Use Asynchronous Mode For Performance Critical Code

When logging from performance-critical code, consider using the Asynchronous mode of your logging software. In Asynchronous mode, log data is Buffered and is written on a background thread so that your performance-critical code does not wait for the log data to be written.

Crypto Logger has full support for asynchronous mode.

Prepare Data To Be Logged Only If Logging Is Enabled At The Desired Level

Before formatting or otherwise preparing the data to be logged, check that logging is enabled at the desired level so that time is not wasted in the formatting/preparation of the data.

For example, instead of doing this:

log.MainSession.LogMessage(string.Format("Current time is {0}",DateTime.Now));

use following code:

if(log.MainSession.IsEnabled(LogEntryLevel.Debug))
    log.MainSession.LogMessage(string.Format("Current time is {0}",DateTime.Now));

Crypto Logger comes with log method overloads which take all format parameters so that you do not have to check for level and your code remains clean and minimal.

Keep Logging Code Error Free

You should take care that the logging code itself does not cause undesirable effects. The logging code should remain as transparent as possible to the actual execution of the software and should not cause exceptions, errors, deadlocks, slowness or other undesirable effects.

This is the overriding principle that is used in the design of Crypto Logger - logging should not alter the behavior or flow of your software. Any exceptions or errors that occur during logging are handled gracefully and the execution of the host software continues uninterrupted.

Keep Logging Code In Sync With The Software Code

Many times, the code surrounding the logging code changes, but the log messages are not changed or removed or added to reflect the changed code. Such out-of-sync logging code may not be very useful in providing helpful information when the log is viewed or analyzed. So, just like comments, it is important that the log messages and logging code is updated when the software code changes.

Crypto Logger:   Download  -  Buy Now  -  More Info.  Have a question? Contact us.