Categories
PHP Randomness Zend Framework

Just a Log

Applications, especially ones that run over and over again with zero persistancy (of the application itself) like a web app needs logging. It’s important to be able to log different types of messages to different places and fortunately Zend_Log is so extensible that it can log to almost anything you can think of.

My typically logging setup consists of multiple log writers configured in Zend_Log to allow me to control where and how certain messages get logged.

Broken down into logging levels I usually have ‘debug’, ‘info’, ‘notice’ all sent to a single file and not enabled in production.
Warnings and Errors are usually considered runtime-issues that are not “omg! it’s broken!” issues, so they get logged to a file and are enabled on production. The last three levels, ‘alert’, ‘crit’, ’emerg’ are all considered to be top priority – aka – your application is failing. And as such these get logged to a file and emailed immediately to a person of importance.

In all cases, in my development environment, all log messages utilize Zend’s Firebug support.

Fortunately Zend_Log supports all this complexity with a very simple set of configuration options.

It’s all done with a few lines of settings in your application.ini file and voila, magic.

Here’s how to bootstrap your logger and set it to a Zend_Registry key for easy use:


protected function _initRegisterLogger() {
    $this->bootstrap('Log');
    $logger = $this->getResource('Log');
    Zend_Registry::set('Zend_Log', $logger);
}

And here’s a sample application.ini – with omitted portions so you can just see the logging items.


[production]
; the operand param doesn't allow for y > 4 & y < 7 so we need multiple writers.
resources.log.production.writerName = "Stream"
resources.log.production.writerParams.stream = APPLICATION_PATH "/logs/production-critical.log"
resources.log.production.filterName = "Priority"
resources.log.production.filterParams.priority = 3
resources.log.production.filterParams.operand  = "<"
resources.log.production1.writerName = "Stream"
resources.log.production1.writerParams.stream = APPLICATION_PATH "/logs/production-errors.log"
resources.log.production1.FilterName = "Priority"
resources.log.production1.filterParams.priority = 4
resources.log.production1.filterParams.operand  = "="
resources.log.production2.writerName = "Stream"
resources.log.production2.writerParams.stream = APPLICATION_PATH "/logs/production-warning.log"
resources.log.production2.filterName = "Priority"
resources.log.production2.filterParams.priority = 5
resources.log.production2.filterParams.operand  = "="

[testing : production]
resources.log.testing.writerName = "Stream"
resources.log.testing.writerParams.stream = APPLICATION_PATH "/logs/testing-notices.log"
resources.log.testing.filterName = "Priority"
resources.log.testing.filterParams.priority = 5
resources.log.testing.filterParams.operand  = "="
resources.log.testing1.writerParams.stream = APPLICATION_PATH "/logs/testing-info.log"
resources.log.testing1.filterName = "Priority"
resources.log.testing1.filterParams.priority = 6
resources.log.testing1.filterParams.operand  = "="

[development : testing]
; this logs all messages
resources.log.testing.writerName = "Stream"
resources.log.testing.writerParams.stream = APPLICATION_PATH "/logs/debug.log"
resources.log.testing1.filterName = "Priority"
resources.log.testing1.filterParams.priority = 7
resources.log.testing1.filterParams.operand  = "="
; no filter on firebug, logs everything.
resources.log.firebug.writerName = "Firebug"
Categories
Linux

I Finally Upgraded to Debian 5

On my production web server, I’m kind of a crazy fool.  I often do things that make people cringe and scream and say “what the hell are you doing?”

One of those said things is doing a distribution upgrade on-the-fly of the OS.  Since the installation of my server some three and a half years ago, Debian has had two major releases.  My server started with sarge, upgraded to etch, then upgraded again to lenny.  Unfortunately this time after 1210 days without rebooting my server I was forced to reboot. That is to say, since I installed my server where it lives it had never been rebooted.

The reboot occurred because the new libc required kernel 2.6. I was still cooking with an old 2.4 kernel.  After a pile of apt-get trickery, I got the necessary packages installed and had to reboot.  Once the 2.6 kernel was up and running everything else installed without a hitch.  I had to track down a few configuration changes with a couple of things, but overall I think the upgrade went smooth and with only a few minutes of downtime.  Not bad, I say, not bad.