Auditing and Logging software applications
For any sustainable, consistent, scalable application that you dream off, the most critical aspect is to get it’s framework right. And trust me, it will never be right. There will always be one thing that is always improvable. So getting your framework right is to get it it right in terms of modifiability and resilience . For that to happen, you need to get 1 thing right. Logging/auditing.
If I have to name top 3 things I would look at while rating an application. I will always list logging and auditing. This is one thing I feel most teams, architects under appreciate.
I would say it’s most critical that everybody in the team understands what to log, when to log and how to log *replace with audit and read the last line again*.
For a production grade system every request, who requested, what was in the request, what was the response and how much time it took your system to respond is really critical. Log or audit every request uniquely, may be a unique request id.
In case of an error log when it happened, what happened, where it happened. If you do that correctly arriving at a why should be a piece of cake most of the time.
Don’t over log, I see this problem in many teams. Logging too much information will just make you loose what was important. You don’t need to log/audit something that your logic generated. If you log the request and all input data points (eg: database values, or at least reference to data record, with a well audited data store, all api calls responses) , you should be there.
If you don’t audit, you dunno anything about your system. It could develop a mind of its own and you will be left wondering why? Lets not get to the extremes, just audit and log, whatever technology you use. Its like buying a safe that follows the thief.
