What should be in Event/Audit records?

Question

For an Enterprise Application, do you write event/audit records just for auditing and debugging purpose (apart from writing transaction records to DB)?

If you do, do you write them to flat files or directly to DB? or Both? What information do you capture?

Answer 1

It completely depends on your business needs. Sometimes businesses have requirements that every single change on every item, by user and time, be recorded. Some require that and that every singe read of the data be logged. Some applications only record when certain data types change. It depends on what you want. Reasonable information captured is: Who, What, When...

Audit logging is typically not technical in nature, the way print statements would be; you wouldn't start with audit-logs for debugging purposes, although you could use them if you wanted. But normal application logs are better suited to debugging issues, as they typically contain stack traces and whatnot, while audit logs do not.

With respect to DB or flat file, again, it depends. Writing to the DB is appealing especially with Hibernate/JPA in that you can hook into the event system of your persistence layer to generate the audit events. It is a quite natural mapping, because Hibernate/JPA have events for 'save', 'update', 'delete' etc, exactly what you want to audit. If requirements call for certain types of users to be able to review the log information, then having the data in the DB is also beneficial. Also, most enterprises back up their date regularly, which also preserves the audit info.

On the other hand, you can't beat the simplicity of flat file logging, if you just need to keep a record.