Confluence Analytics Events Are Not Being Retained As Long As Expected
Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.
Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Confluence Analytics allows you to retain data based on both a date range and a limit on the number of events. Since raising the limit on events over 20 million can cause performance issues, it is not recommended. However, even with this high of a limit in place, you may find that your records do not go back as far as you expect. This is likely due to spikes in event creation. This guide will help you identify where these spikes are coming from.
This guide does not advise manually altering or removing any of the data you identify. It is strictly for informational purposes.
Background Notes
- Before checking anything below, you should ensure that the Confluence Analytics data retention settings match what you intend them to be.
- Confluence Analytics events are stored in the AO_7B47A5_EVENT table.
- For this information to be useful, you should be comfortable looking at your database.
Analysis Steps
List the number of events associated with each space:
SELECT SPACE_KEY, COUNT(SPACE_KEY) as event_count FROM AO_7B47A5_EVENT GROUP BY SPACE_KEY ORDER BY event_count DESC
List the number of events associated with each user:
SELECT um.username, COUNT(um.username) as event_count FROM AO_7B47A5_EVENT AS ae JOIN user_mapping AS um ON ae.USER_KEY = um.user_key GROUP BY um.username ORDER BY event_count DESC
Use the above information to identify potential high volume spaces or users. It's important to note that being high volume does not necessarily mean there is a problem, but it gives you a starting point for investigation.
Use the following two queries to identify the events for the users and/or spaces you want to investigate:
SELECT * FROM AO_7B47A5_EVENT WHERE SPACE_KEY = '<DESIRED_SPACE_KEY>'; SELECT * FROM AO_7B47A5_EVENT AS ae JOIN user_mapping AS um ON ae.USER_KEY = um.user_key WHERE username = '<DESIRED_USERNAME>';
Using the contents of the AO_7B47A5_EVENT table, you can identify the types of events being logged, when they were logged, and other specifics that can help you identify the cause of your rentention issue. If you need additional assistance with interpreting these results, please reach out to our support team.