[GH-ISSUE #131] Different actions for different error levels #45

Closed
opened 2026-03-04 02:11:38 +03:00 by kerem · 4 comments
Owner

Originally created by @lopsided on GitHub (Nov 30, 2012).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/131

Hi,

Im not sure this really qualifies as an issue but my SO post got no replies so not sure where else to turn (http://stackoverflow.com/questions/13478573/symfony2-monolog-different-actions-for-different-error-levels).

I have set up Monolog for our Symfony2 project to email out critical errors to us when they occur.

However I would also like to log non-critical errors also, and to email these errors out to different recipients. I am struggling to see this in the documentation however it looks like it should be possible. I have set up the config as follows:

parameters:
    error_mail_sender: error@mysite.com
    error_mail_recipients: [siteerrors@mysite.com]
    critical_error_mail_recipients: [siteerrors@mysite.com, developer@developers.com]

monolog:
    handlers:
        main_critical:
            type:         fingers_crossed
            action_level: critical
            handler:      grouped_critical
            bubble:       false
        main_error:
            type:         fingers_crossed
            action_level: error
            handler:      grouped_error
        grouped_critical:
            type:    group
            members: [streamed, buffered_critical]
        grouped_error:
            type:    group
            members: [streamed, buffered_error]
        streamed:
            type:  stream
            path:  "%kernel.logs_dir%/%kernel.environment%.log"
            level: debug
        buffered_critical:
            type:    buffer
            handler: swift_critical
        buffered_error:
            type:    buffer
            handler: swift_error
        swift_critical:
            type:       swift_mailer
            from_email: %error_mail_sender%
            to_email:   %error_mail_recipients%
            subject:    Critical error occurred!
            level:      debug
        swift_error:
            type:       swift_mailer
            from_email: %error_mail_sender%
            to_email:   %critical_error_mail_recipients%
            subject:    Non-critical error occurred
            level:      debug

With this set up we receive the critical errors but don't get the non-critical errors.

This set up was loosely based on the (unaccepted) answer to this question: http://stackoverflow.com/questions/12481353/how-to-include-the-severity-of-a-log-in-the-e-mail-subject.

Can anyone spot what is wrong with this? Or if it is not possible to do what I am trying?

Thanks a lot!

Originally created by @lopsided on GitHub (Nov 30, 2012). Original GitHub issue: https://github.com/Seldaek/monolog/issues/131 Hi, Im not sure this really qualifies as an issue but my SO post got no replies so not sure where else to turn (http://stackoverflow.com/questions/13478573/symfony2-monolog-different-actions-for-different-error-levels). I have set up Monolog for our Symfony2 project to email out critical errors to us when they occur. However I would also like to log non-critical errors also, and to email these errors out to different recipients. I am struggling to see this in the documentation however it looks like it should be possible. I have set up the config as follows: ``` parameters: error_mail_sender: error@mysite.com error_mail_recipients: [siteerrors@mysite.com] critical_error_mail_recipients: [siteerrors@mysite.com, developer@developers.com] monolog: handlers: main_critical: type: fingers_crossed action_level: critical handler: grouped_critical bubble: false main_error: type: fingers_crossed action_level: error handler: grouped_error grouped_critical: type: group members: [streamed, buffered_critical] grouped_error: type: group members: [streamed, buffered_error] streamed: type: stream path: "%kernel.logs_dir%/%kernel.environment%.log" level: debug buffered_critical: type: buffer handler: swift_critical buffered_error: type: buffer handler: swift_error swift_critical: type: swift_mailer from_email: %error_mail_sender% to_email: %error_mail_recipients% subject: Critical error occurred! level: debug swift_error: type: swift_mailer from_email: %error_mail_sender% to_email: %critical_error_mail_recipients% subject: Non-critical error occurred level: debug ``` With this set up we receive the critical errors but don't get the non-critical errors. This set up was loosely based on the (unaccepted) answer to this question: http://stackoverflow.com/questions/12481353/how-to-include-the-severity-of-a-log-in-the-e-mail-subject. Can anyone spot what is wrong with this? Or if it is not possible to do what I am trying? Thanks a lot!
kerem closed this issue 2026-03-04 02:11:38 +03:00
Author
Owner

@Seldaek commented on GitHub (Nov 30, 2012):

The problem seems to be bubble: false in the first handler, that means it'll stop propagating messages to other handlers.

Another note, I would remove the group and the streamed handler from grouped_critical, because it will already receive errors from grouped_error, resulting in duplicate entries in the log file.

So this should work:

parameters:
    error_mail_sender: error@mysite.com
    error_mail_recipients: [siteerrors@mysite.com]
    critical_error_mail_recipients: [siteerrors@mysite.com, developer@developers.com]

monolog:
    handlers:
        main_critical:
            type:         fingers_crossed
            action_level: critical
            handler:      buffered_critical
        buffered_critical:
            type:    buffer
            handler: swift_critical
        swift_critical:
            type:       swift_mailer
            from_email: %error_mail_sender%
            to_email:   %error_mail_recipients%
            subject:    Critical error occurred!
            level:      debug

        main_error:
            type:         fingers_crossed
            action_level: error
            handler:      grouped_error
        grouped_error:
            type:    group
            members: [streamed, buffered_error]
        streamed:
            type:  stream
            path:  "%kernel.logs_dir%/%kernel.environment%.log"
            level: debug
        buffered_error:
            type:    buffer
            handler: swift_error
        swift_error:
            type:       swift_mailer
            from_email: %error_mail_sender%
            to_email:   %critical_error_mail_recipients%
            subject:    Non-critical error occurred
            level:      debug

I reordered them to make it easier to see the two handler chains as well.

<!-- gh-comment-id:10884955 --> @Seldaek commented on GitHub (Nov 30, 2012): The problem seems to be bubble: false in the first handler, that means it'll stop propagating messages to other handlers. Another note, I would remove the group and the streamed handler from grouped_critical, because it will already receive errors from grouped_error, resulting in duplicate entries in the log file. So this should work: ``` parameters: error_mail_sender: error@mysite.com error_mail_recipients: [siteerrors@mysite.com] critical_error_mail_recipients: [siteerrors@mysite.com, developer@developers.com] monolog: handlers: main_critical: type: fingers_crossed action_level: critical handler: buffered_critical buffered_critical: type: buffer handler: swift_critical swift_critical: type: swift_mailer from_email: %error_mail_sender% to_email: %error_mail_recipients% subject: Critical error occurred! level: debug main_error: type: fingers_crossed action_level: error handler: grouped_error grouped_error: type: group members: [streamed, buffered_error] streamed: type: stream path: "%kernel.logs_dir%/%kernel.environment%.log" level: debug buffered_error: type: buffer handler: swift_error swift_error: type: swift_mailer from_email: %error_mail_sender% to_email: %critical_error_mail_recipients% subject: Non-critical error occurred level: debug ``` I reordered them to make it easier to see the two handler chains as well.
Author
Owner

@lopsided commented on GitHub (Nov 30, 2012):

Thanks a lot for the reply! It is almost there now, however the only thing is that Critical errors are firing 2 emails, one from each handler. That's why I thought to add the bubble: false previously. I tried adding it back in but it doesn't seem to work

Is it possible to remove the second email for critical errors?

<!-- gh-comment-id:10892653 --> @lopsided commented on GitHub (Nov 30, 2012): Thanks a lot for the reply! It is almost there now, however the only thing is that Critical errors are firing 2 emails, one from each handler. That's why I thought to add the `bubble: false` previously. I tried adding it back in but it doesn't seem to work Is it possible to remove the second email for critical errors?
Author
Owner

@Seldaek commented on GitHub (Nov 30, 2012):

You can only filter down and not up, so you can't split the levels into =CRITICAL. That said, the problem seems to be that critical_error_mail_recipients contains the siteerrors@mysite.com, but that one doesn't need to be there, since they'll already get a mail in case of simple errors. Just removing this should make sure everyone gets at most one mail.

<!-- gh-comment-id:10893364 --> @Seldaek commented on GitHub (Nov 30, 2012): You can only filter down and not up, so you can't split the levels into <CRITICAL and >=CRITICAL. That said, the problem seems to be that critical_error_mail_recipients contains the siteerrors@mysite.com, but that one doesn't need to be there, since they'll already get a mail in case of simple errors. Just removing this should make sure everyone gets at most one mail.
Author
Owner

@lopsided commented on GitHub (Nov 30, 2012):

Right yeah I thought that might be the case.

Thanks a lot for your help and explanations :)

<!-- gh-comment-id:10893588 --> @lopsided commented on GitHub (Nov 30, 2012): Right yeah I thought that might be the case. Thanks a lot for your help and explanations :)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/monolog#45
No description provided.