Latest sites

Quick news

  • 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
  • 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
  • 2013-10-18: My first commit went into MongoDB today. And, guess what ? It's in JavaScript
  • 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
  • 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
  • 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
  • 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ? Bets are on Later

Rethinking watchdog(): logging in Kohana 3

Continuing this exploration of logging solutions used in various projects, let's look at logging in Kohana 3.

Kohana 3.3 Logging - bundled classes While Monolog and log4php share a mostly common logging model of a frontal Logger object instantiated as many times as needed to supply different logging channels, in which log events are Processed/Filtered then written out by Handlers/Writers, Kohana builds upon a simpler model, which can be summarized by three patterns:

  • Singleton: there is only one instance of the Kohana Log
  • Observer: Log_Writer instances are attached (and detached) to(/from) the logger instance and handle events they are interested in based on their own configuration. Much like a Drupal hook, all writer instances receive each Log event
  • Delegation: the Log exposes a write() to trigger the buffered writing, but does not implement it itself, but delegates to the Log_Writer objects to perform it. Buffered logging control is a Log property, not a Log_Writer property.

The logging API proper is a two-step affair:

  1. add() events as needed. No per-level helpers as in the ZF2 or Symfony logging interfaces
  2. at the end of the page cycle, have shutdown invoke Log::instance()->write() to flush the data out if buffered logging has not been deactivated
  3. An interesting bit is that unlike Symfony's LoggerInterface, the main entry point for logging is much like Drupal's watchdog() in that it uses structured message events separating the message template (watchdog parameter 2) from the message arguments (watchdog parameter 3), instead of having to stuff the arguments in the $context object: it's Log::add(<level>, <message template>, <message arguments>, <extra>). However, by using the Singleton pattern to ensure a single Log object, Kohana has no native support for multiple logging channels, which would not be a good fit for Drupal needs.

    Like most logging solutions, Kohana expects event level to be one of the 8 RFC5424 levels.

    Unlike Drupal, Kohana chose not to bundle any DB Writer, keeping to Unix standard streams and Syslog. Additional Writers can be found in the contrib space, notably on Github:

    AttachmentSize
    Kohana 3.3 Logging - bundled classes (GraphViz source)1.3 KB
    Kohana 3.3 Logging - bundles classes (SVG rendering)13.82 KB

I've tried searching all over

I've tried searching all over but can't seem to get just a simple straight forward answer.

I want to write log messages (INFO, ERROR, etc.) to the Kohana log file /application/logs/YYYY/MM/DD.php.

How do I do it? Thanks.

Logging with Kohana 3.3.

Logging is a two-step process (three with the boot in which you set up the log destination):

  1. Get the logger singleton, like $log = Log::instance();, and keep it at hand
  2. Use it to log messages, like this:
    <?php
    $log
    ->add(Log::ERROR, 'Some message about user :user', array(
       
    ':user' => "The user in question",
    ));
    ?>

If your question was actually about choosing the name of the logging file, this is in kohana/bootstrap.php, where you configure the environment. The default code is like this:

<?php
Kohana
::$log->attach(new Log_File(APPPATH.'logs'));
?>

And this gives you, as per Log_File::__construct() log files named with just the day number, in the directory named YYYY/DD as you described. You can overwrite this by creating a new Log_Writer class, probably inheriting from Log_File, and defining a new name format.