Health check: Audit log capacity
About the health check
This check warns you when the number of Audit log events in the database is about to exceed the set limit. By default the limit is 10 million records, regardless of the retention period you select. The limit is configurable using a system property, and is designed to ensure your database is not about to grow out of all proportion.
This check applies to the improved audit log available in Jira 8.8, Confluence 7.5 and Bitbucket 7.0 and later (Server and Data Center).
Understanding the results
Icon | Result | What this means |
|---|---|---|
| The number of Audit log events in the database does not exceed 80% of the set limit. | You are not about to exceed the set limit in the near future. |
| The number of Audit log events in the database has exceeded 80% of the set limit. Once this reaches 100% we’ll start deleting the oldest events, regardless of your retention settings. | You’re in danger of exceeding the set limit in the near future. If you see this warning, you should take action to make sure you don’t lose any events when you hit the capacity limit. |
| The number of Audit log events in the database has reached 100% of the set limit. We'll now be regularly deleting the oldest records exceeding the set limit. | You have exceeded the set limit, and events are now being deleted from your database, starting with the oldest. You should take action now to resolve this. |
What happens if I ignore the warning?
When you receive the warning, you need to take action because when you exceed 100% of the capacity, we’ll delete the events that exceed the set limit, starting with the oldest. The events will be deleted based on the timestamp, so there is a chance some important events will get deleted.
You will receive a notification when your capacity goes over 100% but there won’t be any separate message informing you that the events got deleted.
Resolution
There are several actions you can take when you’re about to reach the capacity limit. However, if you are fine with events being deleted, you don't need to take any action.
Because we cache the event count, it will take up to an hour for the check to start passing after you have taken one of these actions.
Review coverage levels
It might be a good idea to start with reviewing the coverage levels you have selected. If you have those set to Full, this might generate a lot of events. Especially, 3rd-party apps might create a great deal of data. If you decide, you only want the core events to be logged, select Base as your coverage level.
Learn more about the events logged at coverage levels:
Reduce the retention period
You can reduce the amount of data being stored by decreasing the retention time. This will delete all the events that are older than the set retention period and will potentially prevent the audit log from reaching the hard capacity limit. Additionally, your audit search performance will increase.
All the events older than the newly set limit will be deleted so if you want to preserve them, back up your database or export your events. You don’t need to do this if you run Data Center as all your events are also logged to a file.
Learn more about setting retention period:
Back up your database
If you back up your database, you will not lose any events. However, this requires you to have a direct access to the database. If your database capacity is limited and you have some noisy apps producing lots of events, you might need to do this frequently.
You can use the following queries to perform the backup of the audit table:
$ pg_dump -t "public.\"AO_C77861_AUDIT_ENTITY\"" <database_name> > db.sql
Alternatively, you can backup the whole database:
$ pg_dump <database_name> > db.sql
Refer to the PostgreSQL documentation for more details. If you use a different database, your can change the commands to fit your needs.
Increase the hard capacity limit
By default the limit is set at 10 million events. However, if you can’t immediately perform a database backup, you can temporarily increase the limit, to prevent any records being deleted. You can do this with the plugin.audit.db.limit.rows system property. This will allow you to store more events, but your database and audit search might be slower due to the increased amount of data. Also, increasing the limit might result in performance issues.
Make sure your system can store more data before you change the limit.