Continuing this exploration of logging solutions used in various projects, let's look at logging in Kohana 3.
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_Writerinstances 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
- Delegation: the
write()to trigger the buffered writing, but does not implement it itself, but delegates to the
Log_Writerobjects to perform it. Buffered logging control is a
Logproperty, not a
The logging API proper is a two-step affair:
add()events as needed. No per-level helpers as in the ZF2 or Symfony logging interfaces
- 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
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: