Desktop application audit log

Question

Thinking about a Java application desktop that is running in a company, we may come across situations that the user may cause failures in your application, in this case could create a log error and an audit to know which error was caused and how the user arrived there is that error. Regarding creating a log I already have something designed and planned but in terms of auditing how could I do.

• Create a table in the database and record everything done in the system. (I find it impracticable and consume too much database to store this information).

• Create a text file that stores the entire process performed in the use terminal, and records the entire process.

Would saving to the text file be the most feasible? How to log all processes, such as button clicks and fields that have been filled or not filled?

Answer 1

First you need to decide what to save. Try log in each user action seems unfeasible. Monitoring his movements can be useful to analyze the use of the interface and how is the experience, but it should be used at a specific time and if there is someone who will know how to analyze the data.

Log of use, which is called audit in question, should record only what actually generates effect on the system. Even because wrong user actions should not generate errors in the application. If this occurs the error is from the programmer and needs to solve.

Is going log in what is written in the database, the best place to store the log is the database. I see no problem in doing this. Unless the application has architecture problems, but there is another problem. If you think you have a problem, demonstrate this. It doesn’t necessarily have to be in the same database.

It has 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 more in plain text, leaves the system vulnerable. If the user makes a mistake he will try to delete this.

The client side must be responsible for the user interface and nothing else. Business rules should be guaranteed or generate specific criticism if it is flexible. 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 process of log becomes almost transparent. You can even be 100% transparent with the right tools, although you can decrease the quality of information in some cases.

As post specific questions evolve.

Ah, auditing is the process of analysing logs.

Answer 2

Here where I work, we part ways logs and audit. To logs, such as system errors, etc., we use the Logback, which enables us (if running on server), to analyze in real time what is happening and also to filter only by error or any other level.

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

For auditing we use Mongodb in the cloud. We have a large volume of data and to this day, the omnico problem that we had, was to create an application that facilitates the reading of these records.

In a relational database, we also have a giant table containing more than 500gb of data, and this (at the time was not very well thought out) is only used for writing. We used table partitioning techniques, which improved a lot, but still any query is very expensive. What we do with her is have several triggers filtering the incoming data and sending it to others.

Anyway, there are N solutions to this, including Hibernate has something for it. As @Maniero commented, just don’t leave the file on the client side because it might simply delete and say it was "system failure".

Well, that was just another comment, but it didn’t fit all there.