[GH-ISSUE #1543] [rfc] add a 'fanout' / 'switching' log handler

kerem commented

2026-03-04 02:16:46 +03:00

Owner

Originally created by @gggeek on GitHub (Mar 24, 2021).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/1543

I might be abusing the logging subsystem here, but consider this usecase: an application has a logging configuration for 'everyday' usage, and another configuration for 'special contexts'.
Special contexts might be fe. some cli commands which are better logged to a dedicated log file, while other cli commands use the default logging config. Or even, there could be a logging config for console commands and one for web pages.
They are not easy to implement using the 'channel' concept because that concept is generally already in use, eg. in Symfony applications it is used to denote the 'source component/subsystem'.

A 'switching' log handler is basically almost the same as the existing GroupHandler, but it always forwards log messages to only one of its nested handlers (switch), or to a set of them (fanout).

Code-wise, it could be as easy as extending the GroupHandler class and adding an useHandler($index) method, or possibly enableHandler()/disableHandler().

Then the app code would be able to decide at runtime, based on its own logic, which nested handlers to enable/disable.

WDYT?

Originally created by @gggeek on GitHub (Mar 24, 2021). Original GitHub issue: https://github.com/Seldaek/monolog/issues/1543 I might be abusing the logging subsystem here, but consider this usecase: an application has a logging configuration for 'everyday' usage, and another configuration for 'special contexts'. Special contexts might be fe. some cli commands which are better logged to a dedicated log file, while other cli commands use the default logging config. Or even, there could be a logging config for console commands and one for web pages. They are not easy to implement using the 'channel' concept because that concept is generally already in use, eg. in Symfony applications it is used to denote the 'source component/subsystem'. A 'switching' log handler is basically almost the same as the existing `GroupHandler`, but it always forwards log messages to only one of its nested handlers (switch), or to a set of them (fanout). Code-wise, it could be as easy as extending the GroupHandler class and adding an `useHandler($index)` method, or possibly `enableHandler()/disableHandler()`. Then the app code would be able to decide at runtime, based on its own logic, which nested handlers to enable/disable. WDYT?

kerem

2026-03-04 02:16:46 +03:00

closed this issue
added the
Feature
label

kerem commented

2026-03-04 02:16:48 +03:00

Author

Owner

@gggeek commented on GitHub (Mar 24, 2021):

POC code:

<?php

namespace gggeek\poc;

use Monolog\Handler\GroupHandler;
use Monolog\Handler\HandlerInterface;

/**
 * @todo should we add support for 'level ?
 */
class SwitchingMonologHandler extends GroupHandler
{
    protected $currentHandlerIndex = 0;
    
    public function __construct(array $handlers, bool $bubble = true)
    {
        if (!count($handlers)) {
            throw new \InvalidArgumentException('Switching log handler needs at least one nested handler');
        }

        parent::__construct($handlers, $bubble);

        // support non-numeric keys
        reset($handlers);
        $this->currentHandlerIndex = key($handlers);
    }

    /**
     * @param int|string $handlerIndex
     * @throws \InvalidArgumentException
     */
    public function useHandler($handlerIndex)
    {
        if (!array_key_exists($handlerIndex, $this->handlers)) {
            throw new \InvalidArgumentException("No nested handler found with index '$handlerIndex'");
        }
        $this->currentHandlerIndex = $handlerIndex;
    }

    /**
     * {@inheritdoc}
     */
    public function isHandling(array $record): bool
    {
        return $this->handlers[$this->currentHandlerIndex]->isHandling($record);
    }
        
    public function handle(array $record): bool
    {
        /*if ($record['level'] < $this->level) {
            return false;
        }*/

        if ($this->processors) {
            $record = $this->processRecord($record);
        }
        
        $this->handlers[$this->currentHandlerIndex]->handle($record);

        return false === $this->bubble;
    }

    public function handleBatch(array $records): void
    {
        if ($this->processors) {
            $processed = [];
            foreach ($records as $record) {
                $processed[] = $this->processRecord($record);
            }
            $records = $processed;
        }

        $this->handlers[$this->currentHandlerIndex]->handleBatch($records);
    }
}

@gggeek commented on GitHub (Mar 24, 2021): POC code: ``` <?php namespace gggeek\poc; use Monolog\Handler\GroupHandler; use Monolog\Handler\HandlerInterface; /** * @todo should we add support for 'level ? */ class SwitchingMonologHandler extends GroupHandler { protected $currentHandlerIndex = 0; public function __construct(array $handlers, bool $bubble = true) { if (!count($handlers)) { throw new \InvalidArgumentException('Switching log handler needs at least one nested handler'); } parent::__construct($handlers, $bubble); // support non-numeric keys reset($handlers); $this->currentHandlerIndex = key($handlers); } /** * @param int|string $handlerIndex * @throws \InvalidArgumentException */ public function useHandler($handlerIndex) { if (!array_key_exists($handlerIndex, $this->handlers)) { throw new \InvalidArgumentException("No nested handler found with index '$handlerIndex'"); } $this->currentHandlerIndex = $handlerIndex; } /** * {@inheritdoc} */ public function isHandling(array $record): bool { return $this->handlers[$this->currentHandlerIndex]->isHandling($record); } public function handle(array $record): bool { /*if ($record['level'] < $this->level) { return false; }*/ if ($this->processors) { $record = $this->processRecord($record); } $this->handlers[$this->currentHandlerIndex]->handle($record); return false === $this->bubble; } public function handleBatch(array $records): void { if ($this->processors) { $processed = []; foreach ($records as $record) { $processed[] = $this->processRecord($record); } $records = $processed; } $this->handlers[$this->currentHandlerIndex]->handleBatch($records); } } ```

kerem commented

2026-03-04 02:16:48 +03:00

Author

Owner

@stof commented on GitHub (Mar 24, 2021):

to me, the SwitchingHandler should not be a subclass of GroupHandler. the behavior is different

@stof commented on GitHub (Mar 24, 2021): to me, the SwitchingHandler should not be a subclass of GroupHandler. the behavior is different

kerem commented

2026-03-04 02:16:48 +03:00

Author

Owner

@gggeek commented on GitHub (Mar 24, 2021):

@stof that was just the quick-win for me to implement a poc while writing the proposal :-D I am more interested in feedback on the idea, and open to implement it differently

@gggeek commented on GitHub (Mar 24, 2021): @stof that was just the quick-win for me to implement a poc while writing the proposal :-D I am more interested in feedback on the idea, and open to implement it differently

kerem commented

2026-03-04 02:16:48 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 4, 2021):

