Java Desktop Application Audit Log

First you need to decide what to record. Attempting to log in every user action seems unfeasible. Keeping track of his movements can be useful for analyzing the use of the interface and how the experience is. But it should be used at a specific time and if you have someone who will know how to analyze the data.

Log usage, which is called audit in the question, should record only what actually generates effect on the system.

Even because wrong actions of the user should not generate errors in the application. If this occurs, the error is from the programmer and needs to be resolved.

If logs what is written to the database, the best place to store the log is the database. I see no problem in doing this. Unless the application has architectural issues, but there's another problem. If you think you have a problem, show this.

You have several advantages in using the database. It has some advantages in using a text file on the server side.

Do not forget that storing the data on the client side, even in plain text, leaves the system vulnerable. If the user does something stupid, he will try to delete it.

The client side should be responsible for the user interface and nothing else. Business rules should be guaranteed or generate specific criticism in case it is flexible. But this should be done either in the database, or in the application, but on the server, not in the interface.

If you have the right architecture, the log process becomes almost transparent. It can even be 100% transparent with the right tools, although it can reduce the quality of the information in some cases.

As you evolve post specific questions.

Ah, audit is the logs analysis process.

Here where I work, we separate logs and auditing. For logs, such as system errors, etc., we use logback , which enables us (if running on a server) to analyze in real time the that is happening and also filter only by error or any other level.

The logback is super configurable, and in our case, it generates one file per day, and each day there may be more than 1 file if it exceeds the size of 20mb. All files are compressed (by logback), which greatly reduces the size of the file. We also have a routine to delete this, since logs from 2 weeks ago do not matter anymore.

For auditing we use mongoDB in the cloud. We have a lot of data and until today, the only problem we had, was to create an application that facilitates the reading of those records.

In a relational database, we also have a giant table containing more than 500GB of data, and this one (at the time was not very well thought out) is used only for writing. We use table partitioning techniques, which has improved a lot, but even so, any query is very costly. What we do with it is having multiple triggers filtering the incoming data and sending it to others.

Anyway, there are N solutions to this, even hibernate has something for it. As @bigown commented, just do not leave the file on the client side because it can simply erase and say it was "system crash".

Well, that was just another comment, but it did not fit all there.