enable or disable handlers with env vars

[mathroc]

Hi,

we deploy a docker image in production, this image contains the source code, cache and assets (in short, we run composer install in the Dockerfile)

the problem is that logs are pushed to logstash with the gelf handler and this can't work in the image build process (we don't want to log to logstash at that point anyway)

I would like to enable a StreamHandler when in the docker build and the GelfHandler when the image is deployed, ideally the config would look something like this:

parameters:
  env(LOG_TO_LOGSTASH): true
  env(LOG_TO_STDERR): false

monolog:
    handlers:
        logstash:
            type: gelf
            level: warning
            ...
            enabled: '%env(bool:LOG_TO_LOGSTASH)%'
        main:
            type:  stream
            level: warning
            path:  "php://stderr"
            enabled: '%env(bool:LOG_TO_STDERR)%'

and in the Dockerfile I could do:

...

RUN LOG_TO_LOGSTASH=false LOG_TO_STDERR=true composer install

[stof]

env variables are available only at runtime, not at build time. So supporting that would mean that we would still need to instantiate the handler and put it in the logger (as we cannot change the object graph generated by the container at that point), and have a setting in the handler to make it a no-op (based on the runtime config). But handlers don't have such capability.

[mathroc]

yeah that's what I starting to fear while reading the code in this repository. At first I was thinking this could be added to the handler but as it would probably need to be added to Monolog\Handler\AbstractHandler I doubt it would be accepted as an addition to monolog.

My second idea (and last for now) would be to wrap the handler into a ToggleableHandler. if it can be detected whether enabled is specified, it could be ignored at compile time if not needed

[mathroc]

so I solved it in my project by manually creating the handlers and decorating them with a ToggleableHandler

would adding a similar mechanism into the bundle be a welcome addition ? if so I can work on a PR, otherwise feel free to close this issue

thx for the quick feedback @stof

[umulmrum]

Maybe this could be achieved by combining two changes that don't introduce too specific behavior:

1. Add a log level OFF in the configuration only, so that a logger with this log level doesn't log anything (Java's log4j does this). I didn't check the implications though.
2. Enable log level configuration by environment variables (I proposed a PR some time ago: Allow environment variables in log level configuration. #245).

[Seldaek]

Technically passing 999 as log level would mean most handlers would be disabled. AFAIK this wouldn't cause any issues.

[ppodgorskicrido]

Hi,
I encountered a similar problem. Setting 999 is not a solution as it always try to reach graylog (via gelf handler).
monologBundle is now in version 3.10. Will it be implemented?

[fnagel]

Using level: 999 will cause an error in monolog-bundle v3.10.0:

Script cache:clear returned with error code 1
[production] !!
[production] !!  In Logger.php line 508:
[production] !!
[production] !!    [Psr\Log\InvalidArgumentException]
[production] !!    Level "999" is not defined, use one of: DEBUG, INFO, NOTICE, WARNING, ERROR
[production] !!    , CRITICAL, ALERT, EMERGENCY
[production] !!
[production] !!
[production] !!  Exception trace:
[production] !!    at /var/www/html/vendor/monolog/monolog/src/Monolog/Logger.php:508