Like all subjective decisions in technology, which log level to use is the cause of much angry debate. Worse, different logging systems use different levels: Log4j has 6 severity levels, and Syslog has 8 severity levels. While both lists of log levels come with guidance as to which level to use when, there's still enough ambiguity to cause confusion.

When choosing a log level, it's important to know how visible you want the message to be, how big of a problem it is, and what you want the user to do about it. With that in mind, this is the decision tree I follow when choosing a log level:

Continue reading Choosing a Log Level...

'Twas a night before Christmas and on the ops floor
All the servers were humming behind the closed door
The app was deployed to the servers with care
In hopes that the customers soon would be there
When from out of the phone there arose such a clatter
I sprang out of my chair to see what was the matter
"The website is down!" said the boss with a shout
"We need to make money, so figure it out!"
I logged in to the server and looked all around
But the app had no logging; no reason was found
With no other choice, I called the developer
Who said "just restart it, I'm sure that'll fix 'er"
I ran the right service, up the app came
Only to come down again and again
If there but was a way to know what was wrong
I could fix it for sure, but no logging was found

Good logging is crucial for applications in production. In an emergency, you will want it to be as easy as possible to track down problems when they happen. With good logs you can ensure that minor bugs don't cause major downtime and data loss problems. Good logs can help track down security issues and can provide an auditable trail of changes to track down who did what and when.

Log::Any is a lightweight, generic API built for interoperable logging for CPAN modules. Much like DBI allows interoperable database interfaces, CHI allows interoperable caching interfaces, and PSGI allows interoperable web applications, Log::Any allows a CPAN module to produce logs that fit into your environment whether you just want to see logs on your terminal, you're using Log4perl to directly send e-mail alerts to your operations team, or you're using a local rsyslog daemon to transmit logs to an ElasticSearch instance via Logstash.

Continue reading Yuletide Logging...

A new trial of Log::Any (1.044) has been released. This release has a couple changes that make Log::Any a bit more predictable:

• Passing in objects to formatted log methods now handles objects that overload stringify correctly. Previously, these objects would be given to Data::Dumper, which violates object encapsulation. Thanks Philipp Gortan (@mephinet)!
• The imported Log::Any object (use Log::Any '$log') can now be named anything (like $LOG or $foo).

Since CPAN Testers is still catching up from its little bit of downtime a few weeks ago, I won't be releasing this as stable until I get some success reports in. So, you've got some time to test this against your own codebase if you need to. Please report any issues to the Log-Any Github repository.

Since CPANTesters for Log-Any are all showing green for last week's trial release, I've pushed a new standard release of Log::Any 1.042 to CPAN.

Continue reading Log::Any 1.042 Released...

I've just released a new Log::Any trial release. This release improves performance immensely when there are no log output adapters configured. This release also now returns the formatted log string from logging methods, allowing the log message to be used by a die or warn call.

Because of these changes, there is a very small chance of an incompatibility: Log::Any logging methods used to return whatever the configured adapter returned (this was undocumented and was not a feature). Now they always return the formatted log message.

So if you depend on Log::Any, please give Log-Any-1.041-TRIAL a test run through and report any issues to the Log-Any Github tracker.