I'm trying to optimize my project logs (Because my log got 3Gb at now) so that when something goes wrong the server send me an email with the details of the error.
I would like to appear in the log only major errors, such as 500 errors, errors that affect the proper functioning of the project.
I have looked at the documentation of the bundle of monolog on the official Symfony2 but I have not been at all clear.
(http://symfony.com/doc/current/reference/configuration/monolog.html)
Could someone tell me how to get this?
We defined
monolog:
handlers:
main:
action_level: error
in our production environment.
Of course you have to check which handler (in our case: 'main') you need to adapt but by changing the action_level to 'error' you get rid of all the debug/info statements in your log and only level 'error' is shown.
Please check your Swift part:
You have level: 'debug' which is obviously not corresponding with your requirement. You should use 'error' or 'critical' instead. See http://symfony.com/doc/current/cookbook/logging/monolog_email.html as well.
Generally it would be helpful to know what kind of log is producing too much and what kind of information? (e.g. we put Doctrine to a different monolog channel to get rid of it in our main log).
Here is my config for monolog.
monolog:
handlers:
main:
action_level: error
console:
type: console
bubble: false
mail:
type: fingers_crossed
action_level: critical
handler: buffered
buffered:
type: buffer
handler: swift
swift:
type: swift_mailer
from_email: his#email.com
to_email: my#email.com
subject: Critical error spotted
level: debug
Related
I am using the fingers crossed handler to buffer log messages until an error occurs. Below is my config:
monolog:
handlers:
buffer:
action_level: error
excluded_http_codes: [401, 403, 404]
handler: logger
type: fingers_crossed
logger:
formatter: monolog.formatter.json
include_stacktraces: true
level: info
path: php://stderr
type: stream
I am finding that exceptions that should match the excluded_http_codes are still being output into my log.
I have dug into the Symfony\Bridge\Monolog\Handler\FingersCrossed\HttpCodeActivationStrategy class and am finding that $this->requestStack->getMasterRequest() is returning null by the time the exception reaches the isHandlerActivated method.
Is there something I am clearly doing wrong?
This issue is resolved since updating my composer packages. I'm not sure which package was specifically responsible
Is it possible your errors are occuring in a different handler? If I'm not mistaken you only block a couple errors in your buffer handler and none in your logger handler
My prod.log file is getting very large, so I want to use the rotating_file option to create one file per day (max 14). It works, everyday a new file is generated but the file prod.log still exists and logs all new messages. Is it possible to prevent the generation of prod.log file? I use Symfony 2.8, monolog 1.23.0 and the default configuration in config.yml:
monolog:
use_microseconds: false
handlers:
main:
type: rotating_file
path: '%kernel.logs_dir%/%kernel.environment%.log'
level: error
max_files: 14
Problem solved. I disabled full monolog configuration, cleared both caches, reenabled the configuration, cleared cache again, now it works. Strange cache problem, seems both configurations were used.
I want to log only the deprecated warnings to a new file. But I can't see how to achieve that with monolog. Is there a custom configuration?
Thanks in advance!
All Deprecated Message are logged As INFO level, php Channels so if You try this configuration All deprecation message will be logged in one file
monolog:
handlers:
security:
level: INFO
type: stream
path: '%kernel.logs_dir%/deprecated.log'
channels: [php]
I'm trying to configure an email logging in Symfony. I followed the cookbook and it works but I have a problem with Fatal errors.
Those errors aren't logged in prod mode. I figured out that when I add Debug::enable(); to app.php, the error get logged, however I still don't get an email.
Here is the relevant configuration:
mail:
type: fingers_crossed
action_level: critical
handler: buffer
buffer:
type: buffer
handler: swift
swift:
type: swift_mailer
from_email: %error_mail_from%
to_email: %error_mail_to%
subject: %error_mail_subject%
level: debug
This is not an easy thing to log PHP Fatal Errors, because whenever the error is thrown, PHP shutdown...
However, there is a function that can be used to do a little thing just before the process shut down : register_shutdown_function
Have a look to How do I catch a PHP Fatal Error
This is how Symfony's Debug::enable(); is doing the trick. Have a look to https://github.com/symfony/Debug/blob/master/ErrorHandler.php#L118
Which Symfony version are you using?
Seems like from 2.3 there's a nice improvement that allows you to do that (logging fatal errors). Have a look at this: https://github.com/symfony/symfony/pull/6474
I had the same problem ( fatal erros logged in production but emails not sent) and I managed to make it work adding to my config_prod.php :
services:
mydebug.debug_handlers_listener:
class: Symfony\Component\HttpKernel\EventListener\DebugHandlersListener
arguments:
- { 0:"#http_kernel", 1:'terminateWithException'}
tags:
- { name: kernel.event_subscriber }
I found that such a service is defined in \vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Resources\config\debug.xml but not in debug_prod.xml.
With callback to terminateWithException it works fine in my application.
I cannot get the symfony2 configuration to correctly overwrite values from other config-files. Here is the problem:
I have a new environment "staging" where I want to use most of the stuff from config_prod.yml but have another logging level (I want it to be as it is in development, simply logging everything to a file). Here are the config stuff I use:
config_prod.yml:
imports:
- { resource: config.yml }
monolog:
handlers:
main:
type: fingers_crossed
action_level: error
handler: nested
nested:
type: stream
path: %kernel.logs_dir%/%kernel.environment%.log
level: debug
config_staging.yml:
imports:
- { resource: config_prod.yml }
monolog:
handlers:
main:
type: stream
path: %kernel.logs_dir%/%kernel.environment%.log
level: debug
nested: ~
From my point of view, the nested logger is now null and the main logs to the given file. What really happens is that he logs every message twice! The same happens when I use this for the config_staging.yml:
imports:
- { resource: config_prod.yml }
monolog:
handlers:
main:
type: stream
path: %kernel.logs_dir%/%kernel.environment%.log
level: debug
handler: ~
nested: ~
I found a workaround, setting the action_level of the main handler to debug and leaving everything else as is, but I don't like this solution. There must be a way to overwrite config stuff so I only have the main monolog handler.
Pretty much one year later I now have an understanding of what's happening and how to prevent it:
The nested handler is befilled with the configuration from the config.yml and when parsing the config_staging.yml, the yaml component does not overwrite the whole hashmap and set the value to null but tries to merge both, resulting in the same array as before.
There is a type called null which can be used ot overwrite any Logger. It does nothing and is therefor suitable for this use case:
monolog:
handlers:
main:
type: stream
path: %kernel.logs_dir%/%kernel.environment%.log
level: debug
handler: ~
nested: ~
type: null
Another solution would be to not configure any logging in the config.yml but only in the specific environment configs like config_prod.yml and so on.
Check that you don't have any repeated keys in the _staging config file -- the second one would override the first, with the net result that the first is ignored.
If you want to alter a collection by removing an element you will have to create an intermediate YAML file (importing the base) setting the collection to "null" and re-adding all required collection elements in a file which in turn imports the intermediate YAML file.
You can not simply overwrite a collection. New elements will get added but you can't remove existing ones except by the workaround described.