var/log/sailthru.log file size grows out of control

[dpoltoratsky]

The issue we are experiencing right now is that the log file var/log/sailthru.log grows in size about 2G a day which eats up available disk space quite quickly.

I believe this is happening because every single request to API is being logged at "info" level.

There is no way to configure which log level(s) we would like to have reported in our log file. We believe that there is indeed no need for "info" level in the production environment.

[silverman63]

Hi @dpoltoratsky, that definitely makes sense. I've started looking into this and can post here when we have an update.

It looks like we'll have to instantiate loggers without DI, though, as the log-level will have to be retrieved via helper. Glad to hear any thoughts you have on it.

[dpoltoratsky]

Hi @silverman63 ,

It looks like we'll have to instantiate loggers without DI, though, as the log-level will have to be retrieved via helper.

Well, I guess that depends on a solution you are leaning towards from business case perspective.

What we did, for example, to solve the issue in the meantime is put a filter on the log writer to only log messages of "ERR" level and higher.

You guys could easily make it configurable via store configuration.

namespace Sailthru\MageSail;

...

class Logger extends ZendLogger
{
    ...

    public function __construct(StoreManager $storeManager)
    {
        parent::__construct();
        $streamWriter = new Stream(BP . self::SAILTHRU_PATH);
        
        /** 
         * Here is where you guys could read a store configuration value to put a filter on logged messages (a dropdown 
         * with log level values from \Zend\Log\Logger).
         * 
         * I would leave it at \Zend\Log\Logger::ERR to be default for production environments.
         */
        $streamWriter->addFilter(\Zend\Log\Logger::ERR);
        
        $this->addWriter($streamWriter);
        $this->storeManager = $storeManager;
    }

    ...
}

`

[silverman63]

Hi, @dpoltoratsky - yep! I was playing around with that implementation as well.

So all of our store config retrievals happens via instantiated helpers. So there's a circular import here if a logger needs to get a setting from an instantiated helper which needs the logger which needs a helper etc, etc..

Have a branch where I'm playing around with it, and I think the way to solve is to just stop dependency injecting the logger. We'd prefer not to hard-code any logger filter value in case someone can't extend.