In a symfony context where you have channels, IMO it is perfectly fine to say that you have a cli_special channel which ends up in some other file, and can possibly also be included in the all-logs file. Then the commands which are special use the cli_special channel. Or if you need to decide at runtime you can also receive two loggers and decide which you log to, or even use Monolog\Registry for that..

I overall don't really see the need for this in core, which is not to say it's pointless but IMO it's too complex and logging code shouldn't have to concern itself with such matters, picking a channel should be the most you do when logging. If the app wants to decide to route some logs sometimes some place.. then I'd rather set some extra data in $context when logging and then have a FilterHandler-style thing that decides where to route the messages. But this would be a custom implementation for the app/need. Not everything needs to be made generic.

@Seldaek commented on GitHub (Apr 4, 2021): In a symfony context where you have channels, IMO it is perfectly fine to say that you have a cli_special channel which ends up in some other file, and can possibly also be included in the all-logs file. Then the commands which are special use the cli_special channel. Or if you need to decide at runtime you can also receive two loggers and decide which you log to, or even use Monolog\Registry for that.. I overall don't really see the need for this in core, which is not to say it's pointless but IMO it's too complex and logging code shouldn't have to concern itself with such matters, picking a channel should be the most you do when logging. If the app wants to decide to route some logs sometimes some place.. then I'd rather set some extra data in $context when logging and then have a FilterHandler-style thing that decides where to route the messages. But this would be a custom implementation for the app/need. Not everything needs to be made generic.

