【问题标题】:Why does Symfony still log to a dev.log file, even when I didn't define it in a loghandler?为什么 Symfony 仍然记录到 dev.log 文件,即使我没有在 loghandler 中定义它?
【发布时间】:2013-12-22 05:45:48
【问题描述】:

在 Symfony 命令执行期间,我想将消息记录到不同的文件中。我已经阅读了 Symfony 和 Monolog 文档,它应该像我在这里描述的那样工作。 (请注意,我知道来自 'doctrine'、'event'、... 频道的消息仍将由主处理程序记录,但这对我来说无关紧要)

在我的config.yml,我有这个:

monolog:
    channels: [commandline]
    handlers:
        main:
            type:  stream
            path:  "%kernel.logs_dir%/%kernel.environment%.main.log"
            level: debug
            channels: [!commandline]
        commandline:
            type:  stream
            path:  "%kernel.logs_dir%/%kernel.environment%.commandline.log"
            level: debug
            channels: commandline
        stdout:
            type:  stream
            path:  "php://stdout"
            level: debug
            channels: commandline
        mail:
            type:         stream
            action_level: alert
            handler:      buffered_mail
        buffered_mail:
            type:    buffer
            handler: swift
        swift:
            type:       swift_mailer
            from_email: some@email.com
            to_email:   some@email.com
            subject:    "Something went wrong"
            level:      alert

我希望有 2 个日志文件:dev.main.logdev.commandline.log。 但是我仍然有第三个日志文件:dev.log,它记录了 all 消息。 我似乎没有找到该日志处理程序的定义位置以及如何防止它记录事情......

如果有人能指出我正确的方向,那就太好了!

顺便说一句,我正在使用:

  • symfony 2.3
  • 独白包 2.4

编辑

config_dev.yml 中没有 monolog 部分

【问题讨论】:

  • 请将您的config_dev.ymlmonolog 部分添加到问题中。
  • 我可以确认我在devprod 配置文件中都有monolog,但dev 记录条目,如果我没有明确调用app_dev.php。所以,这是您遇到的一些最小配置...
  • @nifr 您的建议确实非常有效。 @Stivni 您的配置与我的唯一不同的是我在 main 记录器中使用 fingers_crossed 策略
  • 我认为他可能已经从他的config_dev 中删除了覆盖main 处理程序,但没有清除他的(操作码)缓存或类似的东西。在 symfony 标准中,这个产生 logs/<env>.log 的默认处理程序在 config.yml / config_dev.yml 中配置,其他任何地方都没有。唯一的其他原因可能是其他处理程序中某处缺少路径,因为%kernel.logs_dir%/%kernel.environment%.logdefaultValue of path
  • @nifr 这些是我一开始就期待的建议。也许您应该将它们包括在您的答案中,然后我将撤销我的反对票。但是:我清除了缓存并没有发现任何变化。您对 path 的 defaultValue 的建议似乎更像我的经验。我将进一步调查它。如果我找到解决方案,我会通知您。

标签: php symfony logging monolog


【解决方案1】:

删除 monolog.handlers.main来自config_dev.yml

它通常包含 path: "%kernel.logs_dir%/%kernel.environment%.log"

配置 _dev.yml(默认)

monolog:
    handlers:
        main:   # <- remove this handler
            type:   stream
            path:   "%kernel.logs_dir%/%kernel.environment%.log" #<- logs/dev.log
            level:  debug

从此配置文件中删除 main 处理程序。

【讨论】:

  • 这只是隐藏问题:Symfony、Monolog 或其他东西正在使用日志处理程序和日志文件,我没有定义。我想知道在哪里以及为什么。
  • 感谢 downvote 在 99% 的情况下可以帮助其他用户的合法答案?! ...因为config_dev.yml 覆盖了来自config.ymlmain 处理程序,并在开发环境中引入了日志文件dev.log。祝你好运解决这个问题......老实说,我希望没有其他人会回答。您是否尝试从 config_dev.yml 删除带有该日志文件路径的 main 处理程序?什么是隐藏这里的问题...解释一下!
  • 我的问题是:“为什么 Symfony 仍然记录到 dev.log 文件,即使我没有在日志处理程序中定义它?” - 我认为您的回答没有解决问题。您无需解释为什么会发生这种情况,而是假设定义了其他处理程序。好吧:config_dev.yml 文件中没有其他处理程序。您的建议也忽略了我可能想要为我的日志文件添加后缀的事实。我认为downvote 与您认为的答案一样合法......
  • @Stivni 4 年后我才读到他的答案,它为我解决了一个问题
  • @Edward 4 年后......这有多酷?很高兴我能帮上忙 - 让我过得愉快,感谢您留下评论 :)
【解决方案2】:

如果有人遇到这个并且仍然对为什么会发生这种情况感兴趣,调试处理程序将被注入到 \Symfony\Bundle\MonologBu​​ndle\DependencyInjection\Compiler\DebugHandlerPass::process() 方法中......

class DebugHandlerPass implements CompilerPassInterface
{
    // ...

    public function process(ContainerBuilder $container)
    {
        if (!$container->hasDefinition('profiler')) {
            return;
        }

        if (!$container->getParameter('kernel.debug')) {
            return;
        }

        $debugHandler = new Definition('%monolog.handler.debug.class%', array(Logger::DEBUG, true));
        $container->setDefinition('monolog.handler.debug', $debugHandler);

        foreach ($this->channelPass->getChannels() as $channel) {
            $container
                ->getDefinition($channel === 'app' ? 'monolog.logger' : 'monolog.logger.'.$channel)
                ->addMethodCall('pushHandler', array(new Reference('monolog.handler.debug')));
        }
    }
}

如您所见,这会将一个新的处理程序推送到每个已注册的通道,从而覆盖可能已经添加的任何其他处理程序。

【讨论】:

    猜你喜欢
    • 2022-01-13
    • 1970-01-01
    • 2020-08-25
    • 2020-11-25
    • 2021-04-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-04-08
    相关资源
    最近更新 更多