'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...
Last week, I attended meta::hack, the MetaCPAN hackathon
in Chicago. I'm the maintainer for CPAN Testers, the
central database for CPAN users to send in test reports on CPAN distributions
and one of MetaCPAN's data sources. I asked to join them so I could improve how
MetaCPAN consumes CPAN Testers data, and ensure the stability and reliability
of that consumption.
Here's a detailed log of what I was able to accomplish, and information on the
new development of CPAN Testers.
Continue reading meta::hack log...
This week, I released a new version of
Beam::Emitter. A lot has changed since
the first releases, so here's some details on all the new features.
Beam::Emitter is a role for turning your classes into event emitters. Being an
event emitter allows other classes to subscribe to important events from your
object. Subscribers can use these events to perform additional tasks, transform
your object's data, or otherwise extend and enhance your class. Beam::Emitter
makes your class extensible by allowing you to provide specific places for
custom code to run.
Since the 1.000 release last year, Beam::Emitter has gotten quite a few new
features and bug fixes to make it easier to use and safer for your code.
Continue reading Beam::Emitter v1.004 released...
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...