kerem commented

2026-03-04 02:16:48 +03:00

Author

Owner

@gggeek commented on GitHub (Apr 4, 2021):

@Seldaek I agree that not everything should be in core, and that this might be a niche requirement.

However, your proposals for possible solutions make me think that you might have misunderstood the original requirement.

What I was asking for is not for the log messages generated by code belonging to a specific command or block of code to be routed to a specific log - which can be easily achieved via a channel. It was for all log messages generated by the application, including the ones coming from 3rd party bundles and libraries, to be routed to different logs depending upon some runtime condition which can be triggered based on an external information, including f.e. a cli switch.
In terms of a symfony app, one might visualize the alternative logging config as a dedicated symfony environment, where only the logging configuration is different.

I don't want the app code to concern itself with this "use alternate logging condition" for the exact reason that you stated: the app should not concern itself with logging configuration. That, and of course I cannot alter the code of the 3rd party libs which generate log messages.

My proposed solution is, imho of course, an implementation of a "FilterHandler-style thing that decides where to route the messages"; it just feels to me more elegant than one that wold rely on injecting data into $context

@gggeek commented on GitHub (Apr 4, 2021): @Seldaek I agree that not everything should be in core, and that this might be a niche requirement. However, your proposals for possible solutions make me think that you might have misunderstood the original requirement. What I was asking for is not for the log messages generated by code belonging to a specific command or block of code to be routed to a specific log - which can be easily achieved via a channel. It was for _all_ log messages generated by the application, including the ones coming from 3rd party bundles and libraries, to be routed to different logs depending upon some runtime condition which can be triggered based on an external information, including f.e. a cli switch. In terms of a symfony app, one might visualize the alternative logging config as a dedicated symfony environment, where only the logging configuration is different. I don't want the app code to concern itself with this "use alternate logging condition" for the exact reason that you stated: the app should not concern itself with logging configuration. That, and of course I cannot alter the code of the 3rd party libs which generate log messages. My proposed solution is, imho of course, an implementation of a "FilterHandler-style thing that decides where to route the messages"; it just feels to me more elegant than one that wold rely on injecting data into $context

kerem commented

2026-03-04 02:16:48 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 5, 2021):

Ok in that I'd say a new handler that receives all logs and has an on/off switch of some kind makes most sense. Maybe we could add this but I wouldn't make it switching to keep it simple it could be like ToggledGroupHandler or smth that has enable/disable methods and accepts an enabled param in constructor so you can preconfigure it if that makes sense.

Then by setting bubble=false and defining this first you could essentially siphon all logs in there and away from other handlers once you turn it on. Does that make sense? If you want switching you could create a few of those in series i guess and enable the group you're interested in.

It's close to what you proposed for sure but I find it easier to grasp, not sure what you think?

@Seldaek commented on GitHub (Apr 5, 2021): Ok in that I'd say a new handler that receives all logs and has an on/off switch of some kind makes most sense. Maybe we could add this but I wouldn't make it switching to keep it simple it could be like ToggledGroupHandler or smth that has enable/disable methods and accepts an enabled param in constructor so you can preconfigure it if that makes sense. Then by setting bubble=false and defining this first you could essentially siphon all logs in there and away from other handlers once you turn it on. Does that make sense? If you want switching you could create a few of those in series i guess and enable the group you're interested in. It's close to what you proposed for sure but I find it easier to grasp, not sure what you think?

kerem referenced this issue

2026-03-04 03:08:23 +03:00

[PR #660] [CLOSED] Fix RavenHandlerTest to work with upstream changes #1282

Rows
Columns

[GH-ISSUE #1543] [rfc] add a 'fanout' / 'switching' log handler #659