[GH-ISSUE #1757] How to extend monolog levels in monolog 3 #744

New issue

Closed

opened 2026-03-04 02:17:35 +03:00 by kerem · 3 comments

kerem commented

2026-03-04 02:17:35 +03:00

Owner

Originally created by @lerminou on GitHub (Sep 7, 2022).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/1757

Monolog version 3

Hi, We were using Monolog 2 and after upgrading to monolog 3, our app is not working anymore.

In monolog2 we have this piece of code in a custom Logger child class to extend monolog levels to add an 'AUDIT' level , for tracability, we need to keep these logs for a long time.

class Logger extends MonologLogger implements LoggerInterface
{
    public static function addLegalLevel()
    {
        self::$levels[LoggerInterface::AUDIT] = 'AUDIT';
    }
}

Now in monolog 3, levels are defined with an ENUM, which cannot be extended.
And the \Monolog\Logger class is referencing this ENUM.

What's the new way to extend monolog levels ?

(we Use Symfony too.)

Originally created by @lerminou on GitHub (Sep 7, 2022). Original GitHub issue: https://github.com/Seldaek/monolog/issues/1757 Monolog version 3 Hi, We were using Monolog 2 and after upgrading to monolog 3, our app is not working anymore. In monolog2 we have this piece of code in a custom Logger child class to extend monolog levels to add an 'AUDIT' level , for tracability, we need to keep these logs for a long time. ``` class Logger extends MonologLogger implements LoggerInterface { public static function addLegalLevel() { self::$levels[LoggerInterface::AUDIT] = 'AUDIT'; } } ``` Now in monolog 3, levels are defined with an ENUM, which cannot be extended. And the \Monolog\Logger class is referencing this ENUM. What's the new way to extend monolog levels ? (we Use Symfony too.)

kerem

2026-03-04 02:17:35 +03:00

closed this issue
added the
Support
label

kerem commented

2026-03-04 02:17:36 +03:00

Author

Owner

@stof commented on GitHub (Sep 7, 2022):

Levels are not something that is extendable (that was not really a supported usage of Monolog 2 btw, more a hack of the implementation, and it would not pass static analysis checks).

To me, this is something you should solve with a dedicated channel of MonologBundle (i.e. a dedicated Logger instance with a specific config) rather than a special level.

@stof commented on GitHub (Sep 7, 2022): Levels are not something that is extendable (that was not really a supported usage of Monolog 2 btw, more a hack of the implementation, and it would not pass static analysis checks). To me, this is something you should solve with a dedicated channel of MonologBundle (i.e. a dedicated Logger instance with a specific config) rather than a special level.

kerem commented

2026-03-04 02:17:36 +03:00

Author

Owner

@lerminou commented on GitHub (Sep 7, 2022):

Oh, that's a bad news, thanks for the quick response.

Monolog a quite a standard and used is all php libraries.
What's the motivation to remove the possiblity to extend it (I just saw a commit to mark Logger as final)

In Symfony, the DI can help us to use the new Logger service, but duplicate the Logger logic is not very interesting

@lerminou commented on GitHub (Sep 7, 2022): Oh, that's a bad news, thanks for the quick response. Monolog a quite a standard and used is all php libraries. What's the motivation to remove the possiblity to extend it (I just saw a [commit to mark Logger as final](https://github.com/Seldaek/monolog/commit/3cba75ec0926eec177a4a2cd6c977ecddd0fc7c1)) In Symfony, the DI can help us to use the new Logger service, but duplicate the Logger logic is not very interesting

kerem commented

2026-03-04 02:17:36 +03:00

Author

Owner

@Seldaek commented on GitHub (Oct 12, 2022):

IMO custom levels was always a bad idea, because many handlers are built to handle the specific levels monolog ships with. And many log storage backends are also only using the standard 8 levels.

So yes as @stof mentioned using a custom channel so you can store these logs in a special place probably makes most sense. Or tag the logs somehow using a special context/extra data that lets you identify them.

@Seldaek commented on GitHub (Oct 12, 2022): IMO custom levels was always a bad idea, because many handlers are built to handle the specific levels monolog ships with. And many log storage backends are also only using the standard 8 levels. So yes as @stof mentioned using a custom channel so you can store these logs in a special place probably makes most sense. Or tag the logs somehow using a special context/extra data that lets you identify them.

kerem referenced this issue

2026-03-04 03:09:42 +03:00

[PR #744] [MERGED] move from abandoned package to maintained package #1326

kerem referenced this issue

2026-03-04 03:09:42 +03:00

[PR #750] [MERGED] use maintained package reference in suggestion #1328