Reduce q-ty of error reports created in <magento_root>/var/report

[arhiopterecs]

Problem

Sometimes some clients have problems with this error reporting mechanism. For example: In the case when there are many requests to the Http application where there is a critical error, a huge number of reports about this error will accumulate in the directory <magento_root>/var/report. Magento does not have a mechanism for cleaning the report directory. System Integrator does not spend the time for monitoring the file reports, in most cases. As a result, report files are accumulated. The number of report files grows to hundreds of thousands, and sometimes it happens that the number of report files reaches a million or more. With such a number of files in the folder, it becomes more difficult to work with error reports. It is not possible to look at the contents of the directory, and it is even difficult to remove the reports. There are cases that report files to occupy all the free space in the storage, which leads to the crash of the application.

Solution

The solution to this problem is to save only unique reports var/report/<unique_hash> and associate them with the messages in the exception log var/log/exception.log. For associations, we may use a unique hash that will be generated using an exception trace, an exception message, $_SERVER['REQUEST_URI'] and $_SERVER['SCRIPT_NAME']. The hash will be used to name the report file and this hash will be indicated in the report and the log message. And, we can save reports in subdirectories with a configurable nesting level, this avoids the overflow of the <magento_root> var/reports` directory with millions of files

Requested Reviewers

@buskamuza @kandy

[larsroettig]

Maybe it will be also good to define different output adapter not only file. It nice if can to put this in elastic search cluster. Currently, uses a job that parses files and put in cluster to build health reports for some customers.

[buskamuza]

@larsroettig , we discussed this. Definitely this is something we want to move towards, as a next step. This proposal itself provides some improvements, so I would not expand it with more improvements.

[larsroettig]

@buskamuza cool next weekend(21-22.09) we have contribution day maybe I should take some time to work on a new proposal