Certainly these days everyone knows that your PHP project should be developed with error reporting set to report everything with E_ALL|E_STRICT (I guess the sloppy freelance days are over). When the project is deployed on a live server you can set the error reporting to log only the severe errors (fatal errors and exceptions), or you can leave it with the detailed error reporting. While I was not a fan of the latter, I did appreciate how useful it is when tracking bugs, since there is certainly a notice or a warning to hint you in the right direction. It is twice that important if your project is a SaaS solution, and you are responsible not only for the development of the application, but for hosting it and making it available to your customers. In that situation detailed logging is as priceless as doing backups: probably in 95% of the time you will not need it, but when the „fuck-up fairy“ comes knocking it is better to be prepared.
Speaking of backups, detailed logging probably shares one more feature with them – the huge space that it occupies. For an application that works without hick-ups for several months the volume of the logs is several times bigger the rest of the application data. The volume of the detailed logging data gets even bigger when 3rd party apps, plug-ins or add-ons are used, since they not always comply with the E_ALL|E_STRICT policy, and some of them might produce tons and tons of repetitive warnings and notices. Depending on the media on which the detailed logging is stored, it might cause performance degradation in the application when its volume gets out of proportions.
That’s the problem I’ve been faced with recently. I want application to run as fast as possible, not burdened by the detailed logging, yet I want to be able to have all the data I need for when tracking bugs and issues. The solution I came up with is called „Quarantine Logging“.
In general, I want to keep all the data that is required for tracking and fixing issues. So, when are these „issues“ tend to surface ? I am sure that you share the same observations as myself: issues happen when the application is deployed: when installed, or when updated. When it starts running you fix the issues that pop up, and the longer it runs, there is less chance for something to go south. Anyway, that’s not always – that’s just for most of the time: usually bugs show their ugly head when you least expect them ;) So, if we can expect problems with a certain probability for some period of time (e.g. after deployment), then let’s turn on the detailed logging only for that time. Hence, the „quarantine“ ;)
The quarantine is the time after the application has been updated, or in other words the time after the supposed problems have been introduced. Until the application is under quarantine, it will use detailed logging to report everything that’s happening. Once the quarantine is over, we can reduce the logging to only the severe emergencies: errors and uncaught exceptions. It is a fair trade-off: you get all the detailed logs for N days (a week) while under quarantine, and then only the most ugly stuff ;)
To make this work after each deployment, install or update, you have to put the application under quarantine, where you choose what period will fit your needs – in mine it is (as suggested above) 7 days. That’s not all: while not being under quarantine, an error or an uncaught exception can happen. The severe-only logging will report it, but in addition to that it will put the application in a state of „self-quarantine“ for M days (2 for example): during that time we expect the error/exception to happen again, so we are again doing the detailed logging while under quarantine.
So, that’s it for Quarantine Logging. I will not bother you with a concrete implementation, I am sure you can manage to do it yourself for your own error reporting. I myself just implemented this feature and will see how it behaves in the next few months.
